Services, practises and tools that should exist in any software development house / department - Part 4 (the security manifesto)

Jun 27, 2011 java english
Share on:

_This part (4) is contributed by a fellow reader of this blog and experienced professional, Dimitri Stergiou ( linkedin, twitter, blog). Dimitris is working as a Information Security Manager and through this post is eager to highlight the importance of designing and building a secure software solution.Security must part of the overall software development lifecycle.

As it was mentioned in [Part2] testing is one of the most important software activities. However, in most of cases, testing is limited to functional requirements and non-functional requirements (such as application security) are largely ignored.

Before we dive into the details, there is an acronym that you need to keep in mind, OWASP (and yes, we will reference it a number of times)

Practise: It is common knowledge, that unless the software product is scrutinized non-stop (e.g.. Adobe, Microsoft), the organization is not putting any “effort” in non-functional requirements (such as security). And in all fairness, why should senior management devote resources (people and money) to address security, when it provides no directly marketable feature, nor any tangible benefit's?

The answer is simple. Security requirements are there to act as an insurance (pay now, prevent bad things from happening), preserve market share ( who wants to use a crappy product?) and provide resilience (especially if your product is used as a service - web based)

Now that we have established that we need security, let’s see how will achieve it. Since the latest trend is Agile Development, here is an example on how you tie security activities with development activities

Since this is not a “be all, end all” post, we will only focus on the security testing (code inspection and dynamic testing)

Before starting the security testing activities, we need to know what we are looking for and how to find it. The best resources on this subject are provided by OWASP in the form of the “ OWASP Top 10 Web Application Security Issues” document and the “ OWASP Testing Guide v3” (v4 is on it's way). These 2 documents will provide the basics on what are the most common (and harmful) web application issues, what are the defences against them and how to identify them in your project

Tools

There are a number of tools available to help with security testing. For code inspection, some of the solutions are:

  1. Peer review: Have development teams read each other’s code. Yes, it is a manual process, but enhances awareness and improves the developers’ ability to produce “better” code. If your programming language is not supported by any of the open source static code analysis tools, and you have no budget for a commercial solution, this is the only way to go

  2. Static code analysis [PDF : Depending on the programming language in use, it is a good idea to use one of the open source static code analysis tools to check your code for common problems (OWASP maintains a list of tools as well). It is not a bulletproof procedure, and it usually generates enough issues to look at, but if you manage to find a code analysis tool that you like and you manage to built custom rules (to adhere to the organization’s coding style) it will definitely catch a lot of the low hanging fruit (empty try / switch blocks, unused variables, etc.)

  3. Commercial static code analysis: As Gartner suggests [PDF, there are 3 major players in this area: IBM (after buying Ounce Labs), HP (after buying Fortify) and Veracode (they didn’t buy anything - not directly at least). Be prepared to pay crazy amount of money, depending on the number of projects, the programming languages used and a number of other parameters which are solely used to complicate the licensing model (or that is my impression). After working with 2 out of these 3 products (IBM/HP) I can say that they are amazing products but in no way they can provide “out of the box” functionality. They require a LOT of configuration in order to provide meaningful results (no one will be happy with a scan producing 19,387 defects) but AFTER you manage to establish the baseline, they will be quite helpful

  4. Static code analysis in the cloud: Fortify also offers a cloud (hosted) solution, if you can’t afford the in-house hosted solution. They have some special offers for open source software, but I have never tried the service, mainly because every company I have worked for was not happy “publishing” their source code in the cloud

By now you should have an idea on how to cover static testing. However, you need to cover dynamic testing as well. Let’s take a look on how to do this

Tools

  1. Manual penetration testing: Although a number of tools are available, when it comes to web application security, no tool can match results from an experienced penetration tester. Penetration testers DO use automated tools for automating tedious, time-consuming tasks, but DO NOT solely rely on the scan results of a scanner. Amongst other reasons, we are VERY FAR away from being able to create a web application scanner that understands and evaluates business logic

  2. Web application scanners: This category includes a number of sub-categories, depending on how the product actually performs it's functions. Some that definitely worth a second look are:

  3. Nikto (written in Perl, one of the oldest kids on the block)

  4. w3af (metasploit approach to web application security)

  5. Arachni (installs as a Ruby gem, nice concept)

  6. skipfish (from Google’s Michael Zalewski)

  7. websecurify (Nice GUI and nice coverage)

  8. sqlmap (for SQL injections)

The 5 products mentioned here are open source, decent communities supporting them and obviously provide the ability to extend the products as you see fit. However, if you have the budget for a commercial solution, here are some interesting ones to try:

  1. Accunetix VWS (one of the oldest companies in the field)

  2. IBM AppScan (ties nicely with IBM’s static code analysis)

  3. Tenable Nessus (although more of an infrastructure scanner)

  4. Rapid7 Nexpose (again, more of an infrastructure scanner)

For a complete list of open source, commercial and cloud solutions, you can go here

  1. MITM proxy: MITM (Man In The Middle) proxies are used by penetration testers to craft of modify requests to / from web applications on the fly. Some of the proxies also contain active reconnaissance capabilities, such as spidering, XSS / SQL injection vulnerability scanning and session manipulation. Some proxy tools to check are:

  2. paros

  3. burp

  4. OWASP’s ZAP

  5. charles

However, expect to be putting in some manual work, since the proxies are a tool to help the penetration (security) tester and not replace him

People, Process, all that Jazz

One thing must be made clear. No matter how many (or few) of the tools an organization implements, it’s the people and the process that will make the difference. Imagine that it has to go something like:

  1. Awareness: Managers, development, everyone needs to be aware of what the goals are and how they will be achieved. Managers need to devote time and money to security testing, developers need to understand how to produce less security bugs (and how to fix old ones) and operations needs to help by deploying infrastructure controls which will help web application security (web application firewalls)

  2. Training: Developers need to understand why the code has security issues, and how to fix them. One of the best weapons in the arsenal of developers is OWASP and specifically the ESAPI (Enterprise Security API) framework. By using ESAPI developers can focus efforts on developing the parts of the software they have their expertise in (business logic) and leave security functions to be implemented by the ESAPI framework

  3. Development: Use open and proven solutions, don’t re-invent the wheel. There is no way that your in-house developed hashing algorithm is better than SHA, nor that your encryption module is faster / better than AES

  4. Testing: Testing for non-functional requirements is a must. End of story!

  5. Lather, rinse, repeat: Whatever you do, remember: it’s a continuous process, you don’t get to do it once and be secure for ever

If you decide that you want to have the process in place, the best way to start is to go through the BSIMM (if your organization is really big) and OpenSAMM (for medium / smaller organizations) and decide which parts of the model you would like to see implemented

Good luck!