Sometimes, it can feel as though auditors get the short end of the stick when it comes to the tools available to assist in the work that they do. It seems like they are always strapped for budget to acquire tools, while adjacent professionals such as security operations folks, have a wealth of tools available—many of them freely available—to help support everything from vulnerability scanning to log file analysis to sorting through malware.
However, believe it or not, sometimes these tools overlap with those that might directly advance an audit in certain situations. During a normal audit situation, an auditor requests evidence to establish that given controls are operating effectively. For example, the auditor might, as a system administrator, pull up a configuration screen, request a tool be run and review the output, or he/she might review a report or log file information. There are good reasons why auditors are not usually the ones in front of the keyboard firing off commands, though. Specifically, having the operations (ops) staff actually do the ops work helps preserve the independence of the auditor (i.e., it helps maintain a separation between those performing and those reviewing). Also, quite frankly, those closest to the business systems under evaluation are probably those best able to navigate them.
However, that is in an ideal world. In the real world, depending on the type of audit or assessment being performed, sometimes things do not go as planned and flexibility is required. Consider, for example, the situation where a larger organization is conducting an on-site review of a much smaller (think small or medium-sized business [SMB] or “mom and pop” shop) service provider. Will that SMB have the technical expertise to supply everything the auditor might want? Maybe. But also, maybe not. It is here where, if direct interaction between the examiner and the systems is permissible (not in every situation will it be), getting a little “hands on” on the auditor’s part can spare everyone some time and energy.
But where are some good places to find tools that an auditor might need should this situation occur? Sure, they can go out and research on the Internet what they might need in response to a given situation, but that is pretty time consuming. One approach is for auditors to look to catalogs of tools that already exist, are already bundled together in a highly portable format, and can be unpacked and used at a moment’s notice.
One fruitful location that has all those properties? Penetration testing (pen testing) Linux distributions. For those who are not familiar with the concept, penetration testing (sometimes referred to as “red team” exercises) is a type of security testing whereby the tester emulates the same methods and tradecraft that would be employed by an adversary against an environment. In essence, testers are trying to get in the same way that an attacker would. To support this type of work, these testers typically employ a specialized testing environment that is “kitted out” with a wide variety of attack tools to accomplish that goal. Over time, specialized Linux distributions have emerged as de facto standard options for that environment: distributions such as Kali (http://www.kali.org/), BlackArch (http://blackarch.org/) and the Samurai Web Testing Framework (www.samurai-wtf.org/), for example.
If the idea of using a pen testing environment to directly support an audit sounds bizarre, consider the following. These environments are portable, usually being downloadable as a virtual machine image ready to be run on a platform such as VMWare Player or VirtualBox (directly on an auditor’s field laptop.) Likewise, they come packaged with hundreds, if not thousands, of versatile tools that can accomplish a wide variety of tasks, many of which are directly applicable to collecting or reviewing evidence needed for an assessment. Will every tool on there be directly applicable to the project the auditor is working on right now? Of course not. But being able to, for example, check an International Bank Account Number (IBAN), search a gigabyte of data for Permanent Account Numbers (PANs) or Social Security numbers (SSNs), rapidly parse log file data, mirror a website, or perform any number of other things with a few keystrokes can greatly increase the efficiency of how evidence is reviewed. And, in some situations, it can help the auditor collect those data in the first place.
Now, note that no one is saying every auditor needs to go out and become fully versed with every pen testing tool out there. And, as mentioned, care should be exercised and diligence employed when considering directly interfacing with a production system (remember, let the ops folks do ops), but, in the event that it is “give up or do it yourself,” doing it yourself can be a useful option.
Ed Moyle
Is director of thought leadership and research at ISACA. Prior to joining ISACA, Moyle was senior security strategist with Savvis and a founding partner of the analyst firm Security Curve. In his nearly 20 years in information security, he has held numerous positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers, and senior security analyst with Trintech. Moyle is coauthor of Cryptographic Libraries for Developers and a frequent contributor to the information security industry as an author, public speaker and analyst.