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

2. 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. 3 Quality Attributes?

4. 4 Quality Attribute Interactions?

5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16 Furnace System Architecture - Option 2... RTS Server 2 Furnace 1... LAN Furnace client 1 Furnace 2 Furnace 16... 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. 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. 18 Attack Scenarios -- 1 Man-in-Middle attack –Use TCP intercept tool to modify temperature values during transmission

19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28 Attack Component Value probability of successful decryption 0.0005 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 0.182 kill server 0.338 server failure 0.0006

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