Should you create a separate, supersecure network?

A safe deposit box protects your valuables -- so why not shield your critical data in an ultrasecure network? It's not that simple

All companies that have been pwned by APT (advanced persistent threat) adversaries look for ways to fend off future threats. My best recommendations: Do better patching and use whitelisting. As I've repeated ad nauseam, these two countermeasures together would reduce the risk of successful malicious attacks by 99 percent in most environments.

But no one listens to me. Most companies want to concentrate on everything else. Often, their plans include creating highly secure "crown jewel" networks.

[ Beware the 5 signs you've been hit with an advanced persistent threat. | Prevent corporate data leaks with Roger Grimes' "Data Loss Prevention Deep Dive" PDF expert guide, only from InfoWorld. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

Here's how it works: The company inventories all services, determines which are of the highest criticality, then goes about securing those assets as best it can. Assets include a mission-critical application or service, the servers and infrastructure that supports it (Active Directory, DNS, user accounts, service accounts, network equipment, and so on), and all the workstations that connect to the application or service. That's a lot to consider and to secure.

The idea is that the crown jewel assets should be protected at a much higher level. The question is how to do that and how many crown jewel networks are needed.

With most APT attacks, the bad guy ends up compromising an Active Directory domain controller, gets all the password hashes, and has complete ownership over the network using pass-the-hash tools. Most companies want to create one or more separate, additional networks so that a single domain controller compromise won't compromise every corporate asset.

Now entering the high-security zone
The crown jewel network isn't an alien idea. Many companies have at least one, and every military branch has had multiple, high-security networks for decades. But at the same time, over the past two decades, most have looked for ways to consolidate multiple networks into fewer networks to lower cost and management overhead. The new awareness of APT (I say "awareness," because corporate networks have been penetrated by APT for five to 10 years) is causing corporate leaders to reconsider the previous consolation trend.

That's a good thing. Simply not having any permanent members in the Domain Administrators group, which is prerequisite to successful pass-the-hash attacks, will also work. But if you can't do that, creating multiple security domains does reduce risk.

If your company is considering adding more networks, you must first ask how many security domains you'll need. Many companies decide to build a new, single, highly secured crown jewel network and place all mission-critical services there. I like this model because you get additional security minus the overhead that comes with having too many networks to manage. The overall thinking is that if all your mission-critical services are indeed mission-critical, they should be managed under the same security policies and managed in the same security domain.

But even if you decide to have only one new supersecure network, you must plan and work hard to make sure the old ways used by the bad guys to break in will not work on the network. Otherwise, it'll be a lot of effort without a payoff. For maximum security, you can always go Pentagon-style, with physically separate air-gapped networks that don't connect to the Internet.

Most companies may yearn for highly secured, separate networks, but they can't afford the cost and time it takes to run separate cables or wireless access points everywhere. A good compromise is using separate VLANs. Although VLAN separation can be breached, it doesn't happen often in the real world.

1 2 Page
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies