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.
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.
CP1.1
Know all regulatory pressures and unify approach. If the business is subject to regulatory or compliance drivers such as FFIEC, GLBA, OCC, PCI DSS, SOX, SAS 70, HIPAA or others, the SSG acts as a focal point for understanding the constraints such drivers impose on software. 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 will comply.
CP1.2
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, customer demand, and consumer 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 PCI DSS places on the handling of cardholder data.
CP1.3
Create policy. The SSG guides the rest of the organization by creating or contributing to policy that satisfies regulatory requirements and customer-driven security requirements. The policy provides a unified approach for satisfying the (potentially lengthy) list of external security drivers. 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 personally identifiable information or the use of cryptography.
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.
CP2.1
Identify PII data in systems (inventory). The organization identifies the kinds of PII stored by each of its systems. 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
Require security sign-off for compliance-related risk. The organization has a formal process for risk acceptance. 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 critical vulnerabilities that have not been mitigated or SSDL steps that have been skipped.
CP2.3
Implement/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] Know regulatory pressures, unify approach.) The SSG tracks the controls, shepherds problem areas, and makes sure auditors are satisfied. If the organization's software development process is predictable and reliable, the SSG might be able to largely sit back and keep score. If the development process is uneven or less reliable, the SSG could be forced to take a more active role as referee.
CP2.4
Paper all vendor contracts with SLAs compatible with policy. Vendor contracts include a service level agreement (SLA) ensuring that the vendor will not jeopardize the organization's compliance story. Each new or renewed contract contains a standard 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.)
CP2.5
Promote executive awareness of compliance/privacy obligations. The SSG gains executive buy-in around compliance and privacy activities. Executives understand 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.
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.
CP3.1
Create regulator eye-candy. The SSG has the information regulators want. A combination of policy, controls, and artifacts gathered through the SSDL give the SSG the ability to demonstrate the organization's compliance story without a fire drill for every audit.
CP3.2
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.
CP3.3
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. Policies become more practical and easier to carry out. (See [SM1.1] Publish process (roles, responsibilities, plan), evolve as necessary.)