Security Architecture Analysis Lecture 3 Architecture Analysis Analysis

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

The “City. Corp” E-Commerce System • Develop: • • Prototype an e-commerce system for the Pittsburgh area Users: 500 merchants, 300, 000 customers, 75 City. Corp 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 2

Quality Attributes? 3

Quality Attribute Interactions? 4

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 5

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 6

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

Preliminaries: What are Scenarios? • 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 8

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 9

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 10

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” 11

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 12

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 13

The Furnace System Example • Three architectures are proposed – 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 14

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

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

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

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

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

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 20

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

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

Security Model -- 2 • To calculate probability of successful attack within window of opportunity, estimate values for RTS attack parameters: Attack Component attack exposure window attack rate server failure rate probability of server failure in one hour probability of TCP intercept probability of spoof IP address probability of kill connection probability of kill server Value 60 minutes 0. 05 systems/minute 24 failures/year 0. 0027 0. 5 0. 9 0. 75 0. 25 23

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 * P 1 * …* Pn 24

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 25

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-ofrange 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 26

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

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

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 Attack Type kill connection kill server failure Expected Intrusions in 60 Minutes 0. 169 0. 056 0. 005 • 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 29

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 30