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.
Encryption
As with most security technologies, it is easy to render the security strength ineffective if used improperly. Encryption is an important component in most security architectures, but there are some complexities involved with its use. The following pieces need to be considered when using encryption:
- The type of algorithm: symmetric or asymmetric
- The generation of keys and keying material
- The management of keys and keying material
- The application's performance requirements
There are two types of encryption algorithms: asymmetric and symmetric. Asymmetric algorithms have separate keys for encryption and decryption, use longer key lengths, have slower performance, and have easier key distribution with somewhat difficult key management. Symmetric algorithms use a single key for encryption and decryption, typically have smaller key lengths, higher performance, and more complex key distribution with simpler key management. Choosing a type and algorithm is often done automatically depending on the technologies used. Unless implementing a new or proprietary protocol, the use of encryption is generally governed by an existing standard.
When using encryption, there are several pieces of information that affect its strength. This includes how the keys are generated and the sources of data used to start key generation. Initialization vectors used to seed keying material or encryption operations often rely on sources of randomness and entropy. What these sources are and how truly random they are can result in weaker keys and encryption that allows attackers to compromise the data. Often, the most reliable sources of randomness are hardware and many systems have built-in pseudo-random number generators (PRNG).
Once keys are generated, the next challenge is their management, which includes storage, distribution, revocation, and updates. The problem of key storage is fairly obvious, with the plethora of smart cards, USB tokens, and dongles readily available. Because the key used for decryption must be stored safely, the use of encryption can become useless if private keys are stored on globally accessible media, such as on a hard drive. The fun does not stop there, however. For symmetric encryption, where a single key is used for both encryption and decryption, that key must somehow be communicated to the parties that want to encrypt data. It is obviously not ideal to simply transmit the key via some common way (e-mail, a file, Instant Messaging, and so forth), because it can be compromised easily. For this reason, several schemes are used to exchange keys, including Diffie-Hellman key exchange, the use of Public Key cryptography to exchange keys, and other algorithms that allow for mutual calculation of keys. Finally, the management of keys can become tricky, especially for keys that are compromised or expire when used on data that persists for long periods of time. If keys are lost, stolen, or expired, new keys must be generated and the data that may have been encrypted with the old keys must then be decrypted and re-encrypted using the new keys.
Finally, the performance requirements of the application can affect which encryption technologies are used. Public key algorithms are computationally expensive and will result in dramatic decreases in performance and throughput. Symmetric ciphers have a higher degree of performance. A balance of the two can often be used—SSL/TLS is a perfect example. SSL/TLS most commonly runs in a mode that utilizes both public key and shared key encryption algorithms. The public key algorithm is used to exchange the shared key in a safe manner, and this shared key then is used for all of the bulk encryption operations that follow the session. It is also important to note that different algorithms perform differently.
If performance is a factor for applications, the careful selection of encryption types and algorithms allows the application to meet performance requirements. Alternately, there are hardware components available to offload and increase performance of various encryption operations. These components come in many form factors and can be utilized by the application software.
Segregation of Data and Privileges
In conjunction with access control (above), how data is organized within the application can add or detract from its security. This flaw manifests itself when the application has no central mechanism for accessing sensitive data and when the management of sensitive data is distributed across many components and modules within the application. This distribution of sensitive data makes access control very difficult. It also allows for multiple points of vulnerability—each module or component that manages sensitive data becomes a potential target.
Applications that work with sensitive information can improve security by segregating access and management of that data to a protected module. This module can implement granular access controls and auditing functionality to assure access is granted only to those components that need it. Centralizing access to sensitive data also allows the application designer to more cleanly and logically organize functionality that may otherwise end up unmanageable when it is distributed across too many components.
The second aspect to isolation and segregation within applications concerns privilege. Most systems have some notion of privilege levels, especially when doing development on Windows and UNIX platforms—and many operations require elevated privileges to execute. Common mistakes in this area are:
- Running the application in an elevated privilege level at all times (as the "root" user on UNIX or as one of the administrative accounts on Windows).
- Failure to determine which actions truly require elevated privileges. Most operations within an application can be done without the need for elevated privileges.
One solution often used today is the separation of privileged actions. There are a few ways to accomplish this:
- If possible, isolate privileged operations to initialization time to start with elevated privileges; then drop them once they are complete.
- If elevated privileges are required at various points during the normal operation of an application, the privileged operations should be isolated from the non-privileged operations. Separate threads or processes then can be used to isolate and execute operations. Combined with the appropriate authentication and access control (above), privileged operations can be implemented and managed safely.
In short, it is vital to limit privileged functionality to a minimum and to keep sensitive data managed. Designing applications with this in mind can reduce the potential vulnerability and allow for better auditing within the application to determine when a problem has occurred.
Error Handling
Error handling is both an engineering and security challenge; how an application behaves individually and in conjunction with other applications can result in stronger or weaker security. An application that has defined constraints and safely handles error conditions can mean the difference between a resilient environment and one that crashes completely.
Error handling is an aspect of application design that is often forgotten or ignored. If a framework for handling errors is not designed, an application may end up with a different scheme for each developer who works on the project. Components of error handling can include:
- Definition of error types: processing, runtime, security violations, program bugs/assertions.
- Definition of severity levels: informational, warnings, catastrophic issues.
- Logging and auditing: centralized auditing with modular logging components such as file, e-mail, and cell phone.
- Defined responses to error types and levels: issue a warning, stop a component, restart a service, shut down the application, notify an administrator.
The design of an application's error handling capabilities is further strengthened when the functional requirements include negative scenarios; see the section on thinking like the enemy, above. Providing a framework for error handling creates more predictable and easily used applications. It resolves any difficulties that arise from individual developer styles and forces the designer to outline the constraints and limits within the application. A framework for error handling also provides greater clarity and understanding when anomalies do occur.
Testing for Security
One final aspect that people often fail to recognize is the importance of testing as it relates to security. Three components of testing for security are:
- Functional verification
- Constraint evaluation
- Border cases and attacks
Functional verification is the most prevalent form of testing and is most often what is meant when people refer to testing applications. Just as one creates tests for their functional requirements, it is equally important to devise tests for those requirements established for undesired behavior and error conditions—the constraints and limits of the application. Each of the conditions and responses defined for the behavior of the application should be rung out and verified.
Border tests can be thought of in the following manner:
- Testing interfaces to the application: APIs, network, and user—the physical borders.
- Testing the borders of data processing: Multiple combinations of imperfect data that will be processed by the application. These can include valid ranges of data values, unexpected types, and randomly generated data.
There are a number of tools available to test an application's security. These include code analyzers, modeling tools, and stress testing tools such as fuzzers, which help identify many software vulnerabilities and coding issues.
The combination of testing that includes defined functionality and constraint evaluation, as well as stress testing that pushes the limits and boundaries of an application, help improve the security before it becomes deployed in critical environments.
Summary
Security in and of an application does not have to be an overwhelming task. By considering the security aspects of an application at all stages, as early as basic functional requirements, one can weave security into all areas of the application; doing so results in a cumulative and strong level of security strength, resiliency, and quality. Effort spent during the design phases looking at the various layers of the application and how one hopes people will and will not use the application sets the foundation for functionality that both meets the needs of users and withstands all anomalies that occur.
Proper application of security technologies such as authentication, access control, and encryption can assure a higher degree of safety in untrustworthy environments. An understanding of worst-case scenario events, handling errors, and compartmentalizing sensitive data and operations within the application can solidify the strength of an application. Finally, taking some time to test and verify constraints, functionality, and security will assure a level of confidence with the developers and users alike. Keep security in mind to create useful—and safe—applications.
4346
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
