With data breaches on the rise and millions and millions of our personal records being stolen by cyber-thieves exploiting lax data security standards, data breach prevention is a hot topic. In 2015, there were 781 data breaches which exposed over 169 million personal records.
As a result, we at MicroAutomation are seeing an increase in requests for data breach clauses to be added to our contracts. Our customers typically come to us with addendums to our existing contracts that broadly require us to indemnify them from any and all data breaches.
We often push back on such requests. Why? Simply moving the liability from one entity to another entity does not address the real objective – improving data security so that data breaches do not occur in the first place.
The Anatomy of a Typical Data Breach
If you look at most data breaches, they usually occur when hackers are able to download large amounts of personal data from a company’s network. Often they will find the user ID and password of an individual with network access, login using the stolen credentials, and then scour network drives for scripts and programs that may expose other user IDs and passwords that have access to the data repositories.
Once they find the “super user” access they need, databases are accessed and the personal information is downloaded. Or, in the case of Home Depot and Target, malware was pushed to the store payment terminals to collect personal data as transactions are being conducted. So, avoiding major data breaches can be as easy as restricting the amount of data any one user or application can access.
Most the solutions we deploy only need information for a specific caller and do not require access that would permit download of bulk personal information. As such, we typically use a Web service or other such intermediate interface in our applications to access data from the database.
In addition, the interface requires the application to provide some caller identification information such as an account number to retrieve data for the caller. Therefore, the interface does not allow for bulk download of personal information from the database, only information for the one caller our system is working with and only with identification information provided by the caller. This design approach ensures that our customers’ data is protected from data breaches.
To protect data, automated solutions are designed according to three-tier architecture guidelines that require separation of the Presentation Layer, the Business Logic Layer and the Data Layer:
So, for an Interactive Voice Response (IVR) solution, the separation might look like this:
Using this design, the caller does not have direct access to the data, and any user accessing any one of the tiers could not access the data directly. This allows the data to be protected from external access and locked down to allow only single records to be retrieved with the proper caller identification information.
Given our focus on data security, it is understandable that we might be little skittish accepting indemnification clauses that hold us accountable for all data breaches that may occur to a MicroAutomation solution. First, most systems we deploy are not under our direct control and are maintained by network administrators at our customers’ sites.
Second, our access to customer data is usually limited to a single function that provides us information for one customer with the proper customer identification information. And, third the level of data abstraction in our systems would require an individual, with the proper credentials, to traverse several systems to get to any data.
As a result, we are working with our customers to structure indemnification clauses to address the little data access our company has so we can assure that we are held accountable for data breaches that only we could cause. More importantly, our meticulous approach to data security allows our customers to feel safe with a MicroAutomation solution.