Hello everyone and welcome to inside your cloud databases session. The truth about your data security posture my name is Mor Manor head head head head head head of innovation operations to share with you with some insights about the importance of cloud data security posture, as well as presenting with you one of our latest innovations called Imperva Snapshot, a patent pending technology that can provide robust insight about the cloud data security posture of your databases. What we have on today at Xenja is a little bit about the current state of cloud and data security. Then we'll jump into snapshot technology and the importance of cloud data security posture. Then we'll move into more technical part of the presentation, switching gears, and we'll talk about the pattern pending technology itself. What are the components that Imperva snapshot tool runs in the cloud environment? And we will wrap up the session with some real life example, the latest findings by cloud operators and users just like you who run Imperva snapshot tool in their environment. And what are the insights and visibility, the type of visibility that they gain after running the tool in their environments. Talking about cloud, and specifically about the importance of data, I would like to focus on those two numbers that I believe can reflect the current state of cloud misconfiguration and data security. If you're looking in 2020, over 31 billion data records have been compromised, while the majority of which were due to cloud data breach. This is a very high numbers that emphasize to us the magnitude of the importance to protect our data, specifically the type of data that resides on cloud environment. And if we look at the other number, 99%, this number form gardener's prediction that indicates that by 2025, 99% of misconfiguration that probably could lead to some sort of data breach would be due to customer fault. So, meaning the majority of those misconfiguration can be addressable had we have the correct visibility and understanding of our cloud security posture to put us all on the same line understanding what are the devastating results of cloud data breach and breaches in general. I do want to share with you a few examples from recent years. For example, though hit the news are indicates for small misconfiguration will leads to devastating results due to the data breaches in those cases. And the first is from a marketing firm that back in June 2019 had over 340,000,000 personal records leaked due to a simple cloud misconfiguration. The database itself was configured to be publicly accessible and then the bad hackers put their hands on the databases. And that leads to a very high volume of records that have been exploited and exposed. Another example is from a financial firm back in July 2020 that 7 million exposed users usernames and passwords have been exposed due to again, could be a minor misconfiguration. The databases was unencrypted and the s three bucket was publicly accessible. Had a security operator had known about those issues, I guess it would put the necessary security rules to address those. But that lack of visibility cloud lead to those scenarios. Data breaches with devastating results. And with those stories in mind, and understanding that visibility is in a key into your cloud environment, specifically understanding the type of data that we have resides on our databases, we've thought about what are the key insights and visibility cloud operators needs to have on their daily basis to understand the security posture of their cloud environment. And those are the key pillars we're thinking are necessary for every cloud operator. We would like to know what is the security posture of the cloud environment and the selected databases. If we have any vulnerabilities, are there any software updates required? And if there are any misconfiguration on the specific databases and the environment. It's also really important to understand what is the type of data that we have resides on the databases, do we have sensitive data on that? Who have access to the database? Regarding permissions, do we set remote access and what are the group policies applicable on the selected database. And lastly, in terms of compliance, it's really important to know what is the compliance level as well as if we have any PII or PCI information on a specific database. With that in mind, we thought about an innovative tool that can provide visibility into those three main pillars, misconfiguration and bad practices, known vulnerabilities and specifically to provide visibility into data, the cloud data security posture indicating what is the privacy and compliance and data classification of a database in your environment. For that, we came up with Imperva Snapshot, a patent pending technology. It's important to know that at the moment, the patent pending technology and the tool itself is dedicated for AWS environment and RDS databases only. And what we have in this environment is the fact that we don't need to any credentials of the database, the selected databases that a users want to scan. The tool itself accesses a snapshot of a selected databases only. We manages to reset the master password of the snapshot and open it on an isolated VPC. That means the tool is production safe, doesn't have impact on your production environment, and all the data is also resides within the specific tenant and account of the user. We also don't need any credential, the ability to reset the master password and to open the database. The snapshot database on an isolated environment allows us to gain a lot of visibility into the databases itself and the data resides on the databases. When a user run impaired a snapshot by the end of a scan, he receives a PDF directly into your inbox and I do want to share with you the main highlights of such a report. First and foremost, the user resides a cloud data security posture high level executive summary when one can learn and understand the security posture of the selected database, it will know what is the risk level. If there are any misconfiguration of the databases, what are the main vulnerabilities of the database as well as the sensitive data found on the selected database. A users can also see what are the top insights and main acts for mitigation in order to have a solid security posture on the selected database. As we go through the report, we'll have a deep dive section for each one of the categories for permissive configuration and best practices. A user can see what are the security risks, what are the assessment tests that have been run and what are the outcome of each one of those. And obviously all of these are being listed based on the severity level. In terms of known vulnerabilities. The user can see what are the type of vulnerabilities that have been found that the database is exposed to being labeled by years later the year. Obviously it requires a patch. Probably that CV is being exploited and exploited somewhere in the wild, but the user really can understand what is the current states of the database and what is the security level of the selected database that has been scanned. And lastly, in terms of cloud data security posture, imperfect snapshot provide visibility into data resides on the databases, making the labeling of the sensitive data records that have been found. What are the categories of each, what are the total items and on which column and what overall number of columns are including sensitive data. The user can also see the compliance level for the selected databases. Understanding what is the compliance degree for the selected scan. Understanding what the tool is doing is great. You get an interesting insight and a quick posture of the selected databases as well as visibility into the data. But I do want to take you through the journey of how the magic happens and what happened behind the scene. When you're running parava snapshot, it's important to know that the entire process is fully automated. As mentioned previously, currently the tool supports AWS environment and RDS and Aurora databases, and I do want to take you through the phases of what is being triggered and what tool that we use when running parabas snapshot. So really starting that automated process with basic prerequisite, obviously we need to make sure that the selected database is RDS or Aurora and we need to make sure that the specific RDS has an available snapshot. Without the snapshot the scan cannot be completed. This specific snapshot is then being deployed in an isolated VPC and for that we're also checking that there is an available VPC to deploy that snapshot into. Once those prerequisites are done and being checked, I do want to take you through the journey of provisioning in flow and what are the basic templates that we use on the cloud formation. It's important to know that in this point all templates are publicly available, so imperva snapshot tool is free and production safe and we have full transparency to help our user to understand what is being run in their environment while running imperfect snapshot. So the root templates actually start by collecting all the key parameters and is the base template to the other templates that are being used. The setup template and the installer template the setup templates start with verifying the prerequisite from the slide before and making sure that the selected database and the DB identifier are on the same region. Then moving forward into the installer template where all lambdas are being set to run pervasnapso tool itself and to start assess the database and route all the relevant tests. So what lambdas are being created and what are the functions of lambda in this process? The first and foremost is the sandbox or lambda that acts the devsec expert in the environment. We can say it creates all the networking resources, it creates the next lambdas, it restore the selected databases into the isolated vpcs and it delete all created resources by the end of the process. So we make sure that everything is running on an isolated environment that will have no impact on your live production environment. And by the end of the process the isolated VPC as well as other lambdas and templates are automatically deleting themselves that they will have no impact on your environment. The next lambda is the scanner and the key function of the scanner is pierced to reset the master password of the restored RDS. This is one of the main part of the patent pending of Imperibus snapshot, the fact that you don't need to insert database credentials at any time. The scanner Lambda delete its master password and then once you deploy it on the isolated VPC, we have full access to the databases on the isolated environment to run all queries and assessment tests. It ran the scan as well as classification, and it sends all the data into the last lambda, the reporter that collects all the results from the scanners and also generate a PDF report that is being sent to the user. So by the end of that process, a user who runs Imperva snapshot in their environment received that Imperva snapshot PDF report to gain visibility into the cloud data security posture of the selected database. Understanding why the components are great, but I do want to take with you a step by step through the flow and what is the process and what's happening through an Imperva snapshot scan. And if we start with the installer stack who creates the sandbox lambda, then it creates the isolated VPC where we can deploy the selected snapshot. Obviously it's based on the fact that it all matched the prerequisite and the selected database has an available snapshot to be deployed. Once the snapshot is being deployed and being restored into that isolated VPC, we create a security group from the sandbox or lambda in order to make sure that there is no Internet gateway and all assets have capabilities and yam rules only to do relevant activities and functionalities to impair the snapshot. So the entire environment is isolated and each one of the resources and the Yam rule created during the process have access and permissions to do activities only on the isolated environment and on the isolated components. Then there scanner Lambda start dire assessment and report all insight into the reporter who then send that final report to the users with the impairment snapshot final report I mentioned through the process a few times the importance of production safe tool obviously for cloud operators to run a new tool in their environment, that might be tricky at times, but we do have full transparency of what Imperva snapshot is doing and we did want to make sure that this is a really production safe tool. So as mentioned before, we have a full transparency of imperfect snapshot and it's code and it's available on our GitHub project. But specifically regarding the precautions that we have taken developing the tool, we made sure that the snapshot is being restored on an isolated VPC. New security groups in the routing table are being created and no Internet gateway is in place, so nothing can come in and out from that isolated VPC. So also important to know that only resources that were created during that process the new security groups have access into so it cannot have access into other resources previously, resources that have been created in the environment. Another important note as part of the patent pending technology of impairment snapshot is the fact that we don't need an admin permissions to run the tool. Security admin or cloud tech operators who want to know the security posture of the selected database can simply run the tool. No need to admin permissions and no need for credential for the selected databases. This is a real game changer that can make your life easier understanding the current security posture of a selected databases for the final part of the presentation, I do want to share with you some examples based on recent scanning and findings from Imperva snapshot scans by cloud operators just like you who run Imperva snapshot in their environment and share with you some insights, common insights that have been identified against all those users who came up to us seeking more information about impaired snapshot and how to mitigate the security gaps in their environment. So the first example referred to into a marketing organization that had a few misconfiguration in their environment. Imperva Snapshot has identified that there were a few misconfiguration about excessive permissions. The database itself was not encrypted and a snapshot of the databases was publicly available. Think about it to yourself for a second. So a bad act has access to a publicly available snapshot and the database itself is not even encrypted. Easy win for the bad guys. Specifically, the databases was also with over 200 known vulnerabilities, so this is a really bad shape in terms of security posture for the selected database. Now, if we make the correlation in order to understand what would be the ideal game plan and what we need to mitigate, then we have the added value of cloud data. Security posture and Imperva snapshot indeed indicate what is the type of data and sensitive data that have been found on the selected databases. So over 1.2 million email addresses have been stored and resides on the database. Over five hundred k of personal identifiers and over 100,000 mobile phone numbers have been identified in that scan. So within those misconfiguration and with that type of sensitive data resides on the database that could really have been and become another one of those base scenarios of a massive data leakage. Another scenario from a financial firm also points out a common misconfiguration that we see in an example before databases that was not encrypted, a snapshot was publicly available. We also have seen that the specific databases had the subscription disabled for security group updates, so you don't get alerts of any security groups for database specifically, we have found impermanent snapshot has identified 500 passwords, 100 credit cards and almost 2000 mobile numbers. Again, a high amount of sensitive data within those misconfiguration in place can be easily leaked into the bad guy. And the last example that I want to bring you is from a cloud service company that also, as you can see, there is some sort of a repeating motive. The type of misconfiguration, a misconfiguration that lead into excessive permissions, a database that was not encrypted, and a publicly available snapshot, the specific database, have been vulnerable to almost 100 known vulnerabilities. And look about the overall sensitive data that have been stored there. 20,000 addresses, 20,000 email addresses and close to five k of personal data. Make the correlation between the security states of the databases, the misconfiguration that you have, and the sensitive data being reside on the databases. A cloud operator can come with a game plan and decide what database is the top priority to be addressed and protect and address the security gaps that have been found. And this is the key thing by Imperva Snapshot, making that correlation providing that visibility between misconfiguration, understanding the security posture of the databases, and what is the type of data that is being resides on the databases. And based on that, you can come up with a game plan to address the security gaps and with priority and visibility to the content and data that you want to protect. So in terms of key takeaways and the common misconfiguration, and what we have seen in the wild from users in cloud operator, again, just like you who run cloud environment, we saw that there are some misconfiguration that repeat themselves and users need to be careful and pay attention to address those ahead of mind so they will not be part of the statistics. Going back to that Gartner quoted in the beginning of the presentation, making sure you don't have any misconfiguration when it comes into excessive permissions, publicly available snapshot, it's really easy to fall into this one. But even if you have a lab environment and you want to share the snapshot between two different location, and you want to have access between two different locations, make sure that if you make a snapshot publicly available for a certain amount of time, change it into a private mode right away. Otherwise it's being available out there. And if your data is not encrypted, the data on that specific snapshot or on the database is not encrypted. That's really an easy game and an easy win for the Badax. And finally, in terms of subscription for security groups, make sure it's being enabled to be triggered regarding any security alerts that are related to your databases. I really hope you find Imperva Snapshot interesting, and if you want to learn more to take some of that transparency to see the code of Imperva Snapshot, I first welcome you to look into our GitHub project where you can see also our CLI project in our GitHub where Imperva snapshot can be activated through a CLI where you can schedule tasks, automate the process, and get an immediate posture security posture of a new database that has been created. And I also recommend you to try impervisnapt yourself if you go into our landing page. Try Imperva.com slash snapshot and see it yourself. Get some more information if you want, run it on your environment and get some insights to make sure your cloud databases is fully secure. If you want to reach out, feel free. Mor Manor hit me up the email or on LinkedIn. I'm really happy to share those insights with you and hopefully talk with you soon. Enjoy the rest of the day.