Compliance & Policy

HomeBSIMM FrameworkGovernanceCompliance & Policy

The overall goals for the Compliance & 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.

Compliance & Policy Level 1

[CP1.1: 45] 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 could 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.

[CP1.2: 61] 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 inform all stakeholders. 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) can get credit by providing privacy controls and guidance for their customers.

[CP1.3: 41] 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 keeping up
with 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. If it’s not mandatory, it’s not policy.

Compliance & Policy Level 2

[CP2.1: 19] 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: 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. 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. If it’s not mandatory, it’s not policy.

[CP2.2: 23] 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 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. Signoff should be explicit and captured for future reference. Any exceptions should be tracked.

[CP2.3: 25] 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 or less reliable, 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 to following its SSDL.

[CP2.4: 29] 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 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. That can open the door for further software security language in the SLA. Traditional IT security requirements and a simple agreement to allow pentration testing are not sufficient.

[CP2.5: 33] 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 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 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: 18] 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.

[CP3.2: 11] 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 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 has been used to help ensure that vendors are complying with the firm’s policies.

[CP3.3: 6] 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.

Loading posts...
Sort Gallery
Newsletter Input text