To Err is Human, to Secure is Divine

Confronting Human Error as an Insider Threat

Cyber-Ark Software – With reports of insider breaches continuing to make headlines, it’s clear that organizations are still struggling to protect high value targets such as databases, key operational systems and highly sensitive information. We are usually quick to blame a disgruntled or malicious employee, as a result, few of us actually stop to consider that an insider breach could be attributed to a seemingly innocent mistake. When it comes to managing privileged identities – those often anonymous identities belonging to IT administrators or database administrators who have unfettered access to critical applications, networks and systems – a simple mistake can lead to catastrophic consequences. So, we all know the saying “to err is human,” but can we rely on technology to decrease the consequences of human nature?

Not All Internal Threats are Created Equal

In its seventh annual security research study, the Computing Technology Industry Association (CompTIA), found that while most U.S. respondents still consider viruses and malware the top threat, more than half (53 percent) attributed their breaches to "human error," while only 47 percent attributed them to technical malfunction.

First, let’s examine the varying degrees of consequences related to human error. On one end of the spectrum, the impact of human error can have a negative impact on a consumer’s experience or company’s brand image. While we don’t want to diminish those negative results, consider the impact of a private contractor working for the Metro Nashville Public Schools who inadvertently disclosed the personal information of more than 18,000 students and 6,000 parents during a data migration in Metro’s student data management system. The information was unintentionally placed on an unsecured web server, which was searchable by the public. This mistake put thousands of individuals’ privacy at risk.

There are several processes and technologies available today that organizations can implement to encourage behavioral changes and establish better safeguards to prevent, or at least reduce, the impact of unintentional errors.

Beyond Password Management: Human Error and Application Identities as an Insider Threat

Most people are familiar with the security vulnerabilities caused by poor password management for individual users. While this side of the insider threat story is fairly well-documented, few organizations are aware of the risks posed by passwords hard coded within applications. Privileged application identities, those generic application IDs (such as AppID1) used by other applications, scripts, Windows services, batch jobs and more, represent serious threats because a simple user or programmer mistake could expose scripts or code leaving extreme amounts of sensitive database information open for all to see.

As background, when an application server, a single software application, a script or any type of batch process is required to connect to a database, a remote server or to another application service - a privileged user name and password are required and are therefore made available to the application. These credentials are most often stored embedded in the application code, or in a configuration file, many times in clear text visible to a large audience.

Consider an airline’s website where travelers can purchase tickets for an upcoming trip. Once logged in to his account and the traveler decides to make a purchase, the web application automatically logs into a database where the user’s credit card information has been stored. As you can imagine, this App2App environment is very sensitive given the powerful passwords that provide applications direct access to high-value information, such as financial data. If for some reason the developer of a script left code exposed or unsecured by mistake, it could lead to others being able to gain access to the database password, allowing them to get credit card data for malicious use.

In another example, consider the programmer who makes a change to a database password for the system she manages– thinking she is practicing good security protocol. What the programmer doesn’t realize is that a dozen other applications need access to that same database, and aren’t aware the password has changed. We recently heard of a story at a financial services firm where this really happened. The mistake cost the firm millions of dollars when multiple, high-volume transactional systems were inadvertently locked out of a critical database, simply because someone changed the password without letting others know.

One solution for securing applications is to eliminate the need to store application passwords embedded in applications, scripts or configuration files, and instead allow these highly-sensitive passwords to be centrally stored, logged and managed within a central server, while still allowing organizations to comply with internal and regulatory compliance requirements of periodic password replacement and monitored privileged access across all systems, databases and applications. Another solution is to enhance the organization’s approach to educating and increasing awareness among application developer teams and business units about the operational impact of effectively securing application identities.

Education and Awareness Can’t Be Taken For Granted

Despite the number of well-publicized breaches, CompTIA found that spending on security awareness and training went down slightly between 2008 and 2007. It may sound simple, but taking the time to educate employees about how to safely access and manage critical systems is equal in importance to clearly identifying the risks of not interacting with those systems properly in the first place. This includes ensuring privileged users, developers, programmers and others understand all the systems and applications that can be impacted by seemingly simple changes in an App2App environment.

For example, because many enterprises never change embedded application passwords, they open themselves up to serious security risks and clear violations of compliance regulations as these powerful, embedded passwords gradually become known to dozens of unauthorized personnel across the organization. Hard coded passwords also limit the ability to change passwords on these resources making them static and never expiring. Employees should be well aware of established practices for changing the password of a database account, and the required synchronization with all applications using that account for authentication.

Associated with training is proper communication about security policies. According to research done by Carnegie Mellon University’s Computer Emergency Response Team (CERT), policies or controls that are misunderstood, not communicated or inconsistently enforced can lead to serious insider threats. This means that organizations need to have clear documentation about policies and consequences of noncompliance; they must ensure employees have read and agree to the policies on a regular basis, especially as a company’s operating environment changes over time.

So, while all the technology and processes in the world won’t protect organizations 100 percent against insider threats, by better understanding the scope of where human error could occur and encouraging organizations to establish best practices and changes to users’ behavior, including halting bad habits such as sharing application scripts or code, they can close the gap. So yes, we all make mistakes and the risk of simple human error will never go away, but organizations can take some simple steps to lessen the frequency, and fall out.

About the author:

Adam Bosnian is the Vice President of Products and Strategy at Cyber-Ark Software (www.cyber-ark.com). He is responsible for the global product and business strategy of the company as well as for managing the North American sales organization. Adam can be reached at adam.bosnian [at] cyber-ark.com.

Top 10 Hot Internet of Things Startups
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies