Fri, June 13, 2008 — CIO — A security review or security audit is a process that helps an organization determine if they have the appropriate security measures in place; that is, if the amount they are spending on each security countermeasure approximates the cost to the company of the expected loss. While there are many methodologies for performing a security audit, most include the following steps: identification of valuable assets, estimating their value to the company and their cost if they are somehow damaged, determining their current level of protection, determining the probability of a potential break-in (i.e., risk), deciding if an asset's current protection matches its estimated value and investigating what options are available to remedy any differences. At first glance, while perhaps time-consuming, this does not seem terribly complex. Ask several top executives what they consider to be the company's valuable assets; merge and prioritize the lists, and you are likely well on your way.

If your executives did well, they will have included many types of assets including physical assets such as buildings, technological assets such as computers, intellectual property assets such as domain knowledge, etc. They might have thought to list risks such as fire, theft, computer break-ins, industrial espionage and even natural disasters.

If you add input from the IT team, you will likely get items added to the list involving security of employee passwords, firewall and other Internet-protection mechanisms, power and air-conditioning failures, etc.

Once complete, you will likely have a very comprehensive list of your company's assets that need protection. But one asset is nearly always forgotten. This is the internal configuration of a company's computer systems. "Internal configuration" includes:

• Internal network topology including firewalls, internal IP addresses, and other networking information and configuration that only need to be accessible from within an enterprise's private network.
• Hardware and software products, including their manufacturers, models and versions.
• Usernames, administrative accounts, privileged individuals.
• Internal or external services used by the company (e.g.: travel agency, office supply website, Active Directory services) and the means of connectivity to those services.
• Computer languages and software frameworks used for networked applications.
• Whole or partial source code—including stack traces.

These pieces of internal configuration, along with many others that have been omitted from this column for brevity, all share one thing in common: They are frequently thought of as non-confidential data, yet, in the hands of a skilled attacker, each might contribute to a break-in. With confidential data such as passwords or private keys, the threat from exposure is clear. But from these trivial configuration facts (e.g.: an IP address that is only accessible from within the enterprise network), the threats are less obvious.