Tuesday, April 10, 2012
The Password Zombie
In 2004, Bill Gates predicted the end of passwords. He thought we'd be using Smart Cards by now. Yet here it is eight years later and we're still using them! This appears in the Wired article, "Do You Really Need a Password You Can Barely Remember?" But what really caught my eye was the section title, "The Password Zombie."
Labels:
Passwords
Friday, February 24, 2012
Information Security Blunders
I enjoyed the "25 Infosec Gurus Admit to their Mistakes…and What They Learned from Them" article on the State of Security blog. I especially liked #15, "Yeah sure, the USB key is secure" and #21, "Eventually, when I have time, I’ll encrypt that hard drive."
Unlike Darth Vader and the Galactic Empire, we need to recognize our mistakes and learn from them.
Labels:
Darth Vader,
Information Security
Friday, December 23, 2011
Careful with that coke can

Saw this referenced on Bruce Schneier's excellent blog and thought I'd pass it along.
Basically a tutorial on how to open padlocks using pieces from a soda can.
Not that I think popping open someone else's padlock is something you should be doing, but there's a salutary lesson here for anyone in the security industry. Those locks cost a great deal more than the price of the coke can, but with a little ingenuity and perseverance, they can be overcome.
Padlocks, like any kind of security (especially software-based) have their place, but don't rely on any *one thing* to keep you safe. Because you just never know...
Labels:
Bruce Schneier,
ITStactical,
Physical Security
Thursday, December 22, 2011
Cracking MD5 really, really cheaply
Kudos to Trend for their blog on this.
The short version - don't bother to rent time (however cheaply) on AWS in order to brute force MD5 hashes, just use google to do it for you.
Loooovely.
Tuesday, October 25, 2011
Breach survey shows a little tiredness

Logrythm recently published these results from a UK-bases survey which, I think, are interesting for a number of reasons.First, they do indeed show a public becoming increasingly weary of breaches. Almost three quarters want legislation to force the publication of breaches, while more than a quarter say they would never have anything to do with a business that lost their data.Of course, without mandatory notification, it’s hard to say who has lost what. That’s up from 17% last year, which means that attitudes towards business that fail to keep other people’s information safe are hardening.
It’s none too soon, either.Europe has lagged behind the US in terms of actually naming and shaming and legislation has been painfully slow in coming to protect information, especially to force some light into the murky world of data security.
A full 80% say they have reservations when it comes to trusting organizations to keep their data safe from hackers (which makes me wonder that the other 20% know that I don’t….) The most interesting stat (and the handy infographic can be found here) is that more people think social networking sites are trustworthy than banks or online retailers.
I’d love to see a similar survey in the US – although I suspect that the overall numbers wouldn’t change all that much.
The organization UK folks trust most to keep their data safe? The government.Which would be fine, if the UK government wasn’t also the source of some of the largest breaches in the country’s history. This gem managed to affect almost half of the entire population.
But hey, anyone can make a mistake…
Labels:
Breach Notification,
Security,
UK
Friday, October 7, 2011
My Little P0wny
We’ve heard a lot about “Operation Aurora” and “Operation Shady Rat.” There is a lot of great detail after the fact. But I’ve found myself wondering, what would you do if you were in the middle of all that? Like your boss just said “figure out what the heck is going on!” What would you do? Where would you get started?
Well, I got hacked... Once! All bluster aside, I could be p0wned right now and not even know it. Nonetheless, I'm going to tell you about the incident and how I figured it out. Note: I also referred to the event here.
Here is the set-up: In the mid-1990s, I was the administrator for a small Internet Service Provider (ISP). For the terminally nostalgic, we were running Slackware and a 1.2 Linux Kernel from the Walnut Creek CDROM set.
We had been receiving complaints that service was slow. So I fired up a terminal session to figure out what was going on. The first thing I did was to check disk space.
What the heck?! I had just installed a new drive! All right, I needed to take a look at what was going on.
OK. Nobody was really playing Doom. But what I really saw was that Eggdrop was getting a huge chunk of CPU and memory. Eggdrop? Really? I never installed Eggdrop. So I did a find (for the pedantic, find / -name eggdrop –print). Sure enough, I found it and something else called BitchX. The kicker was that these things were installed in the home directory of a subscriber that was no longer with us. That’s right; the user’s account had been disabled. Well, it wasn’t now. Along with the IRC client and bot, there was a substantial amount of pr0n. Lack of disk space problem solved.
It turns out, my attacker had gained access through a Sendmail exploit. Hmmm… I guess patching is important. Nothing like learning a lesson the hard way. I checked wtmp and found an IP address. I considered calling the FBI, but at the time I wasn't sure they would get involved for anything less than $5,000. Also, since I couldn't really put a price on damages, I didn't think they would take a look. Instead, I did a reverse lookup on the IP address and emailed the administrator and abuse@ accounts and told them about the incident.
So how does this relate to the security world? Well, as others have observed, recent attacks have been of various (levels) of sophistication. The bottom line is that some of the techniques that worked on me may still be in use. Instead of letting them happen, learn from past mistakes and work forward from the forensic analysis. For example, I learned about TCP Wrapper after this. And if I hadn’t been logging to syslog, I would have been missing several clues.
In short, minimize running services and keep a current list; stay up to date with patches; and have a working log policy.
Labels:
Breaches,
Log Analysis,
Policy,
Security
Tuesday, October 4, 2011
On Tap Security
I wrote a piece recently in cloudcomputingtopics.com on the way in which cloud security is changing and maturing. I don’t intend to re-post the whole thing here, if you’re interested you can certainly go and take a look at the full length piece on that site.But I do think there’s a discussion that needs to be had here. That the cloud introduces security risks seems to be generally accepted as fait accompli. Which in many ways it is. But I want to make sure that the discussion doesn’t just stop there.
Yes, cloud introduces complexities and new areas of potential vulnerabilities, and yes, it could totally bork your security processes. But it doesn’t *have* to.
Cloud computing isn’t some kind of curse handed down by capricious gods to punish information security folks. The problems are the same, in many cases the software is the same. It’s possible to solve the problems of cloud security – but it is almost certainly going to require us to adopt new approaches, new mind sets and yes, occasionally some new technology.
Cloud computing isn’t some kind of curse handed down by capricious gods to punish information security folks. The problems are the same, in many cases the software is the same. It’s possible to solve the problems of cloud security – but it is almost certainly going to require us to adopt new approaches, new mind sets and yes, occasionally some new technology.
One of the main things I wanted to draw attention to in the original post was that recent publication of the CSA’s new whitepaper of Security as a Service.
The idea is to start to define the different kinds of security services that could be offered through the cloud. Of course, some of these are going to be used to secure traditional infrastructures, and like any cloud service the idea is to make them more generally available, with lower up-front costs, and with less of a skill-gap to cross.
But they will also be equally applicable to security of other cloud services. Security as a service offers the opportunity to integrate highly scalable, on-demand and up-to-date security solutions into your existing security processes, and that should align them nicely to at least some of the problems of meeting the needs for cloud information security.
Nothing is going to be a panacea - but there are opportunities to use the move to cloud to actually improve security, and having on-tap security services when and where you need them is almost certainly going to be one of those opportunities. Let’s not waste it.
Labels:
Cloud,
Cloud Security Alliance,
Information Security
Subscribe to:
Posts (Atom)