Posted by Kinnaird McQuade on July 18, 2016
When preparing for a threat modeling assessment, there are a lot of moving parts to consider within a firm. These assessments often cause concerns throughout the organizational hierarchy. Don’t worry, that’s normal. To steady those nerves, here are five activities to undertake before your next threat model that will set your team and organization up for success:
The idiom “a picture is worth a thousand words” suits a variety of security-relevant visuals. Architecture diagrams, network diagrams, logical models, deployment models, and data flow diagrams are a few examples that can provide a forest-level view of a software system’s security posture. Also provide more detailed artifacts if possible. Requirements documents, design documents, and any other documentation related to the application is always helpful.
If you didn’t produce these artifacts during the software’s development, provide what you can to assessors. It is always beneficial to provide high-level diagrams (architecture diagrams or data flow diagrams) and a detailed understanding (design or requirements documents) to perform a thorough assessment.
A component diagram is one example of a security-relevant visual.
Your threat modeling assessor looks for facts, not faults. Risks or weaknesses identified during an assessment paint a picture of the application’s security posture. These risks or weaknesses are not necessarily evidence of a team’s incapability. In fact, it’s known that even the best developers and software architects have some mistakes slip through the cracks. The primary goal of the assessment is to uncover these overlooked issues and ensure they don’t happen again.
The process of identifying and resolving weaknesses in a system’s architecture is kind of like coaching a pro athlete. An athlete knows how to perform well in their sport. However, they may not be an expert in nutrition or high intensity interval training. When it comes to your own software, your firm is more familiar with it than anyone else on the planet. But, you may not have a trained security team with threat modeling experts. Bringing in specialists to conduct a threat model proves that you want to harden your system. An assessment will help to kick off that process.
Internal developers and system architects behind your software become the application subject matter experts (SMEs) during the threat modeling process. Additionally, it’s critical to loop in the network administrators who are most familiar with the network design and will be available to act as network SMEs.
Ensure that each SME is available during the assessment to coordinate input from technical product leads, quality assurance leads, application component developers, lead architects, and other critical internal team members while conducting the threat model. These team members can be very valuable to the process in order to accurately describe major components of the system.
After identifying potential weaknesses, a thorough review provides context-specific controls to ensure that defense in-depth is in place. Multiple security controls ensure that if one defense mechanism fails (due to weak or obfuscated security controls), another is in place to prevent exploits.
The top priority is to protect your assets. This can include user credentials, certificates, auditing logs, sensitive company information, and much more. To protect those assets, the threat modeling assessment identifies attack vectors—the mechanisms by which threat agents (hackers) can carry out attacks. After attack vectors are identified, controls can be put in place. These controls should be proportional to the level of risk and should be feasible for your personnel.
The results of a threat modeling assessment are business-oriented to better convey the impact of certain risks on the organization. These results can also provide customized guidance for mitigating the risks. This helps you focus and prioritize subsequent secure code reviews or penetration tests. Threat modeling results allow penetration testing to be more precise. Additionally, it helps limit the scope of each test, in turn saving time and money.
Visualizing the attack process through a detailed threat model report helps penetration testers proceed with a calculated approach, rather than blindly running nMap scans or deploying Metasploit modules without considering the consequences. The penetration tester can then simulate a more realistic attack scenario where they have one chance to attack the system. Threat modeling is the closest you can get to a quantitative understanding of your return on security investment (ROSI).
Threat modeling certainly isn’t a replacement for a penetration test or secure code review; however, it is an important facet of approaching software and system security holistically. It saves time, money, and provides context-specific recommendations that ensure the protection of your application portfolio.