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.
I'm also a big believer in strong event monitoring and honeypots. If you can't prevent unauthorized data leakage, the next best thing is early warning. Design an event log management plan that will alert you to unauthorized or unexpected data access.
Lastly, keep your ear to the ground because many of the hackivist attacks are announced well ahead of time. One company spokesperson said it best: "I can't believe that they can advertise their coming hack in public, invite others to participate, and then get away with illegally accessing our data or disrupting our services, and think that it's a legitimate form of protest."
Believe it. The new threat landscape continues to evolve -- and we need to evolve with it.
This story, "The two most feared attacks and how to avoid them," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.