Over the last several years, computing has changed to an almost purely
networked environment, but the technical aspects of information protection
have not kept up. As a result, the success of information security programs
has increasingly become a function of our ability to make prudent management
decisions about organizational activities. Managing Network Security takes
a management view of protection and seeks to reconcile the need for security
with the limitations of technology.
A lot of people think of the tax collector when the work audit comes up. I had one of those and it certainly seems like a negative association to me. Others think of financial audits, compliance audits, and so forth. In most of these, people are asked the most embarassing possible questions by people who understand very little about what these people do in their work, and the objective is to find some mistake or malicious act that has resulted in some financial harm to the organization. If nothing is found, the auditor must not have been looking hard enough.
I wish I could tell you that IT audit is much different, but to most people, it is not. I figured it might be worthwhile to give you a view from the inside of an IT auditor's head - my own - about what we do and why we do it this way.
Whenever I do an IT audit activity, I always seem to start at the same place. It is a system I have found effective over many years of doing information protection activities, and like an old friend, I like to revisit it every so often. It's also the basis for this series of articles, so it serves to keep things in context.
This set of viewpoints was originally developed over the years of my consulting practice, and was formalized for the first time in writing during a protection posture assessment for a major financial firm in the early 1990s. In preparation for my 1995 book Protection and Security on the Information SuperHighway I reviewed a substantial number of other peoples' reviews of the information protection field along with much of my own work and the projects I had done for clients up till that time, and confirmed that this set of viewpoints seem to cover the field.
When I use this as the basic outline (with lots of details filled in of course) managers who sit in on reviews ask me if I could give them a copy of my set of questions. One director said: I'd sure like to have that checklist. I explained that it's not really a checklist, it's just a list of areas to consider, and I generate the questions based on their answers. He accepted that and I managed to avoid giving away one of my most valuable pieces of intellectual property.
No. I'm not going to print the whole list of questions here. Besides, I generate my questions based on your answers. But I will give you the outline I use - and even fill it in a bit:
At first, many business people are somewhat hesitant to answer this line of questions. They think I am prying and asking about things beyond the scope of the information protection issues they have asked me to explore. After all, what could the line of business they are in possibly have to do with their firewall, or their policies, or that acquisition they are asking me to help them do due dilligence on?
The explanation is really quite simple. I cannot understand what is important and what is not important unless I understand enough about what things are used for and where value lies.
Although I usually don't have to go any further than this, I will explain it a bit further. Your firewall is only a technical mechanism intended to protect some other underlying value. Your policies only characterize certain philosophies that are realized by the people in your corporate culture. The company you are acquiring is not just a bunch of hardware and software, it is people, and systems, and ways of doing things. Effective protection is attained by a mix of different factors that have to fit together properly if they are to be effective.
If a hierarchical company buys a company that has no formal management structure, there will be information protection implications that management should be aware of. None of these things typically make the buy no-buy difference, but they are all part of the canvas on which we paint the protection picture. Use the wrong paints, and you get a poor quality picture that doesn't stand the test of time. Do your job right and you will have effective and cost effective protection.
I think I have said this at least a few hundred times in the last several years, but it bears repeating. Threats, vulnerabilities, and dependencies combine to produce risks. I can understand the vulnerabilities by understanding what protection you have in place (that comes next), and I can understand the dependencies on information an information technology based on what you tell me about your business, but vulnerabilities and dependencies are only important in the context of threats. If the only threats of concern are hackers, and I use the term narrowly in this context, and your business is producing newspapers, it is unlikely that they risks are very high regardless of the way you implement protection. In this situation, the chances are fairly high that I will advise you not to hire me.
I use a list of threat profiles that are described in some detail on my Web page under the heading "threats". I enclose the list here for completeness, but leave the details for the web page. They are, in alphabetical order, activists, club initiates, competitors, consultants, crackers for hire, crackers, customers, cyber-gangs, deranged people, drug cartels, economic rivals, extortionists, foreign agents and spies, global coalitions, government agencies, hackers, hoodlums, industrial espionage experts, information warriors, infrastructure warriors, insiders, maintenance people, military organizations, nation states, nature, organized crime, paramilitary groups, police, private investigators, professional theives, reporters, terrorists, tiger teams, vandals, vendors, and whistle blowers.
Many clients fail to see the difference between crackers and crackers for hire, and it may be a bit too subtle for most of my readers, but I plod along in my own little world and try to find evidence of what threats will or won't play a role in causing harm and understanding the implications of the defenses in terms of their efficacy against these threats.
One of the most interesting things I find is that the threat profiles that some companies consider frivolous or outrageous others find dead on target. For example, most US firms are not concerned about police as a threat, while many multi-nationals view police in certain countries as a serious concern.
Finally, the existence of a viable threat doesn't mean that the client wishes to try to protect against it. For example, relatively few companies today want to protect information against military actions, even though military actions have a large impact on many large multinational corporations. So there may be a decision made by company representatives to ignore certain threats even though they are real. This is a risk management decision, and I review it in those terms.
In this part of the audit, it is the auditor's job, within the constraints of time and effort available for the audit, to run all the details to ground. First, the auditor has to ask about what is in place, then the client has to show these things to the auditor, then the auditor has to verify some portion of it independently from the client's demonstrations.
Since running everything to ground takes a long time, I usually choose something that, based on experience, is likely to be a problem. It's even better if I haven't ever looked at this particular thing in this particular context for this particular company before.
As an example, in a recent audit, I decided to look at the wiring connecting a firewall to the Internet and corporate intranet. It is normal for me to look at some portion of the connections and ask questions about what is connected to what, but in this case, I decided to follow all the wires, where practical, to their end points. As lunch time came and went, we were still following one fiber optic cable under raised floor, through several rooms. Finally, we arrived at a box that nobody on the firewall team even knew existed, and lo and behold, ...
This activity where you try to run things to ground is usually the part of IT audits that takes the longest and produces the most frustrations.
If this sounds like some tricky university exam intended to trip you up, that's about right. It is my job as an IT auditor to understand and report on the limits of your protection capabilities relative to the threats and business requirements. If I can't find any flaws, the next attacker that comes along had better not find any either. The fewer flaws I find, the deeper I look, and the deeper I look, the harder your people have to work to make sure I find no flaws. If in the end, we run everything to ground, and we find that the only flaws are those that risk management has determined to be appropriate for all the right reasons, your system is as good as it can be, and your audit will come out squeeky clean.
I have an occasional nightmare about going out on an audit and finding everything as good as it can be. Sometimes I stay up late at night finding new vulnerabilities that nobody else knows about or updating my internal audit tools against the potential for such an event. While I think that it makes me a better IT auditor to do this, I have never had to use any of my best tricks on an actual audit - and I have audited some pretty high security places in my day.
If you look a little bit closer at this last part of my description, you might see one of the sources of friction that occurs during an IT audit. It is a matter of pride for the auditor to find a problem, and it is just as much a matter of pride for the defenders undergoing an audit to have none found. History and workload tends to side with the auditor because defenders are almost always underfunded and underexperienced while most good auditors have far more experience than the defenders and it takes a lot less in the way of finances to find a few holes than to block all of them. This is one of the reasons you hear the defenders moan whenever the auditor starts to write something down.
Here's a near quote from a recent audit: Oh no, look at that, he's writing it down, I shouldn't have said anything. Defeated again by his own honesty, the defender acted like like he lost some sort of battle. I consoled him by telling him that he was helping his company find out why more time, money, and effort are required to support his efforts. It didn't seem to cheer him up very much.
He was being a little bit humorous, and we were on fairly jovial terms, but ultimately, it's not a very good idea for an auditor to become too friendly with the client's personnel. This is another important point about IT auditing that many people seem to largely miss. While it is always important to be on a reasonably firnedly basis with your clients, becoming too friendly in an audit situation is never good. It clouds the judgement. This may be one reason that people dread the auditors.
I think that point and counterpoint, question and answer, relate back to the Socratic method that lies at the core of much of our modern social views on the value of the loyal opposition in bettering all of our lives. I also think that IT audit is a helpful tool in ding a better job of protecting information assets.
While I hope I have clarified some muddy waters, I fear I may have muddied some clear ones today. I hope that any insight I may have brought you about the hows and whys of IT audit are helpful. But perhaps more importantly, I hope that you see some value in the purpose and methods of IT audits and that it helps to encourage you to do regular IT audits - both internally and externally.
About The Author:
Fred Cohen is a Principal Member of Technical Staff at Sandia National Laboratories and a Managing Director of Fred Cohen and Associates in Livermore California, an executive consulting and education group specializing information protection. He can be reached by sending email to fred at all.net or visiting /