Taking a Wider View of Application Security
Feature

Securing an application involves securing much more than just the application itself; the app is only the beginning

As a software developer, you have a lot to worry about when writing and testing your code. But if you faithfully use secure coding guidelines from the Open Web Application Security Project (OWASP), test your code with security tools, and conduct peer code reviews, then your application will be secure, giving you worry-free sleep at night.

Wrong.

OK, sorry about that. I put that trap there for you, but I didn’t really expect you to step into it. I want to help you expand your thinking about application security.

If you are a software developer, being aware of OWASP secure coding principles is absolutely vital and has no margin for error. It is critical that your application be free of the vulnerable areas that are so easily compromised and could lead to the exposure of the entire app environment.

But there is more to application security than just securing your application. Sure, other people may be responsible for the other parts, but it is still important that you know what those other parts are. If your organization is small, the people responsible for the other parts of application security may not be fully aware of their implicit responsibilities.

Securing the Web Server
If you’re a Web application developer, then your application is probably running on a Web server. In a larger and more complex environment, your app may be running on a separate server, but for the sake of illustration, I’ll keep things simple.

The Web server—and by this I mean Web server software, such as Internet Information Services (IIS), Apache, WebLogic or iPlanet—is almost as complex as an operating system. Regardless of which Web server software your organization is using, there are some excellent guidelines for securing them. My favorite is Guidelines on Securing Public Web Servers, published by the U.S. National Institute of Standards and Technology (NIST).1

The topics in this publication include:

    * Planning and managing Web servers
    * Securing the Web server (this includes configuring access controls and server settings)
    * Securing Web content
    * Using authentication and encryption technologies
    * Web server administration (this covers logging, backups, and content management).

Each chapter includes checklists that the Web server administrator can use to make sure that all aspects of the Web server are configured correctly.

Without these safeguards, an intruder will be able to issue commands to the Web server that may enable the intruder to bypass authentication controls, view or alter sensitive information, or completely take over the system that the Web server is running on. All of this can occur even if all of the required steps are taken to secure the application itself.

I want to digress for a moment to discuss NIST publications. Published by the U.S. government, NIST publications have earned the reputation of being high-quality guidelines on dozens of topics in computer and network security. All of the publications are free.2

Securing Business Data
Securing Web server software is still not enough. Besides static content on the Web server, Web applications frequently utilize database management systems (such as Microsoft SQL Server, Oracle, or MySQL) that store business information. These also need to be secured.

The more valuable this business data is, the more important it will be to do the best job possible to protect it.

Database management systems are large, complex programs with a wide variety of configurations and access controls. My favorite guideline for securing databases is the Database Security Technical Implementation Guide (STIG), published by the U.S. Defense Information Systems Agency (DISA).3 This document includes the following topics:

    * Authentication (this includes authentication by administrators, users, and applications that access data)
    * Data integrity
    * Replication and clustering
    * Backup and recovery
    * Security design.

Securing the Operating System
Web servers and database management systems reside on computers with operating systems, which must also be secured.

Your organization’s Web server is running on Windows, Linux, Solaris, AIX, or another operating system. The security of the operating system cannot be taken for granted, especially if the Web server is accessible over the Internet.

By design, operating systems have a lot of features installed, and even activated and running, by default (imagine your house with every door and window unlocked and opened). Although this may be handy for someone who wants to get things up and running as quickly and easily as possible, it’s a headache for security professionals.

There are many excellent publications dedicated to securing operating systems. One of my favorites is NIST 800-123, General Server Security.4

The topics covered in this publication include:

    * Server security planning
    * Patches and upgrades
    * Hardening the operating system (removing or disabling unnecessary services, and properly configuring those services that are necessary)
    * Configuring user authentication
    * Logging (making sure that logging is enabled, and that someone will be responsible for reviewing logs regularly)
    * Backups.

Like many NIST documents, this one contains checklists that help the system administrator systematically review each aspect of the operating system to make sure that everything is done right.

Securing operating systems is not optional. Believe me, intruders will quickly discover and exploit servers that are not completely locked down. Imagine taking your new car to the very worst part of a large city. In no time, thieves and thugs will have stolen the wheels and electronics, smashed the windows, and probably burned the entire car to the ground.

The Internet is no different: Place a server without complete top-to-bottom protection on the Internet, and in a surprisingly short period of time, hackers will move in and completely take over control of the system.

So far, we have a secure application, a secure Web server, protected data, and a secure operating system. Are we done? Almost. The network that the Web server is connected to must also be secure.

Securing the Network
Networks are the pipes that enable systems to communicate with each other. This communication includes administrators who manage systems connected to the network, as well as users who use applications installed on systems connected to the network.

Network security is a really broad topic, so I’ll boil it down to a few principles:

    * The network should be protected with firewalls that permit only the specific types of traffic necessary to access and manage the network itself and the systems connected to it. This is especially important for networks accessible from the Internet.
    * The network should be equipped with an intrusion detection system (IDS) or an intrusion prevention system (IPS) that will alert personnel to attempted intrusions and other security anomalies.
    * Only authorized personnel should have access to tools used to observe communication on the network. Because it is not always practical to encrypt all traffic on a network, an unauthorized person’s ability to capture packets on the network may represent a breach of security.

Protecting the Endpoints
After you have secured the application, Web server, database server, operating systems, and network, you will have done a pretty good job of building a secure infrastructure. (See Fig. 1.) Keeping it secure requires effective processes, including vulnerability management, patch management, and change management—topics for another day.

What I want to talk about here are the endpoints—primarily, user workstations and even the users themselves.

An organization whose applications deal with high-value information (such as online banking) will be targeted by intruders. If they find that the application and its supporting components are well-designed and secure, they won’t give up. Instead, they will attack the endpoints.

For instance, they will design and launch malware (viruses, worms, Trojan horses, and so on) that is designed to capture authentication information (user IDs and passwords), so that intruders may simply log in with user credentials and do their worst.

Intruders will also employ “phishing” techniques, where they create authentic-looking email messages sent to end users (and employees) in an attempt to trick them into logging into a realistic-looking imposter application. Again, the purpose is usually to steal login credentials so that intruders can then just log into those high-value applications to steal money or information.

Steps that need to be taken to stop endpoint attacks include:

    * Antivirus software
    * Automated patch management (this may involve setting Windows Update to automatically install new patches; larger enterprises may use more sophisticated tools)
    * User education (people need to be trained to be aware of unsafe practices that could lead to their login credentials being stolen).

Conclusion
Although your responsibility may be limited to safe coding and secure software development, truly securing an application involves many additional layers of infrastructure, each of which requires its own security techniques. But even an organization that does an excellent job of securing its environment needs to see to its endpoints as well.

If intruders cannot successfully attack the application or its supporting infrastructure, they may recruit insiders to help them steal data or money, or attack the users in order to trick them into providing their login credentials.

Peter Gregory, CISA, CISSP, CRISC, DRCE, CCSK, is the author of 23 books on security and technology, including CISSP Guide to Security Essentials, CISA All In One Exam Guide, IT Disaster Recovery Planning for Dummies,and Solaris Security.Peter is the lead instructor for the Information Systems Security certificate program at the University of Washington. He can be reached at www.peterhgregory.com.

1 csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf

2 csrc.nist.gov/publications/PubsSPs.html

3 iase.disa.mil/stigs/content_pages/database_security.html

4 csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf

Mar2011, Software Magazine