 Okay, so hi everybody. I'm Damien and I'm supposed to be a security specialist and we are going to show you something called Harry's Security. Yes, my name is Romain. I'm working for Red Hat. I'm supposed to be a Java expert and I know even less stuff about security. I'm together so we are going to talk about security and how to integrate it in your deployment process. The first thing is that security is broad. Where do we start? Okay, so the first thing to start with is what Microsoft did in fact and the OAS project. It's pretty nice. Okay, so it's called OAS on threat modeling. That's very cool to put on resume but what it's about? It's kind of framework or a list of things that you have to consider if you want to put some security in your application. So it's going to allow you to describe your system and reduce it in small modules, something a bit more manageable basically. Yeah, and then perhaps you can fit it into your sprints and manage it and it should support you in finding your quest for the full company. Okay, it sounds less bullshit than I was expecting so let's look at it in detail. Interesting. Where do we start with this thing? We start with stride and dread. So first stride. So the goal is to put a category on the thread that you are facing. Okay, so there is like five of them or whatever. We have no time to cover that so just like to know let's pick one and analyze one just to have an idea. What is repetition? What is this arthing for? The repetition is to prove that someone did something for real or at least the user did. Okay, and how this process is helping you mitigate that or fix this issue? In fact, you have to rely on auditors and here you can really prove that at least this login performed the actions. It can be repudiated. Okay, so now let's look at the other acronym because there was two of them remember. Yeah, dread. So here the goal is to put a priority or the mage on your thread. Okay, and by the mage what you mean here is actually the impact on my business, not the mage in general. Exactly. Yeah, let's go quickly over the other part of the acronym. So what is this reproductability? It's how easy to, well, to reproduce the attack. Come on. Yes, and exploitability? Well, how is it to reuse and make something nasty with this attack? Well, I think that the user I guess is transparent but still. Yeah, well, are you impacting 50% of your users? All your users? Only 1% of your users? Only the enemy basically. Discoverability. So here it's important is how it is to, for a complete noob at the other end of the world, to discover again the threat or to exploit it. So globally this is just for having the priority and knowing how damageable it is. Okay, so I kind of like it because what I really like here is that it's a brilliant tool to communicate. So you can have your low-level, grunt guy doing like very hardcore security stuff, being able to communicate to his top manager wearing a suit. This is a real issue because they have a way to communicate. I like that. It's kind of UML for security? Yeah. Well, if you like UML. Okay, let's make it a bit more concrete now. We are going to think about a simple web app. We're not going to think like a big application, something very simple, something like, you know. Yeah, so a stupid way, what could really stupid, like just warfight. For the example. And to make it even more simple, we can take an internal app. So it's not going to be like, it's going to be an internal app for employees. It's going to be not sexy, nothing fancy, no high-frequency trading, no big data, no ad-doop, no machine learning, not even social app. Yeah, so let's call it a cool app. Yeah, hashtag cool app, exactly. So let's discuss how we're going to build it a bit. So it's a Java application, right? So we need to have frameworks. Like we actually need to eBay and add the shit out of our play framework. And of course we have to build it with Gradle because maybe it's for losers and stuff. The good thing about this tendency is that there is framework for security, like there is for everything else in Java. So let's take one of them and look at what he does. Yeah, cool. I don't know Java. I'm working for Red Hat. This is actually painful to do that. Anyway, you don't know anything about Java, so I'm going to explain what this shit is doing. Please do. Well, actually it's quite appealing. Ouch. It brings an old stack of security pumbering into your application, basically giving you all the stuff you need to have like authorization, authorization, saying that this user is able to access this part of the resources and stuff like that. Yeah, but here you are talking about only your application. So if I think about an attack as admin or security guide, my first idea is demanding the middle attack. Well, the framework supports that. It comes with support for HHS and also ensure that your client is using HTTPS. Yeah, okay. So if we go directly on the front end, so for click checking. Also support for that. You can use this frame option. The same origin thing inside the framework to prevent you from that. Not an expert on this part. And for cross-scripting attacks. It also does that. It provides support for CRSF token, for instance. Yeah, okay. And now if I want my audit logs. Well, actually, wait, we need that. We mentioned earlier we need that. And actually it's also providing everything you need to have to do an audit log, an audit trade. So bottom line is that we listed a long series of threats that are going to be a menace, like a dungeon for your application. And you need, given the amount of stuff you have to face, you need a framework to help you cover all your bases. That being said, we are dealing with an internal app. So we are behind firewalls inside a very compacted VLAN. So we should be kind of safe, no? Yeah, but come on. Be serious, okay? So, you know, like most of the players, they are using laptops and desktop to access the app. So basically there's at least one which has a root access on it. So we can consider that it's unmanaged with a nice malware on it. Well, I have a good news for you. It's not even a laptop, it's tablet on mobile. So it's even better, you know. It's even less managed. Yeah, it's called bring your own device, which is also called bring your own disaster. So to sum up, in fact, so we have a bunch of users with completely unmanaged devices. And those devices all use the internet, which basically means that if somebody hacks your tablets, you're getting directly access to the internal app, the one hidden behind layer of firewall. You just one tiny hop from the internet. Yeah, but you said it. We have firewalls, come on. Well, yeah, so this is a misconception. Firewalls are not about security. Firewalls are about network quality services. That's what they're doing, actually. Yeah, you have to explain this to me. I'm a security, you know. So I love firewalls. Of course you should like, but it's not really helping you in this case because firewalls are designed to block ports, right? True. And generally, you're breaking port that are not used. True. So you need to use the port for the application. Yeah, okay. I can't close all ports, of course. Yeah, okay, so the application has to be reachable at the end. So the attack is going to follow the same path as the regular user, so you can block it. Yeah. That's the issue with firewall. Okay, so what should I do then? Well, the real trick here is to analyze and monitor the traffic itself on the content of it. For instance, if your application is supposed to send an email using SMTP, this is the only thing you should be ordering there, and it should be valid SMTP. So that's the thing. Side note, both of us used to be consultant. We used to be traveling around, like, to different customers. So we've seen a lot of, you know, companies with different security things, with different habits. And we used to grade how crappy the security is, but the number of port being closed. It's just nice when you want to access your mail, you know, to help your customer, and no mail forbidden. Bad. And, yeah, just for security reasons, you know, the VPN you need to access to your support, in fact, to support your customer, well, is also forbidden for good reasons. Yeah, that's very bad, because especially in my case, as a regular employee and consultant, if I go to a customer and contact my VPN, I can't do anything for you anyway. What I love is, in fact, the use case where, in fact, there's only one trusted user by the customer who has access via a stage to the machine, but not new. You are supposed to help him, but you don't have access to anything. So, generally, he goes in, he's logging in, and you piggyback on his access connection, and you connect to the system anyway, useless. Don't laugh, I've done that. We did it. And, well, so at the end, it's nice to block poor and so on, but it's mostly about illusion of security, okay? Exactly, we gave very strong illusion of security because everything is blocked, so everybody's work on delivery is shitty, but there is no real security. What is important here, joke spot, is so you keep an eye on the protocols and you filter the contents. So, generally, use that for this kind of stuff. Where are we now? In the notes? Yeah, yeah, so it's actually quite nice, because if you do filter the content, and if you do implement, you know, invalid request, on the other hand, as a Java developer, the amount of hacking you must be facing are far more reduced. You just need to face potential hack base on a regular behavior of your application. You're not going to get some kind of crazy URL with, like, buffer overflow or whatever because the reverse proxy is going to drop that. Yeah, okay, so let's go on another area of the application. Yeah, the application better, of course. Also, you have the data. In this case, we have no real business. It's just an old app, so there's no back, no real user, and it's not very interesting. So it's not about wire transfer or whatever. No value to hack and sell somewhere else. Yes, you won't be studying our money to put it on a dark web. This is an internal app. However, we do have, like, typical, you know, employee productivity data. So stuff such as employee address, phone number. Yeah, so what is called, in fact, personally identifier information. And by law, you have to take care of those. So also, you may have salaries, financial packages passing on the wire. So, of course, here you have to restrict access based on the user now. And there is always a bit of business in this kind of stuff. So you may have information about deal, opportunities. Yeah, this is confidential. So even if it's just a stupid app, we have to secure it. And by secure it means encrypting everything from one end to the other end. Yeah, so encryption. Okay, on the front-end side. So if you want to encrypt something, we have to encrypt first the communication. So it's SL and HTTPS. Exactly. So that's pretty easy. I think anybody here has ever, like, you know, deployed HTTPS or SSL on his own little engine hacks or Java web. It's like 10, 10 minutes to do this. Keeping it safe, keeping it, like, keep running a bit of that sort of work. It's heavy. It's massive, in fact, because it's an operation that you have to remember the most of the time. And you can do it only once a year. And if you fuck up, in fact, at the end, all your users would be kind of rejected by the security, of course. And I'm not even talking about a leak certificate, which is then still valid, but, well, you shouldn't use it. Yeah. So let's imagine right now that the infrastructure is correct and we have done that. Well, we're good, right? We have SSL in place. Yeah, nobody moved, and I, in fact, but SSL has been now. Yeah, you still have to keep up your knowledge. That's exactly the point, yeah. So we've deal with the front end. Let's look at the back end now. Well, before that. So now we also have to encrypt everything between the app and the databases because this could also be spied on by hacker. And that's actually complicated because databases are not very good with... No, yeah. So we have it by experience. With also MongoDB, for example, it's really hard to have and to maintain encryption of data. And in the case of MongoDB, well, the feature was missing for years. Yes, I remember that, actually, the first version of this talk, my co-worker Francois, my former co-worker Francois, had to basically implement that in MongoDB. So, or back port it in MongoDB. Anyway, let's say that we have secured this part. There is still one little detail. Database is running on a physical system on virtual as a one and it's throwing on the disk. Hacker can also access that. So we need to think about, do I need to encrypt my data on it? Well, of course, yes, come on. But by seeing that, I'm not solving the problem because encrypted everything is pretty heavy. It's expensive in terms of cost, well, money or performances. And encrypted everything, in fact, doesn't really help, especially when you select what you want to encrypt and it's not the good data. Yeah, so you may remember this story about Ashtam Edison last year. It's a perfect example of that. Basically, they didn't make anything by the book. They did encrypt the password, for instance. There was a hash of password, but they did not encrypt the name of the user, neither the email, neither the physical addresses. So you add everything you needed to blackmail people. People committed suicide because of this hack. Yeah, this can escalate pretty fast. That went dark, but yeah. So, one being that now we have encrypted everything, so we need still to access it. We need to have legitimate user access the application. How do we implement that? Yeah, well, we have to prove who they are and ensure who they are. So it's called strong authentication nowadays. Exactly. So the thing is that you cannot just use the same password. You need to have more, because Ashtam has password R. Yeah, LDAP, KBOS, it's not enough. So this is why you can't have the same password? And also because old passwords can be stolen. So anyway, you talk about something I call 2FA, I think. What is this thing? Yeah, so to factor out for authentication, so to identify someone, you have three factor of authentication. Who the user is. So it's a biological, well, a fingerprint, for example, what the user knows, like a password, or what the user has, which can be a mobile phone or a security token, for example. And 2FA is, well, you pick two out of three. Well, 2FA is definitely the best way right now to implement strong authentication, but it has a big issue with it. It's that people don't like to always put out their phone to take their token or have a token. Users generally fight it and company quite rightly. This is arming their productivity. Yeah, so if you want to have 2FA, you need definitely to have SSO, a single sign-on process. Otherwise, well, the user will be your enemy at the end. Yeah, so for instance, in Red Hat, I'm pretty lucky because when I'm logging in my email and I get access to the Wiki also, I don't need to re-log all the time. Not much, at least. Yeah, so what is really important is that the security is not an excuse for the user's experience. The good example here is, in fact, Slack, for example. Nowadays, we don't even need a password and it's still safe to log in. The user experience is just brilliant here. Okay, so let's go back to our app. We have it secure. We put every encryption everywhere. We are good, except that recently, if you pay attention, the scope of the battlefield for security has kind of extended because there is also a way to arm your app apart from actually expecting a defect. For instance, you can hack it at the source and hack your CI. Yeah, so the CI is also a very sensible system. In fact, it's a system which has a lot of power. For example, it has the right to download your dependencies. It has the right also to access production because when it is triggering a deployment, this is what it is doing and it is doing on something that it has built. So if CI is accessing production, CI's have your secrets, which means that you need to handle and manage your secret properly. This slide is difficult to read, but this guy committed password into his GitHub. So guess what happened? So that's complex. You need a tool for that. People are generally using something like Ansible Vault to do that. This is what we try to do, in fact. But the secret are not the only weakness in the end. Yes, because if you're doing things right, hopefully I wish for you, when you're building your app, your app is 95% not your code. It's dependencies fetching from everywhere. Especially if you're doing Java, you're going to fetch Apache command lines, Apache whatever, Wildfire Blast, Spring Boot Singly. And when you're fetching stuff from everywhere, it's from the internet. So you are basically implicitly trusting the internet there. So it's definitely not funny here, but you have to download carefully your dependency, you have to check what you're downloading, and just check the checksums. Okay, it helps. Exactly. So by the way, Red Hat has been pushing this model for years with Satellite, already with RPM. Way before we bought J-Bus, we were already pushing people to say like, have a repo, sign everything, know what you're handling. Yeah, you already focus on Red Hat, don't you? But at the end, manage your artifacts. They do pay my bill, you know. Okay, so application is built, CI is somehow safe, so now we have a nice little war. Let's run it, let's deploy it. Yeah, just tell me where. Yeah, I don't want to deal with this shit, I'm too old for that. I'm going to do what the cookies are doing, I'm going to go cloud native. So in fact, you don't trust the internet, but you trust someone else's computer. Well, I actually believe that cloud is safer than in-house server. Whoa, really? Well, if you're running the cloud, you do have to rebuild your images on a regular basis, you have to push new stuff, they're going to be crashed and removed, so you kind of have to keep it fresh. Yeah, okay, okay, that's true that we have some servers at home, and well, they're still not patched. Okay, so, okay, point again. Yeah, it's been 10 years, that is. Also, like, if you look at Netflix, for instance, Netflix has a very cool model, and if you access a movie this weekend, the VM you're going to run on is at worst two days old. At worst. Well, it's just nice, but even the problem is, even with a fresh system, sometimes, well, with zero days, the system is still sensible to it to attack. For example, Meldon hasn't been fixed for days, weeks. Yes, and this is bringing us to the very next point, and the most important point is that security is not about being, you know, patched and, you know, fresh. It's also new guys to be ready to fight an attack. Actively. So, let's take an example. Do you remember a few years ago when GitHub was attacked? GitHub faced a very strong distributed denial of services attack, like passing two years ago now, and they were very communicative about that. They were saying on Twitter, hey, we are under attack, so the site is off, we're doing that, we're doing that, we have to be able to blah, and they were very efficient about that, and that was very interesting to see that they were both, you know, able to patch the system, but also actively raised an attack, and they were very transparent also. Yeah, what is really important is that your business is not an excuse for not being transparent to your customers. So, hey, this is my turn. So, I'm working for a bank, which is a startup, and we have, even for a bank, we have a status page where we show the state of our system. We are transparent for our customers, so in case of storm, well, we hope they trust us a bit more. Yes, if you remember Equifax last year, this is a mess by hiding these leaks that we're having. For weeks, they didn't say anything, people were in danger, and they should have really much come forward and said, hey, we've been hacked, like, be safe about that. Yeah, they tried to run away from them responsibilities, and if they're in danger, way more invite them customers. They even hide details for fixing the breach. Yeah, so the point here is actually that it's not a question of are we going to be hacked, it's a question of when are you going to be hacked, and what you're going to do at this point. So, let's take the metaphor of fighter fighters, you know. Firefighters, for example, are always trained to fight, well, fire. So, in fact, you have to be trained to face an attack. Exactly, so basically your app is born to be hacked at some point, so you have to prepare for that. So, to go along with the firefighter analogy, if you want to protect the building against fire, you're going to first install, for instance, a smoke detector. Which, in IT sense, is more ideas, so intrusion detection or prevention system. You also need to have, like, fire doors to stop the fire to, you know, grow in the building. Yeah, and for your radar approach, it would be as a Linux. Yes, exactly, everybody's running with a Linux here. Yeah, and of course, we're doing Java, so you're all running with a security measure on, no? Wait, everybody's doing containers nowadays, and I'm sure they care about that second profile. Yeah, point taken. Anyway, it's time to wrap up and sum up what we've been hobbling for 20 minutes. So, last slide. So, yeah, I survived. You first. Yeah, so what is really important for our security is to keep in mind the big picture, to not lie to yourself, in fact. You have to analyze your risk, you know, to at least know where you are and where you stand, in fact, with your little application. And don't ever think you're safe. You can always be asked from somewhere. Yeah, VLANs and firewalls are just an excuse. Come on, no, there is no real defense. And your data isn't a feature. You have to encrypt what needs to be encrypted. This is a hard part. Yeah, and encryption means managing secrets and using strong notification. Which doesn't mean that, in fact, you have to forget usability to face security. There's no trade-offs here. Yes, and also don't forget that Battlefield has extended up to CI and cloud and other environment. So, you have to also take care, as part of your application, the continuous integration system, how you deliver code and how you deploy even in the cloud. So, basically, feel free to be ready to fight fire, in this case, and act, because you are going to be act. And that's it.