Data classification is an exercise that organizes data based on its level of sensitivity. It may be easy to encrypt all application data but that may not be cost effective. Additionally, encrypting all data provides more cipher text than just encrypting select data; an attacker may be able to use the extra cipher text to determine the key. Instead, data should be classified based on confidentiality, integrity, and availability and then encrypted when necessary. For example, if data is publicly disclosed, it should be classified as public and should not be encrypted. NIST Special Publication 800-18 contains a data classification framework that can be used to classify data by the objectives of confidentiality, integrity, and availability. The following diagram from the Official (ISC)2 Guide to the CSSLP by Mano Paul illustrates the data classification process.
Use and Misuse Case Modeling
This technique diagrams the normal and abnormal behavior of an application. A use case model illustrates the sequence of events for a component of the application. The models help to clarify requirements for the application and identify the actors involved in each process.
Misuse cases are use cases that model abnormal behavior. For example, a misuse case model can show what happens when a database is down or when a user does not have access to the database. Many security requirements can be derived from use case and misuse case models.
Use cases can help you determine authentication requirements and authorization rules. By illustrating which actors access the same data at the same time, a use case can provide you sequence and timing requirements. This information can help to define which groups of data should be updated as a transaction to avoid a race condition. If a misuse case shows that a certain type of actor does not have access, that can be captured for access control information. Error and exception management requirements can also be derived from misuse cases. For example, you may decide you need a centralized error handling process based on the number and type of errors the application will generate.
The subject-object matrix is created from the use cases. The subjects and objects are populated in a table, the subjects or roles listed across the top and the objects down the side. The intersection of the subjects and objects show whether the subject is allowed to access the object. The matrix can be used to create misuse cases. If a subject should not access an object, a misuse case can be created to identify the scenario to deal with an access attempt. The scenario could involve just a denial of access or a denial and logging. The availability requirement comes into play on this misuse case since the denial of access could help perpetuate a denial of service attack. The subject-object matrix and use case modeling can be used in threat modeling; this will be discussed in my next post on secure design.
An example of a subject-object matrix is displayed below. A CSP can read and write a customer object but cannot access a vendor or inventory object. In addition, a buyer subject can read and write a vendor object but not write an inventory object (the inventory clerk will create that object). Instead of simple read and write access, the matrix can also be created using CRUD (Create-Read-Update-Delete) access to define the relationships at a more detailed level.
After these and any other requirement gathering processes that may be part of your SDLC are completed, a Requirements Traceability Matrix (RTM) is created. The RTM is a table that lists all the business requirements in one column and all the functional and testing requirements in other columns. Security requirements should have their own column so they are not missed in the design phase. This also helps to illustrate how security requirements relate to business requirements, reinforcing how important security requirements are to the success of the application.
An example of an RTM is shown below. As you can see, one of the business requirements does not have a security requirement. This business requirement calls for database passwords to be hashed. If no security requirement states how the hashing should be performed, the developers could choose a hashing algorithm like MD5, which is considered to be cryptographically broken by the U.S. Computer Emergency Response Team (CERT) of the Department of Homeland Security. Having a security requirement that states how the passwords should be hashed will make sure that a potential vulnerability is not built into the application.
More information on these techniques can be found in the Official (ISC)2 Guide to the CSSLP by Mano Paul which is a great resource for information on a secure development lifecycle as well as a good source to use for preparing to take the Certified Secure Software Lifecycle Professional (CSSLP) credential.
My final post in this series will discuss secure software design with a high-level look at the considerations in this phase of the SDLC.