1 Raindrop

Beyond Marking Time

Some years back, I was decompressing with another security person. He asked how my conference was going and I said "Great. I did a training today and I am doing another training tomorrow. How's yours?" He groaned, "Ughh. I did a training today and, " he sighed, "I have to do another tomorrow."

It surprised me, sure training is a lot of work, but I really enjoy the idea flow, and seeing developers and security people think about appsec in real ways. I have met many great people to work with in classes and usually leave class with energy than I started.

He went on to complain that his class was dead, people falling asleep and bored and so on. I should pause here to say that this is a very well regarded security person. So my class is all geeked up and his is drooling, what was the difference? I am on ok presenter but this guy is a way better presenter than I am.  I have good content, but so does he. So what is the difference?

Then it hit me, his classes were "have to take" classes, not exactly certification but close enough. People in his class were there on sort of a forced march, because they had to. Not in my AppSec class though. AppSec is many things but its not a glory detail with shedloads of funding. The people in my class sought it out and wanted to be there, they were trying to get to the next level not just check a box.The difference between these two things is as night is to day.

So while AppSec has many problems, its drastically underfunded for one thing, I am glad to work in a field where the majority of people in it self selected to take on a harder challenge. Its not for everyone but its work worth doing. OWASP and other AppSec groups are great in that they bring together practitioners  from lots of different companies. Sure many people are the "one AppSec person" at their company or part of a single digit percent of the security team/budget, when more like half should be invested in AppSec.

The difference between my class and the other security persons wasn't my presentation skills or content. Its that my class the information was pulled and his was pushed at the audience. This is consistent with my experience. When I teach a 101 AppSec class inevitably there are lots of 201 questions. In 201 class there are lots of 301 level questions. In 301, the people email me years later, start their own blogs, OWASP groups, and go do some really neat work. Its a small area, but AppSec is growing because a core of people are intrinsically motivated to work on it.

AppSec is fundamentally a grind it out, bottom up business. Its not a path to glory, but AppSec teams make a difference. Even nascent or smaller AppSec teams are bringing something new and useful to their org when they improve coding practices and patterns. Sure AppSec is underfunded by around 10x at most companies, and this creates a major scaling problem, but these are better challenges than being in a part of security team with bigger budgets when all that gets you is people marking time and falling asleep.

Avoiding the Mobile Blindside

I am not much of a football fan, in fact over Thanksgiving holiday I didn't watch a down. One thing I do appreciate about the sport though is the acknowledged role of defense in success. Many of the most successful teams are defense oriented, and even the offense is built around protection schemes like protecting the quarterback. The worst place for protection to fail is on the Quarterback's blind side, then rushers can close in quickly without the QB being able to scramble out of the way. Catching the QB unaware makes a bad situation (broken protection) worse (QB unable to react = sack).

This same blindside dynamic plays out over and over in infosec. The most common is that infosec only hears about a project a short time before the project is due to go live. Even when there are obvious problems with clear and doable fixes its often too late to put them in. The result of this process is some sub optimal decisions - (attempt to) delay the project or let it go live with rudimentary fixes in place. Neither adds much value from a security standpoint, and it stresses everyone out on top of that.

Mobile takes the security blindside to a whole new level. Mobile projects are often sponsored outside of IT, say by marketing. They are often developed outside IT by new, mobile specialist teams unaware of standard dev practices. And compounding the problem, Mobile dev cycles are very short, a iOS or Android app can go from cocktail napkin to "done" in the time a traditional enterprise app spends writing requirements.

But, you say, there have not been that many mobile app security issues we need to be concerned about. And that is fair, but only to a point. Apps are not static. Not too many people had heard about SQL Injection in 2001 but the seeds of lots of problems were sown in Web code built during that time.

In addition, mobile apps are not islands. They connect to the enterprise back end. This mobile to enterprise wormhole creates an opportunity for attackers. They can find holes in identity schemes, new ways into backend data and functionality. Mobile clients do not get near enough focus from a security perspective, and yet they get way more than most mobile servers. And yet the mobile server side mainly represents far more downside risk than the client.

All is not lost though. Many companies are setting up mobile SWAT teams, or Centers of Excellence. To "do something" around mobile. These teams usually harvest a handful of people from dev, ops, security and other teams. They have the chance to write the playbook from scratch for mobile.

A decade ago, we lost a lot of time in web security with heads in the sand that the firewall would protect us, the industry mostly ignored vulnerabilities like SQL injection to the attacker's benefit. We do not need to see that movie again. The industry has learned a lot about building SDLs, deployed better tools, and so on. We have a chance now to get ahead of the software security problem for mobile instead of waiting and letting it fester. This means doubling down on Mobile SDL, Mobile App security tooling, and frameworks.

The best time to get involved is now, because waiting just replays the same movie and our future selves will wonder - hey why didn't they build a better mobile identity scheme or deal with mobile App security in 2013? Not just getting involved, but getting involved in a way that anticipates the Mobile blindside, having tools, frameworks and security processes built out that are ready to go to work quickly when the project you never heard of crops up with - hey we are going live in four weeks. The mobile blindside is probably unstoappable for most companies, but we can still prepare. I have built out a few services along these lines and will blog more on them, in the meantime email me if you want to get some more info.