Security patterns Eduardo B. Fernandez

1
Security patterns 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
• Anatomy of a security pattern
• Architectural layers and their patterns
• A methodology for secure systems design
• 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
• Not related to intrusion detection, signature
  analysis, or similar

4
Value

• Reusable solutions, maybe not directly, may
  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 of the last 20 years.

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

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

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

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

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

12
Idea of the solution
13
Structure of the solution
14
Filtering a clients 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.
• 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.

17
Using the patterns

• Catalogs of patterns are not enough, designers
  must be given guidance in their use
• There are many patterns (growing in number) and
  the task of selecting them gets harder
• A first approach is to classify the patterns
  according to some criteria

18
How to classify security patterns?

• Avg05 classifies architectural patterns using
  the type of concerns they address, e.g. Layered
  Structure, Data Flow, Adaptation, User
  Interaction, Distribution. Security patterns
  could be classified according to type of
  mecahnism, e.g. access control, authentication,
• We think of a computer system as a hierarchy of
  layers, where the application layer uses the
  services of the database and operating system
  layers, which in turn, execute on a hardware
  layer.
• We combine these two classifications

19
Security principles for layers

• Security constraints should be defined at the
  highest layer, where their semantics are clear,
  and propagated to the lower levels, which enforce
  them.
• All the layers of the architecture must be
  secure.
• We can define patterns at all levels. This allows
  a designer to make sure that all levels are
  secured, and also makes easier propagating down
  the high-level constraints.

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

21
More specialized access control

• Metadata-Based Access Control, later renamed
  Attribute-Based Access Control (ABAC) Pri04,
  Pri05. Allow access to resources based on the
  attributes of the subjects and the properties of
  the objects
• Aspect-oriented access control Paz05. Separate
  in different modules access policies that apply
  to a program.

22
Authorization
23
(No Transcript)
24
Reference monitor pattern
25
(No Transcript)
26
Role-Based Access Control

• Users are assigned roles according to their
  functions and given the needed rights (access
  types for specific objects)
• When users are assigned by administrators, this
  is a mandatory model
• Can implement least privilege and separation of
  duty policies

27
(No Transcript)
28
Patterns for access control
29
Patterns for operating systems

• Controlled Virtual Address Space. How to control
  access by processes to specific areas of their
  virtual address space (VAS) according to a set of
  predefined rights? Divide the VAS into segments
  that correspond to logical units in the programs.
  Use special words (descriptors) to represent
  access rights for these segments.
• Controlled-Process Creator. How to define the
  rights to be given to a new process? Define
  rights as part of its creation. Give it a
  predefined subset of its parents rights.
• File access control. How do you control access to
  files in an operating system? Apply the
  Authorization pattern to describe access to files
  by subjects. The protection object is now a file
  component that may be a directory or a file.
• Controlled Execution Environment. How to define
  an execution environment for processes? Attach to
  each process a set of descriptors that represent
  the rights of the process. Use the Reference
  Monitor to enforce access.

30
Patterns for OSs
31
Latest set (PLoP06)

• Secure Process /Thread Fer06c. How do we make
  sure that a process does not interfere with other
  processes or misuse shared resources?
• Virtual Address Space Structure Selection
  Fer06c. How do we select the virtual address
  space for OSs that have special security needs?
  Some systems emphasize isolation, others
  information sharing, others good performance.
• Administrator Hierarchy Fer06c. Many attacks
  come from the unlimited power of administrators.
  How do we limit the power of administrators?
  Define a hierarchy of system administrators with
  rights controlled using a Role-Based Access
  Control (RBAC) model and assign rights according
  to their functions.

32
Patterns for firewalls

• Packet Filter Firewall. Filter incoming and
  outgoing network traffic in a computer system
  based on network addresses.
• Application Proxy Firewall . Inspect (and filter)
  incoming and outgoing network traffic based on
  the type of application they are accessing.
• Stateful firewall Filter incoming and outgoing
  network traffic in a computer system based on
  network addresses and the state information
  derived from past communications.

33
Authentication patterns

• Authenticator. How to verify that a subject is
  who it says it is? Use a single point of access
  to receive the interactions of a subject with the
  system and apply a protocol to verify the
  identity of the subject.
• Remote Authenticator /Authorizer. Provide
  facilities for authentication and authorization
  when accessing shared resources in a
  loosely-coupled distributed system.
• Credential. Provide portable menas of recording
  authentication and authorization information for
  use in distributed systems

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

35
Patterns for web services
36
(No Transcript)
37
(No Transcript)
38
How to apply the patterns?

• A good catalog and classifications of patterns
  help a designer select among alternatives.
• However, there is still the problem of when to
  apply a pattern during system development
• We need some systematic approach to decide when
  we need to use a pattern, a secure systems
  methodology

39
Security along the life cycle
40
A methodology for secure systems design I

• Domain analysis stage A business model is
  defined. Legacy systems are identified and their
  security implications analyzed. Domain and
  regulatory constraints are identified. Policies
  must be defined up front, in this phase.
• Requirements stage Use cases define the required
  interactions with the system. Applying the
  principle that security must start from the
  highest levels, it makes sense to relate attacks
  to use cases. We study each action within a use
  case and see which threats are possible. We then
  determine which policies would stop these
  attacks. From the use cases we can also determine
  the needed rights for each actor and thus apply a
  need-to-know policy. 

41
Secure systems methodology II

• Analysis stage Analysis patterns can be used to
  build the conceptual model. Security patterns
  describe security models or mechanisms. We can
  build a conceptual model where repeated
  applications of a security model pattern realize
  the rights determined from use cases.
• Design stage When we have the possible attacks
  to a system, design mechanisms are selected to
  stop these attacks. User interfaces should
  correspond to use cases and may be used to
  enforce the authorizations defined in the
  analysis stage. Secure interfaces enforce
  authorizations when users interact with the
  system. Components can be secured by using
  authorization rules for components. Distribution
  provides another dimension where security
  restrictions can be applied.

42
Security methodology III

• Implementation stage This stage requires
  reflecting in the code the security rules defined
  in the design stage. Because these rules are
  expressed as classes, associations, and
  constraints, they can be implemented as classes
  in object-oriented languages. In this stage we
  can also select specific security packages or
  COTS, e.g., a firewall product, a cryptographic
  package. Some of the patterns identified earlier
  in the cycle can be replaced by COTS (these can
  be tested to see if they include a similar
  pattern).

43
Other uses of patterns

• In addition to their value for designing new
  systems, patterns are also useful when selecting
  a system or an application. Possible candidates
  can be compared according to having or not a
  pattern embodying a given function or capability.
  For example, the presence of a Role-Based Control
  pattern in a system indicates its support for
  specific features of this model, e.g. sessions or
  groups.
• Finally, we have used patterns for teaching and
  explaining security aspects. The abstraction
  present in patterns eliminates the effect of
  implementation details and is very valuable to
  make a complex structure more understandable.

44
Conclusions I

• We considered the use of security patterns and
  looked in detail at one of them.
• We classified security patterns using
  architectural levels and surveyed some patterns
  previously developed by us and others
• We considered a methodology to apply security
  patterns to build secure systems
• Patterns are also valuable for evaluating
  existing systems and for teaching security
  concepts

45
Conclusions II

• Patterns cannot prevent attacks that happen
  through code flaws but can make their effect much
  less harmful
• Can be made more formal OCL
• Security patterns are now accepted by many
  companies, Microsoft, Sun, and IBM have books,
  papers, and web pages on this subject. A general
  page for security patterns www.security-patterns.
  org

46
Future work

• Completing our methodology and the development of
  further patterns.
• Use of the patterns in Model Driven Architecture
  (MDA), in general, and as part of our methodology
• Exploring other types of security-related
  patterns attack patterns