Insinuator.net - Bold Statements

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:

Continue reading 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].

Continue reading Continue reading

We’re delighted to announce the first speakers of next year’s Troopers edition. Looks like it’s going to be a great event again ;-).
Here we go:

==================

Ravishankar Borgaonkar & Kevin Redon: Femtocell: Femtostep to the Holy Grail  (Attacks & Research Track)

Abstract: Femtocells are now being rolled out across the world to enhance third generation (3G) coverage and to provide assurance of always best connectivity in the 3G telecommunication networks. It acts as an access point that securely connect standard mobile handset to the mobile network operator’s core network using an existing wired broadband connection.

Continue reading Continue reading

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” …

Continue reading Continue reading

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.

1.1 Method of Estimation

Again, two main approaches exist[1]:

• 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.

Continue reading Continue reading

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";
}

Continue reading Continue reading

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.

have a good one,

Enno

Continue reading

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:

Continue reading Continue reading

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 😉

Continue reading Continue reading

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:

Continue reading Continue reading