|
Size: 320
Comment:
|
Size: 11228
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| * https://www.i-scoop.eu/gdpr-encryption/ == Data Subject Rights == === Breach Notification === === Right to Access === right for data subjects to obtain from the data controller confirmation as to whether or not personal data concerning them is being processed, where and for what purpose. the controller shall provide a copy of the personal data, free of charge, in an electronic format. === Right to be Forgotten === Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data === Data Portability === GDPR introduces data portability - the right for a data subject to receive the personal data concerning them, which they have previously provided in a 'commonly use and machine readable format' and have the right to transmit that data to another controller. === Privacy by Design === Privacy by design as a concept has existed for years now, but it is only just becoming part of a legal requirement with the GDPR. At its core, privacy by design calls for the inclusion of data protection from the onset of the designing of systems, rather than an addition. |
|
| Line 11: | Line 26: |
| * https://www.i-scoop.eu/gdpr-encryption/ | == Notes == {{{ https://www.pandasecurity.com/mediacenter/security/whois-protocol-gdpr/ WHOIS is a protocol that enables you to find the names and contact details of the owners of a domain Yet this system will become illegal under the GDPR, as it does not ask for the express consent of these people before sharing their personally identifiable data. A head-on collision between GDPR and WHOIS The GDPR prohibits companies from publishing information that identifies individuals, which means that the agreements between domain registrars and ICANN regarding WHOIS will be illegal. This means that the current public WHOIS system is incompatible with the data privacy principles of the GDPR. Nevertheless, there is a risk that an increasing amount of personal data will be deleted from the public WHOIS database, as it is easier for companies simply to eliminate sensitive data than to invest time in properly implementing the measures required by the GDPR. https://www.gdpreu.org/the-regulation/key-concepts/personal-data/ For example, you may be an identified person to data controllers like your school, your employer, or your landlord if your identity has been established via your driver’s license, work authorization, criminal background check, credit score pull, etc. Any information these data controllers have on you, such as your date of birth, address, phone number, salary, and rent would therefore all constitute protected personal data under the GDPR. If John pays with a credit card, his card info makes him directly identifiable to the merchant, which means data on his coffee purchasing history (e.g., store location, date & time, amount paid, coffee preference) is personal data, thus entitling him to certain rights and protections. If John pays with cash, he may still be indirectly identifiable if he redeems a targeted coupon that was emailed to his inbox at coffeeaddict@example.com, which can be traced back to his name through John’s blog on different coffee blends. Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. http://techgenix.com/personal-information-under-gdpr/ To comply with GDPR, organizations must follow certain steps to ensure that the personal information that they process, collect, and store is properly protected. All personal information must be securely processed and managed. Remember…collect and process only what you need for business function (and have acquired explicit permission for). If you don’t need it, don’t collect it! GDPR also references “sensitive personal data,” which requires extra special care that incorporates enhanced requirements for protection and processing. This is usually attributed to health-related data, among others. Can personal data become non-personal data if it is pseudonymized or encrypted? Online identifiers and location data are all personal and must be protected as such. So, the answer to the question “can personal data that is encrypted become non-personal data?” is — no, it can’t. Encryption does not convert personal data to non-personal data. However, it does remove the ability for the data to identify a person. As the data can longer be used to identify a person, the organization that used the technical measure to pseudonymize the data is offered some regulation leniency, particularly with regards to data breach notification requirements. Through employing technologies that encrypt the data or render it pseudonymized, organizations are able to manage compliance responsibilities and better manage their risk. Linked personal data examples (directly linked to a person) Full name Date of birth Residential Address Telephone number Email Address Passport number Identification number Drivers Licence number Social security number Banking/card numbers Linkable personal types (combine to identify a person) First name only Last name only A portion of the address (country, street, postcode etc.) Age Category not specific (20-30 years or 40-60 years etc.) Place of work Position at work IP address Device ID Sensitive (special personal data types) Biometric data Racial data Health data Ethnic origin Political opinions Religious or philosophical belief Trade union details Genetic data Sexual preference If unsure, perhaps it’s best to just encrypt it is all! http://techgenix.com/6-gdpr-privacy-principles/ By informing the data subject of what, how (in an easy to understand and accessible means), and why their data will be processed ensures that you are transparent with regards to the processing of their data. Personal data can only be collected for specified, explicit, and legitimate purposes. Only collect the personal data that is necessary for the purpose of the business function. Personal data must be kept accurate and current. Do not retain the data if you no longer require it for the purposes defined and agreed for processing. Securely remove the data when it is no longer necessary. Do not store personal data that you no longer use! Review, review, review! Integrity, confidentiality, and availability are fundamental to security! The confidentiality and integrity of the personal data must always be maintained. Access must also be controlled to achieve this. How can the data be seen ? Who can see the data ? you must be able to demonstrate this compliance https://www.itgovernance.eu/blog/en/how-to-maintain-gdpr-compliant-databases A significant part of the process will involve managing your databases, as this is probably where you keep most of your personal data. designing your systems with privacy as your primary concern first thing you need to do is map your data with a data flow audit. Locate your data A data map should identify the following key elements: Data items (e.g. names, email addresses, records) Formats (e.g. hard copy forms, online data entry, database) Transfer methods (e.g. post, telephone, internal/external) Locations (e.g. offices, Cloud, third parties) Limit who has access to your data you should set up access controls to make sure personal information can only be viewed by relevant employees. manage who has access to what data, making sure no one can view, modify or delete data that isn’t relevant to their job role. You should also protect your personal data by pseudonymising and/or encrypting it. Encryption also obscures information by replacing identifiers with something else. But whereas pseudonymisation allows anyone with access to the data to view part of the data set, encryption allows only approved users to access the full data set. https://blog.thalesesecurity.com/2018/03/01/securing-containers-for-gdpr-compliance/ GDPR Data Security Requirements The GDPR calls for a layered or “Defense in Depth” security approach to protect sensitive data from compromise. Layers should include not only perimeter security, but also, among others as prescribed by GDPR Article 32: Limiting access to data Encrypting or pseudonymization of sensitive data Monitoring and reporting user access patterns https://www.manageengine.com/key-manager/gdpr-compliance.html Digital keys and certificates are at the heart of PKI. These are digital identities which protect access to critical systems and ensure strong encryption of personal data. digital signature https://www.ctrl.blog/entry/gdpr-web-server-logs Personal data in server logs The default configuration of popular web servers including Apache Web Server and NGINX collect and store at least two of the following three types of logs: Access logs Error logs (including processing-language logs like PHP) Security audit logs (e.g. ModSecurity) If you don’t have a legitimate need to store these logs you should disable logging in your web server Legal basis for collecting and storing logs without consent You can’t collect and store any personal data without having obtained, and being able to document that you obtained, consent from the persons you’re collecting data from. You can, however, collect and store personal data as part of web servers logs for the purposes of detecting and preventing fraud and unauthorized access and maintaining the security of your systems. Data should be deleted (including from backups) when there is no longer a need to retain it. Unless you encrypt your logs, an unauthorized third-party who gained access to your servers could extract a lot of data about your users from your logs. Depending on how much private information is stored in your log files and the potential sensitive nature of your business, you shouldn’t store log files for more than a few hours or days unless you take measures to protect them. Managing PGP keys in GnuPG is beyond the scope of this article. However, in short you would create a key-pair on a secure machine, and then import the public key into the GnuPG key chain on your servers while storing the private key on a secure medium with limited access for authorized employees only (e.g. printed on paper or kept on a removable storage media). The server can then use the public key to encrypt its log files with public key cryptography; resulting in the server being able to encrypt the data without being able to decrypt it without the private. The log files could even be transferred to a centralized log-storage server for cold storage. }}} |
GDPR
General Data Protection Regulation
GDPR, as it applies to all companies processing the personal data of data subjects residing in the Union, regardless of the company’s location.
Data Subject Rights
Breach Notification
=== Right to Access === right for data subjects to obtain from the data controller confirmation as to whether or not personal data concerning them is being processed, where and for what purpose. the controller shall provide a copy of the personal data, free of charge, in an electronic format.
Right to be Forgotten
Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data
Data Portability
GDPR introduces data portability - the right for a data subject to receive the personal data concerning them, which they have previously provided in a 'commonly use and machine readable format' and have the right to transmit that data to another controller.
Privacy by Design
Privacy by design as a concept has existed for years now, but it is only just becoming part of a legal requirement with the GDPR. At its core, privacy by design calls for the inclusion of data protection from the onset of the designing of systems, rather than an addition.
Notes
https://www.pandasecurity.com/mediacenter/security/whois-protocol-gdpr/ WHOIS is a protocol that enables you to find the names and contact details of the owners of a domain Yet this system will become illegal under the GDPR, as it does not ask for the express consent of these people before sharing their personally identifiable data. A head-on collision between GDPR and WHOIS The GDPR prohibits companies from publishing information that identifies individuals, which means that the agreements between domain registrars and ICANN regarding WHOIS will be illegal. This means that the current public WHOIS system is incompatible with the data privacy principles of the GDPR. Nevertheless, there is a risk that an increasing amount of personal data will be deleted from the public WHOIS database, as it is easier for companies simply to eliminate sensitive data than to invest time in properly implementing the measures required by the GDPR. https://www.gdpreu.org/the-regulation/key-concepts/personal-data/ For example, you may be an identified person to data controllers like your school, your employer, or your landlord if your identity has been established via your driver’s license, work authorization, criminal background check, credit score pull, etc. Any information these data controllers have on you, such as your date of birth, address, phone number, salary, and rent would therefore all constitute protected personal data under the GDPR. If John pays with a credit card, his card info makes him directly identifiable to the merchant, which means data on his coffee purchasing history (e.g., store location, date & time, amount paid, coffee preference) is personal data, thus entitling him to certain rights and protections. If John pays with cash, he may still be indirectly identifiable if he redeems a targeted coupon that was emailed to his inbox at coffeeaddict@example.com, which can be traced back to his name through John’s blog on different coffee blends. Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. http://techgenix.com/personal-information-under-gdpr/ To comply with GDPR, organizations must follow certain steps to ensure that the personal information that they process, collect, and store is properly protected. All personal information must be securely processed and managed. Remember…collect and process only what you need for business function (and have acquired explicit permission for). If you don’t need it, don’t collect it! GDPR also references “sensitive personal data,” which requires extra special care that incorporates enhanced requirements for protection and processing. This is usually attributed to health-related data, among others. Can personal data become non-personal data if it is pseudonymized or encrypted? Online identifiers and location data are all personal and must be protected as such. So, the answer to the question “can personal data that is encrypted become non-personal data?” is — no, it can’t. Encryption does not convert personal data to non-personal data. However, it does remove the ability for the data to identify a person. As the data can longer be used to identify a person, the organization that used the technical measure to pseudonymize the data is offered some regulation leniency, particularly with regards to data breach notification requirements. Through employing technologies that encrypt the data or render it pseudonymized, organizations are able to manage compliance responsibilities and better manage their risk. Linked personal data examples (directly linked to a person) Full name Date of birth Residential Address Telephone number Email Address Passport number Identification number Drivers Licence number Social security number Banking/card numbers Linkable personal types (combine to identify a person) First name only Last name only A portion of the address (country, street, postcode etc.) Age Category not specific (20-30 years or 40-60 years etc.) Place of work Position at work IP address Device ID Sensitive (special personal data types) Biometric data Racial data Health data Ethnic origin Political opinions Religious or philosophical belief Trade union details Genetic data Sexual preference If unsure, perhaps it’s best to just encrypt it is all! http://techgenix.com/6-gdpr-privacy-principles/ By informing the data subject of what, how (in an easy to understand and accessible means), and why their data will be processed ensures that you are transparent with regards to the processing of their data. Personal data can only be collected for specified, explicit, and legitimate purposes. Only collect the personal data that is necessary for the purpose of the business function. Personal data must be kept accurate and current. Do not retain the data if you no longer require it for the purposes defined and agreed for processing. Securely remove the data when it is no longer necessary. Do not store personal data that you no longer use! Review, review, review! Integrity, confidentiality, and availability are fundamental to security! The confidentiality and integrity of the personal data must always be maintained. Access must also be controlled to achieve this. How can the data be seen ? Who can see the data ? you must be able to demonstrate this compliance https://www.itgovernance.eu/blog/en/how-to-maintain-gdpr-compliant-databases A significant part of the process will involve managing your databases, as this is probably where you keep most of your personal data. designing your systems with privacy as your primary concern first thing you need to do is map your data with a data flow audit. Locate your data A data map should identify the following key elements: Data items (e.g. names, email addresses, records) Formats (e.g. hard copy forms, online data entry, database) Transfer methods (e.g. post, telephone, internal/external) Locations (e.g. offices, Cloud, third parties) Limit who has access to your data you should set up access controls to make sure personal information can only be viewed by relevant employees. manage who has access to what data, making sure no one can view, modify or delete data that isn’t relevant to their job role. You should also protect your personal data by pseudonymising and/or encrypting it. Encryption also obscures information by replacing identifiers with something else. But whereas pseudonymisation allows anyone with access to the data to view part of the data set, encryption allows only approved users to access the full data set. https://blog.thalesesecurity.com/2018/03/01/securing-containers-for-gdpr-compliance/ GDPR Data Security Requirements The GDPR calls for a layered or “Defense in Depth” security approach to protect sensitive data from compromise. Layers should include not only perimeter security, but also, among others as prescribed by GDPR Article 32: Limiting access to data Encrypting or pseudonymization of sensitive data Monitoring and reporting user access patterns https://www.manageengine.com/key-manager/gdpr-compliance.html Digital keys and certificates are at the heart of PKI. These are digital identities which protect access to critical systems and ensure strong encryption of personal data. digital signature https://www.ctrl.blog/entry/gdpr-web-server-logs Personal data in server logs The default configuration of popular web servers including Apache Web Server and NGINX collect and store at least two of the following three types of logs: Access logs Error logs (including processing-language logs like PHP) Security audit logs (e.g. ModSecurity) If you don’t have a legitimate need to store these logs you should disable logging in your web server Legal basis for collecting and storing logs without consent You can’t collect and store any personal data without having obtained, and being able to document that you obtained, consent from the persons you’re collecting data from. You can, however, collect and store personal data as part of web servers logs for the purposes of detecting and preventing fraud and unauthorized access and maintaining the security of your systems. Data should be deleted (including from backups) when there is no longer a need to retain it. Unless you encrypt your logs, an unauthorized third-party who gained access to your servers could extract a lot of data about your users from your logs. Depending on how much private information is stored in your log files and the potential sensitive nature of your business, you shouldn’t store log files for more than a few hours or days unless you take measures to protect them. Managing PGP keys in GnuPG is beyond the scope of this article. However, in short you would create a key-pair on a secure machine, and then import the public key into the GnuPG key chain on your servers while storing the private key on a secure medium with limited access for authorized employees only (e.g. printed on paper or kept on a removable storage media). The server can then use the public key to encrypt its log files with public key cryptography; resulting in the server being able to encrypt the data without being able to decrypt it without the private. The log files could even be transferred to a centralized log-storage server for cold storage.