Security Engineering (SE) Workbench

Key Concepts

"Security", "Security Engineering" and "Security Analysis" are key concepts for the SE-Workbench Project.

Security

The Security Glossary published by the Computer Security Resource Center of the National Institute of Standards and Technology (NIST) defines security as: a condition that results from the establishment and maintenance of protective measures that enable an organization to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the organization’s risk management approach.

Security Engineering

The US Government, National Institute of Standards and Technology (NIST) Special Publication 800-160 Version 1 explains Security Engineering as ”... a specialty engineering discipline of systems engineering that applies scientific, mathematical, engineering, and measurement principles, concepts, and methods to coordinate, orchestrate, and direct the activities of various security engineering specialties and other contributing engineering specialties to provide a fully integrated, system-level perspective of system security. Systems security engineering, when properly integrated into systems engineering, provides the needed complementary engineering capability that extends the notion of trustworthiness to deliver trustworthy secure systems.”

Security Analysis

The core skill employed by Security Engineers is Security Analysis. Security Analysis is an engineering process composed of: creating a problem statement, gathering data, testing and refining hypotheses, and drawing conclusions. The generic Security Analysis process is adapted to a given system, situation or problem. Applied Security Analysis may require a combination of system modeling, critical thinking, constraint analysis, problem determination, problem source identification and root cause analysis. The knowledge domain needed for Security Analysis may include: data communications, computer system architecture, software architecture, software systems, system testing planning and execution, fault analysis, reliability, data science, electromagnetics, signal processing, cryptology (cryptography and cryptanalysis) and more.

As with other forms of engineering analysis, Security Analysis requires a thought process and thought model.

Security Thinking

Security thought models may be expressed in terms of: security paradigms, security requirements, or security capabilities. Each of these expressions conveys the complexity of the field and practice of Security Engineering. The value of any of these expressions in facilitating the practice of Security Engineering varies.

Security Paradigms as a Thought Model

Security Paradigms are used to describe a system with a series of "qualities", or to convey the complexity of the subject matter in a somewhat relatable way. Examples of Security Paradigms are:

"CIA", i.e., Confidentiality, Integrity and Availability;
"6A's", i.e., Accountability, Assurance, Authentication, Access Control, Audit and Availability;
"5 Pillars +2", i.e., Confidentiality, Data and Information Integrity, Availability, Authenticity, Non-repudiation, Recoverability and Auditability;
"Trustworthiness", i.e., Safety, Security, Reliability, Dependability, Performance, Resilience and Survivability.
"Zero Trust", i.e., A collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.

Security Paradigms are often used in training sessions to provide memorable mnemonics, or as means to convey completeness of thought in a final report. The terms and definitions behind the mnemonics are conceptually rich, but they do not directly describe the function needed, how it should be be implemented or what measure of protection is delivered.

Security Capabilities as a Thought Model

Security Capabilities are used to describe common security features and functions.

The US Government, National Institute of Standards and Technology (NIST) has introduced a Cyber Security Framework that includes a catalog of core security capabilities to be incorporated in information systems and services. These core security capabilities have been extended with profiles for common platforms and computing functions in the CISA Security Capabilities Catalog from the Cybersecurity & Infrastructure Security Agency of US Department of Homeland Security.

Security Capabilities from the NIST Cybersecurity Framework and the capability profiles from CISA provide building blocks for organization and process. These efforts do not directly provide an engineering view of system security.

Security Requirements as a Thought Model

Security Requirements represent the output of an engineering-based Security Analysis process that produce actionable specifications.

Technical requirements for Computer Security were first documented in a paper written by the RAND Corporation in 1970 entitled, documented in Security Controls for Computer Systems. These concepts were further refined in a document entitled Department of Defense Trusted Computer System Evaluation Criteria also referred to as TCSEC, or The Orange Book. TCSEC was combined with a similar document from Europe called IT Security Criteria - Criteria for the Evaluation of the Trustworthiness of Information Technology (IT) Systems to form the basis of Common Criteria for Information Security Evaluation, or Common Criteria (CC). The Common Criteria specification forms the basis for ISO/IEC 15408-1:2009 Information technology — Security techniques — Evaluation criteria for IT security.

The Functional and Assurance requirements in Common Criteria are organized as requirements within a taxonomy of class, family and component. Security Functional Requirement classes cover: Audit, Communicaiton, Cryptography, Data Protection, Identification and Authentication, Management and Protection of Security Functions, Resilience and Trusted Paths. Security Assurance Requirement classes are: System Composition, System Configuration, Tests, Documentation, Lifecycle Support and Vulnerability Assessment.

The Functional and Assurance requirements in Common Criteria are rich in detail, but difficult to apply in practice without a structured design methodology.

Thought Models and the SE-workbench Project

Thought Models are useful in organizing and summarizing work, but, in most cases, do not support the rigor needed for "critical thinking" and "design processes" required for Security Engineering.

There is a need to improve the practice of Security Engineering across all practitioners and projects. Improvement can take many forms, to include: (a) consistency in security analysis methods, (b) commonality in security analysis tools, (c) broader availability of authoritative reference information, and (d) reducing or removing time and technical constraints related to security analysis.

The SE-workbench project will enable security engineers to consistently perform more complete security analysis over a range of projects.

top of the page

LAST UPDATE: 13 March 2022