Secure Systems Research Group - FAU Security-related pattern varieties Eduardo B. Fernandez Dept. of...

Secure Systems Research Group - FAU

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

[email protected]


Outline

• Introduction and motivation• Security patterns• Variants: Secure Semantic Analysis Patterns,

privacy patterns, physical access patterns• Attack patterns• Decision trees• Dependability patterns• Conclusions


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


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


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.


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


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


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.


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.


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.

:


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.


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.


Structure of the solution

address addressPFFirewall

ExplicitRule DefaultRule

ExternalHost LocalHost

Rule

in/out

{ordered}*

1

1 1**requestService requestService

RuleBase

addRuledeleteRulemodifyRulereorderRules


Filtering a client’s request

«actor»

:ExtHost:Firewall :RuleBase :Rule :LocalHost

requestService( )

requestService( )

acceptaccept

checkRule

requestService( )


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.

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


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


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.


Authorization

Subject ProtectionObject

Right

idname

idname

accessType

checkRights

* *isAuthorizedFor


Reference monitor pattern

SubjectReferenceMonitor

Set_of_Authorization_

Rules

prot_Objectaccess_type

Request

ConcreteReferenceMonitor

Authorization

** * *

*

makesRequestTo exists


Patterns for access control

Session-basedRBAC

BasicAuthorization

authorizer

Session-basedABAC

DelegatableAuthorization

BasicRBAC

Content-basedAuthorization

ExplicitlyGranted

Authorization

ABAC

s=Role

s or o=attribute values

session

condition

session

CopyFlag

Access Sessionuses uses


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.


Patterns for web services


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


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.


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)


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.


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.


As plaintiff As defendant

Bill client

Client

Other

Opponent Lawyer

Secretary

<<extend>><<include>>

Handle LegalCase

Research CaseKeep track

of costs

Basic use cases


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.


Scheduling

activitydate/time

Client

nameaddress

Case

numberstartDateendDate

Cost

dateamount

Lawyer

specialtyrank

Secretary

rank

Employee

nameIDsalary

Law Firm

nameaddress

Outcome

date

ExternalPeople

nameaddress

CaseDoc

numberstartDateendDate

Contract

Precedent

Brief

Deposition

1

1

1

1

1

1

1*

*

*

*

*

*

*

**

*

*

*

* {subset}

{subset}

CanSchedule WorksFor

AssignedTo

KeepsTrackOf

ResponsibleFor

AssignedTo

For

Solution


Secure structureThe 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


Lawyer

Responsible AssignedTo

schedulestartwriteOpinioncloseopenContract

RLawyerRights

ALawyerRights

writeDepositionreadDeposition

ClientRights

Client readDocscreateDocs

Secretary

SecRights

Case

writeOpinionchargeTimewriteBrief

Authenticator

Authenticator

CaseLog

Secure class diagram


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


SAP

t1

Sec Pattern 1

Sec Pattern 2

t2 ti

Policy 2

Policy 1 Policy i

Sec Pattern 2

SSAP

. . .

. . .

threat 1 threat 2 threat i

SAPs and security patterns


UCs(Workflows)

Security annotations in each UC

Threats

user

legislation

institution

Policies

Secure Analysis Model

SAPs

Secure SAPs

Use of SSAPs


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


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.


ScopedData

ServiceProvider

Scope

User

Requests

RequestsProvides

Provides

References

Scoped data class diagram


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.


New types of patterns

• Attack patterns —Combine security and forensic aspects

• Architectural decision trees---Record architectural decisions in a complex system


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.


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.


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.


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.


DoS attacks in H323

*

AnalogPhone

Firewall

Gateway

PBX

***

*

1

connect

Figure 2 Class Diagram for DoS attacks in H.323

Gatekeeper

1

*

* PSTN-to-PSTN

PSTN*

connect

*

Router *

* IP-to-IP

Internet

*

connect

Attack ControlMechanism*

Layer 2 Switch

1

1

filters

manages

IP-PBX1

TerminalDevice

connect

procecesscall

*

*

1

1

Zombie

*


<<actor>>aCallee:

<<actor>>aCaller:

I:IP-PBX :AttackControlMechanismS:Layer2/3switch

Figure 3 Sequence diagram for a DoS attack in H.323

S.dial(Callee.setup())

I.connect(Callee.setup())

notify(cannotProcessCall)

notify(busyTone)

I.message(attackMessage())

XCallee.setup()

notify(cannotProcessCall)

I.message(attackMessage())


:A

forA

A

C

b1:B

forB

D

f3:ForB f4:ForB

b2:B

D

f1:ForA f2:forB

B

* *

*

*

**1

1

2. b( )

3. c( )

4. d( )

5. e( ) 6. f( ) 7. g( )

1: a( )

8: h( )

Attack dynamics

(collaboration diagram)

Forensic objects

Forensic classes

System structure

with forensics


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


Conceptual M odel

(Security Patterns)

Components

J2EE .NET

Distribution

Distributed Objects (Secure Broker)

SOA

Fixed

W ireless/

M obile

(adapted W S standards)

Combined

Persistence

JDBC AD O

3-tier

(Secure 3-tier)

4-tier

Architectural decision tree


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


Security decisions in the architectural decision tree

Workflow or Class Model of lawfirm

Secure Workflow

Secure Class Model

J2EE Component Model

ACL

Distribution Model

Three-tierarchitecture

Remote Objects SOA

Secure BPEL

Web ServicesRMI/J2EERMI Sec

RMI/J2EEXACML

WS Policy

Three-tier architecture+J2EE+RMI+SOA

Secure 3-tier Secure classmodel


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.


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


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


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

Secure Systems Research Group - FAU Security-related pattern varieties Eduardo B. Fernandez Dept. of...

Documents

Transcript of Secure Systems Research Group - FAU Security-related pattern varieties Eduardo B. Fernandez Dept. of...