Security-related pattern varieties Eduardo B. Fernandez

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_at_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
(No Transcript)
7
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

8
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

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

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

11
Problem Section I

• Now a generic description of what happens when we
  dont 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.

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

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

14
Structure of the solution
15
Filtering a clients request
16
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.

17
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

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

19
Authorization
20
Reference monitor pattern
21
Patterns for access control
22
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.

23
Patterns for web services
24
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

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

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

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

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

29
Basic use cases
30
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.

31
Solution
32
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

33
Secure class diagram
34
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

35
SAPs and security patterns
36
Use of SSAPs
37
Other variations

• Privacy patternsdescribe 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

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

39
Scoped data class diagram
40
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.

41
(No Transcript)
42
New types of patterns

• Attack patterns Combine security and forensic
  aspects
• Architectural decision trees---Record
  architectural decisions in a complex system

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

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

45
Sections of the template II

• Problem
• Defines the goal of the attack pattern. From
  a hackers 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 hackers
  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.

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

47
(No Transcript)
48
(No Transcript)
49
(No Transcript)
50
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

51
Architectural decision tree
52
Law firm example

• We need to apply the following policies to
• avoid or mitigate the identified threats
• T1 Authentication
• T2, T3, and T5 Authorization/ access control and
  logging
• T4 Backup and logging
• T6 Message encryption
• T7 Message encryption and digital signatures

53
Security decisions in the architectural decision
tree
54
Value of decision trees

• The architectural decision tree records explicit
  design decisions about security, vis a vis
  functional architectural decisions
• In this way an architect can reuse a good design
  or backtrack in the tree and make a different
  decision if a particular decision does not lead
  to a satisfactory solution (with respect to
  functional and security requirements), or the new
  application has different requirements
• A specific tree, showing the decisions made in a
  specific application, is a kind of pattern in
  that it embodies good practices that were useful
  in some real case.

55
Conclusions I

• Security patterns are becoming accepted by
  designers and industry two books, many papers,
  companies (Microsoft, Sun, and IBM) have books,
  papers, and web pages on this subject. A general
  page for security patterns www.security-patterns.
  org
• Secure Semantic Analysis patterns let designers
  define precisely security requirements
• Attack patterns help the designer select what
  pattern to apply and are valuable for forensics

56
Conclusions II

• Architectural decision trees record the
  experience of architects, including security
  decisions
• Privacy patterns can express user needs and
  privacy negotiation and enforcement
• Physical security patterns describe convergence
  of physical and information security

57
Future work

• How to combine these patterns efficiently
• Develop more patterns few privacy patterns, few
  reliability patterns, no dependability patterns
• Incorporate their use into the system methodology