Use Case - Threat Modeling SaaS Applications

Introduction

The following process and information serves as a foundation and defense for threat modeling SaaS applications. It is designed to encourage conversations in organizations that leverage SaaS applications in their daily operations. It is certainly not meant to be the last word in how to threat model applications of this type.

Questions

Do SaaS applications need to be threat modeled?

Absolutely! Many SaaS applications follow a Shared Responsibility model where the vendor is responsible for “Security of the Cloud” whereas the customer is responsible for “Security in the Cloud”. This security in the cloud includes many items that if left unchecked or ignored can result in severe data or service disruptions.

Who needs to threat model SaaS applications?

You do! If you are asking the question, you should probably be involved in the threat modeling process. Ideally, this should include a cross functional team of administrators, governance and risk management professionals, security analysts, and other involved stakeholders.

What items are in-scope for our Threat Model?

Setting scope is one of the most important aspects of threat modeling. Without a well defined scope, a threat modeler may be consumed by analysis paralysis as additional variables and objects continuously expand the size and complexity of the model.

Should scope be just limited to the “Security in the Cloud” items?

NO. Security in the cloud is certainly the most important item to be threat modeled because you can be 100% certain that the vendor is not going to be doing those items for you. Additional items that might be considered in-scope as a P2 item might include: vendor access to your SaaS data, data usage, data retention, backups, residency, etc. All of these variables should certainly be considered since they might play a huge role in potential “What can go wrong?” scenarios.

Proposed Process

Keeping this process as simple as possible, we will start with a review of the four questions¹ against the SaaS application to determine our preliminary threat model.

What are we working on?

Define the application, gather information about what type(s) of information is stored and transmitted with this application. Any vendor security due diligence information that was collected during the sales cycle or proof of value should be collected and reviewed. Grab a whiteboard, some diagramming software, or threat modeling application and diagram how the end user (our organization) interacts with this data. This should include all the approved and non-approved methods for interacting with this data.

Reviewing security due diligence documentation should inform the security team where the shared responsibility is defined for the SaaS vendor and for our organization. For example, the vendor does not have MFA by default so this will need to be enforced by our identity provider or the vendor does not meet our log collection requirements so additional log forwarding will be required with some type of storage in the cloud or on-premise. Any noticeable gaps should be documented, communicated to risk management personnel, and have a plan for remediation.

Checklist:

Team has reviewed all security due diligence documentation.
Document the types of assets that this vendor will be storing, transmitting, or processing on our organization’s behalf (assets).
Document how those assets will be exchanged with the SaaS vendor (data flows).
Document how users will authenticate with the SaaS vendor.
Document how access is appropriately provisioned.
Review expected Complementary User Entity Controls which demonstrate the expected controls to implement as a customer.
Document SaaS environment hosting provider and data residency.
Define which parts of this SaaS application will be in-scope for your threat model. It might be helpful to define P1 scope (items we are absolutely in control of) and P2 scope (items at the SaaS vendor, we might be able to influence). Document which items are specifically out-of-scope as well.
Document any connected applications. Specify type of connections as well.
Document how users will interact with this SaaS application (API, Web UI, Mobile Application) and the environment for accessing (BYOD, company network).
Document data transfer requirements between SaaS environment and local environment.

What can go wrong?

Easily the most enjoyable part of threat modeling is reviewing all of the possible cyber events or threats. Regardless of how each organization assesses and triages threats for applicability, this step should include personnel from across the organization to ensure that all possible threats are considered, evaluated, and recorded. Remember, this is not a problem solving (threat remediation) session, this is a threat recording and identification session.

If the SaaS vendor provides a list of Complementary User Entity Controls, then this is an excellent place to start with the threat identification.

For example:

Complementary User Entity Controls	What can go wrong?
Customer will be responsible for establishing policies and procedures related to information security.	If security policies are not set properly, an insider threat (authenticated user) may be able to exfiltrate organization/customer data.
Customer will establish logical access controls related to user provisioning, role-based access, user de-provisioning, and user access reviews.	If access control policies are not set properly, an authenticated user may have access to data outside of their role. If access control policies are not set properly, an authenticated user may be able to delete files accidentally.
Customer will be responsible for establishing robust authentication protocols.	If authentication protocols are not set up correctly, threat actors may be able to brute force authentication mechanisms. If authentication protocols do not require multi factor authentication, compromised passwords may be used by threat actors to access company resources.
Customer will be responsible for timely termination of user accounts.	If user accounts are not terminated in a timely fashion, former employees may be able to access company data following termination.
Customer will be responsible for providing and updating an approved point of contact for vendor interaction.	If contact lists are not provided, a threat actor may use social engineering to gain access to your SaaS environment.
Customer will be responsible for change management processes within an application.	If change management procedures are not set, followed, and communicated to all individuals, changes to the environment may cause service disruption to internal parties, disrupting business operations.
Customer will be responsible for configuring data storage, archival, and retention requirements within the SaaS product.	If data storage requirements are not set properly, data may be improperly removed once a set capacity is met. If archival and retention policies are not set correctly, important regulatory data may not be available during upcoming audits or compliance revi

This list from the vendor provides the minimum standard for threat modeling a SaaS application. Consider the answers from some of the checklist questions and the potential security risks if those items are not configured correctly or configured at all.

If it is difficult to determine types of attacks or vulnerabilities, it may be useful to review CAPEC² or MITRE ATT&CK³ libraries to determine potential tactics, techniques, or sub techniques. MITRE ATT&CK has a specific matrix which details techniques used against SaaS systems.

Threats must be prioritized in this step to ensure that teams understand which order (or priority) threats should be addressed in the following steps. Factors that should be considered when determining the priority might include the following: types of assets being processed, transmitted, or stored by this application, impact of exposure to those assets, likelihood of threat realization, skill level of threat actor, etc.

Checklist:

Review the answers to the question in the first section and continue to pursue how threat actors may exploit those items.
Review the documentation and segment items into in-scope (P1 and P2) and out-of-scope (items which we cannot control).
Tie in-scope items to specific functions or data flows within the diagram. Depending on the specific nature of the threats, the diagram may need to be structured as a data flow diagram, process flow diagram, attack tree, or mental map.
Determine the potential impact to the organization for each possible threat when realized on assets (confidentiality - high, integrity - low, availability - high).
Document threats, techniques, and sub techniques that may be leveraged against items in the P1, P2 regions first. Threats which might be realized against the out-of-scope region should be identified and communicated to the SaaS vendor.
Document the likelihood that each possible threat may be realized.
Document the complexity of the attack (threat actor skill) required for each threat.
Document a process for scanning for new and emerging threats impacting this application or set of systems. When will this threat model be reviewed again?

What are we going to do about it?

And finally to the problem solving portion of the threat modeling process. In this phase, we will review the different threats according to the priorities established in the previous step to determine how, when, and who will address those items. Prioritizing different threats should follow a consistent process so that the highest priority threats are composed of high impact, high likelihood threats.

As different controls or countermeasures are reviewed against the threats list, users should consider capturing the cost to implement as an additional factor when determining the final prioritization for implementing controls.

Checklist:

Organize the threats into prioritized groupings.
Organize threats into groups (using priority groupings) that have common themes or might have common countermeasures.
Work through threats with a team and assign countermeasures. Assign compensating controls if mitigating countermeasures cannot be applied.

Did we do a good job?

The final step in this 4 question process is determining if this process has been effective. Establishing effectiveness for threat modeling will likely require input from external stakeholders. Examples of key performance indicators for modeling SaaS applications might include:

Quantity of threat modeled SaaS applications vs. total quantity of SaaS applications.
Quantity of required unimplemented controls/countermeasures.
Quantity of non-addressable threats in SaaS applications.
Quantity of controls/countermeasures to be implemented per established time period.

Checklist:

Document total quantity of SaaS applications.
Document total quantity of SaaS applications that have been threat models.
Document quantity of controls that are P1/P2 and which cannot be addressed.
Document plan for remediation of P1 controls with established timelines and responsible parties.
Periodic update of implemented P1/P2 controls.
Documentation of discussion of P2 controls with SaaS vendors.

Conclusion

Threat modeling SaaS applications will look different for every organization but this process should reflect the level of control the organization has over the security of the tenant, and the overall security risk and impact of potential data exposure with this hosted application.

This recommended process should not be the final word on threat modeling in the software as a service space. The expectation is that this document serves to create new discussions around threat modeling shared responsibility applications and systems.

References:

¹ Shostack, Adam. Threat Modeling: Designing For Security. John Wiley & Sons, 2014.

² www.capec.mitre.org/index.html

³ www.attack.mitre.org/matrices/enterprise/cloud/saas/

‍