Tag Archives: eu data protection regulation

Post-Davos Thoughts on the EU NIS Directive

Post-Davos Thoughts on the EU NIS Directive

I’ve been meaning to read the 80-page report published by the World Economic Forum (WEF) on the global risks humankind now faces. They’re the same folks who bring you the once a year gathering of the world’s bankers and other lesser humanoids held at a popular Swiss ski resort. I was told there was an interesting section on … data security.

And there was. Data security is part of a report intended to help our world leaders also grapple with climate change, nuclear annihilation, pandemics, economic meltdowns, starvation, and  terrorism.

How serious a risk are cyber attacks?

In terms of impact, digital warfare makes the WEF top-ten list of global issues, ranking in the sixth position, between water and food crises, and beating out the spread of infectious diseases in the tenth position. It’s practically a fifth horsemen of the apocalypse.

Some of the worrying factoids that the WEF brought to the attention of presidents, prime ministers, chancellors, and kings was that in 2016 over 350 million malware variants were unleashed on the world, and that by 2020, malware may potentially finds its way to over 8.4 billion IoT devices.

There are about 7.6 billion of us now, and so we’ll soon be outnumbered by poorly secured internet connected silicon-based gadgets. It’s not a very comforting thought.

The WEF then tried to calculate the economic damage of malware. One study they reference puts the global cost at $8 trillion over the next five years.

The gloomy WEF authors single out the economic impact of ransomware. Petya and NotPetya were responsible for large costs to many companies in 2017. Merck, FedEx, and Maersk, for example, each reported offsets to their bottom line of over $300 million last year as a result of NotPetya attacks.

Systemic Risk: We’re All Connected

However, the effects of malware extend beyond economics. One of the important points the report makes is that hackers are also targeting physical infrastructure.

WannaCry was used against the IT systems of railway providers, car manufacturers, and energy utilities. In other words, cyberattacks are disrupting things from happening in the real-world: our lights going out, our transportation halted, or factory lines shut down all because of malware.

And here’s where the WEF report gets especially frightening. Cyber attacks can potentially start a chain reaction of effects that we humans are not good at judging. They call it “systemic risk”

They put it this way:

“Humanity has become remarkably adept at understanding how to mitigate countless conventional risks that can be relatively easily isolated and managed with standard risk management approaches. But we are much less competent when it comes to dealing with complex risks in systems characterized by feedback loops, tipping points and opaque cause-and-effect relationships that can make intervention problematic.”

You can come up with your own doomsday scenarios – malware infects stock market algorithms leading to economic collapse and then war – but the more important point, I think, is that our political leaders will be forced to start addressing this problem.

And yes I’m talking about more regulations or stricter standards on the IT systems used to run our critical infrastructure.

NIS Directive

In the EU, the rules of the road for protecting this infrastructure are far more evolved than in the US. We wrote about the Network and Information Security (NIS) Directive way back in 2016 when it was first approved by the EU Parliament.

The Directive asks EU member states to improve co-operation regarding cyber-attacks against critical sectors of the economy — health, energy, banking, telecom, transportation, as well as some online businesses — and to set minimum standards for cyber security preparedness, including incident notification to regulators. The EU countries had 21 months to “transpose” the directive into national laws.

That puts the deadline for these NIS laws at May 2018, which is just a few months away. Yes, May will be a busy month for IT departments as both the GDPR and NIS go into effect.

For example, the UK recently ended the consultation period for its NIS law. You can read the results of the report here. One key thing to keep in mind is that each national data regulator or authority will be asked to designate operators of “essential services”, EU-speak for critical infrastructure. They have 6-months starting in May to do this.

Anyway, the NIS Directive is a very good first step in monitoring and evaluating malware-based systemic risk. We’ll keep you posted as we learn more from the national regulators as they start implementing their NIS laws.

 

 

Our Most Underappreciated Blog Posts of 2017

Our Most Underappreciated Blog Posts of 2017

Another year, another 1293 data breaches involving over 174 million records. According to our friends at the Identity Theft Resource Center, 2017 has made history by breaking 2016’s record breaking 1091 breaches. Obviously it’s been a year that many who directly defend corporate and government systems will want to forget.

Before we completely wipe 2017 from our memory banks, I decided to take one last look at the previous 12 months worth of IOS posts.  While there are more than a few posts that did not receive the traffic we had hoped, they nevertheless contained some really valuable security ideas and practical advice.

In no particular order, here are my favorite underachieving posts of the 2017 blogging year.

Interviews

Wade Baker Speaks – We did a lot of interviews with security pros this year —researchers, front-line IT warriors, CDOs, privacy attorneys.  But I was most excited by our chat with Wade Baker. The name may not be familiar, but for years Baker produced the Verizon DBIR, this blog’s favorite source of breach stats. In this transcript, Wade shares great data-driven insights into the threat environment, data breach costs, and how to convince executives to invest in more data security.

Ann Cavoukian and GDPR – It’s hard to believe that the General Data Protection Regulation (GDPR) is only a few months away. You can draw a line from Cavoukian’s Privacy by Design ideas to the GDPR.  For companies doing business in the EU, it will soon be the case that PbD will effectively be the law. Read the Cavoukian transcript to get more inspired.

Diversity and Data Security – The more I learn about data security and privacy, the more I’m convinced that it will “take a village”.  The threat is too complex for it to be pigeon-holed into an engineering problem. A real-world approach will involve multiple disciplines — psychology, sociology, law, design, red-team thinking, along with computer smarts. In this interview with Allison Avery, Senior Organizational Development & Diversity Excellence Specialist at NYU Langone Medical Center, we learn that you shouldn’t have preconceived notions of who has the right cyber talents.

Infosec Education

PowerShell Malware –  PowerShell is a great next-generation command line shell. In the last few years, hackers have realized this as well and are using PowerShell for malware-free hacking. A few months ago I started looking into obfuscated PowerShell techniques, which allow hackers to hide the evil PowerShell and make it almost impossible for traditional scanners to detect. This is good information for IT people who need to get a first look at the new threat environment. In this two-part series, I referenced a Black Hat presentation given by Lee Holmes — yeah, that guy!  Check out Lee’s comment on the post.

Varonis and Ransomware – This was certainly the year of weaponized ransomware with WannaCry, Petya, et. al. using the NSA-discovered EternalBlue exploit to hold data hostage on a global scale. In this post, we explain how our DatAlert software can be used to detect PsExec, which is used to spread the Petya-variant of the malware. And in this other ransomware post, we also explain how to use DatAlert to detect the mass encryption of files and to limit your risks after ransomware infection.

PowerShell as a Cyber Monitoring Tool – I spent a bit of effort in this long series explaining how to use PowerShell to classify data and monitor events — kind of a roll-your-own Varonis. Alas, it didn’t get the exposure I had hoped. But there are some really great PowerShell tips, and sample code using Register-EngineEvent to monitor low-level file access events. A must read if you’re a PowerShell DIY-er.

Compliance

NIS, the Next Big EU Security Law – While we’ve all been focused on the EU GDPR, there’s more EU data security rules that go into effect in 2018. For example, The Network and Information Security (NIS) Directive.  EU countries have until July 2018 to “transpose” this directive into their own national laws. Effectively, the NIS Directive asks companies involved in critical infrastructure — energy, transportation, telecom, and Internet — to have in place data security procedures and to notify regulators when there’s a serious cyber incident. Unlike the GDPR, this directive is not just about data exposure but covers any significant cyber event, including DoS, ransomware, and data destruction.

GDPR’s 72-Hour Breach Notification – One particular GDPR requirement that’s been causing major headaches for IT is the new breach notification rules. In October, we received guidelines from the regulators. It turns out that there’s more flexibility than was first thought. For example, you can provide EU regulators partial information in the first 72-hours after discovery and more complete information as it becomes available. And there are many instances where companies will not have to additionally contact individuals if the personal data exposed is not financially harmful. It’s complicated so read this post to learn the subtleties.

By the way, we’ve been very proud of our GDPR coverage. At least one of our posts has been snippetized by Google, which means that at least Google’s algorithms think our GDPR content is the cat’s meow. Just sayin’.

Podcasts

Man vs. Machine – Each week Cindy Ng leads a discussion with a few other Varonians, including Mike Buckbee, Killian Englert, and Kris Keyser. In this fascinating podcast, Cindy and her panelists take on the question of ethics in software and data security design. We know all too well that data security is often not thought about when products are sold to consumers — maybe afterwards after a hack. We can and should do a better job in training developers and introducing better data laws, for example the EU GDPR. But what is “good enough” for algorithms that think for themselves in, say,  autonomous cars?  I don’t have the answer, but is what great fun listening to this group talk about this issue.

Cybercrime Startups – It’s strange at first to think of hackers as entrepreneurs and their criminal team as a startup. But in fact there are similarities, and hacking in 2017 starts looking like a viable career option for some. In this perfect drive-time podcast, our panelists explore the everyday world of the cybercrime startup.

Fun Security Facts

Securing S3 –  As someone who uses Amazon Web Services (AWS) to quickly test out ideas for blog posts, I’m a little in awe of Amazon’s cloud magic and also afraid to touch many of the configuration options. Apparently, I’m not the only one who gets lost in AWS since there have been major breach involving its heavily used data storage feature, known as S3. In this post, Mikes covers S3’s buckets and objects and explains how to set up security policies. Find out how to avoid being an S3 victim in 2018!

[Video] Varonis GDPR Risk Assessment   

risk assessment video

Are you ready for GDPR ? According to our survey of 500 IT and risk management decision makers, three out of four are facing serious challenges in achieving compliance when GDPR becomes effective on May 25 2018. Varonis can help.

A good first step in preparing for GDPR is identifying where EU personal data resides in the file system, and then checking that access permissions are set appropriately. But wait, EU personal data identifiers span 28 member countries, encompassing different formats for license plate numbers, national id cards, passport ids, bank accounts, and more.

That’s where our GDPR Patterns can help ! We’ve researched and hand-crafted over 250 GDPR classification expressions to help you discover the EU personal data in your systems, and analyze your exposure.

To learn more, watch this incredibly informative video and sign up today for our GDPR Risk Assessment.

 

Do Your GDPR Homework and Lower Your Chance of Fines

Do Your GDPR Homework and Lower Your Chance of Fines

Advice that was helpful during your school days is also relevant when it comes to complying with the General Data Protection Regulation (GDPR): do your homework because it counts for part of your grade! In the case of the GDPR, your homework assignments involve developing and implementing privacy by design measures, and making sure these policies are published and known about by management.

Taking good notes and doing homework assignments came to my mind when reading the new guideline published last month on GDPR fines. Here’s what the EU regulators have to say:

Rather than being an obligation of goal, these provisions introduce obligations of means, that is, the controller must make the necessary assessments and reach the appropriate conclusions. The question that the supervisory authority must then answer is to what extent the controller “did what it could be expected to do” given the nature, the purposes or the size of the processing, seen in light of the obligations imposed on them by the Regulation’

The supervising authority referenced above is what we used to call the data protection authority or DPA, which is in charge of enforcing the GDPR in an EU country. So the supervising authority is supposed to ask the controller, EU-speak for the company collecting the data, whether they did their homework — “expected to do” — when determining fines involved in a GDPR complaint.

Teachers Know Best

There are other factors in this guideline that affect the level of fines, including the number of data subjects, the seriousness of the damage (“risks to rights and freedoms”), the categories of data that have been accessed, and willingness to cooperate and help the supervisory authority. You could argue that some of this is out of your control once the hackers have broken through the first level of defenses.

But what you can control is the effort a company has put into their security program to limit the security risks.

I’m also reminded of what Hogan Lovells’ privacy attorney Sue Foster told us during an interview about the importance of “showing your work”.  In another school-related analogy, Foster said you can get “partial credit” if you show that to the regulators after an incident that you have security processes in place.

She also predicted we’d get more guidance and that’s what the aforementioned document does: explains what factors are taken into account when issuing fines in GDPR’s two-tiered system of either 2% or 4% of global revenue. Thanks Sue!

Existing Security Standards Count

The guideline also contains some very practical advice on compliance. Realizing that many companies are already rely on existing data standards, such as ISO 27001, the EU regulators are willing to give some partial credit if you follow these standards.

… due account should be taken of any “best practice” procedures or methods where these exist and apply. Industry standards, as well as codes of conduct in the respective field or profession are important to take into account. Codes of practice might give indication of the level of knowledge about different means to address typical security issues associated with the processing.

For those who want to read the fine print in the GDPR, they  can refer to article 40 (“Codes of Conduct”). In short it says that standards associations can submit their security controls, say PCI DSS, to the European Data Protection Board (EDPB) for approval. If a controller then follows an officially approved “code of conduct”, then this can dissuade the supervising authority from taking actions, including issuing fines, as long as the standards group — for example, the PCI Security Standards Council — has its own monitoring mechanism to check on compliance.

Based on this particular GDPR guideline, it will soon be the case that those who have done the homework of being PCI compliant will be in a better position to deal with EU regulators.

Certifiably GDPR

The GDPR, though, goes a step further. It leaves open a path to official certification of a controller’s data operations!

In effect, the supervising authorities have the power (through article 40) to certify a controller’s operations as GDPR compliant. The supervising authority itself can also accredit other standards organization to issue these certifications as well.

In any case, the certifications will expire after three years at which point the company will need to re-certify.

I should add these certifications are entirely voluntary, but there’s obvious benefits to many companies. The intent is to leverage the private sector’s existing data standards, and give companies a more practical approach to compliance with the GDPR’s technical and administrative requirements.

The EDPB is also expected to develop certification marks and seals for consumers, as well as a registry of certified companies.

We’ll have to wait for more details to be published by the regulators on GDPR certification.

In the short term, companies that already have programs in place to comply with PCI DSS, ISO 27001, and other data security standards should potentially be in a better position with respect to GDPR fines.

And in the very near future, a “European Data Protection Seal” might just become a sought after logo on company web sites.

Want to reduce your GDPR fines? Varonis helps support many different data security standards. Find out more!

[Podcast] Privacy Attorney Tiffany Li and AI Memory, Part II

[Podcast] Privacy Attorney Tiffany Li and AI Memory, Part II

This article is part of the series "[Podcast] Privacy Attorney Tiffany Li and AI Memory". Check out the rest:

Leave a review for our podcast & we'll send you a pack of infosec cards.


Tiffany C. Li is an attorney and Resident Fellow at Yale Law School’s Information Society Project. She frequently writes and speaks on the privacy implications of artificial intelligence, virtual reality, and other technologies. Our discussion is based on her recent paper on the difficulties of getting AI to forget.

In this second part, we continue our discussion of GDPR and privacy, and examine ways to bridge the gap between tech and law. We then explore some cutting edge areas of intellectual property. Can AI algorithms own their creative efforts? Listen and learn.

[Podcast] Privacy Attorney Tiffany Li and AI Memory, Part I

[Podcast] Privacy Attorney Tiffany Li and AI Memory, Part I

This article is part of the series "[Podcast] Privacy Attorney Tiffany Li and AI Memory". Check out the rest:

Leave a review for our podcast & we'll send you a pack of infosec cards.


Tiffany Li is an attorney and Resident Fellow at Yale Law School’s Information Society Project. She frequently writes about the privacy implications of artificial intelligence, virtual reality, and other disruptive technologies. We first learned about Tiffany after reading a paper by her and two colleagues on GDPR and the “right to be forgotten”. It’s an excellent introduction to the legal complexities of erasing memory from a machine intelligence.

In this first part of our discussion, we talk about GDPR’s “right to be forgotten” rule and its origins in a law suit brought against Google. Tiffany then explains how deleting personal data is more than just removing it from a folder or directory.

We learn that GDPR regulators haven’t yet addressed how to get AI algorithms to dynamically change their rules when the underlying data is erased. It’s a major hole in this new law’s requirements!

Click on the above link to learn more about what Tiffany has to say about the gap between law and technology.

Continue reading the next post in "[Podcast] Privacy Attorney Tiffany Li and AI Memory"

IT Guide to the EU GDPR Breach Notification Rule

IT Guide to the EU GDPR Breach Notification Rule

Index

The General Data Protection Regulation (GDPR) is set to go into effect in a few months — May 25 2018 to be exact. While the document is a great read for experienced data security attorneys, it would be nifty if we in the IT world got some practical advice on some of its murkier sections — say, the breach notification rule as spelled out in articles 33 and 34.

The GDPR’s 72-hour breach notification requirement is not in the current EU Directive, the law of the land since the mid-1990s. For many companies, meeting this tight reporting window will involve their IT departments stepping up their game.

With help from a few legal experts — thanks Sue Foster and Brett Cohen — I’ve also been pondering the language in the GDPR’s notification rule. The key question that’s not entirely answered by GPDR legalese is the threshold for reporting in real-world scenarios.

For example, is a ransomware attack reportable to regulators? What about email addresses or online handles that are exposed by hackers?

Read on for the answers.

Personal Data Breach versus Reportable Breach

We finally have some solid guidance from the regulators. Last month, the EU regulators released some answers for the perplexed, in a 30-page document covering guidelines  on breach notification – with bonus tables and flowcharts!

To refresh fading memories, the GDPR says that a personal data breach is a breach of security leading “to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.”

This is fairly standard language found in any data privacy law — first define a data breach or other cybersecurity event. This is what you’re supposed to be protecting against — preventing these incidents!

There’s also additional criteria for deciding when regulators and consumers have to be notified.

In short: not every data security breach requires an external notification!

This is not unusual in data security laws that have breach report requirements. HIPAA at the federal level for medical data and New York State’s innovative cyber rules for finance make these distinctions as well. It’s a way to prevent regulators from being swamped with breach reports.

In the case of the GDPR, breaches can only involve personal data, which is EU-speak for personally identifiable information or PII. If your company is under the GDPR and it experiences an exposure of top-secret diagrams involving a new invention, then it would not be considered a personal data breach and therefore not reportable. You can say the same for stolen proprietary software or other confidential documents.

Notifying the Regulators

Under the GPDR, when does a company or data controller have to report a a personal data breach to the local supervising authority – what we used to call the local data protection authority or DPA in the old Directive?

This is spelled out in article 33, but it’s a little confusing if you don’t know the full context. In essence, a data controller reports a personal data breach — exposure, destruction, or loss of access—if this breach poses a risk to EU citizens “rights and freedoms”.

These rights and freedoms refer to more explicit property and privacy rights spelled out in the EU Charter of Fundamental Rights — kind of the EU Constitution.

I’ve read through the guidance, and just about everything you would intuitively consider a breach — exposure of sensitive personal data, theft of a device containing personal data, unauthorized access to personal data — would be reportable to regulators.

And would have to be reported within 72-hours! It is a little more nuanced and you have some wiggle room, but I’ll get to that at the end of this post.

The only exception here is if the personal data is encrypted with state of the art algorithms, and the key itself is not compromised, then the controller would not have to report it.

And a security breach that involves personal data, as defined by the EU GDPR, but that doesn’t reach the threshold of “risks to rights and freedoms”?

There’s still some paperwork you have to do!

Under the GDPR, every personal data breach must be recorded internally: “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach”— see Article 33(5).

So the lost or stolen laptop that had encrypted personal data or perhaps an unauthorized access made by an employee — she saw some customer account numbers by accident because of a file permission glitch — doesn’t pose risks to rights and freedoms but it would still have to be documented.

There’s a good Venn diagram hidden in this post, but for now gaze upon the flowchart below.

Not as beautiful as a Venn diagram but this flowchart on GDPR breach report will get you the answers. (Source: Article 29 Working Party)

Let’s look at one more GDPR reporting threshold scenario involving availability or alteration of personal data.

Say EU personal data becomes unavailable due to a DDoS attack on part of a network or perhaps it’s deleted by malware but there is a backup, so that in both cases you have a loss albeit temporary — it’s still a personal data breach by the GDPR’s definition.

Is this reportable to the supervising authority?

It depends.

If users can’t gain access to say their financial records for more than a brief period, maybe a day or two, then this would impact their rights and freedoms. This incident would have to be reported to the supervising authority.

Based on the notes in the guidance, there’s some room for interpreting what this brief period would be. You’ll still need, though, to document the incident and the decision making involved.

Breach Notification and Ransomware

Based on my chats with GDPR experts, I learned there was uncertainty even among the legal eagles whether a ransomware attack is reportable.

With the new guidance, we now have a clearer answer: they actually take up ransomware scenarios in their analysis.

As we all know, ransomware encrypts corporate data for which you have to pay money to the extortionists in the form of Bitcoins to decrypt and release the data back to its plaintext form.

In the GDPR view, as I suggested above, ransomware attacks on personal data are considered a data loss. When does it cross the threshold and become a reportable data breach?

According to the examples they give, it would be reportable under two situations: 1) There is a backup of the personal data but the outage caused by the ransomware attack impacts users; or 2) There is no backup of the personal data.

In theory, a very short-lived ransomware attack in which the target recovery quickly is not reportable. In the real world where analysis and recovery takes significant time, most ransomware attacks would effectively be reportable.

Individual Reporting

The next level of reporting is a personal data breach in which there is a “high risks to the rights and freedoms.” These breaches have to reported to the individual.

In terms of Venn diagrams and subsets, we can make the statement that every personal data breach that is individually reported also has to be reported to the supervising authority. (And yes, all Greeks are men).

When does a personal breach reach the level of high risks?

Our intuition is helpful here, and the guidelines list as examples, personal data breaches that involve medical or financial (credit card or bank account numbers).

But there are other examples outside the health and banking context. If the personal data breach involves name and address of customers of a retailer who have requested delivery while on vacation, then that would be a high risk, and would require the individuals to be contact.

A breach of contact information alone — name, address, email address, etc — alone may not necessarily require notification. But would require the supervising authority and individual to be informed if a large number of individual are affected! According to the guidelines, size does matter. So a Yahoo-level exposure of email addresses would lead to notifications.

The guidelines make a point that if this contact information includes other sensitive data — psychological, ethnic, etc. — then if would be reportable regardless of the number of individuals affected.

Note: a small breach of emails without other confidential information is not reportable. (Source:Article 29 Working Party)

Or if the contact information, email addresses say, are hacked from a children’s website and therefore the group is particularly vulnerable, then this would constitute a high risk and a notification to the individuals involved.

Breach Notification in Phases

While the 72-hour GDPR breach notification rule was somewhat controversial, it’s actually more flexible once you read the fine print.

The first key point is that the clock starts ticking after the controller becomes aware of the personal data breach.

For example, suppose an organization detect a network intrusion from an attacker. That 72-hour window does not start at this point.

And then there’s an investigation to see if personal data was breach. The clock still doesn’t start. When the IT security team discovers with reasonable certainty that there has been a personal data breach, then the clock starts!

When notifying the supervising authority, the data controller can do this in phases.

It is perfectly acceptable to notify the supervising initially when there has been discovery (or the likelihood) of a personal data breach and to tell them that more investigation is required to obtain details — see Article 33(4). This process can take more than 72-hours, and is allowed under the GDPR.

And if turns out to be a false alarm, they can ask the supervising authority to cancel the notification.

For personal data breaches in which it is discovered there is a high risk to individual, the notification to affected “data subjects” must be made without “undue delay”— see Article 34(1). The objective is to inform consumers about how they’ve been affected and what they need to take to protect themselves.

Notification Details

This leads to the final topic in this epic post: what do you tell the supervising authority and individuals?

For supervising, here’s the actual language in Article 33:

  • Describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
  • Communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;
  • Describe the likely consequences of the personal data breach;
  • Describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

Note the requirement to provide details on the data categories and approximate number of records involved.

The supervising authority can, by the way, request additional information. The above list is the minimum that the controller has to provide.

When notifying individuals (see Article 34), the controller also has to offer the following:

  • a description of the nature of the breach;
  • the name and contact details of the data protection officer or other contact point;
  • a description of the likely consequences of the breach; and
  • a description of the measures taken or proposed to be taken by the controller to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.

The GDPR prefers that the controller contact affected individuals directly – rather than through a media broadcast.  This can include email, SMS text, and snail mail.

For indirect mass communication, prominent banners on web sites, blog posts, or press releases will do fine.

The GDPR breach notification guidelines that were released last month is about 30 pages. As an IT person, you will not be able to appreciate fully all the subtleties.

You will need an attorney—your corporate counsel, CPO, CLO, etc.—to understand what’s going with this GDPR breach  guideline and other related rules.

That leads nicely to this last thought: incident response to a breach requires combined efforts of IT, legal, communications, operations, and PR, usually at the C-level.

IT can’t do it alone.

The first step is to have an incident response plan.

A great resource for data security and privacy compliance is the International Association of Privacy Professionals (IAPP) website: https://iapp.org/ .

The IAPP also have a incident response toolkit put together by our attorney friends at Hogan Lovells. Check it out here.

GDPR By Any Other Name: The UK’s New Data Protection Bill

GDPR By Any Other Name: The UK’s New Data Protection Bill

Last month, the UK published the final version of a law to replace its current data security and privacy rules. For those who haven’t been following the Brexit drama now playing in London, the Data Protection Bill or DPB will allow UK businesses to continue to do business with the EU after its “divorce” from the EU.

The UK will have data rules that are effectively the same as the EU General Data Protection Regulation (GDPR), but it will be cleverly disguised as the DPB.  Jilted lovers, separations, false identities … sounds like a real-life Shakespearean comedy (or Mrs. Doubtfire).

For businesses that have to accommodate the changes, it’s anything but.

In the Short Term

As it currently stands, the UK is under the EU’s Data Protection Directive (DPD) through its 1998 Data Protection Act or DPA, which in EU-speak “transposes” or copies the DPD into a national law. Come May 2018, the UK will fall under the GDPR, which has as a goal to harmonize  all the separate national data security laws, like the UK’s DPA, into a single set of rules, and to put in a place a more consistent enforcement structure.

Between May 2018 and whenever the UK government officially enacts the DPB, the GDPR will also be the data security and privacy law for the UK. The DPB is expected to become law before Brexit, which is schedule to occur on March 2019.

Since the GDPR will soon be the data security and privacy law in the UK, replacing the DPA, organizations have been gearing up to meet the new rules – especially, the right to erasure, 72-hour breach notification to authorities, and improved record keeping of processing activities. The DPB should, in theory, provide a relatively easy transition for UK businesses.

A Few Differences

As many commenters have pointed out (and to which I can personally attest), the DPB is not a simple piece of legislation — though you’d think it would be otherwise. The Bill starts with the premises that the GDPR rules apply to the UK, so it doesn’t even copy the actual text.

So what takes up the rest of this 200-page bill?

A good part is devoted to exemptions, restrictions, clarifications that are allowed by the GDPR and which the UK DPB takes full advantage of in the fine print

The core of the bill is found in Part 2, wherein these various tweaks — for personal data related to health, scientific research, criminal investigations, employee safety, and public interest — are laid out. The actual details — lawyers take note — is buried at the end of the DPB in a long section of “schedules”.

For example, GDPR articles related to the right to erasure, data rectification, and objection to processing don’t apply to investigations into, say, financial mismanagement or public servants misusing their office. In effect, the targets of an investigation lose control of their data.

The DPB is also complex because it contains a complete parallel set of GDPR-like security and privacy rules for law enforcement and national security services. The DPB actually transposes another EU directive, known as the EU Data Protection Law Enforcement Directive. There is also a long list of exceptions packed into even more schedules and tables at the end of document.

While the goal of Brexit may have been to get out from under EU regulations, the Data Protection Bill essentially keeps the rules in place, and gives us a lot of abbreviations to keep track of.

Business Beware: ICO’s New Audit Powers

However, it doesn’t mean there aren’t any surprises in the new UK law.

The DPB grants regulators at the UK’s Information Commission’s Office (ICO) new investigative powers through “assessment notices”. These notices allows the ICO staff to enter the organization, examine documents and equipment, and observe processing of personal data. Effectively, UK regulators will have the ability to audit an organization’s data security compliance.

Under the existing DPA, the ICO can order these non-voluntary assessments only against government agencies, such as the NHS. The DBP expands mandatory data security auditing to the private sector.

If the ICO decides the organization is not meeting DPD compliance, these audits can lead to enforcement notices that point out the security shortcomings along with a schedule of when they should be corrected.

The actual teeth in the ICO’s enforcement is their power to issue fines of up 4% of an organization’s worldwide revenue. It’s the same level of monetary penalties as in the original GDPR.

In short: the DPB is the GDPR, and smells as sweet.

For UK companies (and UK-based multinationals) that already have security controls and procedures in place — based on recognized standards like ISO 27001 — the DPB’s rules should not be a difficult threshold to meet.

However, for companies that have neglected basic data governance practices, particularly for the enormous amounts of data that are found in corporate file systems, the DPD will come as a bit of a shock.

CSOs, CIOs, and CPOs in these organizations will have to ask this question: do we want to conduct our own assessments and improve data security or let the ICO do it for us?

I think the answer is pretty obvious!

The Right to Be Forgotten and AI

The Right to Be Forgotten and AI

One (of the many) confusing aspects of the EU General Data Protection Regulation (GDPR) is its “right to be forgotten”. It’s related to the right to erasure but takes in far more ground. The right to have your personal deleted means that data held by the data controller must be removed on request by the consumer. The right to be forgotten refers more specifically to personal data the controller has made public on the Intertoobz.

Simple, right?

It ain’t ever that easy.

I came across a paper on this subject that takes a deeper look at the legal and technical issues around erasure and “forgetting”. We learn from the authors that deleting means something different when it comes to big data and artificial intelligence versus data held in a file system.

This paper contains great background on the recent history of the right to be forgotten, which is well worth your time.

Brief Summary of a Summary

Way back in 2010, a Mr. Costeja González brought a complaint against Google and a Spanish newspaper to Spain’s national Data Protection Authority (DPA). He noticed that when he entered his name into Google, the search results displayed a link to a newspaper article about a property sale made by Mr. González to resolve his personal debts.

The Spanish DPA dismissed the complaint against the newspaper —they had legal obligation to publish the property sale. However, the DPA allowed the one against Google to stand.

Google’s argument was that since it didn’t have a true presence in Spain – no physical servers in Spain held the data – and the data was processed outside the EU, it wasn’t under the EU Data Protection Directive (DPD).

Ultimately, the EU’s highest judicial body, the Court of Justice, in their right to be forgotten ruling in 2014 said that: search engine companies are controllers; the DPD applies to companies that market their services in the EU  (regardless of physical presence); and consumers have a right to request search engine companies to remove links that reference their personal information.

With the GDPR becoming EU law in May 2018 and replacing the DPD, the right to be forgotten is now enshrined in article 17 and the extraterritorial scope of the decision can be found in Article 3.

However, what’s interesting about this case is that the original information about Mr. Gonzalez was never deleted — it still can be found if you search the online version of the newspaper.

So the “forgetting” part means, in practical terms, that a key or link to the personal information has been erased, but not the data itself.

Hold this thought.

Artificial Intelligence Is Like a Mini-Google

The second half of this paper starts with a very good computer science 101 look at what happens when data is deleted in software. For non-technical people, this part will be eye opening.

Technical types know that when you’re done with a data object in an app and after the memory is erased or “freed”, the data does not in fact magically disappear. Instead, the memory chunk is put on a “linked list” that will eventually be processed and then made part of available software memory to be re-used again.

When you delete data, it’s actually put on a “take out the garbage” list.

This procedure is known as garbage collection, and it allows performance-sensitive software to delay the CPU-intensive data disposal to a later point when the app is not as busy.

Machine learning uses large data sets to train the software and derive decision making rules. The software is continually allocating and deleting data, often personal data, which at any given moment might be on a garbage collection queue waiting to be disposed.

What does it mean then to implement right to be forgotten in an AI or big data app?

The authors of the paper make the point that eliminating a single data point is not likely to affect the AI software’s rules. Fair enough. But certainly if tens or hundreds of thousands use their right to erase under the GPDR, then you’d expect some of these rules to shift.

They also note that data can be disguised through certain anonymity techniques or pseudonymization as a way to avoid storing identifiable data, thereby getting around the right to be forgotten. Some of these anonymity techniques  involve adding “noise” which may affect the accuracy of the rules.

This leads to an approach to implementing right to be forgotten for AI that we alluded to above: perhaps one way to forget is to make it impossible to access the original data!

A garbage collection process does this by putting the memory in a separate queue that makes it unavailable to the rest of the software—the software’s “handle” to the memory no longer grants access.  Google does the same thing by removing the website URL from its internal index.

In both cases, the data is still there but effectively unavailable.

The Memory Key

The underlying idea behind AI forgetting is that you remove or delete the key that allows access to the data.

This paper ends by suggesting that we’ll need to explore more practical (and economic) ways to handle right to be forgotten for big data apps.

Losing the key is one idea. There are additional methods that can be used: for example, to break up the personal data into smaller sets (or silo them) so that it is impossible or extremely difficult to re-identify each separate set.

Sure removing personal data from a file system is not necessarily easy, but it’s certainly solvable with the right products!

Agreed: AI forgetting involves additional complexity and solutions to the problem will differ from file deletion. It’s possible we’ll see some new erasure-like technologies in the AI area as well.

In the meantime, we’ll likely receive more guidance from EU regulators on what it means to forget for big data applications. We’ll keep you posted!

New York State Cyber Regulations Get Real

New York State Cyber Regulations Get Real

We wrote about NY’s innovate cyber regulations earlier this year. For those who don’t remember, NY State Department of Financial Services (NYSDFS) launched GDPR-like cyber security regulations for its massive financial industry, including requirements for 72-hour breach reporting, limited data retention, and designation of a chief information security officer.

As legal experts have noted, New York leads the rest of the states in its tough data security rules for banks, insurance, and investment companies. And after Equifax, it has proposed extending these rules to credit reporting agencies that operate in the state.

Transition Period Has Ended

The NYS rules are very process-oriented and similar to the GDPR in requiring documented security policies, response planning, and assessments – basically you have to be able to “show your work”.

However, there also specific technical requirements, unlike the GDPR, that have to be complied with as well: for example, pen testing, multi-factor authentication, and limiting access privileges.

Anyway, the cyber regulations went into effect on March 1, 2017, but most of the rules have a 180-day grace period. That period ended in late August.

There are exceptions.

They extended up to one year – March 1, 2018 — some of the more technical requirements: for example, performing pen testing and vulnerability assessments and conducting periodic risk assessments. And up to 18-months for implementing audit trails and application-level security.

So NY financial companies have a little extra time for the nittier rules.

However, that does mean that the 72-hour breach reporting rule is in effect!

Varonis Can Help

I’d like to add that the NYSDFS rules on breach reporting cover a far broader type of cyber event than any other state. Typically, state breach rules have language that requires notification for the exposure of certain types of PII data — see our totally awesome graphics to instantly visualize this.

While these NY rules protect similar types of PII as other states – social security and credit card numbers as well as online identifiers – financial companies in New York will also have to report on cyber events, as defined as follows:

Cybersecurity Event means any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an Information System or information stored on such Information System.

Note the language for any attempt to gain access or to disrupt or misuse system. This encompasses not only standard data exposures where personal data is stolen, but also denial-of-service (DoS), ransomware, and any kind of post-exploitation where the system tools are leveraged and misused.

Based on my reading and looking closely at the state’s FAQ, financial companies will have to notify NY regulators within 72-hours of data exposures involving PII and cybersecurity events “that have a reasonable likelihood  of materially harming” normal operations – see Section 500.17.

With data attacks now becoming the new normal, this tough notification rule — first in the US! — will likely require IT departments to put in significant technical effort to meet this tight timeline.

Varonis can help NY financial companies.

Ask to see a demo of our DatAlert product and get right with NYSDFS!

 

Finding EU Personal Data With Regular Expressions (Regexes)

Finding EU Personal Data With Regular Expressions (Regexes)

If there is one very important but under-appreciated point to make about complying with tough data security regulations such as the General Data Protection Regulation (GDPR), it’s the importance of finding and classifying the personally identifiable information, or personal data as it’s referred to in the EU. Discovering where personal data is located in file systems and the permissions used to protect it should be the first step in any action plan.

You don’t have to necessarily take our word for it, you can look at GDPR to-do lists from law firms and consulting groups that are heavily involved with advising companies on compliance.

We’ve already given you a heads up about Varonis GDPR Patterns, which helps you spot this personal data, and now that I’ve chatted and learned more from Sarah and the Varonis product development team, I’ve more to share.

Nobody Does It Better

GDPR Patterns is, of course, built on our Data Classification Framework or DCF. For those new to Varonis, DCF has an enormous advantage over other classification solutions, since it implements true incremental scanning. After the initial scan of the file system, DCF can quickly identify any changes, and then selectively scan those directories or folders that have been accessed. This makes far more sense than starting scanning from scratch!

By the way, for those crazy enough to think they can try rolling their own data scanning software, they can refer to my series of posts on a DIY classification system based on PowerShell. Please learn from my craziness and avoid the urge.

With DCF doing the heavy lifting, GDPR Patterns can focus on spotting EU-style personal data within files. According to the GDPR definition, personal data is effectively anything related to an individual that can identify that person. The definition’s very broad and deceptively vague language covers a lot of territory! (For more excruciating details, please refer to this official EU document.)

Obviously, we’re talking about all the usual suspects: names, addresses, phone numbers, credit card, bank and other account numbers. GDPR personal data also encompasses internet-era identifiers such as IP and email addresses, and futuristic biometric identifiers (DNA, retinal scans) as well.

Many EU Identifiers

The EU comprises 28 countries, and that means many identifiers vary by country. This is where the Varonis product team did the hard work of research, spending months analyzing phone numbers, license plate numbers, VAT codes, passports, driver’s licenses, and national identification numbers across the EU.

Does anybody know what the Hungarian personal identification code, known as Születési szám, looks like?

That would be an 11-digit sequence based on date of birth, gender, a unique number to separate those born on the same date, and a checksum.

Or what about a Slovakian passport number?

That’s 9-characters: 2-digits followed by 7-letters.

Varonis has worked all this out!

We use regular expressions or regexes to do pattern matching when possible. It’s not as easy to craft these regexes as you might think.

If you want to match wits against the people who devised the Dutch license plate numbering scheme, you can click here to see a regex analysis of one sample number. And then you can try a few out on your own to see if you’ve got it. Enjoy!

A regular expression representing Dutch license plates. Think you understand it? Try your luck with the link above!

Patterns Are More Than Regexes

The research and effort we put into the regular expressions only forms part of the GDPR Patterns solution. Sure, it’s conceivable that someone could work out regexes for a few countries or do Google searches to find these expressions on the web.

However, we’ve crafted our regexes by looking at real-world data samples, and not automatically accepting what’s provided by government agencies and others. Our GDPR regexes have proven themselves in the field!

With so many different alphanumeric patterns, it shouldn’t be surprising there’d be occasional “collisions” — sequences that could be classified into several types of  personal data. For example, EU passport numbers vary between 8 and 10 consecutive numbers, so they’d also be caught by an EU phone number regex.

That is why we’ve also added validator algorithms to supplement the regexes. Specifically, GDPR Patterns scans for special keywords that are near or in proximity to the EU personal data: if we find the keyword, it helps zero in on the right GDPR pattern.

For example, when GDPR Patterns finds an 11-digit number, it looks for additional keywords to determine if this represents a national personal ID:  “IK” or “ISIKUKOOD” implies Esontia; “Születési szám” or “Személyi szám” or “Személyi azonosító” would of course mean Hungary, etc.

If we don’t find the extra keywords, then we can’t assume the 11 digits are an identification code, and so it would not be classified as GDPR personal data. In other words, the validation algorithms reduce false positives.

In case you’re asking, we do use negative keywords as well. If GDPR Patterns finds one of these types of keywords, it means that personal data caught by the regex expression can’t be classified under that pattern.

More GDPR Patterns Details

The Varonis developers have dived deep into EU identification numbers, driver’s licenses, license plates, and phone numbers, looking at real-world samples to come up with both positive and negative keywords and proximity information.

We’ve integrated GDPR Patterns into our DatAdvantage reports to show which files contain a specific Pattern based on a hit count.

GDPR Patterns is also integrated with DatAlerts so that notifications can be delivered when files are accessed containing personal data. We’ll help you meet the GPDR 72-hour breach notification requirement.

Data Transport Engine will also use GDPR Patterns to archive or remove stale or no longer useful EU personal data, another requirement in GDPR.

Have questions?  Contact us for more information.