Picture this scenario:  you, your spouse, and family are standing in front of your recently completed home.  You spent years saving, planning, and building the home of your dreams.  As the sun sets on the first day in your new home, your smart-aleck kid asks, “How do I turn on the lights?”  Just then you realize you didn’t install any electricity in the home of your dreams… now turned nightmare.  This is exactly what has happened to many   project managers, acquisition managers, and/or developers when it comes to information security.

You spend months, sometimes even years, planning, designing, developing, and deploying the business solution that will save the organization loads of money and make you a star, only to find out, hopefully from someone within the organization and hopefully not from an outside attack, that you did not plan for the security of the information and/or the information system.  An example of this happened at a government agency recently.  I will speak very generically about this to protect all involved.  An application was deployed that solved a legitimate business need.  It had a good amount of users and worked well for approximately one year.  Employees of the agency started to report an unusual amount of identity theft issues.  Investigators traced the source of these issues back to this application.  Users had personal information, including their bank account information, compromised which caused numerous fraudulent transactions.  Once the agency discovered this problem, the application was taken offline, security was added, and they re-implemented the application while looking for a replacement.

So what’s the problem with adding security later in the process?  Well let’s go back to the house scenario… image the cost associated with running electricity to the house that is totally completed, then installing the electrical panel, running the electrical lines from the panel to every room, fixture and outlet, tearing out drywall, making holes in the studs and the joists, wiring, installing the fixtures and outlets, and finally reinstalling/repairing drywall, and painting.  The extra time and labor costs would be enormous.

Like the home scenario, an application or system reprogramming will set the project back in both money and time, essentially, going back to the drawing board.  For example, imagine trying to retrofit security into an application’s code.  You would need to work through the SDLC all over again, but this time with security in mind.  This means creating security feature requirements, analyzing security best practices, reviewing the attack surface, running through threat modeling, and you haven’t even started to think about manual code reviews, code scanning tools, pen-testing, etc.  Considering that you basically have to review the entire application from scratch and purchase security development tools, the cost would obviously put you over your initial project budget, if you hadn’t already surpassed it …  not to mention the time involved in fixing the problem.  And we all know that time = money!

So obviously, like electricity in the house, information security must be included in the planning process, but whose responsibility is it and exactly how do they go about including it in the system development lifecycle (SDLC) of a system or application?  First, let’s start with the “who” problem.

You would hope that anyone requesting a new piece of hardware or software (system) would be concerned about the security associated with that system, but in a normal situation, individuals rarely are so knowledgeable; they just want to improve their business performance by purchasing the new system.  When the requested system gets a project manager, surely they would know and ask about the system’s requirements for security; but sometimes no.  After the assignment of a project manager, hopefully an Information System Security Officer (ISSO) is designated and they would require security to be included in the SDLC.  Next, if there is code development required for your system, the developer should be versed in and use secure coding practices in addition to any of the security requirements that are identified for the system, but in most cases, if it is not written in the requirements document or statement of work, security is overlooked. If the developer doesn’t ask for security, the last line of defense may be the acquisition officer.  Chances of that person adding security requirements are better if they are from the new school (versus the old school), but how often is that the case?  If that does not happen… basically you’re screwed. Call the electrician and start ripping out the walls.

Now for the $64,000 question: how is security included in a new system?  That answer is easier than you think. Ask for it.  Require it.  As mentioned above, someone has to include it in the requirements statement from the very beginning. Whatever bells and whistles are required to satisfy the business need of the requesting business function, don’t forget to include security.  What?  You don’t know how, what to ask, or what to include?  Well that answer isn’t too difficult either.  The National Institute of Standards and Technology (NIST) has done all the research for you.  They have documents that cover just about every aspect of technology and the secure deployment of that technology.  (NIST Special Publication list) If you want the full list of security features that need to be included in a system:  SP 800-53 rev. 4.  If you want to review how to include security in the SDLC then review: SP 800-64 rev. 2.  Other important documents to aid you in the development of a new system are the risk management framework guide: SP 800-37, deploying a web server, email server, firewall, wireless solution, and even the hot issue of mobile devices (in draft).  See the links included.  I think you get the picture.

Speaking of pictures, now picture yourself sitting in front of the CEO of your company, or in front of the executive director of your agency, answering questions about an information security breach.  Hopefully, those questions are about how your system was the only one in your organization that did not have information compromised.  You will be the star of the organization- an example of how security should work.  Otherwise… we don’t want to even think about that alternative.

So take some time to analyze the security of the systems within your organization.  Is there security in place?  Do the users have access to only what they need in order to accomplish the mission?  More importantly, are they restricted from what they do not need to know? Remember Wikileaks?  Are there any new systems coming online?  Is security included in every step of the SDLC?  Is there an ISSO?  Do they know what they are doing?  These are just a few of the questions that need to be asked.  Is someone asking them?  You can ask them!

$pIk3 and mind.