S.C. Security Blunders Show Why States Get Hacked
Governor blames data breach on Russian hackers and the IRS, but states' by-the-book IT ethos shows rules and regulations are the real culprit.
This holiday season, millions of people who live or work in South Carolina have a special treat in store: the potential for their identities and savings to get misused.
That's thanks to the state's Department of Revenue having stored 3.3 million bank account numbers, as well as 3.8 million tax returns containing Social Security numbers for 1.9 million children and other dependents, in an unencrypted format. After a single state employee clicked on a malicious email link, an attacker -- unnamed Russian hackers have been blamed -- was able to obtain copies of those records. The state has now urged anyone who has filed a tax return in South Carolina since 1998 to contact law enforcement officials.
How could this happen? After attackers owned South Carolina's revenue systems, they were able to conduct weeks of reconnaissance undetected. That's because the Department of Revenue had opted out of the state's optional intrusion-detection-monitoring program. Thankfully, the U.S. Secret Service spotted some identity theft cases and seems to have traced the stolen information back to state tax returns.
[ After a six-week silence, banks may again be under siege. Bank Attackers Promise To Resume DDoS Takedowns. ]
Why wasn't South Carolina better prepared? The answer is simple: the state's leadership, from the governor on down, failed to take information security seriously or to correctly gauge the financial risk involved. As a result, taxpayers will pay extra to clean up the mess. Beyond the $800,000 that the state will spend -- and should have already spent -- to improve its information security systems, $500,000 will go to the data breach investigation, $740,000 to notify consumers and businesses, $250,000 for legal and PR help, and $12 million for identity theft monitoring services. Of course, such services only help to spot ID theft; they don't prevent or fully resolve it. Taxpayers get to do that themselves.
Had the state done the right thing, it could have avoided the data breach and saved $13 million, which is a tad ironic, given that Gov. Nikki Haley holds an accounting degree from Clemson University.
Haley said the breach isn't the state's fault. Instead, she blamed the IRS, noting that while the state complied with IRS regulations, the IRS doesn't require stored Social Security numbers to be encrypted. Helpfully, the governor has now written a letter to the IRS recommending that it begin requiring that Social Security numbers get encrypted.
According to The New York Times, Haley has also claimed that a hacker somehow managed to breach the state's state-of-the-art security defenses. Then again, maybe not: In a press conference, she later admitted that the state's revenue systems not only lacked encryption and strong access controls, but also are based on a lot of 1970s-era equipment.
"This is a new era in time where you can't work with 1970s equipment," Haley said. "You can't go with compliance standards of the federal government."
Shocking news, and evidently the governor still doesn't understand information security -- or the folly of "security by compliance," that is, mistaking regulatory compliance with adequate information security.
South Carolina isn't the only state treating information security as an afterthought. Earlier this year, hackers breached a Utah state server, stealing the Social Security numbers of 280,000 people and health information for 500,000 state residents, none of which was encrypted.
Last year, Texas discovered that 3.5 million records, including people's names, mailing addresses, Social Security numbers, and in some cases dates of birth and driver's license numbers, had been exposed. None of that personally identifiable information (PII), which was available for a year on a public-facing website, had been encrypted.
How could the South Carolina breach happen in the wake of the Utah and Texas breaches? The answer seems to be weak rules and regulations. According to a former Texas state IT employee, "a major flaw that occurred in Texas with that data leak incident was the complete and utter failure of three agencies to properly secure their confidential PII per best practice, common sense and agreed-to methodology."
That's because the state's agencies used only information security practices and procedures explicitly required by chapter 202 of the Texas administrative code (aka TAC 202)."If their government code states they don't have to, or makes something an option, state agencies just don't and won't do it -- it costs time and $$$ tax dollars," said the former Texas state employee, via email.
Never mind if encrypting the data would require five minutes and common-sense thinking. "Yes, encrypting payloads with Winzip, 7Zip or GPG/PGP is way easy to do," he said, but without a rule or regulation, state agencies won't bother. On a related note, the state employee said he left for a private-sector job after his efforts to get the Texas Department of Information Resources to update TAC 202 to require encryption for data, whether it's at rest or in transit, were rebuffed.
Gov. Haley, by blaming the IRS for not requiring her state to encrypt Social Security numbers, has hit upon a solution to this problem: Put stronger rules and regulations in place. Require anyone who transmits or stores PII to encrypt the data, safeguard it with access controls and use intrusion monitoring to detect unfolding hack attacks. Just in case that move doesn't make government agencies' responsibilities clear, add extra penalties for any agency that suffers a data breach, regardless of the security controls it has in place. Maybe that step will finally stop the buck-passing and focus state governors' thinking on information security.
About the Author
You May Also Like
DevSecOps/AWS
Oct 17, 2024Social Engineering: New Tricks, New Threats, New Defenses
Oct 23, 202410 Emerging Vulnerabilities Every Enterprise Should Know
Oct 30, 2024Simplify Data Security with Automation
Oct 31, 2024