Security Unfiltered
Security Unfiltered
Finding Zero Days in Salesforce Industry Clouds
SaaS platforms represent a significant security blind spot for many organizations, with misconceptions about the shared responsibility model leaving sensitive data vulnerable to exposure. Aaron Costello, Chief of SaaS Security Research at AppOmni, shares insights from his research uncovering five zero-day vulnerabilities in Salesforce Industry Clouds and explains why SaaS security requires specialized expertise.
• Security teams often mistakenly believe SaaS vendors are fully responsible for security
• The shared responsibility model means customers must secure their own configurations and customizations
• Nearly a third of Salesforce customers use Industry Cloud solutions, which were found to contain significant vulnerabilities
• Agentic AI introduces new security challenges requiring strict access control implementation
• AppOmni provides visibility by connecting to SaaS platforms and analyzing security metadata
• Effective SaaS security requires collaboration between platform administrators and security teams
• Acquisition scenarios create particular security challenges when integrating new technologies
• The most effective approach combines administrative knowledge with security expertise
If you're interested in learning more about SaaS security or accessing the full Salesforce Industry Clouds research paper, visit appomni.com and check out the AO Labs section of their blog.
Follow the Podcast on Social Media!
Tesla Referral Code: https://ts.la/joseph675128
YouTube: https://www.youtube.com/@securityunfilteredpodcast
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
How's it?
Speaker 2:going. Aaron, it's great to get you on the podcast. It's been a few months. It's been like what? Six months probably at this point, since you were last on, I believe. So, yeah, it's great to be back, but I felt like we had so much more to talk about that we could absolutely have you back on sooner. So I appreciate you coming back on and we're going to talk about everything SaaS, security, salesforce there's a new Salesforce report out that we're going to dive into, so I'm definitely excited for our conversation.
Speaker 1:Yeah, me too.
Speaker 2:It's an absolute pleasure to be back. Yeah, yeah, yeah, me too, it's an absolute pleasure to be back, yeah, yeah. So, aaron, you know why don't you? You know, maybe just refresh my audience's, you know, memory of your Qwik background, right, just you know what's your specialty?
Speaker 1:that sort of thing. Yeah, absolutely so. I'm the chief of SaaS security research at AppOmni, so my niche is in SaaS security, as alluded to in my title. So specifically focusing on the SaaS platforms that are powering the enterprise globally so if you're not familiar, that's what those are we're talking about Salesforce, servicenow, oracle, netsuite, workday those cloud systems is what I kind of focus on, and really my specialty area is in identifying misconfigurations or potential for customers to misconfigure these platforms in a way that reduces their security posture. So I do a lot of zero-day kind of research, but it's mostly figuring out and identifying if a customer regresses in some access control or if they enable some configuration, how is that reducing the overall security of their environment and how could that be exploited by an attacker?
Speaker 2:Yeah, it's interesting because, you know, I feel like there's still a notion of SaaS apps being like a very highly secure you know path forward, right, and I feel like people that don't really look into it, that aren't that aren't security experts in the field, it's difficult for them to grasp that Because you're putting all of your trust in this application that you're using every single day for the most part. I mean like Salesforce, for instance. What company doesn't have Salesforce and what company is also looking at Salesforce from a security risk perspective? Right? Like I was working for a large automotive manufacturer, you know, based out of Germany, so you can narrow it down right there to three. Right, and they have a giant, giant Salesforce presence right, globally, because whatever Germany buys, the rest of the globe is going to, you know, take and deploy and everything else.
Speaker 2:Right, because Germany is over there negotiating these insane deals with vendors and, you know, a year in a year into this role, you know, my CISO says, oh hey, you know you should go look at Salesforce. Like we don't know what's going on over there. What are you talking about? We don't know what's going on over there. What are you talking about? We don't know what's going on over there and I found out I mean 20% of what the security team knew about Salesforce was completely wrong or they only knew about 20% of what was going on.
Speaker 1:Yeah, that is extremely, extremely typical. Generally, what we see is that security folks within an organization are forgetting what the shared responsibility model is, and so they have this preconceived notion that it's like, well, it's on Salesforce to secure Salesforce right, and it's like, well, not, it's not that clear cut, because Salesforce is responsible for the security of their software. It's proprietary software. So if you've like a sql injection out of the box that, like the second you buy, a salesforce instance is there, then it's like, yeah, that's on on them to fix. So that's, that's their job from a security perspective. What isn't their job is monitoring and auditing configurations that you, as a customer, and customizations that you make on the platform.
Speaker 1:And this isn't just Salesforce, it's across the board right For ServiceNow, all these different SaaS platforms. If you decide that you want to delete every access control, you can do that. That's what makes these platforms so powerful and also, funnily enough, so popular is they're so customizable. It's like, hey, here's the platform. It can do all these amazing things and you can build so much on it. You don't like our APIs. You can build your own APIs and you can do whatever you want, and it's fantastic. But it's not the vendor's job to secure those APIs for you, right, they don't know what your use case is. They're not going to do any of that.
Speaker 1:So it's on the depending on who you ask could be on the platform administrators the guy who's got the system admin account on sales forest, who's logging in every day, could be their job. Could be the job of the actual like red teams right to kind of get up to up to scratch with the um like access control model of of these sas platforms and do their routine pen tests and things like that. There's also a bit of responsibility on the developers within these organizations. So if you've got a very big Salesforce presence, you've probably got people writing code on Salesforce because they have that on these platforms. They've got their own languages effectively and by writing code you can introduce security vulnerabilities there.
Speaker 1:So, depending on the organization, the security of your platform, it could fall on one person, it could fall on multiple teams across different departments. It really does depend. But ultimately most organizations aren't even necessarily getting that far. They're not even getting as far as like. Well, who should we task with securing our SaaS platforms? It's more so. Yeah, it's the vendor. I feel like, as the past couple of years have gone by, where attackers are now focusing a hell of a lot more on SaaS platforms because of the very sensitive nature of the data being stored there, that it's been a bit of a wake-up call to the internal security orgs being like oh, we should really have visibility into what's going on in these platforms.
Speaker 2:Yeah, it's interesting. I wanted to ask you one of the risks that you're always told about is protecting yourself from proprietary storage methods or like proprietary, you know storage formats of your data. Is that even a real thing in sas apps? No, I feel like it's not because that would be such a huge like lawsuit for these sas companies. You know it's like oh, I can't pull my data out and transfer it to somewhere else.
Speaker 1:You know like you know I'm not gonna point fingers on any particular vendor, anything, but I can't speak to how easy they make it to kind of get off platform. You know it is interesting because you do have, you know, people on LinkedIn, these thought leaders, saying, oh, like everyone's now switching back to like on prem because it's cheaper and like all of these things. So I mean I can't speak to how easy it is to get the data off, but as far as issues go, I can't speak to how easy it is to get the data off but as far as issues go, I haven't heard a ton around that I don't think it's as big of a problem as it necessarily was back in the day.
Speaker 2:Yeah, the thought leaders that are saying that companies are moving back to on-prem, I feel like they'll be back. Like whenever I hear that, it's like I feel like you're going to be right back. You know you guys forgot about the pain of having on-prem infrastructure, running your own data centers and everything Like. That's a huge pain. You have to have whole teams around that.
Speaker 1:Yeah, yeah, and I mean software development's changed so massively that it's like I'm sure the up-and-coming generations will be like how did Mark Zuckerberg build Facebook without Kubernetes? Without Kubernetes and like wireless functions and like Lambda and all this stuff? But, yeah, I think, I think SaaS is never. It's never going to go away, right? Yeah, I've heard ramblings on LinkedIn about, well, with all of this new like AGI stuff coming in, like why do we really need SaaS platforms anymore? However, these SaaS platforms are actually building their own AI, right, in terms of you got like AgentForce or Salesforce and they're moving with the times and the unique thing about them doing that and what makes that so powerful and what will keep customers on those platforms is that those agents have domain knowledge, right, and that's the key differentiator like agent force being on the platform has domain knowledge like that's it doesn't apply off platform for other AGI. So that's another thing to think about.
Speaker 1:I think we're in an interesting time where there's being just a massive shift and how organizations are looking at SaaS and their usage of SaaS, especially incorporating, as I said, like AI into that. But when it comes to overall security, I think it could be forgotten about a little bit. Everyone's focusing on like do more with AI, we'll do more. And it's like, well, you still have a platform to protect, right? And ultimately, all you're doing is, yeah, you're getting a whole host of benefits by utilizing AI, but at the same time, you're also introducing another attack vector. So if, again, you are not putting security at the forefront of your mind when building these agents and granting access controls to these agents on your SaaS platforms, it's going to be a bad time for sure.
Speaker 2:Yeah, so why don't we kind of circle back to what agentic AI agents are? I feel like that's such a new term that a lot of people may not even realize what it is, and we're already interacting with it.
Speaker 1:Yeah, well, are you talking about like in respect to, to, to SaaS?
Speaker 1:or yeah, just talking about you know, like Salesforce's solution that you just mentioned no-transcript, effectively, is going to break down what you're asking for into like subtasks, right?
Speaker 1:So if you've got, for example, like a high level task, like hey, I need you to within an organization, I need you to kind of balance, like the inventory of my, my stock, whatever else, it'll look at that and it will then be like, okay, here's what I need to do. I need to break it down into all of these steps in order to fulfill this kind of, I guess, task execution. So it's effectively running with like zero human oversight. Generative AI, like you, had human oversight for each output that the generative AI was giving you, whereas with agentic AI, you're going run with this and you might give it a little bit of exception, handling guidance, like oh, if something's wrong, do this. But generally those are the biggest differences. Agentic AI's main focus is the completion of tasks with a high-level, prompt and very little human oversight with respect to what it gives back to you, and that's just the contrast to generative AI.
Speaker 2:Okay, that makes sense. So where do you start with securing something like that?
Speaker 1:Yeah, yeah, well, it depends. I can't really speak to SaaS platforms, right, because that's where my expertise lies, but when we're looking at, you've got an agentic AI agent, right, and you want it to fulfill some tasks, such as, like, maybe you have a customer that wants to file a case, just some issue, and so the agenda guy needs to first look at the problem, assess the priority, the impact, file it in the necessary place and assign it to the necessary people, and in order to do that, it needs to have some level of access right To those places in the platform. Right, it needs to be able to see okay, who can I assign this to? Who are these people internally? What's their function? Are they relevant to finding a solution for this case? They need to be able to create and write data, because they need to put the case ticket information somewhere.
Speaker 1:And so the first place that I would be looking at is the access controls that you are giving this agent. It needs to be completely minimal with respect to least privilege, and that comes back to the whole zero trust model, like operating with complete least privilege, because the last thing that you want is an overprivileged AI agent that gets some prompt injection right, gets tricked by a malicious actor into fetching some unrelated information like PII or something, and that can only happen when it has access to those PII records. Right, that's really the myth of securing these agents for SaaS. It is enforcing these privilege following that kind of zero trust model and, as a result, by doing that, you are minimizing your exposure to attacks like prompt injection.
Speaker 1:You know, there's only so much.
Speaker 1:Even in the scenario of a successful prompt injection payload, there's only so much.
Speaker 1:Even in the the scenario of a successful prompt injection payload, there's only so much that the agent can do and so, as a result, the blast radius and impact is massively, massively reduced.
Speaker 1:Now, that being said, like I've seen some pretty intense implementations on platforms, on SaaS platforms, where you've got like one agent communicating with another agent, platforms where you've got like one agent communicating with another agent, and so it's like fanning out these tasks and it's almost like doing its own assignment to like other agents. And so when you start getting these more complex architectures where you've got multiple agents doing that manually, that kind of auditing of permissions and, you know, ensuring there's no like permission drift is going to be a very difficult task, right? Because the more components whether it's agents, whether it's APIs the more components that you start building, the larger your tax service gets. So it's really important that, where possible, manually audit the access controls on the platform. With respect to AI, but I would recommend that, if you are an enterprise organization, to get an automated monitoring and scanning tool like AppOmnit, an SSPM that can continuously assess the security of those agents.
Speaker 2:I have two questions, questions. Right, I want to dive into the Salesforce report. The other part is how does AppOmni, you know, get that visibility? Because, at least from my side right, I haven't really used a SaaS security solution before I've needed to, right, and so I only see the SaaS platform as a security engineer, security expert, right, that's looking at the platform from basically like an admin perspective and I have to go through all these different menus and everything to try and piece everything together. How is AppOmni plugging itself in to show, like, the hierarchy of these agents and the security of the platform overall?
Speaker 1:Yeah, yeah, so there's kind of multiple aspects to the security of the platform overall. Yeah, yeah, so there's kind of multiple aspects to to the product right and to like an sspm in general and starting from from really the bottom is typically speaking for um, getting getting your customer who has, let's say, a salesforce organization, right. So you're going to connect over api using like awath or even like certificate-based authentication depends on the platform they could. The customer will have created an integration account for app omni so that integration account has the necessary roles for us to access various kinds of data you know, and so we then start to ingest anything security related from a metadata perspective. So when I say like a metadata perspective, we are not going to be pulling in like password hashes, that kind of stuff over API. We start to pull into our platform things such as like role-based access controls, any configuration settings related to security, audit logs, access logs, like those kind of things We'll even pull in. In some cases we can even pull in like code components and analyze those. So it really depends on the platform. But generally speaking, in terms of connecting over OAuth or similar form of secure authentication, and we're ingesting those over either existing out of the box APIs the platform provides or, in some cases, if the data, for example, with NetSuite. In the past, they weren't exposing third-party applications over APIs, so we had to deploy custom APIs on our customers' environments, their NetSuite environments, that would expose that information for us. So, once we have ingested all that information, the first thing that you're really getting, without anything else happening, is a single pane of glass like eagle eye view of your entire platform from a security perspective, because we're consolidating all of these security controls and your user role assignments and all of these things your access controls effectively onto like a couple of pages, right, as opposed to, or even just a couple of tabs as opposed to, as you said. You're like, okay, permission sets, click profiles, and you're trying to piece all of the access controls together. So you've now got this very comprehensive, complete inventory of anything security related on app omni. So you log into app omni or you can interact with over api, but, just for argument's sake, you log into app omni. You've got your uh, you've got a full inventory of anything access control related. You've got your audit logs there, right. You've got your third party app connections, you've got all of these things, and so that's the inventory piece done.
Speaker 1:Okay, now from there is where really, like, the real benefit of an SSPM comes in, and that's really where myself and like my team come in and it's like, well, now that we have all of this metadata, let's start analyzing it and servicing the issues to our customers. So, using what we call App Omni Insights, which is just, these are just continuous scans that we do against this data, we surface varying problems, right, like, okay, it could be as basic as you've got too many administrators, you've got no access controls on this Salesforce object or you've got externally exposed data here, and so what we were doing there is we're becoming your SaaS experts, like we were SaaS experts, so you don't have to be. We can tell you what the risks are. All you need to do is look at the findings, click on them. We provide their mediation guidance and you can just go in and make those changes yourself. So we're performing all these very, very complex scans against this data.
Speaker 1:You've also got the kind of monitoring piece right, monitoring and alerting which is we're ingesting all of those access logs, and we've got rule sets that could be out of the box when you have App Omni could be varying rule sets that you want to apply or install that we provide to you, and those rules will run against your audit logs and we also normalize all of our audit logs.
Speaker 1:So if you've got Salesforce connected, you've got ServiceNow, you've got all these platforms, we normalize that into a very consistent format. So straight away, that's a massive benefit because we ingest it and we can dump that normalized format into your SIEM like Splunk. But when it comes to the actual alerting piece, we know what to look for, we know what's suspicious, so we can say, hey, there's a credential spring attack going on right now. You need to look at this and service those alerts to our customers so they can be aware of potential attacks or suspicious activity and then they have the information needed to take action on it. And that's really the simplest way I can put it. When it comes to app on an SSPM, where just connecting to your instance over a secure authentication method, you grant us the permissions that we need to interrogate the kind of security metadata, we pull those in and we give you an inventory of all your security related components and then perform a lot of complex analysis on those various access control components, components yeah, it makes sense.
Speaker 2:It's helpful to kind of just understand. You know how it's working under the hood it's.
Speaker 1:It's an area that not not very many people like focus on you know it's, which is a massive, massive shame, because I'll give you I'll give you an example of of really how how dangerous it can be when you misconfigure access controls. And so a lot of my research that I've done in the past is related to data exposure, so sensitive data being exposed to the public internet, so completely unauthenticated. That's kind of my wheelhouse. And the thing about sas platforms that differ from pen testing, custom, you know, in-house built applications. If you're doing a pen test on a custom app, right, it's got its own implementation for APIs and all these things, so that when you go and do another pen test against a different client, they're going to have a completely different set of features in their product and APIs and access control and things like that. So if you're an attacker, you have to, like, learn every, every little application system and figure out how to get in that way, which is very time consuming, whereas SaaS, the benefit to an attacker is that all of the core components for Salesforce, for example, across all Salesforce customers are the same right, so they've got the same APIs built in out of the box. So in the past I have found cases in which with Salesforce, with ServiceNow, with NetSuite, with Microsoft Power Platform as well.
Speaker 1:If you misconfigure access controls to accidentally imply that unauthenticated individuals can see your data, there are these, in 80% of cases, undocumented, out-of-the-box APIs that are accessible from the outside world, from the public internet, where you can start to pull that data. So if you're an attacker, you can interrogate a SaaS platform like Salesforce and say okay, I'm going to try and extract data from every single object or table it's telling me is available and try to exfiltrate sensitive data that way. And the reason this is so important and why it's so lucrative to attackers is because, as I mentioned, those core API components that allow you to exfiltrate data will exist on every single SaaS customer of that platform. So if you want to attack Salesforce and attempt data exfiltration, you can write a script that will just query every live Salesforce instance and it'll send the same queries effectively, right, and you can do it really at scale. So that's why the book many people love it so much, because they're like oh, I don't have to learn anything new, I just point a script at a salesforce instance and point the same one at another one and try and like find some some data exposed. It's lucrative, you know, wow, but that's why it's it's such a shame that companies aren't paying as much attention to sas, because, one, you've got all of that complex under the hood like undocumented api stuff going on that you may not know about, and, two, it's like where it's where your most sensitive data lives, you know.
Speaker 1:That kind of brings me into the research paper that I released last month and that was focusing on Salesforce Industry Cloud. Well, salesforce Industry Cloud, I should say it's plural, it's kind of an umbrella term. So, to give you the background, I think it was 2014,. A company called Velocity were building these like Salesforce packages, right? So there were these bundles of code components that their Salesforce customers could install and it was providing them with pre-built, like low-code solutions for their industry. So, if your customer was in healthcare, there was one for healthcare and it allowed you to build like workflows that were specific to healthcare and, like you know, healthcare portals. And I just made all that very, very easy because it was all low code. And then I believe it was 2020 or 2021. Salesforce looked at that and said, hey, we love what you're doing, so we're going to buy you. So they bought the company and the solution and said we're going to redo this a little bit, because you're doing everything from these code packages and that doesn't work very nicely with the existing components on the platform. So we're going to take your solution and we're going to actually bake it into the core platform and now it can interact with things a little cleaner. And that's where industry clouds are.
Speaker 1:Today, industry clouds encompass 11 different clouds, so you've got like public sector solutions, I believe there's an automotive cloud, there's a health cloud, financial services cloud all targeting specific industries and so if you're a salesforce shop and you are like a pharmaceutical company, you'll purchase HealthCloud to give you all these pre-built solutions related to healthcare. And so my research was focusing on potential misconfigurations and even vulnerabilities that exist within all these industry clouds. So I was looking at the actual underlying technology that was powering these 11 clouds. So it wasn't focusing on health cloud or anything like that. I was focusing on the underlying engine, so that every issue I found applied to all of them. And so what I did was and the reason I actually even started doing this was because at Bumney, you know, we've got nearly a third of our customers using one of these industry clouds. They're so widely adopted, you know, and so that was kind of the catalyst to me even doing the research in the first place, and so what I did was I was analyzing all the different feature sets and access control implementations, everything, every security relevant aspect of the underlying engine powering these industry clouds, and I was documenting everything that I was seeing. And I was also working with our security contacts over at Salesforce as I was doing this. So, as I was going along and adding more things, adding more findings, I was communicating it with them and saying, hey, this is interesting. What do you think? Is this something you should harden? If so, well, here's my thoughts on how to harden it.
Speaker 1:It was a very collaborative effort because we partnered very closely with Salesforce, and the takeaway from my research was that, out of 20 findings, five of them were considered CVE worthy right Zero days, so to speak, things that the customer couldn't really, for the most part, can't really fix themselves, and that's that shared responsibility model we're talking about. So, for example, one of these items that was assigned to CVE was an authorization bypass, so that wasn't fixable by a customer, so Salesforce had to take that on. And then the other 15 items that I found were things that were. The other 15 items that I found were things that were labeled as potential misconfigurations, and so these are those items I was talking about, where if you're a customer developing something on an industry cloud and using one of their features, if you don't configure it with security in mind, it would fall into the bucket of a potential misconfiguration. So these are kind of like best practices for industry cloud customers.
Speaker 1:And so I released like a 53-page white paper that goes really deep into each and every finding. So I talk about like I give like an overview of every finding, I give like a proof of concept technically. I give like an overview of every finding. I give like a proof of concept technically because, as a security practitioner, I would want to know like how would an attacker even do this? Are you just like telling me that this is an issue? So it gives you like a full setup. So here's how to set this up proof of concept, how to fix it, the risk, all of that, which is why it's 53 pages. And we released that in accordance with Salesforce. We gave Salesforce enough time to kind of roll out those CVEs and the patches and, once their customers were given sufficient time, to install updated packages and things like that and address those concerns. We released the research paper and Salesforce, in conjunction with us, released their own blog post accrediting us with the research.
Speaker 1:So the kinds of issues that I was finding. When it comes to these industry clouds, they are very feature specific because industry clouds has a lot of different ways of doing things, as it's a low code solution right, but we're talking about things like bypassing encryption controls. So, for example, if you've got an industry cloud kind of low code component accessing some data and it's encrypted, normally you shouldn't be able to see that, but there are workarounds in order to actually see the plain text values. There are ways of bypassing, like field level security, so it's like maybe someone internally shouldn't be able to see how much everyone is making, but they should be able to see their list of stuff or whatever. You could bypass that field level access control on that salary field and see that data.
Speaker 1:There was like a myriad of issues. There was issues related to caching in which you could bypass or you could actually receive the data meant for another user. So it was a really weird one where you could build this kind of low code component in Industry Cloud that would fetch some record data and once you execute that component to give you the data. If you had misconfigured your caching mechanism in Industry Clouds, the person who then makes the same query but has different levels of access will get your results. So if you're the first person you're an admin you're kind of screwed because someone authenticated guy over there made the same query and just got your results.
Speaker 1:So there are tons of really really interesting findings that really span across like a ton of different categories, like the encryption related stuff. You've got authorization bypasses, you've got caching related issues. So it was a really, really interesting product to research. We've, most importantly as well, during that research process as I was finding these items, we were releasing the actual automated scanning within our product for our customers, because our customer security is our priority first. So if you're an App Omni customer during this research, we were rolling out the scans long before the research was published. So that's kind of like a holistic view of what the research was and the kind of areas that it delved into, but it was really really fruitful. Extremely high risk findings. You got some zero days in there and a massive, massive blast radius right. As I said, nearly a third of our customers, our Salesforce customers are using one of these industry clouds. So if that's any representation of what, like the non-App Omni customers are like, then it's a ton of organizations that are potentially affected.
Speaker 2:Wow, that's really fascinating and quite impressive. Honestly, how does that even happen? I mean, I don't want to put you on the spot, right, but how does that even happen internally at a company like Salesforce, right? I would think, salesforce being the behemoth that it is in the industry, that it would have a pretty robust, you know, like internal pen testing team that will be looking at it from the outside like a researcher like yourself would right and trying to pull this stuff apart. How does that even happen where this is going on unfound, undetected, at their side?
Speaker 1:Yeah, so when we look at the CVEs specifically like the zero days, because that's really like their responsibility for finding, well, put it this way, so you're Salesforce and you purchase all of these little bundle code components from Velocity, right, number one you don't necessarily have you've got Salesforce all the security you've got in Salesforce, have Salesforce security experience. Naturally, right, it's part and parcel, but they didn't write this code. They don't really necessarily know how it's supposed to work or what it's really doing, and so it's like, okay, well, we need expertise for all these Velocity bundles. I don't know how many folks from folks from velocity went to Salesforce and then stayed there, and so I think what happened was there was maybe a lack of that kind of domain expertise in what they purchased and in addition to that, they were trying to really rapidly convert these code bundles and inject them into the core platform as well, and so it's a combination of all of these things that these security issues can go and notice.
Speaker 1:I don't know what the velocity of what that organization had said to Salesforce. Right, they could have said like, hey, we do pentests every week, we do all of these various things Like we've got, we adhere to all these compliance frameworks. So I don't know what kind of went down, but ultimately I just think it's an acquisition and it just slipped under the radar and they just maybe didn't have the domain expertise, expertise to tackle and hunt for, hunt for those issues. Um, it's very, very typical when it comes to acquisitions because you're trying to like port in all this technology and you're kind of afraid to touch it because it's like all right, we just spent a ton of money on buying this, so let's not break the the core functionality of what we just just bought yeah, yeah, I I was working for a credit bureau when they went and purchased another, like like another you know competitor or whatever it was, and it was an insane deal.
Speaker 2:But security was basically the part that was holding up you know, the deal getting done. And it's because I don't think that it was another credit bureau that we bought, but it was like very close, we're like they had the exact same data and it just made a lot of business sense to purchase them. But at the same time, right, our CISO and our directors were kind of juggling with the fact that, like, hey, we can't do an in-depth, you know analysis of this code and the products and everything, because we're going to be incorporating them into our offering. Like, we can't wait three years. Right, it's got to be done in 12 months, you know like. And even then it's going a little bit slow for us.
Speaker 2:And so it was a risk. It was a real risk and I think it probably still is a real risk, because it was a great enough risk to where they didn't lay off anyone at that other company. They were like, yeah, you guys are doing your own thing, you're fine, keep it going Right. Like, didn't lay off anyone hired more people for them. They actually kept their network completely separate. You know like it was such a big deal that I had to buy like additional instances of my security tools to deploy in their environment. It was a completely separate thing. You know, because, like it said, the same name you know on the on the logo, right, but it was like that is a totally different.
Speaker 1:You know can of worms, right yeah, I've seen I've seen some of um, some rare customers use up omni for m&a for that exact use case of like, hey, we're looking to kind of buy this, so we're going to want to hook up all their stuff to see are we taking a huge risk on? Do things need to be reassessed from a security perspective? What's really the security posture of this organization from a SaaS security perspective?
Speaker 2:I feel like that is a side of security that obviously isn't thought about a whole lot, I mean in conjunction, obviously, with SaaS security, like we were just talking about.
Speaker 2:But you know, when you're going to go and buy another company and you're planning on integrating that product offering tightly into your own product offering, I mean it only makes sense to you know, go to your vendors and say, hey, like can we do like a 30 or a 45 day trial for this other environment over here? We're going to buy them. You know we'll pay you a certain amount or whatever to do it Right, Because how else are you going to, like get that information? You're not going to get that information, even if you do. You know interviews with, like their internal you know pen testing team or their internal blue teams or whatever it might be. Like, you know, at the end of the day day, if I want you to know something and I want to hide it, if I don't want you to know something right, I'll hide it a whole lot of different ways risk the, and there's billions of dollars on the line yeah for sure.
Speaker 1:I mean I'm not gonna say I would do the same thing, but like I get it, I get it right. Yeah, it makes, it makes a ton of sense. And, to be fair, I mean it was only like, um, like a year ago I think, or around that time, when I found out that, like this was a use case for app omni and I was like, oh, that makes an absolute ton of sense. I don't know why I never thought about that aspect of of security. Um, yeah, it's, it's, it's very, very interesting and it kind of just uh ties in very, very nicely with this, this kind of uh topic with the velocity thing, because that could be very well what had happened? Right, they didn't necessarily maybe even know what they were getting themselves into, but it looks like it kind of played out very nicely for them because, as I said, the adoption of industry clouds is absolutely huge. So I think five zero days, reported in a responsible manner, is probably worth the hundreds of millions, billions, that industry clouds is making them.
Speaker 2:Right, Wow, Five zero days. I mean, have you ever seen something like that? Have you ever put anything together? You know of that scale before.
Speaker 1:I haven't ever completed, I've never really done a full kind of product analysis. Now, again, it's a product built on a product, a product right. So this is kind of the first of its kind. Um, for for me I'm doing like a holistic security assessment of the potential risks and also zero days. Um, and it was.
Speaker 1:It was super fun and, honestly, like it took months to put together, but it was only meant to take a couple of weeks. And what happened is I'd find like maybe at first I found like five really cool things. I'd be like maybe at first I found like five really cool things. I'd be like, okay, I'm done, now I'm gonna put the white paper together and I'd see like one little button. I'm like what does that do? And I'd click it and all of a sudden the security shuts off or something.
Speaker 1:And so I kept finding things and I was like I just need to stop looking at this product so that I can actually get around to to writing the research and getting these things over to Salesforce so they can see if they're zero days or not. But I mean, when it comes to, have I seen that amount of zero days in one thing? Fortinet has like a zero day dropped against it every five seconds, so I don't think it competes to Fortinet, but yeah, it was very, very fruitful. It's great to produce a bit of research that not only benefits our customers, obviously, but at the overall, like salesforce community, by identifying these potential foot guns and configurations and telling them how to address it, but also helping at the vendor. I'm being like hey, here's some zero days as well, so it's kind of win-win for everyone and it's it's played out really nicely so.
Speaker 2:So when you're handed this task, right, where do you start? Because it just sounds like a monumental task and I'm not even sure that I would know you know where to start. Are you just working through the basic functionality right of this product offering and just iterating through it Like okay, well, what if I do this over here? What do I get? You know that sort of thing.
Speaker 1:Yeah, and this is why it took so many months, because it's a behemoth of a task, right and how. I always, always when it comes to SaaS in general. How I approach these assessments, you could say, is I don't think like a security person 100% of the time. Honestly, for the first couple of weeks, or for the bulk of the time at the beginning, I think like a platform administrator. I think of okay, how can I build this? What are the configurations? How am I able to expose this and do this? And I think as if I'm trying to actually do something with the technology. And as you kind of put that into practice and start building some things, that's when you begin to notice things, because that kind of security practitioner in your subconscious doesn't turn off. So you'll see something like that's kind of suspicious. And because of that approach of getting holistic knowledge of the platform and all of its features as an admin, you know, in an admin mindset, you're so much better equipped from a security perspective because you know the interoperability of these various features. You know what's kind of working with what and you'll see. You'll start seeing some patterns as well. So I really just approach it like a system admin and get a great understanding of the solution or technology holistically. I get a good inventory of like relevant controls, a good understanding of the use cases, of the various features and various components you can build. And then, once I have that kind of holistic knowledge, I start to interrogate these features kind of one by one, you know, from a security mindset, and I'll start to like toggle off the configuration settings and play around with that kind of stuff as well. So that's generally how I would recommend anyone Like if you're even internally in an organization want to pen test your organization's like service now or workday or whatever it is like, your best resource is going to be the administrator of that platform.
Speaker 1:It's going to be the guy or girl who's literally living on that platform every day. Right, like that is who you should pair with, because that's where you're getting your domain expertise and knowing where to look, because they know where the data is, they know how the platform generally operates, and then you can apply your security expertise and start to actually interrogate things and I personally guarantee you will have far much more success, right, having at least that pairing with someone that has that knowledge of the platform. You'll get much better results and far more findings that way. Now, fortunately, I have to be both as a security researcher, I've got to do both. I've got no service or admin to pair with, so I am the service or admin and the security researcher in my case. Yeah, that's generally my approach, my recommendation to organizations that want to do a little, either security research into SaaS platforms or if they're conducting their own internal hand tests.
Speaker 2:Yeah, it's fascinating to hear you talk about it like that, because early on in my career, when I was trying to get into security, I kind of approached it from that angle. Actually, I was looking at it how my customer is using this platform, how I'm using this platform, and then in the back end I'm actually, you know, tailing various logs and I'm looking through seeing what it's doing and I mean that really helped me build a really strong, just security foundation overall, really strong, just security foundation overall, something I haven't thought about in forever, right, because it was so long ago, but it's just. You know, it's fascinating to break down that mindset because that helps a lot of people start to like think through it, like, oh okay, that's where I would start with it.
Speaker 1:And you know, I I always tell people, if you can envision it, it's a whole lot easier to actually actually accomplish it, you know yeah, yeah, it takes if you're, if you're someone who is a traditional like pen tester kind of red teamy individual, like it does have to be a mindset shift to get the the best buying for your book out of these assessments. And even when I joined up omni, you know I was coming from a very heavy like security engineering background and so I had to. It took honestly probably six months to a year to kind of get into the swing of how to even start looking at these platforms in a different light, and a light that would serve me far better when I'm kind of hunting for things.
Speaker 2:Well, aaron, before I let you go, how about you tell my audience you know where they can find you, where they can find AppOmni and where they can find that really interesting research paper? If they wanted to read it, read through it.
Speaker 1:Yeah, absolutely so. You can find me on LinkedIn under Aaron Costello or Twitter at Conspiracy Proof all one word. Actually, you can find AppOmni at appomnicom. Got a ton of resources there. Most interestingly to your audience would be the AO Labs little section of the AppOmni blog. That's where you'll find the Industry Clouds research. It's where you'll find, historically, all the research that I've been doing into SaaS security. So AppOmnicom and check out the AO Labs section and you'll have all the resources that you need there.
Speaker 2:Awesome. Well, all the links will be in the description of this video. Thanks again, aaron, and I hope everyone watching really enjoyed this podcast. All right, thanks everyone.
