1 / 57

Security-related pattern varieties Eduardo B. Fernandez

Security-related pattern varieties Eduardo B. Fernandez . Dept. of Computer Science and Engineering Florida Atlantic University Boca Raton, FL, USA http://www.cse.fau.edu/~ed ed@cse.fau.edu. Outline. Introduction and motivation Security patterns

hideaki
Download Presentation

Security-related pattern varieties Eduardo B. Fernandez

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Security-related pattern varieties Eduardo 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. Outline • Introduction and motivation • Security patterns • Variants: Secure Semantic Analysis Patterns, privacy patterns, physical access patterns • Attack patterns • Decision trees • Dependability patterns • Conclusions

  3. 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 now being accepted by industry

  4. Value • Reusable solutions, require tailoring • Encapsulate experience and knowledge of designers (best practices) • Free of errors (after a while) • Need to be catalogued to be useful • Useful also for teaching • The appearance of design patterns was one of the most important developments in software engineering

  5. 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. Patterns can also solve 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.

  6. Security objectives • Confidentiality--no leakage of sensitive or private information • Integrity-- no unauthorized modification or destruction of information • Availability (No denial of service) -- annoying , costly • Accountability (Non-repudiation)-- legally significant

  7. Countermeasures • Identification and Authentication– first step • Access control/ authorization --provide confidentiality and integrity • Auditing-- basis for prosecution or improvements to the system • Cryptography-- a mechanism to hide information and prove identity and rights • Intrusion detection

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

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

  10. 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. :

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

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

  13. Structure of the solution

  14. Filtering a client’s request

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

  16. Known uses section • To accept this solution as a pattern we should find at least three examples of its use in real systems. • Related patterns section describes similar or complementary patterns

  17. Applic. Layer: Access control models • Authorization. How do we describe who is authorized to access specific resources in a system? A list of authorization rules describes who has access to what and how. • Role-Based Access Control (RBAC). How do we assign rights to people based on their functions or tasks? Assign people to roles and give rights to these roles so they can perform their tasks. • Multilevel Security. How to decide access in an environment with security classifications.

  18. Authorization

  19. Reference monitor pattern

  20. Patterns for access control

  21. Web services security • Application Firewall [Del04]. The application firewall filters calls and responses to/from enterprise applications, based on an institution access control policies. • XML Firewall [Del04]. Filter XML messages to/from enterprise applications, based on business access control policies and the content of the message. • XACML Authorization [Del05]. Enable an organization to represent authorization rules in a standard manner. • XACML Access Control Evaluation [Del05]. This pattern decides if a request is authorized to access a resource according to policies defined by the XACML Authorization pattern. . • WSPL [Del05]. Enable an organization to represent access control policies for its web services in a standard manner. It also enables a web services consumer to express its requirements in a standard manner.

  22. Patterns for web services

  23. 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 teaching tool

  24. SSAP • We have proposed the use of Semantic Analysis Patterns (SAPs) to build conceptual models of applications • A SAP is a composite pattern that corresponds to a few fundamental use cases • Using SAPs it is possible to build conceptual models in a simpler and more reliable way • We have also developed a methodology to build secure systems • In this methodology we add instances of security patterns to the functional parts of the conceptual model to define security constraints at the application level. These constraints are then enforced by the lower architectural levels.

  25. Secure SAPs • We extend the SAPs to consider possible attacks to the fundamental use cases that define it, and we define policies to prevent the attacks • Since the SAPs are used to build the conceptual model of an application, we have now a portion of a conceptual model where functional and security aspects are integrated from the start, a Secure Semantic Analysis Pattern (SSAP) • To describe SSAPs we have extended the template with sections on possible attacks (the possible attacks in each activity of a use case), needed policies (to prevent or mitigate the attacks), and secure structure (the class model of the solution with security constraints)

  26. Secure handling of legal cases • This pattern describes the handling of legal cases where a client is either suing another party (a plaintiff) or is being defended from a suit (a defendant). The pattern includes the necessary policies (in the form of security patterns) to stop or mitigate the expected attacks.

  27. Forces • Unpredictability of activities. The sequence of activities in a case is usually unpredictable. Depositions, witness court appearances, lawyer briefs to the court might be required in any sequence depending on the course of the case. • Unpredictablity of people and logistics. The total effort and duration of a case is variable and we need to keep track of expenses, time used, supplies, etc., so we can bill our clients. • Precedent searching. Handling cases require searching for precedents (similar cases). To do research for cases, lawyers and secretaries make use of libraries and the Internet and may download many documents. • Access control to information. The information about customers, billing, assignment of lawyers, and other aspects related to a current case must be accessible only to authorized persons. • Control of documents.Legal documents can only be created by authorized persons and their use (reading or modification) should also be controlled. • Confidentality. Communications between lawyers and clients must be confidential. • Auditability. Government regulations apply to law firms and their information must be easily auditable.

  28. Basic use cases

  29. Possible attacks • A1 In the ‘start case’ activity, the client or the responsible lawyer might be impostors. • A2 A lawyer might create a false contract. • A3 The client or the external people might give a false deposition. • A4 A lawyer may change a deposition. • A5 A lawyer or a secretary may produce intentionally incorrect precedents, briefs, or costs. • A6 A secretary may produce an increased or decreased bill. • A7 A lawyer may change some aspects of the outcome to collect a higher fee. • A8 A lawyer can disseminate client or case information for monetary gain. • A9 An external attacker may read/change case information or access client/lawyer communications.

  30. Solution

  31. Secure structure The attacks identified earlier mean that we need the following policies to avoid or mitigate them: • A1 Mutual authentication, to avoid impostors. • A2 Authorization to restrict only lawyers to create contracts, and logging to record possible illegal actions from a lawyer. • A3 Logging, to keep records for future auditing that could detect false depositions. • A4 Authorization and document protection against change. • A5 Authorization and logging, to restrict who can perform these actions and to keep records for future auditing. • A6 Logging, to record suspicious actions of a secretary. • A7 Separation of duty. Two lawyers must concur on the fees to be charged. • A8 Logging, to record possible illegal actions of lawyers. • A9 Authorization and access control to stop external attacks and cryptography to protect communications

  32. Secure class diagram

  33. Conseqs-Effect on security • We can define precise role rights, e.g. an expert can only add to the information, not change it, a lawyer can decide on the next step, bring new witnesses, but cannot change depositions. • A designer building a system of this type can produce software that performs its functions and is at the same time reasonably secure. • The RBAC structure enforces authorized access to the information and employees can make sure that they are talking to the person they intend. • Cryptographic methods can be added to prevent document modification, e.g. hashing

  34. SAPs and security patterns

  35. Use of SSAPs

  36. Other variations • Privacy patterns—describe privacy policy definition, negotiation, and enforcement • Physical security patterns---describe security mechanisms for physical systems: access to buildings, secure SCADA systems • Dependability patterns---combine security and fault tolerance/safety/reliability

  37. Scoped Data Pattern • This pattern provides a way to restrict the usage of data collected by a service to a predetermined context. It introduces the concept of Scope and Scoped Data – in order to restrict the use of data collected by services.

  38. Scoped data class diagram

  39. Patterns for physical access control • Alarm Monitoring. Defines a way to raise events in the system that might require special attention, like the tampering of a door. • Relays. Defines the interactions with electronically controlled switches. • Access Control to Physical Structures. Applies authentication and authorization (RBAC) to the control of access to physical units including alarm monitoring, relays, and time schedules that can control when things will happen.

  40. New types of patterns • Attack patterns —Combine security and forensic aspects • Architectural decision trees---Record architectural decisions in a complex system

  41. Attack patterns • It is not clear to an inexperienced designer what security pattern should be applied to stop a specific attack • Security patterns are not useful either for forensics because they do not emphasize the modus operandi of attacks. • Attack patterns describe, from the point of view of the attacker, how a type of attack is performed (what system units it uses and how), proposes ways of stopping the attack by enumerating possible security patterns that can be applied for this purpose, and helps analyzing the attack once it has happened by indicating where can we find forensic data as well as what type of data.

  42. New sections of the template I • Name The name of the pattern should correspond to the generic name given to the specific type of attack in standard attack repositories such as CERT or Symantec • Intent or thumbnail description A short description of the intended purpose of the pattern (which problem it solves for an attacker). • Context Describes the general environment, including the conditions under which the attack may occur. These may include minimal defenses usually present in the system as well as typical vulnerabilities of the system.

  43. Sections of the template II • Problem Defines the goal of the attack pattern. From a hacker’s perspective, the problem is how to find a way to attack the system. An additional problem occurs whenever a system is protected by some defense mechanisms and there may be indications of how to overcome them. The forces indicate what factors may be required in order to accomplish the attack and what way, for example, which vulnerabilities can be exploited. Also, which factors may obstruct or delay accomplishing the attack. • Solution Describes the solution of the hacker’s problem, i.e., how the attack can be performed in order for it to reach its objectives and the expected results of the attack. UML class diagrams show the system before and during the attack. Sequence diagrams show the exchange of messages needed to accomplish the attack. State or activity diagrams may add further detail.

  44. Countermeasures and forensics • This is a new section compared to the template for standard security patterns. It describes the security measures necessary in order to stop, mitigate, or trace this type of attack. This implies an enumeration of which security patterns are effective against this attack. From a forensic viewpoint, it describes what information can be obtained at each stage tracing back the attack and what can be deduced from this data in order to identify this specific attack. Finally, it may indicate what additional information should be collected at the involved units to improve forensic analysis.

  45. Decision trees • From the conceptual model, which is technology independent, an architect has to make several choices about the technology platform, standard, or product to be used • We can record these decisions in a tree form • We can reuse these decisions in similar applications

More Related