With Salesforce being the central hub of information for many enterprises, it’s no surprise that organizations are focused on keeping their Salesforce instance secure. The good news is, Salesforce is an extremely secure platform.
However, there are still basic steps all organizations need to take to minimize breaches, including malware protection, to prevent phishing attempts and improve Salesforce security.
“91% Of Data Breaches Start With Spear Phishing Attacks On Organizations.”
Often, people assume that malware protection isn’t necessary when dealing with cloud platforms like Salesforce. There’s a misconception that nothing can affect your local machine since everything you’re interacting with lives on Salesforce’s servers. However, there is an exception to this rule: files and attachments.
Salesforce Data Storage vs File Storage
Salesforce provides a generous amount of file storage that’s separate from record data storage. Data storage is used every time a user creates a new record like an Account or Contact. File storage is what is used when a Salesforce user uploads a file, like a pdf, to a record. Or, for example, an attachment on an email uploaded to a Case. Generally, file storage starts at around 10 GB and increases by about 2 GB for Enterprise and Unlimited Editions, as shown here (this is always subject to change).
Now that we’ve covered the difference between data storage and file storage in Salesforce, let’s uncover how to protect file storage in Salesforce from cybersecurity risks.
Salesforce File Storage: Malware Protection Considerations
You may trust internal Salesforce users to not attach a malicious file in Salesforce (plus their computers are likely scanned for vulnerabilities). However, if your organization is leveraging Salesforce Experience (formerly Community Cloud), the risk of an end-user adding a malicious attachment to Salesforce via file storage is much higher.
The risk is higher because, at the enterprise level, Salesforce Admins don’t have any governance over how Salesforce Experience end-users interact with the platform. Organizations cannot enforce what browser Salesforce Experience users are using or what virus scanners they have installed on their machines.
There is no native file scanning completed when a user uploads a file to Salesforce. This opens the possibility of an external user attaching a malicious file to a record and anyone else in the system (including internal users) downloading and installing that file, thus putting their local machines at risk.
The AppExchange: Salesforce Virus Scanners
The AppExchange is the first place we recommend organizations look to extend the functionality of Salesforce. This holds in the case of virus scanners.
Several great pre-built virus scanners on the AppExchange provide monitoring tools to keep an eye out for any malicious files. Two examples are F-Secure Cloud Protection and Cyber Alarm Antivirus. These solutions work well as point-solution scanners for Salesforce. However, there may already be a virus scanning platform in use at your enterprise (ensure your organization validates this).
Can Organizations Repurpose an Existing File Scanner platform for Salesforce?
If there is a virus scanning platform in your organizations’ tech stack, it is possible to repurpose it. However, your use case may require a more custom solution that needs to be built and maintained, and that maintenance will require Salesforce development skills.
“Even if a virus scanning platform is in place, an organization may want more control over what files get scanned.”
Ultimately, the decision to invest in a new file scanning platform or repurpose an existing one will depend on each organization’s use case. Keeping reading to learn what a custom virus scanning solution could look like in Salesforce and what to consider during implementation.
How Content is Stored and Versioned in Salesforce
The next section covers the basic polling design organizations can leverage to ensure their files are stored safely while waiting for scan results from a third-party virus scanner.
To control what files users are attaching in Salesforce, organizations need to understand how content is stored in Salesforce. Below is a simplified object schema that demonstrates how content is versioned in Salesforce.
In this section, we’re going to cover the ContentVersion object in Salesforce. Every time a user attaches a new file in Salesforce, it creates a new content version. Simultaneously, that content version creates a new ContentDocument (assuming this is a net new file and not a new version of an existing file).
The job of the ContentDocument is to mirror the most recent ContentVersion (which is why the fields are essentially identical). It is important to note that the content stored in a ContentVersion record is immutable, which means users can’t update or delete it after they have created it. The only way to delete a version is to delete the entire ContentDocument. Users can, however, add custom fields to the ContentVersion object, and these are editable after creation.
The actual content a user aims to store is captured in two different places before entering the database. It can either be stored right in the ContentVersion record using the VersionData field or stored in a separate object that Salesforce uses internally called ContentBody. When a file is attached, these methods are used, but there is no controlling which method is used on a given upload.
Once the ContentVersion record has been saved to Salesforce, regardless of if the data was in the ContentBody object or in the ContentVersion, it will be accessible via the VersionData field. This is great because it means users access the file in the blob format, put it in a REST request, and send it out to scanning software.
How to Implement File Scanning in Salesforce
Now that we understand how files are stored and versioned in Salesforce let’s look at some use cases on how to implement file scanning in Salesforce.
A common use case, for example, is organizations want to scan specific files that match a set of criteria before they are entered in Salesforce. To do this, start with a before trigger on the ContentVersion object.
There is no way to complete a full virus scan in the limited time available in a Salesforce transaction. This means there are only a few ways to scan files attached in Salesforce to prevent cybersecurity risks. Creating a before a trigger is one of the only opportunities to alter content version data before it becomes immutable (once it is saved within Salesforce). However, before a file is sent out to be scanned by a third party you have to make sure no one can access this file (in case it is malicious). The sections below outline two methods that can be used to ensure the file is unreadable until the results of the scan come back.
Method 1: Scramble File Data
The first option is to encrypt the data before it is saved. Not using Shield Encryption, but instead leveraging the Apex Crypto library. This method involves scrambling the data before it gets saved. This is a very safe option because it ensures the file isn’t readable or launchable until the scanning has finished. However, there are design trade-offs for using this method.
The biggest trade-off is users can no longer preview the image as now the file is unreadable. This can also give some strange behavior when inline rich text images are inserted (yes, this scanning solution handles these as well) as the image won’t show until the scan results have returned. When the file has finished scanning and comes back with negative results (meaning no virus was found), simply reverse the encryption of the file and save it back as a new version of itself to make it accessible again.
Method 2: Lock Down File Visibility
The second method deals with the scenario that happens when the file data isn’t ready within the before trigger at time of creation.
To deal with this, adjust the sharing of the actual file with SharingPrivacy and SharingOption fields to ensure this is Private on Records and Setting additional shares to restricted so it can’t be passed out. This isn’t a perfect solution because users with Modify all permissions still have visibility to this file. For this reason, this method is not as safe as method one above. However, if all your Salesforce Experience users have Modify All access, you may have bigger problems on your hands. Similar to method one, once the file scan results have returned you can reverse this restriction by changing the SharingPrivacy and SharingOption settings back to their original values.
Limitations and Considerations
If you’re going to take the custom route, it’s important to know there is a 12MB file size limit for what native Salesforce REST requests can send out. This can limit the sharing of larger files, and you will need another solution to deal with this.
Another approach that isn’t discussed in this article is building a layer on top of the standard content entry. However, with this solution you will be required to re-create all your UI components to deal with the entry and management of files users are putting into the system. This method is somewhat similar to a Transaction/Centralized style of Master Data Management, where you control the authoring and presentation of files through your own custom interface.
Have Questions About Salesforce Security?
We hope you find the actionable insights provided here to be helpful. Have questions about this blog, Salesforce security, or Salesforce virus scanning considerations? Sign up for our newsletter! We send out a monthly recap of our latest Salesforce content, including articles on security best practices, actionable insight on Salesforce optimization for enterprises, and more.