I’m currently involved in creating an up to date approach to handling external
connections (read: temporary/permanent connections with external parties like
business partners) of a very large enterprise. Currently they have sth along the
lines of: “there’s two types of external connections, trusted and untrusted. the
untrusted ones have to be connected by means of a double staged firewall”.
Which – of course – doesn’t work at all in a
VUCA
world, for a number of reasons (the demarcation between trusted and untrusted is
quite unclear – just think of mergers & acquisitions –; “business doesn’t like
implementing 2-staged firewalls in some part of the world where they just signed
the memorandum for a joint venture to build windmills in the desert”; firewalls
might not be the appropriate control for quite some threats anyway – see for
example slide 46 of
this presentation– and
so on). Not to mention that I personally think that the “double staged firewall”
thing is based on an outdated threat model, in particular when implemented with
two different vendors (for the simple reason that the added operational effort
usually is not worth the added security benefit. see
this post for
some discussion of the concept of “operational feasibility”…).
The above is the exact title of a
Gartner research note
published some days ago. Its main thesis is that an increased convergence of
carriers’ MPLS and Internet infrastructures onto shared IP infrastructures
requires that enterprises re-evaluate their security and performance risks.
While I do not agree with the overall line of reasoning in the paper, it still
highlights a number of interesting points when it comes to MPLS security. Which
in turn reminds me of quite some stuff we’ve done in the past, mainly our Black
Hat Europe 2009
talk “All your packets are belong to us – Attacking backbone technologies”.
Today we’ll release an updated version of the accompanying whitepaper as a
kind-of technical report. Its title is “Practical Attacks against MPLS or
Carrier Ethernet Networks” and it can be found
here.
Given the upcoming public release of ISECOM‘s
Open Source Security Testing Methodology Manual (OSSTMM)
version 3, I took the opportunity to have a closer look at it. While we at ERNW
never adopted the OSSTMM for our own way of performing security assessments
(mostly due to the fact that performing assessments is our main business since
2001 and our approach has been developed and constantly honed since then so that
we’re simply used to doing it “our way”) I’ve followed parts of ISECOM’s work
quite closely as some of the brightest minds in the security space are
contributing to it and they come up with innovative ideas regularly.
So I was eager to get an early copy of it to spend some weekend time going
through it (where I live we have about 40 cm of snow currently so there’s
“plenty of occasions for a cosy reading session” ;-))
One can read the OSSTMM (at least) two ways: as a manual for performing security
testing or as a “whole philosophy of approaching [information] security”. I
did the latter and will comment on it in a two-part post, covering the things I
liked first and taking a more critical perspective on some portions in the
second. Here we go with the first, in an unordered manner:
Today I’m going to discuss the (presumably) most complex and difficult-to-handle
of the three parameters contributing to a risk (as of the RRA), that is the
“vulnerability [factor]”.
First it should be noted that “likelihood” and “vulnerability” must (“mentally”)
be clearly separated which means that “likelihood” denotes: likelihood of threat
showing up _without_ consideration of existing controls. Security controls
already present will affect the vulnerability factor (in particular if they are
effective ;-), but _not_ the likelihood.
First reflect on “how often will somebody stand at the door of our data center
with the will to enter?” or “how often will a piece of malware show up at our
perimeter?” or “how often will it happen that an operator commits a mistake?”
and assign an associated value to the likelihood.
Then, _in a separate_ step, think about: “will that person be able to enter my
data center?” (maybe it’s an external support engineer and, given their high
workload, your admins are willing to violate the
external_people_only_allowed_to_access_dc_when_attended policy. which – of
course – is purely fictional and will never happen in your organization ;-)) or
“how effective are our perimeter controls as for malware?” (are they? ;-)) or
“hmm… what’s the maturity of our change management processes?” and assign an
associated value to the vulnerability factor.
As stated in an earlier post: this will allow for identifying areas where to act
and thus allow for efficient overall steering of infosec resources.
Mixing likelihood and vulnerability might lead to self complacent stuff like
“oh, evidently likelihood of unauthorized access to datacenter is ‘1’ as we have
that brand new shiny access control system” …
This is the second part of the series (part 1
here) providing
some background on the way we perform risk assessments. It can be seen as a
direct continuation of the last post; today I cover the method of estimation
and the scale & calculation formula used.
Qualitative estimation which uses a scale of qualifying attributes (e.g.
Low, Medium, High) to describe the magnitude of each of the contributing
factors listed above. [ISO 27005, p. 14] states that qualitative estimation
may be used
As an initial screening activity to identify risks that require more
detailed analysis.
Where this kind of analysis is appropriate for decisions.
Where the numerical data or resources are inadequate for a quantitative
estimation.
As the latter is pretty much always the case for information security risks,
in the infosec space usually qualitative estimation can be found. A sample
qualitative scale (1–5, mapping to “very low” to “very high”) for the
vulnerability factor will be provided in the next part of this series.
At several occasions we’ve been asked to provide some background on the
Rapid Risk Assessment (RRA)
methodology we frequently use for a transparent (and documented) understanding
of risks in certain situations and to deliver structured input for subsequent
decision taking. As I had to write down (in another context) some notes on risk
assessments and – from our perspective – practical, reasonable ways of
performing them, I take the opportunity to lay out a bit the underlying ideas of
the RRA approach. Which, btw, is no rocket science at all. Honestly, I sometimes
wonder why stuff like this isn’t practiced everywhere, on a daily basis 😉
Once again, in some customer environment the question of allowing/prohibiting
split tunneling for (in this case: IPsec) VPN connections popped up today. Given
our strict stance when it comes to “fundamental architectural security
principles” the valued reader might easily imagine we’re no big fans of allowing
split tunneling (term abbreviated in the following by “ST”), as this usually
constitutes a severe violation of the “isolation principle”, further aggravated
by the fact that this (violation) takes place on a “trust boundary” (of
trusted/untrusted networks).
Still, we’re security practitioners (and not everybody has such a firm belief
in the value of “fundamental architectural security principles” as we have), so
we had to deal with the proponents’ arguments. In particular as one of them
mentioned additional costs (in case of disallowed ST forcing all 80K VPN users’
web browsing through some centralized corporate infrastructure) of US$
40,000,000.
[yes, you read that correctly: 40 million. I’ve still no idea where this – in
my perception: crazy – number comes from]. Anyhow, how to deal with this?
Internally we performed a
rapid risk assessment (RRA)
focused on two main threats, that were:
Some days ago my old friend Pete Herzog from ISECOM
posted a blog entry titled “Hackers May Be Giants with Sharp Teeth”
here
which – along with some quite insightful reflections on the way kids perceive
“bad people” – contains his usual rant on (the uselessness of) risk
assessment.
Given that this debate (whether taking a risk-based infosec approach is a wise
thing or not) is a constant element of our – Pete’s and mine – long lasting
relationship I somehow feel enticed to respond 😉