Identifying stolen databases

A method, computer system, and a computer program product for identifying a hacked database is provided. The present invention may include generating a marked account using a plurality of data. The present invention may then include initiating a first transaction using the generated marked account. The present invention may also include determining that a second transaction has occurred using the generated marked account. The present invention may further include receiving notification of the second transaction based on determining that the second transaction occurred.

BACKGROUND

Undetected data breaches happen more commonly than is known to the general public. Hacked networks may even go months without detecting such a breach since a breach may not be known even after the hacker attempts to use the compromised data. A customer's personal information may be stolen without a company detecting that customer information stored in a database has been stolen. The nature of how data may be compromised has changed with the transformation in security infrastructure.

SUMMARY

Embodiments of the present invention disclose a method, computer system, and a computer program product for identifying stolen databases. The present invention may include generating a marked account using a plurality of data. The present invention may then include initiating a first transaction using the generated marked account. The present invention may also include determining that a second transaction has occurred using the generated marked account. The present invention may further include receiving notification of the second transaction based on determining that the second transaction occurred.

DETAILED DESCRIPTION

The following described exemplary embodiments provide a system, method and program product for identifying hacked databases. As such, the present embodiment has the capacity to improve the technical field of database security by identifying which database may have been hacked. More specifically, a merchant database storing personal customer data may be compromised by a hacker obtaining access to the database and stealing customer information. The described embodiment may identify what database information may have been compromised by implanting marked data that may alert the proper entity when used by the hacker or used by a person who may have purchased the stolen data from the hacker.

As previously described, undetected data breaches happen more commonly than is known to the general public. Hacked networks may even go months without detecting such a breach since a breach may not be known even after the hacker attempts to use the compromised data. Personal information may be stolen without an entity or a company detecting that customer information stored in a database has been stolen. The nature of how data may be compromised has changed with the transformation in security infrastructure. A method for identifying database breaches when the stolen information has been used without authorization and notifying the proper entity or authority may provide a more secure database environment.

Generally, the public may be aware of database breaches that have been detected and announced publicly. Correspondingly, the public may not be aware if a hacker has breached a customer database if the breach has not been detected or if the breach was not announced by an organization. Months or even years may pass before an organization detects a compromised database. If a network breach goes undetected for 8 months, then an entity, an organization or customers may not have known protection was needed. For example, if a hacker has stolen social security numbers from a database, by the time a customer, a merchant, an entity, an organization or the proper authorities have been alerted, the hacker may have already stolen identities, used the social security numbers or have sold the social security numbers through non-legal channels. According to another example, if a hacker has stolen credit card data from an entity's database or an organization's database, the hacker may either wait to use the stolen credit card number or may sell the credit card numbers to another person who may not immediately use the stolen data. Meanwhile, merchants, entities, organizations, customers or the proper authorities may not know the data has been compromised and customers may not be provided with information for a proper response such as to close a credit card account or to seek assistance for identity theft.

Regulations and security infrastructure may have evolved to handle identifying a database breach, however, hackers may have also evolved the nature of database breaches. Breaches may no longer be a binary proposition when a merchant's database, an organization's database or a government entity's database may or may not have been breached. The evolved nature of security breaches may include a variance in severity and ramifications to breached databases, core constituencies and partners to database owners who store personal information. This new and changing nature of database breaches may require a method to detect the severity of a breach since there may not be a way to consistently detect database breaches. Therefore, it may be advantageous to, among other things, provide a method to identify which database has been breached by a hacker once the hacker uses the breached data by placing marked data (i.e., data that may be traced) into databases associated with customer information which may be stolen by hackers.

For the present embodiment, an organization, for example, may include an entity that processes payments for customers (i.e., a service provider) or stores customer data for merchants. Merchants may also store customer data and may use service providers as a third-party authority to communicate with the banks to process payments for goods or services. Merchants may include consumer goods stores, restaurants, online stores, service based companies or a company that may accept payments by a credit card or a bank card. Merchants may also include hospitals or a government office. Merchants and organizations may store both citizen data and non-citizen data since an organization may transact accounts and business in other countries. An online store, for example, may sell products to consumers globally. Another example of diverse transactions may include an encounter when either a citizen or a non-citizen receives a parking ticket. The individual who receives the parking ticket may pay the parking ticket using a government online portal that allows an online payment method. The online payment for the parking ticket may be paid via a credit card where the individual's personal information and the individual's credit card may be processed by the government entity's service provider. Companies that offer services may include services that both process payments and store personal information such as a law office, an accounting firm, a finance firm or a medical facility. Other types of service companies that may process payments may include services such as landscaping, plumbing, architecture, housecleaning, or contractor services.

A service provider may process credit card or bank card payments for a merchant. The service provider may be an organization that communicates with banks to retrieve authorization for the individual's purchase with a merchant. A merchant may offer services to customers such as saving a customer's name, address and credit card number on file (i.e., in a merchant database) for ease of future purchases with the same merchant. A customer who may shop at one or more online stores often may benefit from having the merchant save personal information to create a faster and more streamlined purchase without the need to input a credit card number for each purchase, therefore, saving the customer time. Once the customer opts to save a credit card on file, the merchant may store the customer's personal information and credit card number in a database for accessibility for the next customer authorized purchase.

Databases may store a plurality of data including information personal to customers locally and around the world. An individual, for example, may be susceptible to having personal data stolen by a hacker out of a database if the individual has purchased an item from a merchant using a credit card or if the person has submitted personal information to an entity such as a doctor's office or a government entity. Personal information on a database may include data such as credit card numbers, social security numbers, email addresses, residence addresses, birth dates, usernames, passwords, personal identification numbers, biometric data and other identifying information. Credit card transactions may be processed at a brick and mortar store, at an online store, using a wireless terminal, or using a mobile device such as a cellular phone or a tablet. Since the plurality of data that may be stored on a database is variant in nature, difficulties may ensue while identifying the origin of stolen data. Protecting customer information may require the ability to identify the hacked database source to ensure the proper entity, organization or authority may take necessary precautions to protect customers.

According to at least one embodiment, the hacked database identification program may add marked data into a database for monitoring. Monitoring for usage of the marked data may provide a source of the stolen data once the stolen data is used by the hacker or a person who has received the compromised data. Unauthorized usage of the stolen data may indicate the database has been compromised. Additionally, if marked data is used by the hacker or the person who received the compromised data, then the authority of the marked data may identify that the database has been compromised and may also locate the source of the stolen information (i.e., which database has been hacked). One set of marked data may relate to one merchant or one database. If a particular set of marked data is used by a hacker or a person who received the compromised data, then the authority of the marked data may know which marked account was used and which entity the marked data was associated with (i.e., which entity the authority of the marked data created an account with).

Marked data may be data that is traceable. Information that may be marked may include data such as social security numbers, credit cards or other stored data that may be valuable to a hacker. Marked data may be associated with fictitious data or real data. Marked data may also be associated with both fictitious data and real data, such as an imaginary customer made up as a decoy but the created fictitious customer information is linked to a credit card associated with or linked to real assets (i.e., a credit card that can process a payment). Marked data may be created or used for the purpose of waiting until an unauthorized person uses the data. Marked data may be saved in a database with customer data and if the marked data is used then the hacked database identification program may operate as an alarm and notify the entity or service provider who created the decoy account of the unauthorized use. An alternative notification may come from a credit card company who issued the credit card to the service provider where the credit card account may be a marked account. Here, the credit card company may be a financial institution and may alert the service provider that the marked credit card has been used. The notification from the financial institution to the service provider may be a message on a computing device over a communication network. The hacked database identification program may also identify a specific database that may have been breached once the marked data is used since the fictitious data specific to the valid linked credit card may be present in one particular database. The marked data may also be present in more than one database.

The marked data may also be associated with fictitious non-valid data linked to detect usage when a hacker may attempt to use the fictitious data, such as a fake social security number, a fake account number or a fake username and fake password. The fictitious data may be associated with a real account created with a merchant but the fictitious account may be created for the purpose of being a decoy. Entering the marked data into an online account that saves the data to a database may mimic the regular way an online profile is entered into the database (i.e., the regular way a real customer may enter data to create an online profile) to reduce the chance of automatic detection since even the owner of the database may not know about the fictitiousness of the data. For example, a security service provider may create one or more valid credit card accounts for the purpose of a decoy account.

In the present embodiment, for example, a merchant that may use a service provider to process payments may know or may not know the service provider is using the hacked database identification program to transmit marked data to the merchant database that stores credit card numbers. The service provider may place a valid order with the merchant using arbitrary, imaginary user data associated with credit card linked to real assets. The service provider may be a user operating a computing device running the hacked database identification program. The service provider may process a purchase with a merchant similar to a customer and the merchant may or may not know of the decoy purchase using a marked account. The decoy purchase is a real purchase to get the fictitious account linked to a functioning credit card into the merchant database that stores customer data. More than one marked order may be placed with the merchant. One or more marked accounts may be placed and stored in the same merchant storage database. One or more marked accounts may be placed and stored in a plurality of merchant storage databases.

Then the hacked database identification program may determine a database breach when a hacker executes a purchase with the marked stolen credit card number. Next, the hacked database identification program may notify the security service provider. The service provider may determine which specific database the hacker may have compromised using the hacked database identification program. The database storing the marked account may be the hacked database if the credit card associated with the marked account was used since the decoy marked account may not be authorized to be used. Use of the decoy marked account may indicate to the hacked database identification program that a specific database may have been compromised. The service provider may then take several possible courses of action, such as notify the merchant who has the customer records, notify the authorities who may track the hacker, or allow the hacker to execute the purchase or multiple purchases to attempt to identify the mule places. A money mule may be a person who receives payment for the service of transferring illegal money. The transfer of illegal money may be moved in person, through another service or electronically. The hacked database identification program may alert the security service provider when the marked data has been used, which may occur soon after the marked data is stolen or may occur months or years after the marked data is stolen. The hacked database identification program may identify a database that has been compromised once the hacked data has been used or even before being used, for example, when intercepted upon publication on the dark web.

Another embodiment may be further enhanced by periodically adding marked data into a database (i.e., periodic merchant orders) to narrow down a time frame in which the database has been hacked. This embodiment may, for example, add marked data into the same merchant database once per month and usage of stolen data may indicate when the database was compromised. If marked data was inserted into a database every month, the data used by a hacker may be determined based on what month the marked data was inserted This method may give the company or the proper authorities an approximate 30-day window in which the database was compromised. Further, marked data may be inserted every day to create a narrow window to determine when the database may have been compromised. The time frame may also be extended longer than a monthly insertion of marked data into the database if a narrow time frame is not ideal.

The computer102may be a merchant computer, a customer computer, a user computer or a network service provider computer that may run the hacked database identification program110a. The server112may be used by a merchant, a customer, a user or a network service provider and the server may run the hacked database identification program110b.

According to the present embodiment, a merchant or a service provider using a computer102or a server computer112may use the hacked database identification program110a,110b(respectively) to identify stolen databases. The hacked database identification method is explained in more detail below with respect toFIG. 2.

Referring now toFIG. 2, an operational flowchart illustrating the exemplary hacked database identification process200used by the hacked database identification program110a,110baccording to at least one embodiment is depicted.

At202, the service provider creates a marked account. The service provider may create a marked account by using the same process a customer may use to create an account with a merchant, an organization or an entity. The marked account may be an online merchant account and may be created with the proper details relied upon by the merchant to associate a customer with the account, such as a name, address, email address, username and password. The newly created account may be linked to a credit card for purchases. The credit card may be issued from a credit card company (i.e., financial institution). The details of the service provider account may be fictitious, however, the credit card account may be valid, able to be processed and marked by the hacked database identification program110a,110b. The service provider account created with a merchant may be marked to identify which database has been hacked. The marked account may be associated with a valid credit card or the marked account may be associated with other sensitive data such as a social security number. The service provider may create a plurality of marked accounts with a single merchant or a plurality of merchants. The created marked account or the multiple created marked accounts may be listed and saved in the service provider data repository and each created marked account may be associated with a merchant database. The service provider may keep the saved list of marked accounts associated with each merchant to know where each marked account is being stored and which merchant database is storing the marked account. The service provider may choose to save the created marked account, including the credit card number, on the merchant's web site. The merchant website may then store the marked account in a database that holds valuable customer data that a hacker may want to compromise.

For example, the service provider creates an online profile with a clothing merchant store. In order to create an online profile, the merchant website requires the user, here the service provider, to provide an email address, username and password to create the online profile. The service provider uses fictitious data to create the online profile with the merchant.

Then, at204, the service provider places an order and the marked data is entered in the merchant database. The service provider may place an order with a merchant for a good or service the merchant may be selling. The order may be placed using the marked account and the merchant may not know about the marked account. The service provider may choose to create a marked account with the merchant's knowledge or without the merchant's knowledge. Once the order is placed, the fictitious data and valid marked credit card number may be transmitted into a merchant database or a third-party database with other customer data. If the database is hacked and the hacker uses the stolen customer data and credit card numbers, then the hacked database identification program110a,110bmay identify which database has been hacked based on which marked account the hacker may have used.

Additionally, the service provider may place more than one order with the same merchant using a different set of marked account details (i.e., fictitious details linked to a valid marked credit card) at different time periods (i.e., periodic merchant orders) to establish a time frame the hacker may have compromised a certain database. Different fictitious marked accounts may be used for different merchants and different databases to identify a particular database with a particular fictitious marked account. The service provider may create a new marked account for each order placed with a merchant. Continuing from the previous example, the service provider will place an order using the online profile previously created with the clothing store merchant. The service provider will enter a name, address and phone number associated with a valid credit card to complete the order. The marked account details are then stored in the merchant database that stores other customer order information and payment details.

Next, at206, the hacked database identification program110a,110bdetermines if the marked data has been used. Marked data may be identified upon use. The marked data, such as a valid credit card in possession of the service provider, may be created for the purpose of alerting the service provider of use. For example, if a hacker has compromised a database of information including credit card numbers, then uses the stolen credit cards to make unauthorized purchases, the service provider's fictitious data linked to the valid marked credit card may also be used by the hacker. Once the marked credit card is used, the service provider may be alerted by receiving a notification on a computing device of the marked credit card use. Credit card alerts may be an alert on a computing device connected to a communication network116notifying the credit card owner that the card has been used. The hacker may not know the marked credit card is marked because the credit card is linked to legitimate assets and the payment may have been accepted for the hacker's use of the marked credit card. After being alerted, the service provider may trace the fictitious account with the marked credit card to a specific database by locating, in the service provider repository, the saved data that associates each fictitious account with each credit card. The saved data may show which marked account was used and may show which merchant stored the marked account from the order that was previously placed.

If the hacked database identification program110a,110bdetermines that the marked data has not been used at206, then the status of the merchant's database is unknown at208. If a database was not compromised, then the fictitious data account linked to the valid marked credit card may not have been used. Alternatively, if the merchant database was compromised, however, the fictitious data account linked to the marked credit card has not been used yet, then the hacked database identification program110a,110bmay not identify the compromised database.

If the hacked database identification program110a,110bdetermines that the marked data has been used at206, then the merchant database has been hacked and the hacked database identification program110a,110bwill determine which database has been compromised and notify the proper entity at210. If the fictitious data account linked to the valid marked credit card was used, then the service provider may be notified that the database that stored the fictitious data account linked to the valid marked credit card has been compromised. The hacked database identification program110a,110bmay notify the service provider, the merchant or the proper authorities. Notifications may be alerted to, for example, the service provider via an alert to a computer102, a cell phone, a watch, a tablet or a device capable of receiving alert messages.

It may be appreciated thatFIG. 2provides only an illustration of one embodiment and does not imply any limitations with regard to how different embodiments may be implemented. Many modifications to the depicted embodiment(s) may be made based on design and implementation requirements.

An additional embodiment to creating a marked account at202may include a merchant who has a website that provides an option to save account details for a user for ease of future shopping at the merchant's online store. The service provider may opt to save identifying information using the merchant's web site since these features are offered to users for the ability to efficiently and quickly shop at the merchant's online store. The service provider may input an email address, username, password, name, address, phone number and valid credit card number on the merchant database for one profile (i.e., marked account). Opting to save identifying information and payment details on a merchant's web site may provide one other method to save the marked account data in the merchant database.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Referring now toFIG. 5, a set of functional abstraction layers1100provided by cloud computing environment1000is shown. It should be understood in advance that the components, layers, and functions shown inFIG. 5are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Workloads layer1144provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation1146; software development and lifecycle management1148; virtual classroom education delivery1150; data analytics processing1152; transaction processing1154; and identifying stolen databases1156. A hacked database identification program110a,110bprovides a way to know when a network database has been hacked once the hacker attempts to use the compromised data.