Overview
Policy Statement
Vulnerability: a weakness or system flaw that renders the system open for attack thus reducing its information security assurance. A vulnerability can be found in proprietary developed software, open-source software, system, or process.
This policy details the vulnerability management procedures and guidelines required to maintain a high level of system and application security in a diverse IT and Cloud environment. It outlines a comprehensive and integrated program to detect and remediate vulnerabilities in operating systems, applications, source code, open-source software, mobile devices, cloud resources, and network devices.
Responsibles and Service Levels
A key element of Incident response planning is to identify the key personnel both internally and externally that is able to deal with all incident response scenarios, including the case of vulnerability discovery.
- Head of Engineering – the owner of the vulnerability;
- CISO and Compliance officer – responsible for reviewing scan results. These roles should decide whether identified vulnerabilities are mitigated or their associated risks are accepted;
- CloudOps/DevOps Lead – responsible for scheduling and coordinating remediation actions.
Service Levels
| Priority | Severity Level | SLA | Description | |-----------|-------------------------------------------|-----------|-----------------------------------| | P0 | Critical (we will not exist as a company) | 1 Day | CVSS score >= 8.0, can be readily compromised with publicly available tooling, malware, or exploits | | P1 | High (improve and secure how we operate) | 3 Days | CVSS score >= 8.0 or are given a high severity rating by standards such as PCI DSS v3. There is no known public malware or exploit available | | P2 | Medium | 30 Days | CVSS score of 6.0 to 8.0 and can be mitigated within an extended time frame | | P2 | Low | 90 Days | CVSS score of < 6.0, to be documented and properly excluded if it cannot be remediated |
Assessment Schedule
| Assessment Type | Frequency of Testing | |-------------------------------------------|-----------------------| | Perimeter Vulnerability Assessment (PVA) | Annually | | Internal Vulnerability Scan (IVS) | Quarterly | | Web Application Assessments | Quarterly | | Network Security Assessment (NSA) | Quarterly | | Wireless Security Assessment (WSA) | Annually | | Application Security Assessment | Quarterly | | Security Test and Evaluation | Pre-Production | | Unauthorized Components/Devices Scan | Weekly |
Procedures
Procedures and mapped controls
Discovery (indetification)
The following tools may be used to assess systems or applications for vulnerabilities:
- Cloud Service Providers agents (installed in certified and hardened compute resources, containers, and cloud functions)
- OWASP ZAP
- Burp Suite
- Tenable
- Qualys
- Netsparker
- NMAP
Activities:
- Scan network-accessible systems by pinging them or sending them TCP/UDP packets
- Identify open ports and services running on scanned systems
- If possible, remotely log in to systems to gather detailed system information
- Correlate system information with known vulnerabilities and map those to assets using databases such as:
- VulnDB
- NIST NVD (National Vulnerability Database)
- MITRE CVE
Penetration Testing
Performed regularly as part of this policy, it helps in the discovery phase. your organization uses a bug bounty program run by HackerOne. Also, certified 3rd Party penetration testing is performed annually.
Evaluation
After vulnerabilities are identified, they need to be evaluated so the risks posed by them are dealt with appropriately and under the organization's risk management strategy.
Criteria to consider when evaluating vulnerabilities:
- How difficult is it to exploit this vulnerability?
- Could someone directly exploit this vulnerability from the Internet?
- Is there known, published exploit code for this vulnerability?
- What would be the impact on the business if this vulnerability were exploited?
- How old is the vulnerability/how long has it been on the network?
Prioritization
- Application and system owners should prioritize system or application vulnerabilities based on the findings and public vulnerability databases;
- Application and system owners must address network security policy configurations, content security policy configurations, application header configurations, or certificate configurations (e.g., self-signed, weak encryption) findings;
- The result of this step is to attach a Priority level to each identified vulnerability.
Reporting
your organization uses a ticketing solution to report vulnerabilities and track their remediation. The ticket reporter must fill out special fields which are preconfigured depending on project type, such as:
- Title: example:
[Critical] Production app uses buggy connector to the database - Issue type: Vulnerability or Finding
- Priority Level - see above convention
- Severity Level - see above convention
- Environment: development, testing, production
- Location: Application Name, Repository Name, Sofware Component, etc.
- Version - as number in Semantic Versioning (SemVer) format
- Description: describe the vulnerability
Remediation
System and application owners must do one or more of the following:
- Deploy mitigating control with CISO/COO approval
- Deploy patches/fixes that mitigate the risk for that vulnerability
- Upgrade any outdated packages
- Deploy configuration changes (if needed)
- Address vulnerabilities in time based on the SLA
- Production environments should not operate with unresolved Critical or High vulnerabilities
Validation
- Determine if the vulnerability is a false positive (mitigation control has been implemented)
- The application or system owner is responsible to let the CISO know via email in case of false positive
- System and applications owners must confirm the vulnerability no longer appears within the discovery tool
- If remediation has taken place, and the change is not reflected in a validation scan or deemed not applicable to the system, the application or system owner is responsible to let the CISO know via email
- After implementation, the ticket should be reassigned to the reporter
- In case of identification, if a mitigation control is efficient, but cannot be implemented at this moment (e.g. production environment cannot take a change at the moment), an upgrade window must be scheduled for the fix/remediation to be deployed
- After implementation and validation, the ticket must be closed by the reporter
Query logic
These are the stored checks tied to this policy.
No stored query bodies are attached to this entry.
