Salesforce, Inc. (CRM) Earnings Call Transcript & Summary

Welcome to today's session, how to protect your data with Salesforce Shield. And thank you so much for joining us today. Before we begin, I'd like to cover a few quick notes about our webinar platform. Today's webinar will be available on demand after we wrap up and will be accessible through your role that you're on right now. Please note that the slides will advance automatically throughout the presentation. To enlarge the slides, click the enlarged slide button located in the right-hand corner of your presentation to go. Could you need any technical assistance, click on the help widget located on the bottom left-hand corner of your console. We've also added some additional resources, which are available through the resources window to the right of the slide. There, you can find additional related content, including things like [indiscernible] and e-books. Lastly, we encourage you to as questions at any time throughout the presentation using the ask a question widget at the bottom of your console. We will answer as many questions as we can at the end of this presentation. With that, let's get started. I am Ali Jaeggi. I am a Senior Product Marketing Manager here at Salesforce. In a prior life, I was actually in a public Highschool English teacher, if you can believe it. But after a 2-year stint at USD for my MBA fight on any follow charges out there. I joined Salesforce and have been here for a little over 2 years on the platform team. And I'm pleased to be joined by my colleague, Rachel Beard, who is a security architect here at Salesforce. Rachel, you can help us now and introduce results.

Yes. Hi, everybody. It's great to be here today. Thanks for having me. I spend my days as a security architect, helping my customers understand exactly what is the security that Salesforce is providing for you with the network and infrastructure layers, everything we do day in and day out to keep your data safe with us. But I also spend a lot of my time helping companies develop their security strategy so that they can better prevent data loss among insider threats, which is the top reason for data loss, 89% of data breaches are attributed to the human element. And then I also spend a lot of time on data privacy, compliance and governance topics as well. And I've been here for 8 years, actually today is my 8-year anniversary...

Congratulations on your 8 year, and thank you for joining me on your 8-year anniversary Rachel I had no idea, but congrats that great Yes, I've been to hang out with all of our customers. I agree. It's a great way to under. I'm really happy you here with me today. Let's show these amazing audience what we've got on the bucket for today. Here's the lineup for today's session. I'm going to walk you through a short Salesforce Security and Privacy portfolio overview. Then I'll dive into an introshield and then an overview of Shield's 4 capabilities. And then I'll pass it to Rachel for her amazing live demo. I can't wait for you for everybody to see it. It's amazing. And then I'll be taking your questions while Rachel in the hot seat, getting you all the answers that you need that will be fine. If you sort of drop your questions in the ask equation wheat in the webinar portal whenever they come to mind, and so we can get to them during that Q&A session. All right. Before all of that, it would not be a Salesforce presentation unless I reminded you to only make purchasing messages based on products and services that are currently available -- and here at Salesforce, we know that your success is our success. We would not be here without you, which is why customer success is one of our core values. So thank you for joining us today. Thank you for giving us an hour of your time. We hope that you'll gain valuable information during the webinar today. Your success is truly a priority for us, and we are committed to be your partner and pursuing together in the days of years to come. All right. Let's get into it. Companies just like ours of all sizes and industries need to react to pending threats, especially when you're focused on scaling. There are threats and risks coming from all sides that make having a security posture critical. Unfortunately, since March of 2020, we've seen nearly 700% increase. Yes, you heard me correctly, 700% increase in phishing attacks and a 71% increase in data breaches. The threats are increasing in sophistication and this can come into conflict with managing your core business. There are also privacy regulations, which changed nearly every year and differ from country to country and in the U.S., even from state to state. So for businesses with a global footprint or one to have one in the future, it can use very hard to keep up. We recognize the security and privacy requirements are often at odds with innovating and building next-gen experiences for your customers. which is why securing and managing your data is easier than ever to do on the Salesforce platform. Whether you're using a commercial instance of sales force and industries instances like Dove Cloud or Health Cloud or another solution, salesforce and customers unites all of your teams, marketing, sales, commerce, service, IT, all in one integrated platform. The customer 360 really is how you bring together a full picture of your customer and put them at the center of everything that you do. No matter if your customers are internal employees, citizens, patients or anybody else. And we are here to help you protect that information. Because building customer trust has never been more important. Like any relationship, trust is the currency that moves the businesses forward. That's why trust has been one of our core values since our founding over 20 years ago, but it isn't a onetime thing. Trust can be built over years, but then broken in an instant. In fact, trust is so critical to our growth that we carry a trust first mindset into every product we build, every partner we innovate with and every customer we help scale. Customers don't like you. At Salesforce, we think of data security and privacy as a continuum across 3 key dimensions that adopt with your business over time. These dimensions include understanding your data, then protecting your data and finally, scaling our security program. Today, we're digging into shells you're all here, which such as the first 2 parts of our continuum understand and protect. So let's get in the shells. Salesforce Shell is a suite of capabilities that exist for customers who need a level of security and protection above and beyond the security that's baked into the platform for all of our customers. Customers like you who need to meet complex compliance or industry regulatory requirements, monitor access to sensitive information stored in Salesforce or even who just need to ensure that their implementation is optimized for high scale business efficiency in a large and complex enterprise. Salesforce Shells can help with all of these things and includes 4 key services, which I'll get into event monitoring intend data detect, platform encryption and field audit trail. We're going to go a little out of order this morning. I'd just like to keep things interesting and we're going to start with platform encryption -- so platform encryption is all about protecting your information as it lives in the database in -- as a native feature of the platform, we can provide industry-leading data protection while preserving the power of the platform for you. With full ownership and management of key material used to encrypt the data, you can be rest assured that you're staying in compliance with any internal and external regulations while continuing to build amazing experiences on the platform. Let's take a look at the Watch Trail. We know that tracking data is an essential part of any government strategy, but maintaining an audit trail can be very complex and very resource intensive. But with field audit trail, you can unmake this process. You're on the son team, we love automation. There is no wondering about what's going on with your data because you are always tracking changes to anything sensitive. You can stay compliant with regulations like the general data protection regulation, JDPR and protect all of your data at all times, ensuring accuracy and the tracking indicates. You can archive yield history data for regulatory and internal compliance policies, audit historical data and gain valuable business insights with relevant trends and patterns. Let's tap into event monitoring next. Event monitoring allows you to get complete visibility of your sales force or in renewal time. Event monitoring allows you to answer questions like, how can I find out what my users are doing on Salesforce to help increase user adoption or identify a typical behavior? Or maybe you're wondering things like how long is it taking my custom apps to load? Event monitoring provides reports even down to the Apex class level, if you need it to ensure that you're delivering high-performing secure apps to your end users. Not to mention giving you a very strong return on your investment for your sales force deployment, always a good thing. Let's move over to Einstein the last and shields capabilities. The newest member of the Shield family Einstein Data Detect, and I used the phrase view a little bit loosely it sit out for about a year. You can quickly find the sensitive information in your sales force instance that you might not even to exit. You're able to define policies related to which types of information you can -- that are sensitive, get the data in your org and identify where it might be storing things like social security numbers or other PII, even if that data is buried in a really long text field. Our shield team is known for saying, if you don't know what data you have, then you don't know how you feel about your data and then you don't know how you need to protect it. But with Einstein Data Detect, you can close that gap and start applying the right protection controls sooner. All right, enough for me. I'm going to hand it over to Rachel, who's going to walk you through an amazing demo of not only on Einstein Data Detect, but event monitoring as well. theaters a method to my madness. That's why I ended with that last over the year ago...

That was really well structured. I appreciate that, Alan. Yes, so I'm going to take it away and show you what these 2 solutions actually look like. And while I'm showing it to you, I'll try to add in some dialogue about how I see companies actually utilizing these tools. Within the big domain of security, I am most interested and most focused on human layer security and protecting data loss, preventing data loss. So I'm going to be focused on showing you how you can use these tools for that purpose. I just want to take this moment before I start showing my screen to remind you to add some questions to the Q&A because we're already getting a lot of questions. I see questions in here about platform encryption already about Einstein data detect, about field history tracking and filled out a trail. We're going to make sure we get to these questions at the end but keep them coming, so that we know which -- what you have top of mind, and I'll even try to work some of this into my demo as we go along. Okay. Great. So. I'm going to go ahead and share right now. And Ali, before you go on mute, just so maybe, let me know that you see my transaction security team.

I do, and it looks great. Awesome.

Okay. All right. So here we go. We are going to talk about event monitoring and my favorite feature of event monitoring, which is transaction security. So when we talk about Shield, we're already talking about a suite of solutions and event monitoring is the one of those tools that you're going to use for decoding all the activities that your users are engaging in, in the platform. Everything they search for, what do they click on when they search, what records do they view? What are your admins doing? Do they log in as other users? What do they do when they're locked in as those users? What reports are being done? Are data being downloaded, whether it's from a report export or the API. So you get a lot of information from security adoption and performance use cases, but that's all reactive, right? That's looking back and seeing what's already happened. -- super helpful if you have an incident or if you want to go back and understand your baseline. What I want to help you with is understanding how to be very proactive at identifying an incident or anomaly, getting an alert in a real time something is happening right now and ideally trying to prevent the riskiest behaviors from happening. And the way that you do that is with transaction security, which is one component of event monitoring. So today, I'm going to show you how to build 2 different types of policies, one with Flex and one with code so that you can see an easy way to prevent a large data export, someone walking away with a whole bunch of information or I'm going to show you how to get into data classification and prevent somebody from adding confidential or perhaps PII types of details to your reports. So let's jump in. We're going to go ahead and click new here on transaction security, and it's going to ask me right up front. Do you want to work with Flex or do you want to work with code. We're going to start with clicks. We're going to use the condition builder, and we're going to build the most commonly requested transaction security policy, which is block somebody if they're trying to download a large number of our opportunities or contracts or something that they might take to a competitor. We've seen a lot of movement this year as a result of the great resignation where employees are leaving their roles and perhaps going to work for another company where they might have value in that data. So we want to make sure they don't do that. So here, I select what type of event do I want to monitor for, and we're going to pick reporting events. And then I can define what about reporting do I want to monitor. So we're looking for reports, and I want to look for reports where the user is performing in export. So that's the operation. And you can see all of this is prebuilt for you, so I don't have to even know the correct syntax. I'm going to pick report exported, but you can see that there's things like reports running from mobile or reports being scheduled. There's tons of conditions that are ready for you already. So I've set this up to look for a report that's being exported. Do I want to block all report exports? Or do I want to just focus on the ones that are a large volume of data. So in this case, we're going to focus on a large number of rows. I'm going to go with something like more than 5,000 route. So on the next screen, we're going to say who to notify and what we want to do about it. But just for the purpose of what we're at right now, we've already set up in just a minute, a reporting event where the report is being exported. It's a large number of rows. Just so you understand the scope of what can happen here, you could keep adding conditions and have flexible parameters here. So maybe I'm also worried about our super secret report or maybe we have celebrity data that we need to protect. So I can put the report to me here as well and put some custom conditions. So if you've done any kind of approval processes and things like that, workflows, this will be familiar to you, 1 and 2 or 3. I'm looking for one, it's a report export and either a large number or the Super Seeker airport. We don't care how many records are on that report. We don't want it to be downloaded. So once we have all those conditions set up, we're going to say what do we want to have happen. We actually don't have to necessarily block this. Maybe we just want to alert the security officer for the org that this has happened, and we don't want to interfere with the users. So from the user's perspective, no action. But on our end, we're going to get a notification or we might want multifactor authentication so that we can enforce a high assurance section or we might want to mix and match. So maybe we're going to block this transaction, so they will not be allowed to download the record. And maybe we want to also notify that Security Officer. And you'll notice here you can customize the message. The default message lets you know that you've run into a security policy, but you could be more specific about what that policy means. So I've already got something like this up and running in my org. I've got a policy to block a large data export. And just to show you what it looks like from the user side, let's say that they're going to go run an opportunity report. And I have a policy set to block more than 500 records because this is a demo or without a ton of data. But here, I'm going to act as the user and export this report, taking those 700 opportunities with me. When I go ahead to export that, it tells me that this operation is blocked. It's not out because there's a security policy in the org that's preventing it. Okay. So that's a simple data loss prevention use case. What I want to show you next is one step above and beyond that, which is specifically preventing sensitive and confidential data from being added to reports. Maybe it's okay if you have, for example, employee data for employee cases and an HR manager needs to see this data on a one-on-one basis, but they shouldn't be running the ports and especially shouldn't be downloading data in bulk with PII. So in order to build a policy that prevents PII from ending up on reports, we first need to make sure that we're using data classification. Data classification is out of the box. All of you have this already today regardless of event monitoring, and you'll find data classification field properties on all of your standard and custom fields. This is an example of a custom field that I added. But just so you can see here, you can note who is responsible for the data in this field? Where is the data being used? What is the data sensitivity level and what policies are related to this data. So maybe PII, GDPR, CCPA, government data. And these can all be changed to reflect your actual definitions of data classification. I'm showing you this because what I want you to understand is the policy that I've built with transaction security using Code is looking at this data sensitivity level. And it says, hey, if somebody is performing a reporting event, and they do anything at all related to confidential data, we want to block it. That's a pretty strict report. You might make years a little bit less strict, but that's what I'm doing for the purpose of this demo. So I've built a data classification policy. I am locking any kind of reporting event that has PII in it. And I'm going to throw an error that says, don't add -- it reports when that person engages. And just for those of you who like to see things like this, you can see here that this is a very simple piece of code. We have examples like this published on our health and training. I can point you to those examples if needed. But we're just looking to see where somebody adds that confidential data. So when I go to a report, around employee data that I've built here, I have an example of an HR report that may be the director is using to monitor the workload of the HR reps. So they understand how many cases are being worked. What's the status of the cases, who's working on the cases? How long have these been open? What's the priority? It's a very clean report. It doesn't list even the employees' name. Maybe this is a behavioral case, maybe they have had an incident. We don't want to put the details of that incident on the screen. We don't want salaries, fires. We definitely don't want socials to be reported on in bulk. So if I were to go ahead and make an edit to this report, that's clean now and start adding any kind of protected data to it. I have built a policy to block it. So I'm going to go ahead and add that field, and it's going to tell me now. You can't do this, and you'll see that error that I set up earlier, don't add PII to report. So the value here is that this might not necessarily be a bad actor. This may not be somebody use leaving the company and looking to take data with them. This could be a user misusing the sales force data and likely unintentionally. Sometimes they see things like this where someone's taking a shortcut, maybe they just need to run a payroll adjustment, so they want a list of employees with their socials. -- but now they're downloading this information onto their machine. It can't be guarded by Salesforce. It's local. You don't have access to it. And especially if you have employees working off of a personal device, you absolutely do not want sensitive or competitive information to be extracted and living in a place that you don't have the ability to control it. You don't want it to be shared. -- are backed up to other systems. So this is the most safe way to manage that risk is preventing it from ever being even previewed on the screen. So here, that social security number, it doesn't even render. We don't see it in the preview mode, which means we can't print it. We can't screen shot it. We definitely can't extract that data. We've effectively stopped that behavior in its tracks. So behind the scenes, event monitoring is logging 70 different types of user activities -- it's logging many of these in real time. Some of them are coming through in daily and hourly batches, but there's a lot of data going on behind the scenes so that you could go back and explore what all of those behaviors were. By receiving alerts that help you understand what policies were triggered, and then you can go back and inspect those logs. Maybe you want to go back and see what else is that user is searching for, what reports that they've been running and get a better picture of that user. The other thing I always like to mention too is that all of the logs that support this on the back end are API accessible. So these logs can be sent into your SIEM solution and used in conjunction with other security logging. So if you currently need better visibility to what your users are doing, so you can correlate them with other actions. And if you especially need to put in some more proactive security measures to prevent data loss, I would definitely recommend looking into event monitoring, -- and don't forget that you'll also be getting adoption and performance insights, which helps round out the usability of the tools to help you understand things like technical debt, adoption, app usage, et cetera. Okay. So before I switch to Einstein data detect, which is what I'm about to show you, I just want to remind real quick to this screen. So remember I showed you how I have this custom social security number field, and it has a data classification field applied to it. This is a good example of sensitive data being stored in a sensitive data field that we know about. Hopefully, we have not just applied data classification to it. Hopefully, we're using out-of-the-box tools like field level security. And ideally, we're even using some of these advanced tools like transaction security to prevent it from being downloaded. When we think about Einstein Data detect, we're really thinking about all the instances of sensitive PII type of data in places that we know about, but also in places that we haven't examined. So for example, what if somebody is putting a social security number into a notes field or a commence field or someplace else that you don't have this level of protection on. Einstein data detect can help you understand where that data lives so that you can apply the advanced security measures that will help you manage that data. And that's why we delivered this solution. I'm going to go to my Ensign data detect home, so you get a sense for what this looks like. And keep in mind, of course, that this is a demo word your or will look way different because you're going to have a lot more objects and records and different types of custom fields in place. I'm going to show you this for simplicity. -- that this is the result of scans that have been detected or scans that have been performed in this ore. You can see here that I've primarily focused my scans on the case object and on the contact object. In scanning records, I'm looking for certain types of patterns, I'm looking primarily for e-mails and phone numbers. But we can also look for things that would indicate patterns like social security numbers, credit card numbers, et cetera. To do that, I have a combination of my policy stream to build the policies of what I want to scan for and where and my results screen, which helps me break down what was found in those specific policies. So we're going to look at a policy that I've already built around social security numbers. So here, I've got my policy. The policy name is find SSMs. And I've already instructed data detect to look through the case object as well as the contact object, and you can see here all of my objects are available, and I can continue to add objects and fields to the scan if I wanted to. On this key subject for the stake of the demo, I'm actually scanning for more than just socials. I'm actually looking for patterns that might indicate a credit card number and e-mail draws to URL and IP address, I'm going to go ahead and look for all of those patterns. And I've noted here which fields I want to stand in order to try to find that data. So we have that employee social security number field that I showed you earlier, but I have some other fields here that are larger text areas that perhaps somebody is adding that kind of data to that could help me understand what that looks like. And some of these fields have data classification apply. Some of them, a lot of them do not. So this will be really helpful for helping you understand what is stored in these objects. I did something similar on contact. I could keep going and enable the account object. And again, I would see all of those patterns I want to scan for, and I'd be able to say what are the fields that I want to look for in order to understand if someone's put something sensitive, especially in these larger tech fields, that's where I expect somebody to accidentally enter sensitive information. Again, they're not trying to do anything wrong, but academic use of data happens when employees are stretched thin, distracted, new hires, et cetera. So this is a good way to keep tabs to make sure that we're checking to see that everything is going according to our governance. All right. So if I have more time, I would run this live. Of course, I already ran it behind the scenes kind of like a baking show so that you can see the results of my fully baked at great here. I'm going to show you what these results look like, so you can get a good sense for what that scan detected. Here, you can see I had run it on those 2 objects, the case in the contact object. I scanned a total of 37 fields and 1,000 records. And I found 21 different incidences of those sensitive patterns across all of those objects. Here, you can see what we found, we found phone numbers and e-mail addresses, and we found different fields that are not categorized and only a small number of fields that are categorized with the compliance category, and most of our fields also don't have field owners to help us understand who's responsible for the data. So that gives me a good high level. Now if I want to dig in and look at some of the specific fields that we stand, this is going to be really helpful for understanding exactly what the field usage is here. So I've got this in place, social security numbers field. Only 3 records have data in that field compared to a 1,000, which do not have social security numbers populated. And you can see here where those patterns were detected and understanding exactly which records detected any kind of sensitive data like that. Maybe if I went on to something like a phone number this might have more helpful patterns that we can look at. In any case, here we go, it's going to help me understand where we detect it signs of a sensitive information power, in this case, to numbers. And here, I can even see specifically which records have this data on them. Again, this will be even more interesting if it was a credit card or social number something that was very urgent to clean up, you'd be able to click right through and manage that mitigation if you needed to. And then once you're through understanding where that data lives, you might also decide rate from the screen that it's time to go ahead and apply that data classification. So we can say who's responsible for that data. And just like I showed you on the other screen, we could tag this as being PII, and we can say where this data might be restricted, confidential and if this data is active, maybe it's a hidden field, maybe it's something that we're seeking to remember. So I'll be able to apply all of that and update that data classification rate on the screen. So again, this is where I want you to try to think about that big picture of understanding each kind of data element that you have in your work today and thinking about what is the sensitivity of this data? Does it require a data classification sequence that would tell me that this is public, confidential restricted or something like that for your most sensitive data classification settings, what are the security policies that you should be considering? At a very minimum, I want to make sure that you're thinking about your field level security. So highly sensitive data that doesn't need to be viewed by everybody can be turned off for most profiles, and you can even use permission sets to grant access just to a few users when you have highly sensitive data. Data classification and field level security are out-of-the-box tools that you already have access to today to make sure that you are really using those effectively. And then once you have a good handle on sensitive data and the usage, you're going to be looking at tools like event monitoring to understand who views sensitive data, who could be extracting sensitive data and start to put in real-time prevention to make sure that, that data isn't leading sales force. And then adding in something like Einstein Data detect, which is also part of Shield can help you continue to monitor the ore to make sure that the data that's being entered is compliant, is safe and that you're not opening up data elements that don't have that proper level of security applied to them. So these tools all really do work together to give you that enhanced governance as well as security. Okay. I'm going to pass it back to Ali, so we can do some next steps and then I want to make sure that we leave plenty of time for Q&A. Are we doing Q&A next. Sorry, I got out of... Right... Oh, my god. -- in the time I was looking at the screen, there's like 20-plus questions going on in here.

Don't worry. I will put you back in a hope. And if you want to pull the work back up to show anything, I think that would totally work. Yes. question.

I'm glad we have we lost a lot of time. Sometimes we run up to the end, and I get so excited about demoing I want to show you everything, but we tried to limit it just to a couple of solutions so that we'd have plenty of time for discussion. Awesome. Yes. All right.

And I've been known to talk fast, at least according to my former students. So we'll go fast. Okay. So before we dive into the questions, I just want to remind everybody that you can continue to submit those questions you can ask a question with it. It seems like everybody is doing this. But if you have some other questions, please submit a question to us. We want to make sure that we answer it for you. We're hoping our webinars offer really, really valuable content for you and meet your expectations. So when you have a moment, please rate the session by using a survey with it, which is at the bottom of your console. Okay. So let's dive in to the long list of questions that we've got from our very active audience. Thank you for getting those to us.

Okay. I will start with a new one just popped in. I'm just going to start from the top. Okay. grateful. How does Einstein data detect work on dummy data?

Well, right now, Insite is looking for specific types of patterns. So it's looking for anything that could have the format of a credit card number. So we're looking for a 16-digit pattern. We're looking for something that could look like a social security number or an e-mail address or a phone number. So it's looking for that combination of number of characters spacing, et cetera. We are looking to add forward-looking statements more types of capabilities around detecting different types of patterns as well as patterns that you get to tell us about but that's what it's doing today.

All right. I have a question. I'm going to cover it a little bit and then if you have anything to add Rachel for you to add Okay. So we have a question why do I have to buy Shield separately shouldn't things like event monitoring the default for an app-like Salesforce? So I covered this a little bit at the beginning of the presentation. I don't know when you hope into our remark. But things like memory, there's a certain level that is built into Salesforce. You get a certain number of names with event monitoring when you actually purchase it, it takes you to that next level. It gives you a lot more robustness to kind of like the feature and functionality that you would get out of the box sales force, Rachel, am I missing anything?

Yes. I would just say from my experience, event monitoring is expensive for us to deliver because most of the customers that I work with are generating hundreds of millions of log lines every single month, especially as we continue to add different types of events. So we don't generate those logs at all. If you don't have event monitoring, it would be too much volume, storage, processing, et cetera. When you turn on event monitoring, you really are getting the firehose of all of those types of user activities. And then like I mentioned, having them all exposed through the API means that you can use them not just in sales force, but in conjunction with your other tools that you're already using to explore user activity. So that's exactly why...

And this is why I love co-presenting with you. You bring all the hot knowledge. Okay. Another question, what specific risks are platform encryption and mitigating agents. For instance, encrypting a laptop mitigates the risk of data exposure should that laptop be lost or stolen. What is an example to share of a mitigated risk for platform encryption?

Yes, that's an excellent question. Actually, the question because for most of the customers that I work with, they actually don't feel like platform encryption is required. This is one of the few solutions that we actually don't want to sell you on because Salesforce is inherently secure. We have all these different layers of security protecting your data at the network and infrastructure layers. And for most of the companies, that's sufficient for them. Some companies are adding Shield for compliance reasons. So they have some kind of requirement that says that they want -- that they need to be able to encrypt the data and usually specifically manage the encryption keys. So maybe they need to rotate the keys on demand, destroy key material on a certain cadence or even bring their own keys. That's the main reason that companies are buying platform encryption. In terms of the risks it address, it's really anything that could attack the data in the storage itself. And this is the whole other conversation we can have another time. But at a high level, the data is always stored separate for metadata. So if you -- and because of multitenancy, if you were looking at raw data, it's not identified to any customer. It's totally identified, and it doesn't have object labels, field labels. It's practically unreadable for this reason. You wouldn't even know what type of information you were looking at. So to that end, adding encryption to that just makes that data in the storage unreadable. That means that if you had one of our DBAs working on the table, which very few have access to data and none have access to data and metadata at the same time. They're going to see a jumbled up Cyber text instead of plain text. And likewise, if there was a fact of the data storage, that attacker would see the data scrambled. But of course, we have so many security measures in place, physical security, monitoring, everything secured through locks and biometrics to prevent a soft and then also, of course, our DBAs are highly monitored to make sure that they're not colluding in order to access data that they shouldn't be. So short answer to all that the risks are well mitigated from sales forces built in security, but for the companies who really do want to demonstrate that they've added every security and technical measure, then they're adding a platform encryption to further store the data and add the key management.

Great. Great robust answer. I love that. Okay. Next question is Einstein data detect licensed separately or included with yield. This is a great, great question, and I really appreciate you asking it. So Einstein data detect is included with the Shield bundle. So for those of you who are not familiar with Shield yet, so you can buy the entire bundle, which includes platform encryption, flotation at monitoring and insane data to take altogether in one or you can buy everything a la carte with the exception of Einstein data detect. So if you love Rachel Deal as much as I did and you are interested in purchasing Einstein data detect go for that full bundle, it's great, and you will get Einstein data detect with it. Okay. Next question. How does field audit trail differ from field history tracking?

I love this one. It does, and it doesn't all about that. It doesn't differ from fill history dragging and that it does the same essential task. It's helping you understand changes to your data over time. Who made the change? What's the old value? What's the new value and when did that change occur? Both field history tracking and field audit trail have that same function. Field history tracking, which is out of the box and all of you have access to fill history tracking today, that allows you to track 20 fields per object for 18 months of retention. So the concern that I hear the most is I've run out of fields. I want to track more than 20 fields and I'm hitting my limit or I have a compliance reason why I might need to go back and query and understand who made changes to this data 5 years ago or even in the case of some kind of person who's maybe left the business, you need to go back and explore last year, what were they doing? So field audit trail is different in that it gives you 60 fields per object instead of 20. And it also copies the data over to a big objects at that 18-month mark, so that you also have a repository of those changes to the records. And this is pretty new news for anyone who doesn't heard this new news that now we will hang on to those changes in perpetuity. So you don't need to worry about those changes being delayed after 10 years. We'll hang on to those data elements in a big object as long as you need to. If you want to go ahead and delete it, that's fine, but we're not going to enforce deletion.

That's super new. I just updated these slides a couple of days go for that. So hot off the presses for everybody that's here today.

You can see it now stock meet Yes. also.

Okay. Do we need to be in the Einstein data detect app in order for the transaction security policies to bread? Or will they work into sales after any other app for that matter?

They work in any app. That's just the app that I happen to be working in, in my context, but transaction security and event monitoring runs on all core platform types of solutions. So you'll pick up on all user activity, whether it's coming from Lightning, classic mobile and transaction security policies will apply in all of those contexts as well, including from the APM.

If a field is encrypted already, would it be allowed to be added to reporting. For example, shows where a user was unable to add employee SFN, what if that field was already encrypted?

Yes. And that field actually is encrypted in my org. So this is kind of the interesting thing about our data in friction because platform encryption is encryption at rest. So what that means is that when a user is adding data to Salesforce, the data gets encrypted at the application layer and sent to storage as [indiscernible] cyber test. If somebody needs to access that data again, it will automatically be decrypted for their use. So I'll just pick on Ali. If I had enter her the contact last week, and I encrypted or me, her e-mail address or birthday, whatever I have to encrypt -- it stores on decipherable cyber text, but let's say that she calls me back next week, and I have to search for her name and find it and pull it up on the screen. I need that to be clear tax so I can read it. I don't want that to be encrypted cyber text. Same goes with reporting. If you are running a report and you're calling for those records, they are automatically decrypted for you on demand and likewise for the API and your integrations. So this is where I always like folks to really think about what is the purpose of encryption, which is what I love that, that question was asked earlier. Encryption is not an access control. Encryption is not meant for your internal user visibility. It's really only met for the data at rest. If you don't want data to show up on reports, you're going to use a combination of field level security. If you like it, want to remove access to that field or something like transaction security, if you want the user to be able to see the field but not export the data or build a report with it. I know there's a lot of security tools available. It's going to be tricky to come with the strategy to mix and match them all, but this is where it's really helpful to work with your security architect, who can help understand your unique requirements and concerns and help you model out what are the best strategies...

So then based off of that answer, I have another question which I think could be answer to is yes, but let's go through it. So in the words, we're known to contain sensitive sense of data because of -- I love this print these reasons, which cannot be solved. We are considering encrypting the message body field of the e-mail message object. Can I still search across e-mail messages once the body is encrypted? Based on your answer, it sounds like the answer to that is... Yes. Am I correct?

When you encrypt any kind of data, the data does remain searchable. So even if you're going to encrypt all of your files and attachments, you're going to be able to preview what is contained in that file. And again, you'll preview it in plain text, you'll be able to search for plain texts. There are some functions that you cannot do on encrypted data just because of the nature of the way that the data is being stored in the table, and there's different methods of encryption. This is a much bigger conversation. So if you want to work with your security architect on this, we can demo it all out for you so you can better understand, but pretty what who knows what I'm talking about right now. There are probabilistic methods, there are deterministic methods that are more filter preserving. And you want to make sure that you're applying the right combination. But in general, we really want you to encrypt as low as possible, just was absolutely required for compliance reasons, just because the field is sensitive doesn't mean that it requires encryption. I would definitely think it's going to require field-level security, but -- and probably monitoring to know who uses that data doesn't necessarily to be encrypted at rough. So you want to make sure that you develop your strategy accordingly.

Great -- thank you... For adding that content. Okay. Is there a method of pulling down event monitoring data via a platform event? Example, we have a pub-sec pubs listener on MuleSoft and want to notify admins when they see something isn't right.

Yes. So this is a really exciting thing about real-time events. We actually completely change the architecture of event monitoring. And so, you have the original event log file structure and you have real-time event monitoring and real-time event monitoring is what's running on platform events. So if you have a listening tool and you want to be able to inspect the logs as they come in, you could absolutely do that as well as take action on your platform events. And that's essentially what transaction security is doing. It's finding those events as they occur and acting on them. Actually, it's all of the most interesting change that happened from my point of view, with transaction security when we move to real-time events is that now you can even get in front of certain activities. So if the user is building a report that's never even been saved, they're just trying to build something you can still stop it before they even save that report, built the report, you have a lot more flexibility and the level of activity. Forward-looking statements, you're going to see more changes coming over the course of the next year and even things that are starting to pop up in the next couple of releases that are going to make the original event log files delivered quicker and make them even easier to use and inspect. So I will definitely recommend that you stay tuned for all the information that's coming out around these new enhancements.

That's a great call out. I'm going to just take a breath here and just thank you again for 8 years of being at Salesforce and being here with us today and answering all the questions of which we have more. So we're going to keep going. There.

Pass me up so I can keep going. I appreciate that...

I'm here to motivate...

Okay.

Okay. Do security policies apply to this admin profiles...

Do security policies apply to the 7 profile? Is that the question?

I'm pretty sure that question... Your Yes. Yes.

I think I understand what the question means. Yes,. You can build a transaction security policy with clicks like I showed you. And in that condition builder, you can exact certain users by user name or user ID. So let's say that there's a couple of users who this policy shouldn't interfere with, you can absolutely do that in the condition builder. If you wanted to go broader, like all sys admins all profiles that have sysadmin or Data Steward or something like that, that's available through Apex. And actually, if you haven't already done so, go check out the transaction security Trailhead module. That module has that exact example in it. So it will walk you through how to set up a very simple Apex policy that blocks all of the large data downloads, except the sys admin or accept the data steward and we'll have you make just a small change, don't be intimidated. It's not something that needs to be a developer to do. This is definitely something that I've been order to advance on and to manage...

I have another kind of is admin type of question. So if you add employee SSN as a field that you do not want users to add a report, are you able to add exceptions where this admin or a certain profile of love to add the field to report with having that message or error?

Yes, same answer. You would just build that into your condition. So you would say, "Hey, if someone's doing a report event, and they are adding a field that's confidential and their profile is not sys admin, then we're going to flag it and otherwise, we're going to pass it. So you can be very specific, especially when you're using Apex, you have the power of all kinds of customizations to work with.

Great. How did Einstein data effect that question, how do we define a pattern for the system to understand during the scan. By understanding we have limited patterns right now, is that correct?

That's correct. So right now, there's just a handful of prebuilt patterns for known PII types of combinations like a 9-digit social or a 16-digit credit card number. Those are the patterns that were explaining today. Forward-looking statements, we're looking to make that more robust and potentially allow you to define your own patterns, but that capability does not exist in the generally available version.

All right. So kind of a question about Einstein data detect as well. How exactly was the fine asset then policy that you showed, created? Will it search social security numbers with dashes and without dashes...

Yes, it's fuzzy. So it's going to look for 9 digits with and without dashes when it performs that search. So you would just define it in the same way that I showed you where you're able to go object by object, field by field and say what you need to scan. It's not going to scan everything. You're going to define what you want to stand in that way, it will run quicker, right? So you don't waste time scanning things that you don't need to explore or even evaluating results of things that you don't need to evaluate. So you just decide what needs to be scanned, what patterns to scan for and off you go.

We only have a few questions, and there are only a few minutes left. So we're going to try to get through that as quickly as we can here.

I'm ready to be around...

Yes, the 500 record expert block example that you showed in your deal, if this takes place and blocked, is there a next step condition option, for example, block user pending manager release what stops the user from trying to export 499 records as an example.

Yes, I love this question. And I think that this comes from the concept of a low and slow type of an attack. So maybe a user doesn't want to trigger off at the alarms and they're going to -- instead of downloading 1,000 records, they're going to download 100 records 10x. -- transaction security is transaction based. So it's going to evaluate each transaction one at a time. It won't detect that this is your tax transaction. It's just looking at the one transaction. So I have seen some examples where the companies that I work with have used other services. to manage that kind of metering and aggregate. But oftentimes, what ends up being really useful is the analytics in this case. So have you seen that there's a spike of reporting activity from this user? And have you seen that there's been a large quantity of records downloaded overall. The other thing I'll just mention is threat detection because we really didn't get a chance to talk about this, but this is one of the newer enhancements to event monitoring threat detection allows our machine learning to be running in the background and looking at the user's pattern. So for this user, maybe 499 records is a lot. Maybe they don't usually run reports at all or maybe they're downloading 499 cases when they're not in support and they never look at cases. So this is where our threat detection will look at those events and decide if this pattern is anomalous. -- for that user and potentially throw off an alert in that circumstance. And direct detection is GA part of event monitoring today.

Great. Can the transaction security policy that you showed, can they be applied to access data via API.

Yes. Absolutely. -- transaction security can work off of API events, list view events, anything that might be of bulk access to data. It also can affect certain login events, even permission sentiments, if you want to be alerted when somebody is giving you all modify all terms to a new user, there's a lot of different use cases for transaction security.

Is the client able to access monitoring data older than 30 days. We currently have a client that is required to keep this information for up to 3 years and want to automate this platform events as opposed to downloading a lot manually.

So today, you have our original event locked files, which are stored for 30 days, and the real-time events, which are built on platform events are stored for 6 months. If you wanted to extract them or if your customer wanted to extract them and store them elsewhere, they absolutely can. And I do see a lot of customers taking certain event types and putting them either into an archive or into their SIEM where they have a larger storage capacity. That's fine, but that is the current built-in limit is 6 months.

To wrap it up, do you have any hot steps on performance impact of using platform encryption, field encryption, et cetera?

So for platform encryption, you typically will not have a noticeable impact if you're just encrypting a few fields per object, measurable but not noticeable. Where I tend to see performance impact is when you're really trying to encrypt so many fields. And if you imagine what I mentioned earlier about that data happened to be encrypted and then decrypted in real time as you're pulling the record, the more that you have encrypted, the longer that's going to take for that process and especially with reporting and API activities. So go Slow, obviously do this in the sandbox first to make sure that you have that performance testing underway, so you understand what the performance is like in a full sandbox with production like conditions and then get that kind of benchmarking going. But ideally, if you're just encrypting the builds that you're required to encrypt, you really shouldn't have a noticeable impact.

Well I am officially taking you off the hot seat Rachel, Happy 8 years -- no more questions. But I do want to tell everybody that the audience today. You can continue learning about Shield with the resources that are on the side. We do have quite a bit of resources available on the website, and we can get you some time with a [indiscernible] if want to see some more, reach out to your account team. We got those types of things come up. Feel free to grab a screenshot of this slide to keep the link handy convenient time for you. Check out the trailhead model. It's great. The white paper is excellent as well, some fun stuff on the website that goes beyond what's here as well. So grab that screen shot or check out the resources that are right next to the webinar window here in your webinar app. And of course, I just want to say thank you again. We are wrapping up. And of course, thank you to Rachel for joining us on her 8 year anniversary here at Salesforce. -- super wonderful to cohost with you, loved our webinar session this morning. If you want to come back to today's webinar at any time or if you want to share with somebody or anything like that, today's webinar is going to be available on demand and accessible through the that you're on now. So no new or all to just the one that you already have. So you're going to be able to check the reporting after the using that thing you are all easy peasy. We hope to see you all again in the first future. We hope you join us for another webinar. And I hope you have a great day. Thanks again.

Yes. Thank you, everybody. Thanks.