Taking a more tongue-in-cheek approach to highlighting the types of privilege misuse that occurs daily in applications and databases inside most organizations, I thought that a top-ten list approach might appeal to you as well. How may of these have you seen throughout your organization?
#10—Sam, the CSO, can now sleep nights knowing that inappropriate database activities are not only being monitored but also prevented via policy enforcement at a granular level.
#9—Fiona, the DBA, won’t be able to modify the production database instead of the test copy in the sandbox accidentally or even accidentally on purpose.
#8—Frank, your sole Application Developer, will no longer have to rewrite legacy applications in order to strip out any code requiring administrative privileges.
#7—Ted, the overzealous Tech Support Tech, won’t be able to upgrade your production database to the latest version of Oracle released today before the IT department has had time to vet the im- pact on current processes and attached applications.
#6—Ken, the CSO, can delegate database access based on access control policies that leverage external context such as SOX, PCI-DSS, and FFIEC compliance.
#5—Carl, the Compliance Executive, can now quickly identify all privileged users, review entitlements, and if necessary, de-provision obsolete users in order to pass your next enterprise IT audit.
#4—Francine, the COO, can now easily ensure adherence to change control processes across the extended enterprise for all databases and even reconcile with the change ticketing system.
#3—Larry, the new DBA, won’t have to call his predecessor, who is now serving eight years in the penitentiary for identity theft and attempted sale of your entire customer credit card transaction database, to learn the new processes for database activity monitoring (DAM).
#2—Beth in Human Resources won’t be able to forward the entire company payroll ledger to WikiLeaks because the CEO didn’t tell her how great she looked today.
#1—The IT department can still have the 35th annual birthday party next week for that payroll application that requires desktop admin rights, but no one knows where the source code is to make it more contemporary instead of replacing it outright.
The new California Data Breach Notification Bill (SB 24) mandating that holders of data notify consumers when their personal data has been breached went into effect at the beginning of this year.
The bill has been in the works for several years and as the number of exposed personal records continues to climb (currently estimated at about 500 million), the need to implement laws to protect consumers becomes increasingly more important. California is just one of 46 states with security breach notification laws, and the remaining few are sure to follow.
Last year saw at least 558 data breach incidents, costing U.S. businesses more than $6.5 billion. Deeper analysis of these public breaches found the average per business cost was $7.2 million. By now we all know that data breaches can happen in a number of ways: Criminal attacks, system failures or the most common culprit, accidental or intentional misuse of privilege by employees. With employee negligence being the number one cause of data breaches, having the proper privilege identity management tools in place shouldn’t fall into the category of “nice to have.” But if securing the perimeter within as a precaution for protecting data isn’t enough motivation, being faced with the possibility of a $7.2 million loss certainly should be.
By investing in the proper precautions to prevent these breaches from happening in the first place, companies can save themselves a lot of trouble, and money, in the long run.
Usually, the way we define and implement security is driven by compliance. But despite a wide number of frameworks from the Information Systems Audit and Control Association‘s (ISACA) Control Objectives for Information and related Technology (COBIT) to Payment Card Industry Data Security Standards (PCI DSS), those compliance standards aren’t very clear, leaving ample room for every auditor to interpret them differently.
When you dive deeper into the Ponemon study data, it shows that “cloud providers are most confident about their ability to ensure recovery from significant IT failures and ensure the physical location of data assets are in secure environments.” These are two areas where best practices and the compliance standards are well-defined.
On the other hand, cloud providers are “least confident in their ability to restrict privileged user access to sensitive data.” At least part of that lack of confidence can surely be attributed to the lack of a clear definition of privileged access and what the appropriate controls are.
Since many of the privileged users of a cloud system are the customer’s employees, it makes sense that this has got to be an area of shared responsibility between the cloud vendor and the customer. But who should do what and, ultimately, who’s in charge?
As I guide folks through setting up and using PowerBroker Windows Desktops I'm always thinking ahead, past the, 'Phase 1' deployment. A big part of this is sorting out your rule set, (Policies that dictate what elevation an application receives, or whether it is even allowed to execute), into collections.
A collection is a folder you create within your GPO where you put 'like' application rules into, or rules specific to a particular group. In other words, you may choose to create a collection for In-House created applications, or one containing a set of rules for Adobe software. In other cases, where you do need deeper control over who gets a set of rules, you can create a collection named after this group, for instance, Accounting, Engineering, Marketing, etc. In this latter case, you combine the convenience of collections with the control of Item-Level Targeting, just like what you use with MS Group Policy Preferences. I'll cover this more in-depth in a future post. For now think of Item-Level Targeting like the Security Filtering available in the MS Group Policy Management Console on steroids.
Whether you are just starting out with PowerBroker Windows Desktops or have been using the software to either mitigate the risk associated with over-privileged users or reduce support costs with under-privileged ones for awhile, think about your enterprise and how you can use collections.
- Do you have rules now that you put into a separate GPO because you need to make sure they only apply to certain situations?
- Do you have a list of rules and are having trouble remembering what all of them deal with?
Maybe you're like me and just need to put everything in it's place. These are just a few of the reasons to use collections. If you want more information on applying collections to your environment, just give us a call; we're here 24 hours a day/7 days a week.
Advanced Persistent Threat or APT is a buzzword for a class of targeted attacks usually aiming stealing of sensitive data. The attacks might be described as advanced due to multi-step phases and as persistent because of specific targets. A conventional attacker looks for passwords, ID info, credit card numbers and etc. where it is easier to find. While APT focuses on a particular information from a specific target.
Few examples of remarkable APTs:
- "Operation Aurora" resulted in IP theft from Adobe Systems, Juniper Networks, Rackspace, Yahoo, Symantec, Northrop Grumman, Morgan Stanley, Dow Chemical and Google who discovered that attack
- Leak of sensitive information related to SecureID two factor authentication products from RSA, The Security Division of EMC. The leaked information was used by attackers to penetrate L3 Communication, Lockheed Martin, Northrop Grumma and number of other companies
- Verisign has admitted being attacked and loss of sensitive data
- "Operation Shady RAT" victimized over 70 organizations.
Some experts say that nearly all Fortune 2000 firms have been compromised.
So, why million dollars budgets spent on equipment, experts, policies and compliance do not work? Why access control, encryption, firewalls, IPS, anti-malware and so on cannot detect and confine APT threats?
The answer is complexity. The IT infrastructure grows and gets out of control of regular policies. Besides, the conventional approach to APT largely relies on securing of the network rather than on protection of sensitive data itself. The reason is that traditional DLP (Data Loss Prevention) solutions fail to address such threats. The notable example is RSA, leading DLP vendor, that faced an IP theft. Even DLP vendors cannot maintain comprehensive DLP configuration capable to recognize and stop APT.
An APT always attributes to some detectable outlier activities. This is confirmed by the fact that most of APT successfully discovered after the fact. Thus APT steps might be spotted via anomaly detection. Let's consider mentioned IP theft from RSA. According to the disclosed attack anatomy the intrusion might be recognized through the following anomalies:
- Unusual amount of data sent via FTP channel,
- Unseen application (attackers backdoor) transferred archive file to an external location,
- FTP destination to which users never sent any data.
Not all anomalies indicate an attack but most of APTs cause anomalies.
The anomaly detection approach is leveraged by Active Profiler which is integral part of PowerBroker DLP. The Active Profiler monitors the behavior of end users and applications, creating baselines of normal activity for each of them. It automatically identifies and alerts on irregular patterns attributing to data leaks.
Taking a more tongue-in-cheek approach to highlighting the types of privilege misuse that occurs daily in cloud environments, I thought that a top-ten list approach might appeal to you as well. How many of these have you seen throughout your organization?
#10—Andy, the admin at <insert your public cloud provider name here>, won’t be able to use his admin privileges to your instantiation of a public cloud for data theft.
#9—Clara, your server admin, can’t instantiate a new server used for private cloud applications that will facilitate one business unit admin from poking in on the data from other business units’ instantiation of a cloud app on the same server.
#8—Sid in development won’t be able to code in a back door for privileged access to your hybrid cloud architecture.
#7—Harry, the industrious business unit admin, won’t be able to ““tune” your private cloud to what he read was “optimal” on Seth Grodin’s latest blog.
#6—Ted in Tech Support won’t be able to change cloud file per- missions without the proper policy-driven permissions just because it made his job easier today.
#5—Barney, the new business unit manager, won’t be able to blame “mistaken identity” for missing his quarterly goal because he read that was something that happens when cloud security goes bad.
#4—Sam, the CSO, won’t continue to lose sleep at night fretting over who can hijack admin privileges for any public, private, or hybrid instantiation of their corporate infrastructure.
#3—John, the CEO, won’t get called out in the press for a data breach after moving all data to what he thought was a secure, lower-cost private and hybrid cloud.
#2—Vito, a member of the hacker’s guild, won’t be able to take ad- vantage of the cloud streamlining the efficiency of identity theft.
#1—Bill, the chairman of the board, won’t have to explain why he needs to spend $1 million to fix a cloud data breach problem with the statement “at least it’s not as much as Sony had to spend for its breach.”
Contact us today if you are ready for least privilege for your public, private or hybrid cloud iniatitive.
Capping insider leaks is a top priority for the U.S. intelligence community – so much so that a “national insider threat policy” will soon be enforced. A Presidential Directive has already been issued ordering all departments and agencies to open an Insider Threat Program Management Office (PMO).
Yet while the government is ordering directives on capping the leaks, the top U.S. intelligence official said that it would take roughly five years to put into place new measures to stop insider leaks of classified information. Five years is too long of a time to resolve a critical security issue. Hackers have adapted and now hijack the credentials of over-privileged users as a method to gaining access to classified information. Anyone can get educated on how to wreak IT havoc after just spending a few minutes on YouTube.
Insider attacks have fundamentally changed the way we approach security. Billions of dollars have been spent over the last few decades on IT security in order to “keep the bad guys out,” but it turns out the bigger threat was and always has been, found within the network perimeter. The trusted employee, contractor or partner, can cost an organization more on a daily and/or per incident basis than any outside hacker could hope for.
Human nature is the weakest link when it comes to the intersection of people, processes and technology. In most situations it's more often than not the case that people have way too much privileged access - admin rights on the desktop, root password on server - for the role they are required to play.
Nope this is not a blog about sexual preference in the military. Nor is it a blog about what happened in Vegas during the last tradeshow you attended. It is a scary observation regarding what to do in the aftermath of a breach.
A recent article titled "IT Pros Believe Data Breach Harm Assessment Is More Valuable Than Victim Notification, Study Says" by Lucian Constantin in PC World stated "One of the study's most interesting conclusions was that while notifying victims and regulators are the most common steps taken by companies in the aftermath of a data breach, IT professionals don't view them as the most important actions for reducing the negative consequences of such incidents. Only 6 percent of survey participants said that victim notification is helpful for reducing the impact of a breach, a significant change of opinion compared to 2007 when 54 percent of IT professionals chose it as an important mitigation step."
The article goes on to also point out :"The Aftermath of a Data Breach survey also revealed that, despite making improvements to their data breach response practices, companies still have a long way to go as far as prevention is concerned. Only half of respondents believed that their companies made the best possible effort to protect customer and consumer information in advance of a data breach."
We have spent a lot of time in this blog talking about why prevention is always better than dealing with the aftermath of a breach, so isn't it time that you implement least privilege instead of playing your version of don't ask don't tell?
Anyone who has spent any time at all in the cyber-security space knows that hackers and creators of malware don't rest for an instant. The harder the IT security world works to stay ahead of the cyber-criminals (or, more accurately, to keep pace or catch up to them), the faster increasingly sophisticated attacks burst into corporate networks, infecting servers and endpoints and running IT teams ragged as they chase the threats and remediate the resultant carnage.
Why, with all the efforts IT organizations put forth to stop these external threats, do these attacks continue to rampage corporate infrastructures? Even if a company is spared the uncomfortable action of publicly acknowledging the loss of sensitive data through a breach, IT managers routinely sweat the close calls, the bullets dodged, the inevitable dalayed another day.
It's no surprise that many of these attacks prey on the desktop, where a single mistake in user behavior can bring upon a malicious attack in an instant. Laptops turned to botnet hosts. Trojan horses transported stealthily to corporate servers, poised to steal customer data. Viruses and worms launched and spreading through networks like wildfire. So IT teams (over 99% of them) religiously deploy anti-virus software and keep it updated. And that stops a lot of attacks - but not nearly all of them, or the worst of them.
Perhaps that's why more and more IT organizations are coming to a critical realization: that these attacks, while external in nature, often are brought on by internal people - often completely unknown to them. Just a single mistake in user behavior is all it takes.
When it comes to protecting employees from making such mistakes (preventing good people from doing bad things, you might say), it pays to consider a programmatic approach: adopt a least privilege strategy, granting users only standard rights but permitting elevation of privileges as required to enable them to do their jobs effectively. When you combine such privilege management with fine-grained application control (whitelisting), you add yet another layer of protection. After all, cyber-criminals are pros at getting people to do things they shouldn't. What better defense is there than removing the opportunity to take a risky action in the first place?
“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness…” these opening words of A Tale of Two Cities (1859), a novel by Charles Dickens, have always stayed with me. While these words were written over 150 years ago they resonate with me when I talk to IT security professionals. There is plenty of technology focused on IT security and yet through accidental or intentional misuse of privilege, data breaches still occur. Does our current age of security wisdom have us acting foolishly believing that our systems and data are secure? Do the security breach headlines reflect the weaknesses in IT security implementations?
Privilege access can be controlled and your critical business systems can be protected. Implementing least privilege for UNIX, Linux and Mac OS X systems will provide more centralized and better protection of your systems and data. Implementing least privilege will ensure that your staff doesn’t access systems using root and puts the checks and balances in place through centralized logging.
Many organizations use sudo as the first step to allow users to run programs with the security privileges of root. This is a good first step, however many organizations find that the manageability and security of sudo won’t meet their needs. The need to go to each machine to update sudoer files and to collect logs hinders the productivity of system engineers. The ability for the super user to alter sudo logs just doesn’t meet the security requirements of many organizations. What is required is a simpler more secure method to secure privileged access. Implementing a robust least privilege solution for UNIX, Linux and Mac OS X will provide centralized accountability, management and reporting and meet the compliance requirements of PCI DSS, HIPPA, FISMA and other regulations.
PowerBroker Servers least privilege solutions from BeyondTrust securely delegate privileges and authorization without disclosing the root password on UNIX, Linux, and Mac OS X platforms. PowerBroker Servers controls user activity flexibly and efficiently through fined-grained policies that can invoke virtually any action through scripting, from initiating an email approval workflow to validating a help desk ticket. PowerBroker Servers controls permissions transparently, ensuring user productivity without sacrificing security or compliance. PowerBroker Servers also logs all session activity down to the keystroke level to comply with internal and external compliance requirements. PowerBroker sudo converter makes it easy to migrate from sudo to PowerBroker Servers.
You can protectect your critical business systems by implementing a robust least privilege for UNIX, Linux and Mac OS X systems.
“Security can only be achieved through constant change, through discarding old ideas that have outlived their usefulness and adapting others to current facts.”
- William O. Douglas (1898 - 1980) U.S. Supreme Court Justice
