• United States




Should you create a separate, supersecure network?

Jul 30, 20137 mins
Access ControlApplication SecurityData and Information Security

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.

How separate do you want it? If you’re going to create one or many new, separate networks, another big question is how you’ll provision and deprovision users, devices, and other resources.

With a single network, provisioning is typically tagged to an HR system. An employee is hired, and this kicks off a manual or automated process of adding the new employee’s user account to the domain. If the process is automated, where should the “root system of trust” (the systems trusted with kicking off the provisioning and deprovisioning) reside?

For example, if you leave your root system of trust in the original — possibly compromised — network, can it be trusted to provision services into the new, highly secured network? The answer is a resounding no. You can trust systems of higher integrity and assurance to provide data to lower-integrity systems, but not the other way around.

In reality, most companies don’t have a choice. Rather, they have two suboptimal choices: Either they allow an untrusted root system to help with provisioning the new network, knowing it might be compromised or lead to a new compromise — or they end up with a new root system for every new network, which is costly and hard to maintain over time.

In fact, this decision needs to be made for every additional network. Will the new networks use one or more existing services from the existing network or only rely upon completely new services? Services that are necessary to run any network include provisioning, help desk, security, incident response, auditing, PKI, email, printing, and more.

When figuring out exactly which services from the old network are needed in the new network, most companies may consider adding new groups, but come to the realization that creating truly separate networks is harder than it seems. It’s a light-bulb moment for all teams that have to discuss more secure networks.

Real-world compromise Generally, companies end up creating a model where shared services are either left in the existing security domain or end up in a single new network shared across all other networks. They may also create a hybrid: Some networks with shared services, while other networks have none.

I’ve only seen a few companies that decided to duplicate services in each new network. All in all, these sorts of decisions aren’t easy. In fact, it’s among the toughest decisions IT can make in any company.

Whether to have one or more new network domains is up to each company, its culture, and its risk tolerance. There is no right answer. Pick what you think will work for your company and live with the positives and negatives. You can still change the design later on. In fact, write that into the first design’s known outcome: “Needed changes will be determined by lessons learned from the first one.”

If you ask me, rather than spending all that time creating ultrasecure networks, you’ll find much more value in concentrating on how your company is compromised in the first place — then aligning your defenses to best combat those exploits. That way, you can become a true security hero.

After all, creating a secure network is a ton of work — and if it’s truly secure, it will probably require duplication of effort. What not apply those efforts across the board to the existing network instead?

This story, “Should you create a separate, supersecure network?,” was originally published at Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at For the latest business technology news, follow on Twitter.


Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author