I have been in airports a lot lately and just out of habit, I have spotted a lot of avenues for stealing sensitive information.  As an auditor, I am never satisfied with just spotting a vulnerability, though.  Of course if I see a moderate or high risk I inform someone (like the car rental staff who taped their user names and passwords to their monitors - I saw that last week).  But I also go through a mental process I call “social decompiling.”

Social decompiling is a way of reverse-engineering people who have access to sensitive information to see how a social engineering attack would work on them. While social decompiling I observe people’s risky behavior and I ask two questions: How would an attacker take advantage of that behavior? What test would I run as an auditor to see if that vulnerability was present?

Take for instance the guy on the plane with me last week who was writing up his findings of a clinical trial.  A new drug, when combined with a specific physical therapy, restores muscle mass after a traumatic injury more rapidly than physical therapy alone. He also had a spreadsheet full of patients who went through the clinical trial to prove the point. During the flight he saved his article and raw data to his laptop hard drive, his USB pen drive and his Blackberry.  These documents and their drafts were clearly important to him (and could be to others).  At one point mid-flight, he screen-locked his laptop and went to the bathroom.  He left the USB pen drive within my reach.

My social decompiling started long before he left for the bathroom, and I’ll spare you the multiple scenarios I considered for getting the data, loading a backdoor or Trojan, etc. What was most interesting to me was thinking of how I could test for this behavior in a future audit.  I didn’t bother this guy when he got back, but when I am auditing people I do ask about their comfort with leaving storage devices unattended, even for a moment.  See, I don’t recall, ever, seeing someone take out their car keys on a plane and leave them on the seat when they went to the bathroom.  I don’t ever recall seeing a person leaving their car keys or wallet on a table at a coffee shop when they went to order their coffee or use the bathroom.  They leave their laptops and pen drives there a lot.

There is something about car keys, a wallet, credit cards, etc. that we believe is so valuable that we must physically protect those things at all times.  But our information - saved on laptops, pen drives, in our phones – seem to us less in need of protection.

Yes, an obvious audit test would be to determine whether attached storage devices are encrypted.  But let’s face it; that is not yet a normal configuration.  So I also consider the amount of security awareness that my audited population has.  Are they diligent about protecting information and information containers that they carry?  Are they aware of data breaches in the news in which data devices were lost or stolen?  Is the physical security of pen drives as habitual as it is for their car keys and wallets?  Asking information handlers these questions re-enforces the normative idea that it should be, and tests for how thorough security awareness training is.

Is management training staff to be vigilant, diligent, or paranoid? Are staff given materials that help them to be vigilant, diligent or paranoid, like cable locks, encrypted drives, etc?  Do laptops have stickers plastered to them, reminding staff to never leave laptops or any mobile information unguarded?  Are staff disciplined when they violate these rules?

So not only should information handlers demonstrate to the auditor some level of caution about the information that they carry, but the organization should demonstrate mechanisms for reinforcing a culture of caution so that pen drives, laptops and even reams of paper seem as risky to them as their car keys or wallets.

Just about any security framework or standard I have worked with covers security awareness as part of the control environment (to varying degrees), and for good reason.  As long as we provide people with access to sensitive information, our weakest security link will be their ability to protect it.  So whether auditing with CobiT, ISO-27000 series, or NIST 800-53 or 800-50, social decompiling is a very useful habit to make your awareness and training tests insightful.

To help you get into the social decompiling frame-of-mind, I will recommend two books on the subject: No Tech Hacking by Johnny Long, et al, and The Art of Deception by Kevin Mitnick, which includes lots of practical advice for safeguarding against social engineering.

This post is completely off topic as far as Auditing goes, but it just occurred to me in terms of a personally identifiable information issue.  Here I am sitting at a desk in an office in Brooklyn Heights getting ready to head over to Penn Station to hop on a train out to our house for the weekend.  A week and a half ago I drove cross-country (2,800 miles in 3 days will make anyone tired!), charging my gas and hotel all the way.

As if the cross country charges weren’t bad enough, I then went and bought a new LCD HDTV for our house out here and a new multi-function color laser printer (if you’re looking for one, OfficeMax has a Samsung at a fantastic price).  Stack those two items onto my charges and I now look like someone with a stolen card.

Later that day I tried to purchase a piece of software online only to be declined.  When I called up Visa, it took no fewer than six security questions before the customer service rep could reset my account.  Two hours later I was declined again at a gas station.  At that point I decided that I’d just let the card cool off for a bit!

Back to our story… As I sit here in my office I decided that it would be a really good idea for me to call Visa proactively so that once I’m down in the depths of Penn Station with no cell phone coverage I’ll be able to purchase my LIRR ticket with nary a problem.  It wasn’t until I hung up that I realized what’s now sitting in the “Past Calls” window of my cell phone…  I can see that look on your face too.  You just figured it out.  My entire credit card number plus the CVV number from the back of the card is in the cell phone memory!

Just another example of the many things that we do that potentially compromise our own  security every day.

Working with business as an external auditor and security professional for as long as I have I think that I’ve finally stopped being surprised by the odd views held by some management teams.  Even today, despite all of the headline making reports of compromises and data extrusions, many business continue to draw hard lines between security, disaster recovery/business continuity and audit.

To be sure, I’m not trying to say that these are all the same thing.  However, these functions are sometimes treated as the ugly duckling; in fact, what I usually find is that they are the three ugly ducklings and take turns when it comes to who will be the ugliest!

For example, working with a business and pointing out the serious deficiencies in some of their security controls, the management team responded that they would definitely “…address the issue by tightening up security and adding needed controls.”  You and I both know that to do this will take resources.  Which resources?  “…redirect [funding] from the DR/BCP program to the security team to accomplish these necessary tasks.”

You may be reading this and saying, “Well, yes, I see that kind of thing all the time.  The money has to come from somewhere, afterall!  How should we look at the problem?”  The answer is that as auditors we are in an important position to help management to have a more holistic view of the relationship between these functions.  In reality, all of them are security and process controls, safeguarding data and also safeguarding business processes and profitibility.  If our business fails to do this, we will always be fighting a losing battle as we run from stick to stick trying to spin the plates before they fall!

Much of what we do to secure information involves controlling its location. Information should be “in” somewhere: an office, a server, a network, a folder, a database, etc. When we let people “in” to where the information is, we demand that they identify themselves as the people who we allowed access to that information. And when we expect the information to travel out of its safe place we take measures to secure the places that the information may go to: we encrypt files, we encrypt devices that have access to files, etc.

So why is it that when I’ve seen information security audits of remote access systems (VPN, extranet applications and the like), I see tests of the systems themselves, but not of the processes that the systems provide? Put another way, when we test VPNs for security, are we focused only on the security of the system, and not on whether sensitive information is allowed to pass undetected through the system?

A client once showed me the results of their recent security audit which included a test of their VPN security. Their VPN system provided an excellent client-based connection to the corporate network and an optional, client-less SSL web interface to file folders. The security tests they showed me - which were conducted by a world-class auditing firm - verified encryption of the VPN services, proper patch management, proper account management, the usual drill. After reviewing the results, of which the client was very proud, I asked who was using the client-less file folder access. Anyone with domain access, they replied. What machines do they use to get the access, I asked. Machines that don’t belong to us, they said, slowly realizing that the previous audit had missed something critical. They were providing their staff a means for relocating sensitive documents to machines that the company did not control. What were they thinking?

The SSL file access service was provided for a specific rationale that management had not thought through: to give people access to confidential information when they did not have their corporate machines available to them. My client had spent months and tens of thousands of dollars encrypting laptop hard drives, placing location beacons on them in case they were stolen, and deploying an excellent client-based VPN solution. They wanted to be sure that if sensitive information needed to go mobile – to leave its safest location – that it would arrive in a safe container. When they chose to provide added convenience to their company’s employees using a client-less file access system, they provided a bypass around much of that security. Now sensitive information was allowed to be placed on any device known to human kind.

More frustratingly, they realized that their auditors gave a strong thumbs-up to their VPN solution. But having audited the system, the auditors neglected the actual risk posed by the VPN’s client-less option.

When auditing any conduit to system or file access, we must consider extrusion, or removal of information. Do the remote access systems we are auditing allow for removal of sensitive information without detection or prevention controls? Even if our audit subjects can vouch for the people who access the information, can they vouch for the container (laptop, desktop, phone) that extruded information is sent to? Are banner messages shown to users who log into remote access conduits informing them that the systems they use to access information may be audited? Are connections logged and reviewed for unexpected clients? Are allowed clients (the CEO’s home computer) audited for compliance with security standards?

There are a lot of complex issues to be resolved here, and management will squirm as they try to resolve them. Can they audit a hotel’s business center computer after it accessed the VPN? If not, then do they white-list IP addresses or MAC addresses? Do they block client-less VPN access all-together, or limit what a client-less connection can provide? Are session caches (including login credentials and downloaded information) erased after a remote login session? Do they insist that employees who use their home computers to client-less VPNs be subject to audit, even physically at their home offices to be sure that sensitive print-outs are not stacked in garbage pails, or unencrypted storage devices are not misused?

When an organization provides remote access to protected assets, they also provide a means to extrude the information they are protecting. Auditors must focus on controls around data extrusion as well as the security of the systems themselves.

Developments in data privacy laws may draw security auditors into conducting risk assessments. Are you prepared?

For organizations that operate under FISMA, HIPAA, Gramm Leach Bliley or PCI, risk assessments should be familiar territory. All of these regulations and standards require that a risk assessment be performed to help organizations identify risks and prioritize their security controls. But new legislation, such as the Massachusetts law 201 CMR 17.00 and the HITECH Act extends the legal requirement to conduct risk assessments to thousands more businesses and organizations.

For organizations that have not already driven their security programs from risk assessments, their security auditors will be likely candidates for conducting this task. This can present two challenges to auditors: how to conduct a good information risk assessment, and how to do so while retaining independence as an auditor.

I have found two very clear and authoritative guides for these issues. The first is an information risk assessment method offered by CERT. OCTAVE comes in three flavors, OCTAVE S for small organizations, OCTAVE Allegro for organizations that cannot provide many resources to execute a full scale information risk assessment, and the OCTAVE Method, which is the full OCTAVE risk assessment program. Each of these flavors provides organizations with workshop-style approaches for identifying and assessing risks, enumerating vulnerabilities, and deriving risk priorities from these data. OCTAVE offers template forms, guidance instructions and presentations to conduct productive workshops, and collect the essential information for an actionable assessment. While there are many other risk assessment and risk management methods, such as the reliable CobiT approach, OCTAVE provides very easy-to-use templates and guidance documents so your first time out as a risk assessor is valuable and authoritative.

In some cases, auditors face independence issues when they conduct risk assessments. After all, determining whether a risk assessment was effectively conducted is a common audit test. To help balance these roles, The Institute of Internal Auditors provides authoritative guidance on the matter in a document entitled “The Role of Internal Auditing in Enterprise-wide Risk Management .” The document presents the auditor’s risk management activities (including risk assessment) within a scale of involvement, grouping the activities into three categories; those that are core to audit responsibilities, those that can be conducted with appropriate safeguards, and those that may not be undertaken by auditors while also retaining their independence.

Auditors should feel comfortable offering risk assessment when properly prepared to do so, but not at the cost of also providing reliable audit results. The IIA guidance provides a very clear way to delineate between these two responsibilities.