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 ServerFurnace 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 2Furnace 1...

LAN

Furnace client 1

Furnace 2

Furnace 16

...

RTS Server 1Furnace 1

Furnace 2

Furnace 16Furnace client 2

Each server is primary to 8 clients and backup to 8 clients

Furnace client 16

17

Furnace System Architecture - Option 3

...

RTS ServerFurnace 1

...

LAN

Furnace client 1

Furnace 2

Furnace 16

IC

Furnace client 16IC

IC = Intelligent Cache: saves history oftemperatures and extrapolates future values if server or connection to server is lost

Furnace client 1IC

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 16

...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 16

...

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 minutesattack rate 0.05 systems/minuteserver failure rate 24 failures/yearprobability of server failure in one hour 0.0027probability of TCP intercept 0.5probability of spoof IP address 0.9probability of kill connection 0.75probability 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.0027 * 0.9 = 0.0072

– 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 ServerFurnace 1

...

LAN

Furnace client 1

Furnace 2

Furnace 16

newIC

E/D

Furnace client 2E/D

Furnace client 16E/D

E/D = encryption/decryption

newIC

newIC

28

Attack Component Value

probability of successful decryption 0.0005probability 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 0.182kill server 0.338server failure 0.0006

29

Attack Type Expected Intrusions in 60 Minutes kill connection 0.169kill server 0.056server failure 0.005

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