Step 2

: Prevention">
Security Step 2: PreventionBy Andrew Garcia
In 2001, eWEEK Labs focused security prevention advice on the need to harden outward-facing systems, particularly against external attacks. Six years later, protecting against external threats is still a priority, but administrators now must also look inward to reduce the risks posed by a companys own users.

Indeed, the threat landscape has changed significantly since 2001. Largely gone are high-profile worms crafted to make plenty of noise and cause outages that make way for stealthier attacks. Theyve been replaced instead by increasingly sophisticated and targeted attacks designed to steal data for financial gain. Attackers have found deceiving users to be a highly effective way to establish a foothold on a network, either for use as a way station for further attacks or for outright data theft.

Many organizations have likewise stepped up their user security training, but its still all too easy to make a bad choice-whether it is opening an innocuous-looking attachment, installing some innocent-looking but nefarious software widget or even simply clicking on the wrong link.
The real key to security prevention, therefore, is minimizing the amount of damage that unwitting users can do if and when they inevitably make a bad decision-specifically, by denying the user administrative control over the local system.
You can see the value of this strategy by looking closely at Microsofts December 2006 patch smorgasbord. The vulnerability details for the three critical updates (one each for Internet Explorer, Visual Studio 2005 and Windows Media Player) state the following: "An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights." This message is very common with Microsoft vulnerabilities.
While there are certainly tactics and exploits out there that an attacker could utilize to escalate privilege on a compromised host, limiting a users rights at least would make the process more difficult. Indeed, companies should now be considered negligent for unnecessarily allowing users local admin rights.
Microsoft has clearly recognized this. Windows Vistas UAC (User Account Control) feature strives to limit user privilege out of the box, requiring user approval or additional authentication to perform tasks deemed potentially risky to the system. This kind of system lockdown is also possible with Windows XP- and Windows 2000-based clients.
Of course, the most difficult part of adopting the LUA (Least-Privileged User Account) philosophy is getting poorly written applications to work properly with limited rights, but tools such as Microsofts Standard User Analyzer help identify where applications will run afoul of LUA. Other tools are available to then help administrators adjust credentials in a targeted fashion, increasing privilege levels only when and where absolutely necessary. BeyondTrusts Privilege Manager is just one such solution.
Of course, an attacker with user privileges is still a problem, as an established beachhead can be used to launch additional attacks. Companies must therefore continue to maintain-and even streamline-an effective patch strategy that encompasses not only the operating system but also third-party applications and drivers.
Patching is a now a reactive process, however, as the relationship between vulnerability, exploit and patch has been irrevocably altered within the last year. Administrators may have grown accustomed to the following standard "procedure": Microsoft releases a patch, thereby documenting a vulnerability; exploit code is then reverse-engineered from the patch and released into the wild, leaving a scant few days to test and deploy the patch.
But with the increasing amount of research into the security of Microsoft products-research that is performed by people wearing both white and black hats-vulnerability details and exploit code often are found in the wild well before an actual patch is released. This effectively eliminates the patch window, so administrators must work hard to streamline patch testing and deployment processes.
It is also now incumbent upon administrators to track and monitor lists of known, unpatched vulnerabilities (such as those at research.eeye.com/html/alerts/zeroday/index.html). Admins must evaluate the potential impact of these vulnerabilities to the network and weigh the costs and benefits of deploying temporary workarounds.
Loss of mobile data also remains a major concern, as weve seen from the numerous accounts of lost and stolen laptops that contained thousands or millions of personal records. The use of encryption products (for example, Check Point Software Technologies Pointsec or Utimaco Safewares SafeGuard portfolio) remains an obvious way to deal with this threat, securing files, folders or entire volumes from prying eyes when a device falls into the wrong hands.
But encryption is a workaround that ignores larger, systemic questions: Do the potential productivity gains from granting employees anywhere, anytime access to sensitive data outweigh the risks of this access? And, if so, is there a better way to manage the outflow of this information?
We feel a preferred alternate strategy would be to invest in data access through tightly secured Web services with control over who can access what from where. Network connectivity still has a way to go before it is ubiquitous enough to make this scenario a reality, but it should be a goal to have only a few core entry points to critical data.
Best practices: Prevention

Limit user privileges: Vulnerability exploits will have less attack surface, and there are less consequences to a users bad decision.

Patch: Its critically important to patch applications as well as the operating system; yet, sadly, there is less time for rigorous testing before deployment.

Monitor known vulnerabilities: The zero-day exploit environment is burgeoning, so admins need to stay on top of anything that affects their network and make cost-benefit decisions about deploying temporary workarounds.

Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developersÃÃÃ technical requirements on the companyÃÃÃs evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter companyÃÃÃs first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.