 Good afternoon, I'm Mikhail Adwani and my colleague Rajesh Tamhani, he could not be here today, he's traveling for work. The two of us, we've come up with this open-source project called AWS Security Test, and our talk is basically going to highlight how we have used this open-source tool to basically implement security in a DevOps manner in the AWS Cloud. A little bit around who we are, so Rajesh and I, both of us work for ThoughtWorks, out of the Pune office. Rajesh is a security analyst with close to 25 years of experience. I've been in the DevOps role for the past five years or so. So DevOps sec, just an introduction to the term, an elaboration of what we understand DevOps sec is. It's basically merge for us. I've experienced that many people have different definitions of the word DevOps, and every one of those definitions is correct in their own way. What we understand DevOps to be is the collaboration of the developers, the ops folks, and the security practitioners into a single team. Sorry. This to ensure that we deliver software as fast as possible in the most secure fashion. A few principles which we think very important, DevOps and security especially is everyone's responsibility. The decisions need to be taken together. The decisions, sorry, need to be taken at the correct time. We do not want to retrofit security. We want to think about security from the start. That's the entire principle of DevOps sec. So what we have done, I have had a decent amount of experience in cloud hosting and cloud migration projects, specifically with AWS. So what we came up was with a list of security recommendations that should be tested for and how they can be integrated in a CI CD pipeline. A few features that we considered important. So this we wanted to design irrespective of architecture. We did not care whether your architecture is serverless, is it container backed, or is it classic VMs. What we were looking at were features like identity and access management, monitoring, logging, networking. Novice users is something which we've come up with very recently. It's still a work in progress. So our tool hasn't really started incorporating features around accidental operations yet. But it's very well in the pipeline and hopefully should be released within the next couple of days. Sources for the security recommendations that we've automated. It's CIS AWS Foundation, CIS being the Center for Internet Security. AWS Best Security Practices, and yes, a lot of personal experience. Enough talk, I think I'll directly get to code. So this is an open source tool that we've come up with. It's hosted on GitHub. You can feel free to take a look at it. So what we are implementing as part of this automation suite is a bunch of configurable tests. As you can see here, I'll just zoom in a bit, sorry. Related to each of these features. Now all these features, some of them may be applicable to you, some of them may not. For example, one of the networking features that we're testing for is test RDP is not open from the internet. Now, if you're working in a complete Linux environment, testing for an RDP port access doesn't really make sense. So you can disable these tests. It's a completely configurable security test framework. You can feel free to focus, feel free to put in pull requests. We would be more than happy to merge it and add to the suite. What we have basically done, so I'm actually gonna try a quick demo here. So this is our CI here, this is our CD pipeline, it's a deployment. The deploy changes here are, these are dummy pipelines, they have just an echo statement behind them. But the test dev account, this is an actual functioning pipeline. This is what our value stream looks like. So any check-in into your infrastructure as code repo would trigger the deployment to your dev account. So all these security recommendations that we have implemented are at an account level. After all these changes, there would actually be a test run. So this particular test automation suite is not a preventive measure, it's a detection measure. And only if the deployment and the tests, the dev were successful, would the changes propagate to the higher environment? So what I'm gonna do right now here is, sorry, I think my terminal is not coming up for some reason. Sorry, screen issue. But basically what I wanted to highlight was, I was trying to demo. Is the only successful changes would be propagated. In case of a failure, what would actually happen is this kind of a situation. Where the deployment to the dev account was successful. But after the test failed, the changes did not get propagated higher to the QA environment. Now if our configurations and our code implementation is managed in a way that any changes being applied to a dev account only will identically replicate to the higher environments, to the higher accounts, would this work for you? And just the kind of security report that is generated out of this. We all love our reports. So yeah, this thing is a minified version of the report. Hence you can just see three tests that were executed. Sorry for the network latency. Yep. So this thing is our actual test execution. In this scenario, all the tests passed. And well, out here we had one failure. Where RDP was actually open from the internet. And hence we could not, hence the changes weren't propagated to the higher environment. What I'm going to try and do once again is get my terminal up, zoom in for you. So sorry for the logistics folks. So these are our pipelines. Right now you saw that the particular pipeline was read. The test was read. What I'm actually going to do is just, so I have a script which basically fixes the RDP issue. Yep, that's done. So in the real world scenario, yes, I would not be running a script on my machine. The script would be run as part of the CI process. And on changes being deployed to the dev account. So this thing should go green in a second. I'll just, let's just see how the code and our changes are actually propagating. So the deployment is complete. Now in this test run, we should even have the test being, test going successful. Yep, the test was successful. Just refresh the page. And the changes were propagated to the higher environment only once tests went green. So this implementation that we have carried out is using a CI tool. This is an open source CI tool produced by the company that I work for ThoughtWorks, GoCD. But this thing can very well be integrated with Jenkins, TeamCity, Bamboo, a CI of your choice. Yes, so that's all what I actually had to demo. How we would wire this in of course is not just based on CI. We would also run this in a timely manner because certain security recommendations that we have are very time specific. For example, the password rotation policies, the frequency of that. So that would be the other trigger for this particular test. And yes, sorry. So things like if you have implemented, say in the AWS world, if you have implemented your firewalls or security groups, if you're managing that via code, any changes to the security groups which you have committed, the deployment would actually apply those security groups to the AWS account by making a certain set of API calls. And after that, this test dev account would actually check that have you by mistake opened up SSH to the whole world or opened up IDP to the whole world, etc. Yes, so right now these are dummy scripts. These are dummy pipelines. They've just got an echo statement behind them. I've not really, because my point today was to highlight the test aspect of it, not really the code migration or code deployment. But yes, that's what this pipeline would have. Yes. So this thing is more like a security monkey rather than a nexus or a qualis. So nexus and a qualis operate more at the VM level, if my understanding is correct. Whereas this thing monitors your AWS account. So the services, as I mentioned, IAM. So what are your password policies for IAM? For your IAM users. Oh, sure. I mean, I wasn't aware of that. What kind of cloud watch monitoring you have? What kind of alarms you have based on the cloud watch monitoring? And the network security groups that I mentioned. Also one thing that we're looking for. So it's actually in dev right now. The novice users or accidental behavior, which I was mentioning, is things like setting off the accidental, prevention of accidental termination behavior. That flag should be enabled on all instances by default. If it's not applicable to you, feel free to disable it in your execution. But yes, we're putting it, we're trying to build an exhaustive list. This thing is purely for your AWS account. And from a cost perspective, it's extremely inexpensive. So I'm running this on my personal account. And what I end up paying is less than $2 a month. And my free tier has expired. Any more questions? Thank you. Just in case anybody wants to have a look at the GitHub link. Sorry.