How to Stop Hack Attacks In One Easy Step: Whitelisting
Anonymous, LulzSec, and others have demonstrated time and time again over the past few months that hacking networks and compromising data is mere child's play. Does that mean there is nothing we can do, and that organizations should just accept inadequate security? No. At least one security expert believes that the answer to defending networks and data against the rise in attacks is simple--whitelisting.
The anatomy of recent hacks, and the reliance on precision, targeted, socially-engineered attacks makes them difficult--if not impossible--to defend against. Blocking unauthorized access to the network, and protecting data from external attacks is one thing, but if the attacker dupes an authorized, internal user into executing malware that grants access or gives the attackers the keys to breach the network and compromise data, there is little that can be done.
'Little' is not the same as 'nothing', though. There is a potential solution. In a blog post on Intelligent | Whitelisting, Richard Stiennon, author of Surviving Cyberwar and analyst at IT-Harvest, an independent IT security analyst firm, points out that a common denominator of malware attacks is that the malware executable is new, unknown software. A whitelisting solution would block such attacks from working, because the malware would not be on the whitelist.
What is whitelisting? Well, as I am sure you can guess, it is the opposite of blacklisting. Where blacklisting works by letting programs execute and run by default unless they are on the blacklist of banned applications, whitelisting bans all software from running unless it is on the whitelist of approved applications.
Stiennon recognizes that there are objections to whitelisting--too restrictive, too many false positives, administrative overhead to maintain. However, Stiennon says that whitelisting solutions continue to improve and evolve to meet the need. "Customers have encouraged vendors to accommodate to real world environments."
It seems like whitelisting requires more effort and babysitting by IT admins than the blacklisting approach. Every time a user wants to run some new application, they would have to go through the process of submitting the software for approval, and waiting for the IT department to add it to the whitelist in order for it to work.
That sounds daunting. But, look at the alternative. The blacklist approach means that users can execute software at will--even malicious file attachments. Whether the software is malicious, or causes more benign conflicts and issues, IT admins are then left to scramble to deal with the fallout and repercussions. The whole process is reactionary, and leaves networks and data exposed and vulnerable until after the threat can be identified.
Stiennon sums up: "Regardless of the perceived drawbacks [of whitelisting] there will come a time when the threat of compromise from targeted custom malware will outweigh those drawbacks. That time is now."