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.
After the initial quick shot (see this
post)
we decided to have a closer look. And some more stuff turned up.
After decompiling the integrated java stuff we stumbled about hard coded server
credentials:
package Idonttell;
public abstract interface Idonttell { public static final boolean debug = false; public static final boolean auth = true; public static final String SMTP_SERVER = "Idonttell.openlimit.com"; public static final String SMTP_USER = "Idonttell@Idonttell.openlimit.com"; public static final String SMTP_PASSWORD = "Idonttell"; public static final String SEND_FROM = "Idonttell@Idonttell.openlimit.com"; public static final String[] SEND_TO = { "buergerclient.it-solutions@Idonttell.com" }; public static final String MAIL_HEADER_FIELD = "OpenLimitErrorMessage"; public static final String MAIL_HEADER_FIELD_PROP = "yes"; }
Two days ago I gave the keynote at an industry event, reflecting on the changing
role of traditional security controls in the age of virtualization and the
cloud. As this was an updated version of the stuff distributed in the conference
proceedings, some people have asked for it. Voilà,
here we go.
Currently there’s quite some discussion about the security properties and
posture of the German new ID card (“Neuer Personalausweis”, “nPA”, some
technically reasonable security discussion can here be found e.g.
here.
While – as of our current knowledge – we do not expect major security flaws on
the architecture level, the problems discussed so far (like
Evilgrade
style attacks against one of the main applications or keylogging the PIN in
scenarios with
pinpad-less readers
) certainly show that security best practices must be followed by all parties
involved in the development, deployment and use of the nPA and it’s associated
applications. From our perspective this may be expected from the applications’
developers as well.
Looking at this:
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:
… which was, as in the years before, an awesome event.
Great talks, great people, great fun.
Bruce Potter gave a keynote
which did exactly what a good keynote should do: make the audience think and
entertain it at the same time.
[Those readers familiar with ERNW’s security model will certainly notice that
we do not necessarily agree with everything he said. We still think that – in
particular in times where infosec resources are scarce anyway – putting your
bets on prevention provides a better cost/[security] benefit ratio than going
for extensive detection capabilities.
Fix the doors first, then think about installing a CCTV.
Still, human nature tends to exchange “good security with low visibility” for
“poor security with potentially good visibility” quite easily… as can be noted
every day in many environments.]
Today we dare to (mis-) use the blog for a shameless self promotion 😉
We’re happy to announce that ERNW will contribute to a government sponsored
research project called ASMONIA (which stands for the
German title of the project that is Angriffsanalyse und Schutzkonzepte für
MObilfunkbasierte Netzinfrastrukturen unterstützt durch kooperativen
InformationsAustausch [Attack analysis and Security concepts for MObile
Network infrastructures, supported by collaborative Information exchAnge].
those readers familiar with that kind of projects will have an idea of the
importance of such acronyms ;-).
Just a short notice today on some recent presentations from our team. As some of
you might know we regularly give talks at conferences. This not only encompasses
highly sophisticated security events like Black Hat or
Troopers. Additionally – on our mission for a safer
world – we try to spread the (security) word at various industry events that are
usually focused on some aspect of the large and ramified IT world, not
necessarily equipped with a strong focus on information security.
A number of such events took place in the last few weeks and here’s some links
on presentations given there. While not being as technically deep as the average
Black Hat or Troopers attendee might expect, we still
hope that one or another valued reader finds them useful (pls note that some
parts are in German).
Finding exploitable vulnerabilities is getting harder. This statement of Dennis
Fisher published on
Kaspersky’s Threatpost blog
summarizes a trend in the development lifecycle of software . The last published
vulnerabilities that were gaining some attention in the public had all one thing
in common, they were quite hard to exploit. The so called jailbreakme
vulnerability was based on several different vulnerabilities that had to be
chained together to break out of the iPhone sandbox, escalate its privileges and
run arbitrary code. Modern software and especially modern operating systems are
more secure, they contain less software flaws and more protection features that
make reliable exploitation a big problem that can only be solved by very skilled
hackers. Decades ago it was just like this, but intelligent tools and sharing of
the needed knowledge enabled even low skilled people to develop working exploits
and attack vulnerable systems. Nowadays we are going back to the roots where
only a few very knowledgeable people are able to circumvent modern security
controls, but that doesn’t mean that all problems are gone. Attackers are moving
to design flaws like the DLL highjacking problem, so only the class of attacks
is changing from the old school memory corruption vulnerabilities to logical
flaws that still can be exploited easily. But the number of exploitable
vulnerabilities is decreasing, so this might be a sign that we are on the right
way to develop reliable and secure systems and that developing companies are
adopting Microsofts Secure Development Lifecycle (SDL) to produce more secure
software. As stated in my previous
blogpost
the protection features are available, but not used very often. But if they are
used and if the developers are strictly following the recommendations of the
SDL, this trend of “harder to exploit vulnerabilities” proves that it can be a
success story to do so.