Data security in the age of GDPR – most common data security problems
0 likes462 views
This document discusses common data security problems that can result in fines under the GDPR and how to address them, including: 1) Accidental disclosure of data, such as unauthenticated access to files or APIs, can be avoided by requiring authentication for all data access and properly configuring access settings. 2) Lacking internal access controls allows users to access too much information; these issues can be fixed by implementing and enforcing internal access controls. 3) Targeted attacks by professional criminals are difficult to prevent, but risks can be reduced by limiting data and system access, employing automated checks, and only allowing verified file changes.
More Related Content
What's hot (20)
Similar to Data security in the age of GDPR – most common data security problems (20)
More from Exove (20)
Recently uploaded (20)
Data security in the age of GDPR – most common data security problems
- 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!