Did MCCCD leadership shut their eyes to a database security assessment for plausible deniability in litigation?

A former Maricopa County Community College District employee alleges executive leadership closed their eyes to a report on their database security conducted after their massive data breach in 2013 so they would have plausible deniability in any litigation. As a result, the employee alleges, the findings were never shared with those tasked with securing MCCCD’s data assets. 

In November 2013, Maricopa County Community College District (MCCCD) disclosed that they had been informed by the FBI that 14 databases with personal information had been found up for sale on the Internet. The potential compromise of 2.5 million students’, employees’ and vendors’ personal and financial information currently stands as the largest breach ever in the education sector.

As part of its continuing investigation into that breach, DataBreaches.net recently disclosed parts of a report issued by Stach & Liu in 2011 after an earlier hacking incident. Failure to properly remediate that breach had been cited as a factor in the 2013 breach. Of special relevance now, MCCCD’s external counsel had asserted that MCCCD administration at the highest levels never even knew of the report’s existence until after the 2013 breach. Their claim was disputed by former employee Earl Monsour, who stated he had delivered the report to the Vice Chancellor for ITS.

Today, DataBreaches.net can reveal that following the massive 2013 breach, there was a database security assessment that MCCCD has not shared with its own personnel nor the public.  Will MCCCD leadership claim they have never seen this report, too?  According to a former employee, if the Chancellor and executive leadership do claim they never saw this report, it is because MCCCD did not want to see it for fear it could hurt them in litigation.

According to the former employee who spoke with DataBreaches.net, Oracle had been brought in to assess database security following the 2013 breach, but  MCCCD subsequently tried to stop Oracle from delivering their report to MCCCD:

(MCCCD) made it clear that if they did not see it (the report), they could deny it… they then put Oracle on notice they were going to go after them as this was going to cause harm to their case.

There is no mention of retaining Oracle in MCCCD board minutes following the 2013 breach and no mention of Oracle conducting any security assessment in the timeline of steps Wilson Elser stated the District took following the breach. Wilson Elser’s timeline, submitted in November 2013, names Stach & Liu and Kroll Advisory Services and describes their roles, but never mentions Oracle.

The former employee claims that to MCCCD’s great upset, the Oracle report was delivered, but MCCCD leadership did not look at it:

To be clear – no one at MCCCD leadership saw this… did not want to see it… did not want it on their servers…  they were pissed to the max that this document was sent to MCCCD. The legal teams did everything in their power to never let this see the light of day… and it has not.  Therefore, nothing that was recommended by Oracle was done as part of the official MCCCD remediation plan.

It is one thing for lawyers to claim a report is privileged or work product and exempt from public disclosure or disclosure to any adversary in litigation. It is quite another thing for those responsible for securing tons of personal information to intentionally not read a report they presumably paid for and that might contain important vulnerabilities or problems that should be addressed to prevent future breaches. Should there be another massive data breach, and should it be determined that the vulnerabilities had been identified in Oracle’s 2013 report, the consequences to the District and taxpayers could be significant.

So what was in Oracle’s June 2013 “Database Security Healthcheck”  that MCCCD’s leadership allegedly did not even look at?

Because this blog does not want to provide hackers with a roadmap to attack MCCCD if MCCCD still has not adequately secured its network and systems, the full report will not be published here at this time. DataBreaches.net will, however, note just some of the problems the report identified (without the elaboration or recommendations that were provided in the report). The categorization as “severe,” “significant,” and “moderate” are Oracle’s labels:

    • “Network Not Secure” (Severe Risk category)
    • “Default Application Accounts PW Not Changed” (Severe Risk category)
    • “Unsecured Access to Servers” (Significant Risk category)
    • “No Tool SQL Injection Prevention” (Moderate Risk category)

As noted above, the preceding are just some of Oracle’s findings included in their report. In many cases, Oracle’s report described MCCCD’s then-current security for an identified issue as “none.”

Lack of Transparency a Long-Standing Problem at MCCCD?

Some of the issues raised in Oracle’s June 2013 report are the same issues Oracle raised in its April 2008 “Insights” report. To be fair to MCCCD, many of the issues raised in the 2008 report required vendor solutions or solutions were not even available at the time. The April 2008 report was submitted to MCCCD one month before MCCCD experienced an unrelated data leak in Peoplesoft due to a programming error that allowed any user to query the database for any of millions of users. Although MCCCD claimed that the exposure only affected people with the last name of “Gilford,”  former employees tell DataBreaches.net that they believe that the entire database could have been queried during the few weeks before the error was detected.

In 2011, MCCCD experienced a breach involving a MySQL database on public-facing web servers controlled by the Marketing Department.  While that breach was relatively small as such breaches go, sources tell DataBreaches.net that they felt “lucky” it wasn’t worse, and knew that if they did not secure the web servers, the next breach could be much worse. And it did get worse, they say, because MCCCD administrators ignored or rejected the advice of employees who tried to secure the system and who repeatedly urged MCCCD to quickly replace the badly compromised web servers. Yet, despite the fact that it had still had not replaced the compromised web server that had been brought back online, and despite the fact that its monitoring system was in shambles, the Vice-Chancellor of ITS gave a report to the Governing Board in March 2012 where the Board minutes reflect he asserted that the District was “very consistent” with the industry and things were “very good about where we are but we have a lot of work to do.” Nowhere in his presentation did he reveal how serious the situation actually was.

But it was not just the Governing Board who were being misled or given incomplete information by leadership about security concerns. In the process of investigating the 2013 breach, DataBreaches.net heard from several employees who said that MCCCD never shared Oracle’s 2008 report with them or Stach and Liu’s 2011 report after the 2011 breach. Why did MCCCD never share the Oracle 2008 with its ITS personnel at the time? Why didn’t leadership share the Stach & Liu 2011 report with those attempting to remediate the 2011 breach? [CORRECTION: The S&L report was reportedly shared with  the two ITS leaders of the Systems and Networking departments (who were responsible for the compromised server) as well as with the Vice Chancellor of ITS.]

As one of the former employees who quit in frustration put it:

I have to ask what motivation could they have to withhold information which could have been used to make the environment more secure?  We are not security experts, and designing and maintaining a secure environment costs money – not just applications but FTE’s.  We could not even get an upgrade done…any change associated with expenditure was vetoed almost immediately dating from 2010.

Truth is not really a part of the equation at MCCCD and I doubt it ever will be…

So despite Stach & Liu’s post-2011-incident report, despite state audits that repeatedly raised concerns about security controls that MCCCD had not addressed satisfactorily, despite internal reports and emails from ITS personnel urging MCCCD to deal with the problems more urgently, despite repeated requests for an external audit of the ITS department and the deteriorating work environment that resulted in MCCCD losing approximately 50% of its ITS personnel, and despite briefings of Chancellor Glasper and all members of his Vice-Chancellor group, MCCCD leadership did not ensure that the security issues were effectively addressed, all to the detriment of the millions of people whose personal information the District stored, and to the detriment of students and taxpayers.

The former employee writes:

“The question I have is this, what did they do in response to this ‘in your face’ information? The short answer was not much… if anything… They …. chose to move forward in a normal business fashion… no fire alarm, no urgency, nothing.”

And then, after the largest hack ever in the education sector, MCCCD’s Chancellor and high-level administrators allegedly tried to avoid acknowledging and disclosing Oracle’s  security assessment of their database security – to protect themselves?  Why wasn’t this report shared with everyone involved in trying to secure personally identifiable information in the wake of the 2013 breach?

DataBreaches.net reached out to MCCCD and asked them to respond to allegations that MCCCD tried to evade Oracle’s June 2013 report for litigation reasons.  They were also asked whether Chancellor Glasper and high-level administrators and the Governing Board ever read the Oracle 2013 report, and if so, when. After two requests, MCCCD’s District Director of Marketing and Communications responded that he was having trouble helping people identify the report in question, and could DataBreaches.net provide more details about the report. DataBreaches.net provided a few additional details, but never heard back from MCCCD after that correspondence last night. If a response or statement is received, this post will be updated.


About the author: Dissent

Comments are closed.