Beyond ATO: Securing Salesforce for Government & Public Sector

Thanks everybody for your time today. We appreciate you all taking a few minutes to spend with us on our webinar: Secure Your Salesforce Data in the Government and Public Sector. The briefing today will go a little bit under 30 minutes, and then after our presentation we'll have some time for Q&A. My name is Ron Thomas. I'm the president of a company called Black Knight Medical. I am a service-disabled veteran-owned business located in Atlanta, Georgia, and we service about 100 different VA Hospital systems and Commercial Hospital Systems as well as work with some commercial partners and management consulting. My role here on the team: one of the things I always tell people is whenever you're going up to do business in the government sector, you want to make the job as easy as possible for that buyer. So right after you tell them what you can do and how you can help them out, the next thing you need to talk about is how do you buy from us? Government procurement rules can be very tricky, and that's my role on the team. Just a couple of housekeeping issues. This is not legal advice. This is not a Salesforce presentation. This is a presentation that we put together from our point of view. The agenda we're going to follow: a walkthrough overview, then we're going to look at three frequently overlooked data security and privacy risks. How to understand FedRAMP, ITAR, and HIPAA. Then we're going to ask the question: is ATO enough? And then we'll have a discussion about that, followed by what Salesforce data needs to be safeguarded, ensuring sandbox data privacy is good, and we'll talk a little bit about data masking and explain what that is. All right. Thanks Ron. I'm the president and one of the co-founders of a Salesforce consulting firm. I've been in the IT field about 23 years now. I started out in the US Air Force where I spent about six years in DC at the White House Communications Agency. After leaving the service, I spent a few years as a contractor for the Marines at Quantico, and then I moved on to the public sector where I worked places like the National Archives, HHS, GSA, and others. In 2016 we started our Salesforce consulting firm. We're focused on helping mid to large organizations both public and private sector to modernize their infrastructure and software and to help them accelerate the ATO process. In the public sector, we know that our security obligations will always increase — they will never decrease. Take for instance the recent Biden Administration executive order on improving the nation's cyber security. This order adds multiple security requirements for government networks such as implementing zero trust, establishing additional logging and reporting levels, managing your software supply chain security, and a few others. All of these are on top of and in addition to the requirements for a FedRAMP ATO. A compliance or risk management framework is really just a tool. It's a method to standardize the way in which systems are evaluated and authorized across different entities. Without these standards we wouldn't be able to confidently ensure that our data is protected to a minimum level consistently across the board. It's important to keep in mind that any kind of security risk management framework is just a minimum level to which we must protect data based on its sensitivity or categorization. Obtaining an ATO is really a starting point — it's not the finish line. We know that the FedRAMP ATO is necessary for a cloud-based platform or service to go live, move into production, and host production data in a federal environment. FedRAMP is managed by the GSA. It's designed to give oversight and provide direction to both federal agencies and commercial providers on how those services will be evaluated for use by public sector entities. It's similar to FISMA in that both use the NIST 800-53 series of security controls, but it differs in other ways — the main one being that it is cloud-specific. It is not designed for on-premise systems. Some other frameworks you should be aware of if you plan to operate in a government sector are ITAR, which regulates arms data, and HIPAA, which regulates how health information can be used and shared. Your compliance obligations are complex. It doesn't necessarily matter which sector you're in — you very likely have one or more types of compliance requirements to contend with, and those requirements can be heavily dependent on the types of data you are storing. So to hammer home the point: achieving your FedRAMP ATO or other accreditation is really just a start. On the left side of the picture you have your possible security and compliance requirements — this represents your pre-production phase where you're developing or standing up your environment, documenting your security processes, your control implementations, and essentially preparing for your assessment. Once you achieve your ATO and go live, you move over to the operations phase: maintaining the system, patching, fixing bugs, releasing new features, and all of that requires testing. So with that in mind, we've highlighted some of the common issues we see customers make during this phase after they've attained a FedRAMP ATO. The first is around non-production environments. When you get an ATO, you'll have an accreditation boundary — that is, everything within your system that has to be authorized. It has to stay compliant. However, it's common that non-production environments fall outside of that boundary and they're just not secured or monitored as well as your production systems. A lot of people tend to think that's fine since it's not production. But that can become a problem in a cloud environment where you're paying for resources as long as they exist. Sandbox environments are often stood up on demand, and that can involve simply cloning the production environment to create another copy to test against. At this point you can potentially have production data outside of your tightly managed ATO boundary, and that's never a good thing. The second issue: least-privileged access control is often not as thoroughly enforced in non-production environments. If you combine this with the first point, now you can potentially have sensitive data in a non-production environment that more people have full access to for testing. And again, that's not good. Finally, shared environments. In a SaaS environment such as Salesforce, you may be sharing back-end systems with other tenants. Accounting for that in your ATO boundary and your security implementations can often be taken for granted because it's easy to say we're inheriting that from the SaaS provider, so we don't need to think about it. And that's not always true. Your data is everywhere. Data can exist in many of your sandboxes. You have environments for verification, training, quality assurance, integration testing. These environments may be available to project teams, integrators, vendors, and contractors — all with access to multiple orgs. And your data may have been replicated to other agencies' test systems. What are the impacts of inadequate data security? Lawsuits can exist. You can send out test emails to actual customers. These things affect your reputation and can have a negative impact on your ability to meet your mission. Loss of trust and reputation can impact your agency and careers. Here's an example where there was no malicious intent — just the simple mistake of leaving sandbox credentials in GitHub and using the Salesforce DX CLI. Leaving credential information behind and letting it get into the code repository is very easy. Using those leaked credentials, PHI records were exposed along with employee PII from the user records. A common response is: but I have Shield. Yes, Shield gives you encryption for data at rest. But the question is: these days, is your biggest threat that someone can access data stored at Salesforce? Many exposures occur with an authorized set of credentials. Most of your users still have access to that data, whether they need to use it or not at that moment in time. Without contextual security models, your data is visible most of the time. There are testing vulnerabilities when you allow a tester to log in as different personas or roles. You've granted them access to your data. Persona-based testing of course is important for comprehensive test cycles. But all of this is data that you can mask or delete with Cloud Compliance DataMasker. Cloud Compliance DataMasker operates 100% natively within your Salesforce org, staying within your ATO boundary. No data leaves the platform. This makes compliance documentation straightforward — you are inheriting Salesforce's FedRAMP authorization for the infrastructure layer while protecting the data layer yourself.