Application Security: Methods and Best Practices

Application security is arguably the single biggest challenge confronting security professionals today.

By “application,” I mean any internally-developed build, regardless of whether its primary intended platform is the Web, mobile devices, or a traditional desktop OS like Windows. This is because all application builds must go through the standard cycle of development, testing, settling on a release candidate, and deployment into operations — at which time, too often, problems are found and the new build is sent back for fixes. So application security can often be improved by trying to improve on that cycle, at various points.

Application Security for COTS (commercial-off-the-shelf) applications is inherently more limited, of course, and a topic for another post, though the section “How IT operations teams can improve application security” below is a good place to start.

This perspective has led to DevOps initiatives (a combination of Development and Operations), which try to overcome traditional problems including:

1. IT development and IT operations have often existed in isolation from each other — sharing few/no tools and information, and minimizing collaboration – especially problematic for application security.
2. Both teams are now expected to continuously become more agile: capable of delivering new builds that are as feature-complete and bug-free as possible, yet in a shorter time and for lower costs. Application security is often viewed as an impediment to this goal due to its additional overhead.

A more agile build cycle unfortunately also sometimes means new application security problems. So, toward improving that situation, there are many measures app stakeholders can and should adopt.

How IT development teams can improve application security

First, from a development standpoint, it’s important to integrate application security best practices in coding regardless of the specific methodology (Waterfall, Agile, etc.). After half a century of careful analysis, we now know quite a bit about how programming errors tend to arise, and how best to avoid them.

For instance, consider the SANS list of Top Twenty-Five Most Dangerous Programming Errors. This is a ranked list based on expected business impact, complete with prevention/remediation techniques in every case. Every developer should have it bookmarked — or even better, memorized as their starting point for application security.

There are, additionally, various code vulnerability scanners designed specifically to improve application security at this early stage. I’ve gone into these in another recent blog entry, so won’t be exploring them in detail here, but they can help automatically spot cases in which best practices have not in fact been followed in coding.

How cross-domain DevOps practices can improve application security

Much of the newer insight concerns DevOps per se. As these two domains become more and more tightly integrated, all sorts of great new opportunities arise to drive up application security as a result. Four instances follow:

1. Make sure development, testing, and deployment all have the identical context for the app to execute. By this, I primarily mean the servers involved. At all three stages, applications should have exactly the same operating system version, security patches, middleware, test data, etc. — in short, the complete operational context. Any variation across servers has the practical effect of invalidating test results and production expectations. You can think of this as very similar to a control experiment in science; the idea is to change only one variable, the application build, and see how much better or worse it performs . . . including against application security goals.
2. Take care of reviewing application security connectivity in the development phases. This is so important; it has to be nailed down as early as possible because you really don’t want any chance of such issues emerging in a production build.
3. Update all three environments in perfect sync. As a logical ramification of the first point, any time you change a development, or testing, or production environment, the other two must be updated as well, prior to deploying any new build in any one of them or your application security testing will have gaps.
4. Limit policy control of key security resources (e.g. firewalls) to the security team. Only trained professionals should have the power to affect who can access security technologies in any of the three environments, and with what level of privileges. Don’t cause the operations team to have to open up yet another hole in the firewall because there was no firewall in the development / QA environment for testing the complete application security profile.

How IT operations teams can improve application security

Finally, we come to the operations side — where builds will live and breathe in production servers, creating business value in real time.

This is a complex area, but I would say that any shortlist of best operations application security practices these days should include:

1. Set standard policies that incorporate multiple solutions, then federate policy management as much as possible. Ideally, one would be able to update policy, or create new policies, for security in a holistic sense from a central point of command, rather than using a dozen different interfaces.
2. Scan for possible breaches using best available tools. Example: top-tier intrusion detection (IDS), prevention (IPS) or next generation firewalls (NGFWs) that include such functionality.
3. Ensure that system configuration is up to spec and fully patched everywhere throughout the architecture. But see also point 3 from the DevOps list — updating production servers means updating test and dev servers too!
4. Lock down endpoints using best available solutions and strategies. Security for a desktop running Windows is fundamentally unlike security for a phone running iOS which is fundamentally different from locking down a Linux-based database server. Whatever endpoint strategy is chosen will have to address all endpoint types used throughout the organization, to whatever extent security is technically possible on that endpoint. (Some endpoint solutions offer universal agents to address this issue.) Application security is only as good as the security of the endpoints it is running on.
5. Deploy anti-malware and authentication/validation solutions.
6. Encrypt network traffic in proportion to business priorities, bearing in mind the reduced performance that will occur as a result. Today, these performance tradeoffs are minimal and ensure application security throughout the entire transaction.

Where is application security headed?

We live at an interesting time, when the very definition of applications is rapidly changing — consider all the apps recently introduced for mobile devices, Web apps, plus composite apps! So are the diversity and complexity of the environments in which they operate.

The key to application security therefore appears to be handling all this complexity through a unified approach. More and more, I’m seeing devices like NGFWs include a broad feature set. I’m also seeing “security fabrics” developed that allow third-party offerings to integrate in newer, better ways. This means that — hopefully at least — security professionals should be able in future to manage security more from a holistic standpoint, and less in different domains, via different solutions and processes.