Building Security In

Let's take a second to talk about development.  For most of us there will become a point in our careers that we will have to work on some type of development project.  For some development may be a career, while for others it is just part of the journey of professional growth.  The model by which you develop may be different in each position you hold - waterfall, spiral, extreme programming, agile, and any other rad types that didn't make the cut for this post.


Security in development models has only truly become a concern recently; probably about the past 10 years or so with a major emphasis in secure coding for probably the past 3-5 years.  I'm not necessarily saying that security was never there, certainly early developers had it in mind or operating systems wouldn't follow the model of separation shown between applications, high-level drivers, low-level drivers, supervisory layer, and the kernel; dacl's and rbac wouldn't exist, and so on.  My only real point here is that it is only recently that security early in development has become a focus instead of an after-thought, and after so many people have been developing for so long without it as a major concern. 


So it should come as no surprise then that convincing developers to build security in is a tough feat to accomplish.  After all, it's no secret that security adversely effects many things, and that security for the past decade plus has revolved around securing networks, traffic, and things that have already been developed and are now in place, or have been in place for a long time.  So basically what we are talking about here is a culture change that needs to take place.  As time passes by and attrition takes place, the old-timers will move on, and as more people attempt to build security in early best practices will evolve and a new way of thinking will be born.


I am a huge proponent in the belief that development, testing, operations, and security can co-exist.  Here's a few ideas on how we can better make this happen:


#1. Build security in from the beginning.
Program and Project Managers should be on board with this one.  It seems to be a common occurrence that security is an after thought.  As such requirements are identified too late, slack time is exhausted, milestones and critical paths stand to shift to the right, cost overruns occur; it's just bad all the way around.  The analogy of an onion is often given to define layered security.  Well onions don't just appear one day.  They grow from a seed and expand layer by layer into their maturity.  So should security - FROM THE BEGINNING!


#2. When building in security create a workflow.  Because we all know that security can have adverse impacts, identify those security related functions early that may cause issues.  Document others through testing.  Then as you pass on templates, instructions, or whatever the case may be pass that information on to the next person in the line.  Maybe that's another developer, maybe it's an admin... doesn't matter.  The idea is that the security integration to and through development builds on itself as it passes through the development lifecycle.


#3. Make security extensible through your already existing capabilities.  By today's standards everyone should be following an SDLC, CMMI, and/or ITSM process.  Incorporate it during planning within the SDLC and follow through, incorporate security processes into CMMI practices so you can watch it mature and contribute lessons learned to the community.  ITSM will provide the necessary stakeholders for security reviews when discussing configuration and change management.


#4. Take a holistic, but realistic approach.  This mostly means planning.  Too often schedules are crunched into unrealistic timelines which force things to happen outside of their natural order.  This is inefficient, results in duplication of effort, and can lead to total project failure.


These are just a few thoughts...