APRA Cyber security stocktake exposes gaps — the Salesforce edition
TL;DR;
Salesforce customers that are APRA regulated need to focus on their Salesforce environment to be compliant with APRA’s CPS234 as APRA found that there were major failings in compliance in a recent survey. Salesforce and partners have products and services to assist with this.
Introduction
The Australian Prudential Regulation Authority (APRA) has done a stocktake on about 25% of their regulated financial institutions in Australia and found that there were major issues in compliance with CPS234. The report was published 6th July 2023.
Even though this is specific to Australian Financial companies regulated by APRA, the recommendations are valid for any Salesforce customer in any vertical.
These were the most common failings when it came to CPS234 compliance:
- incomplete identification and classification for critical and sensitive information assets;
- limited assessment of third-party information security capability;
- inadequate definition and execution of control testing programs;
- incident response plans not regularly reviewed or tested;
- limited internal audit review of information security controls; and
- inconsistent reporting of material incidents and control weaknesses to APRA in a timely manner.
So let’s go through each of these in turn and see what an APRA regulated financial institution that uses Salesforce needs to do to correct these shortcomings:
Incomplete Classification
In the Salesforce environment, each field can have it’s own classification for security and compliance. The data elements are Data Sensitivity Level (Public, Internal, Restricted, …) and Compliance Categorization (PII, PCI, …) These data elements can be customised to your requirements and the Compliance Categorization can have multiple selected values.
This allows financial services companies to classify all their data and these classifications can also be used in data loss prevention polices that are able to be created using Salesforce’s Event Monitoring — Transaction Security capability.
To do the classification, you can use the Salesforce Object Manager, or to make it a lot easier, the OwnBackup Secure product has a very quick and easy to use tool that assists in creating this classification data.
When it comes to free text fields and document attachments, making sure that these do not contain information that should not be there, credit card numbers for example, requires more proactive assistance. Blackthorn.io have a compliance product that will check these and highlight when there is noncompliant information in this data.
I published a blog on the Five Knows of Cyber Security — the Salesforce edition, in which I go into detail on the classification of data in Salesforce.
Limited Assessment of 3rd party information security capability
Salesforce publishes a very comprehensive list of compliance documentation that customers can use to satisfy their 3rd party information security assessment requirements. I have covered this site and the documents I think are important in an earlier blog post — Salesforce Compliance Documentation Site — A “How To” Guide.
Inadequate testing of controls
Information control assurance programs were not in place for key controls like user access reviews and data loss prevention controls, and testing was not performed by functionally independent testers.
Creating and monitoring data loss prevention controls is relatively simple with Salesforce as there is an inbuilt capability for data loss prevention, namely Salesforce’s Event Monitoring — Transaction Security capability. As mentioned above, the classification of the data can be used to create tailored policies that will fire only when certain thresholds are breached for certain types of data. For example, if credit card data is being stored, then it is not able to be added to reports at all so that there can not be a way for users to get a list of card details, and you can block the access to the card number field via API unless the API user is marked as allowed access.
User access reviews can now be more easily done in Salesforce as there is a free, open source tool Authenticated and Guest User Access Report and Monitoring. This tool can be used to understand how much and which data a user (including the Guest user) can see.
The functionally independent testers is a bit harder as there are not many independent Salesforce security assessors, and few partners have the capabilities to do a deep dive security analysis of Salesforce environments. In-house testing could be conducted by the customer’s security team, however how many of these folks have Salesforce skills?
Inadequate incident response plan review/test
Some of the findings were that incident response plans were not in place, not reviewed and/or not tested regularly and that incident response playbooks have limited plausible disruption scenarios.
When it comes to getting incident response plans sorted out, first you need to know that you have had an incident (see paragraph 23 in the CPS234 standard), in Salesforce this means you need to have Salesforce’s Event Monitoring otherwise it is “impossible” to know what is going on inside your Salesforce environment. These logs will give exquisite detail into the goings on in your org — tracking users through the system highlighting which records and files the user has looked at, not necessarily edited; which records appeared on a list view; which records appeared on a report preview; and lastly which records were exported via an API or report export. Salesforce does not provide any alerting tool that will do analysis of this data, so a partner, FairWarning, has built a tool that will absorb the log files and provides prebuilt rules for many alert types. A new player in the community is using learning algorithms to provide alerts without the need to write rules at all — Reveal Security’s TrackerIQ.
After you have found the issue, then you need to run the analysis and respond to the incident. FairWarning has a prebuilt tool for this, however you may want to use your standard SOC processes.
The second finding where there were limited plausible disruption scenarios being planned for, APRA gives a great range of scenarios, however the one that leapt out at me was Data Breach and without the information gathered from Event Monitoring, you will not know what data/files has been exposed. Even with these controls in place, data may still leak and how do you know if it has leaked? Seedata.io is a company that has a tool to put seed data into your environment and then is able to detect it in the wild and alert you to a leak.
Inadequate internal audit of infosec controls
APRA’s findings that the internal audit teams of the regulated companies had limited review of 3rd party infosec controls and also the internal audit teams lacked the necessary information security skills. Independent Salesforce security consultants can assist internal audit to make sure that the Salesforce environment has been assessed and any findings highlighted.
Inconsistent reporting of incidents and weaknesses to APRA
There is no direct relevance of this control to Salesforce customers as such, however a workflow as part of an incident response could easily alert the user to notify APRA. Salesforce’s platform is extremely flexible and an incident response system could be easily and quickly prototyped then moved into production.
Thanks for reading — if you have any questions or comments, please let me know.
My company, Platinum7 is an independent Salesforce Security consultancy.
