Architecture & Design Review

Security Innovation offers a range of services that help organizations resolve vulnerabilities and weaknesses in a portfolio of enterprise applications, a stand-alone application, an embedded software system, or within the software development process itself.

Identify problems before they propagate into hard-to-fix vulnerabilities

Most vulnerabilities are introduced during design - before a line of code is even written.  Design Review’s identify weaknesses in the design, requirements and goals of your software system by checking against common vulnerabilities and use of design best practices.  Identifying and remediating problems during this phase will have a positive cascading impact on during coding and release. 

At the end of the review, our experts will provide and present prescriptive mitigation recommendations, ensure that the impact and risk of each recommendation is clearly understood, and work closely with your team to prioritize and implement.   

Our Methodology

(download detailed methodology document)

  1. Create a Threat Model
    Our experts will analyze your application through the eyes of an attacker – identifying the entry points to the application and the associated threats with each one. 
  2. Review Architecture and Design for Flaws
    The objective of this phase is to identify flaws and weaknesses in design components (i.e. communication protocols) and devise recommendations on how to architect, build, design or deploy the application securely.  Each recommendation may address multiple threats identified in the Threat Model.
  3. Identify Damage Potential and Prioritize Threats
    During this phase, we gather additional information to help you understand how to handle each threat found in the threat model. Since all threats do not need to be mitigated, we take into consideration (where possible) your environment and objectives.

Steps:

  1. Analyze threats identified in the Threat Model, and rate based DREAD
    • Damage Potential - How severe is the damage if the vulnerability is exploited?
    • Reliability - How easy is it to reproduce the attack?
    • Exploitability - How easy is to launch an attack?
    • Affected Users - As a rough percentage, how many users are affected?
    • Discoverability - How easy is it to find the vulnerability?
  2. Identify measures to help the customer handle the threat
    1. Avoid - remove or replace the component all together
    2. Reduce or Remediate - fix the issue
    3. Transfer - Pass risk elsewhere and recommend a control or plan for mitigation
    4. Accept - Don’t make any changes due to low risk
  3. Document our rationale behind the risk classification and mitigation recommendation and mapping the threat back to the recommendation where appropriate.