Questions About Data Breaches that You Were Too Shy to Ask

  1. It is obvious when your credit card details are offered for sale on the dark web, but what else constitutes a Data Breach?
  2. How serious are insider threats?
  3. I’m trading only in America. Am I required to notify anyone when there is a breach of personal data?
  4. A friend of mine has just had suffered a data breach in his company. What should he do?
  5. How do breaches happen?
  6. What is likely to be the worst consequence of a data breach?
  7. How frequent are data breaches?
  8. Is SQL Injection the main threat to databases? How is it prevented?
  9. What is the highest risk factor in data breaches?
  10. How could we set up a database intrusion system?
  11. How should an organisation prepare for the eventuality of a data breach?

1. It is obvious when your credit card details are offered for sale on the dark web, but what else constitutes a Data Breach?

Data breaches (also known as data leaks or data spills) can be caused by hostility, malice, mischief, carelessness, inattention or sheer accident. It can range from political ‘activism’ to taking old workstations to a public dump with their hard drives still in place. As well as being due to organized crime, competing organizations, or attacks by hostile foreign regimes, they are often due to staff within an organization being bribed, careless or naive. A considerable number are the work of bored youngsters.

Whenever sensitive, protected or confidential data gets into the control of an unauthorized person, then there has been a data breach. The consensus definition is that a data breach is ‘a compromise of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to protected data transmitted, stored or otherwise processed.’ (ISO/IEC 27040). This definition is no longer adequate: A breach can result from an apparently trivial incident such as accidentally exposing a directory that contains sensitive or confidential information to general access over the internet. If it cannot be proved that it was never accessed, it should be recorded as a data breach. A recent famous example of this was when the AA car insurance and breakdown company in the UK left 13GB of customer information unsecured online last year. It was available to anyone online for a few days in April due to a server ‘misconfiguration’.

The definition of a breach also needs to be widened because of the way that it is possible to extract a surprising amount of personal information by inference attack through joining apparently-innocuous sets of data. A pseudonymized set of records that is published can be a data breach if it can subsequently identify real data about real individuals when combined with another dataset.

If an organisation infringes published security guidelines, the onus is on the organization to demonstrate that there was no breach. For example, the use of live data for developing or testing databases can, in some cases, be considered a data breach if all necessary precautions haven’t been taken, such as performing security checks on contract staff, or implementing access control for developers. Again, the problem, if your auditors become aware of this, is in proving that no actual data breach resulted from unnecessarily exposing the data.

Sometimes, a breach is only confirmed retrospectively by accident, as when a security firm subsequently stumbles across the data on the Dark Web, as when a contractor to the Republican National Committee left a terabyte of data on an unsecured cloud server that included names, dates of birth, home addresses, phone numbers, voter registration details and ‘modelled’ ethnicities and religions.

2. How serious are insider threats?

Sadly, we don’t clearly know the proportion of data breaches that are due to insiders within the organization, because so many have gone unreported. Estimates of the proportion of breaches caused by accidental staff errors range from 14% to 37%. The estimates of disclosure of sensitive company information by insiders vary widely too. We know much more now about the unauthorized passing of data to ‘third parties’ such as journalists from government or healthcare officials because it has been a feature of several public scandals involving the press. Where organizations don’t implement full access control and sensible audit systems, they are unlikely to ever be aware of this type of breach at the time. This has led to the saying ‘There are two types of companies: those that have been hacked, and those that don’t know they have been hacked’.

3. I’m trading only in America. Am I required to notify anyone when there is a breach of personal data?

As well as your moral obligations, 94% of all US states, as well as Puerto Rico, Guam, the Virgin Islands and Washington, DC, oblige your organization to notify everyone whose personal data has been compromised by a data breach, and to notify the relevant supervisory authority as soon as possible. There are regional variations in the definition of personal information and the manner of notification. There are also variations in the defined rights of action that are open to people suffering from a breach of personal information when an organization fails to comply with the notification law. There are details of the law in each state regarding notification but there is a consensus that it must be as soon as possible without undue delay.

4. A friend of mine has just suffered a data breach in his company. What should he do?

You need … sorry … He needs to stop the security breach as soon as possible: Then he must make sure that all the vulnerabilities that led to the incident are fixed. Typically, there will be several. Then he needs to determine whether the nature of the breach obliges him to notify the relevant supervisory authority and the affected individuals. Because a breach is very unlikely to have a single cause, he must audit the applications, systems and networks involved. It helps to implement a comprehensive security protocol and do an intensive and thorough review of network and application security. He must quickly ascertain what personal information was compromised and notify everyone who was affected as soon as possible. He should ensure that there are robust systems in place for breach detection and investigation, and that there are internal reporting procedures in place. He must keep a record of any personal data breaches, regardless of whether they are of a severity that required him to notify the individuals and authorities.

5. How do breaches happen?

It can be any number of reasons, including SQL Injection, a phishing attack, Malware, stolen media, an inside job, accidental publishing, ‘social engineering’, faulty ‘pseudonymization’, an unsecured API, Software bugs, theft of access keys, ‘whistle-blowing’, completely unsecured databases, system vulnerabilities, gaining network access via an unpatched service, use of an open-source content management system, theft of an ‘isolated user account’, careless security from a third-party technology provider, leaving a laptop on a train, dumping old filing cabinets in a disused office cellar, sending old IT equipment to scrap without wiping drives, using third-party add-ins such as forum software to websites or often a combination of all these. OK. To sum up, human nature taking advantage of a whole range of human failings when faced by a fast-moving technology.

6. What is likely to be the worst consequence of a data breach?

There was a time that such matters were of little public interest, but the scale of recent breaches and tragic consequences of a few of them has made it headline news. There is what is termed ‘reputational collateral’. Target’s 2013 breach, for example, cost them an estimated 40 percent drop in profit in the 4th quarter of that year. Yahoo’s loss of personal data of its three billion users dropped its value over 1 billion dollars. However, the worst financial impact for a company that suffers a breach is likely to be the expense, distraction and time of the subsequent legal and audit work, the impact on the staff within the organization and, increasingly, the lawsuits. I wouldn’t want to include the cost of the work to fix the organization’s IT, since this would probably have been below standard anyway unless the breach came like a bolt from the blue.

7. How frequent are data breaches?

All the evidence suggests that data breaches are very frequent, but only the major breaches that affect personal data are reported, Several lists are now maintained, such as Wikipedia’s. Anyone who is responsible for Data Security should read the background details of each breach whenever it becomes public.

8. Is SQL Injection the main threat to databases? How is it prevented?

Not necessarily. SQL Injection is certainly unusual in that It is possible to get at sensitive data via the connection to the database exposed by the application. This is particularly easy on a carelessly-written web-based application. Although SQL injection is the term used, NoSQL databases are also equally vulnerable to attack, due mostly to poor installation and configuration.

SQL injection is inherent in any command or query language that allows literals such as delimited strings or values in expressions. Basically, it allows the attacker to ‘inject’ other queries or statements into the query being used to send application data to the database. These queries can cause data to be returned to the web application. To prevent SQL Injection, it is not sufficient to parameterize queries. All input must also be validated on the server side as well as the application, because the database cannot assume that the connection is being made via the application, or that the application hasn’t been compromised: The application cannot assume that all possible checks are being made by the database. There is a ‘trust boundary’ here. This validation must include checks for the type, size, or content of the data, and must look for obvious injection strings. All database testing must include checks for this. This is not as easy as it might sound. If a string parameter contains a suspect character or substring (‘xp_’, ‘—‘,’/*’ and so on, complete lists of such strings are available) then the entry should be put in abeyance, and a process should send an alert to an administrator who checks whether the parameter value is valid. This needs care and subtlety: Null is a name with a long history, originally from Donegal in Ireland, and meaning an Ulsterman. Alter is both a surname and a given name, coming originally from the Yiddish personal name Alter, an inflected form of alt meaning ‘old’. The Join family is well-known in France.  There are people with the surname Drop from Norfolk. There are plenty members of the of Table family from Tapeley in Devon UK that are alive and well. There are plenty of companies called Select. Johann Jacob Create, and Michael Create both landed in Pennsylvania in the 1750s.

These names should not cause alerts. To check this, such names should be in the test data and checked as valid input for a customer name. XML parameters should be treated with suspicion unless schema-bound. JSON Data must be taken apart and individual values checked.

As well as parameter-checking, the risk of successful SQL Injection is reduced even more by enforcing full access control. After all, an attacker with an application login would need direct access to tables containing the sensitive information in order to bypass the interface. The attacker would be faced with the trickier task of escalating the privileges of the login. Access control requires that all users of the applications must have a login that gives them access only to the data that is required for their role. The simplest way to do this is to provide a default schema appropriate to the users’ assigned role, never DBO. This schema will contain only an interface that gives access to the data that is required by the user. The interface will consist of procedures, or multi-statement functions that validate the input, and preferably logs each call, with User Id, time, and parameters. The server should log each query made against the interface.

Pure SQL Injection takes time when the attacker needs to understand the database schema and access rights by trial and error, because each error can be logged in the system and so a sudden rash of SQL errors should cause an alert in any well-designed SQL Server system. A lot must be wrong with an application to allow a successful SQL Injection attack.

9. What is the highest risk factor in data breaches?

The most likely cause of a data breach is likely to be poor system configuration, failing to apply security patches and updates to server software and operating systems appropriately, choosing weak or popular passwords, keeping the default user ID, failing to identify and eliminate system vulnerabilities, losing devices such as laptops and mobiles, leaving devices open while they are unattended, or not using the proper disclosure procedures. The organisation can make itself vulnerable to a breach through poorly-supervised staff, untracked/unaudited database access or a failure to identify ‘broken’ business processes.

10. How could we set up a database intrusion system?

Ordinary intrusion detection systems can only monitor the network and OS for signs of intrusion. They are useful to have but can give you a false sense of security. Systems for detecting database intrusions need to monitor usage at both the transaction level and process level for anomalous patterns of usage. Generally, these need to establish baseline usage to determine patterns and rules over time. This approach identifies a new user transaction as anomalous, and therefore worth investigating, if it does not conform to the patterns of normal transactions, as established by analyzing the logs for the usual usage over phases of the organization’s work.

Intrusions often require the intruders to test the metadata by deliberately causing errors. This will often cause SQL errors where they would usually be highly infrequent. The same is true of intrusions executed by unauthorized users to explore system vulnerabilities, and also tend to happen when malicious database transactions are executed by authorized users. SQL Errors should always be investigated in production systems.

An effective ruse to alert for an external attack is to have parts of the database with perfectly feasible and believable data, but which are never legitimately accessed. This is termed by a number of names such as Database Honeypot, Database Sting or Wasp Trap. Any attempt at access triggers an alert. Because SQL Injections where attackers are ‘working blind’ without access to the metadata tend to work through a number of standard names of tables found from experience, it is worth naming the tables carefully to fit in with their expectations.

11. How should an organisation prepare for the eventuality of a data breach?

There are five important aspects in preparing for the eventuality of a breach. If you are responsible for data security, you should …