Is There an Alternative to Reperimeterization? What Will You Tell The Judge?
Last week I had a chance to share my views on the value of reperimeterization with the folks at TechEd Israel, which was held in Eilat. I'm always a bit nervous about discussing reperimeterization because I've been talking about the concept for years, and there always seems to be a bit of fear and loathing among the audience when the topic comes up. Why? The issues always seem to revolve around the complexity of setup and maintenance of the reperimeterization solution.
I've talked a bit about reperimeterization a bit on this blog. If you haven't read my previous entries, the concept of reperimeterization has as its goal the logical or physical separation between assets that belong to different "security zones". Assets that belong to a security zone of lower trust should be logically or physically separated from those of higher trust. Or, another approach is to separate assets of higher value from those of lower value. The key is to create multiple perimeters, where monitoring, logging and reporting can take place between the perimeters. This provides you an audit and forensics trail in the event that a data breach takes place between any two perimeters.
While the concept makes sense to me and a few others that I've shared these ideas with, many others see the process as painfully complex. They say that the complexity of the solution will lead to an increased risk of errors, which could create a seriously security problem. My response has always been that the moderate increase in complexity leads to a much greater increase in security, and provides the auditing and reporting that is so critical in an increasingly regulated environment.
In fact, industry regulatory compliance issues may be the most compelling reason to implement a reperimeterization solution. For example, suppose you put together a network based on the old concept of "external untrusted, internal trusted". This is the most common network security model in use today, and unfortunately it is based on a threat model that was valid almost a decade ago. Today's network threat model has changed significantly, in that your greatest risk of attack is now from insiders, not from intruders entering your network from the Internet.
Now imagine that your network was attacked from the inside. The File Server on your network was compromised by someone who shouldn't have had access to that server at all. The file server and the attacker were both on the same "trusted" internal network, so you didn't have any access controls preventing the attacker from reaching that file server. In addition, the same attacker was able to compromise the SQL server. Again, the SQL server is located on the same "trusted" internal network as the attacker.
Next thing you know you're in front of the administrative law judge for the FEC or FTC or any other regulatory body to which your company is beholden. The judge just heard from an expert witness who described how a correctly reperimeterized network would have prevented the data breach. You are asked why you hadn't implemented a reperimeterization plan for your network. Do you think the judge is going to be convinced that "it's too hard" or "it's too complex" is a viable answer to why you didn't do it? I don't think so.
However, there may be other ways to create a virtual reperimeterization plan. I'll talk about that in my next blog post. Until then, I'd like you to think about the value of reperimeterization and whether the potential complexity is worth the increased security it can provide your organization.
Thomas W Shinder, M.D.
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP - Microsoft Firewalls (ISA)