SEC Schools Pearson on Cyber Disclosure Failures

We have yet another reminder from the Securities and Exchange Commission today about the importance of full and accurate disclosure of cybersecurity breaches, this time in the form of a $1 million fine against education publisher Pearson for making misleading statements about a breach the company suffered in 2018.

Pearson is a British company that makes and sells online courses, including software that it sells to school districts and universities to administer online courses those organizations provide to their students. So one can understand how Pearson might come to collect considerable amounts of sensitive personal data such as names, user IDs, passwords, dates of birth, email addresses, and so forth.

What was the disclosure failure? As described in the SEC’s settlement order, Pearson suffered a data breach in late 2018 that resulted in the theft of student data and administrator log-in credentials of 13,000 school, district and university customer accounts. In total, the breach led to 11.5 million rows of student data and usernames and hashed passwords being stolen. 

Pearson executives knew the severity of that breach by March 2019. Still, a mid-year report issued to investors in July 2019 only discussed data breaches as a hypothetical risk; and a subsequent statement to the media — who, by then, had discovered the actual breach in 2018 — only said the breach might have included sensitive personal data, when the company knew that such data had in fact been stolen.

Those actions, the SEC said, qualified as misleading statements to investors. The SEC also said ​​Pearson’s disclosure controls and procedures didn’t assure that those executives responsible for making disclosure determinations were kept apprised of the circumstances surrounding the breach.

Pearson agreed to pay a $1 million penalty to settle the case, while neither confirming nor denying the charges. This is the latest SEC enforcement case over failure to disclose sufficient details about a cybersecurity incident, so clearly this is a sore point with the agency. Let’s take a closer look.

The Data Breach Details

The breach involved a Pearson product known as AIMSweb 1.0, a web-based application that allowed school districts to log and record students’ academic performance — so that’s one pile of personal data stored on Pearson servers. AIMSweb also had administrator accounts so school districts could use the product, which means it also had another pile of names, titles, user IDs, and passwords of school personnel entering the student data. 

Sometime in late 2018, “a sophisticated threat actor” targeted the type of web server that Pearson was using to run its AIMSweb application. The attackers were exploiting a known vulnerability in the web server’s code to execute commands remotely. The server manufacturer (we don’t know the company) had warned customers in September 2018 about that weakness, classifying it as critical and issuing a patch to fix it.

Pearson, however, did not implement the patch until March 2019, after it discovered the breach.

Let’s pause here to state, yet again, that patch management is a crucial part of cybersecurity. All businesses need procedures to implement software patches promptly, or any number of grave threats can come to pass. I’ve talked about this issue before, since Oracle and SAP both can be vulnerable to so-called “unauthenticated attacks” where bad guys can evade your access controls and raid your data. I’m not sure that’s what happened here, but Pearson’s failure to implement patches promptly put this chain of events in motion.

Anyway, back to Pearson. The attackers exploited that server vulnerability to steal troves of personal data stored in the AIMSweb application. On March 21, 2019, the FBI informed Pearson that it had discovered the stolen data, and provided Pearson a copy. So by that date, Pearson knew it had suffered a breach, and that 11.5 million rows of student data had been swiped. Roughly half of those stolen records included students’ dates of birth and 290,000 included email addresses, too.

For whatever reason, Pearson executives decided this breach did not warrant swift disclosure to the public. Instead, the company conducted an internal investigation, and mailed a breach notice to affected school districts on July 19 that their user credentials had been compromised. On July 25, management again decided that no public disclosure of the breach was necessary. 

Well, that didn’t last. The media broke the story of Pearson’s breach on July 31, 2019, and the share price dropped 3.3 percent on Aug. 1.

Misleading Statements About the Breach

Once Pearson knew the breach story was coming, it did issue a public statement on July 31 about the attack. That’s worth studying in detail because it offers examples of what the SEC considers misleading about a breach. For example…

Although Pearson had known for months that the attackers had actually stolen million rows of data from the AIMSweb 1.0 server, rather than just having obtained access to view the data, the statement referred to the incident as “unauthorized access” and “expos[ure of] data.”

The statement also said the compromised data “was isolated to first name, last name, and in some instances may include date of birth and/or email address,” even though usernames and hashed passwords of school personnel had also been taken.

The statement framed the lost data in hypothetical terms — “may include date of birth and/or email address” — when Pearson knew that roughly half the stolen records contained dates of birth and some 290,000 contained email addresses. 

And why is any of this material to investors at all? As the SEC order says:

The breach at issue was material because Pearson’s business … involved collection and storage of large quantities of private data on school-age children around the world. As Pearson acknowledged in its risk disclosures, Pearson “holds large volumes of personally identifiable information,” and its reputation and ability to attract and retain revenue depended in part on its ability “to adequately protect personally identifiable information.” 

We should also remember that according to the SEC’s guidance about disclosing cybersecurity events, a business doesn’t need to describe how an attack happened, in some manner that might divulge proprietary security procedures. But the company does need to disclose relevant facts about the severity of a breach — which didn’t happen here. 

The SEC also flagged Pearson’s statement about procedures to keep customer data safe: “Protecting our customers’ information is of critical importance to us. We have strict data protections in place and have reviewed this incident, found and fixed the vulnerability.” 

Except, those procedures weren’t strict. The company failed to patch a critical software vulnerability for six months, and had been using an outdated algorithm to scramble passwords. It’s a good example of the tricky issues at the intersection of cybersecurity and securities law. That is, if an internal audit flags weak cybersecurity protections, who then puts 2 + 2 together to say, “Yikes, we gotta tailor our risk disclosures to accommodate this finding until we get it fixed?” 

Somebody should consider those disclosure questions. Otherwise, as we see here, the SEC will do it for you.