Integrating Compliance Auditing with DevSecOps By now you have probably at least read about the benefits of merging development, security, and operations into a cohesive unit (if not also implemented to some degree). Now it’s time to take it a little further: integrating security compliance audits. Whether you face mandated audits, like PCI, FISMA and agency specific implementations like Security Controls Testing (SCA) or NISTIR 8011 flavored Adaptive Capabilities Testing (ACT), or self-imposed assessments for your own [good] reasons (or both), integrating an external audit with your system development and maintenance process can help your organization more efficiently remediate vulnerabilities and weaknesses, and the overall audit process will be less costly.
As an industry, we have failed. Miserably. Cyber security professionals have implemented a broken methodology and graduated from failing to properly identify the problem to failing to present an effective solution. The network security methodology of: 1. Find Vulnerabilities, and then 2. Apply Security Patch, simply does not work for the custom web application environment. This statement may seem obvious, but it’s exactly what the industry has tried to do.
FYRM Associates is proud to announce our new AppTrust offering that enables organizations to produce secure applications in Agile environments, in a cost-cutting manner. The typical, flawed approach to application security is based on the network security model of “when we find a vulnerability, we patch it.” This forces your organization into a never-ending game of catch-up with attackers that is nothing more than a costly and time-consuming strategic failure.
Today I finally found the time to release the XAB Proof-of-Concept code. An apology to those of you who have been emailing us wondering when we would publish it. For the time being, it’s hosted at sourceforge and you can download the code from the XAB project page located at: http://sourceforge.net/projects/xab We’ve submitted talks to Black Hat and Defcon for the updates we’re working on, so hopefully we’ll have the chance to catch everyone up, solicit some more feedback, and grab a brew.
All Your Public facing Web Apps Are Relevant To Us. I’m going to start off this post with the moral of the story: Good intentions often have bad, unintended consequences. The following is the ‘Testing Procedures’ text of requirement 6.6 from the new PCI DSS v1.2 (source: https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html): For public-facing web applications, ensure that either one of the following methods are in place as follows: Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
I have had many discussions this year regarding the future of the application security industry and even more about its current state. It’s interesting how people of such varying backgrounds will have similarly varying views; this short article is designed to capture those views and hopefully drive some productive discussion as a result. Where are we now? Should be a simple question, right? Let me summarize in three main categories:
Of the many ideas floating around the cyber security industry lately, there is one often overlooked but very effective approach: spying. Too often security personnel will look at developers as improperly educated code jocks, akin to Hollywood’s portrayal of “hackers” in the 1990s. Similarly, developers see the security analyst as an idealistic zealot with no concept of how things are in the “real world.” So the goal is to bridge the gap between the security and development groups.