Layered Security

Full Title or Meme

Like the layers of an onion, security can be layered with Security Gateways between the layers.

Keep High Value Assets inside layers of protection.

Context

How can you protect your Assets? Zero Trust Architecture or De-perimeterization are recent buzzwords in the media. The thinking goes something like this: It is really hard to keep your enterprise network fee from penetration, so don’t even try. The answer being pitched for today is to protect every server in the enterprise from attack whether it is on the internet or on the corpnet. Now that strategy works well where assets are static objects and the entire authorization process can happen in a single server. This letter is about high value assets that need to be used among a collection of servers that really do need to trust each other in performant collaboration. Servers that need to interoperate within a protection perimeter. Here we call the servers and networks within that perimeter a Stronghold that is within an inner layer (2) of the onion. The only higher layer (3) is in protected hardware that is not allowed to release any of its interior secrets. Mediaeval castles had a keep for protection of high value assets from any incursion that overwhelmed the castle walls. Similarly a server stronghold may have secrets, like cryptographic keys, that have very high value to the enterprise if released or compromised, for example the keys used to generate internal certificates used to validate the authenticity of the enterprise products. These may need stronger protection if the stronghold is attacked.

The attached figure shows the layers of protection with the data inside the enterprise shown as (1) mid value, the data in the Stronghold as (2) high value and the data in the Keep as (3) very high value. These levels are sometimes labeled as (1) confidential, (2) secret and (3) top secret. There are two paths described there. The first path shows how requests pass into the deepest layers of security. Once a request is generated inside the enterprise that request is passed through the following layers of the onion:

1. The request needs to be generated inside the corporation (Layer 1)
2. The request must pass through a gateway which understands the privilege level of the requestor
3. The request goes to a process inside the Stronghold (2) that only talks to the corp gateway.
4. The request is processed and passed to a service that only talks to the keep gateway.
5. The Keep gateway understands the privilege level of that Stronghold service.
6. The request is then passed to a service inside the Keep (3).

Several important points to the path taken by the request are:

1. The “Kill Chain” is a set of independent processes all of which can block (kill) an attack.
2. The gateways, (aka Firewall or Intrusion Protections Services, IPS) can evaluate the source, destination and contents of the request to be sure that all are valid.
3. Processes only talk to gateways at one level. They should never be configured to talk up the layer protection chain and down it. That means that process is a distinct link in the “kill chain”.
4. The results of processing the request should also pass back through the full “kill chain” to give many opportunities to block exfiltration of high value data (aka Data Loss Prevention – DLP).

Completely independent of the request “kill chain” is a set of nested security and network monitors, aka Intrusion Detection Services (IDS). The security monitor within each layer of the onion will have full knowledge of every server, network device, user, role, application and service permitted to operate at that level. As each of the various components performs their function during the day, they are expected to report the results of each operation to the security monitor which can validate that event against the list of know good events. Every event that does not fit the known good pattern is expected to trigger a security incident for evaluation. It is known that some vendors combine intrusion detection in the same box as intrusion protection. This combination solution is better than no solution, but it is not best practice. Going back to our metaphor of Stronghold, the IDS is like a patrol man walking the beat looking for trouble and the IPS is like a gatekeeper that blocks entrance of the trouble into the Stronghold. Mechanisms to Protect devices in the Stronghold Devices in the stronghold must be as secure as feasible. That means two things: they need to be built of secure components and they need to maintain that security in the face of daily uses that could compromise security. Our recommendation is to create an image (aka Golden Build) to show how the application should be constructed in the first place and then deploy a configuration management and reporting support system that allows updates and verifies that all devices within the stronghold remain secure. At the physical device level we recommend the use of trusted platform modules (TPMs) that can be used to create an attestation as to continue health of the physical server as well as secure boot for all VMs to be sure that they still enforce the discipline of started from known good code. Add to this a means to test the configuration of every VM in the stronghold. One mechanism to perform this test is the “Desired State Configuration” feature of PowerShell 4. Another mechanism is the System Center Configuration Manager (SCCM). Whichever mechanism is chosen for a give stronghold, be sure that it is attached to a good Security Information and Event Management (SEIM) application monitor.

Problems

Several attacks against Layered Security include:

• Use of the same password for different layers by admins. It was found that if Active Directory were deployed at each layer, that the same (default) salt layer was used so that the salted hash from one layer would work on an inner layer.
• Even for air-gaped security layers it is possible to infect the device used to move data from one layer to an inner layer.

Solutions

The major take-away for this paper should be a better understanding of these concepts:

1. De-emphasis of the protection perimeter at the enterprise level increases the need for the creation of other protection perimeters within the enterprise.
2. When a significant amount of processing is needed with high value data, the need for a stronghold to contain that processing should be self-evident.
3. A kill-chain between the attacker and the high value assets should be both long and strong. Unlink a load bearing chain; a single link can completely kill an attack if it cannot be bypassed.
4. Some attacks, both malicious and accidental can be initiated by insiders.
5. Some data is just more valuable than other data and needs deeper protections.
6. Protection is needed for incoming requests to be sure the attacker cannot use the data as well as for outgoing requests to provide for data loss protection.

We haves been supporting de-perimeterization with StrongNet protection solutions for many industries throughout the years. We have now added protections to the devices that hold high value assets that can provide a complete end to end solution for business security challenges. Contact us to learn more about our extensive experience in Strongholds for internal data loss prevention or in StrongNet for external data loss prevention.

Read More
Security Intelligence: Attacking the Cyber Kill Chain – The SANS Institute
Practical Risk Analysis and Threat Modeling Spreadsheet from the SANS institute
Cyber Threat Metrics – A Sandia Report – March 2012