 Well, OK, I think it's nine o'clock, so let's get started. Thank you all for coming. I hope you have the great event I have so far. Thanks for voting and it's been excellent. I'm here today to talk to you a bit about the new upcoming EU data protection regulation. How many of you here have heard of the GDPR before? OK, god, a few of you. How many of you here have heard of OpenSec before? OK, great. You should be surprised that in Sweden, when I usually hold this, it's all the way around. So more of them are familiar with the GDPR than OpenSec. The thing is with GDPR is I usually illustrated with this picture behind me. It's from a good friend of mine at IBM who first talked about it. The GDPR is like blind people trying to describe an elephant. It's all about where they are, what they're feeling, and yeah, it doesn't give a complete picture because it's very, very massive, very hard to get a full grasp of the GDPR. Luckily, we are going only to talk about the infrastructure and securing the infrastructure to be compliant with GDPR. So even if we are going only to handle the tail of the elephant, we will be compliant in the tail end of the elephant. So that's the goal of this. I got a review from earlier lecture where they were really disappointed. They didn't give a complete explanation of all things GDPR in 40 minutes. I said, well, that's a pretty big ask because that's describing the complete of the elephant. It's a full day's work. The GDPR, like I said, it's three-layered. You will need policies, you will need processes, and you will need practice. It's the practice layer, the layer where you actually do something that comes down to you and the ops guys, it comes down to open stack. You should be happy with this because it's also a bit of the easiest layer to fix. You have pretty clear directives. GDPR itself is clear as mud, so don't hope to get too much from them. But I base my recommendations upon the Germans, because the Germans has already enforced privacy laws, driven privacy prosecutions. And I dare say that if you are on the right side of the Germans, you will be safe in most European countries as well, because, well, the Germans are the best at what they do in this area. You can trust that no other country will have more strict rules regarding this. This is a lecture about compliance, and it's important to know that security and compliance are not always the same thing. You can be secure, but not compliant, and you can of course be compliant and not secure. So that's the other ways around. I am focusing on compliance. Hopefully you should get both security and compliance at the same thing, because the meaning with compliance is of course. What's a good example about security and compliance when you're not the same thing? One shining example is containers. Why? Because compliance, it's all about surviving the checklist. An auditor will come with a huge document with a lot of check boxes that he needs to take off, check, check, check. These checklists are made when Bill Clinton was still president. They're made for physical hosts. When you run VMs, you have a one-to-one relationship in regards to disks, to network adapters, to, well, pretty much anything. You can translate a checklist based on a physical host, easy to a VM or a virtual object. A virtual router is still a router. You have the checklist. The network is still a network. But when it comes to containers, you will find areas where the checklist can't actually answer, and then it's up to the auditor to see if they have a flexible mind. This is not always the case. So if you run containers, you run the risk of running into an incomplete checklist. And this is something, well, certain companies wants to dare and try this and say it's an acceptable risk for us that we might be taken to court. And some companies don't want to do this. It's up to them, but like I said, from a security standpoint, I would be perfectly happy running a lot of sensitive information in containers. No problem at all. From a compliance perspective, well, you need to think about that. Some definitions I would try to get people up to speed a bit about the GDPR quickly. Personal data, that means anything that can identify a living individual, uniquely identify a living individual. My name is Kim Hindert. There's only one Kim Hindert in the world, so that's uniquely identifiable. If you're calling John Smith, then it's not so it can vary a bit as well, but it's if you can be uniquely identified. This is important to know that the law says that indirectly as well. So pseudonized data, anonymized data, is still privacy data according to EU now. And personal data is included even in our unstructured format. So mailboxes, personal data, same regulations. Processing, well, that's what you will do. Anyone who are part of the information life cycle is part of the processing. So here OpenStack comes in. I will limit myself to talk just about the infrastructure layer, about the OpenStack layer. Now, if you're running an app, well, you have a lot more to think about. Luckily, we get the processing level of the infrastructure at the OpenStack. Only really needs to focus about this personal data breaches. And this means that it might even be accidental. It's still a personal data breach. And like you see loss, alteration, access to store. Now, this is important as well because if you actually allow personal data to be processed, that means that you can make a copy that you just happen to send somewhere that is not legal, that's not allowed, that's being processed in the wrong way. And that's a personal data breach. Even if no human being has seen the information, it's still against the law to transfer it outside the EU, for example. So if you have a backup that goes outside the EU, well, that's against the law. And then the question is can they claim damages against this? Can they say I was hurt by you transferring my data? Even if no human, other human has ever seen that to another country. And yes, you can because there was a case in Germany where this was actually the case itself and the person who claimed this won. Taken into account, this is what the law gives us from the ops perspective about security. It's an easy way you should see appropriate technical and organizational measures. That's what we get. Good luck. That's the EU way of saying we don't want to bother with technology but we will reserve the right to in hindsight blame you. That's actually EU way. So what is appropriate technical measures? Well, we will try and solve that because like I said, the Germans have actually run through this a bit with processes. So if we follow them, we will be on the safe side. Like the data protection authorities tell me when I ask them, but how do I know what it means to be compliant? They say you shouldn't be that worried because if you run faster than your friends, the bear who chases you will eat your friends instead. You don't need to run around the bear, you just need to run around your friend. So, why should you care about the GDPR at all? Well, like I said, it's a law. You can be fined for a personal data breach up to 4% of the global turnover. So we're talking a lot of money and for even minor infractions like not having the appropriate access controls. Like not having updated operating systems. It's a 10 million euro fine for these things. And you have an insanely increased chance of being audited by the pure fact that any data subject that you might have within you, anyone who has a personal record against you. So if you run a store or service or something in the app where anyone leaves their personal information, they have a right to audit you. So if you come to bad terms with a customer and you have mass, then they can just for the heck of it messing with you require you to be audited. So the chance of being audited has increased a lot. And if you don't have your documentations in order then, well then the checkbook with fines will come out. What I don't think, this is what's not of course the spirit of the law, but what I don't think people realize a bit is that there's a lot of money to be earned by doing this as well. So that's a risk factor you should take into account nowadays that privacy data is a lot of hack value just for extortion, for ransomware. If I steal privacy data from you and I know that you face a 10 million euro fine for that, I say give me 1 million euro and I give you back the data. I will come back to that, this is the law. That means that you in the ops who run an open stack has a big chance of being thrown under a bus. I am the chief security officer at City Network. So I write the policies at City Network and I have done this calculation that it's by far a lot cheaper to have a designated scapegoat within the company. Some poor unsuspecting ops guy, then solving all the shit that is required to be legal with the GDPR. So this is really why ops people especially should care because you have no way of totally absolving yourself of responsibility because it's the law. So like if a trucking company tells you you should run over the speed limits. Well, the company will be in trouble because you're not allowed to ask that of your employees. But the employee himself who runs the speeding will have no way of avoiding the fine itself. So this can trickle down to ops. Easy enough, you have a data protection officer at your company. You should talk to them a lot and make sure that what you're doing is approved by them. Then you don't have that responsibility. This is really important. But like I said, we will go through what it means with the open stack itself. I'm usually asked distributions or not. Well, I will say that the community addition of open stack is good enough to handle the security demands of the GDPR. But from a distribution standpoint, it's exactly why I want the distribution, this one, because I can throw someone under a bus. And it's not me. That's what Red Hat, Susebuntis 4, they're excellent under a bus throwing guys. Like I said, distribution-wise, the community addition, it survives the checklist of auditors. They have these things. I was part of the open stack contributions when it was named Cactus. Then I left for a while and came back when it was named Liberty. And it changed a bit between that. I would never dream of saying that the cactus part of the release would actually survive all of this, but now open stack security has grown a lot and the foundation do an awesome job. Real awesome job. Any of the security team here today? Well, they were excellent. Now I will say that what you need to take into account when you run a community addition. You can do this, like I said, you can make it perfectly fine for GDPR audits, but you need to take into account the release cycle and end of life. End of life is a big no-no, always. So no software that's not security supported. That's big fat no. It's sensible, of course. I wish all of the companies would respect this because that's just plain sense. There will be vulnerabilities out there, and it needs to be security supported. But what you will notice is that community additions have a very short lifespan of security support, so you need to update, keep on updating, in a rapid pace if you use the community addition. Not all projects are security supported within the open stack. That's also important to remember. So if you want to use Manila, you won't find Manila here. Really important to know. If you want to use Manila right now, you need to go to distribution and make sure that they support Manila. So don't take this. I'm only pushing for websites because this is a living thing so it changes a lot. I've had lectures before where people watched the video and complained to me. I followed what you said and I was blamed. Yeah, because it was a year ago. Things happened, so keep you updated on this. It's important to know that. One of the demands within the GDPR is that you do a risk assessment. It's easy enough probability, severity. The problem with infrastructure, problem with open stack is that the severity will always be high. That's the part of it. It's infrastructure. Access to full databases, full VMs, full storage. A breach in the infrastructure will always be highly in severity. So it's lowering the probability. That's when best practice guidelines comes into mind. You need to follow the best practice guidelines because when audit comes and you have had a data breach that you needed to report and the auditor comes to check up on this then they will see, okay, this was a severe breach. It was back in the infrastructure. What did you take for precautions? If you have not followed the best practice guidelines then you will be in a bit of trouble. It's enough to say that. So the damn Yorks at OpenStack actually did the best practice guidelines. We don't have any liability, darn it. Forcing us to work. How many of you have read this book? Great, a few of you anyway. All of you interested in keeping compliant with GDPR needs to read this book. You cannot avoid this if you want to be ensure that you won't be thrown under a bus. This is the best practice guidelines and it clearly states what the OpenStack thinks about things. And if you deviate from this you will need to have a big and really damn good reason why you do that and saying, oh, we didn't have the time or resources. That's not good enough. I was helping a bank who went to the EU and cried a lot about these new regulations. We have a lot of systems. We were nowhere near time enough to fix this before 2018. And the EU took the books of the bank looked at them, ten billion dollar profit, ten billion dollar profit. And they said, okay, if you spend a hundred billion dollars next year and you still have not fixed this in time then you can come back and complain. So if you work for a company that's done a lot of profit you are in big trouble if you don't follow the best practice guideline because you can't blame that we didn't have the time or resources. In the best practice guideline I will go through it shortly There is a lot of using TLS SSL encryption. This basis a lot. I just say, control your PKI. Have a good policy for handling PKI's. This is also important because the checklists loves PKI's. They are very familiar with this and it's been around for 20 years now. So they have a lot of issues with it. So keep in mind that you need to have a good root certification authority. You need to have a good process on how you check out certificates. And you need to have this about the certificate chain being completed. So make sure that your company has a good PKI system in place. That's an important part. I will go through it quickly. It comes a bit to setting policies. The guide shows you where the policies are. But how do you set the policy that you ensure that you are compliant? Well, this is the basic default policy of most things. It's also the policy in common law against people that if it's not explicitly forbidden, well then it's allowed. This is not a good policy to have if you want to be compliant. This is the policy you need to change to be compliant everywhere. Everything which is not allowed is forbidden. So deny all is the basic policy and then you allow only the specific things you need to do. People say, oh, hard yes it is. It's one rule regarding policies that you can always fall back on. If you have any doubt at all, am I compliant? Look at this policy and say, okay, is this true, then I'm good. If not, change it. You need to change this, but luckily as well you can automate a lot of it. Automate is the best. Where do you change this in the policies? You see policies in the policy files that have just dash dash and nothing in between. That means that it's allowed in general at large and you can't have this. Always put a role here. Always put up. So every policy has a defined role. That means that no user created just as a user has any rights naturally by themselves. They always have to be assigned a role as well. You can design your own roles. So this is easy enough, but remember this because this is not by default. So you need to change this. Then it comes to easy parts like security groups and firewalls. Always, always, always have this method on your hosts. Allows things specific. No ranges, I tell you. No ranges. Only single hosts, single ports. One rule for each of them. It's easy enough if you automate, believe me, but you should really automate. But this is what you need to do because then you can review it. Luckily OpenStack wants a lot of ports, a lot of traffic, a lot of intercommunication, but it's predictable. You have a really good set, so once you do this, once you have this set up, it's easy enough to maintain. But like I said, no humans should do this. This is strictly automation. Regardless of what type of automation tool you use, any one of them is just fine, but automate and keep the policy intact. Because if you have this policy, then you will be safe when the auditor comes because you can say we did what we needed to. We've done our really best. This is appropriate guidelines. This is best practice. Another thing important to remember is keep logs, analyze logs, secure logs. Decent enough, it's not part of the OpenStack itself to have a logging system. So you should have a remote log server or something or something like that, similar. But just keep the logs. It's good for evidence to prove that, well, it wasn't a problem in our end. Monitor events, set up a monitoring system that gives alerts. Regular opsystems gives alerts when something breaks down, when something stops working, when the services fails. Monitor security events itself as well, especially authentications. Because you want to have even successful authentications sent as an alert to a manager. Because they need to know, okay, wait a minute. This was or building API user. That user shouldn't log in at this time. So monitoring systems as well. Any one of the good monitoring systems today works just fine. But remember to monitor events. You need to have a good check on the side which monitor events are important. And you usually fail to forget that successful logins are just as important as unsuccessful. I would recommend that you follow a couple of standards if you can. PCI DSS gives a really good framework that assures you that you are on the right side of things. As well as ISO 27018, who specifically points out rules regarding privacy. So if you follow these, you will be on the very safe side. PCI DSS is nice enough because you have automated checking verification tools for this. So this is nice. I will show you one of them. It's called OpenScap. How many of you are familiar with OpenScap? Ah, a few of them. Excellent, but for the rest of you. I will show you this one. This is really nice. I use it a lot. You have the OpenScap. I just quickly want to refer to you the OpenSecurity guidelines. This is best practice. Like I said, you should read this, but they have an awesome checklist here. You have Wi-Fi. You have a great checklist with a lot of checks. Make sure you do follow this checklist. Retro it, follow it. Like I said, make sure your policies are in order. Then you will be perfectly home safe about this. But like I said, now you all know that there is a checklist. Let's go to OpenScap. This is automated checking. You can install demons to do the scheduled checkings. It's pretty easy enough, decent enough to have this getting started. They will show you how to run a vulnerability check. So you install a scanner app, and then you run a scan based on a set policy. Let me show you. Here I have my poor little dev stack I put up yesterday. And I have a scanning profile where I select the profile for PCI DSS. And the XML file for this. And if I run this, it will do a lot of checks, as you see. And I will get out a report. And then I will know if this host is compliant or not for PCI DSS. This is really terrific to run on a regular basis. This is really terrific to run when the order comes as well. So most distributions have this. I do know that one huge distribution is working on this. That doesn't have this just by package. I have the libraries upstream, and you can always get these things as well. So it works fine on pretty much all Linux. Like you see, my cloud based dev stack doesn't have a lot of security, a lot of fails. You do get a HTML report directly as well in a more readable format. So I do really recommend that you use OpenScap. It's awesome to quickly verify that your host environment is secure enough as well. Well, that was pretty much what I had to say about securing OpenStack for the GDPR compliance. Any questions? Ubuntu is working on it. The Red Hat Center has this already off the shelf right away. You can get this on Ubuntu and it works fine, but you need to do some modifications. But they're working on it. I know that they have it in production. So if you buy a subscription, if you buy a vendor subscription, you will get help with this immediately. So they have it. It's not always in the free edition though. Yes, I've written things for the OpenStack best practice guides. So I've written in the OpenStack best practice as well. But you need to run the PCI DSS profile by itself and then run the OpenStack best practice profile. Yes, I've pushed them upstream, so I'm waiting for them to be completed, yes. Any more questions? Okay, decent enough time. Thank you very much.