Breaches, privileged credentials and the SaaS application conundrum [Q&A]
Last year Toyota suffered a data breach due to accidentally exposing a credential allowing access to customer data in a public GitHub repository.
This type of breach could be avoided if organizations turned their focus on credentials that are exposed within SaaS applications. We spoke to Corey O'Connor, director of product at SaaS security platform DoControl, about why he believes identity security needs to go beyond just protecting the keys.
BN: How can organizations increase their focus on credentials that are exposed within SaaS applications?
CO: The use of privileged credentials is common in almost every cyber attack. This is well understood. However, it's an ongoing challenge to secure the credentials and identities that have access to them, especially in today's reality of digital transformation initiatives and the journey to the cloud. The threat of both human and non-human access to corporate data becomes a challenge at scale. You have more systems and applications that are accessed by a number of different identities, both internal and external, as well as non-human i.e. application-to-application integrations. Data is generated and exchanged in significantly high volume. This increases an organization’s attack surface and the likelihood of data exfiltration. Security becomes a blocker that introduces unnecessary technical debt to the business if not navigated effectively.
There are numerous examples where machine or non-human identities are introduced to help enable the business (i.e. service accounts or software bots with Robotic Process Automation technologies). Organizations need to increase their focus around non-human user access. These identities and their associated credentials are often overlooked by the Security team, and can be an attractive target for attackers to gain an initial foothold. For example, the OAuth protocol provides a convenient way for one application to connect to another, but when this access becomes compromised, it can provide unauthorized access to sensitive data within the application that it's connected to. The risk of supply-chain based attacks involving OAuth tokens and other non-human identity credentials are becoming commonplace.
BN: Why have we seen an uptick in negligent insider risk associated with privileged credentials and SaaS applications?
CO: The uptick is connected to what originally helped shape the new normal with hybrid and remote working environments. In order to support the business, there was a commingling of different devices and applications being leveraged for users to get work done. You have work-related applications installed on personal devices and vice versa. You then have files being accessed and shared to private email accounts. In the early days of the pandemic, there was a surge in adopting new Software as a Service (SaaS) and other cloud technologies to support the business. CIOs wanted to enable the business and not slow it down. Significant SaaS application and data sprawl was one of the negative outcomes.
From a human user perspective, you have a data management and overexposure problem in a typical SaaS environment -- featuring hundreds of different apps, thousands of internal and external users, and tens of thousands of files. Human error is still so prevalent and challenges every organization. Behaviors of insider risk that are deliberately malicious or purely negligent need to be detected, the right personas need to be alerted, and the appropriate response needs to be applied (i.e. a departing employee who is sharing customer lists with their private email account).
From a non-human user perspective, you have an increase in both sanctioned and unsanctioned applications within the SaaS estate. Some of these applications are often over privileged with risky permission scopes, they might not have been verified by the publisher (i.e. via the vendors Marketplace), and many are not approved internally by IT/Security teams. The same approach needs to be applied for non-human access, where you have the ability to identify malicious behaviors, such as activity that is indicative of a supply-chain based attack. Detect high-risk application-related activity such as excessive write API calls, performing a significant amount of updates, or the application server has a known malicious IP address. IT/Security teams should be notified and take appropriate action to remove the OAuth token, suspend the application, etc. Many of these steps need to be automated in order maintain both business continuity and a strong security posture.
BN: How as more organizations adopt cloud-first strategies can they best ensure these 'keys to the kingdom' are not mishandled?
CO: Knowing who has access and to what is vital here. Again, this goes for both human users, as well as machine identities. Creating a full inventory of users, applications, assets, domains, groups, etc -- and having an understanding of the business-context through communications tracking, mapping, and relationship graphs is essential. Business-context is so critical in not slowing down the business, and security teams need to be able to understand what is a normal practice versus events that introduce material risk to the business. Otherwise, you end up with a significant number of false positives, positioning Security teams further away from identifying and responding to events and threats. Enforcing the principle of least privilege to both human and non-human users is one way to support a strong security posture for organizations pursuing a cloud-first strategy.
BN: How can organizations move away from the mindset of security as an afterthought, especially as users continue to share credentials leaving data exposed to fall into wrong hands?
CO: There needs to be tighter controls around privileged credentials, for both human and non-human users. For example, it's very common for pem files, AWS keys, and other credentials to be shared by developers and administrators over Slack. Having those credentials exposed indefinitely over the Slack channel is obviously problematic. There needs to be a balance of supporting the business in a way that makes sense from a security perspective. This can be a challenge as the business grows and scales, which is why automation plays a critical role. Security needs to be a business enabler.
BN: What advice can you give to mitigate risk and adjust security posture to ensure keys are not mishandled?
CO: Focus on three specific things: discover, monitor and remediate.
- Discover all connected SaaS applications to the core SaaS stack. Identify issues of non-compliance for the entire SaaS application estate to ensure security policies are effectively enforced. Expose a full SaaS-to-SaaS application mapping and comprehensive inventory of first, second and third party applications (i.e. installed users, drive access, drive-wide permissions, and more). Establish a strong understanding of the riskiest SaaS platforms, applications, and users exposed within the SaaS estate.
- Enable Shadow IT through application reviews with business users to monitor and control the SaaS environment. Assign a risk-index to each application to enable the assessment and evaluation of the SaaS estate. Create pre-approval policies and workflows that require end users to provide a business justification to onboard new applications. Quarantine suspicious applications, reduce overly excessive permissions, and revoke or remove applications or access. This way users can be productive without introducing unnecessary risk.
- Remediation needs to be automated in certain instances. Such as enforcing security policy enforcement across the SaaS application stack that prevents unsanctioned or high risk application usage, and remediates the potential risk those apps might expose (i.e. invalid tokens, extensive or unused permissions, listed vs. not listed apps, etc.). Implementing automated security workflows will reduce the risk exposure related to application-to-application interconnectivity (i.e. automatically suspend or remove potential malicious applications).