Buyer's Handbook:

Tools for those seeking security for apps in the enterprise

everythingpossible - Fotolia

This article is part of our Essential Guide: How to fight cloud security threats effectively

Security for applications: What tools and principles work?

Better app security requires both designing security in and protecting it from without. Learn how to work it from both angles and what tools you'll need for the job.

There are two ways to improve security for applications: You can design security in using secure programming methods, or you can protect it from without by layering on security measures. Which one should you use? Both. We'll explore why in this buyer's handbook.

What is application security?

According to, "Application security is the use of software, hardware and procedural methods to protect applications from external threats."

If the goal of application security is to create secure applications, then what is a secure application? It's one that is verifiably resistant to threats. And how do we verify that an application is resistant to threats? By testing it.

How does application security work?

Before we discuss the details of application security testing, we should step back and look at the big picture.

Effective security for applications addresses security-related requirements across three primary domains:

  • application development governance
  • application development lifecycle
  • application runtime hosting

Let's take a look at each of these domains.

Application development governance

We begin with the assumption that your organization already has a mature application development methodology and process. If not, your foundation is weak and it will be difficult to build and sustain a successful program. If you need to strengthen your organization's methodology, perhaps the need for better security for applications will help you build a business case for both.

Management must be security-savvy and aware of the significant revenue and reputational risks of increasing cyber threats, and be willing to fund an application security initiative, including staffing, training and tools. If your management is not convinced of the bottom-line value of application security, the effort will falter.

Management must support the plan to embed security practices across the entire software development life cycle (SDLC), from development to testing to production. Many of the existing practices will need to evolve, which can create organizational challenges. Management's authority is needed to overcome cultural inertia and to provide guidance and arbitration when conflicts arise.

Management must hold the organization accountable for creating secure applications. You must establish an auditing protocol so that you can monitor and measure and report the effectiveness of your application security practices, and identify lessons-learned to continuously improve the practice.

Application development lifecycle

As mentioned earlier, you create a secure application by designing security in and protecting it from without. If you begin with a review of the various kinds of tools used to build in the security, you'll see that multiple tools provide a comprehensive approach.

There are two ways to improve application security -- design security in and protect it from without.

The most important tool is human: a security-aware, properly trained, highly skilled and experienced developer. There are three reasons for this.

First, the most effective way to eliminate vulnerabilities is to not introduce them in the first place, and this requires that your developers understand and follow secure coding practices throughout the SDLC.

Second, the tools will discover a mix of highly likely, suspected and potential vulnerabilities of varying criticality, along with some false positives. Different tools find overlapping sets of vulnerabilities. A trained analyst must correlate and evaluate these findings.

Third, no combination of tools will find all vulnerabilities, so you must supplement them with manual code audits, which means having an experienced eye reviewing the code for items that the tools might have missed.

Nonhuman tools abound. Here is a rundown of those you should be aware of and consider, depending on your company's situation:

  • SAST: Static application security testing tools passively analyze an application's source code or binary code for well-known categories of vulnerabilities.
  • DAST: Dynamic application security testing tools assist a human tester with probing and analyzing a running application that is looking for behaviors that indicate potential vulnerabilities.
  • RASP: Runtime application self-protection tools are embedded into a running application so the application can monitor itself to prevent attacks in real time. This is a relatively new category of tools designed to improve security for applications.
  • SCA: Software composition analysis tools help to identify third-party software components that may contain vulnerabilities. Modern applications aren't so much written as they are scripted interactions of heterogeneous components. Vulnerabilities can be introduced all along the software supply chain, and SCA tools help you assess and monitor your component catalogue.

Patching -- fixing vulnerable code -- is also crucial. There is no such thing as a perfectly secure application, and vulnerabilities are inevitable. When new vulnerabilities are discovered, you should proactively remediate them and patch as quickly as possible. Just as cars are intrinsically repairable, your applications should be intrinsically patchable.

Application runtime hosting

You also need to host your application within a secure environment. First, consider application firewalls. There are three types you need to know about: network application firewalls, host application firewalls and web application firewalls. Although they work in different contexts, the basic idea behind each is the same: They examine application communication and data flows, and enforce rules to block many common types of attacks.

Host hardening comes next. First, you must remove unnecessary and insecure services and protocols.

Operating systems like Windows are general purpose. You need to configure them for a specific purpose -- say, a web server or a mail server. Most organizations simplify creating new servers by using a standard template image -- a gold build. However, your IT department's gold build may contain extraneous services and protocols your application does not require. Be careful: Unnecessary services and protocols increase your application's attack surface.

Operating systems are also backwards compatible so that you can run both new and legacy applications. However, legacy services and protocols are likely to be insecure; they, too, will increase your attack surface.

To reduce the attack surface, follow these two important practices:

Use hardened OS images. Good examples are the Center for Internet Security’s hardened images. The center has done the work for you and created pre-hardened images for most OS and application scenarios. Adopt them as the basis for your gold images.

Don't colocate new and legacy applications. Your critical applications deserve a fresh start; don't burden them with the security problems of a legacy platform. Another twist on this idea is to not colocate applications at all -- every application deserves its own specifically tailored and secured environment. Colocating applications leads to unnecessary security compromises. Virtualization or cloud-based hosting can make this approach cost-efficient and practical.

A framework for understanding and achieving application security competence
Figure 1.

Application control or whitelisting tools should be considered. These tools lock down your host by blocking any executable that isn't on the pre-approved whitelist. Not only does this provide excellent malware protection, but it also helps prevent 'platform drift' by preventing unapproved software installations.

Also consider advanced endpoint protection. Traditional, signature-based antivirus is no longer effective; You should look at advanced, next-generation endpoint protection tools that use behavioral and AI-based detection and protection.

In terms of network protections, you need to take steps to mitigate distributed denial-of-service (DDoS) attacks. If you're hosting an online application, then DDoS attacks are a major threat that can shut down your application -- or even your business -- entirely.

DDos protections are complex and require an enormous scalable architecture, so it's best to reach out to established vendors that provide DDoS-resistant hosting environments.

After you've done everything to design security in and protect it from without, it's time to put all your efforts to the ultimate test: a penetration test.

A penetration test -- or pen test -- is an authorized, representative attack on your application, including the network, the hosting platform and the application itself. A thorough pen test will exercise every security measure currently protecting your application; from the 'inside' secure coding practices to the 'outside' hardening measures. When you pass the pen test, you have a verifiably secure application.

It's best to hire a qualified third-party professional penetration testing firm, both because it's a highly specialized skill and because you want an independent evaluation of your security measures.

You can ruthlessly root out vulnerabilities and meticulously harden your platforms, but you can't build an impenetrable force field around your application. To be of any use, your application must interact with the world, and so it will always be exposed to threats. Eventually, someone will slip through your defenses.

You must instrument your environment to detect indicators of compromise. Questions must be asked: Is that a rogue device? A mysterious file? A stolen credential? You must decisively evaluate the situation, and, if it's a real attack, respond quickly to contain and evict the intruder. After that, you must remediate any damage to your application and return it to a fully functional and secure state.

For these efforts, you will need a combination of tools, such as a SIEM and associated incident response tools and services.

What features should you look for?

Tools and services. Most of the larger vendors offer both tools and services, and even offer their tools as services. You should consider the advantages of a services model. Let the vendor manage the tools, and you can concentrate on application security. However, some organizations have significant investments in on-premises SDLC management, so they may prefer integrating the application security tools into their existing environment.

Orchestration. In this context, orchestration is the automated coordination of people, processes, data and workflows across multiple tools. Using heterogeneous tools in your SDLC can be challenging and require manual procedures and checkpoints. Vendors are working on this problem -- ask them about their orchestration plans.

Emerging platforms. Depending on your organization's business strategy, you may need to expand the scope of your application security practice to include mobile, cloud, IoT, big data and even AI. Fortunately, the application security vendors are incorporating these platforms in their suites.

The bottom line

To summarize, the following steps will help you attain security for applications:

Tools alone won't save you. There are foundational prerequisites (e.g., you have an existing, mature SDLC), organizational prerequisites (e.g., your management agrees to fund, support and require application security) and skills prerequisites (e.g., your developers get security training, not just tools training). If you're weak in any of these areas, address them in your application security strategy.

You need a suite of tools. Each type of tool -- SAST, DAST and so on -- identifies certain kinds of vulnerabilities. Although there will be some overlap, you need multiple tools to find the superset of potential vulnerabilities. Then you can correlate and prioritize the findings, and supplement each tool's findings with expert manual code reviews. 

Design security in; protect it from without. You don't want to entrust your meticulously secured application to a vulnerable platform; nor should you expect a carefully hardened platform to save you from your own insecure code. You need security both inside and out.

Leverage your vendors. The application security vendors are subject matter experts, not just tools experts. Consider them an extension of your team. Lean on them to help you build out your overall organizational competency.

When we combine all the major components of a comprehensive application security strategy, we get an application security competency framework, as shown in figure 1 above.

You can use this framework as a guide to develop your own application security strategy. Best of luck as you start your journey!

Next Steps

What is app patching, and what made Apple halt it?

Assess mobile apps to increase corporate security

Why thinking like a hacker helps app security

This was last published in November 2017

Dig Deeper on Application and platform security