Attack Surface Management for the Adoption of SaaS

By Alfredo Hickman
1892

By Alfredo Hickman, head of information security, Obsidian Security

Earlier this year, I had the opportunity to speak before a group of CISOs about the topic of attack surface management (ASM). While much of the conversation centered around managing the attack surface around on-premise environments and cloud infrastructure, it was interesting to me that not much was said about SaaS. Naturally, that’s where I drove the conversation. Most organizations that use cloud services deal with a small number of cloud infrastructure providers and typically from one or two of the big three: AWS, Azure, or GCP. However, the same organizations typically have dozens—if not hundreds—of SaaS applications deployed through their enterprises. Each of these SaaS applications differs widely from the next and poses a unique set of security capabilities and challenges. It’s easy to see that SaaS security and attack surface management in particular is becoming more critical for our security programs and operations.

Attack surface management is generally defined as taking an adversarial perspective on the continuous discovery, inventory, classification, and monitoring of an organization’s surface area… and then doing something about it.

When it comes to SaaS, this is not as straightforward as we would hope. Staying on top of your SaaS attack surface can be difficult or outright impossible without the right tooling and processes. The dynamic nature of SaaS applications, the limited visibility into configurations, and the fact that many SaaS applications integrate and interact with each other make SaaS attack surface management challenging at best. To make things even harder, there is no generally agreed upon and common SaaS security shared responsibility model and each new deployment, configuration, and integration can change the risk calculus.

However, SaaS attack surface management is not impossible. At the end of the day, SaaS, similar to IaaS, PaaS, and other cloud services, is another security operating domain. As security professionals, we must evolve our security programs and controls to account for SaaS. Taking an adversarial approach can help us be more effective and efficient in our efforts.

Discovery

The age-old truism in security that “you can’t defend what you can’t see” rings especially true in SaaS where you typically don’t control the underlying systems and the applications are hosted on other companies’ infrastructure. With the dynamic nature of SaaS applications and the ease of deployment and integration, SaaS app discovery can be difficult. However, taking an outside-in approach to SaaS discovery can help.

DNS subdomain scanning is a useful tactic to discover internet-exposed SaaS application portals and their APIs. With subdomain scanning, you can target many common SaaS application domains and then search for the common subdomains associated with your organization. As an added bonus, subdomain scanning can help you shed light on what potentially sensitive information about customers, subsidiaries, and partners you may be exposing to the internet.

Another useful approach is implementing a governance process for vendor management. This would require any team seeking to procure a SaaS product to navigate a product risk review process. It’s useful to include finance as a hard gate whereby funding is not authorized until the risk review is complete. This can help ensure that the vendor management process is followed and that others are more supportive of the risk review. While many organizations already do this, the dynamic nature of SaaS and the ease of integration both within and amongst SaaS applications makes it critical to review your SaaS footprint regularly and not just during the initial procurement process.

At the end of the day, discovery is a continuous process. SaaS applications can change often and discovery must be accurate to be useful. The correct tooling can greatly facilitate this process.

Inventory

Keeping track of SaaS applications and their endpoints is critical for knowing what is deployed. Things to consider in your inventory include:

Where is the SaaS application deployed? Know the cloud region and address of the provider if possible. This is important for privacy purposes in addition to security.

What sorts of data are stored in the application? Consider PII, NPI, PHI, IP, and other sensitive types of data.

Who has access? This can be difficult to track at scale, but at least document who has administrative rights, third-party contractors, integrations, interns, and those with sensitive permissions and access that may not be administrators.

What are your security and privacy points of contact? During a security or privacy incident is not the time to try to figure out who to communicate with at the SaaS provider company.

Classification

Just as it’s important to classify the types of data that we are responsible for, it is also important to classify your SaaS applications. Classifying your SaaS apps according to organizational sensitivity, compliance/regulatory risk, integration dependency risk, and so forth can help you triage and respond more efficiently and effectively during a security incident and prioritize security resources and controls. For example, mapping critical organizational processes back to the SaaS applications that support them can help inform incident response and business continuity/disaster recovery processes in the event of an incident. Proper classification of your SaaS application install base can facilitate these critical processes.

Monitoring/Threat Detection

This is an area where having the right processes and tools can make all of the difference. Security threat detection and monitoring in SaaS is hit or miss. Some SaaS apps have robust native capabilities and some don’t have any. It’s not like you can deploy an agent or tap on a SaaS app. CASB is mostly focused on access and does not have visibility into what happens within and amongst the SaaS apps and their integrations. Further complicating the issue is the fact that many SaaS applications are platforms with a plethora of third-party integrations. Each integration having its own permissions requirements, data access requirements, access grants, and so forth. Monitoring individual apps with native capabilities does not scale and trying to apply traditional tools to the challenge is like trying to pound a square peg into a round hole. It does not make sense.

Here is where purpose-built SaaS security tools coupled with regular adversarial simulations, such as red team exercises and penetration tests, can help. The right tools and adversarial exercises can shed light on your surface area, identify gaps in your detection capabilities, and assess the effectiveness of your security tools and controls. Effective SaaS security products will have an in-depth, integrated, and enriched view of your SaaS application install base. The products will understand the entities involved and their activity within and amongst your SaaS apps, and will provide a unified view of your SaaS attack surface and posture.

Posture Management

Most security professionals would agree that prevention, while not always possible, is ideal. This is especially true in SaaS where an ounce of prevention is worth a pound of cure. Posture management, especially when focused on an organization’s attack surface, is an ideal method for identifying the settings and configurations that contribute to either a strong or weak security posture. Once again, this is an area where native capabilities within SaaS applications can be hit or miss. Having the right tool in place that can understand the state of your SaaS applications, understands the implications of the configuration, and surfaces the findings with the context required to make informed decisions on the risk and methods to improve over time is critical. This is particularly important given the dynamic nature of SaaS apps where the security posture can change faster and more easily than with traditional applications and systems.

Moving forward with integrated SaaS security

While SaaS is a relatively new operating domain for many security organizations and there are many unique considerations, at the end of the day, the SaaS security challenge is not impossible. Evolving our security programs to factor SaaS, implementing appropriate governance controls, and deploying purpose-built tools to stay on top of SaaS threat detection, incident response, compliance, and posture management are critical to effectively securing our business-critical SaaS applications against the latest cyber threats.

Ad

No posts to display