1

ARCHITECTING SECURESOFTWARE SYSTEMS

Boshra Ardallani

Paria Rakhshani

Elahe Golezardi

Purya Aliabadi

2

OUTLINE Building Secured Systems Security Requirements Analysis Threat Modeling Security Design Security Coding Safe Programming Security Review Generating the Executable Security Testing Secured Deployment Security Remediation Security Documentation Security Response Planning Safety-Critical Systems

3

BUILDING SECURED SYSTEM

A war against hackers or adversaries The attacker is not visible Build systems that are secured and can

defend any attack Computers are connected through a network how to architect security in software

4

SECURITY DEVELOPMENT LIFECYCLE

use to embed security at the grass-root level starts with defining system objectives

5

SECURITY REQUIREMENTS ANALYSIS LIFECYCLE

6

SECURITY OBJECTIVES

application’s security objectives categories: Identity Financial Proprietary and sensitive data Property and life Privacy and regulatory Availability guarantees Regulatory

7

FUNCTIONAL VERSUS NONFUNCTIONAL REQUIREMENTS

Functional requirement: A system or software requirement that specifies

a function that a system/software system or system/software component must be capable of performing

Nonfunctional requirement: A software requirement that describes not what

the software will do but how the software will do it.

8

USE CASE

Use case is used in software engineering to capture functional requirements

Use cases capture “who” (actor) does “what” (interaction) with the system, for what “purpose” (goal), without dealing with the system implementation details.

Use case is now included within Unified Modeling Language (UML)

Use case can be linked with three types of relationships: Include Extends Generalization

9

MISUSE CASE

Misuse case is used in software engineering to capture nonfunctional requirements.

A misuse case is a special kind of use case, describing behavior that the system/entity owner does not want to occur.

A “misuse case” is the inverse of a use case, a misactor is the inverse of an actor.

10

CO REPRESENTING USE AND MISUSE CASES To represent a system behavior, it should include

both functional and nonfunctional requirements together.

To represent use cases and misuse cases together, they need to be differentiated.

11

DEFINING SECURITY REQUIREMENTS

This is achieved in five steps:1. First concentrate on the functional

requirements through normal actors and the main use cases requested by these actors.

2. look at security-related misuse cases.3. investigate the potential relations between use

cases and misuse cases.4. Look at security-related nonfunctional

requirements as functional requirements.5. Continue with the preceding four steps with

more and more refinements and detailed requirements documentation.

12

THREAT MODELING

use threat modeling to determine security threats.

Threat modeling is a process that helps you to identify, analyze, document, and possibly rate the system’s vulnerabilities.

Threat modeling centers around the following essential components: Assets. This is the object that we need to protect. Vulnerabilities. These are weaknesses in the system. Threats. Possible occurrence of an undesirable event. Exploits (or attacks). When a threat becomes reality,

it is called attack. Countermeasures. These are measures to eliminate

vulnerabilities or reduce the attack surface.

13

THREAT MODELING (CONT.) Some techniques that are proposed to model

the threat are: STRIDE Attack tree DREAD Attack surface

14

STRIDE

STRIDE is a methodology for identifying possible threats.

It is used by Microsoft for threat modeling of their systems.

The STRIDE acronym is formed from the first letter of each of the following categories: Spoofing identity Tampering with data Repudiation Information disclosure DoS Elevation of privilege.

15

ATTACK TREE Attack tree is a tool to evaluate the system security

based on various threats. The root of a tree represents a security event that can

potentially damage an asset. Each path through an attack tree represents a unique

attack. decompose a node of an attack tree through either an

AND-decomposition or an OR-decomposition.

16

DREAD

DREAD is another tool to determine possible threats and their impact.

is also used directly to mitigate the risks. is an average of all five categories:

17

ATTACK SURFACE

that part of the program can be a target of attack that is accessible to an attacker.

the attempt is always to analyze the attack surface and reduce it.

focuses on reducing the area of the code accessible to unauthorized users.

18

PUTTING IT ALL TOGETHER Step 1. identify system objectives. Step 2. Analyze functional requirements of the system using

use-case and UML tools. Step 3. List the system’s security requirements and security

objectives. Step 4. List the assets the system is handling and risk

associated with them. Step 5. Use the misuse case to analyze security risks and

interactions between different tasks and their relationship. Step 6. Use the attack tree to breakdown misuse cases to

understand what are the AND and the OR components in the threat path.

Step 7. Use the DREAD tool to rate these threats. Step 8. Analyze the attack surface and consider reducing the

attack surface. Step 9. Progressively refine the requirements by decomposition

of the requirements.

19

PATTERNS AND ANTIPATTERNS

Design pattern: A design pattern is a formal way of documenting

successful solutions to problems. Design antipattern:

design patterns help to address commonly occurring problems that appear initially to be beneficial, they sometimes result in bad consequences that outweigh the apparent advantages. This is called antipatterns.

20

ATTACK PATTERNS

An attack pattern characterizes an individual attack type that an adversary may use for some malicious intension.

Each attack pattern contains the following sections: Pattern name and classification The overall goal of the attack specified by the

pattern A list of preconditions for its use The steps for carrying out the attack A list of post conditions that are true if the attack is

successful A list of suggestions that can be used to counter

this attack

21

SECURITY DESIGN PATTERNS

Single access point Checkpoint Roles Session Full view with errors Limited view Secure access layer Least privilege Journaling Exit gracefully