Monthly Archives: August 2014

100 years ago

Major Foster Swetenham (Royal Scots Greys) killed in action at Moÿ-de-l'Aisne on 28 August 1914 during the retreat from Mons, in the same action as the charge of the 12th Lancers. Buried at Moÿ-de-l'Aisne. A commemoration took place at Moÿ on 28 August 2014, during which a memorial to the British cavalrymen was unveiled. British Forces News. Coverage by BBC East Midlands Today.

Foster Swetenham was born on the 21st June, 1876, the son of Edmund Swetenham, Q.C., M.P. for Carnarvon Burghs, of Cam-yr-Alyn, Rossett, Denbighshire, and grandson of Clement Swetenham, of Somerford Booths, Congleton, Cheshire. He left a widow, Muriel Gladys née Chaplin and two sons, John Edmund, 5th Royal Inniskilling Dragoon Guards, DSO, Brigadier, Colonel Royal Scots Greys, and Anthony Clement.

Hacking Exposed 78% Of All Records Compromised In First Half Of 2014

Mid-year 2014 data breaches exposed over 502 million records far exceeding the mid-year point in 2013, the previous all-time record setting year.

We are pleased to announce the release of the next installment of Risk Based Security’s Mid Year Data Breach QuickView report.

The report shows that 2014 is on pace to replace 2013 as the highest year on record for exposed records, and the recently reported exposure of 1.2 billion email addresses and user names has not been included. The 1,331 incidents reported during the first half of 2014 exposed over 502 million records, nearing 61% of the 814 million records exposed in 2013.

The Data Breach QuickView report also revealed that individuals’ user names, passwords and email addresses were exposed in 57% of reported incidents, with passwords taking the top spot at 70.1% of all Mid-year 2014 breaches.

Risk Based Security’s research suggests that organizations in all industries, regardless of size, should take an active approach to review their networks for security vulnerabilities in their applications, infrastructure and third party libraries. By doing so, organizations can reduce the time of exposure they are facing with many of today’s threats.

The Data Breach QuickView report was just released and is possible through the partnership and combined resources of Risk Based Security and the Open Security Foundation. It is designed to provide an executive level summary of the key findings from RBS’ analysis of the first half of 2014’s data breach incidents. You can view the announcement and report here. You can view the announcement and report here.

Security: Hard to Get Right!

Couple of interesting articles doing the rounds this week, which are worthy of a quick comment!

Heartbleed: the bug that keeps on giving
Reports suggest that the Heartbleed vulnerability was involved in a breach of over 4 million records from a health provider in the US — we won't see many of these, as identifying the culprit as Heartbleed is really difficult in most cases. That instances like this are still cropping up reminds us of the need to ensure we're patched, and not just in the obvious places like a web server. This time it seems to have been SSL VPN at the heart of the issue, so to speak.

Passwords: why are we still so rubbish at this?
Apparently 51% of people share a password. This is properly daft. Really, crazier than a box of weasels. Even if you trust the other person, there's no telling what accidents might occur, or where they may re-use that password themselves. I always get gyp from my wife that I won't tell her my passwords, but I won't — and believe me, I do pretty much everything else she tells me!

EU "right to be forgotten" rule still here, still a waste of time?!
Internet numptys are still asking Google to remove them from searches in their droves. Happily the BBC is kind enough to reveal who they are by linking us to the relevant articles. When will people realise that once you publish something on the Internet, it is there forever. Unless it's that really useful document you bookmarked last week, which now 404s and was never in the Internet archive. Yes, that one.

The Indelicate Balance Between "Keep it Working" and "Keep It Safe"

Security professionals continue to fool themselves into believing we walk a delicate balance between keeping the business functional, and keeping it safe (secure). This is, in many people's belief including me, a lie. There is no delicate balance. The notion of being able to balance these on a teeter-totter looks like this:

Guess which one the 'safe and secure' is? Exactly.

An interesting conversation (warning: profanity, not so safe for office) happened earlier today. And as per the usual, someone very smart and seasoned in the enterprise side of defense made the point clear.

The bottom line is this:
  You can't ever cross the line into 'breaking business stuff' because you likely never get the chance again.

Each time the pendulum swings into the "secure" side of the spectrum it stays only for a tiny fraction of time, and we as security professionals have to work very hard to make it stick, or it swings back the other way... quickly.

So the question then is, how do we "make it stick"?

Simple! We demonstrate the business value of good security (aka keeping the enterprise safe). Of course, there are few things that are more simple than this, including tightrope walking the Grand Canyon, being an astronaut, and nuclear physics. Whoops, hyperbole ran away with me there for a moment, sorry. Back to reality.

So the key is to make security sticky. You need to align security to something the business can get behind. Hence, business value is so important to measure. But if you're still stuck reporting useless metrics - like how many port scans your firewall blocked, or how many SQL Injection instances your Software Security program identified - you're miles away from demonstrating business value.

This brings me back to KPIs, and the development of data points which strongly align to business/enterprise goals. All of this is predicated on someone in the security organization (or everyone?) being alert and aware to what the business is trying to accomplish at the board/strategic level. Does your organization have this type of awareness and knowledge? Are you leveraging it?

I can tell you that if you're not, the picture above will continue to be your fate... from yesterday to today and on into the future.

For an Internet of Things, We Are Going to Need Better Things

There's a lot of hype around at the moment about "The Internet of Things" (IoT), which, I suppose, is all about attaching, uh, things to the Internet. By "things", it seems we are supposed to be thinking household goods, vehicles; basically anything with electrical current running through it is a candidate for the "internet of things".

While setting up a cheapo DVD player last week, I couldn't help thinking of Chief Brody in the film "Jaws"... "You're going to need a bigger boat", he says, on seeing the enormous shark. We're going to need a bigger mindset on security if we are to survive the onslaught of "things". The firmware in the kind of devices we are already routinely connecting up is drivel. I mean some of it is absolute garbage. I know there are exceptions, but most of it is badly built, and almost none of it is ever updated.

Each of these devices is likely perfectly capable as a host in a botnet - for DDoS, for sending SPAM, SPIM and SPIT (OK, we are yet to see much in the way of unsolicited Internet Telephony... but with the IoT, devices built to make calls/send texts are likely to get hijacked), so each of these devices has a value to the Internet's vast supply of wrongdoers.

Researchers at Eurcom recently completed a study showing up vulnerabilities in the 30 thousand or so firmware images they scraped from vendor websites. Apparently one image even contained a linux kernel whose age had just hit double figures. Ouch. The "Nest" next-gen thermostat hasn't been without issues either, a high profile target, at least we can expect firmware updates from them!

Synology's NAS storage devices are among the early victims of malware attacking non-traditional computing devices, and may be an indication of IoT issues to come. Users of these storage devices have found themselves victim of a crypto-ransomware attack: their files are encrypted, and the encryption keys offered for sale back to them! Other early warnings come in the form of attacks on SCADA industrial control systems. These are all places that traditionally, little or no emphasis has been placed on security.

What can we do to help ourselves here? My advice is be careful before you buy anything you're going to add to your network. Look to see if the vendor has a firmware download, and if there's a recent-ish update. If they're the fire'n'forget types, you're probably not going to want to deploy it.

Footnote: Gartner appears to believe the Internet of Things to have reached "peak hype". Reminds me of an old saying about those dwelling in vitreous abodes launching masonry...

Getting in Our Own Way

The security community has this widely-understood reputation for self-destruction. This is not to say that other communities of professionals don't have this issue, but I don't know if the negative impact potential is as great. Clearly I'm not an expert in all fields, so I'll just call this a hunch based on unscientific gut feeling.

What I do see, though, much like with the efforts of the "I am the Cavalry" movement which has sent an open letter via to the auto industry, is resentment and dissent without much backing. In an industry which still has more questions than answers - and it gets worse every day - when someone stands up with a possible effort towards pushing a solution you quickly become a lightning rod for nay-sayers. Why is that?

One of my colleagues who is the veteran CISO has a potential answer - which for the record I'm uncomfortable with. He surmises that the collective "we"(as in security community) aren't actually interested in solving problems because the real solutions require "soft skills like personality" and business savvy in addition to technical accumen. It turns out that taking the time to understand the problem, and attempt to solve it (or at least move the ball forward) is very hard. With the plethora of security problems in nearly everything that has electricity flowing to it, it's near-trivial to find bugs. Some of these bugs are severe, some of them are the same 'ol, same 'ol SQL injection and buffer overflows which we identified over a decade ago but still haven't solved. So finding problems isn't rocket science - actually presenting real, workable solutions is the trick. This is just my humble opinion based on my time in the enterprise and consulting in.

I once worked for a CISO who told his team that he didn't want to hear about more problems until we had a proposed solution. Furthermore, I'm all for constructive criticism to help contribute to the solution - but don't attack the person or the proposed solution just to do it. Don't be that person.

I think it may have been Jeff Moss that I heard say it - "Put up or shut up"... so give me your solution idea, or stop whining things are broken.

Why Your Enterprise Most Likely Doesn’t Have a Zero-Day Problem

It should come as no surprise that at Black Hat 2014 this week there were an enormous amount of invaluable conversations, as always. We talked about attacks, exploits and exploitation techniques as well as defenses basic and exotic. A few of these ended up in the same place, logically, and have led me to conclude that the majority of enterprises out there don't have a zero-day problem. Let me explain...

It should by now be clear if you're a security professional that the average enterprise struggles with even the most basic security hygiene. This of course makes life difficult when we start to pile on cross-silo dependancies - for example configuration management - for security effectiveness. While I certainly don't mean to imply that every enterprise can't do the basics, I have yet to meet a CISO who is comfortable with the fundamentals of asset, configuration and user management on an enterprise scale and in a timely fashion.

That being said, I further submit that zero-day attacks and exploits are an advanced level of attack typically reserved for targeted organizations which have significant levels of security capability mandating these advanced levels of effort. Basically if you've got your fundamentals right, and you're doing good block and tackle security, your users are well educated to be skeptical of links and things sent to them the determined attacker will be forced to turn to exploiting yet unknown and unpatched weaknesses in your software to get through your defenses. The truth is, I have come to believe, that the vast majority of enterprises just don't have their act together enough to merit that level of effort from the attacker.

From what I know, an attacker burning a zero-day exploit is a non-trivial matter. Zero-days, while still fairly plentiful, have a cost associated with them and an attacker will use one of these once he or she has exhausted the typical, and often easy, methods of breaching your security. There are simply too many options further down the chain. You have to look no further than a conversation with David Kennedy of TrustedSec who makes it clear exploits aren't required to break in. All that's required, in still far too many instances, is sending someone in the organization a malicious link, or a malicious file and they'll open the door and show you their closely-guarded intellectual property ... and probably hold the door for you as you walk out with it. Yes, indeed it is that simple to exploit corporate security with brain-boggling results.

So why burn a zero-day? Attackers typically won't unless they've encountered roadblocks in other avenues. Since PowerShell is installed on every new Windows PC, it's the perfect tool to use to execute an attack, legitimately, on a target host. All the user has to do is let you in...and we all know that most users will still click on the lure of a dancing bear or the promise of nude photos of their favorite celebrity.

So while your enterprise security organization may actually encounter some malware with zero-day exploits in them, they likely aren't targeted at your organization. The problem your average enterprise has is poor fundamentals - leaving you open to all manner of exploit and penetration without the use of any more advanced techniques than "asking the user for permission". So why would an attacker burn a precious zero-day against you? They likely wouldn't. Unless, you know, you're a target.