Posted on March 22, 2011 by Adam Bosnian
As the security industry continues to look for answers and insight to RSA’s recent data breach, we found the security best practices suggested to SecurCare customers valuable for nearly every organization that shares, stores or provides access to sensitive data. We need to wait and see what emerges from this latest attack to see what vector was used – but we support and re-emphasize the response by RSA to its customers as it provides some valuable, current and real-world lessons every organization needs to follow.
Following are several that are particularly relevant to our customers and partners, including:
• We recommend customers enforce strong password and pin policies.
• We recommend customers follow the rule of least privilege when assigning roles and responsibilities to security administrators.
• We recommend customers pay special attention to security around their active directories, making full use of their SIEM products and also implementing two-factor authentication to control access to active directories.
• We recommend customers watch closely for changes in user privilege levels and access rights using security monitoring technologies such as SIEM, and consider adding more levels of manual approval for those changes.
Let’s dive into the concept of enforcing the rule of least privilege for end-users and security administrators– the idea being to provide only that amount of privilege necessary for a given activity. When applied to privileged accounts, those used by administrators or applications to access and manage key systems, applications and databases, it becomes a bit harder to do, since these powerful accounts often provide full, unfettered access to enterprise systems and applications.
However, what’s often overlooked is how these accounts can provide unwanted ‘escalation of privileges’ for Advanced Persistent Threat (APT) attacks. These access points, often in the form of embedded or hardcoded passwords, exist in almost every networked system, application or database. We saw this recently with the Stuxnet virus – entering in through an embedded credential in a SCADA system, as well as in the Operation Aurora attacks on several companies’ source code management systems.
While malicious outsiders and insiders have focused often on the administrative credentials on typical systems like servers, databases and the like, in reality, IT organizations need to identify every asset that has a microprocessor, memory or an application/process. From copiers to scanners, these devices all have similar embedded credentials that represent significant organizational vulnerabilities.
At the end of the day, the use of privileged access to exploit vulnerabilities such as hardcoded passwords is a very real threat that provides malicious hackers with new ways into the enterprise. It’s not just about ensuring that your system administrators are equipped with least privileged access, it’s something that every company—security vendors and enterprises alike—needs to recognize and proactively guard against.
What are some of your favorite security best practices, particularly related to managing, monitoring and controlling privileged access?
Grossly Underestimating the Privileged Account Security Problem Part 3: Automating Privileged Account Management and Cyber-Ark DNA™ (Discovery & Audit)
Posted on May 16, 2013
Grossly Underestimating the Privileged Account Security Problem Part 2: Defining Privilege with Cyber-Ark CMO, John Worrall
Posted on May 9, 2013
Posted on May 8, 2013
Posted on May 6, 2013
Posted on May 3, 2013
AP Hack & Social Media Accounts – Another Great Example of the Danger of Shared, “Privileged” Accounts
Posted on April 25, 2013
Posted on April 1, 2013
Posted on February 22, 2013
DoE Security Breach Proves No Organization is Immune to Advanced Threats and the Privileged “Insider”
Posted on February 15, 2013
Copyright 2013 Cyber-Ark Software - All Rights Reserved