SoylentNews is people
SoylentNews
from the if-you-are-allowed-in,-then-you-are-allowed-in dept.
Sean Gallagher reports at Ars Technica that Dr. Andy Ozment, Assistant Secretary for Cybersecurity in the Department of Homeland Security, told members of the House Oversight and Government Reform Committee that in the case of the recent discovery of an intrusion that gave attackers access to sensitive data on millions of government employees and government contractors, encryption would "not have helped" because the attackers had gained valid user credentials to the systems that they attacked—likely through social engineering.
Ozment added that because of the lack of multifactor authentication on these systems, the attackers would have been able to use those credentials at will to access systems from within and potentially even from outside the network. "If the adversary has the credentials of a user on the network, they can access data even if it's encrypted just as the users on the network have to access data," said Ozment. "That did occur in this case. Encryption in this instance would not have protected this data."
The fact that Social Security numbers of millions of current and former federal employees were not encrypted was one of few new details emerged about the data breach and House Oversight member Stephen Lynch (D-Mass.) was the one who pulled the SSN encryption answer from the teeth of the panel where others failed. "This is one of those hearings where I think that I will know less coming out of the hearing than I did when I walked in because of the obfuscation and the dancing around we are all doing here. As a matter of fact, I wish that you were as strenuous and hardworking at keeping information out of the hands of hackers as you are in keeping information out of the hands of Congress and federal employees. It's ironic. You are doing a great job stonewalling us, but hackers, not so much."
See our earlier stories: U.S. Government Employees Hit By Massive Data Breach and Hacking of Federal Security Forms Much Worse than Originally Thought
Original Submission
(Score: 5, Insightful) by schad on Thursday June 18 2015, @01:45PM
The answer makes sense on its face, but if you think about it then it all falls apart.
OK, so the access was gained by way of social engineering. Why on Earth would any user have the ability to download the entire database? There is exactly one user whose job responsibility might require that level of access: a sysadmin. And guess what? Sysadmins never need to look at the actual data. So encryption absolutely would help you. Yes, your sysadmin would be able to track down the decryption key on the app server, or wherever it lives; but an attacker wouldn't immediately know where to look for it, and he might not know to look at all. If the key is on another system, then at least you're forcing the hacker to gain access to that other system too. That other system might have different passwords, monitoring, etc., all of which increase the chances of detection or even stopping the intruder outright.
It's all part of the security onion. You don't count on any one safeguard to stop everyone. Your objective is to slow the attackers, which increases the odds that they'll be detected and gives humans a chance to do something. In this case, imagine if the compromised account had only been able to download 1000 employee records per hour. It's very plausible that an audit system would flag 24 straight hours of max-rate downloads and bring it to an admin's attention. The admin would contact the user, who would claim not to know what's going on, and the account would be locked. Bam, problem solved. Yeah, you would've leaked roughly 25k accounts, but that's a far cry from the millions that were actually leaked.
But, as we always end up concluding when stuff like this happens, security is hard. It needs to be baked in from the beginning, not tacked on after the fact. And it needs to be done by actual experts, not people who've taken a 6-week correspondence course and passed some certification exams. Even after all that's done, you need to continue to devote resources to security for as long as the system is in operation. (And probably for a while after: securely disposing of the data that was on the system.) Until everyone truly accepts that this is just the way things are, we're going to keep seeing breaches.
(Score: 3, Interesting) by iamjacksusername on Thursday June 18 2015, @03:55PM
You are right - security is hard. I think the problem is that we are getting the article filtered through the PR department. Unless we are looking at the audit report, it is impossible to say one way or the other. It could mean anything- maybe they compromised the admin's personal equipment so they could have retrieved the key anytime. Maybe they compromised the transit route before the data would have been encrypted. Who knows? We sure don't because we will never get to see the un-redacted report.
On a totally unrelated yet related note, I get a kick out of the fact that everybody is catching up to security practices that were baked into Novell Bindery Services by the late 80s. Seriously, the idea of audit accounts who can only monitor admin, admins who are super users but cannot monitor audit accounts, granular role controls. I remember taking my Netware 3.x classes and part of the story was that the audit role in the Bindery tree was added because of a CIA requirement that admins be monitored without being able to see what was being monitored or what accounts were monitoring them. I blame the move to AD for the complete breakdown in traditional security roles - AD had only a very limited understanding of inheritance and good luck trying to do anything with granular controls when MS was marketing it as manageable by any 2-bit reboot jockey.
Sigh. Someone is on my lawn and they should definitely get off of it.
(Score: 2) by c0lo on Thursday June 18 2015, @07:27PM
Sorry, can't do: those who are on your lawn have audit roles
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2, Insightful) by darthservo on Thursday June 18 2015, @04:34PM
It needs to be baked in from the beginning, not tacked on after the fact.
That's one of the major underlying problems in this case. Unfortunately it's not unique - a system that was designed decades ago and built from the ground up in an era and especially in a culture where much or proper consideration to security wasn't addressed until after it was in production. So these kinds of things do need to be tacked on later.
The result is that the process of getting more secure is slowed down significantly by compatibility/usability issues and also, as you addressed, lack of adequate experience. Because (and this is another underlying problem) what looks better from the perspective of unfortunately many higher ups: 'Our systems are running and the agency can function efficiently'; or 'We [ran|are going to run] into major problems while upgrading which [caused|will cause] significant downtime' ? As is common in many other industries, the favor is quite typically given to short-term focus.
A comment from Ars [arstechnica.com] also appropriately addressed the problem:
Congress: "it's all your fault for not replacing those archaic and insecure computer systems with the funding we refuse to give you!"
"Good judgment seeks balance and progress. Lack of it eventually finds imbalance and frustration." - Dwight D Eisenhower
(Score: 1) by unzombied on Thursday June 18 2015, @08:53PM
Certainly, considering the overwhelming dollars given to DHS for secret and non-secret activities, a shortage of funds is not the problem. Rather, the billions spent on US "National Security" are not going to the nation's security.
(Score: 2) by DeathMonkey on Thursday June 18 2015, @05:19PM
OK, so the access was gained by way of social engineering. Why on Earth would any user have the ability to download the entire database? There is exactly one user whose job responsibility might require that level of access...
They must have been valid credentials to the NSA's backdoor.