Listen to learn how leaders can prepare to handle data leakage in these environments.
With the rise of Software-as-a-Service (SaaS), we are hearing more about supply chain risks. Boris Sieklik (Senior Director of Information Security at MongoDB) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to discuss:
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics, and I'm very excited today to talk about, software as a service security, the data security in in, in that environment. It's very timely topic, and I have a great person here to talk to me about it.
His name is Boris Sieklik. He's a Senior Director of Information Security at MongoDB and a strong believer in cybersecurity being a business enabler. He has more than ten years of experience in cybersecurity leadership roles across different industries, including finance, anti malware, and tech. Previously, he published about a new DDoS amplification attack, which was covered in national media.
He holds a number of certifications, including OSCP, CEH, and others. Additionally, Boris holds a MSc with distinction in advanced security and digital forensics from Edinburgh Napier University and first class BSc in computer networks from Middlesex University London. Boris, thank you and welcome to the show.
Thank you for having me.
So, let's just launch right into the topic because I know that a lot of people are concerned about this. How do they protect their data when they're kinda handing it over to other people? So can you tell me a a little bit about your background first? How you gotten close to the world of of cloud security?
Sure. So I have joined MongoDB in twenty nineteen.
I am senior director as you mentioned.
And one of the big gaps that I almost immediately noticed was the potential risks in our SaaS security vendors.
So immediately, kinda, we started to investigate more into this area, and, we actually now build a a full team just focusing on SaaS security.
And I can further talk talk about what that means, but the primary goal is to make sure that we have a good handle of understanding of these risks.
Right. So and and and maybe that's a good, as you mentioned, people who are kind of less familiar.
What does software as a service mean, and what is how does that apply to to the companies today?
Right. And I think, that, the answer will also depend on where you are in your cloud journey. Right? If you're still based in your on premise, it may be confusing with all these terms and acronyms, and we, you know, cybersecurity world will have our will have our terms SaaS, PaaS, and OAuth, all of these different acronyms.
And, but but, also, I think the, the answer and the risks may may be slightly different if you are further along that journey. But yes. Anyway, so the definitions are important. Mhmm.
So so that way we can all talk about the same thing. So I'm gonna use, like, a pizza analogy or meal analogy. So if you're going to, you know, a place to eat, imagine that you want to buy a meal. Now if you're running on premise service, you will have to build your own oven, bring up tables, bring a knife and fork, you know, hire staff.
Just do the whole thing before you can eat. Mhmm. And that's what we call, like, on premise.
If you're going to a restaurant and they give you chairs, oven, and ingredients is, we call that infrastructure as a service.
If you go to a, you know, a a restaurant and that and they will give you chairs, oven, all of that, but you still have to choose a table and bake your own pizza. We call that platform as a service.
Okay.
And now for the final one, which is where my main focus is. If you go to, you know, if you just want to eat, you you kinda go to a restaurant, you just order food you you want, and you have to, and you have to eat it. That's what we call software as a service. Right? It's all about just having something available for you right now of your choice, and you don't have to worry about anything, on the background.
I I love that analogy. That's great.
And and but but, you know, if I'm gonna be more formal here, I would say that, we can formally define it as, you know, SaaS is a software as a service acronym and is a purpose built software for for for an application that is based in cloud.
You know, an example is Slack is a is an application is a chat software in the cloud, Or Gmail is, an email software in the cloud or, you know, or or perhaps a Salesforce, your CRM tool in the cloud. So all of these services are building for you. You don't have to worry about any servers, infrastructure, updates, and you just use the tool. Now if I compare this to the platform as a service, you know, they would give you access to the platform, but you still have to build your own software, patch it, scale it. And Amazon of that service is is, so sorry. An example of that service is Amazon AWS.
Mhmm.
So my main focus is on the SaaS world.
And I'm mentioning that because, you know, because all of these things are done for you, there are many assumptions about infosec, and how secure these these services are.
And because of ease of use, it's sometimes very easy to forget about an InfoSec risks here.
Right. Yeah. So so a lot of people do confuse all of those things and and, but they might be using, SaaS applications and and be familiar with some of these names, but not realize that that is what they're using. Can you maybe list a couple of some of the big players in the SaaS space so that people might already be using and and who who don't maybe have a a technical knowledge of what it is that the product, you know, how it's implemented in their environment, but they may have heard of it. Oh, yeah. We're paying for that.
Absolutely.
So if you think about your emails, Gmail, calendar, g drive, right, you could have Slack for your chat software. You can have Trello for your project management, Zoom. I mean, that's kinda borderline, but, technically, you could define it as a SaaS software. Sure.
There are many other. Basically, there is a SaaS tool for everything. There is a SaaS tool for payroll, SaaS tool for your, organizational charts Yeah. SaaS tool for, for your, HR tools, booking your day off, and provided it's an application in the cloud Mhmm.
The likelihood is it will be a software as a service if you are a regular user.
Right.
Of course, if you are in kind of a technical administrator, you tend to deal more with the platform as a service. Mhmm. But as a regular u user, I think the likelihood is that you are dealing with a SaaS app.
Right. And and there seems to be a little bit of a sliding, you know, scale. A lot of the the groups that I work within kind of evaluating their security stance and and and how they're doing things. It often comes down to the degree to which you can affect the configurations of the whatever it is that you're using.
Is it more platform? Is it more software as a service? Because you can be using software reserves and still have, you know, some configurations available there. But, I I think, that's less important than the idea that how do we how do we address maybe some of the risks?
How do we even understand what the risks are? Because we hear a lot about supply chain risk management.
What what does that mean, in terms of SaaS? What kind of risks, what kind of supply chain risks exist in the SaaS environments?
So I would like to give another kind of analogy here to better understand this. So if you think of a laptop on your desk. Right? It's made out of many different parts. Mhmm. Each of this part is built in a different country.
And, let's just say that there is an malicious adversary that that basically creates a backdoor Mhmm. In one of these parts.
So your so your laptop has hundreds of these parts, so it's very complex to understand if this part is being hacked Right.
What is the risk to my laptop? It could be that they can only see one or two pixels on your screen, or it could be that your whole laptop is absolutely hacked and there isn't and then you don't know about it. So this is very complex. There is so many moving parts. It's very hard to understand.
So so so now going back to the real SaaS world, I would kind of define the problem by this. Let's look at different SaaS organizations and their security levels or security maturity levels. Mhmm. If you think about Google and Gmail, I'm just gonna use them as an on for right. They spend millions on InfoSec research, on on InfoSec tools. They have minimum ten plus, very hard to get certifications.
They have very mature processes.
And, I I guess you could make an assumption that you would trust them more in terms of their security posture.
Mhmm.
And it is little bit less likely for a company like Google to be breached.
But on the but if I was to create a jack stop position of the opposite side, you might have some very small start up, where they just wanna build something fast. Mhmm.
Security is not really their priority.
They may not have the right certifications.
And very likely, they don't have as mature processes as the big players have.
Right.
So so I I I guess we could summarize here that, there are different tiers. Right?
You have the top tier SaaS providers, and then you have the low tier SaaS provider.
So now we can establish that.
We should probably trust less these small providers and be careful what data we send to them. I mean, that's so far, that's pretty common sense. I don't think I've said anything new there.
Right.
So, so many people will say, well, I don't care. I don't use these small SaaS guys or or I or I'm very careful what data I send them. But what I'm gonna be trying to explain here is that there is this new world of interconnected Yeah. SaaS apps.
And where the data is and how it flows, that all becomes really blurred really, really quickly.
And, so, you know, example here is the laptop.
Right? It it's, so going back to my laptop analogy, you can have a, a very small risk in SaaS applications, or it could be that this is such a critical component in your overall infrastructure that any bridge in that SaaS provider will create a very, very big risks. And I can talk more about these risk later on.
Okay. So do you well, do you see common points of risk between in SaaS environments?
Yes. So so I think, you know, I mentioned the to to different tiers and to to to different levels. Now let's say that you are using Slack in your organization as a chat software.
Mhmm.
You are using Google Calendar to make note of your meetings, and you have some kind of payroll, SaaS SaaS app application because you wanna pay your employees.
Right.
Now these three applications will probably have three different risks. So the Google Calendar may be more secure than the kind of very small start up payroll software. Mhmm. So now now imagine that one of your employees says, like, well, I wanna be notified in Slack when it's ten minutes before my meeting.
So what's the easiest way?
Well, you connect Slack Mhmm.
Into your Google Calendar. So so we we call this an integration or connection.
Right.
So and there are so many technical ways how how this can be achieved, but I'm gonna abstract it out. You basically have data flowing now Mhmm. From Google Calendar into Slack. So now we have a connection, and now that data is flowing.
Okay. Well, now you're in place. So, well, perhaps, you know, I want to know when my new payslip is available.
So so now you give your payslip tool ability to send emails on your behalf.
Mhmm.
And now, again, you have a connection between three different SaaS clouds.
Right.
So this is quite simple to understand because you are free. But if you are a medium sized business, you might have hundreds of clouds. Yeah. Marketing, sales, productivity, project management, communication. There is SaaS app for for everything.
Right.
So now we have this super complicated mesh of everything talking to everything with different level of permissions.
Right.
So that's the so that's the common point of risk. And and and I I think it gets worse because it's not just the data flow. Very often, you give some level of access or permissions to this application. So, for example, I'm gonna buy an application that will make my email more secure.
Mhmm.
Right?
And and and now you are given this application permissions to configure or change Right.
Your SaaS app. So it's no longer just data.
It's it's the it's the configuration. So now imagine this startup vendor gets hacked.
They have the same permission as the startup app in your other clouds.
So now, you know, we have to be worried about not just the data or but also the permission that you are granting this one SaaS application Right.
In the other SaaS application.
Yeah. This is, I I think, something that that is it can be difficult to understand because a lot of organizations don't even have a data flow diagram.
A lot of organizations haven't even identified what their sensitive and critical data are in their in their environment. And so, starting with, well, what is what are you protecting? Where is it allowed to go? What's allowed to access it?
And then what can access the accessor? You know, what what level of of permissions and so getting those kinds of diagrams I like diagrams because it's easier to understand where things are because if I look at a picture. But a lot of organizations don't even have that and so it makes it difficult for them to even, understand that there could be, some sort of a security risk to that information because they don't know what connects to it. They don't know as if they don't even know what if they don't know what connects to it, how do you even have the conversation about what are the permissions that that thing that's connecting can do to what it's connecting to.
Right? So, that's kind of one of the things that I look at with organizations is you're right. Things are so complex and so integrated and there's, like, almost a web of interconnectivity that without having some sense of what's connecting to what, groups are going to struggle to understand the the risk to their, that supply chain in the SaaS environments.
Right. And and, you know, I think the this is where the supply chain risk really come and take place. So you can have a one very obscure small SaaS cloud, and a breach of this small SaaS vendor can have much larger implication to your old chain, to your whole mesh. And if I was to to take it to the, like, very extreme level, these kind of attackers can now jump from SaaS cloud to SaaS cloud just by the point of breach.
Mhmm. Like, from that one breach, they can now jump around, maybe even eventually compromising your full mesh. And, and, you know, I think we have to be worried about not just SaaS application security individually, but as a set. Mhmm.
Like, our data in all of our SaaS clouds and all of the connections.
And that's kinda what I'm trying to raise raise raise awareness Mhmm. Is that being mindful of your SaaS connections.
So do you think that most business leaders have a a a good grasp of this type of risk? Or or is this something that's not really being communicated yet?
Well, frankly, from my experience, most business leaders, don't have the good understanding. So I think the answer is no.
I think the most common response that I've seen in my career is that, many people say that they don't have that many SaaS apps or they don't connect them. But my response to that is like, are you sure your your employee is not using Dropbox somewhere?
You know, like, what what if they just wanna make their job easier? And it goes into the wider issue of shadow IT and, like, how much do you know what your employees are using. And maybe they connect that Dropbox to the Slack because it's so much easier for the job, and it's just and it save them hour every day.
So that's kind of the one one area. And then the other area for kind of business leaders to be aware of is that on a technical level, these different integrations or connections are very complicated and very hard to understand even for skilled engineers.
I'll give you an example. Alright. So the Google API has one hundred and forty one API scope categories.
Now you really have to understand each scope Mhmm.
To to fully appreciate the risk that you're opening yourself into. So for example, one application wants to connect to your Google environment using one of these scopes.
And we really have to know what that scope means to fully appreciate and kinda evaluate the risk.
And that's just Google, one hundred forty one. Now let's imagine you have one hundred SaaS clouds.
They each have many different ways how to connect or or or APIs. Mhmm. So that's what, like, fourteen thousand different API connections that you that that you have to truly understand.
That's a novel. That's a novel of connections.
It's very hard on a technical level to understand this. So how can business leader understand where even on technical level is hard? Yeah. And then the I think the important factor for the business leaders is visibility.
Mhmm.
So, unfortunately, what I'm seeing in my experience is that many SaaS vendors don't consider this risk, and many SaaS vendors don't even allow you to see what they are connected into.
So you may say, oh, I want to see everything that connects to this payroll tool, but there is no UI. There is no kind of way how to find that out.
Right.
You have to do some very obscure technical ways, and sometimes you have to create a a support case. So so, basically, you have shadow IT. You have very hard technical understanding, and there is no visibility.
Right? And, and to make it worse, unfortunately, many of these applications have very strange default configuration or or or I'm gonna call it misconfiguration.
Not secure. Not secure default for sure.
And that and that's where I see very common. So we've seen an application which, by default.
So, basically, you you you can use this thing called webhook, which sends a data to a third party service upon every kind of event. So let's say after you receive every Slack message, you will send a a reminder to the I you know, like, that that kind of thing. So so, the, what we've seen is that, instead of just sending a reminders, they've been sending the full content of the message, the attachments, everything. So every time an event occurs, they, by default, send all that in information outside of their of their SaaS clouds.
And that is the default behavior, and you have to know about it to kinda turn it off rather than turning it off by default and only turning on when you need it. So so there are so many complexities here that you really have to have a good understanding. And as a business leader, you have to know about this issue in order to fix it. Right?
So this puts a lot of business leaders in a really difficult position because, first of all, they don't know they don't know what they don't know. Right? The the it's out there and they they don't have visibility into it. They are they are typically not the technical people, and are not expected to have that depth of technical knowledge. Right? But they need to understand enough of it to ask the right questions. So how do we help business leaders gain this visibility so that they can then help increase the security around these issues?
So, naturally, they should have, you know, an appropriately staffed cyber security team that is going to be able to evaluate these risks and kind of and explain them, in a right way.
But to truly understand what the SaaS cloud's, risk are, you need to know what SaaS clouds you are you are using Mhmm. In in in your environment. And we found that if you try to block too many things, the folks will just find a way, and they will just use it, without your knowledge. So it's better to have tool that you are are aware of, and you kind of understand the risks Mhmm.
And you kind of offer it to your to your employees.
You you should also probably create a process where if somebody wants to connect one SaaS cloud onto onto kind of a next SaaS cloud, someone should at least have a rough understanding of the risk. But because of the issues I mentioned earlier, it's not always clear cut. But if you have a good understanding that you that you're just sending calendar in invites as a read only to Slack, that should probably be okay. But there may be other SaaS cards which are asking for more levels of access and more data. That's but you have to know about this in order to fully kind of assess it. And and the last one is very hard and, which is how do you know when one of your SaaS providers is compromised?
Right.
And once they are, what access do they have? So that's more to do with threading the intelligence news, you know, having the right email contacts because very likely they will they would have emailed someone. But what if that someone is just the user? It's not a right person to kind of understand that email.
Right.
So you need to be cautious of what security sorry, what contacts you have in these in these tools. So but I think the one fundamental issue is knowing what you have in your environment.
So so I wanna go back a little bit to what you said about having a good team.
Cybersecurity is is confusing for a lot of people because if you just look at what the job postings are out there, people are asking for cybersecurity people that but they don't really know what they're even asking for. They don't know how to staff properly for the the the, issues in their environment. How what should business leaders be looking for? How how do they go about hiring people with the right skills for, these SaaS environments?
As for any cybersecurity issue, business leaders should should kinda look at it through the risk lens.
I mean, I work in cyber, so I shouldn't really say it. But cyber isn't the be all, and and end all. Right? You are, as a business, you are here to make money, satisfy your customers, and build trust. Right? So so we are a support function that can greatly help you with all of those things.
But you are the business owner. You are here to run a the business.
So Mhmm.
You know, you you need to be aware to put your priorities.
Maybe you're not using SaaS clouds, in which case, all all all of this may not be appropriate for you. So it's so so it's all all all about kind of finding someone who can rightfully focus your resources.
And, you know, in terms of how can they find the right talent, they should probably find someone who understand cloud and be and, hopefully, that person is open minded in terms of, how the data can flow and how we can create unexpected issues.
And it's also important to know your partners internally.
So, you know, we talked a lot about knowing what you have. Right. So maybe there is a team that already knows what they are using.
For example, IT team may be a great partner in helping you create that asset list of all of your laptops, all of your SaaS tools Mhmm. You know, all of the software.
And if you have really good relationship, which actually here we do, you can build those asset risk just weekly and can understand the risk. But it doesn't just stop there. You can go to your sales team, your marketing team. And if you have a good partnership, they will learn more about an infosec, but the but you will also learn about what tools they are using and perhaps where to kind of steer them to lower that risk.
So it sounds like you're you're so you have a lot of knowledge. You you've got some, an experience in this, and and it sounds like you're really applying this on your in your daily, weekly work at MongoDB.
Can you kinda give me an example of of how you're applying this knowledge there to make, your business leaders more aware and and help drive the the cybersecurity efforts there for SaaS?
The kind of research and the focus that we have in the SaaS was really eye opening for us, and it helped us in so many different angles. So MongoDB actually is a SaaS provider as well. Mhmm. We offer, you know, MongoDB Atlas.
So knowing what these risks are help us shape that and make it more secure.
We also started a dedicated SaaS security team with really talented folks who try to tackle and explore some of these issues.
And, and, lastly, you know, I think of a cybersecurity to be a business enabler. So we talked a lot about our data and how we can be risky from one SaaS cloud to to kinda, another SaaS cloud. But that's not the whole story.
Mhmm.
The other angle on that story can be that if you understand this data flow, if you understand the data you have available to you, right, not only you know your risks, but then maybe you can analyze that in, you know, info. You can, you know, create data analytics, and that can give you additional insights and eventually maybe even increase your revenue. Right? So so, sometimes when you do things right for cyber, it helps business grow and gain more information. So it's kind of a win win case.
That's excellent. So let let's talk about maybe some, specific ways to hold thirty third party, SaaS organizations kind of accountable or or find find ways to to know what their security stance is? Are there maybe some compliance or certifications?
Or what what do you ask for from a third party to know that they're really doing things in a secure way?
So that's a really great question. So the one of the first thing that we did here, we started a process that every new SaaS vendor, we do some steps to to check how secure they are. And, moreover, what we started to to do is we check every new connection now. So every new connection from any cloud, we understand the risk, the the data.
By going back to your question, what I would recommend you look at when you're buying a new SaaS product, you try to understand what security certifications they have. Right? Like SOC two type two, ISO twenty seven thousand and one. It it is not a guarantee they will not get hacked, but it's a but it gives an assurance that and kind of an an independent party, looked at their, processes and kinda confirmed that they are mature to to some level.
Right.
Also, you might wanna ask for the report Yeah. And, and see how responsive they are. They may wanna, like, you know, like, misalign the issue or or or kinda hide it all over the actual severity of it. So it really depends how kinda honest they are. Because normally, when they try to hide things, in terms of their progress and their certificate of patients, that is not a great sign.
Right.
What you can also look at is, how well known they are in the in the in the overall industry. Is this a business leader? Is it a start up? And I'm not saying you shouldn't buy start up tools.
All I'm saying is you should be understanding of the risks and make your own choices. Right? I mean, it is very likely that every company is using some kind of small scale SaaS tool that is perhaps not as big as, you know, as as our Gmail's. But but, you know, it's just about understanding, you know, those risks.
So if you look look at those three things, normally, that gives us a good kind of understanding.
You know, we see that a lot in the, credit card industry security, the p PCI world, where people might use a very well known organization that has all of their certifications in place, and they can hand over a an attestation of compliance that was performed by a third party, QSA, you know, all of those things. But we also see groups that are using, smaller service providers that might have only done the SAQ, which is more checkboxy and doesn't have the full verbiage of the of the reporting appliance. Or they might even use the service provider that has filled out their own and self attest self attested.
So these are the mechanisms that PCI uses. The three basic levels of a service provider are are the the done full rock done by a an, a QSA, an SAQ, which is the checkbox one done by a QSA, and then the self attestation, SAQ. And so each one of those, like you said, they come with a different level of risk for whoever is accepting it. So there are a lot of organizations, universities, for example.
A lot of times, we'll have a policy in place that says we as a university will not accept self attested, AOCs from groups because we they feel it's a greater risk and it is. Whenever you're attesting to your own security, that is your it's you you have a lower degree of assurance that they really are secure, and so you have to kinda weigh that risk against what the tool brings you. And so, as you said, you know, what are what are they offering? What is this third party, whether they're big, whether they're small?
What kind of reassurance are they offering you that you can really dig into? I love the idea of asking for, a a pen test or or even, you know, vulnerability scans. Some type of of, measurable, report that you can read and say, what are you actually doing to secure my data? So the PCR world kind of gives people a leg up because they have a mechanism.
In the healthcare world, in HIPAA for in the US, they we don't have that yet. We don't have any kind of, you know, hey, here's the third party things that you'd you could ask for. So it becomes a little more, creative in what is this exactly what access does this set have? What data are you giving them? And then what kind of information? I think I think the more data you're giving an organization, the more access you have. You are allowing that SaaS product into your environment.
The more reassurance you should get from them that they're actually keeping things secure.
Absolutely. And you should also be mindful of the scope scope creep. Right? So you might have bought a SaaS tool that just stores your logos, and you say, okay.
Logos are logos. You know, who my you know, who minds? But, the truth is over the course of one or two years, you might have connected that app into your Slack, into your Gmail, and so on. So so the scope may increase.
Yeah. Right? So so it's just kind of understanding of the risk as it maybe because risk isn't the same throughout the time. Right?
It's dynamic. It's change changes.
Right.
So it's a different hacker. So, you know, you should be reading doing some kind of periodic checks if if this is, if you have bandwidth.
Yeah. The more I the more I do cybersecurity, the more excited I am about risk assessments.
Analyze that risk and then make decisions based on it Because you you can try to follow somebody else's framework for addressing cybersecurity, but it's not going to be as effective as really understanding the risks in your specific organization.
Well, anything else you wanna to share with us before we wrap up this call?
So I think what, I'm trying to do is bring the awareness of the SaaS risk to the wider industry so we have more more kind of folks, more skilled folks doing some kind some kind of research, focus groups, just really, you know, bringing the facts that the SaaS can be a risk, and you just cannot trust that the vendor will do all of that security for you.
Right.
And, you know, most of the folks in my field are focusing on a platform as a service tools, a AWS, Google, and also others.
You know, does but the risk isn't just there. It's also in the SaaS world. And we need to understand the risk, research it more, and come up with kind of innovative ways how to lower that risk. And, hopefully, with a collective pressure, we can bring the some of the SaaS vendors who may not be allowing you to list all of the connections to kind of step up the game and kind of give us more tools to be more secure. So if there is kind of the overall message here is that be mindful of your SaaS and your SaaS connections. Yeah. But also, us as a cybersecurity industry, we should spend more time and attention in this field.
Right. When we don't know, keep asking. Right? Boris, it's been absolutely delightful speaking with you today. Thank you so much for taking the time to come in and talk to me.
Thank you. Thanks.
Alright. Take care. Thanks for watching. To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer.
.svg)
