Secure Systems Requirements and Construction with Security Patterns Eduardo B. Fernandez

1. Secure Systems Requirements and Construction with Security PatternsEduardo B. Fernandez Dept. of Computer Science and Engineering Florida Atlantic UniversityBoca Raton, FL, USA http://www.cse.fau.edu/~ed ed@cse.fau.edu

2. Abstract • Patterns combine experience and good practices to develop basic models that can be used to build new systems and to evaluate existing systems. Security patterns join the extensive knowledge accumulated about security with the structure provided by patterns to provide guidelines for secure system requirements, design, and evaluation. We consider the structure and purpose of security patterns, show a variety of security patterns, and illustrate their use in the construction of secure systems. These patterns include among others Authentication, Authorization/Access Control, Firewalls, Secure Broker, Web Services Security, and Cloud Security. We have built a catalog of over 100 security patterns. We introduce Abstract Security patterns (ASPs) which are used in the requirements and analysis stages. We complement these patterns with misuse patterns, which describe how an attack is performed from the point of view of the attacker and how it can be stopped. We integrate patterns in the form of security reference architectures. We introduce patterns in a conceptual way, relating them to their purposes and to the functional parts of the architecture. Example architectures include a financial system and a cloud computing system. The use of patterns can provide a holistic view of security, which is a fundamental principle to build secure systems. The patterns and reference architectures are shown using UML models and examples are taken from my two books on security patterns as well as from my recent publications. The patterns are put in context; that is, we do not present a disjoint collection of patterns but we present a logical architectural structuring where the patterns are added where needed. In fact, we present a complete methodology to apply the patterns along the system lifecycle.For this conference we emphasize the early lifecycle stages but also show the effect of the requirements in the later stages.

3. About me • Professor of Computer Science at Florida Atlantic University, Boca Raton, FL., USA • At IBM for 8 years (L.A. Scientific Center). • Wrote the first book on database security (Addison-Wesley, 1981). • Author of many research papers • Consultant to IBM, Siemens, Lucent,… • MS EE Purdue U, PhD CS UCLA

7. Outline • Security concepts • Threats • Approaches to security • The design of secure systems • Security patterns • Principles and policies • Using the patterns • Architectural layers and patterns, Abstract security patterns • Security models and their patterns---policies, access matrix, multilevel models, RBAC • Conceptual models in applications • Operating systems patterns • Network layer patterns • Patterns for web services and cloud computing, misuse patterns

8. Outline II • A methodology for building secure architectures • Defining authorizations from use cases---nonfunctional aspects of use cases, RBAC and security policies. Security Logging/Auditing. Authentication. • Security reference architectures (SRAs), a SRA for cloud systems, a financial SRA • Coordination across levels---mapping of authorizations across architectural levels: relating threats to use cases. • Secure semantic analysis patterns • Case studies: a financial system, a cloud system • Conclusions---the future

9. Objectives • Get a panorama of security patterns and their use • Study some specific patterns in detail • Consider a systematic approach to build secure systems based on patterns and UML

10. Security concepts • Motivation and Objectives • Countermeasures • Security architectures

11. The value of information • Individuals and enterprises rely on information for credit, health, professional work, business, education,… • Illegal access (reading or modification) to information can produce serious problems • Because of its value, information is a growing target of attacks

12. Cost of data breaches • An attack on Google cost that company about $500,000 in 2005. • In a recent study (Ponemon Institute), the average cost of a data breach for a company was $3.75 M in 2014, and the average cost for each stolen or lost record was $154.

13. Security is the protection against: • Unauthorized data disclosure (confidentiality or secrecy). • Unauthorized data modification (integrity). Unauthorized modification of data may result in inconsistencies or erroneous data. Data destruction may bring all kinds of losses. • Loss of availability (Denial of service)—Users or other systems may prevent the legitimate users from using their system. • Lack of accountability—Users should be responsible for their actions and should not be able to deny what they have done (non-repudiation).

14. The meaning of security • Security implies providing these objectives in the presence of attacks • Security requires technical, managerial, and physical countermeasures (defenses) • We only consider technical aspects here • A related aspect is privacy, a legal and ethics concern

15. Countermeasures I • Identification and Authentication (I&A)—Identification is a user or system action where the user provides an identity. Authentication implies some proof that a user or system is the one he/it claims to be. • Authorization and Access control (A & A)—Authorization defines permitted access to resources depending on the accessor (user, executing process), the resource being accessed, and the intended use of the resource. Access control requires some mechanism to enforce authorization • Logging and Auditing (L&A)—These functions imply keeping a record (log) of actions that may be relevant for security and analyzing it later. They can be used to collect evidence for prosecution (forensics) and to improve the system by analyzing why the attack succeeded.

16. Countermeasures II • Hiding of information—Hiding the contents of information is usually performed by the use of cryptography but steganography is another option. The idea is to make the information unreadable to an attacker. • Intrusion detection—Intrusion Detection Systems (IDS) alert the system when an intruder is trying to attack the system.

17. Basic secure architecture • Authentication musthappen first • Authorization rules define what is allowed or not allowed (who can see what and how) • Lower architectural levels enforce authentication and authorization • Cryptography protects messages in transit and stored data, and provides non-repudiation and authentication • Continuous logging for later auditing

18. Security environments or contexts • Early systems were isolated and single user --few security problems • Mainframes brought many users but we knew them (registered)—complexity and attacks increased • Distributed systems increased the problem by scattering the users

19. Environments II • The Internet opened up our systems to unknown users—exponential growth in attacks • Wireless devices increase the problem because of their number and ubiquity • The widespread use of sensors will make security even worse • The cloud brings new problems

21. Threats • We need to understand the threats to the system to decide how to defend it • Excess of security mechanisms results in loss of performance, extra complexity, and higher costs • The objective is to provide an appropriate defenses according to the value of our assets

22. Attacks and defenses • Generic attacks are realized in two basic ways: by direct attacks from a person trying to exploit a vulnerability or flaw in the system, or using malware, software that contains code that exploits one or more of these flaws • Security defenses may operate in one or more of three modes and we need to combine them: • Prevent or mitigate an attack. Prevention means completely stopping the attack while mitigation implies partial defense or reducing its effects • If we cannot stop or mitigate the attack, at least we should be able to know that an attack is happening, i.e., we should detect the attack. Detection is also useful to stop an attack because it can alert other mechanisms to take action • After the attack has happened we need to have ways to recover from its effects and analyze it so we can improve the system

23. Types of Threats • Direct attacks to the operating system • Direct attacks to the database system • Directs attacks to the application • Denial of service • Almost no attacks to the messages in the network • Malware: Trojan horses, viruses, worms • Repudiation

25. Approaches to security • Formal models do not prove security because they make many assumptions which may not be true in practice. Also have size limitations. • Cryptographic methods are effective but only for specific aspects: system or message authentication, secure transmission of messages, storage protection. They cannot stop attacks based on code or system flaws. • Code-based methods cannot find all vulnerabilities because many attacks exploit system interactions, not code flaws. • Model-based security can build a strong structure where parts of the system may be compromised but the essential parts of the system can be protected (submarine effect).

26. Approaches to security Model checking and composability of systems Verification Theoretical Analysis of Security UML/OCL models Security patterns Certification Model-driven Security Vulnerability analysis Code examination Best practices Code-based Security Certification

27. Current situation • The Internet is an insecure place and attacks keep occurring • One of the main reasons is the poor quality of the software used in systems and application software • Software engineering neglected security for a long time

28. A possible remedy • Help designers build secure systems using a systematic approach • Provide units of security (packed solutions to specific problems) • Build security together with the functional part of the application • Use a model-based approach

29. Security Patterns Software Engineering

30. Security patterns • Idea • Anatomy of a pattern • Classifications

31. Patterns • A pattern is a solution to a recurrent problem in a specific context • Idea comes from architecture of buildings (C. Alexander) • Applied initially to software and then extended to other domains • Appeared in 1994 and are increasingly being accepted by industry

32. Value • Reusable solutions, but maybe not directly, usually require tailoring • Encapsulate experience and knowledge of designers (best practices) • Free of errors after a while • Need to be catalogued to be useful • Used as guidelines for design • Good to evaluate systems and standards • Useful for teaching

33. Why security patterns? • Analysis patterns can be used to build conceptual models of software, design patterns can be used to make software more flexible and reusable, and security patterns can be used to build secure systems, including hardware or organizational problems. • Security has had a long trajectory, starting from the early models of Lampson and Bell/LaPadula in the early 70s, and resulting in a variety of approaches to analyze security problems and to design security mechanisms. It is natural to try to codify this expertise in the form of patterns. • Security patterns describe mechanisms to stop some attacks and apply principles of good design

34. Value of security patterns • Can describe security principles (Single Point of Access) or security mechanisms (Firewalls) • Can guide the design and implementation of the security mechanism itself • Can guide the use of security mechanisms in an application (stop specific threats) • Can help understanding and use of complex standards (XACML, WiMax) • Good for teaching security principles and mechanisms

35. POSA template (Buschmann) • Intent (thumbnail) • Example • Context • Problem and forces • Solution: in words, UML models (static and dynamic) • Implementation • Example resolved • Known uses • Consequences • See also (related patterns)

36. Anatomy of a security pattern • Every pattern starts with a thumbnail of the problem it solves and a brief description of how it solves the problem. • The Packet Filter Firewall filters incoming and outgoing network traffic in a computer system based on packet inspection at the IP level.

37. Context section • We define the context or environment where the pattern solution is applicable: Context • Computer systems on a local network connected to the Internet and to other networks with different levels of trust. A host in a local network receives and sends traffic to other networks. This traffic has several layers or levels. The most basic level is the IP level, made up of packets consisting of headers and bodies (payloads). The headers include the source and destination addresses as well as other routing information, the bodies include the message payloads.

38. Problem Section I • Now a generic description of what happens when we don’t have a good solution: We also indicate the forces that affect the possible solution. We may list all attacks that we want to stop with this solution. Problem • Some of the hosts in other networks may try to attack the local network through their IP-level payloads. These payloads may include viruses or application-specific attacks. We need to identify and block those hosts. :

39. Forces • We need to communicate with other networks so isolating our network is not an option. However, we do not want to take a high risk. • The protection mechanism should be able to reflect precisely the security policies of the institution. A too coarse defense may not be useful. • Any protection mechanism should be transparent to the users. Users should not need to perform special actions to be secure. • The cost and overhead of the protection mechanism should be relatively low or the system may become too expensive to run. • Network administrators deploy and configure a variety of protection mechanisms; hence it is important to have a clear model of what is being protected. • The attacks are constantly changing; hence it should be easy to make changes to the configuration of the protection mechanism. • It may be necessary to log input and/or output requests for auditing and defense purposes.

40. Solution section • The solution section describes the idea of the pattern. A descriptive figure may help to visualize the solution. Solution • A Packet Filter Firewall intercepts all traffic coming/going from a port P and inspects its packets (Figure 1). Those coming from or going to untrusted addresses are rejected. The untrusted addresses are determined from a set of rules that implement the security policies of the institution. A client from another network can only access the Local Host if a rule exists authorizing traffic from its address. Rules may be positive (allow traffic from some address) or negative (block traffic). Additionally, if a request is not satisfied by any of the Explicit Rules, then a Default Rule is applied.

41. Idea of the solution

42. Structure of the solution

43. Filtering a client’s request

44. Implementation section • What one should consider when implementating the pattern is the objective of the next section. This can be a set of general recommendations or a sequence of what to do to use the pattern. It may include some sample code if appropriate. Implementation • Define an institution policy about network access, classifying sites according to our trust in them. • Convert this policy into a set of access rules. This can be done manually, which may be complex for large systems. An alternative is using an appropriate commercial product. . • Note that the idea of a single point of access is virtual, there may be several physical firewalls deployed at different places. This means it is necessary to install firewalls at all external boundaries (routers or gateways). • Write the rules in each firewall. Again, products such as Solsoft and others automatically propagate the rules to each registered firewall. • Configure the corresponding firewalls according to standard architectures. A common deployment architecture is the Demilitarized Zone (DMZ) [Sch06].

45. Known uses section To accept this solution as a pattern we should find at least three examples of its use in real systems. Known Uses This architecture can be found in commercial firewall products such as: ARGuE (Advanced Research Guard for Experimentation), OpenBSD Packet Filtering Firewall (the basic firewall architecture for the Berkeley Software Distribution system) and the Linux Firewall, the basic firewall architecture used with the Linux operating system.

46. Consequences--advantages • The Consequences section indicates the advantages and disadvantages of the solution embodied in this pattern. The advantages should match the forces in the Problem section. Consequences The Packet Filter Firewall Pattern has the following advantages: • A firewall transparently filters all the traffic that passes through it, thus lowering the risk of communicating with potentially hostile networks. • It is possible to express the institution filtering policies through its filtering rules, with different levels of protection for different parts of the network. • It is easy to update the rule set to counter new threats. • Because it intercepts all requests, a firewall allows systematic logging of incoming and outgoing messages. Because of this, a firewall facilitates the detection of possible attacks and helps to hold local users responsible of their actions when interacting with external networks. • Low cost, it is included as part of many operating systems and simple network devices such as routers. • Good performance. It only needs to look at the headers of IP packets, not at the complete packet. • It can be combined with Intrusion Detection Systems (IDS) for greater effectiveness. In this case, the IDS can tell the firewall to block suspicious traffic. This can also be useful to control Distributed Denial of Service (DDoS) attacks.

47. Consequences--disadvantages • The firewall’s effectiveness and speed may be limited due to its rule set (order of precedence). Addition of new rules may interfere with existing rules in the rule set; hence, a careful approach should be taken in adding and updating access rules. • The firewall can only enforce security policies on traffic that goes through the firewall. This means that one must make changes to the network to ensure that there are no other paths into its hosts. • An IP-level firewall cannot stop attacks coming through the higher levels of the network. For example, a hacker could put malicious commands or data in header data not used for routing and in the payload. • Each packet is analyzed independently, which means that it is necessary to analyze every packet. This may reduce performance. • A packet filter cannot recognize forged addresses (IP spoofing) because it only examines the header of the IP packet. This can be corrected (at some extra cost) using Link Layer filtering, where each IP address is correlated to its hardware address [Fra01].

48. Related patterns section (See also) • Finally, we relate our pattern to other known patterns. Those may be complementary patterns, variations of our pattern, or extensions of it. • The Authorization pattern [Fer01] defines the standard security model for the Packet Filter Firewall Pattern. This pattern is also a special case of the Single-Point-of-Access [Sch06] and it is the basis for other, more complex, types of firewalls (described in the other patterns in this language). The DMZ pattern [Sch06] defines a way to configure this pattern in a network. This pattern can also be combined with the Stateful Inspection Firewall [Sch06].

49. The design of secure systems • Security should be applied where the application semantics is understood • Security is an all-levels problem • High-level policies can be mapped to the lower levels • We need precise models to guide system development

50. Secure Design II • A unified system is easier to understand: better design, better administration • Easier to analyze effect of new hardware or software • Apply principles of good design • Start from principles, policies, and models • Apply security throughout the lifecycle