Vendor or GTA Responsibility?

Yesterday Computerworld reported of a breach that occurred at the Georgia Technology Authority (GTA) as a result of "An unpatched flaw in a ‚Äúwidely used security program.‚Äù" 

Some interesting tidbits from the article:

  • "involved a hacker who used ‚Äúsophisticated hacking tools‚Äù to break through several layers of security after accessing the server hosting the database via the software flaw"

Well, most of the widely available hacking tools are pretty sophisticated…and really require very little sophisticated knowledge on the part of the hacker using them to exploit vulnerabilities…allowing basically anyone to use them.  And, what is really meant by "several layers of security"?  Several different security products?  Or, just different features of this one "security program"? 

The vendor was not named, but the article reported the vendor had already "publicy disclosed" the vulnerability.  So, perhaps looking at CERT we can narrow it down?  The intrusion occurred "sometime between Feb. 21 and Feb. 23."  Look at the CERT vulnerability notes by date published…and the CERT technical security alerts…and the CERT technical security bulletins…hmm…definitely multiple possibilities through the bulletins…

  • "The breached server contained information on a total of eight pension plans administered by the state. The core database itself was managed by the state Employees Retirement System, though the server it was hosted on was administered by the GTA. At this point, there is no evidence that confidential information, including names, Social Security numbers and bank-account details, have been misused, Goldberg said.  Even so, the GTA is sending out letters to 180,000 affected employees for whom it has contact information, she said. The state does not have current addresses for the remaining 373,000 individuals affected and is relying on media reports and its own outreach efforts to inform them of the potential compromise of data, Goldberg said."

Well, as with past incident reports, indicating there is "no evidence" of information misuse is really not reassuring…there are virtually an infinite number of ways in which the data can be misused…most of those ways would not produce evidence…at least not right away…

Odd that the state could not find addresses on 373,000 individuals given they have their "names, Social Security numbers and bank-account details."

So…the debate continues…who is at most fault here…the security software vendor or the GTA…or both equally?  Did the vendor have good procedures in place to incorporate security into their entire SDLC…and thoroughly test before production release…their un-secure security software?  Did GTA not get the patch applied quickly enough…or did they have inadequate patch procedures?

  • "This is the second major breach involving the GTA in the past year. In April 2005, the GTA disclosed that a state employee had downloaded confidential information belonging to more than 450,000 members of the state’s health benefit plan onto a home computer."

Well…this is certainly another type of security issue altogether, but also one that is reported more and more.

  • "Since that breach, the GTA has implemented several measures to tighten security, including stricter password controls, more timely reviews of logs and alerts, more extensive employee background checks and stricter control of access confidential data, according to the GTA’s Web site."
  • Interesting, "more timely reviews of logs and alerts"

Just a few of many lessons that can be learned (again)…

  • Security product vendors need to be held to a higher standard to properly and thoroughly test their software before releasing it.  Things will still get overlooked, but hopefully many fewer.
  • Organizations should not rely upon only one security product…they should use layers of security from various vendors.
  • Organizations need to establish formally documented patch procedures and consistently follow them to ensure the most timely application possible based upon the vulnerability and the potential business impact.
  • Limit access to confidential information to only that necessary for specific groups/roles to perform job responsibilities.
  • Don’t allow entire databases of confidential information to be downloaded to mobile computing devices or employee-owned computers.  If for some reason this is necessary, strongly encrypt it.
  • Educate your personnel, on an ongoing basis and in a number of ways, about how they need to protect confidential data while they are performing their job responsibilities.
  • And so much more…

Technorati Tags

Leave a Reply