*Note: this article was originally published on Security Focus, 16-Jan-2002. I have updated it in places to be more relevant to the current world constraints.
Like a raging cancerous growth the Internet has evolved and expanded in a rapid, unplanned and chaotic manner. Initially, little consideration was given to network security, and inevitably it was added as an after-thought. Because of this we are left with an eclectic and rudimentary assembly of best practices and tools to use for Internet and network security.
A consensus of opinion in the security industry believes the future lies in better communication between security systems. This is the first step towards a biological network. What better way to handle security on a living-breathing and highly complex network than by modeling it after a biological system? Many of the security mechanisms already exist on our networks, even the concept itself has been addressed or considered by various other groups and organizations. The missing piece of the puzzle is an open and common mechanism for communicating between these devices and security mechanisms.
The following sections will address and explore the general concept of Biological Network Security and review some ideas about a common Biological Network Security protocol. I believe that Biological Network Security (BNS) is a logical improvement in security, and the most important factor to make BNS work well is Open Standards.
Vendors and projects are already implementing these concepts, but they are doing it in a proprietary and independent fashion. It is impossible for these proprietary programs to inter-operate and live together in a shared network environment. Unfortunately, without an open standard this will continue to be the case — it is in the self-interest of vendors, which is not necessarily in the customer and Internet's best interest, to build their platforms in a manner which enhances their own product line.
Network vulnerabilities will always happen, but to deal with them well, it may be valuable to have a common and open standard is available for security systems to inter-operate on an Internet wide scale.
How much security is enough?
Every day Network Security Administrators live with the problem of deciding how much security should be sacrificed, in order for the users to accomplish what they need to. The reason for this revolves around the desire of the Security Administrator to keep the network clean, in an environment where it seems every week a new application finds a way to violate and exploit the network. Ultimately, the Administrator is responsible for any security problems, but the users do not care — they simply want to do their job.
In some environments the Network Administrators have been able to work the system and a tight security policy exists — but the users suffer. In others the opposite is true, and instead of the users, the network suffers (and perhaps the organization does not care).
The underlying desire of the administrator wanting to secure their systems revolves around the common belief that if locked in a big enough vault, everything is safe. Harden your systems to the extreme and nobody can use them — not even the intended users. But what is the value of a computer system if not for its users? This paradox is a monumental and often even moral dilemma for many.
Perhaps instead we should be reconsidering the underlying belief that you secure a system by hardening it. Why must you harden a system to make it more secure?
What if instead you do the opposite and lower your barriers, possibly even permiting intruders — if you have decent monitoring and rapid response mechanisms in place?
This is the core precept of Biological Network Security. It is ok for your systems to be open and easy for the users to use — if mechanisms are in place to detect and respond to malicious abuse.
The term Biological is defined as something relating to life and living processes. Living systems are built to deal with intrusions (such as a virus) through many processes, including multiple and often parallel responses such as a seek-and-destroy group of anti-virus cells, in addition to the body's ability to isolate and sacrifice components to attempt to contain the problem.
This is the key difference between biological systems and hardened computer systems. Can we work it out such that it is acceptable to allow some intrusion, as long as the immune system is capable of rapidly responding and handling the problem? Biological Network Security is simply another way of looking at security processes and considering them in the context of how biological systems handle security.
Is the Firewall Dead?
Key to most security infrastructures is the idea of a perimiter firewall, building a form of network security known as Perimeter Defense. Firewall architecture for Perimeter Defense is quite simple. Design the network so only a few access points exist, and then put a firewall at these points where network traffic is moderated and controlled.
This is much like castle building in the medieval period. To protect a city and its occupants a wall was built around the city, with a few gates provided to allow regulated access. If a city was conquered, the walls were simply rebuilt higher and wider. This is much the same approach people are taking with Firewalls; and ultimately it is ignoring the true problem, let alone causing a major inconvenience for the network users.
Prior to this publishing I was involved in keeping a high profile website alive during a Distributed Denial of Service attack (DDoS) in our own datacenter. Unable to do any more on our end, we contacted our Internet Service Provider. Their solution? Turn off our Internet connection for 30 minutes. They found with other customers experiencing the same problem that this thaumaturgic process "solved" the problem, since after the lines are brought back up everything seemed to be alright. Of course this tossing of chicken bones did not solve the problem, it simply alleviated a current result of the problem (too many connections), but it was the best they had to offer.
The key to Biological Network Security is the ability to detect and react to undesired behavior, communicating it upstream all the way back to the origin. With the Internet's current infrastructure any single data center is limited to their own network for control when reacting to a security problem.
At best, a good security infrastructure will have enough Intrusion Detection Systems (IDS) and Web Application Firewall (WAF) to be able to identify and help block undesired traffic at their border (the barbarians at the gate), but even this is likely to be a manual step. Anything better requires a cocktail of frustrated network administrators, ISP help desks and sleepy hold music.
Meanwhile anybody with a grudge and access to a zombie network can hold your systems hostage. Biological Network Security systems proactively seek and lock out this unacceptable behavior. This is different from a firewall as it extends beyond your own network and the "border" concept promoted by firewalls.
Just as biological systems use additional forms of protection (clothing, bullet proof vests, gloves), firewalls remain a valuable component in a Biological Network. However, their functionality needs to be integrated and coupled with the other components of the security network.
A Living Network
Many of the systems to be used in Biological Network Security already exist today. In a Biologically Secure network the IDS (host-based or network based) detects and sends out an alert. This alert is forwarded to a Central Analysis System (CAS) which follows three steps: Determine Threat, Act, Propagate.
- The threat level can be determined from many factors:
- Previous trends of the attack
- The origin of the attack
After the threat level has been determined, the CAS may decide to act on the alert. In this case, it sends a message to the targeted system, firewall, router and other perimeter defense mechanisms, requesting them to deny access from the origin to the targeted services and protocols.
Immediately a warning flag should go up in everybody's mind about possible exploits of this communication, and there certainly should be a strong mechanism of trust built between the CAS and the local network it is considering.
After the internal auto-immune reaction, the CAS then propagates the alert up the wire to its next node. This can be an ISP or a greater component of a WAN. The next node up the network then considers the alert in its own context, can act on it if it wants to and then propagates it onward. Ultimately, the alert should be propagated to the origin network, which can then potentially isolate the offending node, send up an alert to the administrators or even consider the alert as un-trusted, and disregard it. If the offending network does not support Biological Network Security processes, the ISP of the offending network could also receive these alerts and consider them as complaints.
Into the Details
Presently, it is rather premature to claim an exhaustive discovery of Biological Network Security processes. However, this author believes a few seed ideas will help stimulate discussion and momentum. As explained in the previous section, the cornerstone of the architecture as proposed so far is a Central Analysis System which acts as a brain for the local network. The protocol has two main elements: Events and Actions.
Event messages include Intrusion Detection and Anomaly Reports from network, host or other detection systems. Events are either sent from an origin (Intrusion Detection System) to its own CAS, or can also be propagated from one CAS to another.
An action message should include the ability to alter a configuration within acceptable parameters. This includes Access Control List changes (firewall or router) and signature updates (to automatically keep an IDS up to date). This is also the most vulnerable part of the entire architecture because without adequate measures in place to guarantee trust, it could be possible to forge false actions.
As with any other form of security, one of the most critical elements of a Biological Network Security protocol will be trust, how is it established, how it is managed and how it functions securely.
Consider a common Internet DMZ with a web server farm, an application server farm and database servers. This DMZ would also have networking and security infrastructure components including firewalls, switches and routers. Intrusion detection systems would exist in all locations: On each of the servers, on the firewalls and on the switches. The servers have host-based intrusion detection software which monitors not only the local networking stack but also the processes and filesystems. Firewalls monitor networking along with user behavior through the state engine. The switches have an IDS which can monitor anomalous behavior from a larger multi-host perspective. All alerts from these systems are reported, without prior analysis, to the CAS.
Somebody engages a slow port-scan of the network, attempting to determine where resources exist. The CAS begins to notice the behavior from various alerts, and determines the current threat from the origin network to be mild.
However, the portscan is followed up by a DNS zone transfer attempt. This alert is sent to the CAS from the DNS service, as the IDS may not be in a place to detect it happened. The CAS decides this alert, coupled with the portscans, increases the threat level to moderate, and a warning message is generated, but no actions are taken. The warning message is propagated as an alert to the CAS's next level; in this case the network provider (ISP). The message is forwarded on through the internet until it arrives at the origin network, which is a pool of home internet connections. The CAS at the ISP for the DSL connection records the Biological Network Security alert along with the customer currently subscribed with the origin address, but also does not immediately act upon it.
A little later an attack attempt is sent to one of the WebServers in the DMZ. The DMZ CAS decides to increase the threat level once again, and also decides to act upon it. It generates action messages and sends them to the DMZ firewalls, blocking access from the origin address to the DMZ network. It then propagates a new alert with the higher threat level. At the DMZ's network provider they receive the alert and since a high level of trust has been established between the client CAS and the network provider's CAS, they also act upon it. They send action messages to their routers, also blocking the origin IP address to the client's network. They then propagate the alert onward.
However, the next level up does not have trust established with the origin of the alert (the DMZ), so while they do propagate the alert they do not act upon it. Eventually the alert is propagated back to the DSL provider where it originated. Their configuration allows them to trust a certain tier of CAS (determined through 3rd party certificates), and so they decide to trust the alert and block access from the offending DSL connection to the requesting remote DMZ. They also file the alert along with the customer record, as an official complaint.
Another angle may be that the later attack attempt was at an entirely different system, but that system too propagated a message back to the ISP who decided the combination of different mild threats was too high of a risk.