John D. McGregor C 12 – Security/ATAM

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

ATAM Architecture Tradeoff Analysis Method
Designing an Architecture 1.Design Strategy Decomposition Designing to Architecturally Significant Requirements Generate and Test This generate-and test.
Design Concepts and Principles
ITIL: Service Transition
Evaluating a Software Architecture By Desalegn Bekele.
Software Architecture – Centric Methods and Agile Development by Craig Castaneda.
CPSC 872 John D. McGregor Session 22 Architecture Design, cont’d.
The Architecture Design Process
Active Review for Intermediate Designs [Clements, 2000]
1 Introduction to System Engineering G. Nacouzi ME 155B.
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software architecture evaluation
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman
Introduction to Computer Technology
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
RUP Requirements RUP Artifacts and Deliverables
Introduction to Software Quality Assurance (SQA)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
RUP Fundamentals - Instructor Notes
Evaluating Architectures: ATAM
CPSC 871 John D. McGregor Module 4 Session 3 Architecture Evaluation.
ATAM –Cont’d SEG 3202 N. Elkadri.
Architecture Evaluation Evaluation Factors Evaluation by the designer Every time the designer makes a key design decision or completes a design milestone,
Testing Workflow In the Unified Process and Agile/Scrum processes.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
1 Computer Systems & Architecture Lesson 5 9. The ATAM.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
Requirement Handling
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Project quality management. Introduction Project quality management includes the process required to ensure that the project satisfies the needs for which.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Overall Evaluation of Software Architecture By Ashwin Somaiah.
CSE 303 – Software Design and Architecture
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
John D. McGregor Architecture Evaluation
The ATAM method. The ATAM method (1/2) Architecture Tradeoff Analysis Method Requirements for complex software systems Modifiability Performance Security.
Documenting Software Architectures. Outline  Introduction  Uses of Architectural Documentation  Views  Choosing the Relevant Views  Documenting a.
Analyzing an Architecture. Why analyze an architecture? Decide whether it solves the problem Compare to other architectures Assess what needs to change,
CPSC 875 John D. McGregor C15 – Variation in architecture.
CPSC 872 John D. McGregor Session 31 This is it..
Failure Modes, Effects and Criticality Analysis
CpSc 875 John D. McGregor C 12 – Security/ATAM. Attack surface of a product face_Analysis_Cheat_Sheet
 System Requirement Specification and System Planning.
Quality Attribute Workshop. Goal: To identify requirements Held early in development Includes stakeholders Outputs: Business Goals Quality Attribute Scenarios.
OSLC PLM Workgroup1 Towards detailed use cases and alignment to OSLC V0.1 Gray Bachelor 18 th July 2011.
ITIL: Service Transition
Chapter 7: Modifiability
Software Architecture ATAM Process Presentation
Security SIG in MTS 05th November 2013 DEG/MTS RISK-BASED SECURITY TESTING Fraunhofer FOKUS.
Evaluating Existing Systems
System Design and Modeling
Evaluating Existing Systems
Analyzing an Architecture
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Object oriented analysis and design
Software metrics.
Analyzing an Architecture
Portfolio, Programme and Project
Lecture # 7 System Requirements
The ATAM – A Method for Architecture Evaluation
Presentation transcript:

John D. McGregor C 12 – Security/ATAM CpSc 875 John D. McGregor C 12 – Security/ATAM

Microkernel pattern http://viralpatel

Attack surface of a product https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet http://reports-archive.adm.cs.cmu.edu/anon/isr2011/CMU-ISR-11-121.pdf

Attack Surface Metric Damage-Effort Ratio (DER) An attacker will choose the target that can cause the most damage for the least effort The access rights determine how hard it is to access the elements that will be compromised M1 M2 A D B E C F

ChannelConnectors Connector Type ChannelT = { Property channelAccessRights : int; Property channelProtocol : int; } Larger protocol values indicate larger chunks of data that can be passed making it easier to move programs protocols ------------------ access rights 𝑚∈𝑀 𝐷𝐸𝑅 𝑚 𝑚

Port Type EntryExitPointT = { Property entryExitPointPrivileges : int; Property entryExitPointAccessRights : int; } Level of privileges determines the damage that can be done Privileges ------------------- Access rights 𝑐∈𝐶 𝐷𝐸𝑅 𝑐 𝑐

Component Type DataItemT = { Property dataItemType : int; Property dataItemAccessRights : int; } The less restrictive the data types are the easier it is for attackers to enter. Data types ------------------ Access rights 𝑖∈𝐼 𝐷𝐸𝑅 𝑖 𝑖

Complete Attack Surface 𝑚∈𝑀 𝐷𝐸𝑅 𝑚 𝑚 𝑐∈𝐶 𝐷𝐸𝑅 𝑐 𝑐 𝑖∈𝐼 𝐷𝐸𝑅 𝑖 𝑖 A transform is evaluated to determine its effect on the attack surface Would using a feature group reduce the port vulnerability? Would using a record to group data fields together make an attack easier/

Sanitize Data at Entry/Exit Points this transformation requires the architect to insert a component between an entry/exit point and the environment Ports that previously served as entry/exit points should be moved to the sanitizer have their privileges reduced by an order of magnitude to reflect the sanitizing function

Favor Restricted Channels Limiting the type of data transmitted over a channel can reduce the attack surface of the system by lessening the advantage gained by exploiting that channel The protocol value should be lowered to reflect the more restrictive nature of the new protocol

Move Data Items to the Interior Moving data items to the interior of a system shifts untrusted data items away from the system’s perimeter Data items that cannot be moved to the interior of the system should be evaluated to determine if they are necessary and be eliminated if they are not

Design to a Single Point of Access Introduction of a gatekeeper component to serve as a unified point of access Combining entry/exit points that share the same privileges and access rights reduces the number of entry/exit points by reducing the number of externally-facing interfaces in the system.

Attack surface properties in AADL property set securityProperties is Channel_Protocol : aadlinteger applies to (connection); Channel_AccessRights: aadlinteger applies to (connection); entryExitPointPrivileges: aadlinteger applies to (port); entryExitPointAccessRights:aadlinteger applies to (port); dataItemType:aadlinteger applies to (data); dataItemAccessRights:aadlinteger applies to (data); end securityProperties;

Architecture adds value Value is a synonym for desirableness If the value of something increases it is because it has become more desirable for some reason A “value chain” represents a sequence of stages, each of which makes the “thing”, for which this is the value chain, more desirable. The value chain for a software product is the series of activities that craft a solution.

Porter’s Value Chain

Adding value How does architecture add value? (How does it make the product more desirable?) Increased probability that customers like the product Increased probability of highly reliable operation Increased probability that the product will have the qualities desired Increased predictability of implementation

Adding value - 2 Even architecture evaluation adds value It removes defects making the architecture more desirable as a basis for building a product Question: How do we measure these increases in value?

Where are we?

Architecture TradeOff Analysis Method (ATAM) The purpose of the ATAM is to assess the consequences of architectural decisions in light of quality attribute requirements. http://www.sei.cmu.edu/reports/00tr004.pdf

Conceptual Flow of ATAM Business Drivers Software Architecture Quality Attributes Architectural Approaches Architectural Decisions Scenarios Analysis impacts Risks Sensitivity Points Tradeoffs Non-Risks distilled into Risk Themes

Phase 0 Phase 1 Phase 2 Phase 3 Partnership and preparation Evaluation Evaluation continued Phase 3 Follow-up

Phase 0 Logistics are agreed to Agenda is agreed to Meeting dates Who must attend Team membership Agenda is agreed to Collect initial information

Overview of Phase 1 Step 1 Present the ATAM Step 2 Present business drivers Step 3 Present architecture Step 4 Identify architectural approaches Step 5 Generate quality attribute utility tree Step 6 Analyse architectural approaches

Step 1 – Present the ATAM Process The ATAM evaluators set expectations Give an outline of the steps Normal meeting management activities

Step 2 - Present Business Drivers Describe The system’s most important functions Any relevant technical, managerial, economic, or political constraints The business goals and context as they relate to the project The major stakeholders The architectural drivers (the major quality attribute goals)

Step 3 - Present Architecture Driving architectural requirements, measurable quantities associated with these, standards/models/approaches for meeting these Important architectural information Context diagram Module or layer view Component and connector view Deployment view

Present Architecture - 2 Architectural approaches, patterns, tactics employed, what quality attributes they address and how they address those attributes Use of COTS and their integration Most important use case scenarios Most important change scenarios Issues/risk w.r.t. meeting the diving requirements

Step 4: identify architectural approaches Catalog the evident patterns and approaches Based on step 3 Serves as the basis for later analysis

Quality Attribute Scenario Stimulus Stimulus source Environment Artifact Response Response measure

Quality Attribute Scenario Stimulus – the hand control is moved to make a 2 inch long, 1 inch deep incision Stimulus source – doctor Environment – patient and robot have been aligned Artifact – image in the viewfinder Response – the view is updates with no flicker Response measure – the doctor experiences no difficulty seeing the incision as it is made

Step 5: Generate quality attribute utility tree Present the quality attribute goals in detail Quality attribute goals are Identified, prioritized, refined Expressed as scenarios Utility is an expression of the overall goodness of the system Quality attributes form the second level being components of utility

Step 5: Generate quality attribute utility tree con’t Scenarios are prioritized Depending on how important they are and Depending on how difficult it will be for the architecture to satisfy a scenario

Step 5 – Lets draw the tree (H,M) Repair in 3 days Maintenance (M,L) Modifiability Replace function In 2 days Extensibility Utility

Step 6: Analyze architectural approaches Examine the highest ranked scenarios The goal is for the evaluation team to be convinced that the approach is appropriate for meeting the attribute-specific requirements Scenario walkthroughs Identify and record a set of sensitivity points and tradeoff points, risks and non-risks Sensitivity and tradeoff points are candidate risks

Phase 2 Step 7 Step 8 Step 9 Brainstorm and prioritize scenarios Analyze architectural approaches Step 9 Present results

Step 7: Brainstorm and prioritise scenarios Utility tree shows architects view on the quality attributes Here the focus is on the other stakeholders view on the quality attributes and scenarios based on these Which are the mot meaningful and important scenarios w.r.t. users etc.

Step 8: Analyse architectural approaches Highest ranked scenarios from step 7 are presented to the architect Explain how relevant architectural decisions contribute to realising each one

Step 9: Present results Outputs: The architectural approaches documented The set of scenarios and their prioritization from the brainstorming The utility tree The risks discovered The non-risks documented The sensitivity points and tradeoff points found

Conceptual Flow of ATAM Business Drivers Software Architecture Quality Attributes Architectural Approaches Architectural Decisions Scenarios Analysis impacts Risks Sensitivity Points Tradeoffs Non-Risks distilled into Risk Themes

ATAM with AADL Tradeoffs made more crisp because we have better data Sensitivity points can be explored by “jiggling” quality attribute values and observing the degree of change Risks can be more correctly quantified using the results of safety and risk analyses