Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


02:30 PM
Joe Ward
Joe Ward
Connect Directly
E-Mail vvv

Bringing Compliance into the SecDevOps Process

Application security should be guided by its responsibility to maintain the confidentiality, integrity, and availability of systems and data. But often, compliance clouds the picture.

Developers and those responsible for information security inside the enterprise have different goals and motivations — and inevitably, those contrasting things clash. Developers bear the pressure of meeting deadlines for new applications and feature sets. Security's intervention in this process includes the introduction of code-scanning tools to ferret out vulnerabilities and bugs before new apps or updates hit production. Security should be guided by its responsibility to maintain the confidentiality, integrity, and availability of systems and data. But often, compliance clouds the picture, and earning a Payment Card Industry Data Security Standard (PCI-DSS) checkmark from a quality security assessor (QSA) trumps all.

There needs to be a middle ground where a well-structured and mature application security program has at its foundation developers who design and build secure systems that meet the organization's needs. By design and innately, the application developer should build and program in such a manner that all the artifacts required by a QSA are front-and-center as minimum standards that are part and parcel of every new build or update.

One need look no further than the Heartland Payment Systems breach of 2008. The details are gory and, at the time, it was the largest breach ever. The personal and payment card data of more than 100 million people were stolen; more than 600 companies were affected; losses total in the hundreds of millions of dollars. And Heartland was compliant with PCI-DSS, having passed its audit two weeks prior to the discovery of the breach.

Attackers had penetrated Heartland not with a zero-day exploit or sophisticated hack. The breach was facilitated by a SQL injection attack against the corporate website, a Heartland web property that does not handle payment card data, and it was not in scope for a PCI QSA's audit, but yet it was used as a pivot point to attack the payment processing systems.

Let that sink in: An application security vulnerability in a non-PCI controlled system was the launching pad for the largest breach at that time. Heartland tried to stand on the merit that it was PCI compliant, but this remains a case study for why PCI-compliant systems and organizations cannot make the claim they have sufficient security controls in place.

Compliance programs are not the same as security programs and should not govern the operation of a security programs. The requirements of PCI, HIPAA, or any other industry standard should serve as a minimum set of security guidelines for an organization, and never the high end. Compliance teams need to meet that minimum set of standards, which are defined by a third party with no context of an organization's unique needs, in order to continue a certain business function and not keep an organization secure necessarily.

So, how does application security and secure development fit in? Each development life cycle must be tailored to business needs, development cadence, and technology stacks used. These five threads can help any organization establish amazing application security programs.

Thread 1: Scanning is not enough; you have to track and treat.
Success is defined by how the security of application development is improved. For starters, scanning for, and reporting on, vulnerabilities is not enough; they must be managed. Tools used by developers in this light must manage the entire vulnerability life cycle, and report on:

  • Current statistics about open vulnerabilities
  • Aging or time to remediate statistics
  • Historical trending of vulnerabilities
  • Security defect density statistics and trends

This tool (which can be any tool that meets the needs of developers) can, ideally, also integrate your infrastructure vulnerability management reports as well. This will give upper management a clear understanding of overall risk and see what areas to specifically target.

Thread 2: Standardize your SDLC.
I'm not just talking about agile vs. waterfall vs. DevOps here. More important to application security is to standardize the security processes that are applied at each phase of development.

When you create a functional software development life cycle (SDLC), it doesn't matter if a team follows a waterfall process with one big-bang deployment per year, or if they are a true continuous integration/continuous deployment pipeline with multiple production pushes per day. Everyone knows you perform a static analysis at build time and remediate any identified vulnerabilities as a security gate to unit testing.

Your SDLC must also include an operational security maintenance process. Too often, project development is abandoned once pushed to production. The developers are off working on the next release and the production code is frozen. What happens when a new vulnerability is identified in production source code? There must be a process to remediate security issues through security maintenance releases.

Thread 3: Use a few approved technology stacks.
Standardizing on a few well-known and mature stacks will allow you to get focused and specialized. Analysts become familiar with language syntax and are able to assist developers. Automation tools may be tailored to target the specific languages and versions. Managing and cataloging third-party libraries and frameworks enables quicker remediation and eliminates the use of rogue libraries that could be leveraged upon disclosure of a major vulnerability.

Thread 4: Get top-down support.
The best application security program in the world will go nowhere if it isn't supported by upper management. Such endorsement lends weight to a program that it's relevant and important. Security must clearly communicate the benefits of secure development to executives and stakeholders and demonstrate value early with metrics demonstrating improvement. As a result, compliance with industry standards should be an outgrowth of the program.

Thread 5: Educate your developers.
The best way to mitigate vulnerabilities in source code is to reduce the number of those introduced in the first place. Unfortunately, most computer science majors never have exposure to even the most basic security practices or principles. It falls on secure development programs to institute a continuing education program for development communities. This should be foundational to security and not click-through training similar to what is required by the compliance community. Educate your developers on how to break their applications by doing lunch-and-learns or hosting a capture-the-flag event. You would be surprised how many developers' jaws drop when they understand what manner of bad things can be done by decoding or injecting values into cookies.

Related Content:

Joe Ward (OSCP) is a Senior Security Analyst at Bishop Fox, where he focuses on red teaming and network penetration testing, as well as security architecture and vulnerability management. He is an active member of Arizona InfraGard, a government alliance that is dedicated to ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-13
A UXSS was discovered in the Thanos-Soft Cheetah Browser in Android 1.2.0 due to the inadequate filter of the intent scheme. This resulted in Cross-site scripting on the cheetah browser in any website.
PUBLISHED: 2021-04-13
The Motorola MH702x devices, prior to version, do not properly verify the server certificate during communication with the support server which could lead to the communication channel being accessible by an attacker.
PUBLISHED: 2021-04-13
A privilege escalation vulnerability in Lenovo Power Management Driver for Windows 10, prior to version, that could allow unauthorized access to the driver's device object.
PUBLISHED: 2021-04-13
A null pointer dereference vulnerability in Lenovo Power Management Driver for Windows 10, prior to version, that could cause systems to experience a blue screen error.
PUBLISHED: 2021-04-13
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.