Multi-level security model for securing access to encrypted private data

A system, method and program product for implementing a database security model. A database security model is disclosed that includes: a system for maintaining private data in an encrypted storage area; an ENCR system for implementing a plurality of ENCR routines, wherein each of the ENCR routines is callable from a database application to access and process private data and wherein the ENCR system operates in a functional space separate from the database application; and a crypto system having a private key and decryption system, wherein the crypto system decrypts private data in response to receiving a decrypt request and public key from an ENCR routine, and wherein the crypto system operates in a functional space separate from the ENCR system.

TECHNICAL FIELD

The subject matter of this invention relates to data security, and more particularly to a model for securing data stored in an application database.

BACKGROUND

Data security continues to be significant challenge for information contained in application databases. Application databases utilize computer programs whose primary purpose is to enter and retrieve information, and are used in numerous fields, such as government, medical records, accounting, finance, science, web-based services, and so forth. One of the challenges with implementing application databases is the fact that the data often includes private or sensitive information, such as account information, social security numbers, medical records, etc., and such information is available to employees, developers, system administrators, etc. Accordingly, common strategies for handling private data include ensuring that access is password protected and data encryption.

Although it is relatively straightforward to provide password protection and encrypt data contained in such a database to protect user information, problems arise due to the fact that there are often numerous authorized users who have access to the decrypted data. Authorized users, whether acting intentionally or via comprised user credentials, create a significant risk of a data breach. In a typical environment, authorized users may include application users, developers, project managers, and system administrators. Any one of these actors could potentially misuse their credentials to compromise the data.

SUMMARY

Aspects of the disclosure provide a multi-level security model in which no single actor is capable of compromising data in an application database.

A first aspect discloses a database security model for securing data in an application database, comprising: a system for providing access to private data in an encrypted storage area; an ENCR system for implementing a plurality of ENCR routines, wherein each of the ENCR routines is callable from a database application to access and process private data and wherein the ENCR system operates in a functional space separate from the database application; and a crypto system having a private key and decryption system, wherein the crypto system decrypts private data in response to receiving a decrypt request and public key from an ENCR routine, and wherein the crypto system operates in a functional space separate from the ENCR system.

A second aspect discloses a computer program product stored on a computer readable storage medium, which when executed by a computing system, provides a database security model, the program product comprising: program code for providing access to private data in an encrypted storage area; first level program code for implementing a plurality of ENCR routines, wherein each of the ENCR routines is callable from a database application to access and process private data and wherein the first level program code operates in a functional space separate from the database application; and second level program code having a private key and a decryption routine, wherein the decryption routines decrypts private data in response to receiving a decrypt request and public key from the first level program code, and wherein second level program code operates in a functional space separate from the first level program code.

A third aspect discloses a computerized method for implementing a database security model, comprising: maintaining private data in an encrypted storage area; receiving a request at an application database that requires access to private data; passing an ENCR request to an ENCR routine that operates in a first level functional space separate from the database application; processing the ENCR request and submitting a decrypt request along with a public key to a crypto system that operates in a second level functional space separate from the ENCR routine; retrieving and decrypting private data within the crypto system using a stored private key and a submitted public key; passing decrypted private data to the ENCR routine; and returning an ENCR result to the database application.

DETAILED DESCRIPTION

Referring now to the drawings,FIG. 1depicts a schematic overview of a database security model10. In this illustrative embodiment, data is stored in two schemas, as “locked” data34that contain encrypted private data, e.g., Protected Personal Information (PPI), and as non-private application or “open” data36(collectively, the “database”). Locked data34include private data that remains encrypted and are not readily available as plain text while open data36include data that is readily available. For example, open data36may include the job title of a set of individuals, while the locked data36include social security numbers (SSNs), etc.

As detailed herein, locked data34can only be decrypted with a pair of keys, referred to herein as a private key50and a public key52. The pair of keys50,52are kept separate in order to ensure that no single person has access to both keys to access the locked data34.

In general, application users42interface with a front-end database (DB) application32, in which they submit queries and receive back results. For retrieving non-private information, the DB application32simply interfaces directly with tables in the open data36to obtain the necessary information. If it necessary to retrieve private data to execute an inputted query, the DB application32is not allowed to directly access the locked data34. Instead, the DB application32must instead make a call to ENCR system30, which includes one or more ENCR routines44(also referred to herein as ENCR_CODE) specifically implemented to handle the request. Thus, as described herein, although the DB application32cannot directly access and return private data from the locked data34, the DB application32can provide functionality that allows an application user42to interface with private data in a limited fashion indirectly via an ENCR routine44. For example, a user42may be able to enter an SSN to the DB application32to determine if there is a match in the locked data34, which will in turn call an ENCR routine44and, e.g., return a yes or a no.

When private data is required to handle a query, the DB application32submits an ENCR request to ENCR system30which processes the request and returns an ENCR result. In some cases, the ENCR result may include a simple yes/no (e.g., a match exists) or may return actual decrypted private data (e.g., a date of birth). To handle ENCR requests, ENCR routines44can be implemented in two ways: (1) In a first approach, the ENCR routine44can use encryption code45along with a retrieved public key52to encrypt an inputted data record (e.g., an SSN). The encrypted data can then be, e.g., compared to an encrypted record or records in the locked data34to determine if a match exists. Using this approach, no data is ever decrypted—instead processing is done by comparing encrypted data records only. (2) In a second approach, the ENCR routine44can submit a decrypt request, along with the public key, to crypto system28. Crypto system28includes decryption code and private key50that can be used (along with the inputted public key52) to decrypt one or more locked data records. Once decrypted, the decrypted data is passed back to the ENCR system30. Note that the public key52is not stored in the crypto system28, but just temporarily used for the decryption request.

Note that the database application32, ENCR system30and crypto system28are implemented in operationally distinct spaces or realms (i.e., first level and second level, respectively), such that access to files and processes in one space by a user does not allow for access to another. Each system28,30may comprise its own physical or virtual server space.

Note also that the security model10may be implemented such that either or both the DB application32automatically retrieves the public key52from storage and passes it to ENCR system30and/or a qualified and authorized resource such as the project lead22manually retrieves the public key52from storage and passes it to the ENCR system30when access to private data is required from the DB application32or a qualified and authorized resource directly. Note that direct access with an account other than App Users42(such as the ENCR User Acct) requires activation of a user account by the gate keeper18and authorization from a qualified 3rdparty such as the key master20.

Thus, using this multi-level security approach, once an ENCR routine44is deployed to the ENCR system30, developer resources can easily add functionality to the front-end DB application32to access private data without having decryption capabilities. Thus, neither the application user42nor internal developer resources can ever compromise the private data.

Equally important security issues also arise for higher level administrators who traditionally have system level access to all data. For example, it may be determined that the application users42require some additional limited private data access to perform their roles in an organization. In this case, a developer resource under the project lead22must write a new ENCR routine44, which may require decryption access to the private data. As discussed in further detail herein, the present approach contemplates at least three different administrative roles, none of which are given unfettered access to the locked data34. These roles include a gate keeper18, a key master20and a project lead22. Accordingly, rather than provide that developer resource with, e.g., a key, to allow for decryption, the illustrative security model10provides a platform to ensure that no single actor can access locked data34.

The security model10operates with the following tenets:

(1) Bifurcated Key—The key used to encrypt or lock the data is comprised of at least two separate pieces (private key50and public key52). Any actors who have access to part of the key must never be able to access all the other parts of the key to combine all of the pieces together and have the complete key. For example, if the gate keeper18and key master20have access to the private key50then the project lead22must not be allowed to access the private key. Further, in this example the gate keeper18and key master20must not be allowed to access or compromise the public key

(2) Separation of Duties—Security duties are broken out into multiple roles creating a system of checks and balances. Each actor in the model has at least one other actor that can perform a check or block against that actor individually compromising protected resources. Also, an established process for requesting, authorizing, and completing system needs is utilized. For example, a database administrator cannot complete a request from a developer resource to have a secure account activated (or any request that was not approved by an established role within the organization). In order for any action to be taken, that action must be authorized by at least one and possibly two other qualified roles.

(3) Encryption—The sensitive data is encrypted using a robust algorithm so that the protected resources on their own cannot be read directly—a separate key is needed to unlock the data.

The primary accounts and associated roles are as follows:

(1) Gate Keeper18, which is responsible for user access to the Crypto system28and ENCR system30. The gate keeper18controls user creation, privileges, and access to objects contained therein. The gate keeper18may play a role in managing the private key, but does not have access to public key52.

(2) Key Master20, which is either fully or partially responsible for the private key50, and storing the private key in the crypto system28. The key master20also performs a very import audit function and can act as a qualified authorizer of requests whose approval is required for any action to proceed within the model. The key master20does not have access to the public key52.

(3) Project Lead22, which is responsible for the public key52. The project lead22can request actions to be performed by the gate keeper18(e.g., allow access to the ENCR system30) but these requests may require the authorization of at least one other qualified role such as the key master20. The project lead22does not have access to the private key50.

(4) Developer(s), which are responsible for application development and maintenance. The developer does not have access to either key, and cannot access live files or servers. Instead, the developer must provide updates and changes to the project lead22. Note that this role is optional and these duties may be performed directly by the project lead22. Note also that the developer role may include one or many resources of varying levels (e.g., Senior Developer, Technical Lead, etc.).

(5) Security Oversight, which is responsible for reviewing application code for back doors and other intentional breach attempts within the DB application32. Note that this role is optional but recommended in cases where, e.g., sensitive data must be rendered in plain text in the DB application32.

Accordingly, as shown in the illustrative embodiment ofFIG. 1, the key master20is the only person authorized to temporarily access the crypto system28via a crypto user account when allowed by the gate keeper18. Similarly, the project lead22is the only person authorized to temporarily access the ENCR system30via an ENCR user account when allowed by the gate keeper18. As such, access to the crypto system28and ENCR system30is highly regulated, and requires at least two people aware of the access. This helps to ensure that no individual can for example install code on either system to capture the public or private key.

FIG. 2depicts a summary of the process of setting up the security model10. Initially at S1, the gate keeper18creates user accounts, including crypto user account and ENCR user account. Additional accounts may include an application user account (e.g., APPUSER) and a locked table user account (e.g., LBX_USER). At S2, the gate keeper18creates database objects including the locked data34and open data36and at S3the key master20(or optionally the gate keeper18) generates a private key50and stores it in the crypto system28. At S4, the project lead22provides an obfuscation script to the key master20to hide the private key50and at S5the gate keeper18provides login information (e.g., CRYPTO_USER credentials) to the key master20and at S6, the key master logs in, embeds the private key50and creates encrypt and decrypt code functions. At S7, the project lead22verifies that the private key50is hidden. Note that the role of providing the script could be done by another entity, such as the gate keeper.

FIG. 3summarizes an illustrative process for deploying new ENCR routines (ENCR_CODE)44. At S10, the developer resource provides a script for creating a new ENCR routine44to the project lead22. The project lead22reviews the script to ensure that no (or only limited) private data can be returned at S11, and at S12the project lead22requests a create session for an ENCR user account (ENCR_USER) and requests credentials from the gate keeper18. At S13, the gate keeper18activates the session and provides the credentials and at S14the project lead22logs on as ENCR_USER and creates the ENCR routine44and inserts seed values into the locked data34as needed. At S15, the project lead22notifies the gate keeper18to end the session for ENCR_USER and deploys the code. At S16, the project lead22generates a public key52in a secure storage region and at S17, requests access for APPUSER as needed. The public key52is passed as needed. Finally, at S18, seed values are inserted into the database as needed.

The project lead22instructs the Developer resources on the best use of plain text sensitive information in the application with a goal of minimizing or eliminating the retrieval of plain text sensitive data to the greatest extent possible:

a. Mask data unless it is absolutely necessary to display in plain text;

b. Bulk pulls of plain text sensitive data (reports) will run under special accounts that can be made active during specific time windows; and

c. Token IDs are to be used instead if personal information based IDs.

Search algorithms may be written within the ENCR routine(s)44and return masked results and the Developer role has no access to the public key52. Since the Developer provides code to the project lead22for deployment, the project lead22can review the code for attempts to compromise the public key52. Also, the project lead22can utilize a separate repository that is not accessible by the developer to embed the public key52inside the application. Since the developer cannot access the ENCR system30where the public key52is deployed, it is difficult for the Developer to compromise the public key52.

The use of a Cypher Key allows the public key52to be protected as well as the data. Note that this offers additional protection since the crypto system28code must now accommodate processing a protected public key52, so the public key52does not necessarily need to be un-encrypted for it to be useful. The added benefit would be more related to cases where the data values were extracted from the database without the corresponding CRYPTO routines. In this scenario, someone with the two keys but not the CRYPTO routines would not be able to convert the data to plain text.

The Security Oversight role may be implemented, particularly when plain text data needs to be returned to the database application32. Security Oversight must not be allowed access to accounts in the database that can access the private key52.

Finally, in one illustrative embodiment, the Developer Role does not need to have access to the APPUSER database account.

The following checks and balances are provided by the security model10.(1) The key master20does not have access to the public key52. Even with the public key52, the key master20cannot make calls to decrypt the locked data34and cannot access the locked data34. Best practice dictates, however, that care is taken to keep the public key52from the key master20.(2) The Developer does not have access to either of the keys and can only connect to the database with the APPUSER account in lower environments—not live or production environments. The Developer could theoretically include surreptitious code in the application intended to compromise the public key and/or unencrypted data returned from ENCR_CODE. The following checks serve to prevent these threats from becoming realized vulnerabilities:

a. The Developer cannot deploy code. The project lead manages deployments and can review the code for backdoors that may try to compromise data

b. The Developer cannot access the public key. The project lead manages the public key and keeps it stored in a secure repository not accessible by Developers. The Project lead can look at every instance in the code where the public key is utilized and verify that it is not compromised.

c. A Security Oversight role can be incorporated to serve as a second set of eyes backing up the project lead checks

d. The Developer cannot connect to the database using accounts that can call the CRYPTO routines. Since the gate keeper only processes requests initiated by the project lead, the Developer is blocked from requesting access to these accounts

e. Note that compromised Developer credentials can serve as a very powerful attack tool to compromise secure data. Therefore, the Developer role may not be allowed to have accounts that can access production or live servers, file shares, databases, repositories, etc.:i. A compromised Developer account could be susceptible to elevated privileges allowing a threat agent to install malicious code to intercept the public key or detect packets on the wire to gain access to plain text and route this information to an accessible location. To counter this, effective patching, firewall, and network monitoring strategies are recommended. Effective personnel management is also important to make sure old or unused user accounts to not remain active. Also, plain text sensitive data should only be passed when absolutely necessary. Time policies and limit filters are available in some database applications that allow accounts to access data only during certain time windows. Network monitors can be set to a higher level of vigilance during these windows.ii. A compromised Developer account could be susceptible to elevated privileges allowing the theft of production application files (including operating system and database files) to an accessible location. To counter this, it is recommended that the public key be stored in a quality HSM appliance so that it is read and passed by the application at runtime. This way, the public key would not be included in the stolen information and the sensitive data could not be decrypted3. Security Oversight has limited access in that it can only view application code. They may gain access to the public key if it is stored in the code, but because the role cannot access the database code; these users cannot access the private key. Also, because this role cannot connect to the database, they cannot attempt to utilize the public key to try and call ENCR_CODE that may return plain text sensitive data. Since they may be able to review configuration files that contain connection information, these strings would ideally be stored in an encrypted format to prevent unauthorized attempts to connect to the database.4. Project Lead22is one of the most difficult roles to lock down because typically this is the role whose job most requires access to the information that needs to be secured. Moreover, this is the one role that can directly access the public key52. All that would be needed to view encrypted data would be a connection to the database. In applications that do not return plain text data in the ENCR routines44, the check against the project lead22is that a formal request must be entered and approved by a qualified 3rdparty such as the key master20in order for the SESSION privilege to be turned to ON for the ENCR_USER account, which can directly call the ENCR routines44(ENCR_CODE) and potentially, if enabled by the gate keeper with proper authorization, the LBX_USER account, which could directly call the Crypto System routines28. When business needs dictate that plain text sensitive data needs to be returned from the ENCR_CODE, the project lead22could simply connect to the database using the APPUSER account and pass the public key52directly to return unencrypted data. Additionally, a malicious agent who compromised the project lead22credentials could do the same. Consequently, the following are recommended in cases where plain text sensitive data needs to be returned to the front-end application:

a. Take every step possible mask this data. For instance, searches can be coded into the ENCR_CODE in such a way as to mask potential matches but still allow the human to identify the correct match;

b. For reports and other functions that may require multiple records of plain text data, set up a separate account under which these functions run. Seek ways to limit and monitor the times when this account can actively connect to the data;

c. Employ a Security Oversight actor to monitor the application code for potential vulnerabilities;

d. Investigate network monitoring utilities that can monitor and report on specific types of network traffic and usage;

e. Investigate data store application policies limiting connectivity by IP address to prevent the project lead from making a direct connection with the APPUSER account.5. The gate keeper can be the most difficult role to block from compromising the data. Since the main check against the gate keeper is that they do not possess the public key, preventing the gate keeper from obtaining the public key is crucial. Since the gate keeper18is typically a SYS level user in the database, there are inherently many means by which the gate keeper18can exploit the code to capture the public key52. A database running on SiS processors in a secure framework will be very difficult for a malicious agent to leverage to compromise the public key52from the network or volatile memory. So the principle means of exploit for the gate keeper role is modifying the database code where the public key is passed as a parameter. It is very difficult to completely block the gate keeper role (and consequently a malicious actor who has compromised the gate keeper credentials) from modifying the object definitions that compromise the code. But it is possible to detect when this has occurred. For this reason, it is strongly recommended that the key master and project lead set up Crypto Sentry code checks on all database code where the public key is passed. Further, there needs to be an effective and timely response mechanism when these alterations are detected. Since the public key will only be passed to certain database routines, the Crypto Sentry can be focused on only these routines.

Additional features that can optionally be incorporated to enhance security include the following. Items passed in plain text on the wire are vulnerable to breach. Hardware and network protections can be used to mitigate this risk. For example, the unencrypted plain text values returned from a call to decrypt sensitive data for use in the front-end application are susceptible to being compromised by network sniffers. Securing the network can help mitigate these risks

The process of encrypting and/or decrypting data occurs in the random or volatile memory within the data store application. While in-process, there is a potential vulnerability for a malicious agent to scrape the RAM in order to compromise the key. Utilizing data store applications that incorporate Software in Silicon (SiS) hardware that prevents external reads (scrapes) will mitigate this risk. Likewise, the operating systems that process the public key and pass the value to the data store application can employ the same protections.

Any time the public key is passed on the wire (network), the connection would ideally be encrypted (i.e. SSL or VPN). This will ensure the key is encrypted in transit and prevent breach via packet sniffing.

Keys (Public and Private) will ideally be stored outside of the application. Care will need to be taken that these keys are not stored in such a way that it would be easy for a malicious actor to compromise the backup where the keys are stored. Strong Encryption tools such as Advanced Encryption Standard with a 256 bit key (AES256) are recommended. A strong source code repository is recommended for storing the code that will house the public key.

Most data store applications possess filter policy roles that only allow connectivity from specific IP addresses. This functionality can be utilized to prevent compromised credentials from being used to connect to the database from unauthorized entry points. The application connection information will ideally be stored in a secured manner such as encrypting the connection string if stored in a configuration file.

Vulnerabilities may lie within the integrity of the overall architecture (outside the security model10). For example, unhandled exceptions within an application can be sources of vulnerability. These can be mitigated by Runtime Application Self Protection (RASP) components, strong Firewalls, good software patching practices, network monitoring, etc.

Since most data store applications provide a mechanism to detect the user id, IP address, server name, etc., from the calling entity, additional security can be achieved by adding platform specific code to the ENCR and CRYPT routines that check for these properties and raise an exception if the server Meta Data is incorrect.

Some data store applications provide utilities for separating the duties of accounts within the data store. These utilities can help make it more difficult for the gate keeper and other SYS level users in the data store to compromise the data and/or the keys.

The keys would ideally be changed every 12 months or less. One means to accomplish this is to write a code routine in the ENCR_CODE that takes both the new and the prior public key and makes a call to the CRYPTO_CODE routine to decrypt using prior key passing the prior public key and then taking the result and calling the CRYPTO_CODE routine to encrypt the data passing the new public key. The newly encrypted values would overwrite the pre-existing values.

For applications that need to display plain text sensitive information from the database, system level application user accounts would be able to log in to the application and view data. Consequently, it is most secure if these accounts are disabled and can only be enabled by a project lead request approved by an authorized 3rdparty such as the key master.

Sensitive data can be tokenized to add an additional layer of anonymity. For example, random IDs can be created for each client record, and the random id can then be utilized by the application to represent an applicant, using that ID to process sensitive data only when needed. Since the ID on its own could not be used to identify a given person, it is much safer than using personal information as the record identifier.

An alternative approach may be implemented as follows, again with reference toFIG. 1.

The gate keeper18creates the CRYPTO_USER, ENCR_USER, APPUSER and LBX_USER accounts. Note that it is recommended that accounts be created under the ‘Least Privilege’ doctrine. In other words, the accounts will be given the least amount of privilege necessary to perform the needs of the account. Additional privileges can be added later if needed if authorized, but it is better to have the account ask for additional privileges rather than automatically have them.1) The gate keeper18creates the CRYPTO_READ_USER account and GRANTS SELECT privileges on the core table that lists objects within the database (i.e. OBJ$)2) The gate keeper18grants the CRYPTO_USER account privileges to connect to the database and to create packages/procedures/functions3) The key master20then provides the gate keeper18with the private key.4) The gate keeper20logs in with the CRYPTO_USER account and creates the CRYPTO_CODE in the Crypto System28embedding the private key50. Here is sample code for CRYPTO_CODE:

a.declareb.StrVal CLOB;c.StrLine VARCHAR2(4000);d.HashKey NUMBER;e.rec_cursor SYS_REFCURSOR;f.TYPE HashTable IS TABLE OF NUMBER INDEX BYbinary_integer;g.HashArray HashTable;h.HashClobKey VARCHAR(4000);i.beginj.--Pull all lines from routine into single CLOB variablek.OPEN rec_cursor FOR ‘select TEXT from ALL_SOURCE whereOWNER = “CRYPTO_USER” and NAME = “CRYPTO_CODE”and TYPE = “PACKAGE BODY”’;l.LOOPm.FETCH rec_cursor INTO StrLine;n.IF rec_cursor%NOTFOUND THENo.EXIT;p.END IF;q.IF StrVal IS NULL THENr.StrVal := StrLine;s.ELSEt.StrVal := CONCAT(StrVal, StrLine);u.END IF;v.END LOOP;w.CLOSE rec_cursor;x.--Chunk CLOB inot string blocks of 4000 to ensure consistent hashvaluey.FOR i in 1 .. ceil(length(StrVal)/4000)z.LOOPaa.StrLine := to_char(substr(StrVal, (i−1)*4000+1,4000));bb.SELECT db_hash(StrLine, length(StrLine), length(StrLine)) intoHashKey from DUAL;cc.HashArray(i) := HashKey;dd.END LOOP;ee.FOR i IN 1..HashArray.countff.LOOPgg.HashClobKey := CONCAT(HashClobKey,to_char(HashArray(i)));hh.END LOOP;ii.if HashClobKey != 346 thenjj.--Take anomaly detection action;kk.end if;ll.end;11) The gate keeper18then grants EXECUTE privileges on CRYPTO_CODE in the Crypto System28to the ENCR_USER account12) The gate keeper18then grants the SESSION privilege to ENCR_USER so that it can connect to the DB13) The gate keeper18grants the ENCR_USER account with privileges to create packages/procedures/functions in the ENCR System30and provides credentials to project lead2214) The project lead22then leads the creation of the ENCR_CODE functions in the ENCR System30. In this example, the decrypt routines are not publicly accessible by calls to ENCR_CODE routines in the ENCR System30. This ensures that the code cannot be used to compromise the sensitive data. Note that decrypt routines are included as calls nested within the public routines, but so long as these nested decryption values are not returned directly (only TRUE/FALSE is returned) they do not pose a security threat. Note that the script in this example that creates the ENCR_CODE routines in the ENCR System30returns an immediate Hash value that can be provided to the key master20to ensure no tampering occurred by the gate keeper18(or some other malicious actor) while the ENCR_USER account is active. Here is example code:

a.declareb.StrVal CLOB;c.StrLine VARCHAR2(4000);d.HashKey NUMBER;e.rec_cursor SYS_REFCURSOR;f.TYPE HashTable IS TABLE OF NUMBER INDEX BYbinary_integer;g.HashArray HashTable;h.HashClobKey VARCHAR(4000);i.beginj.--Pull all lines from routine into single CLOB variablek.OPEN rec_cursor FOR ‘select TEXT from ALL_SOURCE whereOWNER = “ENCR_USER” and NAME = “ENCR_CODE” andTYPE = “PACKAGE BODY”’;l.LOOPm.FETCH rec_cursor INTO StrLine;n.IF rec_cursor%NOTFOUND THENo.EXIT;p.END IF;q.IF StrVal IS NULL THENr.StrVal := StrLine;s.ELSEt.StrVal := CONCAT(StrVal, StrLine);u.END IF;v.END LOOP;w.CLOSE rec_cursor;x.--Chunk CLOB inot string blocks of 4000 to ensure consistent hashvaluey.FOR i in 1 .. ceil(length(StrVal)/4000)z.LOOPaa.StrLine := to_char(substr(StrVal, (i−1)*4000+1,4000));bb.SELECT db_hash(StrLine, length(StrLine), length(StrLine)) intoHashKey from DUAL;cc.HashArray(i) := HashKey;dd.END LOOP;ee.FOR i IN 1..HashArray.countff.LOOPgg.HashClobKey := CONCAT(HashClobKey,to_char(HashArray(i)));hh.END LOOP;ii.dbms_output.put_line(HashClobKey);jj.end;21) If the Hash value returned from above does not match the Hash value provided by the project lead22, then the deployment is halted as tampering may have occurred and will need to be investigated22) The key master20then creates the anomaly detection routine using the hash value returned from above. For example:

a.declareb.StrVal CLOB;c.StrLine VARCHAR2(4000);d.HashKey NUMBER;e.rec_cursor SYS_REFCURSOR;f.TYPE HashTable IS TABLE OF NUMBER INDEX BYbinary_integer;g.HashArray HashTable;h.HashClobKey VARCHAR(4000);i.beginj.--Pull all lines from routine into single CLOB variablek.OPEN rec_cursor FOR ‘select TEXT from ALL_SOURCE whereOWNER = “ENCR_USER” and NAME = “ENCR_CODE” andTYPE = “PACKAGE BODY”’;l.LOOPm.FETCH rec_cursor INTO StrLine;n.IF rec_cursor%NOTFOUND THENo.EXIT;p.END IF;q.IF StrVal IS NULL THENr.StrVal := StrLine;s.ELSEt.StrVal := CONCAT(StrVal, StrLine);u.END IF;v.END LOOP;w.CLOSE rec_cursor;x.--Chunk CLOB inot string blocks of 4000 to ensure consistent hashvaluey.FOR i in 1 .. ceil(length(StrVal)/4000)z.LOOPaa.StrLine := to_char(substr(StrVal, (i−1)*4000+1,4000));bb.SELECT db_hash(StrLine, length(StrLine), length(StrLine)) intoHashKey from DUAL;cc.HashArray(i) := HashKey;dd.END LOOP;ee.FOR i IN 1..HashArray.countff.LOOPgg.HashClobKey := CONCAT(HashClobKey,to_char(HashArray(i)));hh.END LOOP;ii.if OutVal != 581 thenjj.--Take anomaly detection action;kk.end if;ll.end;23) Note that typically, the gate keeper18can activate either of the CODE user accounts at any time and modify the CRYPTO and ENCR code in the Crypto System28and/or the ENCR System30. By modifying the code, the gate keeper18could subvert decrypted data and/or compromise the public key52as it is passed in and then be in possession of both keys. In most cases, these code changes would not be detected by either the project lead22or the key master20. In the TSM™, the measure that prevents this action from becoming a threat event is the comparison of the CODE signatures in the anomaly detection routines. If the gate keeper18role were to attempt this type of breach, the signature of the modified CODE would be different than that logged by the key master20. Consequently, the key master20has the ability to serve as a CRYPTO SENTRY to detect and prevent this type of breach. The frequency of the CRYPTO SENTRY checks will determine the size of the window available for a gate keeper18role to compromise the code. For instance, if the anomaly check routine is performed on every call to an ENCR System30or Crypto System28routine, then the breach window would be zero. If the call is performed intermittently, then the time window between checks becomes the maximum breach window. Regardless of the frequency, the CRYPTO SENTRY routines become an important check against the gate keeper18acting unilaterally to compromised locked data. The anomaly detection routines in the CRYPTO SENTRY it will need to run in such a manner that the gate keeper18cannot deactivate, override or modify. For example, the Crypto Sentry can be setup to run as an application outside the domain of the gate keeper (as well as the project lead). This would be represented inFIG. 1as a separate realm or space accessible only by the key master20, which would have read access to the Crypto System28and ENCR System30.24) The project lead22then creates a public key52. Note that the ideal place to store the public key52is in a Hardware Security Management (HSM) appliance with the code that passes the public key52to the ENCR System30routines in the database pulling the public key52at runtime from the HSM.25) The project lead22embeds a routine to manage and pass the public key52into the DB App32. Note, that upon successfully authorized request the gate keeper18could potentially enable session on a specified account such as LBX_USER to call either the Crypto System28or ENCR System30directly by manually pulling the public key52and passing it as a parameter26) Note that it is good practice for the project lead22to test ENCR System30routines to make sure encryption works properly—particularly if the public key52is cypher protected. Before testing, however, it is best to ensure that the public key52will not be compromised when it is passed in to the Crypto System28and/or ENCR System30routines.

In a further embodiment, the private key50is stored both in the Crypto System28and in a Hardware Security Module (HSM). Note that if the public key52is stored in an HSM it would need to be kept separate from the private key50. In this scenario, no decrypted data is returned from ENCR System30. Instead, encrypted values are returned and then passed into the HSM along with the public key52to decrypt at the point of display.

In still a further embodiment, gate keeper18manages private key50separately from key master20. In this scenario the key master20becomes a sentry only role (and potentially the additional authorizer besides the project lead22).

In still a further embodiment, the key master20role is eliminated. In this scenario, the gate keeper18manages the private key50and creates Crypto System28. Without the key master20to serve as CRYPTO SENTRY, the gate keeper18will need be perform anomaly detection on the ENCR System30and the project lead22will need do the same on both the Crypto System28and ENCR System30. Since the project lead will now be able to view the Crypto System28, the private key50will need to be extracted and stored under an account separate (but accessible) by Crypto System28user account. For example, the gate keeper18could create a CRYPTO_KEY_USER that creates an object or CRYTPO KEY CODE routine (preferably obfuscated to prevent over-the-shoulder breaches) that simply returns the private key50, and then grant EXECUTE privileges to CRYPTO_USER on this new routine. This routine call could be placed in the Crypto System28, but since the project lead22can only view the code (not execute) they will not be able to see the private key50even as they are checking the Crypto System28CODE for anomalies. Note that without the key master18it will be much more difficult to monitor cases where the project lead22is requesting the ability to call the Crypto System28directly or put public decrypt routines in the ENCR System30. For example, a malicious actor spoofing the project lead22role and having the public key52could directly request access the Crypto System28routines from the gate keeper18. If granted, this malicious actor would have all the resources needed to compromise locked data. In this scenario, additional 3rdparty oversight and/or approval is recommended.

In still a further embodiment, salting can be incorporated into some or all of the locked data34values for added security

In still a further embodiment, the public key52can be cypher protected using the Crypto System28routines so that it is not stored or passed as plain text. This would involve the gate keeper18allowing session connect on the CRYPTO_USER account so the project lead22could pass the public key52to the Crypto System28cypher routine to get back an encrypted value for the public key52. Calls in the ENCR System30routines would need to account for the encrypted public key52and utilize routines in the Crypto System28routines that decrypt the public key before combining with the private key50. Since the cypher value of the public key52can still be used to call the Crypto System28routines to unlock locked data34, this only adds protection for cases where the locked data has been exfiltrated along with the private key50but without the Crypto System28. In this scenario, the cyphered public key52could not be combined manually with the private key50to decrypt the locked data34.

In still a further embodiment, private key50embedded outside of Crypto System28. The key master20executes a script under a separate account (i.e. CRYPTO_KEY_USER) to store the private key50in a separate object or routine (preferably obfuscated to prevent over-the-shoulder breaches) that returns the private key50. Once this script is executed, the separate account is deactivated. The key master20then provides the script to create the Crypto System28routines to the gate keeper18. This Crypto System28script will contain a call to retrieve the private key50from the new object or routine created by the key master20. The CRYPTO_USER would be granted EXECUTE or SELECT privileges on the private key50store, but would not be able to view it. In this scenario, the project lead22could perform the CRYPTO SENTRY duties because the project lead22can only view the code (not execute or select from an object)—they will not be able to see the private key50even as they are checking the Crypto System28for anomalies.

In still a further embodiment, the Crypto System28can be written to store Previous private keys and have routines to utilize these prior keys. This would allow the keys to be changed periodically without the loss of any locked data.

In still a further embodiment, key master20can incorporate Crypto Sentry checks to see if any non-authorized code is making calls to the encryption libraries or the Crypto System28routines. For example:

In still a further embodiment, project lead22can temporarily be given access to an account such as LBX_USER that can directly connect to the database and execute Crypto System28routines. For example:1) The project lead22requests access to connect to an execute Crypto System28routines.2) The request is authorized by a qualified 3rdparty such as the key master203) The gate keeper18gives EXECUTE privileges on Crypto System28to the LBX_USER account and sets SESSION privilege for this account to ON4) The gate keeper18provides user credentials directly to the project lead22ESSION privilege for LBX_USER is set back to OFF immediately following the completion of the work by the project lead22

FIG. 4depicts an illustrative computing system50for implementing a database security system70to implement to above described database security model10for an application database68. Database security system70generally includes an account management system60for establishing the crypto system28and ENCR system30. As noted, the gate keeper role is largely responsible for creating accounts and establishing privileges. As such the account management system60would allocate the necessary resource for the gate keeper. Application management system62is responsible for establishing and managing the DB application32. Associated permissions, firewalls, etc., may be handled by the application management system62. Data management system64is responsible for setting up database tables and determining which data belongs in locked data34and which belongs in app data36. Communication system66provides a platform through which the different roles can communicate with each other. For example, if a developer wanted to deploy a new encrypted code function44(FIG. 1), the developer could pass the code or an associated request to the project lead via the communication system66.

Computing system50that may comprise any type of computing device and for example includes at least one processor52, memory56, an input/output (I/O)54(e.g., one or more I/O interfaces and/or devices), and a communications pathway57. In general, processor(s)52execute program code which is at least partially fixed in memory56. While executing program code, processor(s)52can process data, which can result in reading and/or writing transformed data from/to memory and/or I/O54for further processing. The pathway57provides a communications link between each of the components in computing system50. I/O54can comprise one or more human I/O devices, which enable a user to interact with computing system50. Computing system50may also be implemented in a distributed manner such that different components reside in different physical locations.

Furthermore, it is understood that the data security system70or relevant components thereof (such as an API component, agents, etc.) may also be automatically or semi-automatically deployed into a computer system by sending the components to a central server or a group of central servers. The components are then downloaded into a target computer that will execute the components. The components are then either detached to a directory or loaded into a directory that executes a program that detaches the components into a directory. Another alternative is to send the components directly to a directory on a client computer hard drive. When there are proxy servers, the process will select the proxy server code, determine on which computers to place the proxy servers' code, transmit the proxy server code, then install the proxy server code on the proxy computer. The components will be transmitted to the proxy server and then it will be stored on the proxy server.