WEBVTT 00:00:00.000 --> 00:00:01.885 Know that I'm standing in between, uh 00:00:02.523 --> 00:00:04.163 whatever, Wednesday night beer is 00:00:04.382 --> 00:00:04.632 or dinner, uh 99:59:59.999 --> 99:59:59.999 Actually this will be a pretty short talk 99:59:59.999 --> 99:59:59.999 but uh moreover I would like to hear from you, so... 99:59:59.999 --> 99:59:59.999 My name is Arseny. 99:59:59.999 --> 99:59:59.999 I uh I do not work for Dell 99:59:59.999 --> 99:59:59.999 haha by the way haha 99:59:59.999 --> 99:59:59.999 I do not work for Dell 99:59:59.999 --> 99:59:59.999 I'm a solution[s] architect and I've been working on some Monetary Authority of Singapore, uh 99:59:59.999 --> 99:59:59.999 Technology risk guidelines, before, like many years ago 99:59:59.999 --> 99:59:59.999 They were related to vmware, and I coauthored comparison 99:59:59.999 --> 99:59:59.999 to help the industry basically leverage the best practices 99:59:59.999 --> 99:59:59.999 and map, and if there's a regulatory requirement, how to answer it 99:59:59.999 --> 99:59:59.999 if there's a security team within a big financial organisation, giving you hard time, how to answer their question. 99:59:59.999 --> 99:59:59.999 so I basically want to do the same for containers for Docker 99:59:59.999 --> 99:59:59.999 I basically share the digest of open materials that I found 99:59:59.999 --> 99:59:59.999 around using Google search engine, 99:59:59.999 --> 99:59:59.999 but I really want to hear from you because I believe there's, uh, very different crowd today 99:59:59.999 --> 99:59:59.999 and I really wanted to hear what you do 99:59:59.999 --> 99:59:59.999 what do you do for security in your organisation 99:59:59.999 --> 99:59:59.999 To start with I'm not a security expert 99:59:59.999 --> 99:59:59.999 So don't worry, it's fine 99:59:59.999 --> 99:59:59.999 I'm not a security expert, have never been it 99:59:59.999 --> 99:59:59.999 And I don't want to boil the ocean 99:59:59.999 --> 99:59:59.999 It's really not something I will be able to do in 20 minutes 99:59:59.999 --> 99:59:59.999 So forget about it 99:59:59.999 --> 99:59:59.999 So 2 questions: 99:59:59.999 --> 99:59:59.999 Who has in their production environment today any test-driven security pipelines? 99:59:59.999 --> 99:59:59.999 anyone does test-driven security approaches today? 99:59:59.999 --> 99:59:59.999 Cool 99:59:59.999 --> 99:59:59.999 Who has, ok before even going to SAT, this acronym from financial markets 99:59:59.999 --> 99:59:59.999 Who works for insurance of some regulated enterprise 99:59:59.999 --> 99:59:59.999 That runs Docker in production? 99:59:59.999 --> 99:59:59.999 1...2...ok 99:59:59.999 --> 99:59:59.999 Got it 99:59:59.999 --> 99:59:59.999 That's good for me, because I cannot screw up 99:59:59.999 --> 99:59:59.999 that significantly because everything I do is just assuming my experience and what not 99:59:59.999 --> 99:59:59.999 So, uh, I wanna just start with a problem statment 99:59:59.999 --> 99:59:59.999 Remember the good old days we had very clear demarcation line between 99:59:59.999 --> 99:59:59.999 where the developers are and where the the operations people are 99:59:59.999 --> 99:59:59.999 The dependencies in here, this is where the gray line is starting to appear with containerisation 99:59:59.999 --> 99:59:59.999 So, who actually keeps an eye on all the dependencies for the containers? 99:59:59.999 --> 99:59:59.999 Within the container you may have a particular version of Python, with in the container, running on the same host you may have, like, uh, [inaudible] of other dependencies 99:59:59.999 --> 99:59:59.999 So, who has to work on that? 99:59:59.999 --> 99:59:59.999 So, in ideal containerised world, it looks like that, you have an application and it has all the prerequisites, all the dependencies installed and everything 99:59:59.999 --> 99:59:59.999 is beautiful 99:59:59.999 --> 99:59:59.999 but then, all of a sudden, your guys call you and they say: 99:59:59.999 --> 99:59:59.999 hey, AC, we forgot we actually have a better release 99:59:59.999 --> 99:59:59.999 we just migrated into Java, we wanna migrate into Java, can you just make sure that the image we are building on 99:59:59.999 --> 99:59:59.999 the production security image is right now running on Java, no longer need all these dependencies 99:59:59.999 --> 99:59:59.999 We need it like in 5 minutes 99:59:59.999 --> 99:59:59.999 Well, it's DevOps world, you do is what you do 99:59:59.999 --> 99:59:59.999 you install the needed prerequisites, update the image of the container 99:59:59.999 --> 99:59:59.999 send it back to the rebuild pipeline, everything works, fine, nothing breaks 99:59:59.999 --> 99:59:59.999 But then they wake up and they say, like, oh by the way, we needed Java 8, we forgot 99:59:59.999 --> 99:59:59.999 It actually is optimised for Java 8, can you do the same but for Java 8? 99:59:59.999 --> 99:59:59.999 And you do that and in the end, the risk is with all these images 99:59:59.999 --> 99:59:59.999 You end up with enormous amount of, uh, configuration drift. 99:59:59.999 --> 99:59:59.999 So you may have, like, ports open and something listening on those ports, and 99:59:59.999 --> 99:59:59.999 maybe not even patched through the proper levels 99:59:59.999 --> 99:59:59.999 And this is how configuration drift had looked like for that particular image 99:59:59.999 --> 99:59:59.999 It on [inaudible].io and there are, like, nginx, image that has been open and downloaded like thousand times 99:59:59.999 --> 99:59:59.999 they send it... and it has been used in multiple projects as you can imagine 99:59:59.999 --> 99:59:59.999 across, uh, the universe, across the internet, and they were like 99:59:59.999 --> 99:59:59.999 264 medium level vulnerabilities, 126 high-level vulnerabilities, 99:59:59.999 --> 99:59:59.999 it's just because everyone just patched it a little bit, 99:59:59.999 --> 99:59:59.999 patched it a little bit there, update the image and the latest became this huge drift 99:59:59.999 --> 99:59:59.999 from, like, where it should have been. 99:59:59.999 --> 99:59:59.999 Right? So... 99:59:59.999 --> 99:59:59.999 And actually this a very interesting fly that I found 99:59:59.999 --> 99:59:59.999 Look at this, information security job postings, they kinda tend to go down... 99:59:59.999 --> 99:59:59.999 And then all these jobs, they kinda tend to go up! 99:59:59.999 --> 99:59:59.999 So, the problem, I guess, will be signified in future 99:59:59.999 --> 99:59:59.999 So if we look at the DevOps factory 99:59:59.999 --> 99:59:59.999 I'll try to put it in here 99:59:59.999 --> 99:59:59.999 This is the usual process, it's a mixed like logical and process stateful diagram interchange that leads from development of a particular business requirement from business partners and business analysists 99:59:59.999 --> 99:59:59.999 And all the way into production that's on the operating side and the greens side 99:59:59.999 --> 99:59:59.999 Do you see anything on this diagram, related to security at all? 99:59:59.999 --> 99:59:59.999 This is DockerCon, this is, uh, 2017, it's actually from the keynote of DockerCon 2017 from Metlife, from their presentation. 99:59:59.999 --> 99:59:59.999 So couple of months ago, nothing here says about security. 99:59:59.999 --> 99:59:59.999 It does mention, ok, we have a CI/CD tool, and magically we do push/pull tag and image scanning, no details. 99:59:59.999 --> 99:59:59.999 So I guess this is the area where need to at least put a bookmark for ourselves, well we need to research it 99:59:59.999 --> 99:59:59.999 Because, like, not too much of material or best practices are currently in easily digestable format 99:59:59.999 --> 99:59:59.999 How to do that stuff... 99:59:59.999 --> 99:59:59.999 I actually included one marketing slide later... 99:59:59.999 --> 99:59:59.999 But again, it doesn't actually give you all the best practices how to actually do stuff. 99:59:59.999 --> 99:59:59.999 So the new reality is. There's a new term, DevSecOp -- developer security operations. 99:59:59.999 --> 99:59:59.999 The new reality is we have a completely decentralised ownership of deployment, so we need to get as early concerned about security as we can 99:59:59.999 --> 99:59:59.999 We should narrow it down to an easily digestable tasks all the way through the pipeline, 99:59:59.999 --> 99:59:59.999 and make sure there's no configuration drift in the image for example 99:59:59.999 --> 99:59:59.999 and make sure that the injection points are designed together with the developer, so they understand the concerns 99:59:59.999 --> 99:59:59.999 So they don't come and rush it to you and ask to give them Java 8 99:59:59.999 --> 99:59:59.999 And then, provoke this configuration drift and hence give you a lot og vulnerabilities. 99:59:59.999 --> 99:59:59.999 At a 1-1 level, how secure is Docker? 99:59:59.999 --> 99:59:59.999 And is it the kind of conversation that we may have with the security guys just over coffee in a big firm? 99:59:59.999 --> 99:59:59.999 Or in a Starbucks, if you see someone? 99:59:59.999 --> 99:59:59.999 I went into CVE details and opened up what the current open Docker vulnerabilities. 99:59:59.999 --> 99:59:59.999 So, for, vendor called Docker, there are currently 14 vulenrabilities 99:59:59.999 --> 99:59:59.999 Some still pending from 2016, not yet patched, it's not too bad actually. 99:59:59.999 --> 99:59:59.999 14 CVE's, eh! 99:59:59.999 --> 99:59:59.999 Just to give you an anchor point, what is kubernetes, kubernetes actually has 3. 99:59:59.999 --> 99:59:59.999 So, there are 3 vulnerabilities currently known to the global population of our planet that are related to Kubernetes. 99:59:59.999 --> 99:59:59.999 And to give you another anchor point, our favourite product, ESXi, from the very old days, currently has 31 vulnerabilities. 99:59:59.999 --> 99:59:59.999 So, answer is, it's quite secure, just by nature. Docker and Kubernetes are well-built, they are not really vulnerable as they are. 99:59:59.999 --> 99:59:59.999 How about running in the cloud? 99:59:59.999 --> 99:59:59.999 There's a report, and again I'll share all the materials and digest of the links with you, when you run deployment template for cloud formation that Docker provides with Docker Cloud, 99:59:59.999 --> 99:59:59.999 There are 5 total issues, and 2 of them are low-risk. Basically, they are over-provisioning cloud formation IAM roles. 99:59:59.999 --> 99:59:59.999 Just with little bit too much of permissions than needed. 99:59:59.999 --> 99:59:59.999 I would say, brilliant, actually, 99:59:59.999 --> 99:59:59.999 Same for Azure, there was an independent research that has gone through... recently this research was published, there are only 3 issues that are related to rolling out Docker on top of Azure. 99:59:59.999 --> 99:59:59.999 Bear in mind, our issues again, related to more of like, preferences rather than the problem. 99:59:59.999 --> 99:59:59.999 Now, what has to happen, we used to run app, and again I apologies, it's just the digest of multiple different slides, right? 99:59:59.999 --> 99:59:59.999 We used to run apps through the development into the user acceptance testing and then we would've sent them to the security acceptance tests, which are mandatory part of the DevOps in the old, legacy world. 99:59:59.999 --> 99:59:59.999 So, in a bank for example, security acceptance team would take, like, couple of days, then they will call you and they say "Dude, this is not working, we are not passing the scan..." this used to be, like, a waterfall approach. 99:59:59.999 --> 99:59:59.999 Now, they looked for everything, so security acceptance team would've scrutinised all the code that you push into production, they would've gone and checked every particular source code as well, crawled it for customer data, crawled it for some stored credentials, what not. 99:59:59.999 --> 99:59:59.999 They were acceptable, when we did not have to do releases 5 times and hour. So it's not really what we can do these days 99:59:59.999 --> 99:59:59.999 with DevOps, so the new analysis for vulnerabilities, the new analysis for security has to be bottoms-up one. 99:59:59.999 --> 99:59:59.999 We need to identify the specific classes per application, what are the most likely vulnerable areas in this app, or in this microservice on in this microservice, 99:59:59.999 --> 99:59:59.999 and we need to only care about just those, and we need to push it as heavily into the elimination of these problems early, before they actually hit any particular last-minute security tests 99:59:59.999 --> 99:59:59.999 we need to push for that in the development pipeline as much as we can, 99:59:59.999 --> 99:59:59.999 and that would actually support the only way to support, this would be the only way to support the velocity of security 99:59:59.999 --> 99:59:59.999 Some tidbits, there are really good security best practices published by Docker themselves 99:59:59.999 --> 99:59:59.999 They talk about the usual things, usual things, then I'm saying usual things, the things that regulator, the things that your security officer will care about. 99:59:59.999 --> 99:59:59.999 Centralised logging -- yes! 99:59:59.999 --> 99:59:59.999 [inaudible] reference architecture -- yes, please do something with CloudWatch, 99:59:59.999 --> 99:59:59.999 Lot of cloud deployment in the AWS, please use CloudTrail for the API traces as well, in GCP everything is centralised quite differently with StackDriver 99:59:59.999 --> 99:59:59.999 Do the signing of the content if you use a repository, there's a service within Docker, it's called Notary that allows you to create a hashed, some kind of like, snapshots of the code 99:59:59.999 --> 99:59:59.999 of a particular revision, so that there's no tempering, there's no man-in-the-middle substitution 99:59:59.999 --> 99:59:59.999 All these best practices are covered, there's special very nice document out there. 99:59:59.999 --> 99:59:59.999 Now, there's also for the host itself, that runs Docker, and that is something that could be incorporated into the security practices within your firm 99:59:59.999 --> 99:59:59.999 There's an audit tool, that kindof comes as a part of the intrusion prevention scanner, 99:59:59.999 --> 99:59:59.999 So you run a small container on the worker node itself 99:59:59.999 --> 99:59:59.999 And as you can see, it maps into the /var/runs and etc 99:59:59.999 --> 99:59:59.999 And pull the usual Linux sockets and figures out, are they configured the host underneath, running the containers? 99:59:59.999 --> 99:59:59.999 Are they configured as per the best practices against the known, latest vulnerabilities. 99:59:59.999 --> 99:59:59.999 This is part of Docker, this is a audit tool, you run it as one command line, and it produces a report like this. 99:59:59.999 --> 99:59:59.999 Is your Docker current? 99:59:59.999 --> 99:59:59.999 Is the Docker audit files are in place? 99:59:59.999 --> 99:59:59.999 Are you logging into right folders? 99:59:59.999 --> 99:59:59.999 Do you do proper logging level, is it like, only exceptional or everything that you do? 99:59:59.999 --> 99:59:59.999 etc, etc, etc 99:59:59.999 --> 99:59:59.999 now, there's also a separate, and again, I seek your input, maybe you can try [inaudible] more tools around it 99:59:59.999 --> 99:59:59.999 there's a separate project that could do pretty much the same thing, but both on-prem and in the cloud 99:59:59.999 --> 99:59:59.999 And it's called Clair, it's developed by CoreOS team 99:59:59.999 --> 99:59:59.999 What it does is, it also pulls the vulnerability updates into a small data store, and then also runs it per layer analysis of your Docker image 99:59:59.999 --> 99:59:59.999 if you actually run it on your version N-2 it takes like an hour, 99:59:59.999 --> 99:59:59.999 but since you've done it on layer, that was N-2, on the N-1, it would only scan for the incremental changes on that layer, so you don't have to redo the entire docker scan, you actually significantly reduce the time 99:59:59.999 --> 99:59:59.999 for the vulnerabilities scan, unless there's something not neat 99:59:59.999 --> 99:59:59.999 take a look at this Clair tool, it's incorporated into [inaudible] providers 99:59:59.999 --> 99:59:59.999 Security artefacts, this is a pain point, but I mean, you probably heard about ransomware for MongoDB... 99:59:59.999 --> 99:59:59.999 That recently hit the entire planet? 99:59:59.999 --> 99:59:59.999 People did not at all set passwords, 99:59:59.999 --> 99:59:59.999 but the other problem is, when you set passwords, you hardcode them 99:59:59.999 --> 99:59:59.999 so the best practice is to avoid hardcoding and to pass the credentials, pass the security artefacts through environmental variables 99:59:59.999 --> 99:59:59.999 and you do that for example, by setting -e variable, that is then available for you app to pull 99:59:59.999 --> 99:59:59.999 so you literally pass something into the container from the outer world when you run it 99:59:59.999 --> 99:59:59.999 and then you take it and use it, that is a very simple best practice 99:59:59.999 --> 99:59:59.999 but for some reason, people, especially developing guys, they tend to forget when they push apps and there are so many bitcoins that are paid to ransom, 99:59:59.999 --> 99:59:59.999 because someone then commits the code the public github and it's all there 99:59:59.999 --> 99:59:59.999 when I've been looking at a lot of resources, there are like, some, attack vector analyses, it takes like 15 minutes to completely block 99:59:59.999 --> 99:59:59.999 especially through Jenkins, I have a slide on that 99:59:59.999 --> 99:59:59.999 it's insane, Jenkins allows you to crack it through the console, if it's really password-protected well 99:59:59.999 --> 99:59:59.999 Anyhow, please pass them through environmental variables, you can also, if you are using AWS, EC2 container service, you can pass them in the cloud formation template 99:59:59.999 --> 99:59:59.999 define them, and use the cloud formation script to retrieve it from some secure vault or from other source 99:59:59.999 --> 99:59:59.999 into the cloud formation, so even your cloud formation template that then builds a lot of docker containers on AWS, will not have it hard-coded 99:59:59.999 --> 99:59:59.999 you just script around getting it from some other location 99:59:59.999 --> 99:59:59.999 and you could retrieve it from the metadata of the instance, if you are running on EC2 or Google Cloud, you can just curl into the instance metadata from within the app, at the bootstrap 99:59:59.999 --> 99:59:59.999 and then retrieve the tokens that you need to access other services 99:59:59.999 --> 99:59:59.999 Another tip: previous speaker had it on one of their slides, there's a very interesting startup called cilium, does an additional layer of tapping into the network at the packet level 99:59:59.999 --> 99:59:59.999 they insert themselves before the virtualised adaptors of Docker, add themselves almost like a kernel module, they allow packet filtering to the container blade running on the worker node defined in BPF format 99:59:59.999 --> 99:59:59.999 BFP system is already adopted by Docker, for example, they allow and deny particular syscalls, so form within the Docker container, by default there are some syscalls that you cannot run at all 99:59:59.999 --> 99:59:59.999 There are 44 banned syscalls, you cannot run mount or process trace, you cannot reboot the worker node from within the container 99:59:59.999 --> 99:59:59.999 They already use the BPF framework in Docker itself, but then there is this cilium company, and this is their process architecture 99:59:59.999 --> 99:59:59.999 that allows you to do packet filtering even at L7 on the path level do very complex rules to kill the packets, to deny access, to deny traffic to particular application 99:59:59.999 --> 99:59:59.999 It's running as an agent on a Docker node, they also have a project, they insert themselves in Kubernetes kublet, and they have monitoring and CLI special hooks 99:59:59.999 --> 99:59:59.999 they configure almost like iptables routing, sorry, iptables filtering on the packet level, and again it's very low-latency, it inserts itself at the kernel level 99:59:59.999 --> 99:59:59.999 Very interesting, quite sophisticate startup, there's a very good session about it, about an hour long 99:59:59.999 --> 99:59:59.999 The marketing slides from Docker 99:59:59.999 --> 99:59:59.999 Docker promotes... anyone from Docker here? 99:59:59.999 --> 99:59:59.999 There's none from Dell... none from Docker... 99:59:59.999 --> 99:59:59.999 The guy from Puppet left... 99:59:59.999 --> 99:59:59.999 No vendors? 99:59:59.999 --> 99:59:59.999 This is the marketing slide we discussed, it looks like everything is running out of the box, I cannot, I'm not a user of the enterprise edition of Docker... 99:59:59.999 --> 99:59:59.999 But they really made significant effort to add aspects like RBAC, trusted registry, your on-site completely secured key manages source for container images 99:59:59.999 --> 99:59:59.999 That avoid MITM attacks substituting your app's code 99:59:59.999 --> 99:59:59.999 There's a lot of effort put in place, to just run compliance requirements out of the box with Docker Enterprise Edition 99:59:59.999 --> 99:59:59.999 You can basically label a particular container or control group and allow some particular users that are LDAP authenticated, not just the local user 99:59:59.999 --> 99:59:59.999 that runs user, but particular LDAP user to do some actions against control groups of containers 99:59:59.999 --> 99:59:59.999 or hosts themselves, so it's very definable 99:59:59.999 --> 99:59:59.999 Nothing like that actually in Kubernetes, there are similar things in the cloud, but again not as granular. 99:59:59.999 --> 99:59:59.999 The best practices of hardening Linux containers, reducing your attack surfaces, very simple, right? 99:59:59.999 --> 99:59:59.999 Remember the configuration drift story that we started with... 99:59:59.999 --> 99:59:59.999 Lots of ports that who knows what they are doing there 99:59:59.999 --> 99:59:59.999 I tend to isolate not only as on the development, staging, user-acceptance and production, but also on the risk, so try to containerise 99:59:59.999 --> 99:59:59.999 this is best practice, if anyone worked at a bank, there are business criticalities, so you have to go like, BC5 to top-most one, like, do-or-die go fix it, to BC1, like, ok, let's leave it, if it's down for one week, none will care about it 99:59:59.999 --> 99:59:59.999 Do this on the risk, do this on the exposure, and then try to scrutinise the security one by one 99:59:59.999 --> 99:59:59.999 Create like a structured tree of decisions, what's my most business critical, what are the exposures? what are the attack vectors? 99:59:59.999 --> 99:59:59.999 Apply and enable all security-relevant configuration options 99:59:59.999 --> 99:59:59.999 if you already pay for Docker enterprise edition, or if you already have something enabled by default when you install it, do not temper with it 99:59:59.999 --> 99:59:59.999 Keep everything up to date 99:59:59.999 --> 99:59:59.999 Like the gentleman from Puppet 99:59:59.999 --> 99:59:59.999 Regularly test security recommendations 1~4 99:59:59.999 --> 99:59:59.999 Everything you do, put an Outlook calnedar 99:59:59.999 --> 99:59:59.999 It's absolutely normal to do, put an Outlook calendar reminder once in 2 months, just go and sanity-check, did we change anything? Did we miss anything? 99:59:59.999 --> 99:59:59.999 Remember, complexity breeds insecurity 99:59:59.999 --> 99:59:59.999 The more complex, the more sophisticated set of scripts are, the more the probability that there will be something hardcoded or something that your dev team will inherit from you 99:59:59.999 --> 99:59:59.999 and it will breed the attack vector exposure 99:59:59.999 --> 99:59:59.999 Two very cool talks that I've seen: 99:59:59.999 --> 99:59:59.999 One was on Enigma, and it's been from a guy who works for Mozilla 99:59:59.999 --> 99:59:59.999 And they push a lot of releases, it's pretty much weekly stable 99:59:59.999 --> 99:59:59.999 Of course they use the pipeline, they define the baseline for their security, what should be our central, focal point for every release 99:59:59.999 --> 99:59:59.999 If they do add-ons, it's much more effort to control add-ons to Firefox, because it's a community thing 99:59:59.999 --> 99:59:59.999 Developer submits an add-on, you have to still go through the same pipeline, because it's part of the dependency release for the core browser 99:59:59.999 --> 99:59:59.999 They write tests and they insert them into the CI/CD pipeline 99:59:59.999 --> 99:59:59.999 the security baseline for them, for Mozilla browser, is something like that 99:59:59.999 --> 99:59:59.999 They define scores, what would be the build score for Jenkins to use 99:59:59.999 --> 99:59:59.999 They need to pass some may-fail, some have-to-pass, they define the baseline, 99:59:59.999 --> 99:59:59.999 They write tests using ZAP, I think it's Zed Attack Proxy 99:59:59.999 --> 99:59:59.999 One of their focal points is ZAP, and ZAP has integration plugin for Jenkins 99:59:59.999 --> 99:59:59.999 It's been released not too far ago 99:59:59.999 --> 99:59:59.999 It's already been, it's quite aggressively, there are only 15 installs 99:59:59.999 --> 99:59:59.999 They had a separate plugin for Jenkins and then they moved to the completely new project on Jenkins plugins 99:59:59.999 --> 99:59:59.999 It's now currently being used about 400 installs in the world, which is not bad for security 99:59:59.999 --> 99:59:59.999 The idea behind it is that you are able to define a ZAP scan, 99:59:59.999 --> 99:59:59.999 I'm not sure if I have a slide on it 99:59:59.999 --> 99:59:59.999 The idea is here -- you can define a site, is it gonna be like all headers scan, let's try to exploit all possible web server vulnerabilities 99:59:59.999 --> 99:59:59.999 Let's crunch it with a lot of header-related blocks and see whether it crashes or not 99:59:59.999 --> 99:59:59.999 Some client sessions, you can test you particular app from different paths 99:59:59.999 --> 99:59:59.999 It orchestrates your HTTP or HTTPS scans, and it can simulate a total attack on conventional web servers 99:59:59.999 --> 99:59:59.999 After that they just hook it into the pipeline of Jenkins, and as you see the scan takes about like 30 seconds 99:59:59.999 --> 99:59:59.999 So it's not a really long scan, if you run it on a beefed-up container 99:59:59.999 --> 99:59:59.999 and it's a container itself, it only takes like half a minute in the entire build process 99:59:59.999 --> 99:59:59.999 There's a big set of different libraries that you can tie into the Jenkins testing, they would test different servers, e.g. node.js, rails, retire.js 99:59:59.999 --> 99:59:59.999 All these projects are there for you to test your app on your preferred IDE 99:59:59.999 --> 99:59:59.999 Test it against the known, current vulnerabilities, there's a full list of it. 99:59:59.999 --> 99:59:59.999 If you google for "awesome devsecops" you'll be able to find this list 99:59:59.999 --> 99:59:59.999 Once you've created the criticality, the risk to your applications, start with the threat modelling, like, is data going to be in the wrong hands? 99:59:59.999 --> 99:59:59.999 Or is going to be an accidental compromise or a brute-force attack? 99:59:59.999 --> 99:59:59.999 Then based on this logic, expand it, if it's going to be a human failure, like someone lost their laptop, 99:59:59.999 --> 99:59:59.999 Losing a laptop has special attention in here 99:59:59.999 --> 99:59:59.999 Remember this magic ~/. ? 99:59:59.999 --> 99:59:59.999 Do not lose laptops, or use encryption of the SSD 99:59:59.999 --> 99:59:59.999 If you lose the laptop, there could be a lot of things in your ~ 99:59:59.999 --> 99:59:59.999 Focus on code, as early as possible, ensure that not MD5, but SHA-256 is used 99:59:59.999 --> 99:59:59.999 Ensure that code repositories are private, not public, especially if you hard-code security artefacts into it 99:59:59.999 --> 99:59:59.999 Make sure that the orchestration involves all the testing we've discussed 99:59:59.999 --> 99:59:59.999 there are many other cool things that I wanted to share 99:59:59.999 --> 99:59:59.999 this is something that I've tried today -- 3pm today, on showdone, I've looked at ex-hudson response HTTP 99:59:59.999 --> 99:59:59.999 and I came up with 5 Jenkins that are completely unprotected with password 99:59:59.999 --> 99:59:59.999 Like, totally! 99:59:59.999 --> 99:59:59.999 I've logged into one of them, and it runs on AWS 99:59:59.999 --> 99:59:59.999 Guys actually run it in production, there was like Arun Kumar daily 99:59:59.999 --> 99:59:59.999 I've looked him up on LinkedIn, he's actually working for TATA consultancy 99:59:59.999 --> 99:59:59.999 I never thought it would be that easy! 99:59:59.999 --> 99:59:59.999 Please make sure, all these aspects are reviewed at least twice a year 99:59:59.999 --> 99:59:59.999 Or every 2 months, return and sanity-check what's the security exposure 99:59:59.999 --> 99:59:59.999 Employees, who loves gist? 99:59:59.999 --> 99:59:59.999 Make sure at least it's not Google-crawlable, ok? 99:59:59.999 --> 99:59:59.999 Slack tokens are there, AWS creds as we discussed... 99:59:59.999 --> 99:59:59.999 One good advice -- Jenkins has to be segmented, if you run it on AWS, it has to be in network ACL, it has to be segmented to only allow access from the known set of hosts 99:59:59.999 --> 99:59:59.999 The core take-away form the Jay Kumar example 99:59:59.999 --> 99:59:59.999 Everything should be all-across authenticated 99:59:59.999 --> 99:59:59.999 I'll file it up in terms of links and everything, short link is bit.ly/sg-docket-security 99:59:59.999 --> 99:59:59.999 I spent about 15~20 hours watching these videos and going through these PDFs, a lot of cool material, reach out to me on LinkedIn, if you have any ideas, I'll be happy to learn from you! 99:59:59.999 --> 99:59:59.999 That's a big area, we are not experts, let's move on together! 99:59:59.999 --> 99:59:59.999 There's a devsecops group in Singapore... 99:59:59.999 --> 99:59:59.999 Also did a conference in Feb 99:59:59.999 --> 99:59:59.999 Am I in the wrong room? 99:59:59.999 --> 99:59:59.999 It's a way I structure my thoughts 99:59:59.999 --> 99:59:59.999 Any questions? 99:59:59.999 --> 99:59:59.999 [inaudible] 99:59:59.999 --> 99:59:59.999 vulnez.com 99:59:59.999 --> 99:59:59.999 website looks brilliant 99:59:59.999 --> 99:59:59.999 [inaudible] 99:59:59.999 --> 99:59:59.999 they have an API 99:59:59.999 --> 99:59:59.999 Outlook notification doesn't scale 99:59:59.999 --> 99:59:59.999 Scan packages... 99:59:59.999 --> 99:59:59.999 Let me correct myself, once is 2 months is reviewing the process 99:59:59.999 --> 99:59:59.999 not really checking it once in 2 month, that has to be every build 99:59:59.999 --> 99:59:59.999 vulnhub 99:59:59.999 --> 99:59:59.999 Thanks for that, and the 2nd one you proposed is SourceClear, right? 99:59:59.999 --> 99:59:59.999 Thanks for these 99:59:59.999 --> 99:59:59.999 What's the name of the project? 99:59:59.999 --> 99:59:59.999 black duck 99:59:59.999 --> 99:59:59.999 What sort of applications, what sort of language do you use it for? 99:59:59.999 --> 99:59:59.999 Java, allright 99:59:59.999 --> 99:59:59.999 I love it 99:59:59.999 --> 99:59:59.999 There's twistlock 99:59:59.999 --> 99:59:59.999 Are these, these companies are more likely to be startups, they are not long-term? 99:59:59.999 --> 99:59:59.999 Twistlock and Aqua 99:59:59.999 --> 99:59:59.999 All these websites they are brilliant 99:59:59.999 --> 99:59:59.999 Any other questions? 99:59:59.999 --> 99:59:59.999 Thank you!