Large organizations with ample resources quake in their boots over two common security threats. Here's your best defense
These days when I'm consulting with big businesses, governments, and other organizations, two main topics come up over and over: pass-the-hash attacks and hacktivism. One government client put it thusly: "Our department considers pass-the-hash attacks our No. 1 threat, above all other computer threats." A lot of things are broken in the security world, so to pick out one and call it the greatest threat is saying something, especially since the customer has what most readers would consider nearly unlimited funds, a multitude of competing vendor partners, senior management support, and a horde of experts with whom to discuss the problem.
Defending against pass-the-hash atttacks
The reason pass-the-hash attacks are so feared is that once the password hashes have been obtained, the attackers can move around the compromised environment with ease. Hashes can be used to access any protected resource within the same forest. Worse, if a domain admin has logged on to a computer, a local attacker with Administrator credentials can harvest the domain admin authentication hashes right out of memory.
[ Prevent corporate data leaks with Roger Grimes' "Data Loss Prevention Deep Dive" PDF expert guide, only from InfoWorld. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
I think it is the latter attack, the ability for an attacker to elevate themselves to domain administrator -- just because a domain admin had logged on to a box -- that scares defenders the most. Essentially, the trustworthiness of your domain admin credentials are now an exponential factor of every computer they have ever been used on.
How to fix it? The best way is to not have any domain admins. Even if attackers compromise elevated accounts, their access is less than elevated domain admin. And if they add themselves to the domain admins group, an alert will be generated quickly because your monitoring software will know that should be an empty group. Here are other actions you can take:
Never log on to a normal end-user workstation as a domain administrator. Limit your domain administrator logons to domain controllers or special file servers. By never logging onto regular workstations, you significantly reduce risk.
If you have to log on using domain admin (or other elevated credentials), always do so from a trusted computer. These are known as "jump" boxes. These jump boxes can be unique per user, virtual machined, and flashed cleaned after every use. The idea is to always log on to boxes that you know are clean.
Do as many administration tasks and fixes as possible using remote console tools, which are less likely to leave password credentials in memory on the remote computers. Most pass-the-hash attacks take interactive log-ons (unfortunately Remote Desktop and Terminal Services are interactive log-ons), so the less of them you do, the better.
If you have to interactively log on to a computer, after you are through, reboot the computer (if possible). Rebooting removes the credential temporarily stored in memory.
Frequently update elevated account passwords. I have many clients who change passwords after every use, often with the help of third-party software. That way, if an attacker grabs the credentials out of memory, so what? They aren't any good anymore.
The No. 1 way to prevent pass-the-hash attacks is to keep the bad guy from getting domain admin or local admin in the first place. After doing your best to achieve that, see how far you can get using the other recommendations above.
Best Microsoft MCTS Certification, Microsoft MCITP Training
at certkingdom.com
The looming hacktivist threat
Another growing fear involves hacktivism-style attacks. Most companies point to the malicious success of the Anonymous group. Each CIO I've spoken with is increasingly worried that determined adversaries will get access to data if they want it.
You might ask why they don't fear APT (advanced persistent threats) as much. They do, but most have already been through that pain and are living with the outcome and response. And unlike APT, which usually steals data silently, hackivists steal data or cause DoS attacks, and they publicize the fact to embarrass the entity and cause it to lose customers, trust, and money. In many circles, the publicity factor is worse than some city-state threat looking to steal intellectual property.
How do you defend against hackivist threats? Most attacks of this ilk begin with a compromised Internet-facing host or social engineering of credentials from a trusted employee. If you're worried about hackivists, start here.
First, conduct a penetration test on your outward-facing assets. Why let random attackers be the first to test your new Internet-facing application, server, database, or defense? Use your own testers and/or hire "red teams" to fill the role of the rogue hackivist.
Make sure all custom application code has undergone security development lifecycle creation and review. Make sure all your software is created from the ground up with security built in from the start and not as an afterthought.
Engage in strong antisocial engineering education for all end-users who are in a position to release credentials or protected information. Recently, I was asked to assess how well a large company's antisocial engineering education and policies were working to prevent hackers, calling in over the phone, from obtaining credential information or other employee-related data from administrative assistants.
At this company, the assistants are part of the first-tier support for such information, and they're all trained to ask for specific information and/or to check for confirmation with superiors before releasing such data. I was amazed with the results. Although the company has thousands of administrative assistants, often changing, each with varying levels of computer skills and malware awareness, the education program has been highly successful.
After hundreds of over-the-phone hacking attempts each year, as far as I know, only one hacker was successful in the course of the last decade in obtaining a password reset and none were in obtaining personally identifiable information. No one knows if every attempt (successful or not) was noted, but when going back and auditing accesses and password resets, we were able to verify that nearly 100 percent of them were legitimate and valid requests when reported as such, and vice versa.
I got to listen (or read transcripts) to many of the recorded phone calls of hackers trying to obtain protected information from administrative assistants. The calls went something like this: The hacker would always start by being as friendly as possible, while asking for access to confidential information or a password reset. When challenged to produce the verifying information, the hackers always became more hostile. The more the assistants resisted, the more the hackers challenged. Many times, by the end of the call, the hacker would explode in anger and threaten the assistant's job security. I wondered how well I would have handled such a call early in my career. It showed me that a well-run education program could work.
Of course, you can't rely on end-user education alone. I prefer systematic DLP (data loss prevention) solutions. DLP software monitors your content and traffic flows to prevent unauthorized access. False positives are still a problem, but recent improvements have helped.
Best Microsoft MCTS Certification, Microsoft MCITP Training
at certkingdom.com
