|
Ten Aspects of Security to Improve Application Strength
By Chad Cook
Go to page: 1 2 Next
When designing and developing applications, there are a lot of pieces to juggle at the outset, and when the complexities, priorities, and pressures of business are combined, quality application development easily can become something of an unreachable goal. As a final ingredient, the need for security in the application can further darken an already ominous undertaking. The situation is not hopeless, however, and both quality and security can be achieved by approaching applications logically and with a few guidelines driven from experience. This article provides a set of important pieces that can help application developers avoid critical mistakes as they relate to security within applications.
The first part discusses areas of security that relate to all applications where some of the most common mistakes are made:
- Design time
- Layers
- Think like the enemy
The second part focuses on the application of security within the application where more technical weaknesses can be uncovered:
- Authentication
- Access control
- Confidentiality/privacy
- Encryption
- Segregation of data and privileges
- Error handling
- Testing for security
Design Time
One of the largest mistakes application designers can make is to think of security as a bolt-on feature that always can be added at some later point, or upon request. Security affects all aspects of an application and needs to be looked at and considered from all angles, dimensions, and in all areas during design and development. Start thinking about security early when working on the initial ideas for an application. Consider the following questions:
- What kind of data will the application be using and are there requirements for security such as authentication, access control, privacy, networking, and storage?
- What kind of security-specific technologies and components will be needed? Look at the larger picture and where the application fits, including interoperability and standards such as Role Based Access Control, Public Key Cryptography, and SSL/TLS.
- Are there any laws, regulations, and rules that govern the application, how it's used, or how data is handled? These often mandate auditing and logging, transactional components, and reporting.
Security needs to be woven into the application at all stages. To assure that this happens, some basic steps can be followed during the requirements gathering stage of application design:
- Create a section dedicated to security in functional and design documents
- Start with a list of questions and issues that relate to security. For example: "Do we need authentication here?" "What kind of users are expected to use this application?" "How do we want to handle bad input in module X?" "What effect does my application have on other systems and applications with which it interacts?"
- As the functional requirements unfold, many of the questions can be answered. Repeat this cycle for the design phase.
Layers
Security should be thought of in layers. It is very easy to fall into the trap of perimeter-based security—only at the borders, such as the network via a firewall. The network is only one layer where security needs to be present. Any areas of interaction with external applications, users, and systems should also have security designed into them, as should the data handling inside an application.
A truly comprehensive model can be created by applying security to many layers of an application. Here is a model that roughly follows the well-known OSI layers for networking:
- Physical Layer: Consider how controlling physical access to the system can add to or detract from the security of the application.
- Network: Consider the interaction with the network that an application has, including the systems it interacts with, how network access is protected, and where.
- Borders: The edges of the application, including its points of interaction with other applications, APIs, and libraries.
- Presentation: The user interface of the application, such as a command line, a GUI, or Web browser.
- Internal: The internals of the application, where data is consumed, rules are set, exceptions made, and memory manipulated.
Although these layers present a guideline, it is important to consider each application in its appropriate context by identifying the layers that reflect the application and its usage. Some applications will have more, or less, layers, and may differ from one application to the next.
Think Like The Enemy
When arriving at functionality and the corresponding design for an application, the most common mistake is to consider only ideal-world functionality. This is the act of defining functionality of an application exclusively by the best-case scenario of what you want users to do. Invariably, people will make mistakes and do things with an application that it was never meant to do—if the constraints of an application are not defined and handled, the effect can be severe. Other people will attempt to find vulnerabilities in any application by doing exactly that which one would not want them to do. Therefore, one can more easily be proactive during the design phase of an application by pondering the kinds of behavior and actions that are not desired and to implement functionality to prevent them from happening. Each of the aforementioned layers of an application will have well-known types of attacks that can be avoided and protected against.
It is also important to understand the risks surrounding an application. The best way to analyze risk is to put the application in context with its intended use—its relationship to other high- or low-risk applications and systems, and the data that it uses. Does the nature of the application, such as an e-commerce application, naturally make it a more appealing target, due to the plethora of important and sensitive information with which it works? Is the application known to interact with other systems, on which sensitive or critical material is located? Does the application itself constitute a critical piece of an organization's lifeblood? All of these aspects should be considered when evaluating the security of an application. If the application increases an organization's risk with its use, the appropriate attention needs to be given to the security in the application.
Authentication
When creating applications that have some form of user interaction, multiple system interaction, or any dealing with foreign components, it is probable that some form of authentication be used to protect the application. The most prevalent mistakes with authentication are to:
- Have no authentication.
- Define static and hard-coded authentication information.
- Negate the effectiveness of having authentication with poor authentication management.
For example, the most commonly used authentication mechanism is the username and password. Although not the strongest form of authentication, it can be used safely to provide an adequate level of security, depending upon the context. There are, however, several ways to render username and password authentication very insecure:
- Perform authentication in cleartext over the network.
- Store the password in plaintext in a file or database.
- Hard-code credentials into the application.
- Create pre-defined/static special accounts.
Some ways to increase security for username/password authentication:
- Utilize encryption for network-based authentication, such as SSL/TLS.
- When storing passwords, store password hashes if there is no need to recover the plaintext of the original password. If recovery of the original password is desired, use encryption to securely store it (see the following section on encryption).
- Mandate the use of longer passwords and a mixture of characters, including mixed-case alpha-numeric and special characters.
Access Control
The biggest mistake that an application designer can make is to ignore access control as a piece of required functionality. It is rare that every user or system that interacts with an application should have the same rights across that application. Some users may need access to particular pieces of data and not others; some systems should or should not be able to access the application. Access to specific components, functions, or modules within an application should also be controlled. Access control also is important for auditing and regulatory compliance. Some common ways of managing access control are:
- Read, write and execute privileges: A file
- Role-based access control: administrators, users
- Host based access IP address, machine name
- Object-level access control code object, multiple reader/single writer
Confidentiality/Privacy
Many applications use, manipulate, and consume sensitive data. The mistake often made here is to treat all data the same and fail to recognize the sensitive nature of some data types. Common examples of sensitive data includes:
- Personal information about users: Includes names, addresses, phone numbers, ID numbers; Social Security, passport, and license numbers
- Security information: Includes keys, passwords, tokens
- Configuration information for the application
- Financial information (e-commerce related): credit card and account numbers
Sensitive data can be segregated from other data within the application (see below), and the methods used to manipulate the data can be access controlled (above). When developing applications, especially in this day of increasing regulations and rules, it is even more important to research any regulations or procedures that may govern the application or its use. This is especially common in the financial, healthcare, energy, and other critical infrastructures.
Go to page: 1 2 Next
|
IE 7
Firefox 2.0
