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.
I haven't brought up deception for protection in almost a year now, and I thought it might be worth another look. In the last 10 months, I have seen an increasing focus and interest on deception-based protection, and it looks like the field is about to become a major force in information protection.
In the last year, deception has appeared as a topic for at least one session in at least five major global security conferences. At the Computer Security Institute Network Security Conference, there were two sessions back to back. The HoneyNet project has appeared in scores of newspaper articles and includes an increasing number of sites dedicated to early understanding of emerging attacker techniques and tools. Dick Clark, of the White House, speaking at the Black Hat conference indicated that legal aspects of monitoring in honeypots may be an issue, but in military circles, deception is increasingly becoming a core aspect of information operations as it has been a core aspect of electronic warfare since before World War II.
Deception technology have also started to take off. While one recent patent application attempted to cover all of deception in information networks and ignored the technology that has been in place for many years, at least 5 recent patents have been filed for specific deception technologies that are likely to be the basis for tools we will soon see in industry. The intrusion detection community is starting to look seriously at deception for enhancing the differentiation between simple errors and intentional attacks. As a response technology, deception appears to be making great strides as well. Even deception toolkit, which is free, now has contenders who are charging hundreds of dollars for simple port emulators. Deceptions are starting to be applied increasingly in areas where other tools fail, like insider protection and as a second line of defense when first line defenses fail. And some are using deception just because they are tired of the imbalance between attack and defense. In short, it looks like deception is a technology on the rise.
Underlying the use of deception, there are some basic knowledge areas and skills that must be understood to do the job well. If deceptions are to be effective against serious attackers, these will ultimately be the battle grounds. There is a long history of the use of deception in warfare, and the same skill and knowledge sets that made some commanders succeed at deceptions while others failed are present in the information technology arena.
Deception starts with a deception plan. The plan is typically in terms of the desired effect on the target of the deception. If you don't have such an effect in mind, then you cannot really plan a deception very well. Part 1: It seems obvious, but you need to have a well defined target. Is it the insider or the Internet attacker? Which of them? The ones trying to do network scans, or the ones who have targeted your company for an attack? Is it a kid looking for something to do, or a professional who wants to extort from you? Part 2: Are you trying to fool them into thinking they succeeded or failed? Or are you just trying to discourage them? Perhaps you are trying to catch them. In order to do this well, you will need an experienced deception planner. Deception is about psychology, and it helps a lot to have a psychologist on your team. It is particularly helpful to have one with experience in this area - a psychologist with expertise in deception and experience in deception planning.
Someone who knows computers and networks and attackers is also an important facet of the deception. Most deceptions fail if they are too simple or too complex. For example, if there are 8 steps before the attacker hits the deception, it is likely they will never get there. If there are 2 steps and they are obvious, they might get there, but if they are cleaver they may well figure out that this system is a honeypot. In fact, the honeynet people tend to encounter folks who look for characteristics of honeypots and walk away from them. Of course this sort of knowledge comes with experience, and very few people have much of it, but how do you get experience without trying it? That's how I got mine.
Also, someone from management capable of making decisions relating to liability and risk management is a necessary team member. Hopefully this team member will also be able to facilitate coordination of deceptions with normal operations. This is critical because history shows that deceptions improperly coordinated end up fooling some of the folks you don't want to fool. A classic example is the people responsible for checking your network for vulnerabilities. The reports must go somewhere, and the person who has to understand what they mean also has to be able to tell which of them are deceptive. If they don't the picture they get may be way off. I know that when I have people scan my networks I don't tell them what is and is not a deception, but I do evaluate their results in light of the projection I was trying to create.
There are some core technologies of deception today and more such technologies are on the way. In the work I have done on this I started from the 'outside' and worked my way 'in'.
The first deceptions were designed to fool automation at a distance thus forcing a human to get involved. Deception toolkit is an example of this. From there I worked on making such deception large scale, more realistic, and harder to differentiate from normalcy. These are very effective 'at a distance', against simplistic automated attackers and intelligence gathering systems.
The next level of deception has to work against a more expert attacker with more advanced tools at a shorter distance. Typically, this is at the level of a local area network which is shared between the attacker and defender. This means that in addition to responding realistically to probes at the level of timing and MAC protocols, except in switched networks, there is an additional requirement for simulating realistic traffic. Simplistic traffic simulation is easily detectable by free tools like EtherApe and Ethereal, while simplistic responses are rapidly found by Nmap and Nessus. A good local deception must be able to adequately fool these tools and their operator or the real systems and ports will rapidly be differentiable and the deception will have little effect on attacker workload and produce little in the way of useful detection information.
Then next level of deception operates against insiders with legitimate access to systems or outsiders who have gained access. At this level, systems calls must be adequately mimicked or environmental factors made adequately consistent with the desired deception plan for the attacker to believe in the deception. For example, most honeypots are spotted by their lack of normal legitimate user activities. Of course an excellent deception against these attackers would be a real system that appears to have no users when the standard system commands are used to see what activities are ongoing in the system. Internal deceptions are more widely varied and far more complex than external deceptions that focus predominantly on a small number of easily understood variables associated with network traffic. Internal machine state is extensive and hard to control. There is a lot of information legitimately available to the average user and it is hard to identify inappropriate actions for some classes of users like programmers without causing large numbers of false positives.
The content level is perhaps as complex as the operating system level. It is far less complex when it comes to the technical issues, but far more complex because it demands that any information involved be verifiable to the attacker. In other words, it has to be so realistic that it cannot be reasonably differentiated from reality by the attacker, and yet it is a deception. An example of such a deception might be a situation in which the attacker believes that a data field is encrypted because the content they view seems to be random, and yet the actual data is not encrypted, but rather stored elsewhere. This is of course a technical deception example, but just as relevant is a deception such as the one that formed the basis of the famous book 'The Man Who Never Was', part of Operation Fortitude during World War II. In this deception, a dead drunk from London was posed as a dead courier whose body was found and whose papers were analyzed, with the result of bolstering Hitler's belief that the D-Day invasion would not be at Normandy.
Feedback is often cited as the most important aspect of deception that is most often neglected. In order to be effective at deception, it is vital that there be feedback from the target to the deceiver. If there is no feedback, you may only be fooling yourself. A good example was the 'Man Who Never Was'. In this case, the ability to decode encrypted Enigma messages and insiders provided feedback on the deception and the extent to which it was working against Hitler. On the other hand, even though Hitler had feedback in the form of intelligence operatives in England, the feedback was faulty because the British had found and 'turned' all of those agents. Deceptions within deceptions are common.
Coordination is certainly a critical success factor for any significant deception. For example, without some involvement of the staff who runs your network, a network deception is likely to create problems for someone in network operations. The classic example is auditors who do testing of networks as a part of their audit process. If they are caught up in deceptions, they will be fooled and produce an audit report with the wrong information. This then goes to management who might decide to cancel deceptions or to 'fix' all of the identified vulnerabilities. This can run into significant costs and inconvenience and can upset staff who feel left out or who believe that real vulnerabilities are not being fixed.
Clarity of purpose would seem to be obvious, but this is largely lost on most who undertake deception for the first few times. Without a clear goal, deception may be interesting and fun, but of little real value. It is like lying for the fun of it. When you are a young child you may undertake it to see what happens, but as adults, honesty is part of the social contract. When broken, we tend to get market collapses and jail sentences. While a lie told to a criminal to gain safety is normally hailed as beneficial, lying to the general public about something of value in order to gain an advantage is often called a fraud. With clear purpose, most of the deception planning can proceed with reasonable precautions and often excellent results. Without it, we just get chaos.
I think it is highly likely that we will start to see a great deal of interest, research, and application of deception for information protection in the coming months and years. From more and more honeynet projects to deceptions as major components of firewalls, it will be coming fast and furious. You can reasonably expect:
Firewalls will have embedded deceptions designed to defeat external intelligence processes.
Unused IP addresses will have internal and external deceptions to fill the space with false targets thus concealing the real ones.
Unused ports on computers will be configured to lead to deceptions both to mitigate intelligence attempts against those systems and to gather more information for intrusion detection and response.
Internal deceptions of services and programs at the operating system level will become widespread to reduce risks associated with insiders or those who have gained unauthorized access to systems.
Granularity of deceptions will lead to more fine grained controls than are currently available in most operating systems.
Internal controls will be based on normal usage patterns and detect and react to any unusual patterns with deceptions.
Application level deceptions will be used against authorized insiders abusing their authority.
These are only examples of technologies that are being tested and perfected today. The future will likely see a far wider range of these defenses implemented in increasingly diverse locations and with a wider range of methods.
I have heard lots of nay sayers talk about this technology in negative ways. They ask about legal issues. There are none that cannot be easily addressed with a bit of prudence and self control. They ask about legitimate users being caught up in deceptions. If properly done, this never happens - at least it has never happened yet and people have been using these techniques in increasing quantity and more diverse applications for several years. They ask about entrapment of all things. They don't realize that only the police can 'entrap' someone and that the only punishment is that the bad guy doesn't end up in jail on that charge. If a corporation does this, it is perfectly legal and the prosecution can proceed unhindered.
And the silliest of all... won't it make the attackers mad and get them to attack me even more? This is the height of foolishness. First off, if you do your deceptions well, the attackers may not even know they are being deceived. Second off, the more they attack, the easier it is to get them put in jail. Third on the list, I have lots of attackers mad at me all of the time, and it has no effect at all on my infrastructure. What really happens is that they give up and try elsewhere. Forth and perhaps most important, if good people don't stand together, bad people will win. It's really very simple. If we all do deceptions, it makes it harder for the attackers everywhere. If only some of us do it, it means that the successful attacks will be made against those who don't do it, they will suffer, and those who do it will prosper. Finally, if this argument held water, why wouldn't we just open up the vaults and let the attackers in. After all, why will deceptions make them any madder than the fact that they can't break in? They make the threat because they are afraid of deceptions, and that's exactly why we should all be using them.
The field of deception is way too complicated to describe fully in an article of this size, but as a network security manager, you should be aware that this is the coming trend. It looks now like it's almost certain to be a major force in the world of network security, and it's time to start looking at it in a serious way.
It takes time and understanding to do deceptions well, and you had better get started understanding it before it hits you as a surprise. The attackers understand deception, and as a defender, you had better understand it as well, or suffer the consequences.
Finally, I have essentially ignored the issue of counterdeception in this article, but you better not ignore it in your plans. Not only do you have to assure that the attackers can't easily counter your deceptions, you also need to start doing a better job of countering theirs.
About The Author:
Fred Cohen is researching information protection as a Principal Member of Technical Staff at Sandia National Laboratories, helping clients meet their information protection needs as the Managing Director of Fred Cohen and Associates, 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/