SAP01

The system architecture is able to log and detect

Security architectural principle

It is required that detection and logging capabilities are designed into the product/system security architecture. In this way, continuous learning and improvement could be supported.

SAP02

Ensure the system is scalable

Security architectural principle

Scalability must be handled with great care.

Scalability is a key property of security architecture.

SAP03

Compartmentalize and de-couple whenever possible

Security architectural principle

To segment or modularize the system design, is sound advice.

Likewise, to reduce coupling to the minimum is a sensible goal.

SDP01

Vulnerable components are unacceptable

Security design principle

During security architecture design, it's required to either deprecate or refactor the vulnerable components of the product/system.

SDP02

Defense in depth

N/A

Security design principle

DEF01) Information security strategy integrating people, technology, and operations capabilities to establish variable barriers across multiple layers and missions of the organization.

DEF02) The application of multiple countermeasures in a layered or stepwise manner to achieve security objectives. The methodology involves layering heterogeneous security technologies in the common attack vectors to ensure the attacks missed by one technology are caught by another one.

Defense in depth is an approach in which a series of defensive mechanisms are layered in order to protect valuable data and information. This may be according to segmentation boundaries, etc. If one mechanism fails, the perpetrator must very soon face another security mechanism. This will make an attack more complex to conduct, and it will incur a greater cost in the attack. This will effectively make the attack less scalable and may even thwart the attack.

CNSSI 4009-2015

NIST SP 800-172

NIST SP 800-172A

NIST SP 800-30 Rev1 under Defense-in-Depth from CNSSI 4009

NIST SP 800-39 under Defense-in-Depth from CNSSI 4009

NIST SP 800-53 Rev.5 under defense in depth

NISTIR 7622 under Defense-in-Depth

NSTIR 8183 under Defense-in-depth from ISA/IEC 62443, ISO/IEC 62443 1-1

NSTIR 8183 Rev.1 under Defense-in-depth from ISA/IEC 62443

NSTIR 8183A Vol.2 under Defense-in-depth from ISO/IEC 62443 1-1

NSTIR 8183A Vol.3 under Defense-in-depth from ISO/IEC 62443 1-1

SDP03

Security coverage must be comprehensive and consistent

Security design principle

Security features of the product/system typically comprise identification and authentication schemes, security protection for data in transit and data at rest, and security schemes for authorization and access protection. These functionalities need to be there and be as consistent and comprehensive as possible.

SDP04

A threat modelling mindset must apply to security architecture design.

Security design principle

Threat modelling is an activity normally associated with the design phase of a system, including security architecture design.

SDP05

Zero Trust when considered a design security principle

ZT

Security design principle

Zero Trust is a security design principle and strategic approach that assumes no implicit trust is granted to assets or user accounts based solely on their physical or network location (i.e., local area networks vs. the internet) or based on asset ownership (enterprise or personally owned). Instead, Zero Trust requires verifying the identity of anything and everything trying to connect to its systems before granting access, regardless of where the request originates.

Under the Zero Trust model, security is not determined by the perimeter of the network but is instead based on strict identity verification, device health checks, least-privilege access, and micro-segmentation to minimize lateral movement within networks. Access to resources is granted on a need-to-know basis, and transactions are securely authenticated and authorized within a segmented environment.

DEF01 NIST SP 800-207 Zero trust provides 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.

2004 Jericho Forum introduces the principle of de-perimeterization.

2009 Google establishes Beyond Corp.

2010 Analyst John Kindervag introduces the "zero trust model" in a paper for Forrester Research.

August 2020 NIST delivers NIST SP 800-207.

Avril 2023 CISA delivers Zero Trust Maturity Model Version 2.0

SDP14 (Continuous Verification)

SDP07 (Principe of least-privilege):

SDP11 (Micro-segmentation)

SDP12 (MFASDP13 (Encrypt Data)

SDP06

Minimize the attack surface area

Security design principle

SDP07

The principle of least privilege

PoLP

Security design principle

DEF01 NIST 800-53 R5 AC-6 Control Statement: Employ the principle of least priviledge, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

It refers to the practice of limiting access rights for users (and systems) to the bare minimum necessary to perform their functions. This means that a user, program, or process should have only the privileges which are essential for its intended function, nothing more.

Implementing the least privilege principle helps to reduce the attack surface of a system by limiting access to critical systems and data to only those entities that require it to perform their duties. This can significantly mitigate the potential damage from various security threats, such as malware infections or the actions of malicious actors. By ensuring that users and systems operate using the minimal set of privileges, organizations can better protect sensitive information and critical infrastructure from unauthorized access and exploitation.

The principle of least privilege can be applied across various aspects of IT environments, including user permissions, software execution, system processes, and network access. It is often enforced through user account management processes, role-based access control (RBAC), access control lists (ACLs), and other security mechanisms designed to control access and privileges effectively.

The principle of least privilege (PoLP) is widely attributed to Jerome Saltzer and Michael D. Schroeder, who first articulated it in their seminal paper titled "The Protection of Information in Computer Systems," published in 1975 as part of the Proceedings of the IEEE, Vol. 63, No. 9. This paper laid out a set of design principles for securing information in computer systems, among which the principle of least privilege played a crucial role.

Saltzer and Schroeder were part of the research community at MIT's Project MAC, which later became the MIT Computer Science and Artificial Intelligence Laboratory (CSAIL). Their work was foundational in the field of computer security, influencing not only academic research but also the practical design and implementation of secure computing systems.

The principle of least privilege is one of several key principles they introduced, which also include concepts like economy of mechanism, fail-safe defaults, and separation of privilege. These principles have since become standard guidelines in the design and operation of secure systems.

While the formal articulation of the principle dates back to Saltzer and Schroeder's 1975 paper, the underlying concept of minimizing access or privilege to what is necessary for a particular purpose has been a common practice in security-sensitive environments even before its formalization in the context of computer security.

SDP05 (ZT)

SDP08

Separation of duties

Security design principle

SDP09

Security by Design is the most cost-effective approach to security

Security design principle

Security is vital for all critical infrastructures and should be designed into systems and operations from the beginning, rather than being applied after the systems have been implemented.

SDP10

Never trust, always verify

Security Design Principle

The premise that trust is never granted implicitly but must be continually evaluated.

A restatement of the Zero Trust premise.

NIST SP 800-207

SDP11

Micro-segmentation

Security Design Principle

DEF01 NIST SP 800-215: Microsegmentation is a security design practice where an internal network (e.g., in the data center, cloud provider region) is divided into isolated segments so that the traffic in and out of each segment can be monitored and controlled.

Networks are divided into small, secure zones to maintain separate access for separate parts of the network. This limits an attacker's ability to move laterally across a network. The primary purpose of microsegmentation is to provide a degree of isolation to prevent attack escalation.

NIST SP 800-215, 5.1

SDP12

Multi-Factor Authentication

MFA

Security Design Principle

DEF01 NIST SP 800-63 Revision 3 Appendix A: Multi-Factor Authentication (MFA): An authentication system that requires more than one distinct authentication factor for successful authentication. Multi-factor authentication can be performed using a multi-factor authenticator or by a combination of authenticators that provide different factors. The three authentication factors are something you know, something you have, and something you are.

The use of multiple verification methods to ensure that a user or device is granted access only after successfully presenting two or more pieces of evidence to an authentication mechanism.

NIST SP 800-63 Revision 3 Appendix A

SDP13

Encrypt data

Security Design Principle

Encrypting data at rest and in transit to protect the integrity and confidentiality of the data, even if a network is compromised.

SDP14

Continuous verification

Security Design Principle

Trust is never assumed and must be continually reassessed. Authentication and authorization are required for all users and devices seeking access to resources, regardless of their location.

SDP15

De-perimeterization

Security Design Principle

Jerico Forum

SDC01

Robustness is a prerequisite for a security architecture

Security design consideration

In a dynamic system, a state of robustness is not inherently stable and cannot be expected to last forever. However, it is still a necessary requirement that all components be robust. If a component of the product/system is weak, it's required to remedy the situation.

SDC02

Threat landscape awareness is a prerequisite

Security design consideration

In order to take appropriate countermeasure, it is important to know what kind of threats the system is likely to face. Therefore, it is required to conduct threat landscape investigations, which is a continual process.

SDC03

Awareness of the Cyber Kill Chain is necessary

Security design consideration

Advanced persistent threat (APT) actors will tend to follow a certain set of steps to attack a system. These steps are called the "kill chain". Kill chain knowledge is no silver bullet but kill chain awareness is nevertheless very important.

SDC04

Fallback and backwards compatibility must be managed

Security design consideration

In a dynamic system, it is required to manage fallback and backwards compatibility during the security architecture design.

SDC05

Single point of failure must be avoided (and planned for)

Security design consideration

With serious consideration of the drawbacks, a single point of failure could be avoided.

SDC06

All security functions [must][should] be upgradable, replaceable and updatable

Security design consideration

All security functions will need to be upgradable and replaceable, which can pose a lot of challenges for security functionality.

SDC07

There must be strong detection and response capabilities

Security design consideration

Reactive security measures are for the dynamic cases, and often for unexpected events. So, detection and response capabilities, including the full gauntlet of recovery and incident investigations, are necessary to be supported.

SDC08

Plan for success and a long-term future

Security design consideration

The passage of time almost directly translates into change. And, invariably, any successful large-scale systems will be long lived. This literally translates into requirements to embrace change.

SDB01

Failures provide invaluable information

Security design best practice

To learn from failure is essential. Failures provide vital information about how the system actually works. To learn from security failures in other systems is also important.

SDB02

System interfaces and exposure should be explicitly defined

Security design best practice

Be explicit about intended exposure. To be explicit about intended exposure does not guarantee that the attack surface is well-contained, but it will at least indicate that the problem has been considered

SDB03

Be explicit. Do not assume

Security design best practice

A sound design is normally also a more secure design. A clean and transparent design will contribute towards this goal. However, it is under most conditions also an unattainable goal. Still, this is not the kind of goal that one expects to reach, it more a guideline for direction. One factor that contributes quite a lot is explicitness. Do not assume anything. If it is indeed important, then state it explicitly. This is sound advice for system designs at large, and even more so for security designs.

SDB04

Known vulnerabilities should be prioritised and fixed accordingly, through different security and protection levels.

Security design best practice

An attacker would need to exploit some kind of vulnerability in order to successfully carry out an attack. This is not to suggest that every vulnerability is equally important or need urgent attention. It simply means that all known vulnerabilities could be fixed through different security and protection levels. Sometimes it may suffice to reduce the exposure to provide an effective stopgap mitigation

SDB05

Fail securely

Security design best practice

SDB06

Avoid security by obscurity

Security design best practice

SDB07

Keep security simple

Security design best practice

SDB08

Asset clarification

Security design best practice

SDB09

Establish secure defaults

Security design best practice

SDX01

Juvenal

Security design constraint

Despite the fact that security of some elements in the system can be proved, there is no definite way to measure and compare security of the whole system.

This will be called the Juvenal security design constraint in reference to the famous quote: 'sed quis custodiet, ipsos custodet' which can be interpreted as 'who guards the guards'.

This security design constraint represents a key 'glass roof' that may be pushed, may be deformed but doesn't seem to have any possibility to be pierced.