Here is another interesting chat at RSA Conference this year. A gentleman approached me asking if we could help with their problem of moving data and insider threat.
His organisation policy makers were happy to use Cloud for standard business services, but not storing their sensitive data (he wouldn’t tell me the specifics). Anytime they wanted to move data from that ‘area’ of the network to the cloud they were refused by policy in case there was data leakage… you know… just to be safe.
His first problem I couldn’t help with, apparently encrypted VPN isn’t safe enough for transmission. Maybe they will end up with sneakernet and a suitcase + handcuffs.
The second problem though was a great use case for SOAR, and not one I’ve come across yet. The data source and data destination were from different vendors with no existing integration together. This means the process is very manual and potentially exposes sensitive data to the insider threat / operators.
So I demonstrated our playbook execution and how we communicate with end users. The final pseudo design we agreed on was:
- A playbook that can be initiated by a schedule or by an inbound request
- The playbook automatically restricts permissions of the ticket. Access is only granted with 2 pairs of eyes.
- The playbook fetched the data from vendorA
- The playbook then did some basic pattern matching against the data, file type checking, maybe push it through a DLP, and many more.
- If the data was sensitive we can stop the process, flag the ticket, etc.
- If the data was good we push it to the remote system and close the ticket.
- However If the data was neither definitely good or definitely bad we can use CommunicationTasks to email a manager and the original ticket requester asking what to do? Proceed or stop?
- Using our ComTask we can interactively engage the end user without exposing the data in question (see above)
To summarise, they can still do the process (quicker than before and with fewer mistakes), they’ve removed visibility to the data, but their workers still have the control to initiate and control the workflow. Pretty cool.
Thought not predominantly a SOC incident type, it shows that automation is automation, be as creative as you like.
Andy