Threat Analysis

Overview
For many organizations, security is more of an afterthought and bolted on in the later stages of the software development lifecycle (SDLC).  In this context,  a threat analysis begins with identifying the application’s features and user/attacker entry points, noting feature characteristics such as its relevancy to security and access level required to perform related tasks. These high-level threats are then broken down into sub-threats that can be more easily addressed and prioritized using various ranking techniques.

Proactive organizations integrate security at all stages of the SDLC and in doing so, threat analysis is used to its full potential. The process by which threats are characterized and ranked can be similar to the one described above, however the threat model will evolve as the product progresses through its lifecycle and be leveraged for decision making.

Our Approach
Effective threat analysis requires security expertise as well as intimate knowledge of the application and implementation. We work closely with your team to ensure that we identify the full range of threats your application faces.

Our Threat Modeling process includes the following steps:

  1. Understand architecture and security requirements.  The application is analyzed to determine what needs to be secured.

  2. Identify assets. The system is divided into a series of assets. These represent items of value that you want to protect or than an attacker would like to get access to.

  3. Build an activity matrix. This is a set of explicit mappings that specify each role in the system including which assets the role has access to.

  4. Identify threats that put assets at risk. Threats are defined against each specific asset. Specific attention is given to confidentiality, integrity and availability of each asset.

  5. Identify attacks that could be used to realize threats. Irrelevant threats are removed and the remaining are used to define attacks against the system.

  6. Identify testable conditions for each attack.  Attack condition definitions are guided by the expertise of our security consultants in conjunction with client documentation and risk management teams.

Once the threat model is complete, it can be used to:

  • Review the design or code and test the application for the presence of threats and vulnerabilities

  • Choose appropriate mitigations and responses to realized threats

Presenting our Findings
After all Threat Modeling activities are completed, we’ll provide you with a Final Report that includes a summary of our top-level findings as well as the following:

  • System Decomposition breaks the application into high level components, assets, and roles. This allows our engineers to achieve a coarse understanding of the interconnections of the system.

  • Top Threats highlight the items with the largest potential for security impact.

  • The Activity Matrix & Rules provides a full matrix for the interaction between assets and roles.

  • Threat Trees list the attacks (grouped by assets) and the necessary conditions that need to be in place to make the attacks feasible.