I have spent the last year delving into the examination of how development teams have implemented security into their system development process. I am amazed that even after all the work that has been done in secure coding “the secure design movement”, and the numerous Cyber security related incidences that have happened, most development teams still don’t understand, respect, or even care about application security. Developer “I am sure the framework handles that”, Project Manager (PM) “Code review!!, why would we do that? that’s why I hired professional coders they don’t need reviewing.” AHHHHHH!!!
Those that do attempt to practice security approach, do it ritualistically more like superstition, then from skill and knowledge. Developer “We can’t do that because the security Necromancers have forbidden that!” (I did say necromancer because everyone knows all security folks are on the dark side. This is somewhat by their own provocation). PM “Dynamic code analysis, what dark magic lies in this?; It may disturbed the sacred balance of our network; and invoke the wrath of the ogre boss.” Some of the most prevalent responses I get to application security are, “Security gets in the way” or, “This really does not apply to my application” (waving their hands and trying their Jedi mind tricks “These are not the vulnerabilities you are looking for.”) , or my favorite “This is not my responsibility, clearly this is a infrastructure issue”.
Herein lies the problem, “the perception”of security is considered an isolated process with little respect or ownership of the software developers. One that at best is a necessary evil, limits creativity, restricts capabilities, and slows down the overall development process. Most of these teams would have kept on going with these same beliefs and misconceptions. They would have never by their own volition invited me or even set aside the time to discuss their security practices with anyone, let alone entertained the idea that their applications are riddled with vulnerabilities. Luckily for them “wink wink”, the stakeholders of these applications had some concerns. The development teams’ leadership(my customer), felt that their security may need a closer inspection primarily because of regulatory requirements, but all of them questioning their own security posture, the risks involved with operation, and the desire not to show up in the news.
Ultimately this was a success! After the development teams got over the security misconception they had been taught and began to apply the tools and concepts provided for them. They started to understand secure development and see the benefits and efficiency that it brought to their systems.
Unfortunately the motivation that drove them is not ideal and is not the situation for all developers. Something must change in the approach, or for most developers security will stay on the back burner or an after thought.
I believe the key here may lie in rethinking the role of security in software development, security is not just protecting the system and the network, security is essential to the (UX) user experience. I am not talking only about how users authenticate, eq. password or 2 factor. It should happen holistically throughout the application. Confidentiality, integrity and availability are the responsibility of the developers. We have a duty to our users; due diligence must be taken to insure that the users experience is secure. We are the stewards of more and more user data, almost all of it like it or not is PII (personally identifiable information); at least in respect to their digital persona. Users are a part of the lifecycle of the application. Truly the users security experience is essential to the existence of the application. Too many data breaches, stolen identities, and DDOS’s users will leave the application. And when all your users leave, the application dies. How is that for an impact on the lifecycle?
I recommend and whole hardily agree with David Platt that we focus on the real reason we are developing applications because we want people to use them. Give this series a chance, I think you will be able to find some practical takeaways you can apply to your development process.
Take a look at all the work that David Platt has put into UX, it’s one of those things you think is obvious, but once you stop and take a closer look, its obvious you have been going about it all wrong.
Ok, developers are users too, users of development tools, users of frameworks, of IDEs, Operating systems and if to much is asked of them they too will leave or more then likely ignore the advice they are given.
That’s way I feel compelled to start this series, my plan is to show by example that security can be coupled, integrated and even infused into the Software development process. Without the rigmarole that seems to be encouraging developers to avoid security considerations.
In the first part of this series I am going to start by reviewing an application that is in the process of development and has not, lets say put security first. I will evaluate its design, identify security concurs and get it in line with the SDL.
I will end this series by stating a new project with secure development from its inception.
In these post I am going to be relying heavily on Microsoft’s excellent Security Development Lifecycle (SDL), the Open Web Application Security Project(OWASP), and utilizing NIST SP 800-53 as the framework.
I am going to be following a very simplistic Lifecycle, I will point out how this fits into an agile process just to reinforce that it is not outside of a lean process.
The time to ignore security has long since passed; the time to implement security after the fact has passed. The time has come to stop thinking about security as a step or a process in the development process and embrace security as fundamental at the core of every step and in every process.
Before I get started I would like to make a few more points about software security and development.
First security is not the enemy of an efficient lean process, quite the contrary. I am not here to ruffle the fathers of developers and accuse them of building their foundation on shifting sand but some fathers will ruffle. A lean process is a moral process in that it chooses the best(right) path in favor of a quick path. Short cuts are risks, Security debt is code debt. keep this in mind this is the heart of secure development.
Second Security through obscurity is a lie, this is an extension of the first point. Another name for “Security through Obscurity” is “A Zero Day Exploit. If you feel that you are the only one who knows or will ever know about the flaw in your application you have already failed. (Ignorance is not bless)
Third the importance of a good vision and sticking to it, I can not emphasize this enough. Knowing where you are going will help you make the right decisions. This has been one of the biggest problems I have see. Question: Why did you leave this unused component here? Answer: “We did not know if we needed it. We where really all over the place then we did not know what the final product was going to look like.”
Nebulus is an enterprise service bus notification system rapidly developed for the sole purpose of development education. In the coming weeks Nebulus will go through a transformation as we begin to review its current development process and adapt it to a more secure process.