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 …

• Understand your data and its milieu There should be a map of your sensitive data, and its flow, and you should identify all the third parties and contract organizations with whom it is shared. You will need to evaluate whether all your systems and applications are up-to-date with their patches and configurations. You will need to understand and reduce the surface area of all potential attack vectors.
• Improve your ability to detect breaches. A data breach takes time, sometimes many weeks of probing. If it is caused by people within the organization, it could go on undetected for years. The organization must be able to detect data leaks as they happen. This means that everyone involved must be able to recognize a data breach. It pays dividends to have a network intrusion detection system that can regularly scan endpoints across the network to search for malicious behavior that can indicate an active intrusion is underway.
• Test your systems. Penetration-testing is essential to firm up your security. There are many penetration tests systems available, including PowerShell-based systems that can gain control of a badly-configured SQL Server system within minutes. Staff should be encouraged to use them to make sure there are no security loopholes. Many organizations run ‘fire-drill’ exercises that orchestrate real-time attacks. These will show where weaknesses are in the organization that test awareness of such things as a phishing attack and checks the organizations ability to respond to a real incident. This should be able to highlight any gaps in your incident response plan, and continually update it.
• Understand the consequences of breaches. The organization must understand the broader consequences of a data breach. It isn’t only about loss or theft of data.
• Planning for reacting appropriately to a breach: There must be a documented and tested plan for responding to a data breach, whether it is personal, business or financial data. Minutes matter more than anything when dealing with a compromised network. If the plan for dealing with this is tried and tested, you can collect, analyze and act on information very quickly, even if it happens at night or during holidays. The response plan should have an explicit plan for each class of incident, from run-of-the-mill threats to complete compromise of the network. It needs to follow the whole epic from initial detection to post-mortem and document the lessons learned.
• Make Data Governance part of the organization: There must be part of an organization that is directly responsible for recording all breaches however trivial, managing breaches if they happen, and trying to ensure that they don’t. If, however, they do happen, they must ensure that they are quickly sealed. They need to have a process in place that assesses the likely risk to individuals because of a personal data breach, and a process that provides a notification. This team must collaborate with other business groups, including public relations, legal, human relations and the executive team, especially following an incident. An organized response can take the form of a computer incident response team (CIRT) – where there are defined roles and responsibilities, including threat monitoring, vulnerability assessment and incident handling. This part of the organization must keep up to date with the types of threats that are likely; the latest cybercriminal patterns, attack techniques and malware trends.
• Promote awareness of data breaches: Everyone in the organization needs to understand what a breach is, understand the signs that a breach has happened, and know whom in the organization to notify in order to escalate a security incident.