One of the very first steps when confronted with an application security review, is to build and draft up security requirements. This is the basis upon which the rest of the security review will hinge upon. This step, when done properly, will better inform your efforts to threat model an application.
What are Application Security Requirements?
Security requirements are a baseline checklist of security issue types to check an application for. When faced with a complex task like an application security review, it is very beneficial to break up the review into multiple parts. Like how an artist needs to begin their drawing, painting, or sculpture by laying out their subject in basic shapes and large swaths of color, so must the application security review be generally categorized to give it a general shape. Your first step should be a general analysis of the application based on it's goals and it's design. This will help give you a general direction for the rest of the security review.
Otherwise without this step, if you just go straight into threat modeling an application, you will need to check every application for every possible security issue and you will generally waste your time or get too lost. Building security requirements is a step you also tend to do once you become more experienced, even if you don’t realize it. Not all applications are vulnerable to all possible security issues, so it makes sense to take some time whittling away what is not necessary.
Take an example of creating a sculpture. The application security review is a blob of clay or hunk of stone and you need to turn it into a cohesive and recognizable subject. Your first job is to whittle away the material you don’t need, creating a general shape of the subject. In the security review, you whittle away security issues that are not relevant to this application. If the application does not interact with a SQL database, there’s no real reason to evaluate the application for SQL injection issues. If the application doesn’t vend an API or have a mobile component, there’s no point in checking it for API or mobile issues. The final product of that analysis are Application Security Requirements.
Application Design and Architecture Documentation
Before you can even begin this process, it is necessary that you sit down with the project owners and have a kickoff meeting. This meeting will help you and the developers lay out the groundwork of the rest of the security review and is your starting point to building your Application Security Requirements.
Here are some of the questions that need to be asked when you go to sit down with the developers and review their documentation:
Objectives: What is the goal of this project? Why is it needed? This is a question not asked enough by security people; up front we should be asking why we even need this project. As claims in life require evidence to back it up, you should ask, what is the business requirement we are fulfilling with this project? Is the risk worth it and could it be accomplished another way?
Context within your ecosystem: Where will the application live in the environment? The project owners should be able to list the upstream, intermediate, and downstream services that the application interacts with.
Technologies Utilized: What technologies are being used to support this project? This includes external technology, open source libraries, and internally developed code or tools. The developers should be able to list their entire project stack.
Data types handled: The project owners should be able to list all of the data elements that are being used and what their criticality is. The higher the criticality of the data we are handling, the more stringent and detailed the overall review will be. This step is heavily based on corporate security policies, but in general data can be split into four categories: Public, Internal, Confidential (Restricted to certain internal groups), Highly Confidential (Named internal people only), and Critical (Personally Identifiable Information, payment data, business critical data)
Actors using the application: Project owners should be able to give a detailed list of both internal and external human actors, as well as internal and external services interacting with the application. This is including but not limited to: Customer users, Back-end admin users, External services, and Internal services
Application components: The application should be broken down into describable chunks that list out how they perform their purposes.
Authentication: How do external actors authenticate to this application? And how does this application authenticate to other entities? Refer back to the previous section and ask this question of each listed actor.
Access Control: How does the application control access for the various actors of this application. Again, refer back to the Actors section and find out how the application plans to control who can perform what actions across the application.
Credentials Management: How does the application handle credentials for authentication to other systems or services? How does the application handle credentials for external actors? The project owners should know what credentials are necessary but also where they are stored, how often they are rotated, and how are they rotated.
Database Security: What databases does the application use and how are they secured? Project owners should know what databases they are accessing, how they access them, how they handle database credentials, and what read and write permissions they have.
Log Management: The project owners should know what data is being logged, how long the logs are kept for, how are they accessed, and what the highest classification of data is going into logs.
Input Validation Strategy: For each component of the application, how does the application sanitize un-trusted input and encode it’s output as necessary? This is highly tied into the threat modeling step when we begin to drill down further.
This is also a great time to ask clarifying questions to the development team if you require additional information or if they accidentally left something out. This conversation will also reinforce certain topics with the development staff that they may have forgotten or are unsure of, so allow them to ask clarifying questions to you as well! The more development and application security work hand-in-hand to understand, and respect each other, the better.
Diagrams
I’m a huge fan of diagrams. I’m a highly visual person and I find having a visual representation to breakdown the application is extremely useful. Development teams should have at least one person on the team that not only fully understands the project in question, but also be able to accurately diagram the application out using basic diagramming software. For me, there are three basic types of application diagrams for security reviews:
UML diagrams: A set standard for diagramming complex systems, UML (Unified Modeling Language) can give you a high level view of an application. Some examples include Class Diagrams which lay out the relationship of an OO (Object Oriented) application design or Component Diagrams which lays out the components of an app and their relationships with each other. Generally all diagrams should be a UML diagram, but the next two are my favorite.
Data Flow Diagrams (DFD): Probably the most common diagram for mapping out an application and architecture. Components on the DFD are laid out in various shapes equated to a type of technology, with lines connecting each other with their relationships and what data traverses these relationships. You can also easily diagram trust boundaries here to show where untrusted data is entering a trusted component.
Sequence Diagrams: A Sequence Diagram lays out all of the components and actors horizontally with descending lines that show relationships of components from initialization to completion of the application or component. I’ve found sequence diagrams are extremely useful for helping bring in another layer of understanding to a security review, and understanding an application is key to a successful security review.
Determine Application Review Criticality
Once you gather all of the relevant information about the application, it’s time to classify the application review for it’s criticality. The criticality rating of the application will determine the breadth and depth of the review that’s required. Many factors contribute to the criticality rating of a review, but the most important is considering the data handled. Again, the project owners should know exactly what data elements their application is supposed to be handling. Example data types include PII (full names, emails, phone numbers, addresses, etc.), payment data, employee data, company data, or proprietary company data. Your organization should have these data elements and their respective criticality ratings laid out in policy documentation to make it easy to understand.
Other things to think about when giving an application a criticality rating:
Does the application impact human safety?
Does the application handle secrets or credentials to other applications?
Does the application require access to other critical applications or services?
Does the application need to live in mission critical section of the network to operate?
What Application Security Requirements are there?
There are numerous, but here is a general list:
Architecture, Design, and Threat Modeling: This is the most meta part of the security requirements, because these are the security requirements that affect the rest of the security requirements. Thus why they are first on the list.
Authentication: How does the application determine who a user is before they are allowed to perform authenticated actions?
Session Management: How does the application maintain the user’s authenticated state from action-to-action?
Access Control: How does the application determine what kind of actions the user is allowed to perform?
Validation, Sanitization, and Encoding: Ensure the validation of data from untrusted sources and how the application handles encoding of data for its destination.
Stored Cryptography: How does the application and it’s architecture handle encrypted data and it’s keys?
Error Handling and Logging: How does the application handle error conditions and repudiation efforts from logging?
Data Protection: How does the application handle sensitive data on the device or systems it is executed on?
Communications: How does the application and it’s architecture handle encrypted communications?
Malicious Code: How is the code base and dependencies protected from malicious code being merged into it?
Business Logic: Ensure that business requirements the application must adhere to do not have work-around's or have ways to be abused.
File and Resources: Ensure that the application securely handles inputted, un-trusted file data.
API and Web Service: Ensure application APIs adhere to all of the other security requirements.
Configuration: Ensure everything else about the application is also secure, including the build pipeline, application environment hardening, dependency and configuration management, secure defaults, and patching processes.
OWASP Application Security Verification Standard
The above list looks pretty complete and impressive, but I cannot take credit for it. This list comes from the OWASP Application Security Verification Standard (ASVS). It outlines the entire list above and breaks each down into subcategories to check the application against. It gets quite detailed and it is a great barometer to check for each and every application security review.
The ASVS also breaks down each security verification standard item into three verification levels: L1, L2, and L3. Each verification level defines the depth of the review, the higher the level the more security requirements. Use this as a guide based on the criticality of the review, using a higher verification level for higher criticality of security review.
I won’t get too much deeper into the above list as the ASVS does that easily for you, but that’s not really necessary when you’re building your Application Security Requirements. During this phase I am mostly paying attention to the first layer of verification requirements, then drilling down further when I’m ready to threat model the application.
Finalize your Security Requirements
From this point on it’s fairly simple to apply initial security requirements to application architecture documentation and diagrams. As soon as anything is brought up from the developers or from their documentation regarding anything from the OWASP ASVS, that requirement applies to this security review.
For example, if the documentation begins to describe how users authenticate to the application, or if the application needs to authenticate to another service, then the checks from Authentication Verification Requirements apply to this review. However, if this application only has a single user permission level or doesn’t vend an API of its own, then you won’t need to pay much attention to Access Control Verification Requirements or API and Web Service Verification Requirements. This is a huge time saver for you when you begin to threat model the application, and having it in a checklist format makes your security reviews consistent.
When you have your security requirements list ready, what now? Well first you should communicate this information back to the development team or project owners so they are generally aware of what items will be of concern with the application. Then you are ready to apply this information to your threat model.
Be sure to check back on the Hella Secure blog in the future where we will cover more details about threat modeling.
Links
OWASP Application Security Verification Standard: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project I discovered the OWASP ASVS many years ago and it is a game changer. Like any good standards checklist, it allows you to be thorough with your security reviews while still saving time. OWASP Cheat Sheets: https://cheatsheetseries.owasp.org/ While I should’ve brought this up in my previous article about getting into Application Security, this is still a very handy explanation of application security issues from OWASP. UML Diagrams: https://tallyfy.com/uml-diagram/#use-case-diagram This handy link lists out and describes each type of UML diagram with examples. Very helpful! AWS Data Classification Guide: https://d1.awsstatic.com/whitepapers/compliance/AWS_Data_Classification.pdf This PDF from AWS lays out some of the groundwork for creating a Data Classification guideline or policy document for your organization. This is necessary for every company handling any kind of private or internal data.
About the Author
Aaron is an Application Security Engineer with over 10 years of experience. His unorthodox career path has led to many unique insights in the security industry.