How KPMG can help: Cyber security services
Finding and fixing security flaws in production is much more costly to an organization than finding them earlier in the software development life cycle (SDLC). In order for IT organizations to stay competitive, security must be a mindset that’s embraced from the beginning – starting with planning & design considerations.
While introducing security in the software planning and design stage, most security automation is not available yet, so consider other creative methods to reduce risk. Threat modeling is an effective option that includes creativity and involves team building.
Why Use Threat Modeling?
When you threat model early, you not only satisfy security’s goal to keep information and devices secure by design, but you also satisfy the business need to keep costs and risk low by catching issues before they manifest themselves into more expensive problems in production.
How to Get Started
Threat modeling is a process that involves mapping out an application’s functionality, looking at the application through the eyes of an attacker, and finding ways to mitigate possible threats. Threat modeling in the early stages of design is a great way to build bonds between developers and information security from the get-go, as it involves a joint effort between teams with different perspectives. At its core, threat modeling seeks to answer the questions:
- How could a malicious actor intentionally abuse functionality of the application?
- What can be done to prevent this?
Step 1: Decompose the application
Seek to gain an understanding of the application’s purpose, its audience, and its dependencies. Think about what type of information is processed, where it originates, and where it is stored.
Step 2: Mapping the flow of data
With your new understanding, create a Data Flow Diagram (DFD) to visualize how data moves across your application and how different users and systems interact with it. Look at how data is protected in transit and at rest. Use elements like “actors”, “processes”, and “data stores” to depict your environment. Whiteboard with your team and welcome opinions, ideas, and related discussion to the table.
Step 3: Taking the attackers perspective
Use your DFD to discover threats by looking for ways into and out of the system, opportunities for configurations to be set improperly, with special focus on functionality involving privileged access. Understand what the valuable assets are and how they can be modified, accessed, or abused. A framework like “STRIDE” can be used for categorizing and understanding threat tactics, techniques & procedures. STRIDE is an acronym that represents common threat categories:
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
Step 4: Determine threat risk levels & mitigations
With your new level of understanding you can rank threats by their overall impact by using risk assessment models, like “DREAD”, that consider various threat characteristics:
- Damage
- Reproducibility
- Exploitability
- Affected Users
- Discoverability
After you’ve ranked your threats, discuss ways to reduce the likelihood and impact of the threat. Recognize controls that are already in place, and document recommendations for improved risk mitigation.
Three final “pro tips”...
- Don’t treat threat modeling as a “one and done” exercise. Applications are meant to change over time, and any major update should trigger a refresh of the existing threat model.
- Not all risk is found “in production”. Consider including the continuous integration / continuous delivery (“CI/CD”) pipeline in a threat modeling exercise for a more comprehensive view of the risk to an application. Build pipeline security has taken on increased importance in the wake of the SolarWinds event of December 2020.
- Looking for “friendlies” on the application teams to engage for threat modeling exercises? Security champions programs are great ways to identify or create such allies.
