Documentation< Previous | Contents | Next >
11.2.2. Compliance Penetration Test
The next type of assessment in order of complexity is a compliance- based penetration test. These are the most common penetration tests as they are government- and industry-mandated require- ments based on a compliance framework the entire organization operates under.
While there are many industry-specific compliance frameworks, the most common would likely be Payment Card Industry Data Security Standard16 (PCI DSS), a framework dictated by payment card companies that retailers processing card-based payments must comply with. However, a number of other standards exist such as the Defense Information Systems Agency Security Techni- cal Implementation Guides17 (DISA STIG), Federal Risk and Authorization Management Program18 (FedRAMP), Federal Information Security Management Act19 (FISMA), and others. In some cases, a corporate client may request an assessment, or ask to see the results of the most recent assess- ment for various reasons. Whether ad-hoc or mandated, these sorts of assessments are collectively
13http://tools.kali.org/tools-listing 14http://docs.kali.org
15https://www.offensive-security.com/metasploit-unleashed/ 16https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf 17http://iase.disa.mil/stigs/Pages/index.aspx
18https://www.fedramp.gov/about-us/about/ 19http://csrc.nist.gov/groups/SMA/fisma/
called compliance-based penetration tests, or simply “compliance assessments” or “compliance checks”.
A compliance test often begins with a vulnerability assessment. In the case of PCI compliance auditing20, a vulnerability assessment, when performed properly, can satisfy several of the base requirements, including: “2. Do not use vendor-supplied defaults for system passwords and other security parameters” (for example, with tools from the Password Attacks menu category), “11. Regularly test security systems and processes” (with tools from the Database Assessment cat- egory) and others. Some requirements, such as “9. Restrict physical access to cardholder data” and “12. Maintain a policy that addresses information security for all personnel” don’t seem to lend themselves to traditional tool-based vulnerability assessment and require additional creativ- ity and testing.
Despite the fact that it might not seem straight-forward to use Kali Linux for some elements of a compliance test, the fact is that Kali is a perfect fit in this environment, not just because of the wide range of security-related tools, but because of the open-source Debian environment it is built on, allowing for the installation of a wide range of tools. Searching the package manager with carefully chosen keywords from whichever compliance framework you are using is almost certain to turn up multiple results. As it stands, many organizations use Kali Linux as the standard platform for these exact sorts of assessments.