Compliance & Policy

Compliance & Policy Level 1

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: 79] Unify regulatory pressures.

If the business or its customers are subject to regulatory or compliance drivers such as GDPR, FFIEC, GLBA, OCC, PCI DSS, SOX, HIPAA, or others, the SSG acts as a focal point for understanding the constraints such drivers impose on software. In some cases, the SSG creates 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 single set of software security guidance ensures that compliance work is completed as efficiently as possible. Some firms move on to guide exposure by becoming directly involved in standards groups exploring new technologies in order to influence the regulatory environment.

[CP1.2: 101] Identify PII obligations.

The way software handles personally identifiable information (PII) could be explicitly regulated, but even if it isn’t, privacy is a hot topic. The SSG plays a key role in identifying and describing PII obligations stemming from regulation and customer expectations. It uses this information to promote best practices related to privacy. For example, if the organization processes credit card transactions, the SSG will identify 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) does not relax PII obligations. Also note that firms creating software products that process PII (but that don’t necessarily handle PII directly) can get credit by providing privacy controls and guidance for their customers. The proliferation of Internet of Things (IoT) and mobile devices adds yet another dimension to PII protection.

[CP1.3: 66] 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. The 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 don’t need to relearn customer security requirements on their own. The SSG policy documents are sometimes focused around major compliance topics such as the handling of PII or the use of cryptography. In some cases, policy documents relate directly to the SSDL and its use in the firm. Because they’re so new, codifying decisions about IoT, cloud, and mobile architectures can add some much needed pizzazz to the policy discussion. Similarly, it may be necessary to explain what can and can’t be automated into CI/CD and continuous deployment pipelines. Architecture standards and coding guidelines are not examples of software security policy. On the other hand, policy that prescribes and mandates the use of coding guidelines and architecture standards for certain categories of applications does count. Policy is what is permitted and denied at the initiative level. If it’s not mandatory, it’s not policy.  

Compliance & Policy Level 2

[CP2.1: 39] Identify PII data inventory.

The organization identifies the kinds of PII processed or stored by each of its systems and their data repositories, including mobile and cloud environments. 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 the applications that touch them. In either case, an inventory of data repositories is required. Note that when applications are distributed across multiple deployment environments, PII inventory control can get tricky. Do not ignore it. Likewise, do not ignore the constantly evolving definitions of PII. When combined with the organization’s PII obligations, this inventory guides privacy planning. For example, the SSG can now create a list of databases that would require customer notification if breached.

[CP2.2: 38] 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, regardless of development methodology. The SSG might act as an advisor when the risk acceptor signs off on the state of the software prior to release. For example, the sign-off policy might require the head of the business unit to sign off on compliance issues that have not been mitigated or SSDL steps related to compliance that have been skipped. Sign-off should be explicit and captured for future reference. Any exceptions should be tracked, even under the fastest of agile methodologies. An application without security defects might still be noncompliant.

[CP2.3: 43] Implement and track controls for compliance.

The organization can demonstrate compliance with applicable regulations because its SSDL is aligned with the control statements developed by the SSG (see [CP1.1 Unify regulatory pressures]). The SSG tracks the controls, shepherds problem areas, and makes sure auditors and regulators are satisfied. If the organization’s SDLC is predictable and reliable, the SSG might be able to largely sit back and keep score. If the SDLC is uneven, less reliable, or trying to go faster than its supporting infrastructure can handle (looking at you, CI/CD), the SSG could be forced to take a more active role as referee. A firm doing this properly can explicitly associate satisfying its compliance concerns with following its SSDL.

[CP2.4: 42] Include software security SLAs in all vendor contracts.

Vendor contracts include an SLA ensuring that the vendor will not jeopardize the organization’s compliance story and SSI. This is particularly important when controlling cloud computing providers. Each new or renewed contract contains a set of 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 control process, which can open the door for further software security language in the SLA. Traditional IT security requirements and a simple agreement to allow penetration testing are not sufficient.

[CP2.5: 47] Ensure executive awareness of compliance and privacy obligations.

The SSG gains executive buy-in around compliance and privacy activities. Executives are provided plain-language explanations of the organization’s compliance and privacy obligations, plus the potential consequences for failing to meet those obligations. For some organizations, explaining the direct cost and likely fallout from a compliance failure or data breach could be an effective way to broach the subject. For other organizations, having an outside expert address the Board works because some executives value outside perspective more than internal perspective. One sure sign of proper executive awareness is adequate allocation of resources to get the job done. Be aware that the light and heat typically following a breach will not last.

Compliance & Policy Level 3

[CP3.1: 21] Create a regulator compliance story.

The SSG has the information regulators want. 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 piece of paper for every sprint. In some cases, regulators, auditors, and senior management are satisfied with the same kinds of reports, which might be generated directly from various tools.

[CP3.2: 12] 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. This goes for cloud and mobile platform providers as well. Evidence could include results from code reviews or penetration tests. Vendors may also attest to the fact that they are carrying out certain SSDL processes. In some cases, a BSIMM score or a vBSIMM score is used to help ensure that vendors are complying with the firm’s policies.

[CP3.3: 5] Drive feedback from SSDL data back to policy.

Information from the SSDL is routinely fed back into the policy creation process to help find defects earlier or to prevent them from occurring in the first place. Blind spots are eliminated based on trends in SSDL failures. For example, inadequate architecture analysis, recurring vulnerabilities, ignored security gates, or choosing the wrong firm to carry out a penetration test can expose policy weakness. Likewise, policies that impose too much bureaucracy might need to be adjusted to fit agile methodologies. Over time, policies should become more practical and easier to carry out (see [SM1.1 Publish process (roles, responsibilities, plan), evolve as necessary]). Ultimately, policies align themselves with the SSDL data to enhance and improve a firm’s effectiveness.