Topics: Analysis of Architectural Properties Architecture Tradeoffs – The ATAM Method

1. Security Architecture and Analysis: Session 2b • Topics: • Analysis of Architectural Properties • Architecture Tradeoffs – The ATAM Method

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

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 & 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 Schedule Requests LAN Furnace client 1 Furnace 1 RTS Server Furnace client 2 Furnace 2 ... ... Furnace client 16 Furnace 16 Temperatures

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

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

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

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

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 LAN Furnace 1 RTS Server Furnace client 1 Furnace 2 ... Furnace client 2 Furnace 16 ... Furnace client 16 Attacker

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 0.0027 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.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 LAN new IC E/D Furnace client 1 Furnace 1 RTS Server new IC E/D Furnace client 2 Furnace 2 ... ... new IC E/D Furnace client 16 Furnace 16 E/D = encryption/decryption

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

29. 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 Expected Intrusions in 60 Minutes kill connection 0.169 kill server 0.056 server failure 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

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