Both practitioners and architects need to understand the difference between “compliant” versus “secure” since that is necessary to have coherent risk management discussions.
Both practitioners and architects need to understand the difference between “compliant” versus “secure” since that is necessary to have coherent risk management discussions.
When evaluating “what looks right” for security controls that are applicable to an application, service, or process, this involves not only the GRC team, but the business stakeholders to properly identify “must-have” vs “nice to have” security and privacy requirements.
These are the absolute minimum requirements that must be addressed to comply with applicable laws, regulations, and contracts.
MCC are primarily externally-influenced, based on industry, government, state, and local regulations. MCC should never imply adequacy for secure practices and data protection since they are merely compliance-related.
These are tied to the organization's risk appetite since DSR are “above and beyond” MCC, where the organization self-identifies additional cybersecurity and data protection controls.
DSR address voluntary industry practices or internal requirements, such as findings from internal audits or risk assessments.
While MCC establishes the foundational floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation, and enhanced security.
The combination of MCC and DSR identify Minimum Viable Product (MVP) security and privacy requirements. This can also be considered Minimum Security Requirements (MSR) for the application, service, or process throughout its lifecycle.
Developers and architects should strive for a set of security and privacy controls that equates to “secure and compliant” instead of just “compliant” since meeting minimum compliance requirements rarely means an application, service, or process will be secure.
A “secure system” is a system that ensures that only the authorized intended behaviors and outcomes occur, thereby providing freedom from those conditions, both intentionally/with malice and unintentionally/without malice, that can cause a loss of information assets with unacceptable consequences. The focus is on defining "adequate security" based on the organization's specific scenario (e.g., threats, risks, limitations, resources, etc.)
This definition expresses an ideal that captures three essential aspects of what it means to achieve security:
An organization publishes policies to eliminate potential gaps in that desired governed behavior in an attempt to achieve “adequate security” for the organization based on what a reasonable individual would be expected to do in a similar situation.
The rules associated with this “governed behavior” must be accurate, consistent, compatible, and complete with respect to the executive leadership's objectives to successfully accomplish the organization's mission and overall strategy.
An organization's policies ultimately define the behavior of Individual Contributors (IC) (e.g., developers, architects, etc.) in performing their roles and associated responsibilities, as well as for the development of processes and procedures.
This eventually leads to the configuration of technology assets (e.g., systems, applications, services, and processes), where a discrete set of restrictions and properties must exist to specify how that asset enforces or contributes to the enforcement of the organizational security policies.
Requirements can be categorized as stakeholder requirements (design-independent) and system requirements (design-dependent). Both practitioners and architects need to understand the distinction.
Security-relevant stakeholder requirements specify:
System requirements specify the technical view of a system or solution that meets the specified stakeholder needs. They are a transformation of the validated stakeholder requirements. System security requirements specify: