5 key principles for a successful application security program

The last few years have been filled with anxiety and the realization that most websites are vulnerable to basic attacks.  We now live in a world where daily reports of massive data loss, denial of service, and even complete ruin of companies are upon us.  Take the example of HB Gary Federal, an organization that was basically eradicated from the corporate landscape thanks to a series of attacks by the hacking group Anonymous.

Slowly, organizations are realizing with dread that their web and mobile applications are houses of straw, instead of houses of brick.

The web provides the ultimate testing ground for ideas. Web applications can be quickly spun up, demonstrated, and evolve over time. As a result, all web sites are under continuous development. New features are continually added, new revenue is being realized - a clear win-win for both consumers and technology organizations.

However, along this race to production, security is often seen as secondary in importance, or absent altogether. The problem stems from developers not understanding the threat landscape, to missing security controls, to non-uniform use of security control - and applications are being compromised on a daily basis as a result.

It’s never a clear decision to invest time and resources in security - traditionally management teams have proffered rationalities such as “we haven’t been hacked yet, why would we invest time and money into securing a non-issue”. Fortunately, this type of thinking is rapidly disappearing from the corporate landscape, as high-profile attacks have demonstrated the power of a few skilled individuals against even the largest companies in the digital area.

With that in mind, let’s go through the five top security best principles during the application development process to ensure your organization is safe from an impending application security meltdown.

1. Application Security Training

Most people assume that web developers have a firm understanding of the most common vulnerabilities that affect web applications. However, this is not the case. Most developers around the world who develop web applications were taught how to make web applications work, but there was little, if any consideration put into making application safe against attacks.

Developers frequently have the assumption that all the security must come from the network side - firewalls, SSL, server patching, et cetera. Only a handful of people in each organization realize that web applications security lies within the code. The code contains the vulnerabilities, and is also the only place the fixes can be applied as well.

Application security developer training is absolutely vital demonstrating the vulnerabilities to developers, but more importantly, showing them which security controls they need in place to have a defensible web application.

Training should come in stages, and be reinforced throughout the year. Start out by giving generalized application security awareness training, followed up by language-specific classes for developers.

In situations where turnover is high, or where development is outsourced, e-learning may be a good alternative. Require that developers go through the standard training; demonstrate evidence of understanding (for example, passing an application security quiz of some kind, demonstrating at least an understanding of the basics of application security).

Keep in mind that developers have a lot on their plates, and don’t expect them to be security experts on top of being development experts. Make the information as concrete as possible by linking the training to their current projects. Stay away from abstract information that will not be absorbed.

2. Common Security Control Libraries

In order to code defensively, security controls must be present for particular operations. You want a standardized, unified front of security controls protecting your digital assets. It’s important to provide guidance to developers on exactly which security controls they should be using.

Developers should be presented with a set of common security controls, and which should be covered in the aforementioned training. Developers should know how to configure and use controls in all environments.

For example, when a developer writes SQL statements from within a web applications, they must ensure that all user input to be used in the SQL statement has been parameterized. Failure to do this results in SQL Injection.

Don't leave it up to the individual programmers how to code defensively. Even among security professionals, there is often disagreement on which security controls have the best balance of security, performance, and flexibility.

Some basic areas that need to be covered include:

  • Authentication
  • Access Control (Authorization)
  • Input Validation
  • Anti-XSS Encoding
  • Secure Database Access
  • Encryption
  • Logging

Selecting security controls appropriate for your enterprise can vary depending on the language selected, and other factors. This is a task best left to an internal security team.

3. Independent Verification of Security During Development

We need to ensure the developers use the security controls in absolutely every place the controls are needed. This is exactly what a code review provides - a second set of eyes looking at the code and making sure things are done properly.

In the past, security code reviews have been done by internal security teams, or by security consultants. However, doing this work manually is usually very costly, time consuming and non-scalable. As a result, many organizations are now using automated tools to quickly assess code for the existence of security controls along every necessary path of execution. And with respect to full disclosure, this is the area I work in: helping to build tools to allow continuous scanning of source code helping developers to find and mitigate vulnerabilities throughout the development process.

In addition to automated code assessments, manual code assessments are also vital. Have internal security teams check out the source code, complimenting automated scans by focusing on areas that are not easily automate-able.

4. Monitor Applications in Production

So much can still work against us once the application is in production. For example, part of the workflow of the application might be outside the scope of the source code we scanned. Imagine an application that talks to a mainframe, or makes use of 3rd party web services, or makes use of internal insecure legacy services.

In addition to that, problems can and do arise across other components that make up the web app. For example, a remote code execution flaw was found earlier this year in PHP, a platform that makes up a large percentage of all applications across the web.

Vulnerabilities can be found in the platform, the server, components, services, stored procedures, libraries, shared resources - basically everywhere. Applications in production should still receive ongoing assessments to identify and mitigate evolving threats.

5. C-Level Attention

So the path to more secure code has taken us from Training, to Standard Security Controls, to Code Reviews (to verify the controls were appropriately used), to dynamic testing (to find evolving threats).

However, all these points can only really happen with the full support and backing of upper management and stakeholders. Budgets, scheduling and teams must all come together to construct an internal security initiative.

The bright side to this is once your internal security program is in place, applications will benefit by having a predictable release cycle (less chance of major surprise security showstoppers right before release). Development teams will also spend less time doing emergency security patches, and more time doing constructive work. Security, therefore, works as an enabler - allowing your organization to focus on innovation and revenue, and have assurance new features won’t be the cause of a damaging security incident.

Security is an enabler, not a roadblock. If implemented properly, reasonable security measures can be implemented without hindering developer's ability to produce functional applications.  Speed is an integral part of the software industry, and any service that’s launched has to be delivered quickly. Ensuring your developers have the necessary training, security controls and verification tools on hand will result in code that more compliant with internal standards, more predictability in production releases, and more secure.

To express your thoughts on Computerworld content, visit Computerworld's Facebook page, LinkedIn page and Twitter stream.
Windows 10 annoyances and solutions
Shop Tech Products at Amazon
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.