Building

IPv6 Security ‒ The Story Continues

Just a short addition to the previous posts ([1], [2]) on IPv6 security today. In the last two days I had the opportunity to sharpen my understanding of some aspects of IPv6 behavior in (Windows-) LANs. Actually I gave an IPv6 workshop for some members of the “Project Services” team of Hamburg-based computer & competence IT-solutions provider [btw: thanks to Mr. Wendler of CuC for organizing it, and thanks to Mr. Cassel for the breakfast…].

Continue reading
Building

IPv6 Security Part 2, RA Guard – Let’s get practical

Hi everybody,

this post is the sequel of this one on the IPv6 security feature called “RA guard”. As announced in that post I recently got a 4948 on ebay. After installing the appropriate image and noticing that RA guard was still unavailable I found out it should have been a 4948E which is capable of “doing IPv6 in hardware” (as opposed to the “simple 4948” only supporting IPv6 in a “software switched” way. and pls note there’s also the informal term 4948-E denoting a 4948 running an “enhanced image”).

Continue reading
Misc

Ross Anderson on Responsible Disclosure and Academic Freedom

Hi,

just a short, somewhat non-technical,  post today: I really like this response Ross Anderson gave to the “UK Cards Association” asking Cambridge University for taking offline a thesis of one of their students. It (the letter) pretty much summarizes how security research should be treated and backed by those interested in a more secure world we live in.

On a personal note I’d like to add that Ross’ main volume “Security Engineering: A Guide to Building Dependable Distributed Systems”, initially published in 2001 and updated in the interim with a second edition in 2008, has been the most influential security book for me on my long way in the infosec space (which started back in 1997, with some workshops on firewalls I gave for IT auditors). If I could take only one infosec book to a lonely island, it would be this one.

Continue reading
Building

IPv6 Security Part 1, RA Guard – The Theory

Hi,

at first a happy new year to our loyal readers (and, of course, to everybody else too ;-)! We hope you all had some pleasant transition times, not suffering from bad hangovers after 27C3 or sth 😉

Things are heating up for Troopers and in the course of that we started putting together the slides for the workshops (I’m delighted that Flo told me today there’s already quite a number of bookings for the workshops…). I myself will give the “IPv6 Security in LANs” workshop, together with Christopher. The workshop preparation will be accompanied by a series of blogposts with three main areas to be covered:

Continue reading
Misc

The OSSTMM 3 – What I like about it

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
Building

Security Benefit & Operational Impact or “the Illusion of Infinite Resources”

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
Events

Troopers 2011 – First round of speakers selected

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
Building

Reflections on the vulnerability factor (notes on RRA, part 3)

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
Building

ERNW Rapid Risk Assessment (RRA), Some Additional Notes, Part 2

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