Computing operates in an almost universally 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 have screwy notions about computers that are promoted by and in the media, and many of them get embedded in our psyche without being rationally reviewed. One of the most important ones to understand from a standpoint of managing network security is the fallacy of the time assumptions people commonly make about computers.
Now it turns out that when it comes to computers, people who don't do complex computations for a living almost always think that computers are far faster than they really are. We commonly hear about attacks that happen in a millisecond or computers that run at the speed of light. Now it turns out that there are bad things that happen in milliseconds and computers that operate at the speed of light. The bad things are typically explosions and the speed-of-light computers are optical computers - but neither are the things we tend to deal with on a day-to-day basis - and they certainly aren't the things we defend against in network security.
In this article, time is of the essence. My goal will be to put some more rational notions of time out there for you to consider - with an eye toward understanding things like how fast you have to be - how fast the bad people are - what can really happen when - and what you have to prepare when. The following list is at best approximate, but I hope it gives you a sense of the time taken by attackers and defenders to do different tasks and eliminates any notion that attack or defense happens at anything like the speed of light.
The LAND attack - or similar low-level small network packet attacks can be started at one machine and cause an outage in another machine in less than a second - but not much less. If the attacker is on the same LAN - and assuming that they are ready to press the 'enter' key when we say 'go' - it takes about a quarter second to load and run the program - a quarter second for the program to get the packet onto the wire - and a half second before the packet causes the other system to crash. That's about 1 second in the best case.
To take down 100 computers in a LAN, and assuming it's all automated and they are all vulnerable to the LAND attack, the parallelism gives you a big advantage. It can happen in under 30 seconds if no other traffic is underway and you have programmed it well.
If a remote computer has an easily defeated network service - such as a vulnerable sendmail or a remotely accessible share or a pre-loaded copy of Back Orafice - it takes only a few seconds to get into the system.
If you are logged into a computer and have a script that can plant a long-term reentry hole in the defeated system by down-loading the exploit script and executing it this takes something like 5-10 seconds.
Testing one telephone line for the presence of a modem takes about ten seconds - twenty seconds of you want to get some information about what the modem is connected to. That includes the time to get dial-tone, dial, get an answer (or not get one and give up), differentiate a modem from a non-modem, negotiate a baud rate, get some information on the way the modem reacts and what sorts of prompts it gives, and so forth. This assumes, of course, that the remote site is not trying to deceive you with false modems, false delays on modem answering, and so forth.
Guessing a trivial password - for example a default password on a router takes a few seconds. The typical process is to access the router, determine what type it is, look up the default password in a file, and try using it. Cleaver attackers with time to automate do this in a matter of seconds with automated remote access, type detection, and table lookup, and exploit. The actual exploitation of this vulnerability takes longer because in order to take advantage, you need to figure out what to do with router access based on the goals of your attack.
Getting infected by a computer virus when you run an infected program takes less than a second in most systems. Modern viruses are usually a bit slower than the earlier viruses despite the increased speed of computers. The reason appears to be that the designers have taken to more complex viruses and higher level languages.
If you have a planted vulnerability in a PBX, you can probably exploit it for a free phone call in twenty seconds or less. A typical process would be to dial into the PBX (10 seconds) and direct it to dial another number and connect you to it (another 10 seconds).
The worlds best lock pickers can pick a typical lock in a matter of seconds. I am not one of them, but even I have picked some locks (while acting as a locksmith) in under a minute. Don't ask me to pick one of your locks though - I just don't do that any more.
Opening a window or using a credit card on a real cheap lock takes only a few seconds. Windows are often 'locked' by a mechanism that is easily pushed aside, while doors that close without a dead-bolt and don't have an inhibiting mechanism are trivially opened by sliding a credit card between the bolt and the door frame. I hope you don't have these locks because every 8-year-old has seen this technique used on television.
In a second or two, someone can pick up a rock and throw it through a window. I was at one site where that had recently planted a rock garden with 5-pound rocks outside the large plate glass windows that separated the parking lot from a 'secured' area that didn't have window alarms or surveillance cameras.
Detecting a bad password when entered to a login prompt takes about a half a second on many systems. Of course detection is far different than doing anything about it. For the most part, this appears in a log or is passed to a more centralized intrusion detection system for analysis. A really fast system may be able to disable a users' access to a network in a matter of seconds, but of course this opens up the whole environment to large-scale denial of service attacks through reflexive control. The reflexive control attack - in this case - typically takes only a matter of seconds per user as well.
Detecting an attack against a honey-pot or similar deception-based detection system takes on the order of a second or two if the attacker is using automation. Discriminating a serious attack from a door knob turner takes at least a few seconds - typically five to ten. The reason it is slower with a manual attacker is that the attacker takes longer to do things that indicate a serious break-in attempt.
Shutting down network services to an attacker if you have hair trigger detection and reaction pre-programmed takes only a second or two. This tends to be very sensitive to reflexive control, so in any such system it will also be vital to re-enable services quickly as the attack wanes and to assure alternative access.
Making an access control decision on a file takes something like a hundredth to a tenth of a second on most systems. This includes several disk lookups and some small amount of computation.
A burglar alarm or a fire alarm sounds in a matter of seconds and can alert the authorities in five to ten seconds if it is on a direct connect. While this is a best-case scenario, systems that react quickly are also susceptible to false positives.
A handgun takes only a second or two to draw, aim, and shoot if you are good at it. The best quick-draw experts are incredibly fast at this, but a typical person takes anywhere from 3 to 5 seconds to achieve this - which is why quick draw experts tend to kill their opponents in gun fights.
If you are standing at the only external connector, you can disconnect your systems from the Internet in a second or two. We have a demonstration where we detect an attack and take immediate action to sever the attacker's efforts. It involves pulling out the RJ45 connector and a 10-base-2 hub. It works really well - till the people in the room start to complain about not getting any access for their work any more. We then go into more sophisticated defenses.
Sending an automatic email in response to an attack typically takes only a second or two. I used to do this automatically Internet Holes - Incident at All.Net and it is quite effective. I no longer do it because it consumes too much in the way of resources for a small operation such as mine which gets a large number of attempted entries. I do advocate it for organizations of larger size, however.
Paging a response team member takes only ten seconds for the computer under attack. That is to say, the computer under attack can get the page sent in only about 10 seconds. The actual pager beep might not happen for some time after that because of delays in the queuing system used for sending pager messages and because the recipient may not be listening or have the pager turned on.
It takes a second or two for a person to make a snap decision in an emergency situation. If completely automated and ready to go at the click of a button, it usually takes a few seconds to order a computer to carry out such a decision. With a lot of training and practice, we can reduce this time by a bit. Of course snap decisions without much information are just about the same as automation.
Scanning one computer system for open IP ports takes from one to five minutes depending on the details of the scan. Just running through all of the 32,000 or so possible port numbers for TCP and UDP packets sending a single minimum-sized packet for each port and ignoring the replies involves about a few million bytes of information, which takes nearly a minute to actually get sent on a T1 connection. More realistic analysis includes the intervening infrastructure, listening for returns, limits on the sending system's memory, speed, and several other factors. In practice we are talking about several minutes for a minimal scan and far longer for a more thorough scan.
Executing the same attacks that work in seconds against a single computer will take hundreds of seconds against a network full of computers - simply because they have to be repeated hundreds of times. Even with multiple processes doing different attacks, practical systems take several minutes for even a simple attack across a class C network (255 IP addresses) and hours across a class B network (65,000+ IP addresses).
Manual break-in with a default user ID and password often takes a minute. Typing in the remote system information, doing DNS lookups (if you don't use addresses instead of names), establishing the connection, awaiting the login prompt, typing the user ID, awaiting the password prompt, typing the password in, and waiting for a command prompt is a typical sequence. I have automated scripts that do this for a networked cluster of systems and it takes at least 30 seconds per system when the whole process is automated.
Manual planting of a permanent reentry hole by a decent attacker takes only a few minutes. The typical process includes down-loading the pre-designed Trojan horse, moving the original software, planting the Trojan horse, removing evidence from log files, and testing the Trojan horse to make sure it works properly.
Guessing a non-trivial but easily guessed password - for example a word used in the user's Web pages, typically takes a few minutes. The information (such as the Web page) has to be loaded, a program is used to analyze the contents to form a password guess list, the list of guesses is sorted in order of which to guess first, then the attack starts. Actual login attempts - if automated - take on the order of 30 seconds each, so 10 can be tried in 5 minutes or so, and will likely be detected.
Using a program like Crack to guess the first few thousand passwords it tries takes a few minutes, and the vast majority of passwords cracked with these tools are found in the first 5-10 minutes.
Spreading a computer virus to other systems, for example, when you run an infected program received in email and forward it to someone else who is on-line and waiting for it, takes a few minutes. Longer in most corporate email systems because they don't do email as quickly as other Internet hosts and timesharing systems do.
Even I can pick most cheap door locks in five to ten minutes with $20 worth of tools, and some of the harder ones with $200 worth of tools. Of course getting to the lock may take quite a bit longer, and if it's a good lock, it takes me forever - so I used alternative methods when I did that sort of thing.
Alternative non-damaging break-in technologies typically take on the order of a minute or two. For example, there is a thing that goes through crack at the bottom of a door and reaches up into the room and turns the knobs from there. This takes a minute or two if you are practiced at it and it's not some really strange setup.
In a minute or two, someone with a battering ram can get through most thick doors - or break the casing that holds the door in place. If you have a bunch of folks, this gets even quicker. Of course you probably have to get the battering ram out of the car trunk first.
A rapid reaction guard force in a reasonably secure site can get to any location where a break-in is sensed in a minute or two. A slower force might take 5 to 10 minutes, and local police and fire fighters typically arrive within 5 to 10 minutes of a dire emergency call being answered - at least when emergency telecommunications is working properly - and after you wait on hold for a while if you are in a big city.
A systems administrator who knows their stuff, has the right tools and knows how to use them, is logged in waiting for bad things to happen, and gets notified right away, might be able to cut off an attacker within a minute or two. With proper tools, traceback of the attacker and notice of the remote site's systems administration people might also be done in a minute or so.
Shutting down network services using remote router control commands typically takes on the order of a minute once you have done it a few times. Bringing it back up might take a bit longer, and waiting for router tables to update to reflect the re-enabling of the network can take hours to days because of, among other things, network caches designed to improve speed.
Automated recovery from packet flooding attacks typically takes systems between one and fifteen minutes. For example, the default daemons that come with many systems cause a 10 to 15 minute delay when a service is thought to be 'looping' before re-initiating the service.
Checking log files for recent break-in attempts - given a decent set of tools - typically takes a few minutes for a single user system. On the system I use the most, there is a display of recent events of interest that updates every minute or two. If it shows something of interest, I investigate further. The follow-up usually takes 3 to 5 minutes unless something serious has happened.
It takes only a few minutes for a typical email to get to its recipient - if things go well and the other person is sitting at their system. Most corporate email systems take 15 minutes or so. On average, I get email about 5 minutes after it is sent, but I often don't get to look at it for several more minutes, and when I'm away or asleep, it could be hours or days.
After a beeper message is sent, it takes a minute or two to get to its intended recipient during heavy usage periods. I have used an email-based beeper for demonstrations, and 3 to 5 minutes is a typical response time between when an email is sent to the beeper service and when I actually get beeped.
Rebooting a typical computer system - when it was properly shut down - only takes a minute or two. If it was not shut down nicely, it often takes 3 to 15 minutes, and if there is a minor problem that must be manually addressed, it typically takes a bit longer. The major delay comes from checking disks for consistency.
In emergency situations, it takes a few minutes for most people to reliably make reasonably good decisions about complex issues. Depending on how immediate the consequence is, people may make hasty decisions with limited information, and a well thought out decision that weighs all of the factors can take an indefinite period of time.
It takes me several hours to come up with this monthly article, and several more to type it in and review it. This month it has taken several days of effort, but that's because it is full of facts that have to be manually verified.
Manual break-in by people without much expertise takes several hours against a typical computer system. This was shown in papers written several years ago by a professor in Norway who had his computer security class do unique attacks as part of a class project.
Getting into a facility, walking around, seeing what's there, and taking a few important records can take from 30 minutes to several hours depending on the facility. This varies greatly from facility to facility - especially if you are trying to not get caught. For one large client, in about an hour we were able to enter, obtain lots of financial records, access mission critical information systems with highly confidential data, and leave unquestioned in about 2 hours.
Manually looking for flaws in an operating system setup takes hours - with decent tools it takes 10 to 15 minutes. The manual examination process is rarely done well and is usually not very thorough compared to automated tools, but since all of the high quality automated tools I am aware of are proprietary, the average administrator has little choice.
Getting enough information through human engineering to do a financially substantial break-in to a company typically takes a few hours. Published examples include making a number of calls to find the right person to engineer and getting enough information to be effective at gaining their confidence. Then, when confidence is gained, the person provides access to the specific items of value necessary for the attack. This is quite different from the off-handed social engineering used in television examples.
Researching a target over the Web takes several hours for a quick overview. Depending on the depth of the search and how specific the information sought is, a more thorough overview can take several days,
Getting some address information, maps, and facilities overviews for a target site usually takes several hours. In one recent case, I got a set of addresses from the Web, contacted the local zoning authority, and found that I could get building plans in a few hours by going for a visit. I gained this information in less than 5 minutes. Unfortunately, I would have had to visit a place that was several hours away to get the physical documents and didn't have the time to do it in that case, but I am told this will all be put on the Web before long. Time frames change with technology.
Getting useful information from a bugging device typically takes at least a few hours - because most of the things people say aren't the things you are looking for. In some cases it takes days, weeks, or even months between the planting of a listening device and gaining useful information.
Guessing a 4 digit passwords used in a PBX system for a given mailbox - if you use an array of auto-dialers to do it - takes about 6 hours - (9999 * 10 seconds to exhaust the space takes about a day - divided by 24 if you use a T1 to attack systems - and divide by two for the average time till the password is guessed).
If several individuals are involved, it often takes a few hours to get an informed decision about how to respond to an incident. This typically involves a meeting or two, several phone calls, and a write-up of some sort.
Any attack not previously experienced normally takes at least a few hours to understand and prepare a defense against. For example, when you see suspicious packets coming into your firewall and haven't seen anything like it before, it might require a search of the Internet RFCs to find out what the packet could be used for, some review of processes and software using the particular packets, in-depth analysis of packet content, and so forth. Once people have experienced a particular attack, they tend to recognize it in seconds and be able to verify it in minutes. Experience helps a lot in this area, and that is one of the reasons that I advocate doing penetration testing with the defenders watching every move as it happens. It gets the defenders the experience they need to change hours of effort into minutes.
Getting a search warrant takes at least a few hours, at least in the United States - and it better be important if the judge is going to be awakened at 3 in the morning.
Sweeping a room for a bugging device takes several hours. While a simplistic sweep can be done in minutes, with modern surveillance technology, it is not unusual for it to take 8 hours or more to do a thorough search of a conference room, and it is not guaranteed to be fully effective even at that level of effort.
Big city police normally arrive at a call within the first hour on a busy Saturday night, although there have been cases where it has taken a lot longer. A simple burglary where the thief has left the premises might generate a response in the time frame of 4 hours.
Testing one exchange full of telephone numbers for the presence of modems takes about one hundred thousand seconds - or about 25 hours - if you do it one number at a time. This was accurately reflected in the movie War Games and hasn't changed much since then.
It takes a few days to get all the information you need from open sources to attack the infrastructure of a business and bring it to its knees. For example, suppose you were trying to take down a manufacturing facility. You might start by getting the address, visiting the site, getting brochures, getting a building plan from the local building registrations office, and so forth. If they give tours, which many do, you might walk through and see what you can see. Then you might check who their service providers are for power, water, telecommunications, and so forth. Figure out who takes the trash out and when, who the suppliers are, and how they screen employees. With this, you should have all you need to take them down for quite a while.
It takes a day or two to get to know employees well enough to start to elicit some really personal information from them without seeming too forward. Some people make fast friends, and some people just hit it off with each other, but if you go for the really personal stuff too fast, you typically offend.
It takes a few days to plan a decent attack if it is to have measured effect and controllable consequences. During the Gulf War, according to the many news reels and other shows and books on the subject, the planning cycle for air strikes was 24 hours, and they certainly wanted to get things done as effectively as possible - and had the technology tools to do it well. Typical red-team efforts require several days to several weeks of planning.
It takes a few days to program a few new attacks into systems, test them out, and prepare for a serious attack if you are already in the business of attacking other people. The typical process is to build a copy of the important parts of the site under attack, try a lot of different things, figure out what works, and practice for a range of different contingencies.
It takes a few days to get things like user IDs and passwords to systems by lying about identities and employment - unless the victim is really clue-less. The reason is that most companies take a few days to process such requests, enable accounts, update servers, and otherwise do the support work required to grant access.
Severe weather generally happens over a period of days. While a tornado can show up at a moment's notice, this is only true under conditions that operate on far larger time frames. There are of course exceptions - such as flash floods - which happen very quickly and Sunamis which are not really weather in the sense I was discussing.
It takes days to relocate a small computer center. The planning process underlying such a move is usually much longer, but I have moved several computer centers involving from 20 to 100 users in a day or two.
Spoofing and masquerading can take days of effort to gain much success. For example, in order to access a system protected by TCP wrappers which only allows access from one IP address, you might have to try spoofing every IP address along the way. Intelligence can reduce this level of effort, but the intelligence process also takes time - typically in the same general range.
Effective bribes and extortion with high consequences typically takes days to accomplish. In the trivial case, you simply walk up to the door and offer the guard a $20 to let you in, but this rarely gets the real job done. Extortion means intelligence because pushing buttons at random won't work very often and is likely to get you caught.
Viruses often take days to achieve spread from an initial source to a desired destination. In studies done of long-range spread, weeks to months were not unusual for a virus spreading through the general computer population. More directed viral attacks can be used more specifically and spread with more directed efforts.
Repairs exploited to replace, remove, or copy information usually take several days. The typical process is to get the computer in for repair - which takes a long-term effort in order to become properly pre-positioned - copy and modify its contents - and return it to use. The process involved people pulling systems from active use, shipping or carrying them to you, and physical manipulations of hardware.
Data aggregation attacks often take days to get desired information. For example, watching the total salary of a department before and after a new hire shows up in order to get information on the new hire's salary means checking over a period of time. Unless you are in the process, you won't know exactly when the data will be entered into the database or reflected in the summary results.
Guessing all of the 4 digit passwords used in a PBX system for a given mailbox - if you use a single auto-dialer from your PC takes about a day.
It usually takes a few days to get support staff on site capable of fixing subtle errors in systems. It often takes a day or two just to get the right person on the phone. Even if you have an 8-hour support agreement with a major provider, this does not get all problems resolved in that time frame. I have encountered several occasions where it took 3 to 5 days to get a part in this circumstance.
It takes a few days to get and install new systems when old systems are seriously damaged - unless you have a good disaster recovery program in place that lets you do it more quickly. Even companies with off-site recovery contracts often have delays caused by simultaneous events.
It takes a day or more to get an express delivery package from place to place.
It takes at least a few days to get new telephone numbers assigned, new IP addresses, and similar minor infrastructure changes. This is largely because of inefficiency at the highly centralized organizations that control critical assets such as these. In practice, the actual operations involved in accomplishing this take only a few minutes.
It takes days to get an initial background check done and months to get a really thorough investigation completed. This is a process that is hard to short cut - simply because it takes time to interview people, the sources of information are not all instantaneous, and the people that do these sorts of things aren't waiting around with nothing to do when your request to shows up.
It takes at least a few days for most information security folks to get a meeting with top management in the best of circumstances - unless the crisis is really extreme.
It takes at least a few weeks in most cases to get a job at a victim's site. There may be rare exceptions to this, but I have only seen this in small family-run businesses with new hires that were already known to the owners or who were a friend of the friend and members of the same community. These are very low risk circumstances. It often takes months to get a job, and the odds of getting one at the place you want to attack are not as high as might be imagined.
Creating and exploiting a fictitious personage takes weeks to months, and sometimes years. Fictitious people can be created quickly, but it is their reputations that bring value to their fictions. Reputations take time to build. If you have a well-embedded organization you can add a new fictitious person in a few days or weeks without a lot of difficulty because other fictitious people become the reference points for claiming their legitimacy.
Dependency and error analysis and exploitation often take weeks to months to carry out. In the case of dependency analysis, I know from experience that it takes weeks to complete when the customer is helping you as well as they can. Doing this without their assistance no doubt takes considerably longer. Error exploitation means waiting for an error of the right type - which may take weeks or even years. I know that in cryptography during World War II periods of weeks were often involved before an error in the way a new system was used became exploitable.
Salami attacks and kiting schemes usually take weeks to months to carry out, and in some cases fail if not operated for extended periods of time. In the most widely published cases, these efforts took place over periods of months to years.
Creating and exploiting false updates take from weeks to months to accomplish. The famous case of false updates sent under the auspices of being from a popular computing magazine in the early 1990s was an effort that took several weeks to complete.
Strategic deceptions almost always take weeks to months to carry out, and sometimes are planned for periods of years. The many examples from World War II are good starting points for studying this. The Gulf War's major deception involving the deployment and use of troops traveling over the western desert route to envelope the Iraqi troops took weeks to set up and days to carry out.
It takes at least a few weeks to prepare a large-scale attack on a distributed business. Simply add up the logistics from several of the attacks listed above and it will give you an idea of the effort involved.
It takes weeks to months to get passed the large scale effects of damage to reputation from a publicly announced attack. For example, the widely published attack on CitiBank of several years ago is still widely cited even though the defense was largely successful and the loss was within normal expectations for a bank of that size.
A major relocation often takes weeks to months to accomplish. Such relocations of computing facilities is normally done in stages with services shifting over one at a time until the entire operation is moved. In cases of bombings, disaster recovery sites are often used for extended periods and many services are simply eliminated rather than recreated.
It takes weeks to rebuild a network of a few hundred systems screwed up during an attack, and often takes longer to get the users back on track. Data recovery is often infeasible for portions of the loss.
It takes weeks to months to make major infrastructure changes. For example, getting a major electrical power change or adding high-volume telecommunications often involve processes over many months.
Consider this. If an attacker is going to get a job so as to become an insider in order to corrupt information in your systems, how fast do you have to be on the defensive side and what techniques can you use? Suppose the attacker is going to try bribes or extortions to get the same job done - how does this effect your analysis.
I have often said and written that threats, vulnerabilities, and consequences drive protection measures, and I have talked about issues of time repeatedly in this series. Now consider the ways you might defend against different threats based not only on the consequences, but based also on time frames for attack and defense techniques. It should put a whole new light on the subject.
In next month's article, I am going to extend this notion for better detail, but for now, spend a month and consider these points.
My major conclusion from this discussion is quite simple. It is that some protective measures have to be pre-planned and pre-positioned in order to have any hope of being successful, while other protective measures can be purely responsive in nature. All of this is driven by time, and with this article, we have some measures of times to use as a starting point.
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 /