To understand how the business side of any organization intersects with technology, ask an internal auditor. This might sound counterintuitive at first, but think about what auditors need to know to do their job: Not only do they need to understand what the business objectives are and the processes those areas employ, but they also need to understand (with a high level of specificity) exactly what systems support those business teams in doing so. They need to know how those systems operate, how they interact with each other and how they cross boundaries to interface with other business areas.
The “short version”? Technology auditors almost always know the situation when it comes to technology use throughout the business, and they can understand in full measure exactly how important technology is to the business as a whole.
The downside of that dynamic, though, is that it can sometimes make it sting—especially keenly when those auditors’ requests for new tools and technologies to support audit activities go unfulfilled. It is the reality, though: When evaluating an assessment tool purchase against a tool that directly supports the business, very often the business tool gets priority. This puts technology auditors in the boat of “doing more with less” from a technology, application and tool support standpoint.
This, in turn, means that it is especially important for audit teams to realize as much value as possible from tools they already have. In fact, they may benefit from tools already in house that can be repurposed or extended to help support assessment activities. Because, in truth, there are likely tools an organization uses for some other nonassurance purpose that can (with a bit of creativity) be applied to help bolster audit and assurance. With that in mind, let us examine a few candidates: tools that an organization may already have that, while probably not originally brought in specifically for assurance, can, nevertheless, provide direct value to audit teams when harnessed for that purpose.
In discussing these in detail, it goes without saying that there are likely hundreds of tools in this category for any given organization. Moreover, they are, on the whole, likely to vary significantly from firm to firm based on organization-specific factors such as industry, geography, size and type of organization. No one source (no matter how well intentioned) could account for these unique factors and lay out an exhaustive list. Therefore, the focus here is on areas that are likely to be present in any organization regardless of those specific factors. as new needs are identified and the audit team becomes more accustomed to partnering with other teams on tool use, opportunities to collaboratively partner and bring in additional tools might also arise.
1) Asset and Configuration Management Tools
Most organizations—at least those larger than a few dozen employees—have some methodology and supporting application footprint to support creating and maintaining an inventory of fielded systems, components and equipment. This might be one central, integrated system or it might be multiple smaller and disparate ones spread throughout the organization (e.g., in a situation where each business unit maintains its own separate inventory).
In fact, assurance teams oftentimes interact with these systems in the course of doing their work. For example, they might review reports from asset management databases to ensure that specific goals are met (e.g., decommissioning of systems no longer in use, correlation of system information to business purpose). However, use of these tools can extend well beyond the simple viewing of reports or interaction on a particular assessment to a broader one that can help to streamline the audit process in the future.
First and foremost, the automation functionality of many of these tools can be directly leveraged. In cases where configuration information is collected in automated fashion via the tool (e.g., via a remote agent or over the network), that information can be adapted to help streamline configuration review across the board. Rather than fighting to get budget for a special-purpose configuration reviewing tool (or, worse yet, reviewing those configurations manually), can the asset management tool enable automation of that review process? In many cases, the answer is yes.
Alternatively, if an organization employs automated configuration management (e.g., Puppet [http://puppet.com] Chef [http://www.chef.io/chef]) either for rapid development or as a security control, this information can directly feed into an assurance activity. Not only can it be a repository of information about configuration, but it can also be leveraged in many cases to help evaluate a given configuration relative to a known benchmark.
2) Business Continuity and Disaster Recovery Environments
One of the hardest things to analyze can be the role of—and interactions between—systems in the environment. Specifically, this refers to assessing what role a given system (or set of systems) plays in a business process and understanding what else with which it might interact and on what it depends. Determining those things can often entail numerous interviews with business subject matter experts and often can involve quite a bit of investigation to get to a reliable answer.
One way to potentially streamline this process is to look for information that might already be collected that can help shine light on those relationships. One source of information that can assist here is in the business continuity planning (BCP)/disaster recovery (DR) space. Specifically, processes such as business impact analysis (BIA) that support identification of critical systems for a given business process can help identify critical systems and relationships. So the data from a BIA can immediately provide valuable information to the assurance team. Beyond this, though, there can be valuable information that can be cleaned from a DR or business continuity (BC) environment that is otherwise challenging to collect on its own, e.g., traffic patterns that are indicative of active communications. In many cases, a DR environment is less “noisy” than the production environment it reflects, so analysis of traffic patterns (to determine what talks to what) can be easier to accomplish.
3) Data Loss Prevention
One additional tool that can be potentially valuable to the assessor is data loss prevention (DLP) tools. Typically deployed as a security mechanism, the purpose of these tools is to analyze data and flag situations where potentially sensitive data are in a location where they should not be (e.g., an outbound email, a public file share).
Should an organization already have a tool along these lines, it can prove invaluable for assurance teams. Why? Because it can help assurance teams evaluate the presence or absence of data in a particular locality that might be relevant to an audit. For example, an auditor might wish to assess whether a control designed to limit the exposure of information (e.g., encryption) is working as intended. That can be challenging to do leveraging manual methods; leveraging a DLP tool, should there already be one in the environment that can be adapted for this purpose, can streamline that process and more readily alert the assessor to the presence or absence of that information. In other words, it can verify the effective operation of the control.
It bears saying that it is less likely that an enterprise will have a DLP in place compared to the prior tools outlined; in fact, only a subset will have DLP at the ready to employ to enable audit. In this case, free alternatives may be investigated such as OpenDLP (http://code.google.com/archive/p/opendlp), MyDLP (http://www.mydlp.com), or special-purpose command-line tools such as ccsrch (http://adamcaudill.com/ccsrch).
Conclusion
These are, of course. only a few examples of situations where existing tools can be retargeted to assist in assurance activities. Many more tools can provide value to the assessor. By evaluating how tools already fielded in the organization can be leveraged to assist in assurance activities, the audit team can squeeze additional value from investments already made; moreover, as new needs are identified and the audit team becomes more accustomed to partnering with other teams on tool use, opportunities to collaboratively partner and bring in additional tools might also arise.
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.