Mike Chapple - (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide

Procedures are the final element of the formalized security policy structure. A procedure or standard operating procedure (SOP) is a detailed, step-by-step how-to document that describes the exact actions necessary to implement a specific security mechanism, control, or solution. A procedure could discuss the entire system deployment operation or focus on a single product or aspect. They must be updated as the hardware and software of a system evolve. The purpose of a procedure is to ensure the integrity of business processes through standardization and consistency of results.

At the top of the formalization security policy documentation structure there are fewer documents because they contain general broad discussions of overview and goals. There are more documents further down the formalization structure (in other words, guidelines and procedures) because they contain details specific to a limited number of systems, networks, divisions, and areas.

Keeping these documents as separate entities provides these benefits:

Not all users need to know the security standards, baselines, guidelines, and procedures for all security classification levels.

When changes occur, it is easier to update and redistribute only the affected material rather than updating a monolithic policy and redistributing it throughout the organization.

Many organizations struggle just to define the foundational parameters of their security, much less detail every single aspect of their day-to-day activities. However, in theory, a detailed and complete security policy supports real-world security in a directed, efficient, and specific manner. Once the security policy documentation is reasonably complete, it can be used to guide decisions, train new users, respond to problems, and predict trends for future expansion.

Threat modeling is the security process where potential threats are identified, categorized, and analyzed. Threat modeling can be performed as a proactive measure during design and development or as a reactive measure once a product has been deployed. In either case, the process identifies the potential harm, the probability of occurrence, the priority of concern, and the means to eradicate or reduce the threat.

Threat modeling isn't meant to be a single event. Instead, it's meant to be initiated early in the design process of a system and continue throughout its lifecycle. For example, Microsoft uses a Security Development Lifecycle (SDL) ( www.microsoft.com/en-us/securityengineering/sdl) with the motto of “Secure by Design, Secure by Default, Secure in Deployment and Communication” (also known as SD3+C). It has two goals in mind with this process:

To reduce the number of security-related design and coding defects

To reduce the severity of any remaining defects

A defensive approach to threat modeling takes place during the early stages of systems development, specifically during initial design and specifications establishment. This method is based on predicting threats and designing in specific defenses during the coding and crafting process. In most cases, integrated security solutions are more cost-effective and more successful than those shoehorned in later. While not a formal term, this concept could be considered a proactive approach to threat management.

Unfortunately, not all threats can be predicted during the design phase, so a reactive approach to threat management is still needed to address unforeseen issues. This concept is often call threat hunting or may be referred to as an adversarial approach .

An adversarial approach to threat modeling takes place after a product has been created and deployed. This deployment could be in a test or laboratory environment or to the general marketplace. This technique of threat hunting is the core concept behind ethical hacking, penetration testing, source code review, and fuzz testing. Although these processes are often useful in finding flaws and threats, they unfortunately result in additional effort in coding to add in new countermeasures, typically released as patches. This results in less effective security improvements (over defensive threat modeling) at the cost of potentially reducing functionality and user-friendliness.

Fuzz testing is a specialized dynamic testing technique that provides many different types of input to software to stress its limits and find previously undetected flaws. See Chapter 15for more on fuzz testing.

There's an almost infinite possibility of threats, so it's important to use a structured approach to accurately identify relevant threats. For example, some organizations use one or more of the following three approaches:

Focused on Assets This method uses asset valuation results and attempts to identify threats to the valuable assets.

Focused on Attackers Some organizations are able to identify potential attackers and can identify the threats they represent based on the attacker's motivations, goals, or tactics, techniques, and procedures (TTPs).

Focused on Software If an organization develops software, it can consider potential threats against the software.

It's common to pair threats with vulnerabilities to identify threats that can exploit assets and represent significant risks to the organization. An ultimate goal of threat modeling is to prioritize the potential threats against an organization's valuable assets.

When attempting to inventory and categorize threats, it is often helpful to use a guide or reference. Microsoft developed a threat categorization scheme known as the STRIDE threat model. STRIDE is an acronym standing for the following:

Spoofing: An attack with the goal of gaining access to a target system through the use of a falsified identity. When an attacker spoofs their identity as a valid or authorized entity, they are often able to bypass filters and blockades against unauthorized access.

Tampering: Any action resulting in unauthorized changes or manipulation of data, whether in transit or in storage.

Repudiation: The ability of a user or attacker to deny having performed an action or activity by maintaining plausible deniability. Repudiation attacks can also result in innocent third parties being blamed for security violations.

Information disclosure: The revelation or distribution of private, confidential, or controlled information to external or unauthorized entities.

Denial of service (DoS): An attack that attempts to prevent authorized use of a resource. This can be done through flaw exploitation, connection overloading, or traffic flooding.

Elevation of privilege: An attack where a limited user account is transformed into an account with greater privileges, powers, and access.

Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage threat modeling methodology. PASTA is a risk-centric approach that aims at selecting or developing countermeasures in relation to the value of the assets to be protected. The following are the seven steps of PASTA:

Stage I: Definition of the Objectives (DO) for the Analysis of Risks

Stage II: Definition of the Technical Scope (DTS)

Stage III: Application Decomposition and Analysis (ADA)

Stage IV: Threat Analysis (TA)

Stage V: Weakness and Vulnerability Analysis (WVA)

Stage VI: Attack Modeling & Simulation (AMS)

Stage VII: Risk Analysis & Management (RAM)

Each stage of PASTA has a specific list of objectives to achieve and deliverables to produce in order to complete the stage. For more information on PASTA, please see Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis (Wiley, 2015), by Tony UcedaVelez and Marco M. Morana.