When taking security decisions of whatever kind (e.g. for/against a certain control) one should always consider two main parameters: the security benefit of some action (“how much do we gain with regard to security/to risk reduction?”) and the operational impact or effort (“how much does it cost us opex-wise?”).
While this may seem fairly obvious it is often overlooked. One reason is that people think “doing more can’t hurt”. Which, unfortunately might be plain wrong in many cases. There is _always_ an operational cost of an additional measure. And the security benefit _must_ be worth this cost.
If it’s not, implementing a certain control might just be… waste.
Before giving two examples I’d like to note that this is one aspect I particularly like in the ISECOM OSSTMM where one of the main metrics, that is the “rav” can be higher than 100% which in turn can be used “to prove when money is being overspent on the wrong types of controls or redundant controls”.
[it should be noted that I’m in heavy disaccord with quite some other parts of the OSSTMM; more on this in a post to follow in some days. still the “rav” as a potential representation for showing waste is a really nice thing].
Back on topic, here’s two real-world examples to illustrate my point:
a) some months ago we performed a network audit in some financial institution. They heavily relied on network based security controls, namely 802.1x (the best! implementation I’ve ever seen so far, with a deployment rate > 98% in a 12K ports network. impressing stuff.) and ACLs on the layer 3 switches at the demarcation between the access and the distribution layer. One of those ACLs was of special interest. It contained about 120 lines which could be split into three pieces:
– first 118 lines allowing all types of actions from a “Quarantine VLAN” to some central systems, amonst those their domain controllers. To enable the automated installation of new systems (not disposing of a cert => put into the quarantine VLAN), with subsequent joining a domain, there were all sorts of rules allowing port UDP 53, TCP 88, 135, 445, 389, 636, ephemeral TCP ports etc. to each of the domain controllers (distributed across two data centers).
– line 119 went like: “deny quarantine_vlan any”.
– line 120 went like: “allow all_other_vlans any”.
After figuring the overall approach we asked them: “What’s the threat you want to protect against by this ACL?”.
The answer was sth like: “Malware infection from the systems in the quarantine VLAN”.
Now, ask yourself: with regard to the domain controllers (which can certainly rated “crown jewels” in this network, as in many others) does this ACL provide this protection?
[Hint: which ports did Blaster, Sasser and Conficker use?]
We then suggested: “you could heavily simplify this ACL by allowing any IP traffic to the domain controllers and – security-wise – you won’t lose much, as for the main threat you’re trying to protect from.”
Their answer was sth like: “While we understand your point we already have it and what’s wrong about having a kind-of-enhanced control, even if it does not provide much additional value?”.
And here we have what I call the “illusion of infinite resources”!
Imagine a new domain controller is added (or sth other network change affecting this ACL occurs). Some person will have to spend (precious) man power on modifying the ACL, testing it, deploying it etc. And this will cost more operational resources in case of an extensive ACL compared with a much simpler one (delivering more or less the same level of security). Those resources “wasted” could and should be much better spent on some other security optimization in their environment.
b) I just had a discussion with the CISO of another global organization. In that environment one of the national subsidiaries is going to have their own SSL VPN gateway shortly (those units can act rather autonomously) and there’s mainly two design variants discussed currently. That are
– put the internal interface of that SSL VPN gateway directly into the subsidiary’s LAN (with placement of the SSL VPN gateway in a DMZ at the firewall).
– put the internal interface of the SSL VPN gateway into the DMZ as well and route all the incoming VPN traffic through the firewall (placement in DMZ again, evidently).
He said to me: “Enno, obviously I prefer the second option”.
I replied: “Why? What’s the additional security benefit? Given you’ll have a ‘all traffic from VPN -> all internal networks: allow’ rule anyway, what’s the benefit of the extra hop [the firewall] and the extra filtering instance?”
I mean, there is practically none. So it’s just an additional rule (set) to be administered, to be looked at when troubleshooting etc.
Without any added security (visible to me at least).
This again, might serve as an example that one should always carefully reconsider those two parameters mentioned in the beginning of this post. Think about it.
have a good one,
Enno