Security Requirements: from Threats to Security Patterns

PhD Thesis ProposalFabricio Braz

04/11/08

1

Outline• Introduction– Problem Statement– Security Patterns & Security– Security Requirements

• Proposed Research– General Goal– Specific Goals– Overview– Hypotheses– Contributions– Negative Scope

2

Problem Statement (1)

• Complex software applications– medical, financial, legal, military, infrastructure…– distributed, web, COTS, wireless, multiplataform– standard/regulation compliance (HIPAA, SOx, Fisma, CC,

PCI)– vital and sensitive information handling – variety of security policies to accommodate different

system requirements while protecting against a variety of threats

A systematic approach to build secure app is requiredA systematic approach to build secure app is required

3

Problem Statement (2)

• Increasing app with flaws and incidents reported [Cert-CC]

• Operational System x Application Security• Previous response– Patch + Blame users

• Approaches to deal with it– Inspect the final release (Pentest) – Security in, from the beginning [McG06]

4

Problem Statement (3)

• Innocuous for well complex systems– Purely formal methods

• Implementation does not reflect proved security models– Practical ad hoc

• Procedural coding lacks of conceptual approach and abstraction

• Insiders as a big source of threats

A comprehensive approach is necessary to deal A comprehensive approach is necessary to deal with security thoroughly the SDLC with security thoroughly the SDLC

5

Software Patterns & Security (1)

6

• Security– Conf., Avail., Int., Account.

• Attacks– Monetary, political, vandalize, …

• Responses– Authe., A.C. & Autho., Logging, Crypto., Int. Dect.

Software Patterns & Security (2)

7

• Patterns role in security dev– Do not repeat the same error– Well known solution to common problem in a

context– Ideally every sec. problem would have its sec.

pattern– The security patterns has increased (hundreds)

enabling their use in the SDLC• Now the challenge is to find the appropriate one for a

specific context [Fer08, Haf07]

Software Patterns & Security (3)

8

Security Requirements (1)

• Definition– system security policies that constraints FR [Red07]– sometimes the security is more than the constraint

itself, it is the good to be delivered (HIPAA)– provides information about the desired level of

security for a system to fit its business goals • Lightweight <-> Heavyweight– How to determine the appropriate system security

level• Mitigate / stop the potential attacks or threats [Goe06,

Tøn08, hip]

9

Security Requirements (2)

• Approaches– Misuse Case• Deals with security requirements as use cases that

defend against attack scenarios described by misuse cases [Ale03, Sin05]

– SQUARE• A comprehensive methodology without a specific

technique to elicit security requirements [Mea05]. – Problem Frames• Not so commonly used as UML (how to convince the

developer?)

10

Security Requirements (3)

11

General Goal

This thesis attempt to improve the security of new intensive software systems with a

methodology that focuses on the integration between the requirements and design development phases through a smooth

transformation from threats to security patterns applied to design artifacts.

12

Specific Goals• Survey security requirements approaches• Refine the analysis of misuse activities in order to be

more systematic and to generate more precise threats• Develop a model to determine from the elicited

threats a set of policies that can stop or mitigate them• Develop a model to map security policies to security

patterns that realize them• Develop a model to incorporate the appropriate

security patterns into the system design• Develop a tool that automates part of the analysis and

transformation

13

Overview (1)

14

Threats Policies

The customer provides false information and opens spurious account

Mutual authentication. Every interaction across system nodes is authenticated

The manager creates a spurious account with the customer’s information

Logging. Since the manager is using his legitimate rights we can only log his actions for auditing at a later time

The manager creates a spurious authorization card to access the account.

Separation of administration from use of data. For example, a manager can create accounts but should have no rights to withdraw or deposit money in the account.

An attacker tries to prevent the customers access to their accounts

Protection against denial of service. We need some redundancy in the system to increase its availability.

T1

T2

T3

Tipk

p4

p2

p1

Pm

P3

P2

P1r1

r2

r3

r4

rj

threat response realizationpolicy sec. pattern

R1

R2

R3

R4

Rl

P4

p3

Overview (2)

Hypotheses1. A comprehensive list of precise threats can be generated

semi-automatically from ordinary UML activity diagrams.2. A set of appropriate security policies (security

requirements) can be inferred from a set of precise threats.

3. A set of appropriate security patterns can be inferred from the security policies.

4. The application static diagram in the architectural level can be semi-automatically enhanced from the security perspective, through threat analysis and security patterns knowledge. We first express use cases as activity diagrams.

16

1 . A comprehensive list of precise threats can be generated semi-automatically from ordinary UML activity diagrams

• How to recognize the activity diagram elements to be analyzed?– MOF / XMI

• What are the syntax and semantic rules for precisely describing threats?– Ontology, First Order Logic, OCL

• How the Misuse Activities should help?– Security Attributes Subverted + Source of Threat + Type of Misuse

• What is the role of the following elements, when precisely creating the threat? (It may require its own syntax rule, to make the analysis easier.)– Activity names, Arrows, forks, joins, merges, Entry/exit points, Flow objects, Decisions, Swim

lanes (source of threats?)• How about the false positives (negatives) generated?

– Should the user have a way to refine this analysis according to domain?• How to validate that this threat list is comprehensive?

– Using examples? (Checking that they cover all activities.• What’s the expected outcome?

– Parameterized threat list• We can do this manually now [Bra08]

17

2. A set of appropriate security policies (security requirements) can be inferred from a set of precise threats.

• How to define of a comprehensive policy list?• We need to elucidate the terminology (Policy,

Security Requirement, Hierarchical Policies, and Security Goal).

• We need to create a mapping between the threat syntax and the appropriate policy(ies).

18

3. A set of appropriate security patterns can be inferred from the security policies• How can we reduce the ambiguity from the patterns

elements (problem, solution, forces, and consequences) in order to enable inference, such as dependency, association, etc?

• What else has to be taken into consideration in order to refine the pattern search?– Environment.– Problem, forces (lists the attacks the pattern can handle)

• How may we validate that this inference is appropriate?– Are all the threats mitigated/stopped?

• What else might help in the patterns inference process?

19

4. The application static diagram in the architectural level canbe semi-automatically enhanced from the security perspective,

through threat analysis and security patterns knowledge

• How can we recognize the class diagram elements?– MOF/XMI

• How can we reason about the best place to tie the Pattern Static Structure into the Analysis Class Diagram? (May we use the flow objects from the activity diagram?)– Analyze if the class is an asset, whether it can be accessed remotely, whether

it receives/sends info. to other classes.• What if the class diagram has already been security enhanced? Should we

care about security replication?• How to validate the whole transformation (from activity diagram to

security enhanced class diagram)?– Can we handle all threats?

• What’s the expected outcome? What is the expected transformation to be employed in the class diagram?

• How can we trace back to the flow object, since patterns have a relation NxN to threats

20

Contributions• A systematic approach:

– deals with security from the beginning – realize the elicited security requirements by security patterns on

design artifacts• Contributes to reduce architectural flaws• Some activities from the approach will be semi-automated,

which gives scalability, mandatory when dealing with large systems. Automation is necessary for large systems to reduce cost.

• Performing this approach might indicate the need of security pattern(s) refactoring or documentation in the worst case (cases in which no security pattern can realize a particular security police).

21

Negative Scope

• Security Bugs (implementation failures) [How06, Che07]

• Validation that the source code that • How does the environment affect the security

concerns? How to demonstrate that its operation is secure?

22

Discussion

• I would love to have a copy of your written comments.

• We are recruiting volunteers!– email to: fabricio.braz@gmail.com

23

THANKS’

24