Secure Your Salesforce Org & Data: The ANZ Edition

Everyone, thank you for joining. We are covering this topic on Salesforce security and we wanted it to be very holistic. We'll talk about Salesforce security completely like a 360 view and this is specifically in response to some of the recent events that have happened in the Australia and New Zealand region. Safe harbor: we're going to have a bunch of conversation here and everything we're talking about is for informational purposes. The two organizations here, Platinum 7 and Cloud Compliance, are not law firms. We're talking about security, privacy, and compliance but this is not legal advice. These are our individual points of view based on our experiences at Salesforce and after talking with a lot of customers. A little bit about me. My name is Saurabh Gupta. I am the co-founder and CEO of Cloud Compliance. We are a Salesforce data security and privacy focused product company. We are an AppExchange ISV partner. All our apps are on the AppExchange, 100% native. Our focus areas are data retention, data masking, and portability and right to be forgotten — which is typically for GDPR, CCPA, and other privacy law compliance. I spent about seven and a half years at Salesforce. I was an Enterprise Architect there. I'm based out of Chicago and very active on LinkedIn. Over to my friend Doug. I was also at Salesforce for 13 years. I'm also an Enterprise Architect. I have a purely Salesforce-focused security and compliance consultancy. That's all I do — just look after Salesforce security. Looking at the agenda for today: we're covering a little bit of the overview about why we decided to bring this webinar to market, then discussing what sort of data you have at risk, then how you should look at securing that both from the application security point of view and your data security point of view, and then a little bit about how you can increase your security awareness. So as we all know, it's been a challenging few months in this region with quite big hacks. These were actually quite interesting in the way that the attackers got in. The Optus hack came about because they had an issue where they used production data in a test environment, and then that test environment was not necessarily as well protected as it should have been. That's where the Optus breach came from. The Medibank hack was quite interesting in that the criminal syndicate found login credentials for a single support desk worker. Support desk people tend to have access to most customer information because they have to be able to answer telephone calls, and that worker did not have two-factor authentication. So it was so easy to get in that respect. Both of these issues are things we'll be covering off today and how you can keep your Salesforce data safe. Both of these were not Salesforce issues — these customers are Salesforce customers, but these were not Salesforce platform vulnerabilities. Security does not have to be hard. It isn't hard, but it never stops. You start off with assessing your org's health, you then secure your application, you secure your data, you improve your awareness, and repeat. It keeps going around in a never-ending cycle because you'll never finish — the threats will change, Salesforce capabilities will be improved and enhanced, and new technologies will come to market. One quick point here: one of the trends we've seen is that as organizations rely more and more on Salesforce, as you bring more processes, more users, more regions of the world, more different types of technology — Sales Cloud, Service Cloud, Health Cloud, FSC, Marketing Cloud — it significantly makes your Salesforce org a much more attractive target for people with bad intentions. The threat vectors keep on changing. When you come to assess your org health, there are a couple of things Salesforce provides: the Health Check, which everyone knows about — it's a pretty good test, it'll go through and give you a security health check score. It gives you good pointers on what the main issues you should be focusing on when it comes to security. The Portal Health Check is important if you have a community in Salesforce where you let your partners or customers access your Salesforce environment — that is a very, very common place for issues to occur. For securing your application: MFA is mandatory. A single credential without a second factor is the primary path for credential-based attacks. The Medibank breach is a perfect example. IP range restrictions via VPN and certificate-based device authentication reduce unauthorized access. API access control must be explicitly enabled via Salesforce support — it is not on by default. Connected app permissions should be reviewed and restricted. For securing your data: sandbox environments refreshed from production carry live PII into less-controlled environments where developers and testers have broad access. Data masking tools replace real customer data with realistic but fictitious values before sandbox refresh. This directly addresses the Optus breach pattern. Field-level security and sharing rules must be audited regularly as orgs grow and evolve. Deletion and right-to-be-forgotten automation ensures compliance with the Australian Privacy Act and Australian Privacy Principles. Security awareness: your users are your biggest risk and your biggest asset. Regular training, phishing simulations, and making sure your team understands the value of the data they're working with are all critical components. Security is a cycle — you keep going because the threats keep changing.