Tag: operations

Hi,
I’ve discussed the concept of evaluating the operational “feasibility” (or “impact”, depending on your point of view) of security controls before. Some people approached me asking “which considerations should we take into account when trying to understand or rate this for $SOME_SECURITY_CONTROL?”. Therefore, in the following I’ll give an unordered list of factors to consider to get an understanding of the “operational feasibility” of a given security control. Two things should be noted in advance:

 
– evaluating the operational “feasibility” (which is “a positive factor”) as opposed to the operational “impact” (being a “negative factor”) allows for easier integration into a metric scheme, as the two main factors-to-considered – the other one is the “security benefit” of a control – can be expressed on the same scale then, with a high value meaning a good thing.
– as the (maturity of) and as-is state of operational processes usually have a much higher impact on the security posture of a given environment than the components deployed in the environment (see this presentation, slide 14ff.), this approach focuses on _operational costs_ and does not take initial investment costs into account. In short: opex is the thing to look at, not capex.
Here we go… for each (potential) security control you might look at:

a) How many lines of code/configuration does it need?

b) Can it be implemented by means of templates or scripts? Effort needed for this?

c) To what degree does the implementation differ in different scenarios (e.g. per system/subnet/site)? Can “the difference” be scripted, e.g. taken from another source (a CMDB) or “calculated” (like the addresses of neighboring routers on the local link)?

d) How much additional configuration is needed to establish the previous functionality/state? E.g. to pass legitimate traffic in case of a (“fresh”) application of ACLs?

e) What’s the “business impact” incl. number of associated support/helpdesk calls?

f) Cost for _deployment_ of additional hardware, licenses or other tangibles. (again, the cost for their initial procurement is capex).

g) In case of a tangible security control think about the full life-cycle management of the asset (patching, monitoring, alerting, capacity management and the like). This one is often heavily overlooked, see for example this excellent blog post of Anton Chuvakin for a discussion of the “real costs of a SIEM deployment”.

h) Does the control require a new operational process or task?

i) Propagation: how far does the (implementation of the) control reach?

j) How many different people or companies/partners (sub contractors) touch the work?

k) Impact on OLAs and SLAs.

The above might give an idea of how to tackle the task of evaluating the operational feasibility. In another, future blogpost I may discuss a sample metric using this stuff from a real-world environment (will have to write down and anonymize some pieces though). For the moment many thanks to Friedwart, Angus and Sergey for valuable input to the above list.

Feel free to contact us (or leave a comment) with suggestions as for additional considerations.

have a good one,

Enno

Continue reading

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

Continue reading