This preview shows page 1. Sign up to view the full content.
Unformatted text preview: ay/yr)
✦✦Developers (1 day/yr)
✦✦Architects (1 day/yr)
✦✦Security Auditors (2 day/yr)
✦✦Managers (1 day/yr) Related Levels
✦✦Strategy & Metrics - 1
✦✦Security Requirements - 2 SAMM / The Security Practices - v1.0 Activities 47 TA 2 Threat Assessment Increase accuracy of threat assessment and improve granularity of per-project understanding Activities
Results A. Build and maintain abuse-case models per project ✦✦Granular understanding of likely
threats to individual projects
✦✦Framework for better tradeoff
decisions within project teams
✦✦Ability to prioritize development
efforts within a project team
based on risk weighting Further considering the threats to the organization, conduct a more formal analysis to determine potential misuse or abuse of functionality. Typically, this process begins with identification of normal usage scenarios, e.g. use-case diagrams if available. Add’l Success Metrics
✦✦>75% of project teams with
identified and rated threats
✦✦>75% of project stakeholders briefed
on threat and abuse models of relevant
projects within past 6 months Add’l Costs
✦✦Project overhead from maintenance of
threat models and attacker profiles Add’l Personnel
✦✦Security Auditor (1 day/yr)
✦✦Business Owner (1 day/yr)
✦✦Managers (1 day/yr) Related Levels SAMM / The Security Practices - v1.0 ✦✦Strategy & Metrics - 2
✦✦Secure Architecture - 2 48 If a formal abuse-case technique isn’t used, generate a set of abuse-cases for each scenario
by starting with a statement of normal usage and brainstorming ways in which the statement
might be negated, in whole or in part. The simplest way to get started is to insert the word
“no” or “not” into the usage statement in as many ways as possible, typically around nouns
and verbs. Each usage scenario should generate several possible abuse-case statements.
Further elaborate the abuse-case statements to include any application-specific concerns
based on the business function of the software. The ultimate goal is for the completed set
of abuse statements to form a model for usage patterns that should be disallowed by the
software. If desired, these abuse cases can be combined with existing threat models.
After initial creation, abuse-case models should be updated for active projects during the
design phase. For existing projects, new requirements should be analyzed for potential abuse,
and existing projects should opportunistically build abuse-cases for established functionality
where practical. B. Adopt a weighting system for measurement of threats
Based on the established attacker profiles, identify a rating system to allow relative comparison between the threats. Initially, this can be a simple high-medium-low rating based upon
business risk, but any scale can be used provided that there are no more than 5 categories.
After identification of a rating system, build evaluation criteria that allow each threat to be
assigned a rating. In order to do this properly, additional factors about each threat must
be considered beyond motivation. Import...
View Full Document
This homework help was uploaded on 03/31/2014 for the course GEN ED IS taught by Professor 3445 during the Spring '14 term at ITT Tech Flint.
- Spring '14