Insurance Cyber Security Webcast Q&A follow up
RSM recently hosted a webcast discussing the NAIC Data Security Model Law. Following the webcast, RSM professionals responded to several questions from individuals who attended the webcast. Following is an overview of the questions received and corresponding responses.
Question: As a carrier, we provide access to our systems to insurance agents. In addition, many carriers’ systems are integrated with rating comparison systems. How does the data security law relate to these two scenarios?
Response: The parties you have described would likely fall under the requirements within the model law that is associated with third parties. The model law is quite clear on its requirements for third-party service providers. In short, first licensees are responsible for understanding the risks associated with third-party service providers and properly vetting those parties. In addition, Section 4.f of the model law details that licensees are responsible for ensuring that the service provider implement the necessary controls to protect non-public information. There is even a provision in Section 5.c that requires a licensee to report if a third party has had a breach.
Question: What other states are approaching adoption of the NAIC Data Security Model Law?
Response: The states of New York and South Carolina have already enacted legislation. Most legislatures are in summer recess, but we expect that as states reconvene their legislatures for fall sessions that we will see some movement on this topic. States will be deciding independently on this issue.
Question: Are the new requirements based on the state of domicile, state where services are provided, or where the participant lives?
Response: The state where the licensee does business is the deciding factor regarding the security and privacy requirements, not the state of domicile, for most of the requirements. However, the notifications about breaches may be tied to the domiciliary relationship, depending on how each state passes its version of the law. We encourage clients to have their legal counsel review the text of the new law to help ensure full compliance.
Question: What level of involvement do you recommend the Enterprise Risk Management (ERM) committee/working group have in managing a cyber security program?
Response: In our opinion, the ERM committee does not need to manage the cyber security program. That is the job of the chief information security officer (CISO), or equivalent role, who should be the responsible party for identifying risks and providing remediation recommendations within the ERM committee. The individual who leads the cyber security program should have a seat on that committee and your cyber risk should be considered along with other risk areas. We have seen several organizations that list cyber security as one of their top five risk categories, but it still does not get the necessary attention or resources. The reasons for this are speculative, but it could be that risk professionals are failing to discuss cyber risk from a business perspective. That is why we recommend that risk assessments seek to quantify risk in terms of dollars or operational impact as often as possible. We recommend the ERM do the following:
Question: What fines can we anticipate based on non-compliance? Is it compliance with all or is there some flexibility with having a majority of parts within compliance?
Quantify and communicate risks in terms of monetary and operational impact. This will help ensure the organization understands the impact of the risk and any reduction strategies based on return on the investment.
Help security get a seat at the table with company management. In addition, when they do get a seat, coach them to ensure they are prepared for that role.
Security professionals do not typically grow up on the business side, so they will most likely need to learn how the business works and how the business communicates risk internally.
Collaborate with cyber security to set risk thresholds.
Require annual security risk assessments and metrics to track the status of the risks identified during the assessment.
Require that the security risk assessments and security risk nomenclature align with the organization’s ERM program. This will ensure that the security risks are assessed in line with the other risks facing the organization.
Response: Section 10 of the NAIC model law leaves penalties up to the individual states to determine. As shown by the South Carolina law in its corresponding Section 38-99-80, violations of the SC law are subject to penalties described in a prior regulation (Section 38-2-10). A link is provided here: https://www.scstatehouse.gov/code/t38c002.php. Basically, Section 38-2-10 states that fines and license revocation may occur, in addition to any criminal penalties. The state’s action also does not preclude further criminal or civil action. Because South Carolina is thus far the only state to adopt the model law, we don’t have other examples to draw from. However, we would expect that other states would follow a similar path, assuming they have the penalties already defined by statute (as in South Carolina). In New York, Section 500.20 of 23 NYCRR 500 simply states that the state’s law “will be enforced by the superintendent pursuant to, and is not intended to limit, the superintendent’s authority under any applicable laws”, which is vague. The New York law is not the NAIC model law, but the model law clearly drew from 23 NYCRR 500. Bottom line: penalties are up to the individual states.
Question: Is there any guidance on what type of logging we should perform?
Response: Each of the new regulations are pretty specific about the need to collect adequate details about cyber security events, which then must be reported to the state insurance regulatory bodies—generally the state insurance commissioner. The regulators will be looking for details about who was impacted, the extent to which people were affected, and the type(s) of data that was compromised. Also, remember the need to retain supporting data for up to five years, as outlined in the regulations. Beyond cyber security event reporting, the new regulations are not overly specific about the type of data that needs to be collected. Because it is easy to get overwhelmed by logfile data, a good approach might be to use the results of periodic risk assessments as a starting point. Try to match what you are logging with areas of most significant risk. It can also help to look at logging from three directions:
First, focus on identifying unauthorized activity—catching the “bad guys”. IDS and IPS systems are good at this and so is the firewall, but there is plenty of data you can obtain from servers and network gear, such as failed logins (especially privileged accounts), unauthorized configuration changes, and starting or stopping of services. The risk assessment process will likely have identified things like this at a high level, and the subsequent drill-down should produce the list of unwanted events that should be identified.
Second, for authorized activities, focus on the most critical data and transactions and maintain data on key financial data flows, administrator access (in and out), administrator password changes, etc.
Third, performance and capacity data that is not directly related to security can be a valuable indirect aid to support investigations into unexpected activity. For example, a gradual increase in port 21 traffic over time might not raise any initial suspicions, but it could be a symptom of unauthorized data exfiltration. If the infrastructure team maintains its list of significant metrics, this can help everyone better understand what information is available to help support forensic security efforts. This is not really part of the new regulations, but it should be part of a general approach to log file management. The ability of modern systems to generate log data is a double-edged sword—everything is potentially useful to a degree, but the key is determining what meets the threshold of true usefulness for your organization. Finally, don’t forget about security over the logfile data itself. If the chain of custody cannot be assured, then the value of the data drops and may ultimately become useless if it is to be used during legal proceedings.