Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection program success depends more on prudent management decisions than on the selection of technical safeguards. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.
OK - so this is not the most exciting subject for anyone I know - but on the other hand, it is necessary and often critical to an effective protection program over time. It is required by standards, prudence, and in some cases legal mandate. And of course without adequate and usable documentation, there is a high tendency toward protection failures.
As a manager, you naturally have the responsibility for documentation along with everything else, perhaps more so than anyone else. When your documentation is put to the test it is generally too late to do anything about it, and of course until then, it may seem like more of a waste than anything else.
To understand just how important documentation is, I should really explain my consulting rates. I get paid by the hour for consulting. I charge a lot and I'm worth it, and one of the reasons I am worth it is because I seem to end up working on lots of networks that have absolutely no documentation. I can tell you that it is a real pain to walk into your company when you have just lost or fired your top network folks with the job of making sure you are not vulnerable to them or others who might choose this weak time for their attack.
I was called into a local company for an 'emergency'. No details about the emergency were provided ahead of time but I was asked if I knew a lot about networking. I indicated that I could probably handle anything they needed for the short run and that my associates were available for assistance if special expertise was required. So I was engaged right away and off I went into information security nowhere-nowhere land.
When I arrived the real issue was explained to me. The entire IT staff was being fired as we spoke. They needed me to 'secure' their network before the end of the meeting where they were firing everyone. So I asked about what their network was comprised of and I found out... they didn't know. So I asked for the documentation and I found out... they didn't have any. They knew that they had some T1 lines and could direct me to the computer room. They knew that they also had a firewall at a remote facility - and they could take me there.
And that was all they knew...
Their PIX firewall (fortunately?) had the password written on a slip of paper on the console - documentation at last! I was able to get a bypass password for another key device from the manufacturer and I was able to figure out their internal IP address setup by looking on several computers and tracing wires manually through their building. And I was able to take them mostly off-line without disabling critical functions within the required first hour. We managed to figure out enough about what was going on to prevent access to the internal fraudulent email servers and the other web server that didn't belong there.
And over the next day or so enough of it was documented to be able to figure out how to do most things we wanted to do without having to crawl through floors sniff cables to figure out what was where. They were operating in a stable configuration and the rest of the investigative process could proceed.
So the lack of documentation cost them many thousands of dollars and placed them at increased risk for a few days. It may not seem that bad, but you weren't working the 18-hour days and crawling under the floors for lack of a piece of paper. Of course, you weren't getting consulting fees for it either...
Of course I don't know if their systems were really protected or not, because I was making reasonable guesses and hunting things down physically as well as I could. But if someone was trying to hide something, it would not have been all that hard to do so. I could have put a wireless hub in a wire tray or above the ceiling and it would not have been found in our rush to try to get things reasonably safe.
And there was no way to examine the software on most of the systems. And the backups were in an exposed location so anyone could have walked away with a copy of lots of information and I would not be able to tell because of the lack of documentation on what was supposed to be there. And the inventory of what was there was not well documented, so there was no way to check for things like missing computers.
The list goes on and on. And this is only a case where there was no attack or other harmful software agent that might cause configurations to change or files to be deleted.
This example of poor documentation leading to problems in an incident is only the tip of the proverbial iceberg. Documentation is required in order to demonstrate compliance with policy (in order to avoid gross negligence), to show that training has been done, to help in incident recovery, to allow independent audit, to facilitate job changeovers, and the list goes on.
Documentation is required for almost every facet of any technical endeavor, but somehow in security, it seems to be almost universally inadequate. If you really want to get a sense of this, you should try teaching a technology class over the Internet. I use this as an example because, unlike a live class where you can show your students how to do things and interact on a live presence basis, classes over the Internet are generally supported more by documentation than by interaction. As a result, failures in documentation become starkly clear.
My most recent example is a daily one right now. I teach Internet-based graduate classes at the University of New Haven, and as I write this the firewalls class is in full swing. Building the first firewall (two are required for the course), students have incredible amounts of difficulty in finding the documentation required to understand the commands and options and how to use them. We direct them to the online 'manual', but it is practically useless unless you already know most of what you need to know. They then result to searching the Internet for information on how to get their firewall to work. A lot of the information there is just plain wrong, some of it is for the wrong version, a lot of it is out of date, and as hour after hour passes, frustration increases and deadlines cannot be met.
Documentation is usually both critical and poorly done, and you almost never find this out until it is too late. There are many reasons for this but we are not here to blame folks.
We offer little in the way of cures for this. Management has asked for documentation from technologists for many years, and technologists have provided what they seem able to provide, but it seems like a missing skill in the skill sets of most organizations and individuals.
There are some exceptions to this rule, but they are few and far between. Training in documentation, awareness of the requirements for documentation, and exercises that require its use seem to help in the short run, but over time, things fall apart, unless we keep them up.
About The Author:
Fred Cohen is helping clients meet their information protection needs at Fred Cohen & Associates and Security Posture and doing research and education as a Research Professor in the University of New Haven's Forensic Sciences Program. He can be reached by sending email to fred at all.net or visiting http://all.net/