We're currently reviewing the affects of the GDPR legislation (Wikepedia Link) that is due to come into force in May 2018 and one of the implications of GDPR is data encryption and how personal data is stored at rest and in transit.
So we were wondering, has the Core team considered the implications of the new legislation and whether or not encryption should now be included in the core (and enabled by default) in order to meet this legislation (and just data security in general?).
I've raised this in the forms forum as it's probably the logical place given this is the most likely functionality to gather personal information, however I guess this could also apply to members and/or users.
Has anyone else looked into this and if so, how far reaching does this go? I've even been wondering if the email addresses used for members should be encrypted as it's not clear to me where the line is drawn.
I'm interested in this too, we've seen other threads about this exact thing, but nothing seems to have materialised from it. We're thinking of implementing a custom membership area + helpers to handle encryption etc...
Hoping someone from the Core team can shed some light on the situation before I start.
I think Umbraco HQ is doing some amazing security stuff with regards to version 7.7 and hopefully we can inspire them to look at this stuff for that version or maybe 7.8.
But most helpful is probably if we come up with the specifications that we need to comply GDPR. First step that it's possible to encrypt the data. In the related forum discussion people have tried to use SQL Server Encryption, but I don't whether that is sufficient to comply fully to GDPR.
Will dive into this in August and hopefully can give more info later in that moment.
Do you currently have any specs that should be built into core?
Currently we're working with our legal advisors to understand how GDPR will affect the things we do. Once we fully comprehend the scope, we'll make sure that everything we do will be compliant with GDPR (including both CMS and Forms).
Any update on the timeline for this? As clients start to ask this question more and more it would be good to be able to say that Umbraco meets the requirements "out of the box" (ie before the custom designs & code)
I don't think there is a specific forum for this, but if they are doing the open space free for all like they did last year, there could be a spae for a an open chat..
I get the feeling most people are looking for a steer. I know I am at the very least:
will umbraco be compliant out of the box before any mods
if not what steps would we need to comply, and doing it in a reasonable timeframe so we can as users and business owners approach businesses to say this needs to happen so they can have the thorny who foots the bill
also does mean that potentially there will be a need for a data officer or owner of data.
Because theoretically anyone who registers as a user is subject to the new GDPR
First and foremost: If your role is to advice your clients in this matter, make sure to do thorough research on what GDPR really is. We've done a lot of research and in the current context of Umbraco, GDPR is 99% internal processes in organisations and 1% tech. Thus very little to do with Umbraco.
There's three central elements to current state of Umbraco and Umbraco Forms:
Opt-in / consent when submitting personal data
Right to be forgotten (delete personal data)
Right to export data
All three scenarios can currently be covered in Umbraco to date (we're looking into an out-of-the-box feature for exporting member data although it's very trivial already).
Further down the line it might make sense* to offer a feature out-of-the-box to encrypt/pseudomise data although in a breach where access to servers is given, it's very likely that this would have limited effect (at least if the data should be available to managers or website in some human readable form (decrypted)).
There's a heavy trend currently to turn GDPR into another Y2K - especially in the digital experience place. While parts of it is relevant, it's really important to cut through the noise and while we've also been close into going into the path of adding "gdpr features" in Umbraco CMS, after a good deal of research and legal talks, we've decided to stick to the norm of Umbraco and try to find simpler approaches.
That said other types of CMSes than Umbraco - especially those which does heavy personalisation, data mining and analytics - might need more gdpr work than Umbraco per se.
Hope this helps!
/n
*might due to data storage could offer this ootb already
If you do research online make sure to use best practices, including research on the writer of what you read.
GDPR is turning into a massive industry for anything from consultants to vendors of various types of software. A lot of these have been doing amazing SEO work and a lot of them are very frequent guest bloggers on various media.
Just delete the form entry (it's enough that people can request to get their data getting deleted). Just like you'd need to delete it from other systems if you've exported the data (hence why GDPR is more about processes than tech).
It's also a data breach if you've exported data and accidentally shared that file with a 3rd party.
Just like encryption have much less with the GDPR than people think (in fact it's only mentioned 3 times in the entire 200+ pages of regulation(!). The reason people are so focused on encryption/pseudonymisation is because you don'thave to inform your customers of a data breach (although, isn't it a good idea?). Yet, you'll still need to inform authorities!
If you have a correct workflow where you sent out an email (via the default workflow or through another package we've created, called PerplexMail (https://our.umbraco.org/projects/backoffice-extensions/perplexmail-for-umbraco/)), and then delete the entry the website is pretty okay because the personal data isn't stored any longer in the site / database.
This package stores login attempts, logouts, lock-outs, etcetera to the backoffice of Umbraco. I think this is a crucial part in having control over the administrative part who has access to personal data. I think there should some extension points in Umbraco where we get the ability to store who has access which form entries, and/or which member profiles in the Umbraco backoffice. By doing that you can get a pretty comprehensive audit trail of who accessed these personal data.
Hope that other people can share their thoughts too in this forum about what is missing in Umbraco currently to be GDPR compliant. Then we can bundle these and make issues on the issue-log and put people to work ;)
+1 this, I too have created an audit trail tab for the membership area for use within websites built where I work. I agree that this would be a very useful addition to Umbraco out of the box.
Sounds interesting Jeffrey, will have to check it out!
I think GDPR leads into a bigger discussion about data security and whilst I agree with you Niels that only a small proportion of GDPR is technical, it is still there. Whilst GDPR strictly speaking doesn't insist on encryption, it does suggest it on several occasions as a path to go down and I think it's a reasonable method of ensuring that you have a technological barrier to keeping personal data secure. It shouldn't be the only one, but that's not to say it shouldn't be there. We should make it as frustrating as possible to any potential hacker to get hold of personal data and encryption is certainly a good way to do that.
Additionally we are getting more and more requests from clients to show how we can encrypt personal data in Umbraco and whilst we might come up with our own ways of doing that, it would be 1000 times more easier if this is something that was built into Umbraco as a standard (even if it was an optional choice so you could have unencrypted data at rest if you really wanted to) and would make Umbraco even more of a no brainer as the CMS of choice for a lot of our potential clients.
I would urge everyone at HQ to consider looking into this as something to incorporate into a future version of Umbraco for Members, Users and Forms as whilst it's fairly straight forward to create custom data types that use encryption, it would be great if Umbraco supported this out of the box.
I completely agree with you on this. We also get asked about encryption and it's certainly a big concern to our clients - the fact there is nothing OOTB is slightly disappointing. Umbraco and Umbraco Forms are such good products and the last thing I want to do is start hacking them up trying to slip in some encryption layer, which will never be as good as if the Umbraco team do it directly.
I'm currently working on blogpost about what we (Umbraco + community) should do to make this GDPR-compliant. Including mock-ups of the needed changes, and stuff like encryption (and why TDE is not the complete answer).
I'm hoping to release it on November 29th (I love deadlines), so we could get in discussion during December 2017 and start implementing it during Januari 2018 and finish that off in Q1 2018. Sounds good :)?
I'll keep this forum updated,
Jeffrey
p.s.: If you're really curious; I'm looking towards making some datatypes implementing encryption like we did in our mail-package (https://our.umbraco.org/projects/backoffice-extensions/perplexmail-for-umbraco/) where the emailadresses and content of the emails are encrypted when stored. The sourcecode is also available if you really want to deepdive into it.
Unfortunately encryption OOTB isn't smooth sailing and come with heavy side-effects too (such as a tradeoff between incredibly ineffective encryption or very slow search (down to non-working search at a certain volume).
At the same time it doesn't do anything in terms of making organisations GDPR compliant (the only thing encryption will give you for GDPR is that you don't have to inform your customers if you have a security breach. You're still subject to fines, though).
We're all ears on specific areas where Umbraco needs to be modified to be GDPR compliant and if anything relevant come up, I'm more than happy to make it a high priority.
wow that's going fast from lets have a discussion to getting something out there.. , just as a sideline.. once you have a blog post maybe release the discussion via a @skrift_io article so people are at the very least aware ..
I have the feeling lot of people are letting other dictate what happen rather than being involved in the process
I think hiding a lot f that information and expiring it are going to be key factors but maybe that's a healthcheck that could be written
I think Niels makes an excellent point that GDPR compliance is largely about business processes. Sometimes it's easier for us all to focus on a technical solution, but that isn't solving the business problem.
When we started looking at GDPR we realised that the weakest link in the chain is not the storage of data in production, it is in controlling all the copies of data as it moves in or out. We can't afford to leave spreadsheets or old backups lying around!
As an agency we found that GDPR has made us change our development processes because we are liable for keeping all copies of end user data safe. Whilst production servers and backups have our best efforts at being secure, if a copy of the live database is used during development or testing ... and that laptop or USB stick gets left on a train - then our contracts leave us liable for the data breach.
Our answer is to never copy live data outside of a production or secure staging environment. I think developing against a copy of live data is a habit everyone will have to stop, as people start to see data as a liability as well as an asset.
For development, the options are either generating test content or anonymising an existing copy. We've gone down the second route. and have created a package to do this easily in Umbraco - https://our.umbraco.org/projects/developer-tools/umunge/
With sufficient interest, we would like to extend uMunge to Umbraco forms data - as a likely store of user-supplied personal information - but this is hard because it is stored in a dynamic JSON format.
Encrypted storage is a good way to tick the box for telling our customers that we are compliant, but my experience is they are also keen to have tight contracts and security policies that ensure as developers we are taking good care of handling their data. We need to solve business problems with business level solutions.
A very important and often overlooked point about protecting development environments! A lot of larger breaches have come from them in the past couple of years. Will look into the package. Interesting approach!
Actually, my comment was in response to the self promotion of the following package: https://our.umbraco.org/projects/developer-tools/umunge/. I thought that the comment would indent under his comment so it would be obvious what I was referring to. Oops.
What I've always loved about Umbraco is that it is well very well developed by the people at Umbraco and at least most of the third-party packages developed are functional and well developed also. In short, it's nothing like the junk plugin farm that Wordpress is. It annoys me to no end when I see "developers" muddying the waters by releasing things that don't function at all, particularly when they are closed source and there is nothing I can do about it & I burn through half a day trying to fix it for a client just to end up with an unhappy client, a refund, and an incomplete project.
When working on Umbraco, I love that I can usually easily quote a client without having that sinking feeling that I've just "given away the farm." So, I suppose I could say that I take exception to pointless packages from developers who mark their own package as compatible and the rating system shows 100% functional in the latest release of Umbraco. It reminds me of a DNN plugin I used a few years ago where the developer released a totally broken closed source plugin & made his money by immediately providing a dll that actually works.
Fair to be frustrated, but we're the Friendly CMS and your first comment wasn't in sync with our values.
The project above clearly states it's in beta and in the spirit of paying it forward you could have left feedback in their forum.
Umbraco is great because of the people. If the people don't behave nicely, Umbraco is no longer the Friendly CMS. No matter your frustration, I'd encourage you to keep a friendly tone or keep your frustrations out of this forum.
We didn't set out to build something that didn't work, or release a package designed to waste anyone's time. We have done our own testing, but it obviously does not cover all the possible ways people can use Umbraco.
Please give us some specific feedback - either direct at [email protected] or on the package forum - as to what didn't work for you so that we can try and recreate any issues and fix them.
I agree with Niels's point that the GDPR is mostly about processes and governance.
Most of the work lies in figuring out which data you actually store, where it is stored and very importantly what the purpose of storing it is.
A good way of doing it can be taking a risk-based approach where you classify your data and protect it accordingly. You need to actively consider which data to keep or even better if you need to store it in the first place.
As developers most of us have been guilty in hoarding data with the purpose of future fun functionality or analytics that only benefit ourselves as vendors. With the regulation's demand of active opt-in and explicit consent for every use and re-use of data this will no longer be allowed.
The thought of Privacy by Design, which is a basis of the GDPR, is new to most developers as are are lot of the techniques required to support it.
For simpler CMS solutions (ie without advanced membership) my best bet is that instead of looking at Umbraco you need to look at what third-party trackers and analytics tools you use. Do you need them? Do you have legal basis to use them? Where do they store data about your customers? Identity all data controllers and data processors.
One place that I do see a need for Umbraco to improve is to provide proper and accessible event and audit logging out of the box for all system events. It is in place in some parts of the system but it needs to be extended (and configurable) to all user and membership events. Ideally standardise the way we write to it from packages etc. This data should be formatted in way that it can be forwarded directly to a log management and analytics tool (or provider). Jeffrey and Co's package is an excellent step in the right direction (H5YR!) but we need this in core.
Wearing the tinfoil hat... Prepare for a breach. They will happen. What will the consequences be for your and your customers. Encryption at rest isn't the solution to everything if you forget basic input sanitisation ...
I look forward to a lot of interesting discussion about this at CG18!
A couple of handy links for those that wish to dig in a bit further:
Interesting discussion. I would agree that Umbraco Forms and Member data pose a challenge for us under GDPR. A large part of GDPR is processes but I wouldn't go so far as saying that the technical end of compliance is tiny by comparison. Technical implementations will be a part of enabling those processes. Aside from the security aspects already mentioned, technical solutions will also factor from an auditing and consent management point of view and efficiently enabling a number of the rights conferred to Data Subjects under the regulation.
In terms of Umbraco Forms, storing the collected data by default I would see as an issue. It is not enough to say that the Data Subject can request that you remove the data that you hold on them. We need to be limiting the data surface as much as possible, and therefore limiting risk. It is likely that many implementations just use Forms to collect data and send that data elsewhere using the workflows for further processing. Allowing developers to choose whether that data is stored after the workflow is complete would go some way towards mitigating risk.
Under GDPR we are also tasked with being more transparent in explaining the reason for the data collection, how the data will be used and what processing may occur. This will mean that pointing people to a catch-all privacy policy may not suffice if you have reason to collect data throughout the application for differing purposes. If Umbraco Forms were to enable us to store the reason for data collection along with the form itself that could make transparency and auditing easier to implement. These reasons can change over time and so capturing a snapshot of the terms the user agreed to at time of submission would be useful.
As an aside I straw polled GDPR awareness in the community a few months back:
It's good to see the awareness/discussion progress!
Thanks for the reply, answers to some of your questions below.
1) I'm self-employed and don't work on large complex sites. The example I have shown is just a demo and work OK for small websites/business. But as stated, 'Improve if necessary' anyone can download the code and enhance it. That's why I put it up :).
2) In the backofficehelper.cs class the EditorModelEventManager.SendingContentModel captures the loading of the page and passes the encrypted data off to be decrypted.
Nice proof of concept. I think features like encryption at rest for the database is something that should be used whenever possible. Azure offers this by default now:
Then the issue in the back-office in terms of security comes down to locking down file media (uploaded via forms) and form entries themselves only to those that should have access.
I think there's a few things that could be done to improve Form's compliance:
Don't automatically store submissions - make it a workflow option, not compulsory.
When submissions are stored, have an option to say how long for eg. 6 months. After this period they are automatically purged.
Have Forms generate some kind of "delete my data" URL (with a unique GUID or hash) that can be used to generate a link that can be given to submitters to remove their data (could be added to emails etc.)
Great article overall and many good points about technical Umbraco specifics.
Perhaps you could have covered user consent and data minimisation a bit more in detail? Both are quite important and will require a change of mindset for many of us.
Important additional questions to your list are "Do we need to collect this data?" and "Do I have legal basis to do so?"
Recommended further reading in that direction could be:
"Privacy Architecture Design Principles" by Jutla and Bodorik which provides a good mnemonic "The 7 Cs" that allows you to put yourself in place of a data subject (user).
The eight "Privacy Design Strategies" by Hoepmann which provides both data and process oriented strategies for Privacy by Design. (His work is the basis of at least a couple of ENISA's reports and guidelines on the topic.)
Once again, thanks for your community efforts on increasing the overall security and compliance maturity of Umbraco over the past few years!
thanks for your kind comment, really appreciate that!
Thanks for point these two points out, but in my article I tried to focus mostly on the technical stuff that should be done (with a package / within Umbraco Core) to get everything in place. The user consent and data minimisation is something a Form Editor / developer should think of, but is not something that could/should be forced within Umbraco.
So that's why I didn't touch upon that topic in my article.
a- A two-tiered sanctions regime will apply. Breaches of some provisions by businesses, which law makers have deemed to be most important for data protection, could lead to fines of up to €20 million or 4% of global annual turnover for the preceding financial year, whichever is the greater, being levied by data watchdogs. For other breaches, the authorities could impose fines on companies of up to €10m or 2% of global annual turnover, whichever is greater.
The relevant provisions on data security are contained under Articles 5 and 32 of the Regulation.
Article 5 sets out basic rules on personal data processing which only apply to data controllers, considered to be fundamental to data protection. One of those rules requires data controllers to ensure that personal data is "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".
According to the Article 83 provisions of the Regulation on administrative fines, where data controllers breach that Article 5 requirement they can be served with the highest possible fine that data protection authorities will be able to issue under the reformed framework.
In contrast if data processors breach their statutory data security obligations, set out under Article 32, which requires them to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk" of their personal data processing, then the most they could be fined is up to €10m or 2% of global annual turnover.
If people understand the necessity from a privacy perspective, they may act as more active collaborators and even ambassadors than if they are just scared of fines. That said, some scaremongering might be needed to get funding. :)
Just to ramp up Ravi's scaremongering, there's also the risk of prison time if you find yourself in serious breach of the Data Protection Act! :-S
Great article Jeffrey and some good points made by Frederik. As you mention in the article, I've leaned towards carrying out encryption and decryption in code and used AES 256 Rijndael enhanced along with SALTing to try prevent Rainbow attacks, however you then hit another problem of where do you keep your encryption keys?
Going back to Forms though, at the moment we're in a position where we're finding that we can't propose it as part of our solution due to the default nature of storing data in the database. Although there is the package Jeffrey has created which deletes the form data, strictly speaking you could have data stored in the SQL Server transaction log, which I'm guessing (and it is a guess) still needs to be taken into account. There's also the risk of something causing an error that prevents the data being deleted. Granted it's a tiny risk, but still one that's there.
If your there Niels, any chance you can let us know if this is something that might be added in at a later date? A checkbox saying "Store data?" will do the trick! ;-)
Nothing like scare mongering.. however to your point..
Good database practices like a trigger to destroy old records and being super careful with what you keep . ie really paring down what you keep .. the other alternative would be to get people to sign up to apple like terms and conditions so you have iron clad legal sign off might be a way to approach
essentially the first and biggest decisions .. need to be what do i actually need to make the site run..
the question about where you keep your encryption keys is totally legit, and I'm currently storing these encryption keys in the web.config. Not the best place, but I have no better option.
In my opinion, there should be an easy "encrypt" and "decrypt"-function in Umbraco Core that you could use without knowing the exact implementation as developer. The Core should implement a strong algorithm (like AES256 RijnDael) and of course you should have the option to alter that.
I'm really wondering if you could shine your HQ light on my Skrift-article. One of the issues is not storing the data at all, and it's great news to see that's coming, but what do you think about:
Creating a datatype in Umbraco Core that stores the data encrypted in the database. This datatype could be used for sensitive data on Member-types, but also for doctypes (although I have no idea why you should do that). That datatype could be assigned to a Umbraco Usergroup, so only Users who are a member of that Usergroup can see the data in the backoffice. Some sort of visual mock-up can be seen on the first tab: http://downloads.perplex.eu/umbraco/gdpr/member.html
Our company deals with a lot of clients who use Umbraco as their desired CMS and since the ever increasing importance of GDPR they have ALL asked for the Forms data to be encrypted. It would be so important to every one of our clients if this was available by next year.
I really don't see the point in encrypting database content that is exposed via the CMS. Clients may be asking for it, but only because they have been panicked into thinking it is required.
What is more likely? Someone gets access to the Umbraco back-end where they can access all the unencrypted data or someone gets access to your database server?
If someone has access to your database server, it's game over anyway. They could just reset the admin password via SQL, gain access to the CMS and then get all your data.
If you have a genuine fear data stored in Umbraco forms is so sensitive it can't be leaked then don't store it in first place. That is the only safe way.
I do not agree. As written in the article; if you have an SQL Injection flaw on your website (still #1 in the OWASP-list), you could preform a SELECT-statement on the data. In the case of unencrypted data you'll have access to all data. If it's encrypted you only have some encrypted data that you cannot unencrypt without getting the key from for example the web.config or via C#.
You probably won't be able to do an UPDATE-statement, so that is not a problem. And if you use Transparant Data Encryption, it won't protect you against the SQL Injection attack.
If, as I believe, Umbraco Forms (which is what we were talking about) uses PetaPoco for database access (which I believe it does) then SQL Injection can never be an issue. Likewise for the rest of Umbraco.
Sure, there are hypothetical risks we can guard against. But the biggest glaring risk is someone gaining access to the CMS - probably via social engineering - and this won't protect against that at all.
Encryption just feels like a very "developer led" solution when the best way to protect data is via processes ie. educate users to have strong passwords, educate users not to share data (ie. exported CSV of forms data etc.).
And, as I say, the best scenario is always not to store the data in the first place - I bet 90% of Forms users don't really need to keep those records in perpetuity - they just want an email with the form submission. And I bet most submitters don't know their data will be stored. Removing automatic storing should be first priority IMO.
And I think if you are going to do database encryption then I think it should be done at the database level, not the application.
That's my personal view - not saying you are wrong, I just don't see it as priority at the moment. It is "icing on the cake", but we first need to secure the sponge!
The encryption migh prevent data leaks from some sql injection attacks but in many cases we see similar attacks via an API that is not properly secured. I guess it all dependes on you data and access model as well? (Row based vs. all access etc)
The first and most important thing when looking into GDPR is understanding it.
Don't start rushing DB encryption, audit trails, throwing out consent pop-ups all over your site and what not because in a lot of cases you will not need to do it.
Second thing is that people need to think about what data they ask, what they store and why they store it. Chances are you probably don't even have use for some data. So stop storing it.
If you are NOT storing personal information (names, id's, e-mail, locations, sales order etc. etc.) in your Umbraco database, then you'll probably do not need encryption on it that database.
If you're running commerce plugins for Umbraco and the data is in the main Umbraco DB... chances are you're better off with encryption, I guess sales information goes in the DB.
If you have a simple Umbraco site with 1 or a couple of admin accounts (you can pseudo-anonimize them), and you are not storing anything from your visitors, again, you will not need DB encryption.
If you are gathering let's say analytics via GA, modify your tracker to store it anonymously in GA... this way you can skip the consent pop-up because again... not storing personal data.
HTTPS/SSL is a must when your visitors submit information on your website. If anything that's sent clear-text can be intercepted... it means you have a data leak already.
That's why it important to map what your online situation looks like, analyze where you are asking for personal data, where are you storing it, how long are you keeping it etc. and then see if you need to take any actions.
As programmers we often run into scenarios where we think the client is "Over thinking" these issues and they are paranoid about loss of personal data.
But these clients are paying for us to make their requirements a reality.
So if they ask for encrypted data, encrypted data is what we need to supply them regardless of our thoughts.
I agree to some extent. But in many cases it is the other way around and we should be able act as advisers and guide the clients in the right direction. Of course this is borderline ethics and I respect that some developers want to focus on the coding task.
For those of you based in the UK ICO has just released their advisory to SMBs based there. They provide basic self-help check lists and a 12 step plan with activities to begin with now: https://ico.org.uk/for-organisations/business/
Most of these will apply to all of Europe but of course local legislation can be slightly different.
Ps If you have specific questions, you should contact the ICO, as they monitor most of the legislation so if someone (who should have a good graso) they should
We have been offering a four day GDPR course for the past couple of years. It covers both the legal and technical parts of the regulation. I have a talk that covers the Privacy by Design part of it.
I usually refer people to ICO for English language content. They were among the first to provide interpretations of the GPDR articles. Also their Norwegian counterpart is good but the number of people here that read Norwegian is probably limited. :)
I am by no means an expert in privacy law but I have read slightly more about it than a lot of devs in general. I can't chip in with package development but try to give back a little with links and general advice around this when I can. :)
It would be great if we could contribute to the discussion of the changes planned for Forms & Member data management, consent auditing etc. Whether that's here on Our or the Issue Tracker.
There's a lot of data protection expertise in the community. Let's use it!
I wrote a piece on the UX of GDPR showing an example of unbundling and layered in-context delivery of processing & privacy info as suggested by the WP29 in their Transparency Guidelines - for those interested!
GDPR and Umbraco
Hi,
We're currently reviewing the affects of the GDPR legislation (Wikepedia Link) that is due to come into force in May 2018 and one of the implications of GDPR is data encryption and how personal data is stored at rest and in transit.
So we were wondering, has the Core team considered the implications of the new legislation and whether or not encryption should now be included in the core (and enabled by default) in order to meet this legislation (and just data security in general?).
I've raised this in the forms forum as it's probably the logical place given this is the most likely functionality to gather personal information, however I guess this could also apply to members and/or users.
Has anyone else looked into this and if so, how far reaching does this go? I've even been wondering if the email addresses used for members should be encrypted as it's not clear to me where the line is drawn.
Cheers,
Simon
I'm interested in this too, we've seen other threads about this exact thing, but nothing seems to have materialised from it. We're thinking of implementing a custom membership area + helpers to handle encryption etc...
Hoping someone from the Core team can shed some light on the situation before I start.
Hi Simon,
thanks for raising the topic and I'm also really interested in the GDPR. We also had a discussion in this topic https://our.umbraco.org/forum/umbraco-forms/86655-umbraco-form-encryption and I've raised it a few times at Umbraco HQ.
I think Umbraco HQ is doing some amazing security stuff with regards to version 7.7 and hopefully we can inspire them to look at this stuff for that version or maybe 7.8.
But most helpful is probably if we come up with the specifications that we need to comply GDPR. First step that it's possible to encrypt the data. In the related forum discussion people have tried to use SQL Server Encryption, but I don't whether that is sufficient to comply fully to GDPR.
Will dive into this in August and hopefully can give more info later in that moment.
Do you currently have any specs that should be built into core?
Kind regards,
Jeffrey
Currently we're working with our legal advisors to understand how GDPR will affect the things we do. Once we fully comprehend the scope, we'll make sure that everything we do will be compliant with GDPR (including both CMS and Forms).
Hi Niels, thanks for the update. Any idea of a time path?
Any update on the timeline for this? As clients start to ask this question more and more it would be good to be able to say that Umbraco meets the requirements "out of the box" (ie before the custom designs & code)
:)
+1 Starting to get serious now..
I agree, will there be any discussion on this at the Umbraco Festival in London next Friday?
Hi Simon,
let's make a discussion happen :)! I will be there, HQ will be there, and you will be there.
See you next week,
Jeffrey
I'd be interested in getting in on that discussion action! ;)
+1, this is starting to get serious for us and our clients.
I don't think there is a specific forum for this, but if they are doing the open space free for all like they did last year, there could be a spae for a an open chat..
I get the feeling most people are looking for a steer. I know I am at the very least:
also does mean that potentially there will be a need for a data officer or owner of data.
Because theoretically anyone who registers as a user is subject to the new GDPR
+1 - this is relevant to our interests
First and foremost: If your role is to advice your clients in this matter, make sure to do thorough research on what GDPR really is. We've done a lot of research and in the current context of Umbraco, GDPR is 99% internal processes in organisations and 1% tech. Thus very little to do with Umbraco.
There's three central elements to current state of Umbraco and Umbraco Forms:
All three scenarios can currently be covered in Umbraco to date (we're looking into an out-of-the-box feature for exporting member data although it's very trivial already).
Further down the line it might make sense* to offer a feature out-of-the-box to encrypt/pseudomise data although in a breach where access to servers is given, it's very likely that this would have limited effect (at least if the data should be available to managers or website in some human readable form (decrypted)).
There's a heavy trend currently to turn GDPR into another Y2K - especially in the digital experience place. While parts of it is relevant, it's really important to cut through the noise and while we've also been close into going into the path of adding "gdpr features" in Umbraco CMS, after a good deal of research and legal talks, we've decided to stick to the norm of Umbraco and try to find simpler approaches.
That said other types of CMSes than Umbraco - especially those which does heavy personalisation, data mining and analytics - might need more gdpr work than Umbraco per se.
Hope this helps!
/n
*might due to data storage could offer this ootb already
If you do research online make sure to use best practices, including research on the writer of what you read.
GDPR is turning into a massive industry for anything from consultants to vendors of various types of software. A lot of these have been doing amazing SEO work and a lot of them are very frequent guest bloggers on various media.
Related to bullet #2 Right to be forgotten (delete personal data)
How would you go about doing that with Forms outside of a custom workflow?
Just delete the form entry (it's enough that people can request to get their data getting deleted). Just like you'd need to delete it from other systems if you've exported the data (hence why GDPR is more about processes than tech).
It's also a data breach if you've exported data and accidentally shared that file with a 3rd party.
Just like encryption have much less with the GDPR than people think (in fact it's only mentioned 3 times in the entire 200+ pages of regulation(!). The reason people are so focused on encryption/pseudonymisation is because you don't have to inform your customers of a data breach (although, isn't it a good idea?). Yet, you'll still need to inform authorities!
/n
Hi Amir,
we have created a Umbraco Forms-package (https://our.umbraco.org/projects/backoffice-extensions/umbraco-forms-on-perplex-steroids/) which has some additional question types, but also a workflow that deletes the form entry (and potential uploaded files when you have an upload question type on the form) directly after submission.
If you have a correct workflow where you sent out an email (via the default workflow or through another package we've created, called PerplexMail (https://our.umbraco.org/projects/backoffice-extensions/perplexmail-for-umbraco/)), and then delete the entry the website is pretty okay because the personal data isn't stored any longer in the site / database.
Regards, Jeffrey
Furthermore we've released a new package yesterday (https://our.umbraco.org/projects/backoffice-extensions/perplex-dashboards) that is also a small step in my opinion to GDPR-compliancy.
This package stores login attempts, logouts, lock-outs, etcetera to the backoffice of Umbraco. I think this is a crucial part in having control over the administrative part who has access to personal data. I think there should some extension points in Umbraco where we get the ability to store who has access which form entries, and/or which member profiles in the Umbraco backoffice. By doing that you can get a pretty comprehensive audit trail of who accessed these personal data.
Hope that other people can share their thoughts too in this forum about what is missing in Umbraco currently to be GDPR compliant. Then we can bundle these and make issues on the issue-log and put people to work ;)
+1 this, I too have created an audit trail tab for the membership area for use within websites built where I work. I agree that this would be a very useful addition to Umbraco out of the box.
Super amazing, Jeffrey! #h5yr
Hey Jeffrey that's awesome! +1
Sounds interesting Jeffrey, will have to check it out!
I think GDPR leads into a bigger discussion about data security and whilst I agree with you Niels that only a small proportion of GDPR is technical, it is still there. Whilst GDPR strictly speaking doesn't insist on encryption, it does suggest it on several occasions as a path to go down and I think it's a reasonable method of ensuring that you have a technological barrier to keeping personal data secure. It shouldn't be the only one, but that's not to say it shouldn't be there. We should make it as frustrating as possible to any potential hacker to get hold of personal data and encryption is certainly a good way to do that.
Additionally we are getting more and more requests from clients to show how we can encrypt personal data in Umbraco and whilst we might come up with our own ways of doing that, it would be 1000 times more easier if this is something that was built into Umbraco as a standard (even if it was an optional choice so you could have unencrypted data at rest if you really wanted to) and would make Umbraco even more of a no brainer as the CMS of choice for a lot of our potential clients.
I would urge everyone at HQ to consider looking into this as something to incorporate into a future version of Umbraco for Members, Users and Forms as whilst it's fairly straight forward to create custom data types that use encryption, it would be great if Umbraco supported this out of the box.
Hi Simon,
I completely agree with you on this. We also get asked about encryption and it's certainly a big concern to our clients - the fact there is nothing OOTB is slightly disappointing. Umbraco and Umbraco Forms are such good products and the last thing I want to do is start hacking them up trying to slip in some encryption layer, which will never be as good as if the Umbraco team do it directly.
As you can see from my previous post https://our.umbraco.org/forum/umbraco-forms/86655-umbraco-form-encryption - I've tried and failed to find a suitable work around - I was hoping we could use the TDE in SQL Server 2016 to get around this, but even the techs at Microsoft couldn't do it.
Heres hoping we see something soon.
Hi Paul,
I'm currently working on blogpost about what we (Umbraco + community) should do to make this GDPR-compliant. Including mock-ups of the needed changes, and stuff like encryption (and why TDE is not the complete answer).
I'm hoping to release it on November 29th (I love deadlines), so we could get in discussion during December 2017 and start implementing it during Januari 2018 and finish that off in Q1 2018. Sounds good :)?
I'll keep this forum updated,
Jeffrey
p.s.: If you're really curious; I'm looking towards making some datatypes implementing encryption like we did in our mail-package (https://our.umbraco.org/projects/backoffice-extensions/perplexmail-for-umbraco/) where the emailadresses and content of the emails are encrypted when stored. The sourcecode is also available if you really want to deepdive into it.
Unfortunately encryption OOTB isn't smooth sailing and come with heavy side-effects too (such as a tradeoff between incredibly ineffective encryption or very slow search (down to non-working search at a certain volume).
At the same time it doesn't do anything in terms of making organisations GDPR compliant (the only thing encryption will give you for GDPR is that you don't have to inform your customers if you have a security breach. You're still subject to fines, though).
We're all ears on specific areas where Umbraco needs to be modified to be GDPR compliant and if anything relevant come up, I'm more than happy to make it a high priority.
/n
wow that's going fast from lets have a discussion to getting something out there.. , just as a sideline.. once you have a blog post maybe release the discussion via a @skrift_io article so people are at the very least aware ..
I have the feeling lot of people are letting other dictate what happen rather than being involved in the process
I think hiding a lot f that information and expiring it are going to be key factors but maybe that's a healthcheck that could be written
Ravi
I think Niels makes an excellent point that GDPR compliance is largely about business processes. Sometimes it's easier for us all to focus on a technical solution, but that isn't solving the business problem.
When we started looking at GDPR we realised that the weakest link in the chain is not the storage of data in production, it is in controlling all the copies of data as it moves in or out. We can't afford to leave spreadsheets or old backups lying around!
As an agency we found that GDPR has made us change our development processes because we are liable for keeping all copies of end user data safe. Whilst production servers and backups have our best efforts at being secure, if a copy of the live database is used during development or testing ... and that laptop or USB stick gets left on a train - then our contracts leave us liable for the data breach.
Our answer is to never copy live data outside of a production or secure staging environment. I think developing against a copy of live data is a habit everyone will have to stop, as people start to see data as a liability as well as an asset.
For development, the options are either generating test content or anonymising an existing copy. We've gone down the second route. and have created a package to do this easily in Umbraco - https://our.umbraco.org/projects/developer-tools/umunge/
With sufficient interest, we would like to extend uMunge to Umbraco forms data - as a likely store of user-supplied personal information - but this is hard because it is stored in a dynamic JSON format.
Encrypted storage is a good way to tick the box for telling our customers that we are compliant, but my experience is they are also keen to have tight contracts and security policies that ensure as developers we are taking good care of handling their data. We need to solve business problems with business level solutions.
A very important and often overlooked point about protecting development environments! A lot of larger breaches have come from them in the past couple of years. Will look into the package. Interesting approach!
Hard to have much interest when you release packages that don't work at all and waste developer's time.
Hi Brandon!
If I may ask - what's the purpose of that comment?
Kind regards,
Niels Hartvig
Hello There, Niels,
Actually, my comment was in response to the self promotion of the following package: https://our.umbraco.org/projects/developer-tools/umunge/. I thought that the comment would indent under his comment so it would be obvious what I was referring to. Oops.
What I've always loved about Umbraco is that it is well very well developed by the people at Umbraco and at least most of the third-party packages developed are functional and well developed also. In short, it's nothing like the junk plugin farm that Wordpress is. It annoys me to no end when I see "developers" muddying the waters by releasing things that don't function at all, particularly when they are closed source and there is nothing I can do about it & I burn through half a day trying to fix it for a client just to end up with an unhappy client, a refund, and an incomplete project.
When working on Umbraco, I love that I can usually easily quote a client without having that sinking feeling that I've just "given away the farm." So, I suppose I could say that I take exception to pointless packages from developers who mark their own package as compatible and the rating system shows 100% functional in the latest release of Umbraco. It reminds me of a DNN plugin I used a few years ago where the developer released a totally broken closed source plugin & made his money by immediately providing a dll that actually works.
Hi Brandon!
Fair to be frustrated, but we're the Friendly CMS and your first comment wasn't in sync with our values.
The project above clearly states it's in beta and in the spirit of paying it forward you could have left feedback in their forum.
Umbraco is great because of the people. If the people don't behave nicely, Umbraco is no longer the Friendly CMS. No matter your frustration, I'd encourage you to keep a friendly tone or keep your frustrations out of this forum.
Thanks!
Hi Brandon,
We didn't set out to build something that didn't work, or release a package designed to waste anyone's time. We have done our own testing, but it obviously does not cover all the possible ways people can use Umbraco.
Please give us some specific feedback - either direct at [email protected] or on the package forum - as to what didn't work for you so that we can try and recreate any issues and fix them.
Thanks!
Alan
I agree with Niels's point that the GDPR is mostly about processes and governance.
Most of the work lies in figuring out which data you actually store, where it is stored and very importantly what the purpose of storing it is.
A good way of doing it can be taking a risk-based approach where you classify your data and protect it accordingly. You need to actively consider which data to keep or even better if you need to store it in the first place.
As developers most of us have been guilty in hoarding data with the purpose of future fun functionality or analytics that only benefit ourselves as vendors. With the regulation's demand of active opt-in and explicit consent for every use and re-use of data this will no longer be allowed.
The thought of Privacy by Design, which is a basis of the GDPR, is new to most developers as are are lot of the techniques required to support it.
For simpler CMS solutions (ie without advanced membership) my best bet is that instead of looking at Umbraco you need to look at what third-party trackers and analytics tools you use. Do you need them? Do you have legal basis to use them? Where do they store data about your customers? Identity all data controllers and data processors.
One place that I do see a need for Umbraco to improve is to provide proper and accessible event and audit logging out of the box for all system events. It is in place in some parts of the system but it needs to be extended (and configurable) to all user and membership events. Ideally standardise the way we write to it from packages etc. This data should be formatted in way that it can be forwarded directly to a log management and analytics tool (or provider). Jeffrey and Co's package is an excellent step in the right direction (H5YR!) but we need this in core.
Wearing the tinfoil hat... Prepare for a breach. They will happen. What will the consequences be for your and your customers. Encryption at rest isn't the solution to everything if you forget basic input sanitisation ...
I look forward to a lot of interesting discussion about this at CG18!
A couple of handy links for those that wish to dig in a bit further:
@Niels, perhaps I should dust of the PbD talk I suggested for CG16 for CG18? :)
Interesting discussion. I would agree that Umbraco Forms and Member data pose a challenge for us under GDPR. A large part of GDPR is processes but I wouldn't go so far as saying that the technical end of compliance is tiny by comparison. Technical implementations will be a part of enabling those processes. Aside from the security aspects already mentioned, technical solutions will also factor from an auditing and consent management point of view and efficiently enabling a number of the rights conferred to Data Subjects under the regulation.
In terms of Umbraco Forms, storing the collected data by default I would see as an issue. It is not enough to say that the Data Subject can request that you remove the data that you hold on them. We need to be limiting the data surface as much as possible, and therefore limiting risk. It is likely that many implementations just use Forms to collect data and send that data elsewhere using the workflows for further processing. Allowing developers to choose whether that data is stored after the workflow is complete would go some way towards mitigating risk.
Under GDPR we are also tasked with being more transparent in explaining the reason for the data collection, how the data will be used and what processing may occur. This will mean that pointing people to a catch-all privacy policy may not suffice if you have reason to collect data throughout the application for differing purposes. If Umbraco Forms were to enable us to store the reason for data collection along with the form itself that could make transparency and auditing easier to implement. These reasons can change over time and so capturing a snapshot of the terms the user agreed to at time of submission would be useful.
As an aside I straw polled GDPR awareness in the community a few months back:
It's good to see the awareness/discussion progress!
Cheers
I think there are a couple of issues with file uploads in Umbraco Forms that do need prioritising with GDPR in mind.
File uploads that could contain personal data go to the media folder (GDPR: personal data must be processed securely) http://issues.umbraco.org/issue/CON-1454
File uploads are not deleted with the form (GDPR: right to be forgotten) http://issues.umbraco.org/issue/CON-1183
@Neils Could you comment? I'm just starting to work with Umbraco Forms so hopefully I've just missed a setting somewhere.
Great points - thanks Rick. We'll get them prioritised for next Forms version.
Brilliant, thanks Niels.
I think this is another issue which needs a technical fix:
New users should not be granted access to manage and view all forms (GDPR: personal data must be processed securely) http://issues.umbraco.org/issue/CON-1022
Hi
In case anyone is interested, I have pushed a demo up to Github with an example of encryption/decryption data in Umbraco back office.
The link can be found below if anyone wants to have a look. Improve if necessary
https://github.com/GeorgePhillipson/GDPRSolution
Regards
George
Interesting example George, couple of questions though:
Hi Nik
Thanks for the reply, answers to some of your questions below.
1) I'm self-employed and don't work on large complex sites. The example I have shown is just a demo and work OK for small websites/business. But as stated, 'Improve if necessary' anyone can download the code and enhance it. That's why I put it up :).
2) In the backofficehelper.cs class the EditorModelEventManager.SendingContentModel captures the loading of the page and passes the encrypted data off to be decrypted.
3) See answer 1
4) No works OK every time I have tried it.
Cheers
George
Hi George,
The Umbraco DB doesn't seem to be committed to your repo. The gitignore looks like it may have prevented it. Am interested to look at your example.
Hi Alan
I have uploaded .sdf file, downloaded and tested and works
George
Nice proof of concept. I think features like encryption at rest for the database is something that should be used whenever possible. Azure offers this by default now:
https://azure.microsoft.com/en-gb/updates/newly-created-azure-sql-databases-encrypted-by-default/
Then the issue in the back-office in terms of security comes down to locking down file media (uploaded via forms) and form entries themselves only to those that should have access.
I think there's a few things that could be done to improve Form's compliance:
Don't automatically store submissions - make it a workflow option, not compulsory.
When submissions are stored, have an option to say how long for eg. 6 months. After this period they are automatically purged.
Have Forms generate some kind of "delete my data" URL (with a unique GUID or hash) that can be used to generate a link that can be given to submitters to remove their data (could be added to emails etc.)
Hi all,
just released an pretty extensive article on Skrift.io on GDPR and Umbraco: skrift.io/articles/archive/i-have-a-nightmare-dream-about-umbraco-and-gdpr/. Would love to have your opinion on it?
And make sure to check out the html mockup too: http://downloads.perplex.eu/umbraco/gdpr/members.html
Regards,
Jeffrey
Hi Jeffrey
Great article overall and many good points about technical Umbraco specifics.
Perhaps you could have covered user consent and data minimisation a bit more in detail? Both are quite important and will require a change of mindset for many of us.
Important additional questions to your list are "Do we need to collect this data?" and "Do I have legal basis to do so?"
Recommended further reading in that direction could be:
Once again, thanks for your community efforts on increasing the overall security and compliance maturity of Umbraco over the past few years!
Kind regards Frederik
Hi Frederik,
thanks for your kind comment, really appreciate that!
Thanks for point these two points out, but in my article I tried to focus mostly on the technical stuff that should be done (with a package / within Umbraco Core) to get everything in place. The user consent and data minimisation is something a Form Editor / developer should think of, but is not something that could/should be forced within Umbraco.
So that's why I didn't touch upon that topic in my article.
Cheerio, Jeffrey!
Relevant scoping... I am just pushing for general awareness among devs whenever I can. This is going to (should) change how many people work. :)
Everything @frederik said,
The only thing i would add is a tiny bit of scaremongering ,
What does this mean for me if I collect data?
https://www.out-law.com/en/articles/2016/may/gdpr-potential-fines-for-data-security-breaches-more-severe-for-data-controllers-than-processors-says-expert/
a- A two-tiered sanctions regime will apply. Breaches of some provisions by businesses, which law makers have deemed to be most important for data protection, could lead to fines of up to €20 million or 4% of global annual turnover for the preceding financial year, whichever is the greater, being levied by data watchdogs. For other breaches, the authorities could impose fines on companies of up to €10m or 2% of global annual turnover, whichever is greater. The relevant provisions on data security are contained under Articles 5 and 32 of the Regulation. Article 5 sets out basic rules on personal data processing which only apply to data controllers, considered to be fundamental to data protection. One of those rules requires data controllers to ensure that personal data is "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". According to the Article 83 provisions of the Regulation on administrative fines, where data controllers breach that Article 5 requirement they can be served with the highest possible fine that data protection authorities will be able to issue under the reformed framework. In contrast if data processors breach their statutory data security obligations, set out under Article 32, which requires them to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk" of their personal data processing, then the most they could be fined is up to €10m or 2% of global annual turnover.
If people understand the necessity from a privacy perspective, they may act as more active collaborators and even ambassadors than if they are just scared of fines. That said, some scaremongering might be needed to get funding. :)
Just to ramp up Ravi's scaremongering, there's also the risk of prison time if you find yourself in serious breach of the Data Protection Act! :-S
Great article Jeffrey and some good points made by Frederik. As you mention in the article, I've leaned towards carrying out encryption and decryption in code and used AES 256 Rijndael enhanced along with SALTing to try prevent Rainbow attacks, however you then hit another problem of where do you keep your encryption keys?
Going back to Forms though, at the moment we're in a position where we're finding that we can't propose it as part of our solution due to the default nature of storing data in the database. Although there is the package Jeffrey has created which deletes the form data, strictly speaking you could have data stored in the SQL Server transaction log, which I'm guessing (and it is a guess) still needs to be taken into account. There's also the risk of something causing an error that prevents the data being deleted. Granted it's a tiny risk, but still one that's there.
If your there Niels, any chance you can let us know if this is something that might be added in at a later date? A checkbox saying "Store data?" will do the trick! ;-)
Nothing like scare mongering.. however to your point..
Good database practices like a trigger to destroy old records and being super careful with what you keep . ie really paring down what you keep .. the other alternative would be to get people to sign up to apple like terms and conditions so you have iron clad legal sign off might be a way to approach
essentially the first and biggest decisions .. need to be what do i actually need to make the site run..
True... or not storing the data in the first place! ;-)
Hi Simon,
the question about where you keep your encryption keys is totally legit, and I'm currently storing these encryption keys in the web.config. Not the best place, but I have no better option.
In my opinion, there should be an easy "encrypt" and "decrypt"-function in Umbraco Core that you could use without knowing the exact implementation as developer. The Core should implement a strong algorithm (like AES256 RijnDael) and of course you should have the option to alter that.
Umbraco Forms will support not storing data in a Q1 release, so you should be covered there.
Great news Niels, that will definitely help a lot!
Hi Niels,
I'm really wondering if you could shine your HQ light on my Skrift-article. One of the issues is not storing the data at all, and it's great news to see that's coming, but what do you think about:
I know you're not a big fan of GDPR, but in my opinion this some stuff that should be in Umbraco OOTB and not be created by package creators.
\ Jeffrey
just seen this: may help anyone with some nice infographic soothing...
Hi Niles,
Our company deals with a lot of clients who use Umbraco as their desired CMS and since the ever increasing importance of GDPR they have ALL asked for the Forms data to be encrypted. It would be so important to every one of our clients if this was available by next year.
Thank you all,
Jon
I really don't see the point in encrypting database content that is exposed via the CMS. Clients may be asking for it, but only because they have been panicked into thinking it is required.
What is more likely? Someone gets access to the Umbraco back-end where they can access all the unencrypted data or someone gets access to your database server?
If someone has access to your database server, it's game over anyway. They could just reset the admin password via SQL, gain access to the CMS and then get all your data.
If you have a genuine fear data stored in Umbraco forms is so sensitive it can't be leaked then don't store it in first place. That is the only safe way.
Hi Dan,
I do not agree. As written in the article; if you have an SQL Injection flaw on your website (still #1 in the OWASP-list), you could preform a SELECT-statement on the data. In the case of unencrypted data you'll have access to all data. If it's encrypted you only have some encrypted data that you cannot unencrypt without getting the key from for example the web.config or via C#.
You probably won't be able to do an UPDATE-statement, so that is not a problem. And if you use Transparant Data Encryption, it won't protect you against the SQL Injection attack.
Or am I overlooking something?
Jeffrey
If, as I believe, Umbraco Forms (which is what we were talking about) uses PetaPoco for database access (which I believe it does) then SQL Injection can never be an issue. Likewise for the rest of Umbraco.
Sure, there are hypothetical risks we can guard against. But the biggest glaring risk is someone gaining access to the CMS - probably via social engineering - and this won't protect against that at all.
Encryption just feels like a very "developer led" solution when the best way to protect data is via processes ie. educate users to have strong passwords, educate users not to share data (ie. exported CSV of forms data etc.).
And, as I say, the best scenario is always not to store the data in the first place - I bet 90% of Forms users don't really need to keep those records in perpetuity - they just want an email with the form submission. And I bet most submitters don't know their data will be stored. Removing automatic storing should be first priority IMO.
And I think if you are going to do database encryption then I think it should be done at the database level, not the application.
That's my personal view - not saying you are wrong, I just don't see it as priority at the moment. It is "icing on the cake", but we first need to secure the sponge!
The encryption migh prevent data leaks from some sql injection attacks but in many cases we see similar attacks via an API that is not properly secured. I guess it all dependes on you data and access model as well? (Row based vs. all access etc)
Exactly Dan... I fully agree with you man.
The first and most important thing when looking into GDPR is understanding it.
Don't start rushing DB encryption, audit trails, throwing out consent pop-ups all over your site and what not because in a lot of cases you will not need to do it.
Second thing is that people need to think about what data they ask, what they store and why they store it. Chances are you probably don't even have use for some data. So stop storing it.
If you are NOT storing personal information (names, id's, e-mail, locations, sales order etc. etc.) in your Umbraco database, then you'll probably do not need encryption on it that database.
If you're running commerce plugins for Umbraco and the data is in the main Umbraco DB... chances are you're better off with encryption, I guess sales information goes in the DB.
If you have a simple Umbraco site with 1 or a couple of admin accounts (you can pseudo-anonimize them), and you are not storing anything from your visitors, again, you will not need DB encryption.
If you are gathering let's say analytics via GA, modify your tracker to store it anonymously in GA... this way you can skip the consent pop-up because again... not storing personal data.
HTTPS/SSL is a must when your visitors submit information on your website. If anything that's sent clear-text can be intercepted... it means you have a data leak already.
That's why it important to map what your online situation looks like, analyze where you are asking for personal data, where are you storing it, how long are you keeping it etc. and then see if you need to take any actions.
Good luck everyone.
As programmers we often run into scenarios where we think the client is "Over thinking" these issues and they are paranoid about loss of personal data. But these clients are paying for us to make their requirements a reality. So if they ask for encrypted data, encrypted data is what we need to supply them regardless of our thoughts.
I agree to some extent. But in many cases it is the other way around and we should be able act as advisers and guide the clients in the right direction. Of course this is borderline ethics and I respect that some developers want to focus on the coding task.
For those of you based in the UK ICO has just released their advisory to SMBs based there. They provide basic self-help check lists and a 12 step plan with activities to begin with now: https://ico.org.uk/for-organisations/business/
Most of these will apply to all of Europe but of course local legislation can be slightly different.
The European Commission launched an easy-read campaign site on the GDPR with a business oriented focus for SMBs: http://ec.europa.eu/justice/newsroom/data-protection/infographic/2017/index_en.htm
Thanks for sharing!
Continuing my spam streak this post covers a lot of the GDPR requirements with specific solutions targeting developers: https://techblog.bozho.net/gdpr-practical-guide-developers/
(via @dadolfi)
gosh Fred, you have been doing the deep dive.....
come back up for air..
Ps If you have specific questions, you should contact the ICO, as they monitor most of the legislation so if someone (who should have a good graso) they should
Ravi
Thanks Ravi, I am staying deep though. :)
We have been offering a four day GDPR course for the past couple of years. It covers both the legal and technical parts of the regulation. I have a talk that covers the Privacy by Design part of it.
I usually refer people to ICO for English language content. They were among the first to provide interpretations of the GPDR articles. Also their Norwegian counterpart is good but the number of people here that read Norwegian is probably limited. :)
I am by no means an expert in privacy law but I have read slightly more about it than a lot of devs in general. I can't chip in with package development but try to give back a little with links and general advice around this when I can. :)
An update from the HQ on GDPR, as I'm sure you've all read: https://umbraco.com/blog/umbraco-and-gdpr/
It would be great if we could contribute to the discussion of the changes planned for Forms & Member data management, consent auditing etc. Whether that's here on Our or the Issue Tracker.
There's a lot of data protection expertise in the community. Let's use it!
I am wondering if someone more knowledgeable then me could explain how the "Right to be forgotten" would be executed regarding members/users?
Does this involve the scrubbing of user/member related data such as values of properties.
Any high level explanation on how this would work in practice would do wonders.
I wrote a piece on the UX of GDPR showing an example of unbundling and layered in-context delivery of processing & privacy info as suggested by the WP29 in their Transparency Guidelines - for those interested!
https://www.serveit.com/gdpr-user-experience/
Hi all,
we've just released a package that implements stuff that could be relevant for GDPR: https://our.umbraco.org/projects/backoffice-extensions/perplex-security-and-gdpr-package/.
Mostly based on the implementation of my blogideas:
Maybe it helps a bit,
Jeffrey
It seems that Umbraco 7.9 will be released Tuesday, February 27 2018 and it's called The GDPR release: https://our.umbraco.org/contribute/releases/790
Jeroen
is working on a reply...