Last updated at Thu, 31 Aug 2017 14:18:58 GMT
The recent vBulletin hack is the most recent case of a compromise being labeled as a ‘sophisticated attack.' Predictably, the internet exploded with people complaining about this label, stating that it was just SQL Injection. The same thing occurred with the news of the TalkTalk breach. Before that, the Playstation Network breach comes to mind, although there have surely been many in between. I will issue my mea culpa right now. I have publically blasted people for this in the past. But today I stopped and thought about it for a minute — there are a few relevant points that need to be addressed in this argument.
The first point is that it is a fallacy to say an attack isn't sophisticated just because it is SQLi.
SQLi is a category of vulnerability, and has a broad range of application. A SQLi can be very simple, or very difficult to pull off. It can sometimes involve pulling together several different behavioral elements to get the data you are looking for. Of course, sometimes it doesn't. The point is, unless we have the details about that particular SQLi, how can we truly say it wasn't sophisticated? We seem to operate under the assumption that all SQLi is exploited just by running SQLmap against a page and then winning. That is far from being always true.
The second point is the fallacy of who gets to determine what is a “sophisticated attack.”
As Information Security experts, I think that we feel that is our sole purview. Nobody else may determine how sophisticated or lame an attack was but us. By the same logic applied to these SQL injection attacks, we should be calling out every buffer overflow thusly. “Your 0-day isn't sophisticated, it's just an SEH overwrite. You don't even have to use a stack pivot.” Think how absolutely pedantic and elitist that sounds.
I know what you're saying right now. “But Cosine, they're just using the term ‘sophisticated' to make it sound okay that they got breached.” Here's where a third and fourth fallacy come in. Let's keep taking them in order.
The third fallacy here is that security is easy.
Yes, there is PR spin here, no doubt. If security were that easy, there wouldn't be so many great jobs out there for us, and I'd have to get a more honest line of work. The horror! We have made great strides in the past decade with initiatives like SDLCs, education on secure coding and best practices. It takes a long time to move an entire industry though. There are also economic realities that companies have to deal with, and developers and sys-admins face incredible pressure to meet business deadlines and objectives. This ties in to fallacy number four.
Fallacy number four is that this kind of engagement is useful in any real or meaningful way.
It is negative reinforcement at the very best, and outright shaming tactics at its worst. Shaming is not the most effective means of teaching or correcting behavior. Imagine if you were in math class and your teacher said to the whole class: “Jimmy/Susie can't solve a simple inverted matrix problem. Why don't they get it?” Would that have helped you? Would you have done better at the next inverted matrix problem? Maybe you would have. Chances are equally good you would have slunk down in your desk, and prayed nobody noticed you for the rest of the class. Chance are also good that you would feel stupid, and start to give up on yourself, doing even worse in your math class. So why do we resort to this behavior in InfoSec?
My belief is that we are really disappointed in ourselves. We are not changing the world of IT as fast as we would like, or maybe even thought we would. Maybe we thought, deep down, that we'd have SQLi eradicated by now. The fact that we have not eradicated most SQLi by now is our fault though. There may be blame to pass on to other parties as well, but this is our job.
If developers are still not following best practices for secure coding, it's because we haven't engaged them well enough.
If businesses are still pressuring their sysadmins and devs to push things out fast, and bypass security checks, then that's on us too.
We need to do a better job of education. If that math student can't solve an inverted matrix, that's on the teacher to do something about. We need to be good teachers. We need to engage in a positive way. Yes, it is really hard, especially when we see the same mistakes time and time again. This is what we signed up for though. It's time to tighten the belt and dive in.
When we see a rash of SQLi breaches, it's time to step up education campaigns on SQLi and how to fix and/or mitigate it. When we see these breaches, we need to hold it up as an example of why these things matter. Not to shame those who were hit, but rather to show the consequences.
I believe in us. I believe in our industry and the incredibly intelligent professionals in it. I believe we can change the course of this ship.
First, we have to accept that it is going to take time. It's going to take a lot of time.
We need to stop every so often and evaluate how we are engaging with people. Are we being positive? Are we offering real solutions, or helpful insight, or are we just criticizing?
Think of yourselves as teachers, and keep that image in your mind. Every time you want to be harsh, or critical ask yourself “is this really helping?”
We'll still slip up, all of us. The important thing is that we keep taking a deep breath, and re-evaluate our own behavior. Cheers!