Transcript and Video from Webinar: How to Protect Data and be Compliant When Embracing the Cloud

By Christopher Detzel posted 04-21-2020 16:58

  
Photo by Pixabay from Pexels

Take a look at the Webinar that hosted for Community Members here. 

Transcript from Ran's Webinar on How to Protect Data and be Compliant When Embracing the Cloud

Christopher Detzel (00:29):

Welcome, everybody. Thank you for coming to the community online webinar called How to Protect Data and Be Compliant When Embracing the Cloud.

Christopher Detzel (00:38):

I have a special guest today on, Ran Rosin. He's director of product management. So, I will not be presenting today, but I will lay down some of the ground rules. So let me do that first, but definitely welcome. Thank you for coming. We will have Imperva customers, some Imperva employees, and some Imperva partners. Customers, partners, and employees, yeah.

Christopher Detzel (01:05):

So just some ground rules, is that keep your audio on mute. We want to be open, so we want people to ask questions. [inaudible 00:01:16] We do hear somebody that's not on mute, so please put yourself on mute. If you have questions, please ask in the chat.

Christopher Detzel (01:25):

Additionally, I have created a post on the community, which I'll post here shortly in the chat, but if you have questions and you don't get to ask a question, or you don't get an answer, post it here, just reply directly. Again, I'll post that in the chat here shortly, and then I will push Ran to go and answer those questions. By the way, you might not get a lot of questions here, probably more so in the chat.

Christopher Detzel (01:51):

The other thing is the webinar will be recorded and we will share it to the community sometime next week. And we would like to do more of these, so I do ask employees to help. But additionally we are trying to get some customers to help with some of these webinars, to kind of get you engaged and involved. So if you have best practices that you would like to share, maybe it's only a 15 to 30 minute webinar to help the community, that would be really cool.

Christopher Detzel (02:22):

Again, we'll be doing more of these in the future. I have one about advanced bot protection coming up probably in about three weeks, but that's not 100% settled yet. So again, use the chats for questions. We will have about 10 or 15 minutes of Q and A at the end, so you can ask the questions in chat, but you can also ask them as well. So I'm going to stop sharing Ran, and I'm going to allow you to share, so that I can mute some people, too.

Christopher Detzel (02:52):

By the way, last thing I'm going to say is if you want to be on video, you can. On the bottom left, you can just hit "start video." If you don't want to be on video, that is okay, too. So I'm going to put myself on mute and let you take it from here, Ran.

Ran Rosin (03:11):

Okay. Thank you very much. Can you see my screen?

Christopher Detzel (03:16):

Yes. Yes, I can.

Ran Rosin (03:20):

Okay. Very good. So thank you everyone. Thank Chris for hosting us.

Ran Rosin (03:27):

What I'd like to do in this session is we just released a product called Cloud Data Security, and that we call CDS, which is aimed at protecting for compliance and security of managed databases in the cloud. And what I'd like to go here in the next 45 minutes or so is kind of to take you through the thought process of why we think there is a need for such a solution, what is unique about this solution when protecting data in the cloud and again, going into managed databases, it's not just another cloud. There is a different, it's a shift in the mindset and how things are working.

Ran Rosin (04:10):

And then we'll do a demo of the product, just to show you how it works [inaudible 00:04:14] And again, feel free, Chris here will manage the Q and A, but I would like you to be as much as engaged and not just [inaudible 00:04:25] started and hopefully we get your questions and go through areas of interest if you want, and not just me going on my own.

Ran Rosin (04:36):

So I'll start with what is called DBaaS. DB as a service is growing. The numbers are there. [inaudible 00:04:49] last year has grown 87%. That by 2023, 75% of the data will be in managed cloud databases and so on. But how much the numbers are accurate is one thing, but there is no doubt we see it and we see it in the market that companies are moving to more service-oriented services, such as if it's [inaudible 00:05:15] application side and managed [inaudible 00:05:17] and those types of things to manage databases. It makes sense. They produce quite a bit of the overhead. So it's a trend that I believe some of you are going to or thinking about going, so this is something we see a real trend and a real market with a real problem.

Ran Rosin (05:38):

Now if we're talking about the problem, there is this reality check of the cloud security, means that your data is protected. There is the shared responsibility model and in DB as a service, more responsibility basically move to the cloud providers. There's an attaching to the OS level that you don't need to do. There's an attaching to the database. But again, most of the errors have been on the customer fault. So there is a lot of queuing, a lot of things to do.

Ran Rosin (06:12):

Most companies go to a multi-cloud strategy, which means that there's several clouds and now you need to know what to do in each and every cloud, so it's becoming something to look at. And it's a reason to deploy and to do things and database as a service give you quite a bit of tools to do it, but at the same time, security for the compliance purposes can kind of go unseen in a lot of cases.

Ran Rosin (06:41):

So basically what we have here is DBS and again, I'll attach the demo later that support right now our DS. All the instances [inaudible 00:06:53] MySQL and we're going to add more and more managed databases. Again, some of you, not all of you, have our secure serve product. CDS is really focused only on managed databases. [inaudible 00:07:06] will not be probably like S3, Redshift, Snowflake, and so on.

Ran Rosin (07:16):

So now let's take a step back, and I would like to go through the process of why we think that cloud or managed cloud are different. So when companies move to the cloud in order to do business in everything and not just in a mix and shift way, where there's a lot of companies that are doing mix and shift. But really when you go cloud mixing or cloud-first, this is where you can look like the cloud services in a better way to achieve this with agility with most people, most companies are going to the cloud for.

Ran Rosin (07:51):

So everything, again, everything might be a bit of a stretch, but a lot of things are changing in the way, from the way that you design software to the way you deploy software to the way that you maintain [inaudible 00:08:03] and so on. So things like we knew the method, going from waterfall, going to Agile, DevOps architecture from monolithic to microservices, databases from mainframe to some more very specific database. So really everything in the organization or in the development cycle is changing. And we need security to all these security solutions that will adhere to those needs and changes.

Ran Rosin (08:36):

Sorry? Okay. I'll continue.

Ran Rosin (08:43):

So if we go one layer differ, and say okay everything is changing, but let's see how things are changing that affect database, even without going into the security itself. So when you go with the monolith, from monolith to microservices, what happens a lot of the time is that before you had one monolith and one or two databases underneath. Now you have each microservice, or several microservices, have their own DBs and they're task-specific DBs. For example, my log in microservice can have a SQL database because it makes a lot of sense. But if I have an order entry, it might have a no SQL database. This makes more sense with [inaudible 00:09:22] microservice and function.

Ran Rosin (09:25):

So we see really more databases and more variety of databases. This is the outcome of it. I always give the example of SecureSphere, our own data product. It is a monolith with one Oracle database underneath. CDS is, right now, something like 18, 19 microservices, with 10, 11 RDS [inaudible 00:09:49] under the root. And this is how a typical transformation from a monolith to a cloud [inaudible 00:09:56] looks like in those companies.

Ran Rosin (10:00):

So once you have all those microservices, doing it manually is just not an option anymore. You can go and deploy it manually, it just doesn't work. So everything really becomes DevOps-oriented, and then it needs to be API-driven. Everything needs to be with APIs to fit into the CI/CD process. And this is just another thing, just to fit into this very modern environment. And the third topic here is that [inaudible 00:10:32] where you go to the cloud, we take it for granted but not all products work like this, and really you would like to have a product that is completely elastic and can grow with your needs, and you don't have to think about the sizing and those type of things.

Ran Rosin (10:49):

So those are the three main, there's lots of other differences, but when we try to say how everything is changing, we try to see what in the deployment and in the design of the software changes and how it affects the database inside. And if we go one deeper, now how it really affects the security from this point of view, so in security manager, there's just more databases that you need to be aware of. And really the way that we challenge it is really with easy and fast onboarding of it takes you two minutes to onboard, if it is one or 10,000 databases, and we'll look at it, the elasticity.

Ran Rosin (11:29):

CDS is a SaaS solution, so the scale out and everything is completely automatic from the customer point of view. There is no need to worry about it. [inaudible 00:11:43] the security and speed of DevOps and maybe a better term here is "never be surprised." So here is the out-of-the-box compliance. The nature of the cloud environment, it's dynamic services because of the automation and because of the microservice, the scale out services go up and down in a faster way. And a lot of times you lose this ability.

Ran Rosin (12:09):

And if before asking to have provisions in IT in order to do something today, and asking [inaudible 00:12:16] function, it has an RDS in the backend and is [inaudible 00:12:19] internal, an internal application that it stores on PII and no one even thought about going through a process of approving it, in the way that they choose. And this is something that, again, with CDS we address this dynamic environment of the visibility and see if things are going up and down, we're aware and be able to do an out-of-the-box compliance and security.

Ran Rosin (12:49):

Another point of this is that most customers don't have all the expertise. It's not as if you're building an on-prem and then you went to one cloud, and most companies go to two or three clouds. We have triple the amount of security engineers. This is not the case. And every cloud by itself has quite a steep learning curve to understand how to configure it directly. So remember the first line, that most of the fault will be on the customer's side, and it's a lot of misconfiguration.

Ran Rosin (13:19):

And here is a solution that we are building that is embedded within the cloud. And if there is cloud services such as AWS Config and [inaudible 00:13:29] and Detective and [inaudible 00:13:30] we are harvesting [inaudible 00:13:34] of those today and we're continuing to harvesting in the future those specific logs in order to give you, the customer, the information that you need in order to protect and see that the database has a good security posture, and not just run after logs.

Ran Rosin (13:51):

Because if you go to cloud, [inaudible 00:13:52] just a lot of specific alerts that doesn't paint the complete picture for the needs that you need in the security. And as I said, most of the cloud strategy, today the solution, the solution was released three weeks ago, right now it works on AWS, RDS instances, that we're building more databases into it, and we're going to have both the [inaudible 00:14:22] support in the near future.

Ran Rosin (14:24):

I didn't look at the comments. Chris, there is any question that need to answer or to continue?

Christopher Detzel (14:32):

No questions as of yet.

Ran Rosin (14:34):

Okay. Good.

Ran Rosin (14:37):

So what is our vision? So our vision is really to have cloud native data security platform that enables organizations to manage and reduce cloud data security risk with agility and confidence. This words were written in a very specific way. So when we say "cloud native data security" we truly believe that in order to address all of the points that I specified before, to be able to work seamlessly with the CI/CD environment of the customer, to be aware of the cloud, to be able to scale out with the cloud environment as a dynamic environment. This is something that we really re-written everything in order to be microservices and to have a complete cloud native, to be cloud native.

Ran Rosin (15:26):

And where we see most of, and I touched on this a little bit before, when you go to the cloud, the speed of the cloud really where it becomes quite a bit of the friction between security and the agility. So companies want to be agile, they move fast, so going into the services and so on, and then security managers, a lot of the time, have to say, "No, let's stop here. I need to look at it. I need to be able to validate it. I don't want to be surprised. I want to tell you ahead of time."

Ran Rosin (15:58):

And really this is what with CDS we're trying to focus on, the ability to give security managers the power not to be surprised. So you will see. You'll know when a new database is been up, you'll know where some specific information is starting to flow in, without the need to manually go and configure and say, "I want to monitor this and I want to do it."

Ran Rosin (16:24):

And how we do it, and after this we'll go into a demo and I think it will be more interesting, kind of to show how we address the problems and what we do. But I kind of lay out the lay of the land. We looked at it as why managed databases are different than just a database and why an RDS instance is different than if I take a MySQL RDS, why it's different than an EC2, on a MySQL on an EC2, just because then we need two services. The way that you work is probably different when you work with microservices and you work in Agile when you work with DevOps so a lot of things are changing, it's not just I moved from one database to another.

Ran Rosin (17:08):

And in order to address those problems, we can divide our solutions to four main parts. The first part is discover. So what we're doing in discovery when we're doing an onboarding, and remember our solution is a SaaS solution, the onboarding is say something like two minutes, three minutes. We get access, we can read what is called the AWS Config, and on an ongoing basis we monitor the environment, and if there is a new RDS or someone stopped the log or did something, we can detect a change, and acknowledge it in the UI.

Ran Rosin (17:50):

So this is something that you will see. And again, it's an ongoing basis. It's not just a snapshot in time. The discovery's ongoing, talking about usability, not to be surprised. But if someone's been at the database, you'll see it and you'll be able to see if you want to automatically monitor it, report it for audit purposes, and so on.

Ran Rosin (18:10):

The other part of discovery is classification. Here we have our patent-pending classification algorithm. What we're doing here, we're not accessing your data, or your database. We don't have keys to the database. We live off the logs. We read the logs, and we look at the actual SQL and we see where it's going to conduct or reside. Either by the column name and the actual data that was accessed after [inaudible 00:18:40] had entered it.

Ran Rosin (18:41):

And this is, again, going on an ongoing basis. We'll be able to see once a database has been up, we'll detect the columns, we can say something and sense if a column is sensitive or not sensitive, and then we can change it. Again, we'll go and show everything here. But this is going again to the point of discovery and classification, where someone's [inaudible 00:19:05] the database sending sensitive information, you will know about it. You don't have to do anything in order to validate a classification or to start a classification scan.

Christopher Detzel (19:15):

Hey Ran?

Ran Rosin (19:17):

Yes.

Christopher Detzel (19:18):

Question. Is this only available as a SaaS solution, or can they deploy it within their cloud environment?

Ran Rosin (19:26):

It's a very, very good question. So we have the two option. One is in release, the SaaS, is in released and the other one is at the data space for design partners. But yes, any one of our customers that like to be a design partner can deploy it. We have a complete automation of deploying it at the customer AWS environment, with DuraForm, takes something like 17 minutes. And the same value is delivered via what we call the "local deployment." The same UI, it's the same code. We made it clear that we're not developing two different products. The local deployment and the SaaS are the exact same value. It's the same code, just a different deployment [inaudible 00:20:11] So just to reiterate, the SaaS was released three weeks ago, and what we call the local deployment option is in beta right now, and it's open for design partners.

Christopher Detzel (20:24):

Thanks Ran.

Ran Rosin (20:26):

Okay. Talking about audit, this is audit and policy report, this is more of the meat of what need to be done and we have it in CDS, the ability to schedule reports for audit purposes and policy alerts. Again, we'll go in and we'll see it. It will be easier. But what is important here to note that we don't, because it's a SaaS solution, we don't save any information on our end.

Ran Rosin (20:59):

All the audit logs are going to the customer S3 bucket, and it stays there within a team that just need the reports. But it is saved on the customer S3 bucket. We don't save any information for a longer period than what we need to. Most of the time it's a day or something, just in order to create an e-site, for its policy matching and so on. So this is the policy and report.

Ran Rosin (21:25):

And the last one is the insight. This is our machine learning and AI algorithm that, without any need for configuration, is able to help you reduce the risk of your databases. This is something where it's on a learning basis, it's create a baseline of a behavior. And then we can notify you on a specific event, not just an anomaly, but something that is really related to a data, to an event that has something to do with a database risk or a database breach that we might encounter. And again, I'll go into the actual demo and I'll show it in more detail, just a little I'm trying to go into the demo.

Ran Rosin (22:15):

This is a, before we go into the demo- [crosstalk 00:22:18] Yes?

Christopher Detzel (22:19):

Quick question. Can you elaborate a little bit more on the classification? If you don't have access to data, how can you determine if something is sensitive?

Ran Rosin (22:29):

Right. So we see, the way we work, and this is a good, and I'll go through it while I'm going through the slide and I'll answer this question. It's a good question.

Ran Rosin (22:38):

So on the right hand side is our platform, is the SaaS platform. On the left hand side is the customer and environment, the RDS and the S3 bucket. So what's going on when we say "onboarding," we get access to query data we have configged. And in read only, we can't write or change anything there.

Ran Rosin (22:55):

And we can specify how many databases you have, without starting to send any data. The RDS it would query, and the customer decides to monitor, we collect the logs. So there is a need to open the database [crosstalk 00:23:09] [inaudible 00:23:09] the database log. And we read the logs. Basically, the actual queries is going into the database.

Ran Rosin (23:29):

Looking at the logs will be statements like, "Insert this value to email." So think about it. Then we can see, okay, there is a column named "email," and we see a value. We sanitize it, because we don't need to see the actual value, but we know that this is an [inaudible 00:23:47] of an email, and we can say okay, and we'll see it in the product, here we have a column "email," and we look at the data. So by looking at the logs, and looking at many logs, by looking at the actual column names and the actual data in the query, we can start to do to classification on this line. So this is how we do the classification without actively scanning the database on all the rows and columns that it has. So hopefully I answered this question. I think we'll see it in the demo, where it will be clear.

Ran Rosin (24:18):

So going back here, once we start to monitor a database, or the customer says, "I want to start to monitor this database," we start to read the logs from the RDS instances. We're reading into our environment. We normalize them, so the different databases which is the SQL, which is the MySQL if it's in a real DB. If it's Oracle, we normalize all of the data, we enrich the data, we classify the data, we see if there is some policy matching and alerts, we go to the AI if we have any certain reports for auditing, we create the reports and basically put them back in the customer S3 bucket for each use, for quality. This is basically how it works. We're working on bringing more clouds. Right now it's work on AWS and we're looking to bring on soon Azure and GCP as well.

Ran Rosin (25:18):

This is the section of kind of me waving with my hands and telling you what is the problem and how we're trying to solve it, and what we're doing. Let me start the demo with one movie that shows the onboarding, how simple it is to onboard. And with the phone, and this is here with the computer, so you're probably not going to hear the sound, but I'll tell you what's going on. Tell me if you hear the sound. I don't think you'll hear it. Oh, maybe.

Christopher Detzel (25:50):

Yep.

Ran Rosin (25:50):

Can you hear it?

Christopher Detzel (25:52):

Sort of, yep.

Ran Rosin (25:52):

Maybe you'll hear it better.

Christopher Detzel (25:52):

It's not that good. Yeah.

Speaker 3 (26:07):

[inaudible 00:26:07] cloud data security, dashboard, and enter the name and account number tied to their [inaudible 00:26:12] In this case, AWS. Once they have clicked "okay" Imperva will redirect it to their AWS environment for all the required [inaudible 00:26:20] generated that CDS can call through. On the customer acknowledging these permissions, all that is left for them to do is say yes. Once that is done, we can begin to see that everything is deployed and the end result enables us permission to automatically begin the discovery process.

Ran Rosin (26:46):

Okay. Hopefully I'm back here. And Chris, it was kind of experiment, we could hear the voice, right?

Christopher Detzel (26:54):

It was okay. It wasn't great. What I can do is send a link out to everyone. There is a question.

Ran Rosin (27:01):

Okay.

Christopher Detzel (27:02):

What is the percentage of false positives for data classification, and can it detect data types like driver's license?

Ran Rosin (27:14):

So let me go into the demo, and we'll go over and you'll see it, how we classify the specific data types and what data types we have. And as for the false positives, I don't have the specific number, so I can't tell you what the ratio of false positive is. We do have a confidence level for each one. We have possible threat and sensitive, so it's not just a binary mode. And the customer can go and address [inaudible 00:27:42] false positive.

Ran Rosin (27:44):

We didn't get any specific from all the data that we have and the customer, it was not raised as an issue until now. And we're enhancing it all the time. So I don't have the specific rate of false positive, but it was not an issue until now, in the way we worked.

Ran Rosin (28:02):

So let me go here into the actual demo. [inaudible 00:28:12] CDS demo. So this is the access to the process of security. I'm going through the demo account that we have. And I will try not, it's configuration, basically. But I'll try to go on the interesting parts and not just go one after the other, just as a configuration.

Ran Rosin (28:39):

So let's start with the movie that we saw. So there is two ways of adding an account. One is really automatic, as you see. I just put the name and the account ID, click "okay." It's really fully automatic. There is nothing in the video that was skewed or changed. It's really open the AWS and do everything. And if a customer would like to do everything manually, it can be done. All we need at the end of this process is cross example to allow us which specific policies that we specify, to allow us to query the AWS log, the RDS logs, to query the AWS Config.

Ran Rosin (29:15):

But a customer can go here, create the policy that the customer [inaudible 00:29:19] and at the end of the day, give us the raw ARN and external ID. Those two are the identifier for the [inaudible 00:29:25] account [inaudible 00:29:26] and then we have access. The end result is the same. Either the customer is doing it, or we're doing it automatically.

Ran Rosin (29:33):

As is shown here, I can add, most customers do it, more than one account, and I can see everything in one view. It's not limited to one account only. So as I go back to the dashboard, the first time I onboard an account, I can see all the databases. It doesn't mean that I read the logs of all the databases. Here it's just that I can see in this customer account, those two accounts, 103 are asset.

Ran Rosin (30:07):

If I click on it, I can see the name of the account. Remember, I can have more than one cloud account. The name of the database, the type, the space. If I want them deleted and I can go and delete it from here as well. If the encryption is enabled or disabled, this is the method that we get. We don't need to query any logs.

Ran Rosin (30:29):

From this point on, this is where you'll, once you start to monitor the databases, at this point we start to query the logs. We pull them into our environment, and we can start to process them. I can go and do a sort here, and ask to sort by the databases that I monitor, and I can see here the different databases and the different databases that have sensitive information or possibly sensitive information.

Ran Rosin (30:55):

This is the point where I'm actually starting to monitor the database. When I said before a security manager, you can never be surprised, so if you go into setting, and you set those three to "on" this means that any new database is going to be detected, is going to be automatically monitored and everything will be applied automatically. Monitored, as I said, all the policy match, everything will work on it without the need of security manager to do anything in order to see if there is classified information in need or not.

Ran Rosin (31:38):

But if you go back to the dashboard, probably what is more interesting here is the sensitive data. So let's see how this works. Here is a database, Clinic Demo is one that I saved a few days ago. So I can see I click on the actual database, again I see our, what we see out of the database. It has no connection, real connection, to the actual user database from any query to the actual database itself.

Ran Rosin (32:09):

And for the question of what type of categories we have, there is either free text, personal, first name, state or province, zip code, and so on. I don't, I believe, national ID, I do believe we have a driver ID number. I have to check it. And you can see it here, I have 14 sensitive information that, based on the column name, here is the column name, I can see it here on the table in schema.

Ran Rosin (32:38):

So the column name and the actual data that's going to show, we could only show enough of it, we can say in a confident way that this is column named "phone" there is actually phone numbers in it. And if I go to "possibly sensitive," this is where we still don't have enough confidence to say, "Oh, this is sensitive." But the more data that we're going to see, very likely that possible sensitive will just move either to "unclassified" or to "sensitive" data.

Ran Rosin (33:12):

So those are the, I think there is interesting there is, I played with it even yesterday, so let's see here. There is a comment. You can see "comment" here. The comment at the beginning was just a free, was just a table without any specific information in it, without any sensitive information in it. And I started to send sensitive information into it in some script, and automatically after I sent enough sensitive information into it, it moved to sensitive data in order to show that this is sensitive data, although "comment" doesn't say too much about if it's sensitive or not, so it is based on the actual data in it.

Ran Rosin (34:02):

As I said, if I think there was a mistake or a false positive, I can go into here and mark something as "non-sensitive," and it will move into here. And this is basically on the sensitive data portion. Again, this is on an ongoing basis. So even if someone is altering the table, and changing and adding a column, even if this comment that was a comment at the beginning, but someone started to send some sensitive information to it, we'll detect it and it will appear here. And here there's some more of just graphs on the number of events that are going into the specific database.

Ran Rosin (34:42):

So this is about discovery and classification. I'm just looking here. Chris, I'm kind of asking you, because with all this, so a lot of the time I don't know where, if there is questions or not. So I'm- [crosstalk 00:35:00]

Christopher Detzel (35:02):

I'll stop you every time. No worries.

Ran Rosin (35:04):

Okay. Very good. So the other thing that we talked about, remember, we had those four pillars, right? We had discovery, we had classification, so with our discovery we [inaudible 00:35:18] classification. Let's go into policies and reports. So report is the most basic one. This is where we, and again some of you are [inaudible 00:35:31] customers so there is an ocean of audit policy. Because we read all the logs, or we monitor all, we read all the logs from the database, and we save them in the S3 bucket. As you can see with all the events here.

Ran Rosin (35:46):

But then, for audit purposes, you would like to have for PCI or for [inaudible 00:35:52] specific reports that are run on a daily basis or a weekly basis, and you have them when Mr. Auditor comes and you can say, "Yes. Do you want to see all the failed logged in? Here are all the failed log in." So to create those, we just go to "reports," we give it a name, and there is a list of 12 type of reports. We're going to add more and more reports, now we're working on a dynamic report system. You can define it yourself.

Ran Rosin (36:19):

Some of the reports don't require any information, for example, log in and log out. Sorry, log in and log out. I just have to give it a name and schedule it. There is no need for an input on my end. But if I go to a non-DBA performing privilege operation, this is where I do need to, in the comments [inaudible 00:36:39] put the DBA users that will match in the actual lookup table of what privilege operations are, this is something that we have, at least that we have behind the scenes, so every user that will create in this case either in that other table, drop table, create in someone, will have a match and will go into the report.

Ran Rosin (37:03):

I'll go back to the report. Each report can be scheduled. And either it succeeded or failed. What does it mean, succeeded or failed? Remember, this is in your, in the customer S3 bucket, this is a testing environment so we're failing it automatically so some of these failed due to permissions, but once it works, you shouldn't see any partial succeeded or failed. It's basically taking the Athena and running a specific report on your S3 bucket in order to have those reports that you need.

Ran Rosin (37:35):

So if I go to the failed log in, I can see here that I created this account. This is the link to the actual report that was made. And if I click this one, now it will not get any because I'm not in my AWS environment, but it will open just where the file sits within your S3 bucket, and it's just a CSV file that you can open in Excel that is the actual report with all the fields for this log in and log out.

Ran Rosin (38:06):

And you can see here, if you want to take it because we're embedded within the cloud, and it's important, we didn't want to spend time developing services that the cloud providers give us almost for free in a really good way. So all the reporting, instead of writing a reporting engine, we decided to use Athena and when we run we basically will likely run, with BigQuery there is no need to re-develop those. So you can basically go into here, copy the actual query that we run in the Athena, and run it yourself in the SB9 [inaudible 00:38:40] for just something.

Ran Rosin (38:41):

So there is no magic, re-opened platform here. We're just trying to bring the knowledge that we know of what our [inaudible 00:38:48] operation. What are, with the user, what is the sensitive data and be able to do reports on sensitive data and so on. And again, the scheduling is quite simple. I can make it do daily reports or weekly reports. Unsubscribe, subscribe. And this just run automatically. Most customers don't go into screen too often. It's something that they set up and know they have the reports. S3, you're not going to have an issue with this space there, and you can manage the life cycle through Glacier and so on if you would like even to reduce more the storage costs. So this is about reporting. It's quite straightforward.

Ran Rosin (39:30):

The other one is policies. So policy, is a good way that one of our engineers likes to explain it is kind of like TSA. "See something, say something." We do see a lot of customers that they kind of mix between policies and reports. Some of the reports use the policy. But this is more, we can't say "real time." Remember this [inaudible 00:39:51] we are not a proxy. Maybe it's a good form to stop for a second and say that we go to such a solution if you take the proxy way or the non-proxy way, there are solutions out there that take the proxy way. We believe that the proxy doesn't really fit with the cloud environment to the point of failure. Failing is an issue. So we decided to go with a no-proxy.

Ran Rosin (40:17):

So again, so here it's close to real time. It's in a matter of seconds. And I can go in to edit one of those reports that I did in here. In this case, it's a policy of active DBA, unauthorized DBA read. I have two tables that I have to fill in. One here is the table name. So here I want it to say, "I know that treatment is a table that I would like to pay close attention to." And this is the user that I would like. So it means, in theory, we should never query "treatment." There is no reason for a need to query "treatment." And if it happens, trigger an alert, and in a second I'll go back to and I'll see what we can do an alert to follow the action. So those are the policies.

Ran Rosin (41:13):

If I go in to add a new policy, it's quite easy. Right now there are four types of alerts. Either unauthorized from a source IP, if I want to see from a different, specific source IP, something, I will send the unauthorized DBA which we saw, that re-targeted account usage. And again, this is something that we're really now working on creating more dynamic or custom policies that we'll be able, any customer will be able to create his own set of rules based on events, tables, IP, and so on.

Ran Rosin (41:47):

Once an alert is triggered, there is a screen here called "policy alert." As you can see here, my alert DBA activity treatment, on treatment. If I click it, I'll be able to see here some of the parameters, the table name it was active was "treatment," and here it has a query, looks like. And you can see that the question mark is when we sanitize the data. We don't show any specific emails or any data like this- [crosstalk 00:42:16]

Christopher Detzel (42:15):

Hey Ran?

Ran Rosin (42:17):

Yes?

Christopher Detzel (42:18):

Quick question. Any integration with LDAP or similar to populate the list of privileged users?

Ran Rosin (42:24):

A good question. So no, but everything is in API first, so our goal, and I really, because it's a SaaS and it's moving fast, I need to speed forward here. The point here is that with API, people will be able to populate the list or to upload a list like a file list of CSV. But right now, it's not connected to active directory. Again, it's something that we will look at and if needed, could be on the roadmap. We know how to do it, we did it, we just need to see on the different clouds what makes the most sense. Good question.

Christopher Detzel (43:09):

Thank you.

Ran Rosin (43:11):

So those are here. I can see the actual events. Again, so event can be a critical or a non-critical. And what is interesting here is that a lot of theory in SecureSphere or in other product there is a funneled action here [inaudible 00:43:28] log because a lot of the time when they have a policy alert like this, I would like to do something with it. I would like to put it in my workflow, either to open a ticket on ServiceNow and send it into a [inaudible 00:43:39] there's lots of different ways to integrate with it and we thought that the best way is if we live in the cloud, really be open and use the cloud platform as it should.

Ran Rosin (43:48):

So if I go back to policies, and I would see [inaudible 00:43:52] and I'll go to add it, at the bottom I can specify and follow the action, and in this case, what it's doing, it's writing into a SNS Pocket. So in AWS you can open an SNS Pocket, and give us the ARN to the SNS Pocket, and we provide to the SNS Pocket. What this gives you is really the, it's a way we open our platform and tell the customer, "Now listen, do whatever you want with it. It's very easy with SNS to assign an email, to assign a push notification, or to run a complete lambda that is doing some magic of enriching the data and then you do a ServiceNow, sending it to a theme and so on.

Ran Rosin (44:40):

In this case, we wrote and we can share a simple lambda that, in this one, that is subscribed and put in this alert in S3 bucket. So then it can be triggered from there to something else. It's completely scalable. You don't have to worry about scale. SNS is a very much robust service by AWS. It adheres quite a bit. And again, inserting an email is quite easy as well to be able for funneled action.

Ran Rosin (45:09):

Now again, this is something of how you, being a cloud making solution, we use the cloud and we're not trying to reinvent the wheel, where everything here we can use something in the cloud that better fit the cloud. Design pattern we'll continue to do so and this is a good example of how customer really likes this activity to use the cloud here. This is on policies and alerts.

Ran Rosin (45:34):

The last one is the security incidents. This is, if you remember we talked about four pillars. Discovery, classification, policies and reports. And Insight. Insight is our machine learning algorithm. We're adding more and more to it. Right now, probably the most useful one with three algorithms already in it, the one that is quite nice is "multiple consecutive failed logins." Basically, it was good for a tier database.

Ran Rosin (46:05):

If I'll go into it here, I didn't have to set anything up. So we learn the base activities and then we see something in, we look for this specific anomaly of brute force. We're not telling you we found an anomaly. We don't believe that we should create more alerts. You go to the cloud, you have enough alerts to worry about. We want to give you something concrete that you can do something about. So this is something that here you can see "total failed logins" is 303, and it happened in a minute and 10 seconds.

Ran Rosin (46:41):

So we created an alert and group it all together, and we can show here that the [inaudible 00:46:47] the name of the user is [inaudible 00:46:49] and what the error is. So this is about the incidents. There is more incidents you can see here that it's set by major, minor, and so on. The minors are ones that we see something that you might want to know about, like, oh after a week that we've looked at the system, now we see a new user in the system we didn't see before.

Ran Rosin (47:15):

So we alert unit or a specific user going to a database that you didn't need to go before. Again, what we're trying to do at CDS in general is to try to make it as automatic and as, almost as serve-service as we can, in order to get this compliance out of the box, security out of the box, and do more and more things automatically, where we can either the machine learning or just by very easy setup.

Ran Rosin (47:41):

So if you go kind of back, remember if I go and I put settings here, all sitting on "on," and I go and I set some policies that I want and some basic reports, from this point on any new database that will go through the system will be automatically monitored, automatically will be classified, and the reports and the policies will automatically be applied, any security incidents, without the need for me as a security manager to do anything specifically, actively, in order to secure my environment.

Ran Rosin (48:18):

So we try to do everything by default, everything automatic, because you just believe that the dynamic environment of the cloud just is not real, solution need to be built to be very dynamic in that way, and not asking a security manager to run after it asking and see that, oh, I need to do this and I need to do this. Or ask them to change something in the way they work in order for you to be able to address the security and compliance piece.

Ran Rosin (48:44):

I think that that's it, basically. There is a bit more things, but I wanted really, want just to talk about CDS but just to talk about why cloud database is different and to show people with CDS how we address those issues. And this was the focus of this session, and I hope it helped. I'll be more than happy to answer more questions or you can-

Christopher Detzel (49:13):

Hey Ran?

Ran Rosin (49:13):

Email me. Yes?

Christopher Detzel (49:15):

Yeah. If you're giving out your email, just put it out in the comment section. But I do have a question, I think. It says, "We are saying that no agents are required to be installed." Is that what you're saying?

Ran Rosin (49:31):

Yes. So in the SaaS version, there is nothing that need to be deployed. No agent, nothing. All there is to do is you saw the movie, the one minute movie, it's actually what it takes. One minute. It's a cross account role, and we can start to monitor and do all the magic that we saw right now. There isn't any small thing that I needed to do here in order to make it work. This is how it works. On an ongoing basis, no agents, nothing. I don't remember if Salesforce's [inaudible 00:50:03] has this slogan of "No software." So this is kind of "no agent." There is nothing to be installed. It's complete SaaS solution.

Ran Rosin (50:09):

On what we touched at the beginning, on the local deployment, there is still no agent. All there need to do is to install this solution. Deploy it's more than install. In the customer environment, you see exactly the same menus. It acts exactly the same. Still need to onboard every single [inaudible 00:50:27] it's just no data leaves the customer environment. No logs leave the customer environment. But even in this deployment, no agents, nothing. Nothing need to be installed on the actual database, or in the proximity of the database, in order to start to do this. The policies and the security and the compliance.

Christopher Detzel (50:51):

Thank you. Can we forward the security events to a SIM, such as Splunk?

Ran Rosin (50:56):

Yes. Yes. Absolutely. And this is where I said that we set it with the SNS Pocket. And the SNS Pocket can have a lambda that just forward it to a SIM, to an S3, enrich it, and then send it to a SIM. Sometimes you want to enrich it maybe with data that you know about it and send it to a SIM. This is really the beauty of the SNS Pocket that it will make it completely open. We have a Web HOOP. Basically there is a Web HOOP for each policy alert, and you can do it whatever you want with it. Again, Splunk, S3, ServiceNow, all of the above. And so on.

Christopher Detzel (51:31):

Also, can it be a hybrid solution?

Ran Rosin (51:33):

So this is a good question. No. So we are focusing on managed databases and the more we go, so RDS is one type. We're looking into how we protect S3 bucket. Redshift more of data links. Everything in managed database. And we think that this is a bit of a different use case, so we have our current secured serve product work on databases that are deployed on an EC2. Right now, again, we can do it a lot, but right now the focus of CDS is really we think there is a big problem to address there, with the focus on managed databases, and we wanted to solve this problem really well. So right now, it's truly, CDS is as a name suggests cloud data security fully focused on cloud managed databases.

Christopher Detzel (52:33):

As of now. Quickly, any roadmap for DBA AS providers like Snowflake, Mongo DB?

Ran Rosin (52:46):

Yeah.

Christopher Detzel (52:47):

[crosstalk 00:52:47] 600.

Ran Rosin (52:47):

Yep. Yeah. So the roadmap, it's a good question. So let me see the question. So the roadmap right now is we're adding, the one that is really on the radar is Redshift. And because we're SaaS what we're trying to do here, there is enough value. It's out there. Customers are using it, and we would like, we're developing really SaaS so there isn't going to weekly deployment. Again, microservices, all the things I talked about in deployment, we can even deploy several times a day. So we're trying to be very close to customer demand, and see that we're developing what customer needs and we're following it. So right now, Redshift is the first one that we're working on.

Ran Rosin (53:27):

But then we have DynamoDB, a lot of people are asking for. And we're looking into Snowflake and S3. And S3, we're talking about S3 from an application applicative background. So what we see, we use it as well, a lot of companies use S3 as a data link, and then a lot of people use Athena to query the database. And no one really knows what's going on there. So they have a VI team that query with Athena in S3 bucket. It might have sensitive data, which kind of [inaudible 00:54:00] a lot of companies there. And this is another area that we are addressing in the near future.

Ran Rosin (54:05):

So those are the main databases we work on right now. MongoDB [inaudible 00:54:10] is a managed database. Again, it changes because we're not a proxy and we're reading the logs, should be in a lot of ways easier, and we're trying to be the case to be easier for us to support more and more databases faster and faster. But the roadmap right now, as I said, is Redshift, S3, Dynamo, and we're starting to get quite a bit of Snowflake as well. And those are the things we're looking in AWS right now. And then we have another cloud, which is likely going to be Azure this year. And again, we're trying to see if we match what customer need and we're debating between GCP and Azure, but it seems like Azure has more potential and more customer pull for.

Christopher Detzel (54:53):

Does it integrate with attack analytics?

Ran Rosin (54:59):

It doesn't integrate to attack analytics, because attack analytics, before I answer, attack analytics is doing something different. Attack analytics is doing plastering for application security attacks and just doing a smart plastering there. It was not designed to work on data security events, so this is why it's not, for example attack analytics can work on SecureSphere [inaudible 00:55:30] but it doesn't work on Secure [inaudible 00:55:33] because it's completely different algorithm.

Ran Rosin (55:34):

The more relevant to attack analytics is because we have DRA, data risk analytics, this is not the same, but this is our AI machine learning to our secure for them and the insights that we see here, this is kind of the beginning of trying to get the DRA capabilities into this process. There is an insight, but again, it doesn't translate one to one. So we're looking to see if attacks that we know that are happening on through the on-prem, we can take them and just forward them to the cloud, but we just want to see that they make sense, that they look the same.

Ran Rosin (56:17):

Because the machine learning is creating a profile and would like to see the profile of the behavior of those on-prem environment is similar to the one in the cloud. In some cases with, in some cases without them. But this is one of the insights. So a longer answer about attack analytics, but the short answer is no.

Christopher Detzel (56:36):

Great. That is all the questions. So Ran, thank you so much. This was really informative and really good. There were really good questions asked, so thank you so much.






#CloudDataSecurity
#video
#Webinar
0 comments
1320 views

Permalink