Vulnerability Management¶

2020.1

Policy Statements¶

Changineers policy requires that:

(a) All product systems must be scanned for vulnerability with each change, and at least quarterly if no change occurs.

(b) All vulnerability findings must be reported and tracked to resolution. Records of findings must be retained for at least seven years.

The scanning and identification of system vulnerabilities is performed by

Automated dependency analysis services (e.g. Snyk, Dependabot)
- The service(s) automatically raise GitHub for any identified vulnerabilities
- Where possible, the service(s) automatically send Pull Requests upgrading dependencies when vulnerabilities are resolved
- This assessment is performed continuously
Scans of Changineers’s AWS infrastructure are performed using ScoutSuite whenever an infrastructure-as-code change is made. These scans identify any potential security misconfigurations in the modified code and fails our Continuous Integration builds.
AWS Config is used to continuously monitor compliance of existing AWS infrastructure.
Penetration testing is performed regularly as part of the Changineers vulnerability management policy.
- Additional external penetration testing is performed at least annually by either a certified penetration tester on Changineers security team or an independent third party.
- White-box internal penetration testing is performed at least quarterly by the security team.
Findings from a vulnerability scan or penetration testing are analyzed by the Development and Security teams and reported following the process as defined in the next section.
All security testing reports and findings records are retained for 7 years.

We follow a simple vulnerability tracking process using GitHub. The records of findings are retained for seven years.

Wherever possible, the process listed below should be automated using our preferred tooling (Snyk or Dependabot).

Upon identification of a vulnerability (including vulnerability in software, system, or process), a GitHub Issue of labelled Security is created on the project of the affected system.
The following data should be captured as part of the GitHub issue when applicable:

Source of Finding

In Production

Version Number (text/tag)

The Summary of the Finding should be in this format: “{[sev]} {short description}” (e.g. “[High] Outdated package on ECS AMI image”).
The Description of the Finding should include further details, without any confidential information, and a link to the source.
The Priority of the Finding should match its severity level.

In an effort to quickly remediate security vulnerabilities the following timelines have been put in place to drive resolution.

Sev Rating	Priority Level	SLA	Definition	Examples
P0	Highest	3 days	Vulnerabilities that cause a privilege escalation on the platform from unprivileged to admin, allows remote code execution, financial theft, unauthorized access to/extraction of sensitive data, etc.	Vulnerabilities that result in Remote Code Execution such as Vertical Authentication bypass, SSRF, XXE, SQL Injection, User authentication bypass
P1	High	7 days	Vulnerabilities that affect the security of the platform including the processes it supports.	Lateral authentication bypass, Stored XSS, some CSRF depending on impact.
P2	Medium	30 days	Vulnerabilities that affect multiple users, and require little or no user interaction to trigger.	Reflective XSS, Direct object reference, URL Redirect, some CSRF depending on impact.
P3	Low	Best Effort	Issues that affect singular users and require interaction or significant prerequisites (MitM) to trigger.	Common flaws, Debug information, Mixed Content.

In the case a sev rating / priority level is updated after a vulnerability finding was originally created, the SLA is updated as follows:

severity upgrade: reset SLA from time of escalation
severity downgrade: SLA time remains the same from time of creation/identification of finding

The Finding should be assigned to the owner responsible for the system or software package.
All findings should be addressed according to the established SLA.
No software should be deployed to production with unresolved HIGH or MEDIUM findings, unless an Exception is in place (see below).
A finding may be resolved by:

The assignee should provide a valid resolution (see above) and add a comment to the finding.
The finding should be re-assigned to the Reporter or a member of the security team for validation.
Upon validation, the finding can be marked as Done (closed) by the Reporter.
Before the finding can be marked as closed by the reporter, the fix must be deployed to production.

An Exception may be requested when a viable or direct fix to a vulnerability is not available. For example, a version of the package that contains the fix is not supported on the particular operating system in use.
An alternative solution (a.k.a. compensating control) must be in place to address the original vulnerability such that the risk is mitigated. The compensating control may be technical or a process or a combination of both.
An Exception must be opened in the form of a GitHub issue (label = Exception) on the application’s project.
The Exception GitHub issue must reference the original Finding by adding an Issue Link to the Security GitHub issue.
Each Exception must be reviewed and approved by the Security team and the impacted asset owner.
All Exceptions are reviewed every six months to re-assess its validity.