doomholderz Security Blog

A Methodology for Prioritising Security Projects

Rank the following security projects in terms of importance:

Instinctively as security professionals we'll try to consider the above in terms of the risk they reduce, but without context both to your organisation and the security industry at large, this is not straightforward.

The tendency is then to fall back to allowing FUD and our teams' biases to cloud our judgements - 'Wiz shows our container vulnerabilities as the cruelest shade of red: this must be our priority!'

Our objective is simple: We want a clear understanding of how a given security project tangibly resolves an actively exploitable issue against our organisation - we can refer to these as 'true-positive projects'.

Below is a list of 10 questions to vault this gulf of FUD and qualify the value of a given project for an organisation.

Pre-Project Questionnaire

  1. What is the underlying risk(s) this project is trying to mitigate?
  2. Does this piece of work resolve (fully or partially) an issue discovered previously within your live services (e.g. disclosed in a bug bounty program, or identified during an external pentest)?
  3. What are the likely outcomes of not doing this work?
  4. What is the worst-case outcome of not doing this work?
  5. How exploitable is the underlying issue(s) this project aims to mitigate?
  6. Does this piece of work resolve a risk identified in an industry-standard risk framework (e.g. ISO27001, OWASP)?
  7. Does this piece of work resolve (fully or partially) an issue recently exploited in the wild (e.g. within the CNCF Supply Chain Compromises Catalog)?
  8. What is the minimum viable work to resolve the identified issue(s)?
  9. What are the costs (technically and non-technically) for implementing this work, and maintaining this long-term?
  10. Where will this work induce friction (both technically and non-technically)?
Here's a runthrough of prospective answers for 'Enforcing 4-eye reviews across our Github repos'.
  1. Lack of change control to prevent deploying vulnerable or malicious code to our production services
  2. No - this risk has not previously been identified as being exploited.
  3. Non-reviewed code will be deployed, increasing the chances of faulty production services
  4. An attacker will compromise a valid Github account to deploy malicious code to our production services, affecting the confidentiality, integrity, and availability of services and their respective data
  5. Relies on either a. a motivated internal attacker, or b. compromising a valid Github account internal to our organisation. As we use SSO this will mostly lie on compromising a users' personal access token, which we lack auditing on currently.
  6. Yes, this is #1 in OWASP Top 10 CI/CD Security Risks
  7. Yes, this is a common attack vector (e.g. PHP incident in 2021, Homebrew incident in 2021)
  8. Work to change Backstage template for Github repos to enforce 4-eye review config. Then use Github API to find all non-conforming repos. We then need to ensure all repos are declared with Terraform, make the config changes, and merge PRs to align these repos with our standard.
  9. Cost of enforcing this for newly created repositories is just for making technical change to our Backstage template repository. Cost of enforcing this for existing repositories is in making changes in Terraform, confirming with affected teams, and merging related PRs. No additional costs long-term.
  10. Friction for developers that are used to pushing changes without approval, unfortunately there is little to be done here as this is a systemic change for which engineering culture will need to adapt.

In answering these questions during project planning you'll quickly identify true-positive projects that are almost guaranteed to solve a highly exploitable vulnerability within your organisation, and flush out projects that masquerade as 'high-value'.