SD3 Top-Level Security Principles (General Security Principles)
Overview
3 Core security principles drive software architecture. These Core principles break into five architectural principles. The five architectural principles map to STRIDE. Each component should be developed with the concept of Defense-In-Depth. To do this in a consistent and repeatable manner, the following secure architectural definitions are made
Core Security Principle 1 - Secure By Design
Secure architectural decisions are based on well-known agile security strategies, tactics, and patterns defined as reusable for achieving security-quality concerns.
Security patterns provide solutions for the necessary authentication, authorization, confidentiality, data integrity, privacy, accountability, availability, safety and non-repudiation requirements, even when the system is under attack.
The Secure By Design principle provides a robust intentional architecture and the preservation of that architecture during software implementation.
This is a superset of the principle of Defense-In-Depth.
Core Security Principle 2 - Secure By Default
The most relevant security primitives are built into IT systems at all stages of development.
These primitives rest on a foundation of secure intentional Agile Architecture patterns to make them available and usable across the entire corporate estate. Security patterns need to be built into components from inception, with fewer additions later.
The default patterns should complement and not compromise usability. Threat analysis will provide secure design defaults for better defence-in-depth and identity provision.
This is a superset of the principle of Identity and the principle of Least-Privilege.
Core Security Principle 3 - Secure In Deployment
The target environment must be mapped with external system dependencies identified. The security weakness of the dependencies will affect the overall security of the operating environment. Egress endpoints and communication methods for the system are classified for security or insecurity.
The target system needs to be maintained securely after deployment by updating with security patches, backing up in case of compromise, monitoring anomalous activity, and auditing for malicious users and content.
This is a superset of the principle of Secure Access and the principle of Secure Communication.
(Secure By Design) Architectural principle of Defense-In-Depth
Each element of an IT system has its defensive capabilities and its defensive framework. This provides security redundancies in the design and anticipates future changes ("future-proofing"). This multi-layered approach with intentional redundancies increases the security of a system. In addition, it addresses many attack vectors, including possible vectors coming as a result of changes to the system. Defense-In-Depth is commonly referred to as the "castle approach" because it mirrors the layered defences of a medieval castle.
The Open Systems Interconnection (OSI) computing system model can be used to define defensive patterns across the system broadly. In addition, the defensive capabilities can be mapped against the steps in the Attack-Kill-Chain to provide more robust defensive capabilities. Appropriately done, Defense-In-Depth manages threats with diverse defensive strategies. If one layer of defence is inadequate, another layer of protection will mitigate the attack probability and impact.
These defences result in a far more effective security system than anyone defence alone would.
The STRIDE element directly relating to this principle is:
Elevation Of Privilege
(Secure By Default) Architectural principle of Identity
Each entity interacting with the IT system needs to be unique, and there has to be a method to prove the authenticity of that entity. An entity may be human, logical, abstract or hardware-based. The principle of Identity is the proactive approach to safely managing information used to authenticate entities for access to secure resources. It is an essential aspect of any identity and access management (IAM) framework and serves as the cornerstone for security.
Identity-based security allows organisations to provide access-control actions to specific entities by enabling the same credentials, ensuring accurate matching and logging for those entities.
The STRIDE element directly relating to this principle is:
Spoofing
(Secure By Default) Architectural principle of Least-Privilege
The least privilege refers to restricting access rights for entities (users, accounts, processes) to only those required resources to perform authorized activities. Privilege itself refers to the authorisation to bypass certain security restraints. For example, the Least-Privilege security model outlines the minimal level of entity permissions that allows the entity to perform defined activities and nothing more. This principle reduces the risk of attackers gaining access to critical functionality or sensitive data by restricting their area of origin, stopping them from spreading to the system.
Only the minimum necessary rights should be assigned to an entity that requests access to a resource. This grant should be in effect for the shortest duration necessary before revoking privileges.
Combining Least-Privilege with Identity ensures an accurate match between what entities and what they receive are entitled to.
Benefits are better system stability (limiting the chance of unhandled system exceptions), better access-control definitions and ease of deployment into larger systems (well-defined access-control granularity).
The STRIDE element directly relating to this principle is:
Elevation Of Privilege
(Secure In Deployment) Architectural principle of Secure Access
The purpose of all IT systems is to process information and data. This information is sent into the system via access points (endpoints). These endpoints are available to a broad range of internal and external entities in numerous instances. The principle of Secure Access outlines the framework to keep the endpoints from being exploited by malicious actors and campaigns. Endpoint security is usually the defensive frontline of a system, and architectural patterns need to be applied to quickly detect, analyse, block, and contain malicious activity.
Good secure architectural patterns will help by covering similar types of endpoints. Therefore, endpoint security is more difficult without good secure architectural patterns at hand.
The STRIDE elements directly relating to this principle are:
Repudiation
Denial-Of-Service
(Secure In Deployment) Architectural principle of Secure Communication
Inter- and intra-system communication uses defined formats for exchanging messages, information and data. This communication is structured by communication protocols, which define the semantics and synchronization of information exchange. The principle of Secure Communication defines the use of protocols that don't have known vulnerabilities and protocols to protect the integrity, confidentiality, and availability of data being transmitted.
This includes cryptographic protocol maintenance (key generation, key lifetime, key storage), schema definitions and defined limitations on message elements (such as length limitations).
The STRIDE elements directly relating to this principle are:
Tampering
Information Disclosure
Denial-Of-Service
Authentication and Identity (Spoofing)
Identity & Access Management (IAM) patterns
The integrity of data (Tampering)
At-Rest
In-Transit
Authentication + integrity of data (Repudiation)
Identity & Access Management (IAM) patterns
Logging and Monitoring
Confidentiality of data (Information Disclosure)
At-Rest
In-Transit
Availability of data and functionality (Denial Of Service)
Well-defined data schemas
Authorization and access control (Elevation Of Privilege)
Identity & Access Management (IAM) patterns
Identity & Access Management (IAM) patterns
These are the agreed patterns to enable Authentication & Authorisation for
Accessing Microservices
Accessing Database
Accessing Microservices
The API layer within the microservices shall authenticate the request using a JWT (JSON Web Token) access token that securely identifies the requesting service in each request. A service can include the access token in requests to other services.
Each service/application/microservice is an OIDC Client, identified by its application ID. The OIDC client is usually the party that the end-user interacts with, and it requests tokens from the authorisation server. The client must be granted permission to access the resource by the resource owner. In this pattern, microservices do not handle/manage Resource Owners / End Users authentication.
Accessing Databases
Each database, schema, or table should be only accessible by a dedicated set of microservices. Therefore, each microservice will have its database user account.
The user account will be strictly defined on what CRUD operations it can execute on the database.