Data, the lifeblood of any organization, relies on the database as its beating heart. As a result, businesses invest heavily in designing and monitoring all access to it. In traditional literature, there are two types of users: administrative users, who manage the entire lifecycle of a database from design to security incident handling, and end users, who consume and update data with varying levels of permission. However, a more modern view would further distinguish the essence of the user, a human user versus an application user.

Consider a major financial institution that maintains sensitive customer information, such as banking records, account information, and credit ratings. Applications within the bank have elevated privileges and have access to all the data, for example, a backup service application. The bank also has accounts for various end users, including those who need high-level and cross-project privilege access to fulfill their jobs, like DBAs or developers, and others who require project-specific privileges. For example, a user experience analyst will probably require website click history data, rather than credit card information tables. 

What happens when these boundaries are not maintained? For example, consider an analyst who uses an elevated application account that exceeds his role’s access requirements. In addition to making himself an attractive target for hackers, think about the limitation of the security team to monitor a real data breach when it is unclear who the real privileged access owner is. This is a dream scenario for every hacker.

The Fine Line Between Security and Real-world Constraints

An ideal data access chain would clearly separate human users from application users by examining several characteristics including Source, Credentials, and Asset. 

Source

The user origin from which the client accessed the data. It can be, for example, the IP address it came from, its hostname, and the type of client (e.g. server, PC, or jump server). It is common for organizations to maintain clear distinctions between human and application clients, so, for example, specific address spaces will be reserved for applications and hosts will be referred to different naming conventions, for example, different prefixes and suffixes.   

In practice, maintaining consistency in naming conventions across departments or teams can be challenging, particularly in large organizations with many servers and users. Over time, changes in organizational structure or priorities can also cause inconsistencies, making it difficult to identify the source of a security breach.

Credentials

The security principle of least privilege (PoLP) states that each account should only have access to necessary resources. Accounts should be divided into personal accounts (for human users with limited privileges for their role) and service accounts (for applications with specific task privileges and access to sensitive information). In practice, personal accounts may acquire more credentials over time, while service accounts tend to have higher permissions than necessary to keep them up and running throughout the service lifetime and changes.

Asset

To ensure security, sensitive data accessed by applications should be separated from human access. The type of data and usage can be used to differentiate between databases for applications and those for human access. It’s best to have separate tables and permissions for sensitive data like credit cards, which will probably be accessed only by applications, and non-sensitive data that can be used by humans like sales data.

This is unlikely to happen in most cases. Developers may misuse high-privileged service accounts for faster maintenance, leading to untraceable data breaches. Alternatively, developers may run their new microservice with privileged personal accounts rather than creating dedicated accounts, making them vulnerable targets for hostile actors while increasing the risk. In both cases, convenience takes priority over security.

A Common Bad Practice 

Some parts of the data access chain are often abused in organizations. Based on our experience and the data we analyze, this phenomenon is quite common, especially in the credential and the asset parts of the data access chain, and mostly differ between one organization and the other by the magnitude of the phenomenon.

Let’s look again at the case of the large financial institution mentioned earlier, where humans regularly access application tables and accounts, demonstrated by a three-month database access log. The blue graph identifies the number of events in which human users abused a services account to access some available asset while the orange graph shows the number of reported security incidents in which the identified human user suspiciously accessed an asset that contained data normally accessed by applications. Identification of human users and application assets is done by Imperva’s DRA detection algorithms. We can see that these phenomena occur regularly, with an expected decrease during the weekends working off time. As mentioned, while this is just one example this synergy is actually quite common in many organizations.

Hackers are often drawn to application service accounts due to their elevated privileges and permissions to access sensitive data, making them a prime target. Among the most popular data breaches in recent news is the SolarWinds case. It took months for SolarWinds to discover that it was victimized by a cyberattack that spread to its clients. As part of the attack, malicious code was injected into Orion, a software system widely used by companies for managing IT resources. Over 33,000 customers use Orion, including several U.S. government agencies–  including the Pentagon. Attackers have been reported to have exploited 3 SolarWinds’ high-level privilege service accounts to perform lateral movement across the SolarWinds network and gain access to additional enterprise resources. The attack could have been prevented or at least blocked earlier if those accounts were monitored and protected for human-originating activity.

Here Is What Needs To Be Done. Today

Protecting an organization’s data and network requires separating highly privileged or automated applications from interactive human users.

• Prioritize security over convenience – don’t let administrators, including DBAs or system developers, use their own privileged accounts as service accounts, or vice versa.
• Make sure to separate all data assets and the path to them, when possible. 
• Make sure to be organized and define the appropriate source conventions according to the client type who accesses the data. 
• Keep in mind that providing everyone with permission to do only what they need to do in their day-to-day jobs will maintain security. 

Maintaining data path separation standards allows the organization to keep track of the data and all paths to it and to monitor suspicious activity more efficiently. With Data Risk Analytics by Imperva, you can use various pre-made detection tools to identify cases of abuse by both human and application users.

The post Breaking the Chain of Data Access: The Importance of Separating Human and Application Users appeared first on Blog.

*** This is a Security Bloggers Network syndicated blog from Blog authored by Amit Leibovitz. Read the original post at: https://www.imperva.com/blog/breaking-the-chain-of-data-access-the-importance-of-separating-human-and-application-users/