This is the 3rd part of this loose series on considerations of (operating) DMZs in 2016 (part 1 on the role of a DMZ is can be found here, part 2 on reverse proxies here).
Again, I dare to deviate a bit from the plan & order I initially had in mind – today I will cover one process whose maturity may significantly influence the overall security posture of a DMZ environment: firewall rule management.
DMZ
To Control Something
Some years ago I discussed the meaning of the term “control” in this post, but at the time I was mainly referring to the noun “control”. Given I’ll extensively use the term “control” as a verb in the next parts of “the DMZ series” and some upcoming talks I reflected a bit on its meaning (as a verb). In the following I’ll lay out the definition/understanding to be employed at those occasions.
Merriam-Webster defines, amongst others, as follows:
Continue readingConsiderations on DMZ Design in 2016, Part 2: A Quick Digression on Reverse Proxies
This is the second part of a series with considerations on DMZ networks in 2016 (part 1 can be found here). Beforehand I had planned to cover classification & segmentation approaches in this one, but after my little rant on how “the business” might approach & think about reverse proxies in the first part, I felt tempted to elaborate a bit further on this particular topic. I kindly ask for your patience 😉 and will digress a bit for the moment.
Continue readingConsiderations on DMZ Design in 2016, Part 1
I’m currently involved in a “DMZ Redesign” effort in a sufficiently large enterprise (800+ hosts in “the DMZ”) and I thought this might be an opportunity to reflect on some aspects of “DMZ networks” in a series of posts.
Some of you already know that, at ERNW, we have a tendency to discuss stuff starting with some formal definitions and a bit of abstract (overview) approach. It’s not different this time ;-), so let’s first find out what the term “DMZ” means, what such a thing is considered to be and to deliver, and what the actual state of affairs might be in 2016. Different people within an organization might have quite different understandings in this space.
Further it’s entirely possible that the DMZ networks are not operated by a company themselves but by an outsourcing partner which then means that “placing a system in the DMZ” becomes “ordering a DMZ [network] port” by means of some web-based procedure or ticket system, which in turn might have a number of interesting implications (we’ll have a dedicated post on those).
Some reflections on virtualization security, part 1
Today was an interesting day, for a number of reasons. Amongst those it stuck out that we were approached by two very large environments (both > 50K employees) to provide security review/advise, as they want to “virtualize their DMZs, by means of VMware ESX”.
[yes, more correctly I could/should have written: “virtualize some of their DMZ segments”. but this essentially means: “mostly all of their DMZs” in 6-12 months. and “their DMZ backend systems together with some internal servers” in 12-24 months. and “all of this” in 24-36 months. so it’s the same discussion anyway, just on a shifted timescale ;-)]