Secure Software Design and Development: Part 1

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.

The Plan

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.

Soap Boxing

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.

Further Pontification

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.”

Enter Nebulus

https://github.com/Mike-McDonnell/Nebulus

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.

 

 

Simple Secure Data Transfer: Part 2

In the previous post Simple Secure Data Transfer: Part 1, I discussed modeling a data encryption method that relies on moving the encryption negotiation “out of band“.

In this post I will complete the process with a simple Web API that will receive and decrypt the Data.

Lets start by creating the web method that will accept our encryption envelop.

When we receive the envelope we will need to retrieve Server B’s certificate.

Here is a helper method to retrieve the certificate by thumbprint.

Now that we have server B’s certificate lets decrypt the data.

I separated for clarity the asymmetrical decryption from the symmetrical.

Now we have the data unencrypted. We are now free to do what we need with the data, save it to database, respond to some action in the data etc..

 

 

 

Simple Secure Data Transfer: Part 1

I was posed the question the other day (details not important) on how to synchronize data between two systems on two different networks. System A has the data, system B needs the data, System A can reach out to system B, system B cannot reach back into System A.

This is a pretty straight forward client-server scenario. One we all preform every day on the web. Every time we submit a web form or even interact with a webpage we are doing just that. Before we jump into this as the obvious solution, lets stop and ask the question. “Is this data sensitive or does it have anything identifiable in it?” this can lead to the question  “How can we be sure this is secure?”

Well TLS/SSL, Simple Right?

Yes, and no

If we are using https TLS/SSL and we have control over every network and system in between A and B we are good.

But what if we don’t know all of the networks hops in between(most likely the case) we can be subject to the infamous Man-in-the-middle eavesdropping on our communication.

“They are not all accounted for, the lost Seeing Stones. We do not know who else may be watching!” -Gandalf the gray

So what do we do?

If we take a look at SSLs cousin S/MIME we can get some insight into a method of better securing our communication with System B.

Take a look at this article it shows how S/MIMEs very nature is more secure than basic TLS/SSL over http.

Can S/MIME be trusted when SSL has had so many security issues?

What’s the difference? S/MIME uses the same Public key infrastructure(PKI) as TLS what’s going on? Simple  S/MIME does not rely on everyone in between to insure its secure communication. This has been predetermined “Out of Band” by its creator ahead of time. Bottom line it is End to End Encryption.

So how do we do it?

For starters we can give server A server B’s public certificate “Out of Band”, this will insure that server B’s certificate has not been altered at the time of encryption.

Lets encrypt the data end to end. We could if we wanted to use S/MIME to encrypt the data. This would be simple, and with help from projects like MimeKit we could do this fairly quickly.  But instead lets reproduce what S/MIME is doing.

First S/MIME is encrypting the data with a symmetric algorithm.
S/MIME by default uses 3DES, but for this I am going to choose AES-256.
Note: The AesCryptoServiceProvider class is used because it is FIPS-140 compliant in windows.
Second S/MIME encrypts the Symmetric key from the first step with the recipients public key. So in our case server B public key. Note: this will be padded to adhere to PKCS#7 Cryptographic Message Syntax

Now we will have all the parts we need to send to server B we just need to put them in to a logical package. (Envelope)

When we serialize this it will produce JSON that looks like this.

Now all we have left to do is send this to Server B.

In the next post we will continue with the decryption of this message by Server B.

Get project file Here