Whether you call it layered perimeter defences, virtual teams, secure compartments, secure enclaves, or even virtual LANs, the concepts share the same goals: isolate and protect information assets from unauthorised access using more than single perimeter protection.
Security: A conflicting objective
Easy access to shared information directly competes with the objective of information security. At one end of the spectrum all computers are networked together and information is shared freely within the organisation, at the other end all computers are isolated from each other and no information is shared. Clearly reality must lie somewhere in the middle, based on a risk analysis for each and every information asset.
Organisations want the benefits of a cost-effective shared network infrastructure yet they also want to isolate and protect "compartments" which contain information assets, computers, and people. In some cases, there are even legal or contractual requirements to separate information within a shared infrastructure. So what has prevented the widespread adoption of the compartmentalisation method? The required technologies such as access control, firewalls, user provisioning, etc, have been available for several years. The barrier to widespread adoption is usability and manageability.
Lessons learned from the Titanic
An easy way to understand the concept of secure information compartments is to use an analogy.
Every modern ship is built with watertight compartments so that when a leak is identified within a compartment, it can be quickly sealed off. It is better to flood one or more compartments than to lose the ship, passengers, and cargo. The same applies to information security. Relying upon a single network perimeter (hull) to protect the whole organisation (ship) is very risky. If an unauthorised person is able to penetrate the single network perimeter, they can often roam at will across the complete network. Of course most unauthorised access comes from within the organisation thus making a single network perimeter futile.
Designing secure compartments is one thing - making them easy to operate and manage is another. Keeping with our naval analogy, the Titanic had sixteen "watertight" compartments, which contained electric doors that could be closed from the bridge. So why did it sink? Here are three facts and their information security equivalents:
1. The "watertight" compartments were not actually watertight; each compartment was open at the top, so when the water poured into the first compartment it simply overflowed into the subsequent compartment, much like an ice-cube tray. The information security lesson: even the slightest error or design oversight can create an opening in the perimeter.
2. The ship's maintenance crew reopened many of the watertight compartment doors to make it easier to rig the bilge pumps. The information security lesson: It is human nature for people to override security policies and settings to make their jobs easier.
3. Only 1/3rd of the watertight compartment doors could be automatically closed from the ship's bridge. As a result, the remaining 2/3rds of the doors had to be closed on-site by hand, which was a time-consuming and difficult task at the best of times, let alone when the ship is taking on water. The information security lesson: It is impossible to prevent all security breaches, so at least have a quick and automatic or semi-automatic method to push-out and activate pre-defined emergency policies on selected or all devices.
Additional challenges of information security
One additional complication is that many-to-many relationships exist within an organisation in that people are authorised to use more than one information asset and multiple users also access information assets. For example, members of an ever-changing team access a project team file server and a sales database will be accessed to varying degrees by different arms of a sales team. These many-to-many relationships make it very difficult to isolate and protect information, as the boundaries of each compartment are often complex to identify and describe.
The second major complication is that organisations never stand still. User specific access to information resources changes continuously. Most organisations cannot even hope to keep up-to-date in this never-ending race. What happens when an employee changes their role, gets promoted or demoted, or even worse laid-off or fired? How long does it take the organisation to update access control to all information assets?
Potential solutions
Most network security technologies require administrators to interact with network security devices using a technically oriented low-level "language". Administrators must use this technical language to implicitly define the specific commands/script to command and control each network security device supplied by each vendor. Unfortunately, it is the business layer, which is under constant change, not the physical layer that is relatively static. The result is that it is almost impossible to keep a secure compartment up-to-date with business and organisational changes.
What is required is a "language" and modelling environment, which allows business administrators to explicitly define security policies at the business-level, independent of the underlying network devices, which execute the policies.
Forth generation programming languages (4GL) enabled programmers to become significantly more productive and effective than was the case with 3GL. The same is also true for information security management. The ability to manage information security at the "business-level" or "logical" level allows administrators an order of magnitude increase in productivity, effectiveness, and consistency. After all, computers excel at being able to perform the complex tasks of analysing, translating, and distributing business-level security policies into specific configurations for each and every impacted network device.
James Janisse – Synartra (www.synartra.com)
