Presentation by Kalle Varisvirta at Exove and Bird & Bird's joint seminar on GDPR sanctions

1. Data security
in the age of
GDPR:
Most common data
security problems
Kalle Varisvirta
CTO
Exove

2. ● Data security problems that
have resulted in fines (or are
threatened to)
● Why it happens?
● How to avoid?
● How to detect?
● How to fix?
● How to audit
● How can we help
In this
presentation

3. Accidental disclosure of data

5. What is it?
● URLs accessible without any authentication
● Typically binary files, such as PDFs, that are stored on a
authentication protected system, but accessible without
any authentication
● API endpoints that are left open without authentication
● Cloud storage with no access control configured

6. Why?
● For binary files:
● Web-facing servers have traditionally two ways of serving data out, via
server-side programming or just serving ready-made files out, such as
images on a web page
● When serving files out, there’s no “intelligent software” in between the
client and the file
● APIs:
● APIs usually have some sort of authentication, but a lot of developers
might trust that the URL isn’t guessed and leave it open for simplicity
● APIs that don’t “write” are usually considered “secure anyway” by
developers
● Internal search engines are open by default

7. How to avoid?
● When serving out e.g. PDF files with personal data, make sure
they are served out through a software other than just the
web server software
● When building an API, require all API consumers have their
personal credentials for using the API, even when just reading
information from the API
● When using a cloud storage platform, make sure to configure
the access settings to limit access to the files

8. How to detect?
● Go to a binary file, copy the URL from the browser to another
browser in private mode and see if you can access it
● For APIs, you should just point your browser to the API,
manipulate the URL on the browser address line and see if
you can access personal data

9. How to fix?
● Pass all security needed binary files through software; it’s
fairly simple to do, basically you just check the existing
session, set proper headers and pass the file through
● For APIs, you should always have some authentication for
your API, even if it’s just for reading
● Add a simple shared secret / API key for every consumer,
or go a more sophisticated route and use proper
authentication

10. Lacking internal access control

12. What is it?
● An internal user can access too much information in a system
due to no internal access control or lacking internal access
control

14. Why?
● It’s very typical to focus most resources to actual functionality
of a system, with some focus on external security, too
● Internal security is a topic considered low priority in most
system projects
● By default, even the systems with a highly sophisticated
internal access control settings allow administrator users to
access all information
● Some systems require you to allow access to too much
information, due to the access control setting being too
coarse

15. How to avoid?
● Always start with taking internal security seriously in a system
project
● Always take internal access control settings into use at the
initial adoption of a system
● Always increase rights as they are needed, starting from the
most limited set of rights you can find will get the job done
● It’s a pain, but it might save a lot in GDPR fines

16. How to detect?
● Try to access information you shouldn’t be able to access
● Ask others to access information they shouldn’t be able to
access

17. How to fix?
● If there’s no internal access control in a system, in most cases
one can be built
● If you haven’t taken proper access level into use, do it
● If you haven’t limited the access properly, limit it now
● For giving out access rights, you should have a documented
process that gets followed every time

18. Targeted attacks

20. What is it?
● A targeted attack to steal personal information from a system
● Typically targeting credit card information
● CC information isn’t safe on the form they are filled into, even
when they are only stored on a external PCI DSS certified
card-on-file service provider
● If it’s written into a box, everything surrounding that box
have to be hardened
● CC information should never be stored to a system not
specifically designed (and certified) to do that

21. Why?
● Some systems are just too darn good to be true;
● Travel websites handle huge amounts of credit card data
● Online commerce also has variety of ways to handle
payment information
● A targeted attack is done by professional criminals
● They may try to find ways to get in for months or years

22. How to avoid?
● Avoiding targeted attacks is very hard
● Typical routes to attack are people and their personal
computers of mobile equipment
● Limited access to data and production environments should
be considered in a high risk environment
● Automated checks can also be employed to protect against
malicious files
● Only allow version controlled files to be ran
● Only allow files to version control via a peer review
process

23. How to detect?
● Targeted attacks are made to be hard to detect
● You can use DLP (data leak protection) technology, that will
try to detect credit card information being sent out, but they
have their own problems (encryption, MITM)
● You can check for all changes on a digital service, and just
verify that all files changed were changed purposefully
● You can keep your eyes open for data being sold on Tor
network or some other darknet

24. How to fix?
● If you have been attacked, implement the best practices to handle an
attack
● Incident response is a four step process
● Communication
● Seizure
● Analysis
● Reporting
● Recovery for business continuity
● Root cause analysis and changes to policies and processes
● You might want to get help to deal with a targeted attack

25. How to audit

26. Auditing for GDPR compliant data protection
● Audits for GDPR compliant personal data security and regular
security audits overlap partially, but one doesn’t cover the
other
● Regular security audits are focused on system security and
are based on security principles such as OWASP top 10
● Data security audit can be significantly lighter and more
focused on personal data protection

27. Auditing for GDPR compliant data protection
● Security architecture
● Code inspection for risk structures
● Internal access control
● Maintenance and development practices
● Isolation

28. How can we help?

29. Security audit focusing on
data protection related risks
for your most vulnerable
internet-facing systems
The aim is to find problems
that, if found by the general
public or attackers, may result
in sanctions
Data
security
audit
for an internet
facing service

30. ● Security architecture review
● Accidental data leak
inspection
● Automated audit
● Expert review
● Internal access control /
isolation inspection
● Security of maintenance
and deployment practices
review
Data
security
audit
for an internet
facing service
What’s included?

31. ● Complements data protection
audit done by Bird & Bird by
discovering the unknown
● What’s happening under
the hood?
● Is the architecture
secure?
● Are there vulnerabilities
that may cause a data
leak?
● Are the maintenance
practices secure?
Benefits

32. Thanks!