The VP of Sales comes to your door and says “I hired a new contractor to integrate our new SaaS CRM package with Microsoft 365 and our ERP system. We need you to open the firewall to the ERP system so the CRM can talk to it.” Initially, a ton of red flags and sirens go off in your head. You think about:
- This is the first you’ve heard of this. You haven’t vetted the new contractor, done 3rd party risk assessments on them, reviewed the contracts from a security/risk perspective, nor assessed their capabilities.
- A new CRM system?! When were they going to tell you?
- Your legacy ERP system does not reside in a DMZ, does not have an API for integrations, and is a fragile and potentially vulnerable system.
- You don’t want to open your firewall for inbound traffic for any SaaS cloud application.
Rather than fight back with questions and scathing refusals, you remember your mantra: “I am a business enabler. I am a business enabler.” After the VP of Sales leaves your office, you call his boss, the Chief Revenue Officer. She explains to you that this initiative has been budgeted and approved already and that cybersecurity will absolutely not be permitted to slow down the process.
Before you do anything else, log this in your risk register. You can’t cover all of these risks. Log all of these red flags and document the situation in your risk register.
What’s next after the risk register? You scramble for some controls to put in to protect your vulnerable assets.
- Can you segment off your ERP server any further?
- You set up a DMZ with a reverse proxy in it and create access rules so that your proxy can only access your ERP server.
- You put a firewall/WAF in front of your new DMZ.
- You create a VPN from the CRM vendor to allow only traffic directly to a VPN aggregator in front of your DMZ WAF.
- You increase monitoring on the DMZ and on the ERP server.
- You add new best-of-class endpoint detection and response software to the proxy and the ERP server.
- You set up increased monitoring of Azure AD and the enterprise application integrations.
You’ve added these controls. You still don’t feel comfortable. You could get hacked at any time through this integration. The entire due diligence process is being sidelined. How do you handle this problem? First, you have the CRO accept the cyber risk from the new CRM software and the integration vendor. This is not your risk to accept. She needs to accept responsibility for her decisions and failure to include you. Second, you begin a retroactive due diligence process to understand the risk to your systems.
What does this risk acceptance look like? Use this model as a template:
Requestor: Summary of the Request (explain the risks and the exceptions to policy or process): Potential Impact to Safety, Finances, and Reputation (if known): Overview of the Service(s) Impacted: Overview of the Data and Data Classifications that are at risk (of exposure, of corruption, etc.): Existing Controls (if any): Benefits of Accepting this Risk: Risk Acceptance: I understand that this request introduces risk to the organization and either violates our infosec policy or circumvents controls. This risk may have negative effects, including breach, downtime, loss of money, data, or reputation. I understand and accept responsibility for the risks associated with this exception to information security policies. Signature of Responsible Requestor: Printed Name of Responsible Requestor: Date:
After your CRO fills out this Risk Acceptance, you file it in your audit documentation.
It is important to have a Risk Acceptance process. This is mine, and it is fairly simple. Depending on your organization’s risk tolerance and change management process, you can customize one to fit you. In the end, it is important that you understand this: You need to be clear with your colleagues that they are responsible for their bad decisions. If you give people this Risk Acceptance, some of them will change their mind. The risk might not be worth the work for them.