Another point I would like to make is that these requirements can be used in any type of SDLC process, including waterfall, agile, or a hybrid of both. Every process gathers requirements so the ones listed below can be identified as part of any SDLC process. Some requirements may not seem to relate to application security but they all apply to the security triad of confidentiality, integrity, and availability, which are the cornerstones of a secure application.
The following requirements are from the Official (ISC)2 Guide to the CSSLP by Mano Paul. They should be reviewed and documented during the requirements phase of an SDLC.
This requirement protects against disclosure of information to unauthorized persons. Information used by the application has to be protected in transit, during processing, and in storage. Data classification can be used to determine the level of protection information needs. I will discuss data classification in my next post.
This requirement involves protection against unauthorized modification of data in an application, which ensures reliability and accuracy of data. Checksums and input validation are two examples of integrity checks. As mentioned above, data classification helps one decide what information needs to be protected.
This requirement involves determining the periods of time in which the application needs to be accessible by end-users. The Maximum Tolerable Downtime (MTD) is the amount of time that an application can be unavailable before it has a negative effect on the organization. The Recovery Time Objective (RTO) is the amount of time to restore the application after a failure. These two measurements help determine application availability and if the application needs load balancing or redundancy. This requirement may not seem to be related to security but poorly designed software can be susceptible to denial of service attacks.
Validating the user’s identity is an important requirement for confidentiality and integrity. The type of authentication depends on the type of users who will be accessing the application. If the application does not need to know who the users are and does not need to log their activities, anonymous authentication could be used. On the other hand, if authentication may be needed in the future, one should design the application so it could incorporate this functionality.
Once an entity is authenticated, what the entity can access needs to be determined. One must first identify the subjects and objects. Subjects request access, and objects are the things they access. My next post will discuss subject-object modeling which can be used to capture these requirements and help to decide what type of authorization is needed.
This requirement is needed to detect unauthorized access, troubleshoot problems, and gather evidence for forensic investigations. The security analyst and subject matter expert (SME) should discuss what information to log as well as how long to keep the logs. Policy decomposition, which will be discussed in the next post, is used to determine the logging requirements. This requirement also ties into the error-handling requirement that is discussed later.
This requirement is important for defending against session hijacking attempts. When a user authenticates to the site, there has to be a process to maintain the user’s state; otherwise, the user will have to authenticate on each page. Building a secure session process is important to the application’s design even if it does not seem to need it at the beginning. Applications are continually enhanced so someday secure sessions may be needed. Many software vulnerabilities are introduced to applications when they are enhanced since the original design did not account for the added functionality.
Errors and Exception Management
Handling errors properly is important; the application should not provide information to an attacker through verbose error messages. This requirement should also spell out what happens when an error occurs. The user should not be left with a failed application. Logging is important for this requirement because the details of the error need to be maintained for troubleshooting purposes.
Configuration Parameters Management
This requirement helps to capture all the configuration parameters that are needed to deploy the software correctly. Documenting all the parameters helps to make sure that a setting is not missed during deployment. Examples of important parameters are the encryption standards used in the application. Managing parameters properly includes making sure there are no hard-coded passwords.
Sequencing and Timing
This requirement is important since a poorly designed sequencing and timing process in an application can lead to race conditions which enable denial of service attacks as well as impact the availability of the application. Race conditions happen when at least two threads are executing concurrently, the threads are accessing the same object, and at least one of the threads is updating the object. This requirement involves the use of threading in an application to handle race conditions.
This requirement deals with when and how information should be archived. Archiving requirements can be obtained from the SME and from policy decomposition. Policy decomposition identifies the policies that the organization operates under and creates requirements from the policies. I will discuss policy decomposition in my next post. Maintaining archived data can help in forensic investigations and in the availability of the application. Older information maintained in an application may not be needed for day-to-day operations but could be interesting to an attacker. Archived data that is encrypted will need to be identified so that a process can be built if the encryption key or process is changed. If the key is changed, the archive data cannot be read.
This requirement will need to be addressed if the software is being developed for use in a foreign country. There may be legal requirements as well as technical requirements for character encoding and display. If the correct character encoding is not used, the software could have vulnerabilities such as spoofing, overflows, and canonicalization. Even if the software is not currently going to be used in a foreign country, it may be in the future so considerations such as being able to add language packs should be addressed.
This requirement deals with the environment (network, physical infrastructure, etc.) in which the software will be deployed. If the deployment will be in an existing environment, information about the environment must be obtained so that the other requirements can be reviewed to make sure that they are in sync. For example, the application will need to be on load-balanced servers but the current environment is not load balanced.
If the decision is made to purchase software instead of develop, all the other requirements should be included in the contract to make sure the software meets the organization’s needs. Service level agreements (SLA) and contract terms will need to be discussed.
If the application will be sold off-the-shelf, anti-piracy protection requirements should be developed to protect the organization’s intellectual property.
Requirements gathering can be a long process, but missed requirements can create vulnerabilities in the software. For example, missed sequencing and timing requirements can make it easier to attack the software with a denial of service attack. The attack can create enough race conditions to lock up all the database connections. Adding this requirement after the software is developed involves rewriting major parts of the application.
My next post will discuss techniques to elicit information for requirements gathering, and my last post will discuss techniques for designing secure software.