.png)
Adopting A Security Mindset
One important facet of cybersecurity and data protection that the Developing Security & Privacy by Design (DSPD) initiative focuses on is educating applicants on the holistic concepts of how broader business planning and analysis ultimately leads to actionable cybersecurity and privacy requirements. Understanding this hierarchical nature of requirements is a fundamental construct of governance processes.
You cannot adopt a "security mindset" unless you understand the broader requirements that directly and indirectly affect Secure Software Development Practices (SSDP).
Theory of "Adequate Security"
No technology can provide absolute security due to the limits of human certainty, the uncertainty that exists in the life cycle of every system, and the constraints of cost, schedule, performance, feasibility, and practicality. Therefore, trade-offs are expected to be routinely made across contradictory, competing, and conflicting needs and constraints. However, these trade-offs must be optimized to achieve “adequate security” which reflects a risk-based decision made by stakeholders.
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. [click on the image below for a larger PDF version of the infographic]
.jpeg)
The required configuration settings for technology assets must be inclusive of technical and business requirements, which ultimately fall under organizational cybersecurity and privacy policies. Requirements can be categorized as:
-
Stakeholder requirements that address the need to be satisfied in a design-independent manner; and
-
System requirements that express the specific solution that will be delivered (design-dependent manner).
Compliant vs Secure
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:
-
Minimum Compliance Criteria (MCC).
-
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.
-
-
Discretionary Security Requirements (DSR)
-
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 to address voluntary industry practices or internal requirements, such as findings from internal audits or risk assessments.
-
DSR are primarily internally-influenced, based on the organization’s respective industry and risk tolerance.
-
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.
Minimum Viable Product (MVP) Security Considerations
Defining What It Means To Have A "Secure" System, Application, Service or Process
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. This definition expresses an ideal that captures three essential aspects of what it means to achieve security:
-
Enable the delivery of the required system capability despite intentional and unintentional forms of adversity;
-
Enforce constraints to ensure that only the desired behaviors and outcomes associated with the required system capability are realized while satisfying the first aspect; and
-
Enforce constraints based on a set of rules to ensure that only authorized human-to-machine and machine-to-machine interactions and operations are allowed to occur while satisfying the second aspect.
​
For a system, adequate security is an evidence-based determination that achieves and optimizes security performance against all other performance objectives and constraints. Judgments of adequate security are driven by the stakeholder objectives, needs, and concerns associated with the system. Adequate security has two elements:
-
Achieve the minimum acceptable threshold of security performance; and
-
Maximize security performance to the extent that any additional increase in security performance results in a degradation of some other aspect of system performance or requires an unacceptable operational commitment.
Stakeholder Security Requirements
Stakeholder security requirements are those stakeholder requirements that are security-relevant. Stakeholder security requirements specify:
-
The protection needed for the mission or business, data, information, processes, functions, humans, and system assets;
-
The roles, responsibilities, and security-relevant actions of individuals who perform and support the mission or business processes;
-
The interactions between the security-relevant solution elements; and
-
The assurance that is to be obtained in the security solution.
System Security Requirements
System requirements specify the technical view of a system or solution that meets the specified stakeholder needs. The system requirements are a transformation of the validated stakeholder requirements. System requirements specify what the system or solution must do to satisfy the stakeholder requirements. System security requirements are those system requirements that are security-relevant. These requirements define:
-
The protection capabilities provided by the security solution;
-
The performance and behavioral characteristics exhibited by the security solution;
-
Assurance processes, procedures, and techniques;
-
Constraints on the system and the processes, methods, and tools used to realize the system; and
-
The evidence required to determine the system security requirements have been satisfied.
SecDevOps
Security, Development & Operations (SecDevOps), also commonly called DevSecOps, is a relationship model that integrates security in development and operational practices throughout the SDLC. SecDevOps is a “three legs of the stool” concept where each leg is important and the stool falls over if one or more leg is missing. There is considerable material that exists on the subject of SecDevOps, so the SCA-BoK will focus only on a few of its concepts.
Avoiding Siloes
SecDevOps merges security, development, and operations capabilities so these specialized functions can work in unison to achieve a common goal, which is rapid and secure development. This process requires organizational leadership to properly resource integrations and decision-making capabilities, but its benefits outweigh the drawbacks that exist with siloed operations.
GRC Frames SecDevOps Controls
Just as the concept SecDevOps is to integrate functions to eliminate siloed operations, it is important to understand that SecDevOps does not exist within a vacuum. The “security” component of SecDevOps is constrained by the organization’s overall Governance, Risk & Compliance (GRC) function. GRC exists to align people, processes, and technology with the organization’s business objectives while managing risk and meeting statutory, regulatory, and contractual compliance requirements. The security feed of SecDevOps is constrained by the controls GRC deems appropriate.
