Its more than Healthcare.gov: Lets fix the problem

There has been a lot of buzz around the Healthcare.gov website and the possible security vulnerabilities that it has.  While many people focus on the political side of the story, or just the vulnerabilities themselves, there is a bigger issue here.  An issue that spreads further than just Healthcare.gov or even government sites, but to all sites on the internet.  That issue is the lack of security being a part of the design, development, and testing process of applications.

I will not deny that there is a concern that the public’s data may be at risk in these systems.  However, this is not a new problem.  This is a breakdown in how the software is developed, functionality first, security…  when someone finds the vulnerabilities.  Rather than dwell on the issues that were identified or that could be identified if a proper test was performed, I want to take a look at what can be done to help reduce these risks for the current applications and for the future.

Secure SDLC
The first step to take is to adopt a secure software development life cycle.  Hopefully all developers are aware of the SDLC, but often the “secure” part is left out.   It is imperative that security be thought of before the design process even begins.  We need to be thinking about the types of data that we are going to be handling, who are clients are, and how can we protect that data.   We label this as security, but it really still falls under functionality.  As we design with security in mind, we start to develop with security in mind.  That then leads to testing these security features that we have thought about to ensure that we are following best practices and understanding how and why attackers do what they do.  This all leads to a more secure application and infrastructure.

The Secure SDLC is a pretty expansive topic that includes many sub topics.  Some examples of  the types of activities performed include:

• Static Code Analysis – This helps identify vulnerabilities in the application code early in the development process.
• Dynamic Code Analysis – This helps identify vulnerabilities in a running application.
• Code Review – This helps identify incorrect configuration settings, business logic flaws and other security vulnerabilities.

Security Training
Security training is very important not just for the developers but for everyone involved in the project.  I have worked on many projects where some features are forced in from business, because of a lack of understanding about security.  Obviously, we need business functionality to make the application to work, but when security is considered, there may be a better way of implementation to get both.  All of the people should be getting consistent security training so they understand these concepts to effectively create secure applications.  We must understand how attackers attack and what they are looking for to feel confident in what we are doing to protect our systems.   I wouldn’t build a moat around my castle if I didn’t think someone would try to attack from the ground.

When working with third party development shops, we need to ask the question of what type of security training do they provide to their employees.  While we can provide all the training in house, we have to ensure that the sub-contractors that we use are meeting our required standards.

Regular Testing
Applications and infrastructure need to be tested on a regular basis.  It is great to have an internal team that has the capabilities to do this, but very important to also engage independent vendors.  Often times the independent vendors have more experience with similar applications which can help identify other vulnerabilities.  Independent vendors also usually are not tied to the application so they can have less bias when it comes to what risks they identify.

Bug Bounty
Many companies are taking to the people of the internet to help them find vulnerabilities in their applications.  Instead of hiring full time penetration testers for large salaries, they create programs that allow testers that identify vulnerabilities and report them to the company in a coordinated fashion to get something in return.  That something could be a t-shirt, all the way up to the $100,000 that a researcher received from Microsoft recently for a bug he found.

In the Healthcare.gov situation, most of this site is open source.  It is already possible for people to review the code.  An additional step would be to create a test instance of the website to allow people to perform legal testing, under the specified guidelines, that they could then alert the website creators.  This gets many more eyes looking at the site and can lead to quickly finding many of the flaws that may exist.

Adopt a Maturity Model
Let's face it, security doesn’t happen overnight.  It takes a while to build a lot of these processes into our workflow.  We have to pick where we want to start and build a roadmap of where we want to go.  We need to set goals that are attainable and get us to the security level we want to get to.  Note that even the most mature security models still do not guarantee that there won’t be a breach, but it does help reduce the risk.  There are multiple security models that you can look at.  BSIMM and OpenSAMM are are two of the examples which you can really learn a lot from.

It is important to realize that there are vulnerabilities in just about every site.  Some are obviously more severe than others.  The point I want to make is that we have to start thinking more about how we implement security into these systems as they are being built.  We can find the bugs once it is built, but it is much more difficult to fix at that point and the reputation damage that can be created can be devastating.

James Jardine is ta Principle Consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com, @jardinesoftware on twitter or visit the Secure Ideas – Professionally Evil site for services provided.