WO2024251350A1 - Unauthorized database access detection using honeypots - Google Patents

Abstract

A method, system, and computer program product for unauthorized database access detection, the method comprising: by at least one processing unit, performing: generating for a database schema at least one honeypot field; returning the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and applying at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.

Description

UNAUTHORIZED DATABASE ACCESS DETECTION USING HONEYPOTS

BACKGROUND

Some embodiments described in the present disclosure relate to information security and, more specifically, but not exclusively, to unauthorized database access detection.

Computer systems control and/or facilitate many aspects of human life, from simple tasks such as text editing to complex and/or multifactorial endeavors such as infrastructure resource management of power plants, traffic lights, and/or the like. Network communication which may often be used by and in some cases may be even essential to basic functioning of many computer systems, may make such systems susceptible to various threats commonly referred to as cyber-attacks, i.e., deliberate attempts to gain unauthorized access to or harm proper operation of the system and/or any of its resources, carried out via a computer network and/or communication network connection. Such attacks may cause serious damages in monetary loss, and in extreme cases even result in grave injury or death.

One type of threats to digital data is commonly referred to as ransomware, a term that refers to malicious software developed to prevent its victims from accessing their own critical business resources until they pay a fee.

Ransomware usually infiltrates systems much like other forms of malware, typically involving the privileged execution of untrusted code delivered via email attachments, infected websites, instant messaging, and/or the like. Once established, ransomware may seek to discover and prevent access to resources of value while also spreading itself to other vulnerable systems.

Unfortunately, there may be no guarantee that access to these resources will be restored even if the victim decides to pay the fee demanded by attackers.

The potential impact of ransomware cannot be overstated. Infection can potentially result in temporary or permanent data loss, operational disruption, considerable expense, liability exposure, and reputation damage.

SUMMARY

It is an object of the present disclosure to describe a system and a method for unauthorized database access detection. The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to an aspect of some embodiments of the disclosed subject matter there is provided a method for unauthorized database access detection, comprising: by at least one processing unit, performing: generating for a database schema at least one honeypot field; returning the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and applying at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.

According to another aspect of some embodiments of the disclosed subject matter there is provided a system for unauthorized database access detection, comprising: a processing unit adapted to: generate for a database schema at least one honeypot field; return the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and apply at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.

According to yet another aspect of some embodiments of the disclosed subject matter there is provided a computer program for unauthorized database access detection, the computer program comprising program instructions which, when executed by at least one processor, cause the at least one processor to: generate for a database schema at least one honeypot field; return the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and apply at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.

Optionally, the at least one countermeasure action comprising at least one of: blocking the attempted access; analyzing the attempted access; applying the attempted access to a temporary database; returning a confirmation message; returning an error message; and alerting a user.

Optionally, deployment of a database client authorized to access the database schema comprising program instructions for removing from the database schema returned the at least one honeypot field.

Optionally, the database schema is a Structured Query Language schema.

Optionally, the query is a Structured Query Language query comprising at least one dynamic analysis operation on the database schema.

Optionally, the at least one honeypot field is generated ad hoc in response to receipt of the query. Optionally, there are further generated for the at least one honeypot field a plurality of honeypot values.

Optionally, in response to a query requiring for data retrieval of values of all fields of the database schema indiscriminately, there are generated the at least one honeypot field and there are further generated a plurality of honeypot values respective of each of the at least one honeypot field, and there is returned a result of executing the query on values of all fields of the database schema with the plurality of honeypot values of each of the at least one honeypot field added thereto.

More optionally, deployment of a database client authorized to access the database schema comprising program instructions for removing the plurality of honeypot values of each of the at least one honeypot field from the result returned.

Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which embodiments. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Some embodiments are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments may be practiced.

In the drawings:

FIG. l is a schematic illustration of an exemplary architecture for unauthorized database access detection, according to some embodiments; FIG. 2 is a schematic illustration of an exemplary flow of placing honeypots in a database table schema, according to some embodiments;

FIG. 3 is a schematic illustration of an exemplary flow of placing honeypots in data results of a database query, according to some embodiments;

FIG. 4 is a schematic illustration of an exemplary flow of honeypots detection, according to some embodiments;

FIG. 5 is a schematic illustration of an exemplary architecture for unauthorized database access detection with deployment of client-side honeypots component, according to some embodiments;

FIG. 6 is a schematic block diagram of an exemplary system for unauthorized database access detection, according to some embodiments;

FIG. 7A is a flowchart schematically representing an exemplary method of honeypots generation for unauthorized database access detection, according to some embodiments; and

FIG. 7B is a flowchart schematically representing an exemplary method of honeypots usage for unauthorized database access detection, according to some embodiments.

DETAILED DESCRIPTION

Some embodiments described in the present disclosure relate to information security and, more specifically, but not exclusively, to unauthorized database access detection.

One technical challenge dealt with by the disclosed subject matter is to provide for mitigation of information risks such as ransomware attacks and/or the like in the context of databases and/or database systems, such as Structured Query Language (SQL) database servers and/or likewise relational database management and/or manipulation tools and/or techniques, for example, the database management system SQL Server developed by and available from Microsoft Corporation of Redmond, Washington USA. Exemplary ways in which ransomware attacks may affect a database system such as the SQL Server and/or the like are described herein.

One common ransomware attack vector may be a file system of a computing device and/or storage service deployed on one or more machines. Cryptographic ransomware may seek to encrypt files so that these files thus encrypted can only be accessed again through use of a decryption key to be (ostensibly) provided once the ransomware attacker's demands have been met. Although SQL Server write-locks its database files while running, ransomware may attempt to halt associated system services to release those locks - or even reboot the machine in order to run before locks can be established.

Once database files are encrypted by ransomware, any attempts by SQL Server to attach to them will fail. The resulting error logs are often the first indication the victim receives that their database server has been compromised.

Another common attack may be in the form of the database manipulation attack where an adversary does not withhold access to and/or misappropriate the information and/or data, but instead makes subtle, stealthy tweaks to data for some type of gain. Such attacks can be just as crippling for organizations compared to theft and/or denied access. The ability of attackers to manipulate and shift data around may be a real threat, to an extent that there could be caused widespread financial and even physical harm as a result, if exercised successfully.

To illustrate, an exemplary database manipulation attack scenario is discussed herein. One example to be considered as a possible target on which malicious actors may purport to launch an attack is the stock market. Hypothetically speaking, if an attacker were to successfully breach the Information Technology (IT) systems and/or databases responsible for updating a stock ticker symbol and manipulate data to show a billion-dollar tech giant like Apple, Microsoft, Google or Amazon taking a nose dive, it would cause immediate chaos and panic would ensue. It could result in people selling off their stocks in a frenzy, as the culmination of a deliberate and effective attack.

Data manipulation attacks do not always have to result in a tangible financial gain. If an attacker managed to carry out a similar attack against health record information for patients in hospitals and altered critical data like drug dosages and prescriptions that need to be administered, it could result in sickness or even death.

These types of attacks are commonly carried out by malicious insiders, individuals who have privileged access to critical data in the first place. If an insider got their hands-on blueprints for a manufacturing facility that was being built, they could make minor modifications to drawings that could set the organization up for systemic failure. Understated and difficult to detect, an attack like this could ultimately put a company out of business and give a competitor, perhaps in an adversarial nation state, the ability to take over market share. Such occurrences have been seen to play out before more than once. When one may be required to address and/or deal with a “trusted” insider as the culprit, it makes it all that more difficult to detect and track down. One technical approach to cyber-attacks mitigation is to employ tools and/or techniques generally referred to as honeypots. In computer security terms, a cyber honeypot entails and/or operates by baiting a trap for hackers. It is a sacrificial computer system and/or resource that is intended to attract cyberattacks, like a decoy. It mimics a target for hackers, and uses their intrusion attempts to gain information about cybercriminals and/or the way they are operating, to distract them from other targets, and/or the like.

One exemplary manner in which a honeypot may work and/or be employed is as follows. The honeypot may be constructed to look like a real computer system, with applications and data, fooling cybercriminals into thinking it is a legitimate target. For example, a honeypot could mimic a customer billing system of a company and/or likewise enterprise resource, where such system may be a frequent target of attack for criminals who may want to find credit card numbers for fraudulent use. Once the hackers are in, they can be tracked, and their behavior may be assessed for clues on how to make a real network more secure.

As another example, honeypots may be made attractive to attackers by building in deliberate security vulnerabilities. For instance, a honeypot might have ports that respond to a port scan, weak passwords in authentication of human and/or machine entities, and/or the like. Vulnerable ports might be left open to entice attackers into the honeypot environment, rather than a more secure live network.

A honeypot may not be set up to address a specific problem, like a firewall or anti-virus. Instead, it may be an information tool that may help one to understand existing threats to a business and spot the emergence of new threats. With the intelligence obtained from a honeypot, security efforts may thus be prioritized and focused.

It would be appreciated that different types of honeypot may be used to identify different types of threats. Various honeypot definitions may be based on the threat type being addressed. All of them have a place in a thorough and effective cybersecurity strategy. Non-limiting illustrative examples may include one or more of the following:

-Email traps and/or spam traps, which place a fake email address in a hidden location where only an automated address harvester may be able to find it. Since the address may not be used for any purpose other than the spam trap, it may thus be 100% certain that any mail coming to it is spam. All messages which contain the same content as those sent to the spam trap can be automatically blocked, and the source Internet Protocol (IP) address of the sender(s) can be added to a deny-list. -A decoy database, which may be set up to monitor software vulnerabilities and spot attacks exploiting insecure system architecture or using SQL injection, SQL services exploitation, or privilege abuse.

-A malware honeypot, which mimics software applications (apps) and/or Application Programming Interfaces (APIs) to invite malware attacks. The characteristics of the malware may then be analyzed to develop anti-malware software or to close vulnerabilities in the API.

-A spider honeypot, which may be intended to trap web-crawlers (generally known and/or referred to as “spiders”) by creating web pages and links only accessible to crawlers. Detecting crawlers can help one to learn how to block malicious bots, as well as ad-network crawlers.

It would be appreciated that by monitoring traffic coming into a honeypot system, a user may assess for example one or more of the following:

-where cybercriminal(s) may be coming from

-a level of threat

-what modus operand! cybercriminal(s) may be using

-what data and/or applications cybercriminal(s) may be interested in

-how well one’s security measures may be working to stop cyberattacks

There are pre-existing approaches to counter data manipulation attacks such as illustrated by the following exemplary tools and/or techniques.

One way to counter data manipulation attacks may be to check integrity of the data on respective systems. In fact, a majority of large companies in recent years have been known to use either hashing or integrity checking. As a result, this approach assures that no error occurs during the restoration of data. Similarly, it has been suggested that backups may be considered as an effective tool of protecting data from manipulation, among other modem security features. It may happen that an error occurs while implementing the data storage and/or during the data restoration process. However, in such cases, integrity checks may be implemented to fix the issue.

Another way and/or feature of a file integrity monitoring (FIM) system may be issuance of alerts when data manipulation occurs. Additionally, this feature may give the FIM system an edge compared to a backup system, since the backup system may not send alerts. Further, the FIM system may also determine what data had been manipulated.

Yet another approach may be to counter data manipulation attacks through endpoint visibility. In this approach, a consumer may be assured by a supplier on risk that their Information Technology (IT) systems have endpoint visibility. For instance, imagine an attacker succeeded to access the network. As a result, the supplier needs to move sideways over the environment to search for vulnerable data. Threat hunters and incident respondents must chase the forensic footsteps. Indeed, it is their job to quest and encounter such invasion before any data damage or manipulation occurs.

Yet another approach may be that of logging activity which may also provide security against data manipulation attacks. However, activity logs may not be highly effective. Therefore, IT teams may be required to design the internal supervision to verify the information and may need to continually monitor the prioritized logs.

Yet another approach may be to implement encryption. As implementing encryption may be associated with an integrity check, enforcing encryption to secure confidential data may also engender integrity checks. Encryption is not widely used among business sectors and/or the like.

The pre-existing approaches to detection of data manipulation cyber-attacks suffer from several shortcomings and disadvantages. In particular, such detection tools and/or techniques are mainly based on how to minimize the negative effects after the attack already occurred.

According to some embodiments of the disclosed subject matter, there is provided a type of honeypot adapted to counter data manipulation attacks, in which fake database values and/or fake database attributes may be provided and/or injected to search results returned in response to a database query. A honeypot in accordance with the disclosed subject matter, which may be specifically adapted for use in relational databases such as for example SQL Database, may entail placement of fake column(s) and invitation of an attacker to manipulate such fake column(s). All operations which contain access to and/or otherwise involve the fake column(s) trap, may thus be readily detected and acted upon, for example, such operations may be automatically blocked, a source IP of the perpetrators and/or other actor(s) to which the operations are traced may be added to a deny-list, and/or the like.

Data manipulation attacks may target financial, healthcare, and/or government data. In particular, many leading industries may be highly vulnerable to such attacks.

The disclosed subject matter may be employed to detect and block data manipulation attacks on relational databases such as SQL Database and/or on databases that expose SQL-like API (e.g., several NoSQL Databases prevalent in industry usage may expose SQL API).

SQL (i.e., Structured Query Language) is a programming language used as an interface to manage databases. Various organizations use SQL systems to view and manipulate the information and data contained in their files, as well as to create and modify new tables. To truly comprehend SQL, it is essential to first understand what a database is. A database is a tool for gathering and storing records. Databases can hold data about individuals, goods, orders, and everything else. Many datasets begin with a word processing application or spreadsheet, but as they grow in size, many database owners and/or custodians may find it beneficial to migrate the data to a database generated by a database management system.

In a SQL database, a schema is a list of logical structures of data. A database user owns the schema, which has the same name as the database manager. A schema is an individual entity (container of objects) distinct from the user who constructs the object. In other words, schemas are similar to separate namespaces or containers used to handle database files. Schemas may be assigned security permissions, making them an effective method for distinguishing and defending database objects based on user access privileges. It increases stability of the database for security-related management.

An illustrative exemplary SQL schema is provided herein as follows. Consider the following sequence of commands and/or queries:

CREATE SCHEMA STUDENT AUTHORIZATION STUDENT

CREATE TABLE DETAILS (

IDNO INTEGER NOT NULL,

NAME VARCHAR(40),

CLASS INTEGER)

The first instruction will create a schema named as STUDENT and with user STUDENT as the owner of the schema. Further, the second instruction will create the table named DETAILS under the STUDENT schema.

The following exemplary SQL statement can be used by a user to retrieve the schema information from the SQL database:

DESCRIBE STUDENT DETAILS

The output returned may be as in the following table, denoted herein as Table 1 :

In order to retrieve the values from the database table, the caller can either specify explicitly the name of the fields as in the following exemplary query:

SELECT IDNO, NAME, CLASS FROM STUDENT. DETAILS

Alternatively, the caller can use the term * to retrieve all the fields from the database table, as in the following exemplary query:

SELECT * FROM STUDENT DETAILS

According to some embodiments of the disclosed subject matter, one or more honeypot fields, namely fake fields that are not really present in the actual database, may be placed in a result returned in response to suspect database queries and/or operations, for example, to the query schema (DESCRIBE table) and/or to the query data (SELECT * FROM) statements. The fake fields may be tracked for any subsequent access attempts by the caller, i.e., any and/or all further queries and/or commands submitted by the caller may be checked to determine whether the caller may be trying to access (e.g., write, update and/or read) one of the fake fields (i.e., the honeypot). Detection of such (attempted) accessing to a fake field may indicate a high probability for cyber security attack. As a result, one or more countermeasures may be taken, such as for example, triggering an alert, blocking the caller immediately, and/or the like.

In some embodiments, a suspect query and/or operation may be any database command to retrieve and/or provide data in an indiscriminate and/or oblivious manner to any one of particular data fields of an underlying database schema, such as for example, data retrieval of values of all fields of the database schema indiscriminately and/or without specifically addressing any field by its respective name and/or designation, as is the case where using the SQL query operation “SELECT” with the asterisk operator, so that all fields with their values content are retrieved in result. Similarly, a query on the database schema may entail a request for data on all fields be provided without specifically referencing any field by name, as is the case where using the SQL query schema operation “DESCRIBE” or “DESC”. Additionally or alternatively, the suspect query may attempt to dynamically analyze and/or parse the database schema by one or more operations. Such indiscriminate data retrieval and/or schema data request may be indicative of a lack of any prior knowledge on the database and/or contents thereof that a legitimate user may be expected to possess, and thus giving rise to a high probability of malicious activity by an originator of statements of this sort.

In some embodiments, countermeasure actions in response to detection of attempted access to the honeypot field(s) may include one or more of the following: blocking the attempted access; analyzing the attempted access; applying the attempted access to a temporary database; returning a confirmation message (without performing a database operation as requested); returning an error message (e.g., in case it may be desired to let an attacker know that a launched attacked may have failed, thus dissuade them from sending further requests); and/or the like. Additionally or alternatively, an alert may be issued, e.g., an administrator, analyst, data protection officer, and/or the like may be notified accordingly, so that ramifications of the attempted access detected may be assessed and/or further handled through proper channels. Optionally details and/or information gained by analysis of the attempted access may be further acted upon, for example, an originator device and/or source IP address to which the attempted access may be tracked, may be recorded for future reference, e.g., blacklisting the device and/or address from further accessing to the database and/or other resources, forensics purposes such as reporting and/or handing over evidence in the conduct of investigation of cybercrime by authorities, and/or the like.

In some embodiments, honeypots generated may include both the fake field(s) to be added to the original database schema as well as fake data values for each fake field. Optionally the fake field(s) and/or respective fake values may be generated ad hoc in response to a query schema and/or query data of a type deemed as suspect, such as discussed herein. Alternatively, the fake field(s) and/or respective fake values may be generated in advance, in whole or in part, and retrieved from storage for usage whenever a need may arise.

In some embodiments, a deployment of an authorized database client may include an installed and/or packaged component such as a Software Development Kit (SDK) and/or the like adapted for honeypots removal from data results returned in response to database queries and/or operations. Such component may be provided so as to allow dynamic analysis and/or parsing of the database schema and/or contents without the authorized database client failing due to added honeypot field(s) and/or honeypot values.

Other technical challenges, approaches, and/or effects dealt with, improved upon and/or contributed by the disclosed subject matter may become apparent from the disclosure herein. Before explaining at least one embodiment in detail, it is to be understood that embodiments are not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. Implementations described herein are capable of other embodiments or of being practiced or carried out in various ways.

Embodiments may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the embodiments.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of embodiments may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of embodiments.

Aspects of embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/ acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the fimctions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to FIG. 1 which is a schematic illustration of an exemplary architecture for unauthorized database access detection, according to some embodiments.

As shown on FIG. 1, an unauthorized database access detection system architecture may comprise a database server, a database client, a honeypots generator, and a honeypots detector. The database server and/or database client may be, for example, relational database server and client commercially available and/or otherwise as known in the art, such as SQL Database server and client and/or the like. The honeypots generator and the honeypots detector may be components provided as a further layer added in-between the database server and database client, e.g., as a database interface, wrapper, and/or the like, each constructed and deployed as described herein. The honeypots generator may be responsible for generating honeypots to be implemented on results on executing SQL queries and/or operations on the database, i.e., placed therein, injected thereto, and/or the like, whereas the honeypots detector may be responsible for detection of honeypots accesses indicative of unauthorized access attempts possibly related to cyber-security threats such as malware attacks and/or the like. The honeypots detector may intercept incoming queries and/or requests to the database server for performing a database operation (specifically, SQL operation and/or the like) and detect any suspect activity such as an attempted access to a honeypot previously set by the honeypots generator, such as described herein.

Reference is now made to FIG. 2 which is a schematic illustration of an exemplary flow of placing honeypots in a database table schema, according to some embodiments.

As shown on FIG. 2, an operation on the database comprising a statement such as “DESCRIBE TABLE” in SQL and/or the like, which may be and/or comprise a query on a table schema of a database, thus requesting a description of the fields (i.e., columns types and/or attributes etc.) in the table, may be sent to and received at the database server from a database client and/or an actor perceived as such. The database server may return in result a table such as illustrated on FIG. 2 and similarly to the exemplary output table schema as discussed herein with reference to Table 1 (last column omitted for better clarity).

The honeypots generator component may intercept the original table result returned from the database server and generate one or more honeypot fields to be appended to table. For example, as shown on FIG. 2, the honeypots generator may place a new field, called INCOME, in the schema returned to the caller, i.e., the database client. A legitimate actor such as a regular application and/or the like deployed at a client side (the database client) may not be expected to use the new INCOME field, because the application may not be aware of this field. However, a malware application and/or other malicious actor may use this field because such application and/or actor may not differentiate between the original fields and the honeypots.

In order to make the honeypots attractive for the attackers, the honeypots generator may use terms and/or strings from a pre-configured dictionary of fake field names, optionally descriptors of confidential and/or sensitive information, such as for example: income, salary, password, key, passport ID, and/or the like.

Reference is now made to FIG. 3 which is a schematic illustration of an exemplary flow of placing honeypots in data results of a database query, according to some embodiments.

As shown on FIG. 3, an operation on the database comprising a statement such as “SELECT * FROM TABLE” in SQL (also known as “SELECT ALL”) and/or the like, which may be and/or comprise a query requiring for data retrieval of values of all fields in a table schema of a database indiscriminately (i.e., data values in all columns of a table queried), may be sent to and received at the database server from a database client and/or an actor perceived as such. The database server may return in result a table such as illustrated on FIG. 3 and where each row entry contains respective values for each of the fields in the table schema. For illustrative purposes and ease of understanding, the exemplary original table result returned from the database server and contents thereof shown on FIG. 3 correspond to the exemplary table schema of FIG. 2, as indicated in the headline row denoting the field names.

The honeypots generator component may generate one or more honeypot fields and may further generate respective values for each of the honeypot fields thus generated to be appended to table in each row entry of the table. For example, as shown on FIG. 3, the honeypots generator component may place a new field, called INCOME, and may further place new values for the new field at each row entry of the table, in the result returned to the caller. Similarly as discusses herein with reference to FIG. 2, legitimate actors such as regular applications and/or the like deployed at a client side (the database client) may not be expected to use the new INCOME field, because the application may not be aware of this field. However, a malware application and/or other malicious actor may use this field because such application and/or actor may not differentiate between the original fields and the honeypots.

Again, and similarly as discussed herein, in order to make the honeypots attractive for the attackers, the honeypots generator may use terms and/or strings from a pre-configured dictionary of fake field names, optionally descriptors of confidential and/or sensitive information, such as for example: income, salary, password, key, passport ID, and/or the like.

Furthermore, in order to accord the honeypots credibility at the least from an attackers’ perspective, the honeypots generator may use values that reliably simulate and/or approximate actual, real-life values such as for example, by using random samples with probability distributions akin to those in general populations and/or the like.

Reference is now made to FIG. 4 which is a schematic illustration of an exemplary flow of honeypots detection, according to some embodiments.

As shown on FIG. 4, a malware application acting as the database client may send a request to perform a database operation involving unauthorized access, such as trying to update the field, called INCOME, which may be the field that was added as a honeypot by the honeypot generator, as discussed with reference to FIGS. 2 and/or 3. The honeypot detector may detect this operation, and respond with one or more countermeasures, such as for example, block the operation as illustrated on FIG. 4, send an alert to an IT administrator, and/or the like. Optionally, the result returned to the attacker may be either a confirmation such as “OK” and/or the like, if one does not want to expose the detection to the attacker at least for the time being and rather continue to collect information on the attacker and/or the pattern of the attack, or the result may be an error message such as “ERROR” and/or the like, to cause the attacker to cease the attack and divert their efforts elsewhere. The one or more actions taken by the honeypots detector in response to detected data manipulation attempts such as described herein may be configured by a user (e.g., IT administrator and/or the like) and allow different set of actions and/or any combinations thereof, such as for example: (1) block and return OK; (2) block and return Error; (3) apply to a temporary database (for further analysis); etc.

It will be appreciated that detection of honeypots access may not require necessarily that an attacker address and/or refer to a honeypot field explicitly, i.e. by its name, as in the exemplary update operation illustrated in FIG. 4, but rather implicit referencing may also be detected, for example, in case that an attacker following an indiscriminate data retrieval such as illustrated on FIG. 3 may attempt to update a row entry by specifying substitute values for that row, also including values for columns that do not exist in the original table schema (the honeypot fields), even such an implicit honeypot access and/or operation of this sort may be revealed by the honeypots detector as well and similarly handled as discussed herein.

Reference is now made to FIG. 5 which is a schematic illustration of an exemplary architecture for unauthorized database access detection with deployment of client-side honeypots component, according to some embodiments.

It will be appreciated that, while for most of the regular, legitimate applications, the honeypot fields as generated by the honeypot generator according to some embodiments may be transparent and harmless. However, there might be applications that may be trying to parse, analyze, and/or likewise process the schema dynamically and thus might fail due to the newly added honeypot fields.

As shown on FIG. 5, another deployment of a system architecture in accordance with some embodiments may comprise a client-side component such as a Software Development Kit (SDK) and/or the like, optionally comprising program instructions for honeypots removal from query results. In this alternate and/or additional kind of deployment, the SDK library and/or a similar component integrated in and/or in communication with the database client application program may drop the honeypots such as the ones generated and/or added to a query result by the honeypot generator and instead return the original result, i.e., as provided by the database server initially, to the calling application. Malware application which does not use the honeypots SDK may thus still get the honeypots in the results.

Reference is now made to FIG. 6 which is a schematic block diagram of an exemplary system for unauthorized database access detection, according to some embodiments.

A system 600 for unauthorized database access detection may comprise an apparatus such as 601, which may be implemented as, for example, a standalone unit, a server, a computing cloud, a desktop computer, a laptop computer, a tablet computer, a smart phone, a wearable computer, a mainframe computer, a quantum computer, and/or the like. The apparatus 601 may be implemented as a customized unit that includes locally stored software and/or hardware that perform one or more of the acts described with reference to FIGS. 1-5, 7A and/or 7B herein. Alternatively or additionally, the apparatus 601 may be implemented as code instructions loaded on an existing computing device. Alternatively or additionally, the apparatus 601 may be implemented as hardware and/or code instructions (e.g., an accelerator card) installed and/or integrated within an existing computing device.

The apparatus 601 may comprise one or more processors such as 612, which may be implemented on, include, utilize and/or otherwise facilitate one or more hardware modules (elements), for example, central processing unit(s) (CPU), graphics processing unit(s) (GPU), field programmable gate array(s) (FPGA), digital signal processor(s) (DSP), circuit(s), component(s), integrated circuit(s) (IC), application specific integrated circuit(s) (ASIC), artificial intelligence (Al) accelerator s) and/or the like. The processor(s) 612 may include one or more processors (homogenous or heterogeneous), which may be arranged for parallel processing, as clusters and/or as one or more multi core processing units. The processor(s) 612 may execute one or more software modules such as, for example, a process, a script, an application, an agent, a utility, a tool, an Operating System (OS), and/or the like, each comprising a plurality of program instructions stored in a non-transitory medium (program store) such as the memory 618 and executed by one or more processors such as the processor(s) 612.

The apparatus 601 may comprise a network interface such as 614 which may comprise one or more wired and/or wireless network interfaces for transmission and/or receipt of data over one or more wired and/or wireless networks such as 605 and/or any other likewise suitable communication channel(s). The network 605 may be any type of data network, for example, a local area network (LAN), a wireless LAN, a wide area network (WAN), a Metropolitan Area Network (MAN), a cellular network, the Internet, and/or the like. The wireless LAN may use one or more wireless protocols, including Bluetooth, Bluetooth low energy (BLE), 802.11 compliant wireless local area network (WLAN), and/or any other wireless LAN protocol. The network 605 may use networking protocols, for example Transmission Control Protocol and Internet Protocol (TCP/IP), Asynchronous Transfer Mode (ATM), asymmetric digital subscriber line (ADSL), and/or any other networking protocol. The network 605 may comprise one or more wired and/or wireless routers, hubs, smart hubs, switches, smart switches, and/or any other type of networking equipment. The apparatus 601 may comprise and/or be in communication with one or more input and/or output (I/O) devices such as 616 for receiving input from and/or providing output to a user. The communication with the I/O device(s) 616 may be, for example, over the network 605 via the network interface 614 and/or via another suitable I/O interface (not shown) which may comprise wired and/or wireless I/O interfaces, ports, interconnections and/or the like for connecting to one or more external devices, for example, a Universal Serial Bus (USB) interface, a serial interface, a Radio Frequency (RF) interface, a Bluetooth interface and/or the like. Exemplary I/O device(s) 616 of apparatus 601 may comprise one or more of a touchscreen, a display, a keyboard, a mouse, voice activated software using speakers and microphone, a printer, a touchpad, game controllers, haptic devices, and/or the like. Additionally or alternatively, one or more standalone devices communicating with processor(s) 612, e.g., via the network 605, may serve as VO device(s) 616, for example, a mobile and/or stationary computing device such as a smart phone, a tablet computer, a laptop computer, a desktop computer, awearable computer, and/or the like, running a suitable application program, may establish communication (e.g., cellular, network, short range wireless) with the processor(s) 612 using a communication interface (e.g., network interface, cellular interface, short range wireless network interface). The user may input data and/or receive data outputted by the respective device, e.g., by entering and/or viewing data on a display of the computing device (e.g., a smart phone), optionally via a graphical user interface (GUI) application and/or the like.

The apparatus 601 may comprise a memory and/or data storage device such as 618, which may be configured to store code instructions executable by the processor(s) 612, for example, one or more volatile devices such as a random access memory (RAM), a read-only memory (ROM), a cache, and/or the like, one or more tangible, non-transitory persistent storage devices, for example, a non-volatile memory, magnetic media, semiconductor memory device(s), a removable storage, optical media (e.g., DVD, CD-ROM), a hard drive, a Flash array, and/or the like. The memory 618 may additionally or alternatively comprise one or more local and/or remote network storage resources, for example, a storage server, a Network Attached Storage (NAS), a network drive, a cloud storage service and/or the like accessible via the network interface 616 and/or one or more other I/O interfaces. The memory 618 may store code instructions that implement one or more acts of the method described with reference to FIGS. 1-5, 7A and/or 7B herein. Alternatively or additionally, one or more acts of the method described with reference to FIGS. 1-5, 7A and/or 7B herein may be implemented in hardware. The system 600 may comprise a database server and/or likewise database management system such as 620 which may be in communication with apparatus 601, for example, over the network 605 via the network interface 614 and/or via other I/O interface (not shown). The database 620 may be a relational database such as SQL Database Server and/or the like.

The system 600 may further comprise one or more client device(s) such as 602 which may each be another apparatus implemented similarly as the apparatus 601. Alternatively or additionally, one or more of client device(s) 602 may be implemented as, for example, a client terminal, a thin client, and/or the like. The client device(s) 602 may comprise one or more processors (not shown), network interface (not shown), one or more I/O devices (not shown), and/or memory, which may be implemented similarly as the processor(s) 612, network interface 614, I/O device(s) 616, and/or memory 618 of apparatus 601, respectively.

In some embodiments, the memory 618 may comprise a honeypots detector such as 630 configured to detect unauthorized access, data manipulation attack, and/or any likewise malicious activity aimed at the database 620 as may be indicated via honeypots usage. The honeypots detector 630 may monitor and/or intercept incoming requests to the database 620 for performing database operations, such as for example, read, write, and/or modify data. Such incoming requests may be arriving and received over the network 605 from the client device(s) 602 of which the honeypots detector 630 may not have any prior knowledge preceding the (first of which) requests. The honeypots detector 630 may be configured to check whether a requested operation may attempt to access honeypots, such as honeypot field(s) and/or honeypot value(s) generated by the honeypots generator 640 and/or likewise component, and in response to detecting such attempts take one or more actions, such as for example, issue an alert to supervisory personnel and/or system, block the client device(s) 602, user(s) logged in thereat and/or IP addresses associated therewith, return error message(s), return confirmation message(s) without performing the operation, apply the operation on a temporary and/or mockup database, store details of the attempts in an activity log, and/or the like.

In some embodiments, the memory 618 may comprise a honeypots generator such as 640 configured to generate honeypots which may optionally be utilized to counter unauthorized access, data manipulation attack, and/or any likewise malicious activity aimed at the database 620 as may be indicated via honeypots usage. The honeypots detector 630 may monitor and/or intercept incoming requests to the database 620 for performing database operations, such as for example, reading data and/or querying a structure thereof, e.g., a database table schema and/or the like. Such incoming requests may be arriving and received over the network 605 from the client device(s) 602 of which the honeypots generator 640 may not have any prior knowledge preceding the (first of which) requests. The honeypots generator 640 may be configured to check whether a requested operation may attempt to query a table schema of the database 620, retrieve data from all fields of a table schema of the database 620 indiscriminately and/or otherwise gain knowledge on structure and/or contents of information stored in the database 620 that may be exploited for data manipulation attack. The honeypots generator 640 may generate in response to such request received one or more honeypot fields and optionally may further generate respective honeypot values for each of the honeypot fields, and accordingly add the honeypot fields and/or honeypot values to results returned from the database 620 in response to executing the requested operation on the database 620. The honeypots generator 640 may forward the results with the honeypots added therein to the client device(s) 602.

It will be appreciated that while the honeypots detector 630 and honeypots generator 640 are illustrated in FIG. 6 as respective separate units in an exemplary architecture of the system 600 and/or the apparatus 601, the disclosed subject matter is not meant to be limited in such manner and other architectures, configurations, implementations, and/or the like, such as wherein the honeypots detector 630 and honeypots generator 640 are a same and/or integrated single unit, module, component, and/or the like may be employed as well.

Reference is now made to FIG. 7A which is a flowchart schematically representing an exemplary method of honeypots generation for unauthorized database access detection, according to some embodiments.

Reference is also made to FIG. 7B which is a flowchart schematically representing an exemplary method of honeypots usage for unauthorized database access detection, according to some embodiments.

At 710 a query to a database requesting to perform a database operation, such as read data and/or obtain structure thereof, may be received. The query may be formatted in a relational database language such as SQL and/or the like.

At 720 a determination may be made as to a query type of the query received at 710, i.e., whether the query may be a schema query such as for example a “DESCRIBE TABLE” statement (where “TABLE” may refer to a table in the database) and/or the like, a data query such as for example a “SELECT * FROM TABLE” statement, or otherwise.

In case of a query schema statement according to the determination at 720, one or more honeypot fields may be generated at 730 and added to a result of the query, such as may be obtained by execution of the query schema statement on the database (e.g., a schema table describing which fields a table of the database may contain and/or the like). The schema with the added honeypot fields generated at 730 may be returned at 740 to respective requestor(s) that submitted the query schema statement.

In case of a query data statement according to the determination at 720, one or more honeypot fields and respective value(s) for each of which may be generated at 750 and added to a result of the query, such as may be obtained by execution of the query data statement on the database (e.g., a data table with values as contained in each field of a database table and/or the like). The data results with the added honeypot fields and honeypot values generated at 750 may be returned at 760 to respective requestor(s) that submitted the query schema statement.

At 770 a request for one or more database operations may be received, such as in a form of one or more subsequent database queries. At 780 any and/or all such subsequent queries submitted to the database may be checked for database operation(s) attempting to access (e.g., read, write, modify, and/or the like) one or more of the honeypot field(s) generated at 730 and/or at 750. In case of detection of attempted access to honeypot field(s), one or more countermeasures may be applied in response thereto at 790, such as for example, denying access to the database and/or any further requests from a same origin, alerting a user, diverting activity to a temporary database, returning confirmation and/or error message(s), and/or the like.

It is appreciated that one or more of the acts described herein, particularly, but not exclusively with reference to FIGS. 1-5, 7 A and 7B herein may be executed by a computer program for unauthorized database access detection, the computer program comprising program instructions for executing the aforementioned one or more acts which may be executed by at least one processor. Each of these programs may be provided on a non-transitory storage medium.

The descriptions of the various embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant database systems and/or database client applications will be developed and the scope of the term “database” is intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %. The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of' and "consisting essentially of'.

The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of embodiments. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of embodiments, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of embodiments, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements. Although embodiments have been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

It is the intent of the applicant(s) that all publications, patents and patent applications referred to in this specification are to be incorporated in their entirety by reference into the specification, as if each individual publication, patent or patent application was specifically and individually noted when referenced that it is to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.

Claims

CLAIMS:

1. A system for unauthorized database access detection, comprising: a processing unit adapted to: generate for a database schema at least one honeypot field; return the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and apply at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.

2. The system of claim 1, wherein the at least one countermeasure action comprising at least one of: blocking the attempted access; analyzing the attempted access; applying the attempted access to a temporary database; returning a confirmation message; returning an error message; and alerting a user.

3. The system of claim 1, wherein deployment of a database client authorized to access the database schema comprising program instructions for removing from the database schema returned the at least one honeypot field.

4. The system of claim 1, wherein the database schema is a Structured Query Language schema.

5. The system of claim 1, wherein the database schema comprising a description of a plurality of fields respective of a plurality of values stored in a table having a plurality of rows and columns.

6. The system of claim 1, wherein the query is a Structured Query Language query comprising at least one dynamic analysis operation on the database schema.

7. The system of claim 1, wherein the at least one honeypot field is generated ad hoc in response to receipt of the query.

8. The system of claim 1, wherein the processing unit is further adapted to generate for the at least one honeypot field a plurality of honeypot values.

9. The system of claim 1, wherein the processing unit is further adapted to, in response to a query requiring for data retrieval of values of all fields of the database schema indiscriminately: generate the at least one honeypot field and a plurality of honeypot values respective of each of the at least one honeypot field, and return a result of executing the query on values of all fields of the database schema with the plurality of honeypot values of each of the at least one honeypot field added thereto.

10. The system of claim 9, wherein deployment of a database client authorized to access the database schema comprising program instructions for removing the plurality of honeypot values of each of the at least one honeypot field from the result returned.

11. A computer program for unauthorized database access detection, the computer program comprising program instructions which, when executed by at least one processor, cause the at least one processor to: generate for a database schema at least one honeypot field; return the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and apply at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.

12. The computer program of claim 11, wherein the at least one countermeasure action comprising at least one of: blocking the attempted access; analyzing the attempted access; applying the attempted access to a temporary database; returning a confirmation message; returning an error message; and alerting a user.

13. The computer program of claim 11, wherein deployment of a database client authorized to access the database schema comprising program instructions for removing from the database schema returned the at least one honeypot field.

14. The computer program of claim 11, wherein the database schema comprising a description of a plurality of fields respective of a plurality of values stored in a table having a plurality of rows and columns.

15. The computer program of claim 11, wherein the query is a Structured Query Language query comprising at least one dynamic analysis operation on the database schema.

16. The computer program of claim 11, wherein the at least one honeypot field is generated ad hoc in response to receipt of the query.

17. The computer program of claim 11, further comprising program instructions which, when executed by the at least one processor, cause the at least one processor to: generate for the at least one honeypot field a plurality of honeypot values.

18. The computer program of claim 11, further comprising program instructions which, when executed by the at least one processor, cause the at least one processor to, in response to a query requiring for data retrieval of values of all fields of the database schema indiscriminately: generate the at least one honeypot field and a plurality of honeypot values respective of each of the at least one honeypot field, and return a result of executing the query on values of all fields of the database schema with the plurality of honeypot values of each of the at least one honeypot field added thereto.

19. The computer program of claim 18, wherein deployment of a database client authorized to access the database schema comprising program instructions for removing the plurality of honeypot values of each of the at least one honeypot field from the result returned.

20. A method for unauthorized database access detection, comprising: by at least one processing unit, performing: generating for a database schema at least one honeypot field; returning the database schema with the at least one honeypot field added thereto in response to a query on the database schema; and applying at least one countermeasure action in response to detection of an attempted access to the at least one honeypot field.