I know a few folks who are into this little microtrend of having chickens and chicken coops. They all have a similar story. Things were going fine, then one day a fox/weasel/raccoon found its way through the coop protection and they woke up to a coop full of headless chickens.
John Lambert says " Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win." I am a big fan of checklists as a way to avoid mistakes, but they do not have a role in design or telling you what to do. That's a very important nuance for defensive architects to grasp.
Symbols are very important in how we process things. The classic DMZ design shows a layer of protection between the big, bad Internet and the soft chewy enterprise center. One problem with list thinking is that it can lull you into a false sense of security. Like Brian Snow says the worst thing is not being insecure, its assuming you are secure, acting accordingly when in fact you are not secure.
The DMZ concept by itself is not the problem. However there are knock on effects of the mindset that we must guard against as security architects. The DMZ conjures up an image of highly trained, highly capable people and technology rigorously scrutinizing inbound and outbound flows. Keeping the inner sanctums safe. Reality has diverged from this.
The other problem is that while the DMZ is an important layer, it neglects to address one the most fundamental questions in all of engineering - failure modes. What happens if some malicious code gets back to the back end? What happens if the attacker can move laterally? You get headless chickens.
The industry today is geared toward making a safer chicken coop, strengthening the controls and DMZ structure is where 99% of security dollars and attention go to. Auditors then come along and ask if you have 17 controls on the coop, why not 18, why not 24? No doubt this is all important and hardening matters a great deal.
But today you have to assume that lengthening the list of controls on the DMZ won't stop the determined opponent. So the next question to ask is, assuming the attacker's graph gets them by the coop walls, what next?
In other words, assuming a chewy center how to avoid a coop full of headless chickens? That question leads you to a number of deeply suboptimal tradeoffs and unappetizing choices.
My take is that we have pushed the DMZ concept very far over a long period of time, and just like that third cup of coffee does not have the same effect as the first two, we need to look to some new areas to improve.
Those directions of change need to come without and within the coop walls. Some of it is better recognition of malice, some of it is better response. Many companies are embarking on unflattening (unchewifying) the centers. This could be through stronger (in many cases any) authentication, fine grained authorization, segmenting networks, using gateways to reduce attack surface, tokenization, limit options for lateral movement, integrating monitoring and access control with risk based access control and finally taking a hard run automating key management. If the "lose less" design cannot save all the chickens perhaps it can save the flock as a whole.
These are long tail projects that reshape the security architecture, yet they also require process changes. Process change is far harder than technical change, and its effect on project deployments is almost always underestimated. One of the reason the DMZ continues to receive investment is that its already assumed the normal rules do not apply there, so adding an 18th control is not a problem. However, once security architects seek to change Inside systems, totally different rules of engagement apply. It pays to be conservative in the short run as to what you can achieve in terms of process changes.
The nature of security capabilities is different here as well. The key to unlock this is threat modeling. Threat modeling is usually done with how hard is it to bypass the DMZ. Some part of threat modeling should start with the assumption, "now that the attacker is on step 2 and inside the system" what happens? This second question is not often asked. Hardening is the de facto standard in the DMZ and it should be. Inside the system segmentation or tokenization may matter more. One chicken is lost but the flock makes it. Stronger authentication to limit lateral movement, so one system has an issue but not 2,000 internal apps and database. User activity monitoring to watch the inflows and outflows and detect/respond when there is an issue.
The famous crunchy shell and soft, chewy center does not work so well with a determined, graph executing opponent. Its worth asking if the next $100 you spend on security capabilities should be used to further harder the crunchy shell or should it be used to make the center less chewy and more resilient? Or perhaps we should change the nature of the game itself with something like tokenization or risk based access control.
Basically, this is an effort to get to graceful failure modes in security. Unfortunately, we currently have a system today where everything works or its all chickens dead, game over. There are more directions that this can go, but changing that one assumption and making sure you design for failure of the core security capability itself is a key to long run system survivability.
Beware the fox disguised as a chicken! The best way I see to protect against this is detection. Once one chicken is headless to have the process and/or systems to detect this and react to protect the rest is a must. Maybe we should start to think of DMZs as Detect Malicious (activity) Zones?
Posted by: Roger | July 06, 2015 at 11:02 AM
"Unchewifying"......I like the term!!
Posted by: Scott | July 14, 2015 at 05:42 PM