As the practice of recent months shows, the most common cases of data leaks in the financial industry are the consequences of unloading from corporate databases, which are often carried out by privileged users.
The reason is simple. Banks and any other organizations operating with such critical information as client data, including their personal data, usually pay very serious attention to the distribution of user roles. This includes the delimitation of access rights to both data and the functional capabilities of a particular business system. For example, information from CRM- (Customer Relationship Management) or ABS systems available to some employees may not be visible to others. These rights can be relatively easily managed and have their current list. But not a single information system and, importantly, the DBMS included in its composition can do without privileged user accounts – these are administrators, developers, and contractors. Given the widest access rights of these groups of people, the ability to monitor their actions is extremely important.
The difficulty is that it is not always possible to control user data requests at the network level. This can happen both because of the possibility of physical (local) connection to the database servers, if there is physical access to the data centers and server rooms, and in the case of connection via remote access protocols (RDP, SSH, and so on). It is for the control of such users and their typical connection methods that agent solutions for access control to databases are used.
What security features do agents provide for organizations?
Consider how agency solutions work and how they can be useful, using the banking sector as an example. The classical system of class DAM (database activity monitoring) is built on the principle of passive monitoring of user access to databases. Control at the network level gives the information security officer the opportunity to answer questions who made this or that request, when it was made, what the request was (it could be reading, deleting, changing) and what information the user received from the protected system.
In ideal cases, the information security officer in retrospect will see the same information that the user saw in his web browser or application. Most incidents in this case can occur due to incorrectly configured access matrices.
The complexity of controlling the activity of privileged database users is that they do not operate on the interface of business systems, but have access directly to the "raw data" located in the databases. In most cases, they are well aware of their structure, understand which tables, columns, queries should be made in order to obtain the necessary information bypassing the application.
In addition, agent solutions often help protect databases, as network traffic segments cannot be obtained by other means. The reasons may be different, they include:
- lack of network equipment capable of redirecting a copy of traffic to DAM systems;
- widely used virtualization technologies and private clouds built on their basis, when it is impossible to connect to physical equipment.
The principle of agent solutions
The introduction of any additional software on the database servers of key business systems always has a number of difficulties. These include the potential decrease in system performance, and the impact of agent software on the performance of the protected system, and so on. When developing agent solutions that are part of the database protection system and web applications Garda DB from Garda Technologies (part of IKS Holding), we take all these points into account. Thus, the additional load on the processors of database servers according to the results of various tests does not exceed 5-7%, and the necessary amount of RAM does not go beyond 2 GB. Given the architecture and the principle of the system, all additional load is projected only on local requests, since it is their control that is carried out at a lower level.
The practice of implementing agency solutions is different from passive solutions. Agent is an active decision, since it is put directly on the customer’s equipment. Therefore, in order to minimize concerns on the part of the customer, the introduction of agents into test databases becomes a necessary practice. As a rule, large companies have test benches that are close to “combat” in terms of load and content. Pilot projects give the client confidence in the correctness of the solutions, simplifying subsequent operation in real conditions.
A common question of security services is how to hide the work of agent software. The answer is simple, a technically savvy specialist can find any additional module embedded on the database server; moreover, it is often DBA administrators who are involved in installing agent solutions. Another question is that at the moment when something happens with the agent’s decision, the service is stopped or deleted, the security service receives an instant notification both via e-mail and through the SIEM system (security information and event management). Thus, it turns out to quickly respond to the shutdown of the agent and find out the cause of what happened.
At the moment, agent solutions of the Garda DB APK is a full-featured solution that allows you to control both local and network connections to all popular DBMSs installed on servers running the Red Hat, CentOS, Oracle Linux, Solaris, Windows Server, openSUSE family of OS as well as AIX. As practice shows, the implementation of agent solutions even as an additional module allows you to control user actions on all segments, forming a full-fledged base for retrospective investigations.
The practice of using agents is interacting with databases through local queries. Identification of calls to "sleeping" accounts
The customer’s automated banking system stores information about all accounts, all account balances and dates of the last requests for these accounts. Having access to this information, they often try to implement fraudulent schemes such as this one.
Attackers identified accounts on which a large amount of money was stored, this is a prolonged deposit account. That is, the owner rarely turned to him for any operations. Having access to information on the account and the data of its owner, the insider – an employee of the bank – transferred them to an external attacker to produce fake documents in the name of the owner. A dummy came to the bank and withdrew money from the account. The difficulty in identifying and investigating such an incident lies in the fact that the appeal of the rightful owner can occur after a long period of time.
The implementation of the database protection system made it possible to track all user requests and help in investigating the current incident even before the client contacted.
Subsequently, with the help of the Garda DB system, an information security officer set up policies, thanks to which a system alert is triggered even at the first unauthorized attempts to access data. This made it possible to quickly identify and level the consequences of such incidents.