It's 2 AM, Do You Know Where Your Data Is?
By Ben Moreland
Let’s stop just short of saying panic is setting in for insurers without a solid cyber security strategy. Those on the other side, however, with cyber security supposedly all locked up, must be ever vigilant and still on the lookout for continued improvements that can be made in terms of both strategy and execution. As data becomes more service-oriented, protection must be more focused at the data level, and not at the firewall.
Continue Reading from eInterpreter...
And speaking of fires…
It’s easy to get caught up in solving immediate problems, or in meeting self-imposed deadlines which come up when boardroom discussions elevate buzzwords and shiny objects beyond the theoretical and the strategic to a more tactical level. It’s also easy to brush one’s hands together and pat each other on the back and consider cyber security as a project which is “done.” Unfortunately, in this world of moving targets, declaring “mission accomplished” is akin to taking a premature victory lap, don’t you think?
So, even though there may be a cyber security strategy in place with rules, roles and responsibilities assigned, one potential loophole which may have escaped incorporation into insurers’ original cyber security strategies, implemented as new threats develop every day, is vendor management. Typically sequestered in purchasing, acquisition or operations domains within an insurance company, vendor management may not seem in any way related to cyber security until you think back on recent high-profile data breaches. Edward Snowden, for example, was an independent contractor for the National Security Agency (NSA) and that the high-profile Target breach occurred via the company’s HVAC service provider.
Without wagging a finger to shame anyone, it seems worth mentioning that vendor management should already have been a key part of insurers’ data management and data security strategies. Unfortunately, in an effort to streamline onboarding of vendors or contractors, many companies (insurance and otherwise) provide blanket access via forms that “guarantee” standard operating procedure for all vendors across the board. When everyone has the same access, processes are easier to automate, finalize and maintain.
Compounding the issue is the fact that insurers still largely view threats as coming from outside the company firewall. However, when third-party contractors, who are normally positioned or thought of as outside the firewall, are allowed to build or have access to components that are inside the firewall, the loophole has been exposed. In addition, some insurers have been burned by not understanding that some third-party contractors actually subcontract out work. Subsequently, the subcontractors used by an insurer’s vendors, even the most preferred ones, may put critical data at risk. Many insurance companies, in fact, have contracts restricting where data can be housed, but miss that the vendor subcontracts to another, possibly even outside of the country.
Unfortunately, an insurer’s customers – developers, agents, customer service representatives (CSRs), administrators, policyholders, production support, executives, etc. – do not all require the same access to data, so blanket access and using the same forms to determine access or restrictions for everyone is dangerous at best. Within applications, security must reside at the application layer, the component layer and more and more, the data service layer (i.e., Who has what rights to a data entity in this context?).
Insurers with a greater degree of data mastery have the upper hand here as these companies will have a higher level of data security and more complete knowledge of where data is housed, how it is accessed and by whom, and which parties should be authorized to have access in the first place, both during development and in production. It’s 2 AM, do you know who is accessing your data and why?
Ben Moreland is vice president, data and analytics, for 1insurer. He can be reached for further comment or information via email at firstname.lastname@example.org.