1. New security legislation like the GDPR and NIS Directive impose strict requirements on organizations to implement appropriate technical and organizational security measures to protect personal data. 2. The GDPR in particular requires detailed documentation of security decisions, mandatory breach reporting, and holds both controllers and processors directly responsible for security failures. 3. Proper management of open source software vulnerabilities is important for compliance, as organizations must ensure all components, including third-party libraries, receive security updates to prevent data breaches. Failure to do so has resulted in fines under prior UK data protection law.

1. 1

2. New security legislation and its implications for
OSS management
Daniel Hedley
Partner
Irwin Mitchell LLP

3. Some scene setting
• 79,000 known OSS vulnerabilities, 30,000 reported since 2000
• 96% of applications scanned found open source components with an
average of 147 unique components per application
• 67% of applications scanned had known open source vulnerabilities
• Those vulnerabilities known on average for more than 4 years
• e.g. almost 200,000 devices with the Heartbleed vulnerability still on the Internet
(Shodan 2017)
• OSS vulnerabilities are attractive targets:
• OSS is ubiquitous
• Victim often doesn’t know OSS is there

4. Why this matters - some key new legislation
For everyone:
• General Data Protection Regulation
For some businesses:
• NIS Directive
• Electronic Identification Regulation

5. GDPR – what it is and what it does
• Comprehensive reform of data privacy law
• In force 25 May 2018
• NEW – extra-territorial effect
• NEW – direct obligations for processors
• NEW – much more detailed and prescriptive security
requirements
• NEW – obligation to document security decisions and processes
• NEW – mandatory detailed breach reporting for all

6. GDPR – subject matter scope (art 2)
APPLIES TO:
“the processing of personal data wholly or partly by automated means and to the processing other than by automated
means of personal data which form part of a filing system or are intended to form part of a filing system”
• “processing” = “any operation or set of operations which is performed on personal data or on sets of personal data,
whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or
alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available,
alignment or combination, restriction, erasure or destruction”
• “personal data” = “any information relating to an identified or identifiable natural person (‘data subject’); an
identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier
such as a name, an identification number, location data, an online identifier or to one or more factors specific to the
physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”

7. GDPR – territorial scope (art 3)
Applies if processing takes place in the context of the
activities of an establishment in a member state (regardless
of data location).
ALSO applies if NO establishment in a member state BUT:
• Offering goods or services to data subjects located in member
states (no payment required)
• Monitoring behaviour of data subjects in member states

8. GDPR – application to data processors
• Under current law, data processors (e.g. IT service providers) have no direct
liability to data subjects or regulators.
• Only exposure is contractual, to the controller
• Failure to deal with contractually = controller’s problem
• Under GDPR, processors have direct obligations and direct liability for a
range of obligations, including obligations to secure data, to ensure it has a
compliant contractual obligation to the controller to secure it, & to
cooperate with the regulator.

9. GDPR – security principle (art 1)
• “Personal data shall be processed in a manner that
ensures appropriate security of the personal data,
including protection against unauthorised or unlawful
processing and against accidental loss, destruction or
damage, using appropriate technical or organisational
measures”
• Fleshed out more in art 32 (next slides)
• Burden of proof of compliance on data controller (art 1(2))

10. GDPR – security (art 32)
1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and
purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of
natural persons, the controller and the processor shall implement appropriate technical and organisational
measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems
and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a
physical or technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational
measures for ensuring the security of the processing.
2. In assessing the appropriate level of security account shall be taken in particular of the risks that are
presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised
disclosure of, or access to personal data transmitted, stored or otherwise processed.

11. Unpacking article 32 (1)
• Core obligation to “implement appropriate technical and
organisational measures”
• Requires a risk assessment
• So, must know what the risks are!
• Balance risk against state of the art, cost
• Risks to consider include “accidental or unlawful
destruction, loss, alteration, unauthorised disclosure of, or
access to personal data transmitted, stored or otherwise
processed”

12. Unpacking article 32 (2)
Then a list of things must consider and either
implement or have a reason to reject, incl.
• “the ability to ensure the ongoing confidentiality,
integrity, availability and resilience of processing systems
and services”
• “a process for regularly testing, assessing and evaluating
the effectiveness of technical and organisational
measures for ensuring the security of the processing”

13. GDPR – obligation to document (art 30)
• Controllers and processors must comply with record
keeping obligations.
• INCLUDES record of security measures and decisions taken
under art 32
• Make avail to regulator on request
• Only exception = <250 staff AND only occasional
processing, no likely risk to DSs, no “special categories” of
data

14. GDPR – mandatory breach reporting
• Controller – to regulator UNLESS no real risk to DSs
• 72 hours unless not “feasible” (basically, have a v good reason)
• Processor – to controller
• Without undue delay
• Controller – to data subjects IF high risk to rights and freedoms
• Without undue delay
• Information to be provided to regulator includes
• Nature of the breach (i.e. how it happened, who affected etc)
• Likely consequences of the breach
• Mitigation and remediation measures

15. Network and Information Security Directive (1)
• Much of it devoted to establishment of agencies and a
cross-border infosec cooperation framework
• But ch IV & V also addnl obligations for some businesses:
• “Operators of essential services”
• Energy, transport, banking, financial infrastructure, healthcare, water supply,
digital infrastructure
• “Digital service providers”
• Online marketplace, online search engine, cloud computing platforms
• Transposition deadline May 2018

16. NIS Directive – what does it add to GDPR?
• From a security perspective, covers a lot of the same ground
• Applies based on activities and characteristics of ENTITY, not characteristics
of affected DATA
• If GDPR-compliant, prob. most of the way there BUT devil is in the detail
esp. notification requirements
• Micro and small business exception for digital service providers

17. Network and Information Security Directive (2)
“Operators of essential services”
• Designated by the state
• “appropriate and proportionate technical and organisational measures”
• Mandatory breach notification “without undue delay”
• When breach notification obligation triggered not very clear though

18. Network and Information Security Directive (3)
“Digital Service Providers”
• “appropriate and proportionate technical and organisational measures to manage the risks posed to the
security of network and information systems which they use in the context of offering …” [marketplace,
search engine, cloud services etc]
• “A level of security of network and information systems appropriate to the risk posed” & taking into
account a range of factors including
• “the security of systems and facilities”
• “monitoring, auditing and testing”
• Mandatory notification without undue delay of “any incident having a substantial impact on the
provision of a [digital service] that they offer in the Union”

19. Electronic Identification Regulation
Applies to “trust service providers”
“appropriate technical and organisational measures to manage the risks posed to the security of the trust
services they provide. Having regard to the latest technological developments, those measures shall ensure
that the level of security is commensurate to the degree of risk. In particular, measures shall be taken to
prevent and minimise the impact of security incidents and inform stakeholders of the adverse effects of any
such incidents.”
Mandatory breach notification within 24 hours if “a significant impact on the trust service provided or on the
personal data maintained therein”
• Potentially to several bodies

20. Relevance to OSS management (1)
• Legislation is technology neutral
• Compliance is self-assessed at the time, retrospectively
re-assessed by regulators post breach
• Strong legal obligations to secure
• Unlikely that 3P vendors will take much if any liability for
OSS
• It is for the breached party to show that its security was
“adequate”

21. Relevance to OSS management (2)
• From 2014 guidance published by the ICO, the UK data privacy regulator (emphasis
added):
“It is ... important that any software you use to process personal data is
subject to an appropriate security updates policy ... you must also ensure
that no relevant components are ignored. This is a common risk where
responsibility for updates is split between multiple people, or where third-
party libraries or frameworks are used.”
• The UK ICO at least has fined people specifically for failure to do this.
• & under GDPR, fines get much much bigger …
• Reminder: 67% of applications scanned by Black Duck in 2016 contained unpatched OSS
vulnerabilities.

22. Relevance to OSS management (3)
How does it get into org:
• From vendor, due diligence as to patch and security management
• Contractual? Sometimes. Starting to see in regulated industries e.g.
finance
• Clarity as to who is responsible for what is key
• From own code base, check-in processes and scanning tools
• Other sessions covering this in some detail.

23. Consequences of failure
• Potential for very large fines (up to EUR20mn / 4% of
global turnover under GDPR)
• Reputational damage (e.g. TalkTalk, Yahoo!)
• Damages claims by data subjects
• Regulatory intervention
• Possibility under GDPR of class actions led by charities and
campaign groups

24. Conclusions and takeaways
• The law has caught up with infosec risks
• Compliance is self-assessed at the time, but its adequacy is
retrospectively considered by the authorities post breach – so you
need to have a good story to tell
• OSS is not a special case and is not a get-out clause
• Failure to manage OSS vulnerabilities is unlikely to be accepted as
an excuse by regulators
• Financial and other consequences can be very serious

25. Questions?
Daniel Hedley
Irwin Mitchell LLP
+44 (0) 1293 742 717
daniel.hedley@irwinmitchell.com

26. tt
http://blkduk.io/2vniKhH
Or Click Here: http://blkduk.io/2vnikhH