Preface

The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them.

While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.

Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.

The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.

As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.

Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.

There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.

This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.

Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.

We are regularly hearing from our security clients about their difficulties finding people with the right skills – or when they do finally find them, these people are too costly to employ because their skills are in such demand.

Indeed, the “unavailability of people with the right skills” was cited as a top challenge for security groups in both our enterprise and SMB surveys.

In comparing need for talent across 25 different IT roles, Forrester analysts came to the conclusion that information security experts are among the hottest roles in IT, sharing the top spot with information/data architects.

The skills shortage is likely to get worse before it gets better. We’re unlikely to see a significant spike in security experts’ salaries to attract those we need to hire: large changes in compensation for senior security personnel would run against the current of economic belt-tightening. Another typical approach to offsetting the shortage would be to train up: foster the career development and advancement of existing security personnel on our payroll. However, with all the outsourcing that is going on – and which will increasingly occur – there is a shrinking pool from which to find people with “the right stuff” worth championing their advancement.

We could look outside of security to others in IT, or even to co-workers in other departments or business groups. But given how poor a job IT Security does of marketing its value proposition, I don’t hold much hope for attracting non-security people.

What do you think? Are we about to hit a very big wall when it comes to skills and staffing? Are you presently feeling the pain of a skills shortage? Do you see such a shortage looming? What measures are you taking to acquire and nurture talent? Which ones are successful and why?

I welcome your thoughts on the topic.

An interesting blog post this morning discusses the obstacles and implications of this kind of technology, in part quoting a recent New York Times article —

In short, we need a log-on system that relies on cryptography, not mnemonics. As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code.

An obstacle to this kind of system are the current initiatives toward Open ID and single-sign on services, strategies that are backed by large industry players such as the Equifax, Google, Novell, Microsoft, Oracle, etc. In the open ID system, you would log in to a session on the web with one password, which would be accepted by any application/account supporting the open ID infrastructure.

To me Open ID sounds like a step backwards, toward less security…
then again, I would think that encrypting everything could also make your system run significantly slower, and that it wouldn’t prevent all the risks either…

Today, allow me to update you on FAIR and the movement towards a formal, open standard.  There’s a couple of cool things going on in our little risk-world.

First, The Open Group Security Forum continues to move towards a formal adoption of FAIR.

WHAT DO YOU MEAN “WE” - YOU GOT A STANDARDS BODY IN YOUR POCKET OR SOMETHING?

Our meeting in Chicago a few weeks ago was great, but also slightly disturbing for me. I got pronoun-confusion syndrome.   I’m used to using the “we” pronoun to refer to RMI, or Jack and myself as we vet the models.  So without even thinking I would said “we have been looking at how loss occurs, and may want to change the model some” and The Open Group Members freaked out (rightfully so).  Adrian Seccombe gently reminded me that the “we” was now the Security Forum, and that “we” didn’t go changing things at will without vetting against each other.  Man I love this stuff.  I get to run our thoughts and ideas past some great folks now - you know, those smart people who tend to have really complex problems and are trying hard to solve them.

Formal Adoption:  Soon, Very Soon Now

Formal Adoption basically means we’ve made this document, everyone is close to saying that they generally like it, and once that finally happens then “bam”, we’re ready to move onward and upward with better things (see Cookbooks, below).  We’ve got a couple of changes to the current document that have been requested that aren’t a big deal.  For example, one request is that we make some statement about general applicability of FAIR to risk domains outside of the IT realm.   But once additions like that and others are done, this long process should be complete.

New Document Moving Towards Public Release:

We’ve got a basic document that should be public in the next few weeks on “What Makes a Good Risk Assessment Methodology” - written by yours truly and Jack.  It’s a very high-level document, and serves two purposes:

• For novices it helps parse out what is important in any undertaking to understand corporate risk (the repeated discussions on the ISO 27001 mailing list make me think it would be a place ripe for such a document).
• For those who “know” risk, it helps to re-establish some fundamental principles like the use of scales (ratio, please), the implications of dealing in probabilities, what attributes like consistency and defensibility mean, how “risk” should be reported to the business (something you know, meaningful) and so on.

When this doc is deemed ready for public consumption I’ll be sure to post on this blog here.

COOKBOOKS, EUROPEAN AGENCIES, AND, IRON CHEF “RISK” - WHOSE CUISINE WILL REIGN SUPREME?

One interesting thing that came up in the Chicago meeting was that ENISA (The European Network and Information Security Agency) developed a very nice document that reviewed something like 18 different risk assessment methodologies against their Criteria for Goodness.  FAIR was one of the ones they reviewed, and we (the royal “we” used there to include all us FAIR-Folk) did awfully well.  Things of interest:

1. They based their work on the current introduction paper which is not at all a step-by-step guide towards an organizational risk assessment (what ENISA really wanted) and we did pretty well.  Well enough that if we had developed a paper along the lines of NIST 800-30 or OCTAVE for the use of FAIR in a formal process, we could have done really, really well.  Like won-the-bake-off kind of well.
2. FAIR is actually not at all incongruous to many of the risk assessment methodologies offered, and in fact compliments many of them by letting those methodologies develop real, structured probabilities.  Think OCTAVE, where they basically say “math is (probabilities are) hard, so if you want to do them for reals, good luck!  But here’s a nonsensical way to do things if you want to believe in magic-fairy risk“.  FAIR fits right in there by stomping on the magic-fairy risk with the jack-boots of rationality.  FAIR similarly helps other risk standards that might lack structured probability development.

So The Open Group Security Forum decided that though we could create a new document and totally p0wn any future ENISA bake-off, there wasn’t much demand for the development of that documentation by the membership  - a point which was made quite apparent at the beginning of the discussion when one large European company CISO asked “What’s ENISA?”  Relevancy is everything, I suppose.

But that second item up there - the one about helping rather than competing with other “risk assessment methodologies” - really struck a chord.  So “we” (The Security Forum) are going to develop some “Cookbooks” that basically are high-level documents that say “If you want to use FAIR with (OCTAVE/COSO/CoBIT/Whatever) here’s how it fits, makes it better, and improves your life.  I’m pretty excited about these, and our first document looks like it’s going to be COSO integration.

THE OPEN GROUP SECURITY FORUM - THEY’RE A TRUSTING BUNCH (WITH QUALIFICATION, OF COURSE)

Finally, many people have asked me “Why work with The Open Group?”  There are many reasons, to be sure, but I will give you one example.  Members of the Security Forum there are not only great at vetting the model and getting consensus on risk and risk factors - but they’re quick to start applying.  So in Chicago, I thought I’d be talking about FAIR and the standard and fighting groupthink.  Nope.  Not at all.  In fact, the forum members spent more time suddenly discussing use of FAIR in a new Trust Model they’re developing.  So all of the sudden, I’m part of a new and exciting project to develop a Trust Model - how cool is that?  While formal adoption of the Trust Model will be necessarily long and deliberate - the collaboration and development is happening much faster than I can keep up with.  But if you all will allow me, it will help me get my head around it all by blogging about it later this week.  So be prepared to read about me dealing in “Trust” a little bit.

You will discern a certain amount of enthusiasm for blocking, and for a “something must be done” approach. However, in coming to their conclusions, they do not, in my view, seem to have listened too hard to the evidence, or sought out expertise elsewhere in the world…

Google/YouTube told them that 10 hours of video was posted every minute, and the amount is increasing. In the oral evidence session an MP helpfully suggested: “That video content is tagged. You do not need to look at every single minute of video content. Surely you could have people who would look at the video content which is tagged with labels which suggest it could be inappropriate.” Of course “happy_slapping.wmv” or “fluffy_bunnies.avi” must always contain exactly what it says on the tin (not!) but unaccountably Google said it was a “fair suggestion”, so perhaps my cynicism is misplaced.

However, back to blocking.

I submitted some evidence of my own, which the committee summarised, reasonably accurately:

Dr Richard Clayton, a researcher in the Security Group of the Computer Laboratory at Cambridge University and author of several academic papers on methods for blocking access to Internet content, pointed out that there was no single blocking method which was both inexpensive and discerning enough to block access to only one part of a large website (such as FaceBook). In his view, the fatal flaw of all network-level blocking schemes was the ease with which they could be overcome, either by encrypting content or by the use of proxy services hosted outside the UK.

The committee’s conclusion, having read this was:

At a time of rapid technological change, it is difficult to judge whether blocking access to Internet content at network level by Internet service providers is likely to become ineffective in the near future. However, this is not a reason for not doing so while it is still effective for the overwhelming majority of users.

which I suppose logically means that the committee thinks that blocking should now be discarded as a policy option — but somehow I think that isn’t their intended meaning.

The Committee should perhaps have a look at this Australian report, which found that ISP level content filtering (and in Australia the politicians want to use ISP level filtering to provide a child-friendly Internet) did work (up to a point) at Tier 3 (the smallest) ISPs. The up-to-a-point is that unlike previous tests the systems didn’t completely wreck the browsing experience by slowing it down. However, the systems blocked only 85-98% of illegal material and similar percentages of material suitable for adults but not for younger children. Interestingly some products were better at different categories.

Getting that many sites wrong is really quite significant, so it’s difficult to see this as a ringing endorsement for blocking the web. Additionally, the Australian report found that the blocking was useless on “non-web” protocols (such as peer-to-peer) and their report specifically didn’t consider cost, or ease of circumvention — so it’s not just UK politicians not wanting to consider evidence on that topic!

Finally, I should note that the Culture Media and Sport Committee has also ignored some rather more recent academic work. The MPs have put into their report that they were horrified to discover that child sexual abuse images took 24 hours to remove in the UK. What (should they ever learn of it) will they make of the recent discovery by Tyler Moore and myself that shows that if the website is hosted abroad then a month is more to be expected?