CSCE 548 Architectural Risk Analysis - PowerPoint PPT Presentation

Loading...

PPT – CSCE 548 Architectural Risk Analysis PowerPoint presentation | free to view - id: 17515b-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CSCE 548 Architectural Risk Analysis

Description:

... the software is working according to the client's specification ... More cost effective to do requirement review than code testing alone. CSCE 548 - Farkas ... – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Slides: 23
Provided by: far1
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: CSCE 548 Architectural Risk Analysis


1
CSCE 548 Architectural Risk Analysis
2
Reading
  • This lecture
  • McGraw Chapter 5
  • Next lecture
  • Secure Software Construction
  • Jan Jürjens, Towards Development of Secure
    Systems using UMLsec, http//citeseer.ist.psu.edu/
    536233.html
  • Lodderstedt et. al, SecureUML A UML-Based
    Modeling Language for Model-Driven Security,
    http//citeseer.ist.psu.edu/lodderstedt02secureuml
    .html

3
Note
  • Deadline change in project specification
  • Task 5 detailed research write up and updated
    project proposal is DUE on March 18, 2008
    (changed from March 11, 2008)
  • First deadline brief project proposal is due on
    February 14 NEXT CLASS

4
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
2. Risk Analysis
5. Abuse cases
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
5
Requirement Analysis
  • Identify and document the customers requirements
    for a proposed system
  • Client brief idea on what the system should do
  • Requirement Analyst
  • Detailed system requirements
  • Implied requirements
  • Regulatory requiremetns
  • Create Software Requirements Specification (SRS)
  • What the product should do

6
Software Requirement Specification
  • Functional requirements
  • Features a software has
  • Implied requirements
  • Non-Functional requirements
  • Performance, reliability, security, etc.
  • Effects quality of product
  • Regulatory requirements
  • Law, standards, organizational regulation,
    contract, etc.
  • External interface requirements
  • Interaction with other software and hardware
  • Acceptance criteria
  • Confirm that the software is working according to
    the clients specification

7
Review SRS
  • Cost effective getting the requirements right
  • Manual review team of experts (at least 3) for
    1.5- 2 hours/session
  • Detection rate of good review 60-90
  • More cost effective to do requirement review than
    code testing alone

8
Design Flaws
  • 50 of security problems
  • Need explicitly identifying risk
  • Quantifying impact tie technology issues and
    concerns to business
  • Continuous risk management

9
Security Risk Analysis
  • Risk analysis identifying and ranking risks
  • Risk management performing risk analysis
    exercises, tracking risk, mitigating risks
  • Need understanding of business impact

10
Security Risk Analysis
  • Learn about the target of analysis
  • Discuss security issues
  • Determine probability of compromise
  • Perform impact analysis
  • Rank risks
  • Develop mitigation strategy
  • Report findings

11
Traditional Risk Analysis
  • Financial loss-based
  • Balance cost vs. loss
  • Mathematically derived risk rating
  • Threat, probability, and impact
  • Qualitative assessment
  • Knowledge-driven or anecdotal factors

12
Terminology
  • Asset object of protection
  • Risk probability that the asset will suffer an
    attack
  • Threat the actor (agent) who is the source of
    danger
  • Vulnerability defect or weakness in the system
  • Countermeasures or safeguards management,
    operational, and technical control to protect
    confidentiality, integrity, and availability
  • Impact impact on the organization
  • Probability likelihood that the event will occur

13
Knowledge Requirements
  • Three basic steps
  • Attack resistance analysis
  • Attack patterns and exploit graphs
  • Ambiguity analysis
  • Knowledge of design principles
  • Weakness analysis
  • Knowledge of security issues
  • Forest-level view What does the software do?
  • Critical components and interaction between them
  • Identify risk related to flaws

14
Risk Calculation
  • ALE SLE x ARO
  • ALE annualized loss expectancy
  • SLE single loss expectancy
  • ARO annualized rate of occurrence
  • Qualitative risk assessment (e.g., loss of
    reputation, loss of trust, etc.)
  • ROI return-on-investment
  • Note security is more like insurance it will
    never hit a big payoff

15
Limitations of Traditional Approaches
  • Hard to find correct data for statistical
    distribution
  • Do not necessarily provide an easy guide
  • Modern applications are complex contextual
    variability of risk

16
Modern Risk Analysis
  • Address risk as early as possible in the
    requirements level
  • Impact
  • Legal and/or regulatory risk
  • Financial or commercial considerations
  • Contractual considerations
  • Requirements must-haves, important-to-have,
    and nice-but-unnecessary-to-have

17
Basic Risk Analysis
  • Tailored for specific vulnerabilities
  • High-level overview
  • Meaningful results
  • Cross-tier analysis different trust zones
  • Use of deployment pattern
  • Decomposing software on a component-by-component
    basis

18
Risk Analysis Practice
  • Ad-hoc manner
  • Does not scale and not repeatable or consistent
  • Depends on knowledge and expertise of analyst
  • Results are difficult to compare

19
Attack Resistance Analysis
  • Information about known attacks, attack patterns,
    and vulnerabilities known problems
  • Identify general flaws using secure design
    literature and checklists
  • Map attack patterns based on abuse cases and
    attack patterns
  • Identify risk in the architecture using
    checklist
  • Understand and demonstrate the viability of known
    attacks

20
Ambiguity Analysis
  • Discover new risks
  • Parallel activities of team members ? unify
    understanding
  • Private list of possible flaws
  • Describe together how the system worked
  • Need a team of experienced analysts

21
Weakness Analysis
  • Understanding the impact of external software
    dependencies
  • Middleware
  • Outside libraries
  • Distributed code
  • Services
  • Physical environment
  • Etc.

22
Next Class
  • Secure Software Development
About PowerShow.com