Principles for engineering secure systems are to be set, written down, kept current and applied to every information system development activity. Purpose: have information systems designed, built and operated securely throughout the development life cycle. Guidance: apply documented security engineering principles to system engineering, building security into every architecture layer (business, data, applications, technology), analysing new technology for security risk and reviewing designs against known attack patterns. The principles steer how users are authenticated, how sessions are protected and how data is validated and cleaned, and should analyse the full set of controls needed against identified threats; how well controls prevent, detect or respond to events; controls specific business processes need, such as encryption, integrity checking and digital signing; where and how controls are applied, for instance by fitting them into the security architecture and the technical infrastructure; and how manual and automated controls combine into an integrated set. They should account for integration with a security architecture; technical security infrastructure such as PKI, identity and access management, leakage prevention and dynamic access tools; whether the organization can build and sustain the technology it picks; the cost, time and complexity of meeting requirements; and current good practice. Secure engineering should draw on architecture principles: least privilege and least functionality; designing security in and making it the default; layered defence; denying unless allowed; failing into a secure state; treating input from outside applications as untrusted; securing deployment; assuming a breach has happened; and keeping security usable and manageable; include security-focused design reviews that find vulnerabilities and confirm controls are specified and meet requirements; record and formally accept any control that does not fully satisfy its requirements, for example because safety requirements override them; and harden systems. Consider zero trust principles: assume systems are already breached rather than relying on the perimeter; never trust, always verify; encrypt requests end to end; verify every request as though it came from an open external network, whether it began inside or outside; apply least privilege and dynamic access control (5.15, 5.18, 8.2) using context such as authentication information (5.17), identities (5.16), endpoint device data and classification (5.12); and always authenticate requesters and validate authorization on that basis, for example with multi-factor authentication (8.5). Apply the principles to outsourced development through contracts and make sure suppliers' practices fit the organization's needs. Review the principles and procedures regularly so they keep raising security standards and remain current against new threats and technologies. Other information: the principles apply to fault tolerance and resilience, segregation such as virtualization or containers (so a compromised instance affects only itself), and tamper resistance that records attempts and can destroy data to prevent extraction.
This control maps to 87 controls across 30 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.27 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 87 it maps to, and the evidence behind each claim, over MCP and REST.