Over the weekend, a self-made "hacker" who goes by the handle N4rCochaos claimed that he had hacked one of the Web's most visible security journalists, Brian Krebs.
According to his claims, he hacked KrebsOnSecurity.com and obtained a database dump of user names, email addresses, and passwords.
For the curious, the hyped-up database dump is available on Pastebin. A quick search of Google is all that's required to debunk the hacking claim. What N4rCochaos published is actually part of an article Krebs wrote in May of 2013, when he profiled an alleged DDoS service called Ragebooter.
For further proof that the hacking claims are little more than a poorly planned grab for attention, one only needs to consider that Krebs' website doesn't offer account registrations. So there is no way a user list could be compromised, as one doesn't exist.
When a reader pointed me to the Pastebin post and the laughable hacking claims, my gut instinct was that nothing happened and this really wasn't news. But the more I thought about it, the more I realized that there was a lesson of sorts that can be learned from this comedic weekend event.
So what's the lesson? It's that, even if Krebs' website was hacked, it wouldn't be a big deal.
He keeps nothing of value stored on the server. There's no financial information, or personal information. There are no super-secret sources, or story ideas. His site is just a basic WordPress install with limited account functions and access.
Worst case scenario, the name and email address entered into the comment section of a given post is all that would be stored, along with the comment's text. Assuming the database was compromised, that's all an attacker would get. Hundreds of people saying "great job" or pimping products. Moreover, this is all public information anyway. Hardly seems worth the effort, no?
The claims of hacking got me thinking about mitigation, and lowering the overall attack surface.
Since there's nothing of value on the website, then a successful attack – while possibly time consuming to clean up – really doesn't hinder Krebs' day-to-day operations. Even DDoS attacks, which he sees somewhat regularly, don't impact his work all that much.
Could it be embarrassing or harm his reputation?
Not likely. He's one man, and outside of updating WordPress to the latest release (along with the plug-ins) there is little he can do to secure the platform's code.
Working security professionals wouldn't bat an eye if Krebs' domain was to suffer a defacement, or an unpatched SQLi was used to dump the database. Sure, it would be an unpleasant event, but it wouldn't be his fault. As long as he didn't try to hide the facts (as a journalist – he wouldn't – believe that), he would walk away from the incident unscathed.
So this post has two points.
(1) No, Krebs' website was not hacked, and even if it was, it wouldn't be a big deal in the grand scheme of things. There's nothing of value on the website, outside of the content itself.
(2) To me, defense isn't about stopping every attack that comes your way. It's about lowering the impact of the successful attacks, while recovering from them quickly. You can do this with segmentation and separation of assets, along with strict access control. Know what's most important to you or your organization, and focus on protecting it. The process isn't easy, but it's worth the time and energy it takes to accomplish.
Website compromises and defacements shouldn't be an emergency. Events like that should require a restoration of backups, and checks to ensure that there's nothing out of order in the site's code or on the server.
On the other hand - if critical information is stored on the webserver and inside the website's database (ignoring the previously mentioned rules of thumb) - then defacements and compromises are an entirely different matter.
If that's the case, then the event becomes a nightmare. Because you were the low hanging fruit, and unless proven otherwise, you have to assume everything on the server was compromised.
Such an incident will require disclosure, notifications, and costly regulatory and compliance measures. Free credit monitoring doesn't come cheap if you're required to offer it to a few hundred thousand people at a time.