1 Security Architecture Analysis Lecture 3 Architecture Analysis –Analysis of architectural properties –Architecture tradeoffs Presentation: “Architectural.

Slides:



Advertisements
Similar presentations
ATAM Architecture Tradeoff Analysis Method
Advertisements

Distributed Data Processing
Evaluating a Software Architecture By Desalegn Bekele.
Software Architecture – Centric Methods and Agile Development by Craig Castaneda.
Chapter 19: Network Management Business Data Communications, 4e.
Chapter 12 Network Security.
The Architecture Design Process
Chapter 6 Database Design
SE 555 Software Requirements & Specification Requirements Management.
OCT1 Principles From Chapter One of “Distributed Systems Concepts and Design”
Lecture 11 Reliability and Security in IT infrastructure.
1 Security Architecture and Analysis Management of System Development and Implementation –The System Development Process –Issues and Risks –Mitigation.
Chapter 9: Moving to Design
6 Chapter 6 Database Design Hachim Haddouti. 6 2 Hachim Haddouti and Rob & Coronel, Ch6 In this chapter, you will learn: That successful database design.
Maintaining and Updating Windows Server 2008
Network Infrastructure Security. LAN Security Local area networks facilitate the storage and retrieval of programs and data used by a group of people.
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
Load Test Planning Especially with HP LoadRunner >>>>>>>>>>>>>>>>>>>>>>
CSC271 Database Systems Lecture # 21. Summary: Previous Lecture  Phases of database SDLC  Prototyping (optional)  Implementation  Data conversion.
Computer System Lifecycle Chapter 1. Introduction Computer System users, administrators, and designers are all interested in performance evaluation. Whether.
Basic Technology for Electronic Commerce Fan Fan address: GUANGXI UNIVERSITY BUSINESS SCHOOL 2005.
AICT5 – eProject Project Planning for ICT. Process Centre receives Scenario Group Work Scenario on website in October Assessment Window Individual Work.
CPSC 871 John D. McGregor Module 4 Session 3 Architecture Evaluation.
THE PROTOTYPING MODEL The prototyping model begins with requirements gathering. Developer and customer meet and define the overall objectives for the software.
Software Testing Life Cycle
MSF Requirements Envisioning Phase Planning Phase.
Version 4.0. Objectives Describe how networks impact our daily lives. Describe the role of data networking in the human network. Identify the key components.
Project Management : Techniques and Tools (60-499) Fall 2014 / Winter 2015.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Identifying Application Impacts on Network Design Designing and Supporting Computer.
IST 210 Database Design Process IST 210 Todd S. Bacastow January 2005.
1 Chapter 9 Database Design. 2 2 In this chapter, you will learn: That successful database design must reflect the information system of which the database.
Week 4 Lecture Part 3 of 3 Database Design Samuel ConnSamuel Conn, Faculty Suggestions for using the Lecture Slides.
OV Copyright © 2013 Logical Operations, Inc. All rights reserved. Network Security  Network Perimeter Security  Intrusion Detection and Prevention.
Engineering System Design
What is System Design? In System design, we use the requirements we developed in system analysis to create a blueprint of the future system Successful.
OV Copyright © 2011 Element K Content LLC. All rights reserved. Network Security  Network Perimeter Security  Intrusion Detection and Prevention.
Chapter 14 Part II: Architectural Adaptation BY: AARON MCKAY.
Second Hour Lecture 9:30 – 10:20 am, September 8, 2001 Evolution of Software Economics Improving Software Economics (from Chapters 2 and 3 of Royce’ book)
Chapter 6. Control Charts for Variables. Subgroup Data with Unknown  and 
Business Data Communications, Fourth Edition Chapter 11: Network Management.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
IAD 2263: System Analysis and Design Chapter 3: Investigating System Requirements.
Lecture 24 Wireless Network Security
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
1 Client-Server Interaction. 2 Functionality Transport layer and layers below –Basic communication –Reliability Application layer –Abstractions Files.
Network Infrastructure Microsoft Windows 2003 Network Infrastructure MCSE Study Guide for Exam
Unit 9: Distributing Computing & Networking Kaplan University 1.
Introduction to Project Management.  Explain what a project is?  Describe project management.  Understand project management framework.  Discuss the.
Copyright © 2007 Pearson Education Canada 23-1 Chapter 23: Using Advanced Skills.
John D. McGregor Architecture Evaluation
Architecture Tradeoff Analysis Method Software Engineering Institute Carnegie Mellon University Presented by: Senthil ayyasamy CS 590l- winter 2003.
SCID Master Control 4/22/2014SCID Design Details Presentation1 Handheld Device (Walkie) Master Control (Managie) Data Protocol (Talkie)
CI R1 LCO Review Panel Preliminary Report. General Comments –Provide clear definition of the goals of the phase (e.g. inception), the scope, etc. in order.
The ATAM method. The ATAM method (1/2) Architecture Tradeoff Analysis Method Requirements for complex software systems Modifiability Performance Security.
IS3220 Information Technology Infrastructure Security
Understanding IT Infrastructure Lecture 9. 2 Announcements Business Case due Thursday Business Analysis teams have been formed Business Analysis Proposals.
IST 210 Database Design Process IST 210, Section 1 Todd S. Bacastow January 2004.
Maintaining and Updating Windows Server 2008 Lesson 8.
Securing Interconnect Networks By: Bryan Roberts.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco PublicITE I Chapter 6 1 Creating the Network Design Designing and Supporting Computer Networks – Chapter.
System Architecture CS 560. Project Design The requirements describe the function of a system as seen by the client. The software team must design a system.
Quality Attribute Workshop. Goal: To identify requirements Held early in development Includes stakeholders Outputs: Business Goals Quality Attribute Scenarios.
Dr. Ir. Yeffry Handoko Putra
Data and database administration
Maximum Availability Architecture Enterprise Technology Centre.
Chapter 6 Database Design
AICT5 – eProject Project Planning for ICT
Presentation transcript:

1 Security Architecture Analysis Lecture 3 Architecture Analysis –Analysis of architectural properties –Architecture tradeoffs Presentation: “Architectural Mismatch” paper

2 The “CityCorp” E-Commerce System Develop: Prototype an e-commerce system for the Pittsburgh area Users: 500 merchants, 300,000 customers, 75 CityCorp personnel, six banks Function: Present online catalogs and items, and manage sales transactions Architecture: Control center, network of servers and routers, Internet communications Your job: Ensure quality attributes(properties) are met by the architecture

3 Quality Attributes?

4 Quality Attribute Interactions?

5 Observations Attributes interact both positively and negatively Must address security together with other attributes Architecture is right level to address attributes, before committing substantial resources to development Attribute tradeoffs are often not done or employ ad hoc methods High stakes are involved in large systems

6 Architecture Tradeoff Analysis Method (ATAM) An SEI-developed method A structured technique for evaluating an architecture’s fitness with respect to multiple competing quality attributes A spiral model of design: postulating candidate architectures followed by analysis and risk mitigation leading to refined architectures A social and technical process Clarifies requirements, facilitates stakeholder communication, and identifies architecture tradeoff points

7 ATAM Phases Phase I: Scenario and requirements gathering Phase II: Architectural views and scenario tracing Phase III: Model building and analysis Phase IV: Tradeoffs

8 Scenarios can define common or typical “uses” of a system –A “use” can be thought of as a transaction –Example: The steps required to book a flight on the Travelocity website Scenarios can define system failure or stress situations –Example: A critical server suffers a hardware failure Preliminaries: What are Scenarios?

9 Phase I: Scenario and Requirements Gathering Collect scenarios –Involve all stakeholder groups –Scenarios reveal function and attribute requirements Collect requirements/constraints/environment –Identify attribute-based requirements –Described by values or scenarios

10 Phase II: Architectural Views and Scenario Tracing Describe architectural views –An architecture is functionality assigned to a set of structural elements –Competing architectures are described in terms relevant to selected quality attributes Firewalls and encryption for security attribute Concurrency and priorities for performance attribute … Scenario tracing –Understand how scenarios interact with the architecture

11 Phase III: Model Building and Analysis Attribute-specific analysis –Address each attribute in isolation, no tradeoffs yet –Produce models for each attribute for the candidate architectures “Resistance to known denial of service attacks is sufficient in architecture A” “Architecture B performance is 2000 transactions/hour” “Architecture A MTTF is 3.1 days” “Modifiability is good for architecture A, poor for architecture B”

12 Phase IV: Tradeoffs Identify sensitivities –Vary aspects of candidate architectures and observe effects on attribute models –Modeled values significantly affected by architecture changes are sensitivity points Identify tradeoffs –Tradeoff points are architectural elements to which multiple attributes are sensitive –Client/server performance, reliability, security, etc., are sensitive to number of servers, a tradeoff point Select optimum architecture based on tradeoffs

13 The Furnace System Example Remote temperature sensor (RTS) system exists to measure temperatures of a set of 16 furnaces and report them to 16 clients (one furnace per client, client-server architecture) Normal scenarios –A client requests that the RTS server change the schedule for temperature readings for a furnace (each furnace can report on a different periodic schedule) –A furnace temperature is read by the RTS server and sent to the client based on the current schedule for readings

14 The Furnace System Example Three architectures are proposed –Client-server –Client-server-server –Client-intelligent cache-server Architecture tradeoffs are analyzed for performance, availability, and security attributes See paper for performance and availability analysis, we will look at security analysis

15 Furnace System Architecture - Option 1... RTS Server Furnace 1 Schedule Requests... LAN Furnace client 16 Furnace 2 Furnace 16 Temperatures Furnace client 1 Furnace client 2

16 Furnace System Architecture - Option 2... RTS Server 2 Furnace 1... LAN Furnace client 1 Furnace 2 Furnace RTS Server 1 Furnace 1 Furnace 2 Furnace 16 Furnace client 2 Each server is primary to 8 clients and backup to 8 clients Furnace client 16

17 Furnace System Architecture - Option 3... RTS Server Furnace 1... LAN Furnace client 1 Furnace 2 Furnace 16 IC Furnace client 16 IC IC = Intelligent Cache: saves history of temperatures and extrapolates future values if server or connection to server is lost Furnace client 1 IC

18 Attack Scenarios -- 1 Man-in-Middle attack –Use TCP intercept tool to modify temperature values during transmission

19 Man-in-Middle Attack RTS Server Furnace client Attacker LAN Furnace client 1... Furnace 1 Furnace 2 Furnace 16 Furnace client 2

20 Attack Scenarios -- 2 Spoof-the-Server attack -- three methods –Server failure Wait for server to fail, spoof its address, and take over connections –Kill server Cause the server to fail, spoof its address, and take over connections –Kill connection Disrupt client-server connection, spoof server address, and take over connections

21 Spoof-the-Server Attack... RTS Server Furnace client Attacker Furnace client 1 LAN Furnace client 2 Furnace 1 Furnace 2 Furnace 16

22 Security Model -- 1 Security requirement: focus on accuracy of temperature reports –“The temperature readings must not be corrupted before they arrive at the client”

23 Security Model -- 2 To calculate probability of successful attack within window of opportunity, estimate values for RTS attack parameters: Attack Component Value attack exposure window 60 minutes attack rate 0.05 systems/minute server failure rate 24 failures/year probability of server failure in one hour probability of TCP intercept 0.5 probability of spoof IP address 0.9 probability of kill connection 0.75 probability of kill server 0.25

24 Security Model -- 3 Terminology –W is length of time an intruder can operate undetected –R is rate of attack within W –P is probability of success in an attack step Attack scenarios consist of several steps, each with some probability of success, so general expression is: E = W * R * P1 * …* Pn

25 Security Model -- 4 Man-in-Middle Attack: E = W * R * Ptcp-intercept = 60 * 0.05 * 0.5 = 1.5 Spoof-the-Server attack –Server failure: E = W * R * Pserver-failure * Pspoof-ip = 60 * 0.05 * * 0.9 = –Kill server: E = W * R * Pkill-server * Pspoof-ip = 60 * 0.05 * 0.25 * 0.9 = 0.66 –Kill connection: E = W * R * Pkill-connection * Pspoof-ip = 60 * 0.05 * 0.75 * 0.9 = 2.04

26 Architecture Analysis and Evolution Analysis shows security attribute is not satisfied in any of the three architectures, which have no security features Propose a revised architecture –Add encryption/decryption to communication links –Add “new intelligent cache” to clients to detect out-of- range temperature variations possibly from intruders Requires additional attack components –Decryption: Decode and modify temperatures –Replay: Intercept temperatures and resend later –Key distribution: Intruder obtains encryption keys Revised architecture will satisfy the security attribute

27 Revised Furnace System Architecture... RTS Server Furnace 1... LAN Furnace client 1 Furnace 2 Furnace 16 new IC E/D Furnace client 2E/D Furnace client 16E/D E/D = encryption/decryption new IC new IC

28 Attack Component Value probability of successful decryption probability of successful replay 0.05 probability of obtaining encryption keys 0.09 Security Analysis: Just Encryption/Decryption Adding encryption requires additional estimates: Expected intrusions with encryption/decryption drop by at least an order of magnitude: Attack Type Expected Intrusions in 60 Minutes kill connection kill server server failure

29 Attack Type Expected Intrusions in 60 Minutes kill connection kill server server failure Security Analysis: Just New Intelligent Cache New cache treats out-of-bound temperature change as possible result of intrusion and thus aids operator in detecting intrusions Result: attack window drops from estimated 60 to 5 minutes Thus, number of expected intrusions drops 1-2 orders of magnitude (comparable to encryption), but at less cost and performance impact -- this is the best tradeoff choice

30 Overall Sensitivity Analysis Availability and performance attributes were positively correlated to the number of servers (see paper) Security is negatively correlated to number of servers –Additional server switching logic in clients is another entry point for spoofing attacks not present when hard-wired to a single server –Probability of server failure increases with number of servers Number of servers is a significant architecture tradeoff point