How to handle a zero-day attack – from lawyers

We all know about zero-day attacks. But what about when the zero-day attack is in the form of a subpoena or other legal notice regarding the data in your CRM system? Don’t panic.

Comments

It’s easy to make fun of lawyers, but the actual steps involved with legal proceedings is neither easy nor fun. Before I start, I need to clearly state that I am not an attorney and none of this article should be used as legal advice. It can be used as the starting point for a discussion with your lawyer ... and yes, my attorney made me write that.

Let’s start at the beginning: why would any legal eagle want access to your CRM data? It’s just contact information and your pipeline – both of which are confidential parts of your business, right? Here are some common reasons attorneys might need to get in there:

One of your sales reps did something fraudulent with a customer, who is now suing you.
One of your sales reps didn’t do their job, was fired, and is now suing you for wrongful termination.
One of your employees left their former employer and took a bunch of that company’s data with them ... and then uploaded it into your CRM system. Now that old employer is suing you for theft of intellectual property.
One of your competitors is infringing on one of your patents. You need to be able to prove the extent of damages and lost business.
A patent troll has hit your business with an infringement suit, based on code that’s in your CRM system. You need to be able to prove who wrote that code and (hopefully) be able to deflect the suit to a consultancy that worked on the system.
You’ve got a dispute with one of the integrators who worked on your system, and are suing them for damages.
A regulatory agency is exploring product failures or customer complaints and needs to review your customer service records.

Your attorneys are unlikely to know anything about the data in your CRM, much less what can and can’t be done with it. So their requests may be pretty confusing, if not outright non sequiturs.

Step 0 of your response strategy should be to carefully read the subpoena, the legal complaint, and any supporting documents. Understand clearly what the time frame of the issues are, and get clues as to the timing of events going forward so you have deadlines to work with (don’t be surprised if they’ll all change, but at least you’ll have a starting point). Talk all this over with your attorney and understand the specific rules and procedures that will be relevant. The rules of the road are very different indeed for arbitrations versus court proceedings, let alone government regulatory investigations.

Of course it’s all in the backups

Actually, what you will need is almost never all in the backups…and even if it is, the first thing for you to do is find the snapshots of the entire system data and metadata for the relevant time periods, and get those snapshots onto write-once media. Yes, really. You want to have a copy that can’t be messed with. If you can’t find the backup files for the relevant period, create write-once media copies of the closest versions before and after the time period. The next thing you do is create another full data and metadata snapshot of the current production system (hopefully, into a sandbox) and sequester that snapshot so that only a couple of people can log in to it.

Once that’s done, schedule a meeting with your attorneys to understand the nature of information they need to discover in the CRM and the kind of analysis they want done. In that meeting, you should brief them on the basics of the CRM system: what data is in there, what data is missing, what basic system terms mean (like, “what’s a lead vs a contact?”), and how meaningful the data is (or, more likely, isn’t).

You should also brief them on who had administrative access during the relevant time period and what your users’ data access privileges are (and what that implies about possible data manipulation). Discuss with them who should/should not have access to the snapshots and analytics. Discuss with them who should be actually doing the analysis (most likely, an outside expert).

Catalog your backups and archives

Typically, companies don’t know what backups, archives, and audit trails they have for their CRM system. Because CRM data changes so rapidly, the systems are weak about handling history (e.g., “can you show me what these records looked like 17 months ago?”). So, here’s what you’re looking for:

The user login history table
The administrative change log history table
The change audit trails for each relevant object
The historical snapshots of all data in the system
The historical snapshots of all metadata
If your CRM administrators use a configuration control or ticketing system, the data from that system. If they use paper, the log books for the relevant period.
If you have an ILP/DLP product monitoring Salesforce data, the report-run and data-download logs from that product.

Unfortunately, most companies don’t regularly capture the data above, or they throw it out after a year or so. This is dumb city, as most suits come years after that (I’m working on one right now that is regarding data from 10 years ago).

If you simply don’t have this data and use Salesforce, the company may be able to reconstruct much of the information from their internal archives. However, this is not a standard service – it’s a consulting project, and can be an extremely expensive one. If you’re missing the historical info, you’d better just hope that opposing council hasn’t read this article … because they can compel you to spend mightily on a data reconstruction project.

Write everything down

As you are doing all the steps above, create a journal of everything you find (and don’t find). Any decisions made – even minor ones about data access and storage—need to be memorialized. You’ll never remember this stuff months later when you get deposed about it.

When it comes to analyzing or even manipulating the data, try to avoid using any custom code. It’s going to be much easier for all concerned if you use products and methods that can be easily reproduced, even if a clever AWK script with some APL matrices would be more elegant. Any settings and parameters for the apps and databases used in your analysis should be recorded in your journal entries, and use screenshots liberally to substantiate the details.

Of course, anyone with an interest in the outcome of the case should not be analyzing, let alone manipulating, data. Typically, this means consultants should be doing all the data crunching. Make sure that the consultant has no investments in your company or the opposing party, and that your contract with them contains no incentives or bonus payments for specific outcomes.

(It’s best if there are no incentive payments at all.) If there is going to be analysis that is critical to your company’s case, the consultant is likely to have to testify (at least in deposition) and it is critical that they be fully qualified as an Expert Witness and willing to give testimony. These are fairly rare birds: you can find them in the FEWA, TASA, or IMS online guides; expect to spend between $400 and 600 an hour on them (yes, really) if they are going to appear in court.

The big picture

If all this sounds daunting, it is. Your goal – immediate and long-term – should be to settle the matter as fast as you possibly can. Do not get defensive, focus on proving “I’m right and they’re wrong,” or obsess on purist goals: that way lies only increasing frustration and huge costs. Because even if you win, you lose. Law suits are always a distraction from your real business, and nobody will compensate you for the opportunity cost of the time and emotional energy you put into it.