Like it or not, the GDPR is now just weeks away from kicking in
Darron Gibbard, Chief Technical Security Officer at Qualys recently spoke to us about the biggest challenges it presents to businesses.
Are there any recommended frameworks for implementing controls and processes for information security that I could follow to ensure GDPR readiness?
There are plenty of different general security best practice frameworks that can help you comply with GDPR. There are also some specific recommendations and each member country is starting to post those requirements.
The most advanced one is the Information Commissioner’s Office in the UK. The ICO has provided a lot more depth about what you should put in place, but even their recommendations are still vague. This isn’t like the regulation for processing card payments put together by the PCI – there you had to implement a change detection solution to monitor critical changes to configuration files, and you had to monitor log files on a regular basis. GDPR doesn’t have prescriptive controls like that.
Instead, GDPR states that you have to implement controls that are appropriate for the level of risk you face. You need to protect data against breaches of confidentiality, integrity and availability. Basically, GDPR says: “Do a good job at security.”
I like the SANS Top 20 Security Controls best, as it covers general best practices for good security hygiene for any organisation, and it covers all of the critical areas of IT security.
How do I ensure my partners are held accountable for their end of GDPR?
You must build security requirements, metrics, SLAs, and other terms into your contracts. Secondly, these need to be measurable and enforceable over time, and you have to check them.
This sounds like a lot of work, but you can automate assessment of these controls and gather evidence that they are being followed.
Should I segregate my data to reduce exposure to varying requirements across the EU?
Data crossing borders significantly complicates compliance. The compliance implementations will potentially be different and even conflict with each other. In many cases, organisations find it easier to segregate the data or even maintain data physically within a specific regional boundary.
You should assess the risk of data exposure, classify what data is held on different countries in each application and then determine if data segregation would be worth the effort compared to the risk and the cost.
Where is the best place to track cross-functional infosec requirements and controls?
Automating assessment of controls is key to ensuring controls are appropriate and properly enforced. This can help you measure compliance against multiple regulations and reduce the effort required – collect the data once and then view that data from the point of view of multiple regulations or auditing frameworks.
How does GDPR applies to US-based organisations, and how can they avoid falling under the requirements of GDPR?
At a basic level, if you’re marketing services to EU citizens, even if you’re based in the U.S., you’re going to be under GDPR requirements. If your primary business is U.S. based for U.S. customers, and you have an occasional EU citizen using your services while traveling, it’s less likely you’ll have any significant problems with that.
If you collect information on EU citizens, GDPR applies to you – regardless of where you are based. Enforcement may be a challenge if you have little EU exposure, but you should discuss with proper legal counsel if you are concerned.
To avoid falling under the requirements of GDPR, you should avoid collecting any data from or about any EU citizen. There are some vague areas here. For example, if the EU citizen is traveling in the U.S. and you collect information about them, that may be subject to GDPR. However, if you have general statements of what you’re collecting data for and depending on the scope of the information they provide you, there may be limits to the impact.
Does GDPR cover business contact information (name, business title, address, phone number) that has been available publicly and for a long time? I’ve heard that this basic business contact info is not part of the regulation.
Identifying information for individuals is definitely in scope, but I think we’re going to need more clarification from regulators on the extent that a name alone, or contact information shared as part of business interaction, is in scope or not.
Given the low sensitivity of the information and that it’s generally available, it likely carries lower risk. However, there are no current exclusions for this information.
Do you have to ask your end-customers for additional approval for various ways of collecting and using personal data (marketing, SMS/email/push notifications)?
Absolutely, for consumer-facing businesses. You have to get consent, specify how you will use the data, and then only process data for reasons included in the consent. It’ll be interesting to see how this affects advertising and other services that mine large volumes of data about consumer purchases, searches, and related information.
Is GDPR mainly focused on customers, or on employees as well? If employees are within its scope, what type of information would be governed by GDPR (i.e., proxy logs, email, etc.)?
It is focused on protecting individuals’ data, which includes employees. Certainly, employee health, pay, identifying data, and other sensitive data are in scope. Most likely, acceptable-use policies related to use of technology would require that the devices are used for only business purposes, and your terms of employment should define how you use that data and what is and is not in scope for access and right-to-
be-forgotten requests. Your legal and compliance teams should really look into your existing employment terms and contracts, and verify that appropriate consent is gathered from employees.
What are your thoughts on differences in “breach definition” under GDPR?
There is no difference in the definition of a breach. GDPR defines a “personal data breach” in Article 4(12) as: “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.”
What should be clear is that a breach is a type of security incident. However, there is a difference in the breach notification rules. So if you suffer a breach, the U.K. requires 72 hour notification and The Netherlands requires immediate notification. Those are the two extremes. Each EU member state has defined their own notification rules from immediate to 72 hours, which greatly complicates matters for your network and security operations teams.
Incident management processes need to account for each of the member states’ requirements and ensure that the legal or compliance teams deal with the actual breach notification.
Is there a good way to erase all data to respond to a right to be forgotten request? That person could be anywhere in any data sets.
That is why GDPR is such a challenge. Applications need to be rebuilt with security and process features to track how data is being used, when it is collected, relate it back to consent collection data, and make it easy to find for inquiries or right-to-be-forgotten requests. Most applications will need to be redesigned to accommodate this, and process controls preventing exporting and off-purpose processing will need to be put in place.
How can you manage interaction with European customers when you sell internationally and don’t specifically target them? When do you have to start thinking about GDPR in this process?
There is no issue with browsing to a site, but as soon as you start collecting the personal data you come into scope of GDPR. So placing a tracking cookie on the end-user’s browser is technically collecting personal data.
Geo-fencing your website – so potential customers from IP addresses in the EU – can help. Equally, directing those customers automatically to a local site that is set up to comply with GDPR can help as part of the overall process.
So if we aren’t marketing to EU citizens but they find our website on the internet, we have to prevent them from signing up or donating?
No, but you may want a general acceptable use policy.
What is the best approach for tackling friction between vendors, software developers and risk assessors with regards to false positives?
False positives are not directly related to GDPR, but you should have general requirements for technical and procedural controls with your vendors along with SLAs, as mentioned above. For vulnerability requirements, an approach similar to
that of PCI is a good methodology, where certain vulnerability classes have higher requirements for remediation than others.
I’ve read conflicting information about whether or not an IP address is considered personal data. Given that counter-intrusion software often uses IP address to mitigate attacks, how does the GDPR affect those security systems?
It can be considered identifying information, but alone it is less sensitive. An IP address can be personal data in some circumstances, such as when it’s linked to a login for a unique personal account. But the IP address of a corporate website or server, router or infrastructure on its own would not be personal data.
