Security professionals and developers don't think alike. And, yes, I am making a sweeping generalization with that observation. There are exceptions, of course. But for the most part the characterization is true, and that has a lot to do with why security professionals often can't comprehend developers' attitude toward security matters, and developers can't stomach the ways security professionals want to mess with their creations.
Developers look at systems, apps and other software tools and are impressed by the cool things they can do, and maybe by the economy with which it was all achieved. They marvel at features and innovation. In software parlance, they focus on their products' functional specifications (or user stories, for you agile folks).
Security professionals look at those same things and immediately analyze them for what can go awry. We have a healthy presumption that things will go wrong more often than not. We are always trying to anticipate how we can respond to the things that go wrong and thinking about how we can keep them from going wrong in the first place. For security professionals, the coolness factor isn't all that meaningful if it's overshadowed by the risk factor.
I spend a great deal of my time working directly with software developers, architects and other people whose focus is on building things. As a class, they are full of optimism, and that trait probably has a lot to do with why they are good at building things. On my side of the table, though, pessimism reigns, and the builders often complain that we security folk are always raining on their parade by constantly focusing on negative things.
But you cannot shake a security professional's default attitude: We assume everything is dangerous until proven safe. We know that when we live by that tenet, we end up with more secure results. Say that I'm presented with an app that takes user input. I am going to presume that the input data is poisonous and will not be shaken in that presumption until it can be proved to be safe. I know that software that immediately acts on input is often susceptible to injection attacks, cross-site scripting (XSS) and other security defects. So I demand proof that none of those things can happen. When I do this, we end up with software that's more resilient.
So how do we instill in our junior software staff a healthy sense of mistrust? We need them to take a lessons from squirrels. Let me explain. When I ride my mountain bike, I often encounter deer, fox, raccoons, squirrels and other wildlife. In all of them, the survival instinct is strong. As soon as they see me approaching, they presume me to be a threat and immediately scurry away. It's a reasonable reaction — and not just because it's me.
Sign up for MIS Asia eNewsletters.