Security engineering applies established engineering principles to implement system security concepts in practical and effective ways. It focuses on addressing specific challenges, requirements, or threats through well-defined methodologies. Recognized as a specialized branch of systems engineering, security engineering is endorsed by both the International Council on Systems Engineering (INCOSE) and the National Institute of Standards and Technology (NIST).

Security Engineering Standards

Industry-accepted standards and frameworks for security engineering include the following:

INCOSE Systems Engineering Handbook

INCOSE, a nonprofit organization, promotes the principles and practices essential for successful system development. Its Systems Engineering Handbook outlines engineering methodologies with a focus on affordability, performance, and structured project management approaches.

NIST SP800-160: Systems Security Engineering

This publication provides guidance on engineering-driven measures to create secure and resilient systems, covering components, services, and dependencies. It integrates international standards from ISO, IEC, and IEEE with security engineering techniques to enhance system and software security.

ISO/IEC 15026: Systems and Software Engineering

This standard series offers guidelines on system and software security, assurance, and integrity, ensuring alignment with established engineering practices.

ISO/IEC/IEEE 15288: Systems and Software Engineering

This standard defines the system engineering life cycle, evolving from earlier models found in U.S. military specifications and standards.

Security Engineering Processes

Engineering as a discipline inherently incorporates change management and configuration control. Regardless of the engineering domain, processes revolve around managing system information while ensuring security, reliability, and performance. The degree of formality in change management is dictated by mission or business requirements.

Security engineering follows a structured approach defined by NIST SP800-160, aligning with the INCOSE Systems Engineering Handbook and ISO-based standards.

Technical Processes

  • Business and Mission Analysis – Identifies the scope, underlying factors, and potential security risks associated with business or mission-related problems or opportunities.
  • Stakeholder Needs and Requirements Definition – Defines security requirements, including protection capabilities, security constraints, and essential security characteristics.
  • System Requirements Definition – Translates stakeholder security requirements into technical system requirements for implementation.
  • Architecture Definition – Develops security-oriented architectural models to evaluate and select suitable system security frameworks.
  • Design Definition – Outlines security-related elements within the system’s architecture to guide secure implementation.
  • System Analysis – Provides security-specific insights to support technical decision-making and risk assessment.
  • Implementation – Integrates security requirements into all system components and their operations.
  • Integration – Ensures security measures are effectively incorporated during system assembly, aligning with security specifications.
  • Verification – Validates that security requirements and characteristics are met, with an appropriate level of assurance.

Technical Management Processes

  • Project Planning – Develops security-focused project plans, defining tasks, deliverables, and necessary resources.
  • Project Assessment and Control – Monitors security-related progress and identifies deviations requiring corrective actions.
  • Decision Management – Analyzes and evaluates security-based alternatives to recommend the most effective course of action.
  • Risk Management – Identifies, assesses, mitigates, and tracks security risks throughout the project lifecycle.
  • Configuration Management – Ensures security considerations are included in managing system elements and configurations.
  • Information Management – Incorporates security concerns into information handling and documentation processes.
  • Measurement – Collects and analyzes security data to support risk management and system assurance.
  • Quality Assurance – Conducts security-focused quality checks to maintain confidence in the system’s security performance.

Enabling Processes

  • Life Cycle Model Management – Establishes security requirements for system policies, procedures, and models to ensure trustworthiness.
  • Infrastructure Management – Ensures adequate security infrastructure and supporting services are in place.
  • Portfolio Management – Integrates security considerations into organizational project management and investment decisions.
  • Human Resources Management – Defines qualifications and training requirements for personnel responsible for security processes.
  • Quality Management – Establishes security quality objectives and ensures compliance.
  • Knowledge Management – Collects and maintains security knowledge to facilitate knowledge reuse and improvement.

Agreement Processes

  • Acquisition Process – Ensures that acquired products and services align with security requirements and risk considerations.
  • Supply Process – Ensures security functions and protections are maintained in supplied products and services per contractual requirements.

Security Policies, Models, and Architecture

The development of secure systems typically begins with defining business or mission needs and constraints, often articulated through security policies. These policies shape security requirements and establish constraints on system design, operation, and usage.

Security models, based on prior experience and best practices, use methodologies such as equations, flow diagrams, or operational sequences to guide system development. Engineers apply these models iteratively to design secure system architectures and their interactions with external environments.

Security Policies define acceptable security levels by balancing factors such as operational feasibility, cost, and risk impact. These policies impose behavioral and technical constraints on system usage and development, ensuring security measures effectively mitigate potential threats.

The ISC2 ISSAP course provides an in-depth exploration of security architecture methodologies, offering valuable insights for security professionals.

Security Models

Over time, different security models have been developed, each focusing on specific security aspects. These models typically involve subjects (processes performing actions) and objects (data, hardware, software, or even people). Some key security models include:

State Machine Model: Defines a system’s initial and final states, ensuring security policies remain intact. For example, verifying that a copied file matches the original using a secure hash ensures no unintended changes occurred.

Information Flow Model: Expands on the state machine model by tracking how information moves within a system. It enforces rules on how subjects can access and modify objects based on their privileges.

Noninterference Model: Prevents interactions between different security levels. Each access attempt is independent, ensuring sensitive operations do not reveal details about security decisions. For instance, a login system should not expose entered credentials during authentication.

The best way to understand the security models below is to simply memorize them, since most of us have never worked with them, and will never use them after the exam.  They are also not intuitive and the CBK does not teach us how the three models above tie into the models below – this is something we’ll have to wrap our heads around later. 

Bell-Lapadula (BLP) – for this model, you simply need to memorize the phrase “no read up, no write down”.  Using labels, it does not allow the viewing of objects that are considered of higher security, and also it does not allow modification of objects that are of lower security.  The focus of this model is on confidentiality. Data hiding might be an example of this, where processes operating at one level are prevented from seeing data at another level.

There are two properties in this model:

  • Simple security property (no read up)
  • Star security property (no write down)
  • Strong star property only write to objects at the same security classification level as the subject, or, a lateral write, so there is no write down or write up, only a “write sideways”

Biba is a model that focuses on integrity, and is the exact opposite of BLP, thus “No write up, no read down.”  This also has two properties:

  • Simple integrity property (no read down)
  • Star integrity property (no write up)

Notice the commonality between the models and terms.  The key to memorizing the properties is this: 

  • Simple = Read
  • *Star = Write

You can also remember that the “star” indicates “write” because in computing when you change/write something, a star typically appears on the file to indicate that you have unsaved changes.  

Be aware of the invocation property as well, which is the third property of Biba that states that subjects cannot send logical service requests to an object of higher integrity.

So if we were to say “simple security” this would mean no read up, because simple = read.  The “star security” property would mean no write down, because star = write, and you would know this refers to the BLP model.

If we are to say “Simple integrity property” which model would this refer to?

That’s right, Biba.

Simple means “read”, and integrity refers to the Biba model, thus a “simple integrity” property means no read down, indicating the Biba model.  Consequently a Star integrity property would mean no write up

BreWer Nash has a “W” in it, and is sometimes referred to as the Chinese Wall model, because it prevents users from accessing one another’s files, in other words it prevents conflict of interest.

Clark-Wilson has an “eye” (i) in it, and conveniently this model also is concerned with integrity.

Notice the letters matching, so repeat the following:

  • Brewer – the W is for wall
  • Wilson – the i is for integrity

You can learn about the other models (Graham Denning, Harrison, Ruzzo, Ullman) in the thicker books, which also delve deeper into the functioning of these models.