One of the most pressing challenges facing organizations today is attaining and maintaining compliance with various industry and government regulations and standards. Failure to comply with certain regulations can result in heavy financial penalties that can put many organizations under severe pressure. This series of blog posts will look at how the Microsoft Security Development Lifecycle (SDL) can be used to help organizations meet various compliance requirements.
At first glance, the overlap between software security and compliance would seem to be limited to the specific software requirements posted in standards such as the Payment Application Data Security Standard (PA-DSS). However, the realms of software security and compliance are in fact deeply intertwined. Key processes in most businesses are now vitally dependent on software. For example, many compliance attestations, particularly around the assurance of secure data flows rely on the software that is processing that data being secure. There are activities that must be carried out to comply with a regulation or standard such as PCI DSS or Sarbanes-Oxley (SOX) and activities that should be done to secure business processes. This shift towards software dependence has forced businesses to reexamine their application security strategy and prompted important questions about the security processes of their software suppliers.
Earlier this year we published a white paper titled “The Compliance Benefits of Better Application Security.” This paper helps to demonstrate how a mature software security program can help facilitate broad enterprise compliance as well as increase operational security.
The move towards more trustworthy software and systems is reflected in the evolution and interpretation of key regulations and standards. Looking at true operational security, the risk is too great for software security to be just a line item in a compliance checklist. Having a mature software security approach is vital to information security and can facilitate broader enterprise IT compliance.
There are substantial positive (and cost-saving) side effects of a security development process, particularly in producing a set or artifacts that feed other areas of compliance. For example, key artifacts from the gathering of application security requirements can aid in driving the architecture of network defenses and compensating controls. Understanding the demands of compliance, and mapping security requirements to a mix of application security and compensating controls, can make articulating the security of a process to an auditor easier. It can also help uncover flawed assumptions about the operating environment which can lead to substantial savings such as avoiding the acquisition and maintenance of unneeded compensating controls.
It is also important to note that threat modeling – an important part of a security development process – produces artifacts which help anticipate the activities of a would-be attacker and therefore help to secure the system against attacks.
New regulations and standards continue to emerge and evolve. A compliance-first approach means that software development processes will need to be continuously revised and retooled; this can be an expensive proposition that does little for the operational security of the system. Instead, focusing on building a mature security software development lifecycle can help deliver a significant proportion of compliance coverage. Adopting a security development lifecycle internally and demanding it throughout the supply chain can allow enterprises to reduce risk, seize business opportunities with more confidence, take advantage of cloud deployments and services and satisfy the rigors of audit.
For more information on software and compliance, I encourage you to check out the Microsoft SDL compliance center.