Security frameworks help us understand the unique controls relevant to our testing requirements. In this video, learn about some of the most well-known security frameworks.
- [Instructor] Newton said it best. "If I have seen further, "it is by standing on the shoulders of giants." So much of the security testing knowledge we rely on today was pioneered by those who came before us. People who recognized the risks inherent in relying on technology, especially when someone with malicious intent could make that technology act in a way that its creators never intended. Security frameworks are excellent examples of that accumulated knowledge put to paper. Offline application security testing happens where development methodologies and security methodologies intersect. Developers and security professionals both want the same thing, we want the applications to do what they were intended to do. Developers approach this from a functional standpoint. Can we make the application do a thing? Security professionals approach this from a defensive standpoint. Can we prevent bad actors from interfering with the application while it does its thing? When we identify where those two goals intersect, that's where we can be the most effective. The best part is that nearly every security framework already includes application security requirements. That means that you don't have to start building your offline application security tests from scratch. You can turn to these frameworks to determine where it makes the most sense for you to start your testing. While there are quite a few security frameworks to choose from, I recommend that you start with four of the most popular. The ISO 27000 series, the NIST Cybersecurity Framework, Control Objectives for IT or COBIT, and the CIS Critical Security Controls. The ISO 27000 series is actually a collection of over 30 related standards from the International Organization for Standardization. This series of standards is designed to help you build a fairly robust information security management system or ISMS. When you mention ISO to a security professional, chances are that person's going to think of the 27001 standard. Truth be told though, it's 27002 that I've always found the most useful. 27002 contains 114 specific controls with an entire category devoted to information systems, acquisition, development and maintenance. The NIST Cybersecurity Framework draws on multiple special publications from the U.S. National Institute of Standards and Technology. It does this in order to provide an all-encompassing approach to cybersecurity and risk management. Similar to ISO 27002, NIST has documented anywhere from 115 to 173 unique security controls depending on which baseline you choose, low, medium or high. The specific publication that I'm referencing here is NIST Special Publication 800-53 Revision Four. Although the larger cybersecurity framework document maps the specific NIST controls to all of the other frameworks that I want you to know about. COBIT, what was formerly known as Control Objectives for IT, comes from the ISACA organization. COBIT was designed with the broader topic of IT governance in mind. COBIT includes six application controls, showing how these controls relate to other IT controls. Finally, I recommend you take a look at the Critical Security Controls from the Center for Internet Security. The CIS applies a maturity model when selecting controls. Choosing those controls that are right for your organization based on resource availability and cybersecurity expertise. The most interesting aspect of the Critical Security Controls is that the CIS prioritizes those controls while the other frameworks rely on organizations to choose control priority based on each organization's unique risk appetite. You'll find tremendous value in reviewing these four frameworks in detail focusing on the guidance each one provides regarding application security. But we haven't even touched on compliance standards yet. Where security frameworks contain recommended guidance based on best practices, compliance standards contain rules that organizations that have to follow in certain cases. Failure to meet compliance standards can result in hefty financial penalties. Publicly traded companies in the US must comply with Sarbanes-Oxley while financial services organizations must meet the requirements laid out in the Gramm-Leach-Bliley Act. Healthcare organizations in the US are expected to protect healthcare information in accordance with the Health Insurance Portable and Accountability Act. And any organization who processes credit card information needs to know their obligations to the Payment Card Industry Data Security Standard. Regarding privacy, the EU General Data Protection Regulation and Canada's Personal Information Protection and Electronic Documents Act both have a lot to say about protecting consumer and citizen information. And when it comes to compliance, this list is far from complete. It does, however, give you a starting point for other resources you can turn to for guidance on relevant application security controls. In other words, there's no shortage of guidance from security standards, regulations and frameworks on what you should be testing for when it comes to application security. You should use these resources to build your foundation and then turn to OWASP for more specific, tactical guidance on how to execute those tests.
- Security frameworks
- OWASP Top Ten
- Building Security In Maturity Model (BSIMM)
- Planning your testing projects
- Creating security policies
- Source code reviews
- Application threat modeling
- Offline testing for OWASP Top Ten vulnerabilities