In our final installment of a six-part series for CISOs who are looking to survive the “Wild West” of application security, we explore the sometimes tempestuous relationship between security and compliance. Follow us through this last piece of the security puzzle, as we continue to think about the “how” of doing business in a digital environment that often feels like a lawless frontier. As a CISO, you’re in charge of law and order in your town—that is, of security across the software development life cycle (SDLC). So when regulators roll in and try to tell you how to do your business… Well, who can blame you for thinking, “This town ain’t big enough for the both of us.”

(Read part one | part two | part three | part four | part five)

Avoid a Shootout at the SDLC Corral

Is there an ongoing feud between security and compliance monitoring? From a CISO’s perspective, regulatory requirements can often feel like they’re in place only to make things harder, not better. And unless some type of positive relationship is forged with the notion of security compliance, the entire regulatory process can start to feel more like a burden than a benefit.

The most famous shootout in the Wild West, the gunfight at the O.K. Corrall, was the result of a bitter feud between the lawmen of Tombstone and a group of outlaws known as the Cowboys. The authoritarians say it was self-defense against outlaws, while the outlaws claim otherwise. While this might sound like a classic Western scenario of “good” and “bad” guys, the truth is both sides had their reasons.

In the modern world of application security, this analogy continues to ring true. Application security and compliance aren’t enemies facing off at high noon—but rather, they are separate entities working on the same side. And to make collaborative progress, they need to focus on what unites them, their shared vision of security—not on what divides them.

If You’re the Sheriff of the SDLC, Compliance is Your Deputy

Security and compliance are both concerned with ensuring digital assets are safeguarded against cyber threats. They just come at it from different angles. Security is about implementing controls to protect digital assets. You do it on your own, within the individual context of your business. While compliance, on the other hand, is often about satisfying external requirements, it is also chartered with overseeing adherence to internal policies. Some might be mandated by federal or state laws. Others may not be enforced by the government but rather, by the organization. Regardless of whether compliance relates to internal or external regulations, you ignore them at your peril.

Instilling security controls and practices throughout your SDLC doesn’t automatically make you compliant. And adhering to all regulatory requirements doesn’t necessarily mean you’re sufficiently secure. You have to do both. What makes this challenging is the range you may be dealing with. Different regulations cover different aspects of security and offer varying levels of specificity in their guidance.

For example, the PCI-DSS compliance framework provides a comprehensive set of standards for protecting the systems that store or transmit cardholder data. The NYDFS Cybersecurity Regulation places strict requirements on certain institutions, including the need for a designated CISO and a comprehensive security policy that meets all regulations.

And there are others, depending on your industry or where you do business. The good news is, by bringing compliance into your security practices—working as a team—you’ll bolster both initiatives.

Build Your Security and Compliance Ranch

You need to address the applicable regulatory requirements as you build and enhance security across the SDLC. Think of all those moving parts as cattle and sheep. If you let them wander all over the place, you’ll quickly lose control. But if you build the right structures on your land—a working ranch—you can better manage your herds. In the modern SDLC landscape, your “ranch” is a governance framework. This provides the structure needed to enable a closed-loop discovery/remediation/validation process that supports both security and compliance requirements.

But the structure alone isn’t enough. That’s simply the fence around your ranch. You will need orchestration and automation to securely build out your organization. Your security and compliance livestock may be contained, but they’re still wandering around independently. Automation is the function that eliminates manual and siloed approaches so you can manage risk proactively and strategically. Automation also…

  • provides the comprehensive and up-to-date visibility you need to prioritize and mitigate risks.
  • enables fast and effective remediation so you can maintain your security posture.
  • offers a robust governance framework to provide demonstrable accountability and oversight.
  • makes compliance and regulatory oversight manageable.

And when paired with orchestration, automation can be centralized to manage vulnerability scanning tools, and the data they generate, more effectively, making it usable and operational for security teams. When application security is centrally orchestrated, it’s possible to visualize your security posture more critically.

This Town IS Big Enough for the Both of Us

Making peace with external oversight is never easy. Too often, when compliance monitoring is treated as a burden, it in fact becomes an impediment. But compliance isn’t the enemy of software security; it never has been. When you embrace your regulatory responsibilities as a subset of application security, you’ll strengthen both efforts and your entire program.

Share This