Governance: Compliance and Policy (CP)

The overall goals for the Compliance and Policy practice are prescriptive guidance for all stakeholders and auditability of SSDL activities. Management-approved prescriptive guidance must be available to all SSDL stakeholders, including vendors, for use in meeting security and compliance objectives. All SSDL activities must produce artifacts sufficient to allow auditing for adherence to prescriptive guidance.

Identifying controls for compliance regimens, developing contractual controls (COTS SLA), setting organizational policy, auditing against policy.
  Objective Activity Level
CP1.1 understand compliance drivers (FFIEC, GLBA, OCC, PCI, SOX, HIPAA) unify regulatory pressures 1
CP1.2 promote privacy identify PII obligations
CP1.3 meet regulatory needs or customer demand with a unified approach create policy
CP2.1 promote privacy identify PII data inventory 2
CP2.2 ensure accountability for software risk require security sign-off for compliance-related risk
CP2.3 align practices with compliance implement and track controls for compliance
CP2.4 ensure vendors don't screw up compliance paper all vendor contracts with software security SLAs
CP2.5 gain executive buy-in promote executive awareness of compliance and privacy obligations
CP3.1 demonstrate compliance story create regulator eye-candy 3
CP3.2 manage third-party vendors impose policy on vendors
CP3.3 keep policy aligned with reality drive feedback from SSDL data back to policy (T: strategy/metrics)

CP Level 1: Document and unify statutory, regulatory, and contractual compliance drivers. The SSG must work with appropriate groups to capture unified compliance requirements in prescriptive guidance and make that knowledge available to SSDL stakeholders.


Unify regulatory pressures. If the business or its customers are subject to regulatory or compliance drivers such as 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 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 may also serve as the regulatory focal point. The goal of this activity is to create one set of software security guidance so that compliance work is completed as efficiently as possible (mostly by removing duplicates). Some firms move on to guide exposure by becoming directly involved in standards groups in order to influence the regulatory environment.


Identify PII obligations. The way software handles personally identifiable information (PII) could well be explicitly regulated, but even if it is not, privacy is a hot topic. The SSG takes a lead role in identifying 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. Note that outsourcing to hosted environments (e.g., the cloud) does not relax a majority of PII obligations. Also note, firms that create software products that process PII (but don't necessarily handle PII directly) may provide privacy controls and guidance for their customers.


Create policy. The SSG guides the rest of the organization by creating or contributing to software security policy that satisfies regulatory and customer-driven security requirements. The policy provides a unified approach for satisfying the (potentially lengthy) list of security drivers at the governance level. As a result, project teams can avoid learning the details involved in complying with all applicable regulations. Likewise, project teams don't need to re-learn 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. 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.


CP Level 2: Align internal practices with compliance drivers and policy, backed by executives. Executives must overtly promote the SSG and associated software security initiative, including the need for compliance. Risk managers must explicitly take responsibility for software risk. The SSG and application owners must ensure service level agreements address security properties of vendor software deliverables.


Identify PII data inventory. The organization identifies the kinds of PII stored by each of its systems and their data repositories. A PII inventory can be approached in two ways: through each individual application by noting its PII use, or through particular types of PII and the applications that touch them. 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.


Require security sign-off for compliance-related risk. The organization has a formal compliance risk acceptance and accountability process addressing all software development projects. 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, and exceptions should be tracked.


Implement and track controls for compliance. The organization can demonstrate compliance with applicable regulations because its practices are 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 or less reliable, the SSG could be forced to take a more active role as referee. A firm doing this properly can explicitly tie satisfying its compliance concerns to its SSDL.


Paper all vendor contracts with software security SLAs. Vendor contracts include a service-level agreement (SLA) ensuring that the vendor will not jeopardize the organization's compliance story and software security initiative. Each new or renewed contract contains a set of provisions requiring the vendor to 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. That can open the door for further software security language in the SLA.


Promote 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 and the potential consequences for failing to meet those obligations. For some organizations, explaining the direct cost and likely fallout from a 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 over internal perspective. One sure sign of proper executive awareness is adequate allocation of resources to get the job done.


CP Level 3: Organizational threat, attack, defect, and operational issue data drive policy evolution and demands on vendors. Executives must ensure that software security policy is periodically updated based on actual data and must demonstrate the organization's ongoing compliance. The SSG, application owners, and legal groups must ensure vendors deliver software that complies with relevant organizational policy.


Create regulator eye-candy. 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. In some cases, regulators, auditors, and senior management are satisfied with the same kinds of reports, which may be generated directly from various tools.


Impose policy on vendors. Vendors are required to adhere to the same policies used internally. Vendors must submit evidence that their software security practices pass muster. Evidence could include code review results or penetration test results. 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 has been used to help ensure that vendors are complying with the firm's policies.


Drive feedback from SSDL data back to policy. Information from the SSDL is routinely fed back into the policy creation process. Policies are improved to find defects earlier or 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 may expose policy weakness. 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 and enhance and improve a firm's effectiveness.