Upcoming Webinar, Dec 5th — Phish Kit Teardown

Blog
/
Company news

From launch to series A

We’re proud to share that we’ve locked in our $15M Series A round, led by GV. Here's what we've learned.

We’re proud to share that we’ve locked in our Series A round, led by GV (Google Ventures). We’ve learned a lot about what our customers need since we launched in July 2022 - they want to help employees use SaaS more securely, of course, but they also need centralized visibility and the ability to make good decisions around the use of SaaS by knowing how their employees are using it. 

Most security-savvy organizations have a fairly good handle on IT-owned and managed SaaS platforms (like Microsoft 365, Google Workspace, Salesforce, Slack, etc) and many have started using newer security solutions that discover the SaaS work apps that employees have started using and often integrated with those IT-owned platforms. 

The rise of PLG and how it impacts security 

What they’ve been missing is the rise of product-led growth (PLG) - a popular sales motion that relies on the product itself as the primary driver for customer acquisition and conversion. Potential buyers sign up, integrate it, and experience the product value before going through any sales-cycle. 

The impact this has on security is that where in the past, employees would have needed to go centrally through procurement, which gives the security team an opportunity to assess the risk and determine whether or not the service would invalidate the organization’s security compliance. With PLG, employees can (and do) onboard sensitive applications themselves directly. This shift in buying behavior has contributed to a sharp increase of SaaS sprawl and shadow IT.

Old software procurement process
Traditional software procurement process
New way of procuring software due to PLG
The new way of procuring software due to PLG

PLG is also the norm for app-to-app integrations as well. In our data, we found that around 37% of Microsoft 365 app integrations were IT-approved and owned. The rest (63%) were all employee-owned and consented to. That’s just looking at app-to-app integrations to the M365 tenant, so it doesn’t include all the SaaS apps accessed through the browser. Sure, some of those apps are used by a whole team and may be on IT’s radar if the department head went through the proper security measures. But many may just be used by one person or a team is just signing up for a free trial. And even for those free/trial instances, the apps need to integrate with business apps and data to work and test, so they can present as much risk as any other app used in your environment.

What’s the risk of SaaS sprawl?

The unknowns - the old trope that you can’t protect what you don’t know is cliche for a reason - it’s true. Not every SaaS app or integration carries massive risk, but most apps employees are using to get important work done accesses sensitive data or need to integrate with business data, which is then shared with a third party in each instance.

Each app becomes an asset that security teams need to protect and each new account employees create forms part of the company’s public-facing attack surface. With PLG, apps are adopted before security get a chance to onboard them onto SSO, so weak user accounts employees have created are a potential entry point for an attacker.

This can be a high ROI technique for an attacker. Instead of burning client-side exploits and C2 infrastructure, an attacker kicks off an automated password scan against all popular SaaS apps and gets alerted each time they access an account. Attackers are also utilizing credential stuffing by taking a single compromised employee password and trying it against every popular SaaS service to extend their access. 

The sensitivity of these applications vary depending on their capability, but some particularly high-risk examples we’ve come across include:

  1. Apps that access employee email - attackers can use this access to do account resets and compromise other SaaS apps.

  2. Compromising development or testing tools that have access to API keys and production systems.

  3. Compromising data warehouses, or any independent SaaS app that integrates back with that data warehouse.

  4. Compromising marketing apps that can be used to control public facing assets such as the company social media account or website. 

The Solution 

Complete, real time, centralized visibility

To get a handle on the SaaS sprawl and shadow IT that the PLG movement has caused, security teams need complete visibility of every business application (SaaS apps, cloud apps, app-to-app integrations, etc.) employees are adopting, integrating with company data, and accessing through the browser.

Alongside visibility, security teams also need the option to turn on notifications to keep them up to date about potential security concerns around SaaS use in their organization. This provides security teams with near real-time visibility so they’re notified when someone has signed up for a new app. If an employee or team has been using an app for weeks or months, it can be much more difficult to migrate them to a more secure platform if security decides the risks outweigh the benefits for that app. It also means that security teams get to be part of the decision-making process again. So, even though the PLG model has put security in the mode of constantly having to play catch-up to do risk assessments after the app has been adopted, security teams can reclaim their role in the procurement process with timely notifications. 

The thing is, the notifications need to have enough information to be meaningful rather than just acting as another alert to distract them from their work. Enter channel messaging for security teams. 

Our new channel messaging feature tells security teams about new SaaS being onboarded, of course, but also provides useful security insights about that activity. If a new app is added to or integrated with the company’s Google Workspace or Microsoft 365 tenant, we can tell you in Slack or Teams, and we’ll also let you know if it’s low-risk or if it merits more investigation. 

In the case of app-to-app integrations, we’ve decided against providing an abstract risk score, which isn’t actually very helpful, and focused instead on tangible information on what data the integration exposes, so the security team can make the right risk assessment for their organization. See the example below:

Channel message high risk
Channel messaging flags new apps that request excessive access and permissions

We’ll also flag you if an integration is high-risk because it’s asking for excessive data permissions. For instance, one interesting data point we’ve discovered since launch: 23% of the Microsoft app-to-app integrations we discovered granted access to high-risk assets or data, such as email inboxes, and shared drives like OneDrive. For Google workspace, 17% were equally high-risk.

Security teams need complete SaaS visibility and foundational insights into the security impact of those apps used in their business. Couple that visibility with a user-centric approach to security and you’ve got baseline SaaS security covered, whether you’re a small business with no dedicated team or you’re an enterprise with a highly skilled, dedicated team that’s overburdened with constant alerts and struggling to make actual improvements to your company’s security posture.

Automate the fix by involving the user

The most sensible way we’ve found to scale SaaS security in an employee-adopted apps world is to put users at the center of helping to improve security. We prompt users at the right time to encourage them to take an action that will benefit an organization’s security, like updating their software or securing their user account with MFA or a stronger password.

This shared responsibility model is nothing new, really. It’s a concept that was pioneered by Slack, Netflix, and Duo Security before us. The way we’re applying it to securing employee SaaS use, however, is pretty novel. To us, a user-centric approach doesn’t simply mean building in ChatOps in Slack and Teams - it’s building in a variety of ways to notify and interact with the user when the time is right for them to take action. 

User centric pyramid
This combination of user-centric features drives a shared-responsibility model for securing SaaS at scale

Our approach involves the user from beginning to end:

  • We provide real-time guidance to help prevent problems before they happen (in the browser),

  • We nudge employees to self-remediate issues that have already happened, and

  • We provide an overview for each employee, so the security team can see each employee’s security state for their SaaS use.

Real-time guidance

Our just-in-time notifications act like password-checkers in the browser, but they’re more robust in that security teams can fully customize which words and phrases employees can’t use in their passwords as they’re creating new accounts; it might be company name, location, common words, street address, and so on). This helps prevent employees from creating weak passwords like those that were leaked in a password dump after a breach. Here’s how we’re doing that in the browser:

Just-in-time password security notifications
Just-in-time password security notifications help prevent weak passwords at the initial sign-up point

These simple measures help employees pick stronger passwords from the start, cutting down on the need for any nudges on ChatOps or any notifications to security. Why fix issues when you can prevent them from ever happening?

Notifications

We use notifications in ChatOps (Slack or Teams) when employees can fix security issues with one click without the need for security to talk to them directly. An example of this is using a chat to check if an employee is still using a dormant or inactive app. If they’re not using it, they can automatically eliminate it from the company’s attack surface by clicking the “I’m not using it, you can remove” button. 

Inactive app ChatOps message
A ChatOps message to an employee about an unused app that could be removed to reduce the SaaS attack surface

Employee SaaS security overview

The final component of user-centric security is to provide a personal view of an employee’s overall security state. Security teams can see each employee’s SaaS security state for a quick view of where they need to fix security issues and where they’re in the clear. This user security dashboard is really handy for visibility over particularly high-risk employees (usually those who use a lot of different SaaS apps and those who work with highly sensitive data - like legal teams, executives, HR, finance, etc.). 

By displaying this information in a single, clean, easy to read panel, both employees and security teams can work together to take actions to fix issues quickly and easily.

Employee SaaS security overview
Employee SaaS security overview in the Push platform

How to apply a user-centric approach in your organization

We’ve found that many companies believe in a user-centric approach to security in theory, but what that looks like in practice is less clear. That’s partly because there’s confusion around how to apply a concept that feels like a design principle to your organization’s security strategy. Most people we talk to like the idea of equipping employees to help secure the apps they’re using, but how to make that work in their environment is a bit scary, since it directly impacts every person in the company. 

Part of the problem is that “user-centric” has become a bit of a buzzword in marketing, with a lot of the vendors saying they’re user-centric when that really means they’ve just built a Slack or Teams integration that can message employees. Turning that feature on without thinking about how it’ll impact all of the employees in the business is a recipe for disaster. 

After speaking with customers and prospects since launch, we’ve discovered how important it is that we clearly explain how employees are going to be contacted and with what information. To adopt a user-centric approach that actually leads to measurable improvements in security, you need a tool that reaches out to employees with the right messaging at the right time and in the right place, whether that’s via ChatOps or in the browser, where they’re working.

Equipping employees is part of the solution, not the whole solution 

User-centric approaches are a tool in the security team’s toolbox, a practical way to bring employees into the process - not a way to outsource the technical security burden to people with no security expertise. You don’t get to outsource security to employees and employees should never be making technical security decisions on the company’s behalf. Employees provide context on how they’re using apps so that the security team can make risk-based decisions on which apps employees can use. 

By adopting a user-centric approach alongside centralized visibility and controls, most security teams have found a way to secure employee SaaS accounts and SaaS use at scale. We’re excited to work with our customers and investors to solve new problems in this emerging space. Follow us on Twitter and LinkedIn and sign up to our mailing list to come along for the ride!

Subscribe to get updates from Push
The latest news, articles, and resources, sent to your inbox