The Compliance & Policy practice is focused on identifying controls for compliance regimens such as PCI DSS and HIPAA, developing contractual controls such as service-level agreements (SLAs) to help control COTS software risk, setting organizational software security policy, and auditing against that policy.
[CP1.1: 81] Unify regulatory pressures.
If the business or its customers are subject to regulatory or compliance drivers such as the Payment Card Industry security standards; GLBA, SOX, and HIPAA in the United States; or GDPR in the EU, the SSG acts as a focal point for understanding the constraints such drivers impose on software. In some cases, the SSG creates or collaborates on a unified approach that removes redundancy and conflicts from overlapping compliance requirements. A formal approach will map applicable portions of regulations to control statements explaining how the organization complies. As an alternative, existing business processes run by legal or other risk and compliance groups outside the SSG could also serve as the regulatory focal point. A unified set of software security guidance for meeting regulatory pressures ensures that compliance work is completed as efficiently as possible. Some firms move on to influencing the regulatory environment directly by becoming involved in standards groups exploring new technologies and mandates.
[CP1.2: 105] Identify PII obligations.
The SSG plays a key role in identifying and describing PII obligations stemming from regulation and customer expectations by using this information to promote best practices related to privacy. The way software handles PII might be explicitly regulated, but even if it isn’t, privacy is a hot topic. For example, if the organization processes credit card transactions, the SSG will help in identifying the constraints that the PCI DSS places on the handling of cardholder data and then inform all stakeholders. Note that outsourcing to hosted environments (e.g., the cloud) doesn’t relax PII obligations and can even increase the difficulty of recognizing all associated obligations. Also note that firms creating software products that process PII (where the firms don’t necessarily handle it directly) can meet this need by providing privacy controls and guidance for their customers. Given evolving consumer privacy expectations, proliferation of “software is in everything” and data scraping and correlation (e.g., social media) adds yet another dimension to PII protection.
[CP1.3: 76] Create policy.
The SSG guides the rest of the organization by creating or contributing to software security policy that satisfies internal, regulatory, and customer-driven security requirements. This policy includes a unified approach for satisfying the (potentially lengthy) list of security drivers at the governance level. As a result, project teams can avoid keeping up with the details involved in complying with all applicable regulations or other mandates. Likewise, project teams won’t need to relearn customer security requirements on their own. SSG policy statements can sometimes focus on major compliance topics, such as handling PII or using cryptography. In some cases, policy will relate directly to the SSDL and its use in the firm. Because they might be new topics, codifying decisions about IoT, cloud, and mobile architectures can rekindle interest in setting policy. Similarly, it can be necessary, for example, to explain what can and can’t be automated into CI/CD and continuous deployment pipelines (see [SM3.4 Integrate software-defined lifecycle governance]). Architecture standards and coding guidelines aren’t examples of policy, but policy that prescribes and mandates the use of coding guidelines and architecture standards for certain software categories falls under the umbrella. Policy is what is permitted and denied at the initiative level; if it’s not mandatory, it’s not policy. In many cases, policy statements must be translatable into automation for use in a software-defined lifecycle, not just a process enforced by humans, but even automated policy must be mandatory.
[CP2.1: 48] Identify PII inventory.
The organization identifies the kinds of PII processed or stored by each of its systems, along with their associated data repositories. A PII inventory can be approached in two ways: starting with each individual application by noting its PII use or starting with particular types of PII and noting the applications that touch them. System architectures have evolved such that PII will flow into cloud-based service and end-point device ecosystems, and come to rest there (e.g., content delivery networks, social networks, mobile devices, IoT devices), making it tricky to keep an accurate PII inventory. The inventory must be easily referenced in critical situations, such as making a list of databases that would require customer notification if breached or a list to use in crisis simulations (see [CMVM3.3 Simulate software crises]).
[CP2.2: 47] Require security sign-off for compliance-related risk.
The organization has a formal compliance risk acceptance and accountability process that addresses all software development projects. In that process, the SSG acts as an advisor when the risk acceptor signs off on the software’s state prior to release. For example, the sign-off policy might require the head of the business unit to sign off on compliance issues that haven’t been mitigated or on compliance-related SSDL steps that have been skipped. Sign-off should be explicit and captured for future reference, with any exceptions tracked, even under the fastest of agile methodologies. Note that an application without security defects might still be noncompliant so a clean penetration test is not a substitute for a compliance sign-off. Even in DevOps organizations where engineers have the technical ability to release software, there is still a need for a deliberate risk acceptance step even if the criteria are embedded in automation. In cases where the risk acceptor signs off on a particular set of compliance acceptance criteria that are then implemented in automation, there must be an ongoing verification that the criteria remain accurate and the automation is actually working.
[CP2.3: 51] Implement and track controls for compliance.
The organization can demonstrate compliance with applicable requirements because its SSDL is aligned with the control statements developed by the SSG (see [CP1.1 Unify regulatory pressures]). The SSG tracks SDLC controls, navigates problem areas, and ensures auditors and regulators are satisfied. If the organization’s SDLC is predictable and reliable, the SSG might be able to remain in the background because following the SSDL generates the desired compliance evidence. Increasingly, the DevOps approach of embedding compliance controls in process shows up within software-defined infrastructure and networks rather than in process and manual intervention. A firm doing this properly can explicitly associate satisfying its compliance concerns with following its SSDL.
[CP2.4: 44] Include software security SLAs in all vendor contracts.
Vendor contracts include an SLA to ensure that a vendor won’t jeopardize the organization’s compliance story or SSI. Each new or renewed contract contains provisions requiring the vendor to address software security and deliver a product or service compatible with the organization’s security policy (see [SR2.5 Create SLA boilerplate]). In some cases, open source licensing concerns initiate the vendor management process, which can open the door for additional software security language in the SLA. Traditional IT security requirements and a simple agreement to allow penetration testing aren’t sufficient here.
[CP2.5: 56] Ensure executive awareness of compliance and privacy obligations.
To gain executive buy-in around compliance and privacy activities, the SSG provides executives with plain-language explanations of the organization’s compliance and privacy obligations, along with the potential consequences of failing to meet those obligations. For some organizations, explaining the direct cost and likely fallout from a compliance failure or data breach is be an effective way to broach the subject. For others, having an outside expert address the Board works because some executives value an outside perspective more than an internal one. A sure sign of proper executive buy-in is adequate allocation of resources to meet those obligations. While useful for bootstrapping efforts, be aware that the sense of urgency typically following a breach will not last.
[CP3.1: 25] Create a regulator compliance story.
The SSG has the information regulators want, so a combination of written policy, controls documentation, and artifacts gathered through the SSDL gives the SSG the ability to demonstrate the organization’s compliance story without a fire drill for every audit or a piece of paper for every sprint. Often, regulators, auditors, and senior management will be satisfied with the same kinds of reports that can be generated directly from various tools. In some cases, the organization will require additional information from vendors about how the vendor’s controls support organizational compliance needs (e.g., cloud providers, especially in a multi-cloud deployment). It will often be necessary to normalize information that comes from disparate sources. While they are often the biggest, governments aren’t the only regulators of behavior.
[CP3.2: 15] Impose policy on vendors.
Vendors are required to adhere to the same policies used internally and must submit evidence that their software security practices pass muster. For a given organization, vendors might comprise cloud providers, middleware providers, virtualization providers, container and orchestration providers, bespoke software creators, contractors, and many more, and each might be held to different policy requirements. Evidence of their compliance could include results from code reviews or penetration tests, or from tests built directly into automation or infrastructure. Vendors might attest to the fact that they perform certain SSDL processes. In some cases, a BSIMM score or a BSIMMsc score can help ensure that vendors are complying with the firm’s software security policies.
[CP3.3: 7] Drive feedback from software lifecycle data back to policy.
Information from the software lifecycle is routinely fed back into the policy creation process to help find defects earlier or to prevent them from occurring in the first place. In doing so, blind spots can be eliminated by mapping them to trends in SSDL failures. The regular appearance of inadequate architecture analysis, recurring vulnerabilities, ignored security gates, or the wrong firm choice for carrying out a penetration test can expose policy weakness. In some cases, lifecycle data might indicate that policies impose too much bureaucracy, for example, by introducing friction that prevents engineering from meeting the expected delivery cadence. Rapid technology evolution might also create policy gaps that must be addressed. Over time, policies become more practical and easier to carry out (see [SM1.1 Publish process and evolve as necessary]). Ultimately, policies are refined with SSDL data to enhance and improve a firm’s effectiveness.
