I recently ran a risk assessment analysis exercise with one of Blue Bear Inc's clients. I want to share here the way I approached the problem and how I structured my report.
1. Brainstorming risks
Technical Risks
It is impossible to identify all risks that apply to a product. It would be like trying to check your health against every single disease in the medical encyclopedia, alphabetically. It is important to be pragmatic and think about what would truly be problematic to your product, business or company.
What are your most critical assets? Is there data, software, hardware, processes or people that are essential to the success or operations of the product? For each one of these assets, what is the worst that could happen from a technical perspective? What could compromise the confidentiality, integrity or availability of that asset?
Lists such as the OWASP Top 10 and OWASP API Top 10, or other lists of common vulnerabilities, can be a starting point as well. However, simply because they are common in the industry, doesn't mean they apply to all infrastructures and that there aren't more important (in terms of impact or likelihood) vulnerabilities in the product being audited.
User Behavior Risks
The human element continues to drive breaches. This year 82% of breaches involved the human element. Whether it is the Use of stolen credentials, Phishing, Misuse, or simply an Error, people continue to play a very large role in incidents and breaches alike.
I highly recommend reading through the Verizon 2022 Data Breach Investigations Report (DBIR). It highlight in concrete ways the importance of addressing non-technical security risks.
Access control is key here. When looking at the critical assets, is it possible to control, audit, permit, deny or revoke access to those assets? What security processes are in place to grant and check access?
Here are a few more brainstorming questions:
- Who has access to the most critical assets?
- How do they access it? What can they do with that access?
- What is the password / MFA policy?
- Do employees know not to reuse password? Is a password manager provided?
- Is there visibility and alerting when something odd happens?
Compliance Risks
Compliance risks are both easier to identify and harder to assess. It is important to get the data protection officer (DPO) involve in the risk analysis process for this part.
The main questions to answer are:
- What laws and regulations apply to my company?
- What laws and regulations apply to the data I am collecting?
- What laws and regulations apply in the jurisdiction where my end users are?
Based on the answers, compliance gaps can start to be identified. For example:
- Is the company / product missing required compliance pieces, such as a privacy policy?
- Are end users able to claim their rights under those laws and regulations?
- Is the product able to easily handle data requests from end users?
- Is the product getting the right level of consent from end users in regards to how their data is used?
- Are there roles or responsibilities requires by laws that the company does not have, such as a DPO?
- Is sensitive data segregated appropriately?
- If I were to be audited next week, would the company be able to provide all the data and policies required by the regulators?
2. Scoring the risks
For this assessment, I decided to use the Microsoft DREAD risk assessment model. It is not used by Microsoft anymore (They use SDL Bug Bar now) but this framework provides a subjective but useful way to quantify threats and risks. The DREAD methodology was also very useful in making the reasoning behind the prioritization clear. It's much easier to have discussions with stakeholders when that thinking is broken down and explicit.
There are 5 components that helps us reason about them:
Damage: How big would the damage be if the attack succeeded?
- Can an attacker completely take over and manipulate the system?
- Can an attacker gain admin access to the system?
- Can an attacker crash the system?
- Can the attacker obtain access to sensitive information such as secrets or personal data/PII?
- How many connected data sources and systems can be impacted?
- How many layers into infrastructure components can the threat agent traverse?
Reproducibility: How easy is it to reproduce an attack?
Exploitability: How much time, effort, and expertise is needed to exploit the threat? Can it be done remotely? Can it be automated?
Affected Users / Datasets: If a threat were exploited, what percentage of users or data sets would be affected?
Discoverability: How easy is it for an attacker to discover this threat?
The original version of this framework simply suggested calculating the overall score by adding each individual score and dividing by 5. That's been criticized as too simplistic, and the original authors have since provided a new calculation mechanism. I've decided to do it differently, keeping the components from the DREAD framework, but calculating distinct Impact and likelihood scores.
Impact
To calculate the Impact score, we will focus on Damage and Affected Users, summing those scores and diving it by 2 to find the average.
- High: Average Score 8 and above
- Medium: Average Score 4 to 7 and above
- Low: Average Score 3 and lower
Likelihood
To calculate the Impact score, we will focus on Reproducibility, Exploitability and Discoverability, summing those scores and dividing it by 3 to find the average.
- High: Average Score 8 and above
- Medium: Average Score 4 to 7 and above
- Low: Average Score 3 and lower
3. Putting the report together
Let's breakdown the different sections of the report. I'm providing this as a template anyone can reuse for this product / feature / business line / topic.
How does Security fit into the [Product] Plan
In this section, I reiterated why security needs to be taken into consideration for this product. It is important to emphasize what the negative consequences could be for this product / company if security is not handled right.
Example:
A successful [launch / improvement / commercialization ] of [product] is [important/necessary/needed/...] to [team/company]’s [future goal]. Over the next few months, we will need [product roadmap of product]. However, because of the nature of our business and the data it handles, it is essential that we build a pragmatic security practice into [product]'s development lifecycle. If we fail to do so, we might face at best the loss of our reputation and associated loss of customer and revenue, and at worst, we might be forced by legal authorities to cease all data processing activities [adjust to your product / company's circumstances with specific consequences].
How do we Fulfill our Security Responsibilities?
Summarize the findings of your analysis. The report this post is based on was 17 pages long, and most stakeholders were not interested in reading all the details, so having a one pager "executive summary" of why security matters to this product/feature/topic, what the 3 biggest risks are and what needs to be done about it is crucial to have an impact.
Example:
There are three main ways for [team / company] to approach security pragmatically for [product].
The first is to [ex: understand and address our legal requirements under GDPR]. [Expand on the risks: By having compliant processes to protect our users’ rights, we can avoid audits and fines from unsatisfied customers. The measured compliance risk is not the highest, but it increases rapidly the more customers we get].
The second is to [ex: address the biggest known security gaps in our technology architecture, focusing on known vulnerabilities].
The third is to [ex: deeply test our front end web apps to make sure that they do not provide any entry point into our internal systems].
Risk breakdown
For each risk identified in the analysis, I summarized it with this structure:
Title: Overall Security Score: Description Impact: Likelihood: Steps already taken to address this risk: Additional Mitigation steps to take:
Example:
Title: Known Vulnerabilities in Application Logic
Security Score: 6.8
Description: User inputs are a very common attack vector, if the inputs are not sanitized by the application and can be used to execute db queries, return unauthorized personal data, and/or compromise the workings of the application in other ways.
Impact: High
Damage: 9 - remote code execution, privilege escalation, DDoS, data exfiltration, ransomware, …
Affected Users / Datasets: 9 - production databases and serversLikelihood: Medium
Reproducibility: 4 - we have secure coding practices, so we have yet to find any indication of this being possible, but we have not looked for that information
Exploitability: 5 - depending on the vulnerability, the longer is stays in our system, the more easily it can be exploited
Discoverability: 5 - depending on the vulnerability, a dedicated hacker could spend enough time until they find an entry pointMitigation Steps already taken: Inputs are sanitized and typed. Tests suites ensure application code does what it is supposed to do and no more
Additional Mitigation steps to take: Roll out open source Static Application Security Testing tool to identify vulnerabilities in the logic of our applications
Annexes
I added two annexes to my report. One was a page long overview of the data processed by the product subject of the analysis. I went into details on what that data was, how it was processed, and how it related to GDPR and other applicable regulations.
The second annex I added was on the methodology. I described the DREAD methodology, very similarly to how it is described in section 2 of this post. The goal is to give everyone reading the report the tools to make their own assessment and understand the reasoning behind the scores given to risks. The DREAD methodology is subjective, so it is important for the readers of the report to understand it to not dismiss the analysis.
Closing Thoughts
Best of luck with your own risk assessments. If you've doing it differently or use other frameworks or templates, I would love to hear what you think of them.