The New York State Department of Financial Services (DFS) announced the $1.5 million settlement of its investigation of Residential Mortgage Services (RMS) surrounding the unauthorized access to an email account which contained protected private information about New York residents.
The saga began when DFS examiners issued a “First-Day Letter” for a safety and soundness examination of RMS for the 2019 time period. As part of that process, DFS sent a notice confirming that they had not received any cybersecurity event reports during that time period. In response, RMS sought to file notice of an event from 2019 involving a phished mailbox where the user authorized two-factor authentication four times after business hours even though she had not attempted to access the mailbox. The mailbox was used to close many mortgages and contained sensitive and private information about New York residents. Despite authorizing the access, the user did report the event to RMS’s IT department.
The IT department’s investigation was limited to investigating the access and ultimately preventing access from the unauthorized IP address. There was no effort to determine if data had been exfiltrated, no investigation of the mailbox’s content, no notice to the affected data subjects and no prior notice to the DFS prior to being advised that they were about to be audited. Pursuant to the regulation, New York DFS requires notice within 72 hours of discovering a reportable cyber event.
Importance of Incident Response Policies
What is unfortunate about this event is that handled differently, RMS would likely not have been fined. The organization had multifactor authentication. It had complex and changing passwords. It had antivirus and network monitoring. RMS even knew the IP addresses of the individuals who accessed the account so they had some form of network logging. What they did not have were appropriate controls and procedures in place when these security controls failed. If RMS had performed a risk assessment and sought to understand the nature of the mailbox’s content, they would have understood the risk this event posed to New York residents. If the company had a meaningful incident response policy that defined when notice was required to affected data subjects and regulators, it would have satisfied the regulation. In short, RMS suffered a self-inflicted wound for failing to reasonably act once it knew of the event – but not for being breached in the first instance.
There are several take-aways other DFS regulated organizations can gain from this settlement. First and foremost is the importance of having a well-trained workforce and clear policies that mandate reporting when reportable events occur. The employee was unreasonable in approving four log-ons when she was not trying to authenticate to the system, but overall, RMS appeared to have largely compliant systems. Moreover, the employee did report the event the following day. Had RMS dug just a bit deeper and acted appropriately, it would have probably been on the correct side of the DFS regulation.
Two-Factor Authentication Not Foolproof
A second takeaway is that two-factor authentication is not foolproof. Most 2FA systems can be configured to work with either a swipe or the entering of a code. Here, the employee just swiped and allowed access since the bad actors already had her password through phishing. If the system was configured to require a code, she would not have been able unwittingly to grant the hackers access since she would somehow have to communicate the code for them to enter. This is an unlikely scenario. However, swiping is something someone might do just to clear the screen so they can get back to whatever they were doing on the phone. Clearly swiping is easier, but the additional hassle of entering six digits is not that much to ask and is probably worth the trouble for most applications.
Another takeaway is the need for organizations to perform risk assessments. Here, RMS was capturing sensitive information by email. This is a rather high-risk method to collect private or protected information because once the system is breached there is no compartmentalization, and all the data is in the clear. Sensitive information can be transferred without sending it in the clear through email. Organizations that collect this type of information should look to implement one of these methods and avoid email. Email further compounds the problem because when it is breached (and it almost always is) it is very expensive to sift through to identify protected information and then identify data subjects requiring notification and all the mailing information associated with them since most states require notice by paper mail. The cost associated with just one breach will eclipse virtually any other system an organization could choose to implement. Moreover, with a proper system, the required information is in a more useful format.
RMS might have missed a further opportunity to mitigate its risk had it performed a risk assessment to affected data subjects. Pursuant to DFS regulations, notice to the Superintendent is only required when notice is required pursuant to other notice regulations or the event had a reasonable likelihood of materially harming the operations of the covered entity. This event would trigger reporting under state breach laws such as New York’s SHIELD law (GBL Section 899-aa). That law allows an entity to avoid providing notice where it can reasonably show that New York residents are not a risk from the event. This can often be established with logs capable of establishing no messages or data was transferred outside of the organization. This analysis must be documented and retained and there is a risk that a regulator may disagree with the conclusion, but clearly RMS did not perform any analysis to avail itself of this defense.
Risk is Widespread
By far the largest takeaway from this event is that any organization can be breached and that, in and of itself, is not a terminal or defining event for any organization. Even the National Security Agency gets breached and its’ entire purpose is to not be breached. What the company does next will define it. Will it demonstrate good stewardship for the data it holds and determine if any of the data subjects face a risk because of the event? Will it be a good neighbor and advise other parties that it suffered a breach, and that they may receive bogus wire instructions or other security compromising efforts in its name? These are all things a company could do that will have very few negative consequences and often fosters stronger relations with customers and business partners. Conversely, concealing or ignoring an event such as this will almost always fail and result in a worse outcome than just reporting it. It behooves all organizations to implement strong policies and controls that promote risk analysis and reporting when indicated.
If you would like to strengthen your organization’s cybersecurity policies and controls or recently experienced a cyber event and are concerned about whether it is reportable, call Alan Winchester, Chief Development Officer of Caetra.io, at 585 419-8713 or email him at firstname.lastname@example.org.
Caetra.io is an affiliate of, and controlled by, the law firm of Harris Beach PLLC. Caetra is not in the business of providing legal advice or legal services, and the protections of the client-lawyer relationship (including attorney-client privilege) do not exist with respect to any services provided by Caetra.