Architecting secure software systems Boshra Ardallani Paria Rakhshani Elahe Golezardi Purya Aliabadi

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

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

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

Security requirements analysis lifecycle

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

functional versus nonfunctional requirements 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.

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

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.

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.

defining security requirements This is achieved in five steps: First concentrate on the functional requirements through normal actors and the main use cases requested by these actors. look at security-related misuse cases. investigate the potential relations between use cases and misuse cases. Look at security-related nonfunctional requirements as functional requirements. Continue with the preceding four steps with more and more refinements and detailed requirements documentation.

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.

threat modeling (cont.) Some techniques that are proposed to model the threat are: STRIDE Attack tree DREAD Attack surface

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.

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.

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:

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.

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.

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.

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

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