You’re working on an API library. There are three formats in common use in these types of API. Do you support all three of them? Does this decision have security ramifications?
You need to store some configuration data. A is a common dependency, very readable, and used by most Python developers. B is less common, harder to read and write, and isn’t used as often. Which do you choose? Does this decision have security ramifications?
You’re implementing a serialization format. At first it only supports primitive types, but users quickly request that you extend the language to allow serialization of arbitrary objects. Do you say yes? Does this decision have security ramifications?
“There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know.” — Donald Rumsfeld
A good security policy Lays out standard terminology used when talking about security issues. Explains the expectations and commitments around vulnerability handling. Creates a transparent, repeatable assessment mechanism.
Advisory Issues that the security team wishes to communicate but that carry no specific required action. May sometimes contain recommended actions, but no specific response is required to an advisory, and no timeline is defined.
Low Issues that need to be resolved, but have either a low risk of exploit or low consequences for an exploit. Should not interrupt day-to-day operations, but should be scheduled for the next appropriate slack time.
Medium Issues that carry a noticeable risk, but are still theoretical, not ongoing, or have a low impact. Expect Medium vulnerabilities to cause limited interrupts, but otherwise have minimal impact on normal operations.
High Carry a substantial risk to your customers, finances, reputation or otherwise. Expect High-level vulnerabilities to interrupt several developers, perhaps from multiple teams.
Critical Critical vulnerabilities threaten the integrity of your company, contain substantial financial risk, or are otherwise “sky is falling”-level issues. These are literally existential threats to your company. Critical vulnerabilities are “all hands on deck” moments.
4. What resources are required for an attacker to exploit the vulnerability? (0) Full superuser-level access (sudo access) (2) Staff-level access (access to internal tools) (4) Special access required (needs a particular type of account) (7) Limited access required (anyone with an account) (9) No access or resources required
1. How technically skilled is the attacker? (3) Network and programming skills - The attack requires a carefully required connection string, so we assume an attacker would need some network and programming skills.
2. How motivated is this attacker? (9) High reward - in a worst-case, the attack could be used to remotely access arbitrary databases, which is quite valuable.
5. How easy would it be for an attacker to discover this vulnerability? (3) Difficult - the vulnerability existed in PostgreSQL for many years and went undiscovered, and was eventually only discovered by a core contributor.
6. How easy would it be to actually exploit the vulnerability, assuming knowledge that it exists? (5) Easy - once you know of the vulnerability, it's easy to craft a proof of concept.
2. How much data could be corrupted, and how damaged would that data be? (7) Extensive corruption to much customer data with difficult or incomplete recovery possible.
6. Would an exploit result in reputation damage that would harm our business or our brand? (7) - worse than "loss of public goodwill", not quite "long-term or permanent brand damage"
Likelyhood: 5.625 Likelyhood: 5.625 Likelyhood: 5.625 0 to <3 3 to <6 6+ Impact: 7.5 0 to < 3 Advisory Low Medium Impact: 7.5 3 to <6 Low Medium High Impact: 7.5 6+ Medium High Critical
5. How easy would it be for an attacker to discover this vulnerability? (3) Difficult - the vulnerability existed in PostgreSQL for many years and went undiscovered, and was eventually only discovered by a core contributor.
jacobian
masa5555
comucal
bigwheel
k1low
h1kita
dahatake
you
keiko713
hhiroshell
ouchi2501
wakamatsu_takumu
k1style
marcduiker
samlambert
soudai
ammeep
jonrohan
keavy
reverentgeek
eileencodes
chriscoyier
mongodb
swwweet