Whether it came to you as a sudden epiphany or a growing acceptance, deciding to integrate security into your application and development culture is no minor decision.
Sure, there are people who make this choice and treat it as it’s no more complex than deciding whether to wear red socks or blue socks today. (this rarely ends well)
For everyone else, this is a significant milestone and dependent on where you on in the evolution of your product.
If you are at the start of your project, involved in a start-up or otherwise near the beginning of your applications life you have you very few technical or process constraints in place. Your technical debt collection is still more of a molehill than a mountain and you don’t have a complex hierarchy of people involved. Great!
Sadly however, unless the angel investors have shined their lights on you, you are probably fiscally challenged and unlikely to have any existing collateral, systems or tools to work with. Couple this with trading off your limited resource between innovation and development (that thing that means you can pay your bills and put food on the table) and security (more likely to cost you money than make you money) — justifications can be hard to come by.
However if you are like most organisations, far from those Greenfield days, the task of retrofitting and integrating security with your existing systems, processes and code bases can be a little on the daunting side of things for a whole range of different reasons.
You probably have a budget and a range of people and resources available (with the right business cases of course) and you may even have some tools and processes in place. However your technical debt is definitely in the mountain phase (caution, avalanches possible — proceed with care) and you have a codebase of hundreds of thousands of lines of code (representing thousands of hours of work) — that has never been touched by security.
So regardless of who you are and what your circumstances are — the first question on your journey is going to be the same.
Where do I start?
There are two possible answers to this question.
The quickest, simplest and mostly likely to drive you to rage is ‘anywhere you want to!”
Yeah, I told you that one was going to irritate you.
The longer, more comprehensive answer is that to begins with a metaphor
Stop trying to climb the mountain in one day if walking to the end of your garden will take a week.
In short, despite feeling overwhelmed by the enormity of the task ahead of you — there is one simple truth that should allow you to start taking steps forwards.
The is no such thing as perfectly secure unless you are willing to stop doing business.
When you are taking those first steps, remember that the aim isn’t for the perfect secure application after x number of days/weeks/months. There is no magic certificate that will appear when you have squashed 50 bugs or implement 3 standards. You will never achieve 100% secure and that’s OK. Don’t aim for a lofty far away target now, make your aim more realistic.
End everyday with an application that is more secure than it was yesterday
In essence what I am describing is continuous improvement and setting realistic goals.
Security isn’t something that is ever done or complete so don’t treat it like it can be. Security is a combination of looking at every aspect of your application and organisation every day and asking ‘how can I make this better’.
So … where do I start?
Like I said, ‘Anywhere you want to’ but if it were me I would start with what I am working on already, the current change or feature, every line of code you write today, every quirk/bug you solve this week.
The time will come very soon to evaluate how big and complex the mountain ahead of you is,but for now, let’s start by taking one step.
Originally published at www.defensible.me on May 25, 2014.