 Welcome to the third session of the day. The next session is Leverage Ansible Security Automation in DevSecOps by Sumit Jayaswal. We are starting with the next session. Allow me with a minute. Apology, I'll just restart. Give me a minute for the Ansible Business Unit, and thanks for joining this session. In this talk, we are going to cover how Ansible Security Automation can help Dev and SecOps teams. Let's have a look at what we're going to discuss today. Firstly, I'm going to share what Ansible Security Automation is and how it can help security teams. Sumit Jayaswal is then going to provide some real-world use cases and examples of how Ansible Security Automation can integrate with IDPS systems, with firewalls, and with CFs. Let's get started. What is Ansible Security Automation? Well, before I get there, I'd like to share some analysis of what's happening in the market. God that predicts that this year, 2021, the spend on cybersecurity is going to surpass $150 billion. But counter-intuitively, if we look at what we are seeing in the headlines of all the increased cyber attacks and the increased cyber breaches, this doesn't make a lot of sense. Well, the Cyber Resiliency Organization provided a report which has some great insight that I'd like to share with you. Of all the alerts that security teams are getting, they're only able to respond to 5% of this. And the predominant reason for this is because between a mid-sized organization and a large-sized organization, they'll have between 20 and 40 security devices that they need to protect their organization with. However, they go from different vendors and they perform different tasks. They're all provided alerts in a very specific way. So it's very impossible to get all these alerts to address all of the alerts. Also, counter-intuitively, again, the amount of time it takes for security teams to respond to a cyber incident has increased. But if all that money has been put and invested in it, why is this occurring? There's several reasons for it. The first and predominant reason is the severity of the cyber attacks has increased, as well as the throughput and volume of the cyber attacks has significantly increased these days, especially taking for the fact that our working circumstances have changed. Also, if we look at how security teams look off the traditional data center and because of the lack of integration between the different security tools, there's a lot of manual tasks. But organizations are expanding. They're looking at including cloud computing models. They're trying to create microservices architectures and move to a cloud-native environmental practices. These manual tasks that security practitioners use because of the lack of integration is just not going to scale and be agile enough to keep up with that. There's also a large need for more skills within the security space. Companies are extremely willing to pay for it and extremely willing to hire. There's just a lack of those skills. On average, they say, if there's 100 developers within an organization, there's usually 10 people in the operations team. And for the 10 people in the operations team, there's going to be one person who's trying to look after this and secure all of this. They are overwhelmed and inundated. I've mentioned that the severity of the cyber tax has increased. And this is because the actors who are writing this malicious code and actually performing the attacks have embraced ideas and products and methodologies such as AI and machine learning and automation where security teams now traditionally are still relying on a lot of manual tasks. Let's imagine we're a security practitioner and we're just even trying to investigate if the threat is malicious. Well, that person, we would have to log into maybe five different user interfaces. We would have to go and manually input the same data again. It's error-prote. Human error is a real factor. Thankfully, the organization and the security ecosystem realize that automation is going to be vital for security teams to be able to keep up with the new demands. This is where Ansible security automation comes into the picture. We have had as Ansible a tremendous success within the infrastructure space, within the networking space and the app space to name a few. Ansible security automation expands that portfolio and that success to now include the security space. It's important though to mention firstly that we are not a security product ourselves. We are only there to be that conduit, to be that integration layer between these multiple vendors and multiple security tools. We augment them. We provide the security teams the capabilities, the tools, the integration to ensure that if there is indeed a cyber attack, right, they are able to create and mount an effective response a lot quicker. We also integrate with the different teams with security for sure, but we elevate that automation so when security teams do have the automation in place, they can now share this with the rest of the organization and form part of an effective remediation plan. Adopting automation in security is a journey and from what we've seen in the market, we see there's three main parts to it. Systematic is when a practitioner or a team are just looking to automate one task. They want to do it with more speed and they want to do it with more consistency. Here, the human readable YAML language that Ansible provides is vital to this. It makes it easy for them to do so. Moving up as they move to the systematic layer, this is where the security teams now want to be able to share their automation beyond their domain to other domains within the IT organization or the security practice. This is where automation controller, formerly known as Ansible Tower, provides role-based access control, APIs, credential management, just to name a few to help them do this. At this stage, we also see security tools such as a security information and events management system or a CEM. And what those tools do is they provide alerts and aggregates all the logs to provide analysts the capability of identifying and classifying security threats. Ansible automation platform and Ansible security automation has integration to supported CEMs, which opens up a new avenue for analysts. Usually, if they had to increase the verbosity of a log, as an example, they would have to reach out to their team. However, in a safe, controlled and consistent manner, they are able to actually directly start changing the verbosity of a log on a specific device, reducing a lot of the operational overhead. Moving to institutionalized, these organizations have a mature security posture. They have an effective remediation plan in place. Their compliance, their auditing, their regulation requirements are all met. At this stage, you'll see tools such as a security orchestration and automated response platform or a SOAR. And a SOAR gives the organization the capability of mapping and creating business processes and mapping it to a security remediation plan or a compliance plan, et cetera. And what we can do as Ansible. And once again, just to say we are not there to compete, we are there to augment, we are that integration layer. We enable supported SOARs to increase the footprint that they can reach to ensure that the tasks are performed correctly to ensure that the remediation plan is executed correctly to ensure that there's ordering and compliance because Ansible has such a wide footprint across the IT domain. What we've done with Ansible security automation is we have created three high level use cases. The first one is investigation enrichment. Let's imagine once again that we are a security analyst and we noticed an alert, but we need more information about this. That would usually be a phone call. That would usually be a meeting or a ticket that they would have to submit to that relevant firewall team or IDPS team. Using Ansible security automation, that analyst can actually go and do an increase the velocity or include more logs from different devices into that CM, getting more insights into what is happening and being able to classify what the cyber threat is. When it comes to threat hunting, that's mostly at a preventive layer. In other words, Ansible security automation allows them to update signatures as an example on an IDPS device. It allows them to integrate a latest security bulletin and ensure that that is applied organization-wide. Whereas the security analyst again, let's imagine that that person has to change a specific signature on an IDPS device. Now they have the capability to do so from the CM portal. As we move to incident response, I have chatted about how it takes so many different teams to work cohesively to be able to provide an effective response to a cyber attack. Ansible automation platform and the tools it provides as well as Ansible security automation provides that collaborative environment where different teams can describe their requirements, can describe their needs, and work together to create these workflows to form part of a larger security remediation plan, eliminating the manual steps that are usually required and reducing the time it takes to actually go and fix that cyber attack. Because remember, the more time an organization is exposed, the more risk it introduces. Thank you. And with that, I'm going to hand over to Sumit Jaiswal. Okay. Hi all, thanks Greg for setting up this stage for Ansible security automation and also giving us the overview what Ansible security automation is and all about and why security automation has become a necessity and how Ansible security automation initiative can help enterprise customers as well as individual users equally to automate their security needs. So before moving on to the discussion, I'll just like to try, I'll just give a brief intro about myself. So my name is Sumit Jaiswal and currently I'm working as a senior software engineer for Ansible content team where I'm largely focusing on security content side of it. Okay. So first thing we'll discuss about is the firewall management. So we can move to the next slide. So here we'll discuss about the incident response scenario where in this scenario, basically we have identified an attack and we need to block access to a specific machine that find itself the target of the attack. By using content from ACL manager security automation roles, we are able to block access via a playbook and because we are using variable as input, these variables can pass dynamically as well. And alternatively, this information basically can also be supplied to Ansible tower job by an input template or through tower API call and for further integration. So continuing on the same use case of incident response, here we are using Cisco firepower threat defense with a Cisco FTD to deny access via creation of security intelligence URL policy. And this basically is to highlight that in a single playbook, we could remediate the situation across multiple devices in the infrastructure from multiple vendors. And this capability will continue to grow and expand and mature because as time goes on, we'll keep on adding new vendors and we'll keep on partnering with new vendors to come up with the integration with Ansible. Okay, so this slide talks about bringing in dev workflows with the CI. So if you think from a developer's perspective, we can consider bringing security practices and policy into the development workflows. And in this particular scenario, we have a CI environment that's provisioning a new minimal set of production infrastructure, but typically details of enterprise security policies and the devices, which if ignored, will have a negative effect on the validity of our integration test. So if you use Ansible to provision and set up the CI environment, we should allow Dev Team to simply use the existing and the same security policy Ansible playbooks in their CI such that they can actually test like production and can actually validate and verify if the test traffic close or works as expected. And this in turn ensures that application developers are mindful of their application requirement, which has been given from the security team and are mindful of those points while developing. So this slide may look like something, some fancy slide, and this all may sound like some fantasy, but it actually works because our security workshop are tested and verified using the same scenario where we are actively testing these type of scenarios. So here we are trying to put on our idea that your operation team, your security team and your development team all are coming together and trying to design on the CI pipelines, which is very much similar to the production pipeline and all your security policies and all the system related stuff are being tested over in your CI before we move on to the production system because if you use, if you check and if you test the security policies in your CI system before going into the productions, before that goes into this production, we can actually verify that everything works and there is no gap from or from this, which can be breached from security side. So now comes the inclusion detection prevention system management. So here in this scenario, basically, IDS and IPS knows which traffic is expected to reach to your application and what all traffic is not expected to reach to the application. And here we have taken an example of new signature which has been added to SNOT checkpoint 148 to check if someone is doing a DDoS simulation or doing some SQL injection. So if you see this playbook is using Ansible role, which is IDS rule role. It is actually developed and maintained by the Ansible security automation engineers and this Ansible role is to manage when diagnostic IDS rules to add a new rule using this SNOT backend provider. So the backend provider tells the role which IDS utility on the backend to target and allow SecOps administrator using Ansible to have consistent user experience regardless of the IDS solutions. This is your, this can be your trend micro, which can be your checkpoint, which can be your coordinate as well. More details about this SNOT rule and how it is laid out. You can go and check in the current workshop. I'll link the required at the end of the slide deck so that you can go ahead and check out for yourself. Okay, so in this particular slide, we are trying to create an IPS sensor using 40 OS. Something you will immediately notice here is the amount of options that we have in comparison to the previous slide. This is because and this is also, this also highlights that we have the capability within Ansible, which in many cases to take full advantage of all the features available to a particular technology, but providing abstraction for common use cases that all the vendors oppose. So here, as you can see currently it is using 40 OS IPS custom on you, which is a module written by like currently maintained by a coordinate engineers. So this is using a module and in the previous slide we were using an IDS rule, which was abstracting the module functionality. If let's say you have to configure a module, like any particular IDS rule or any particular IPS with custom requirements, you can use the module itself and go ahead and configure those IPS rule. Okay, so this is the slide which talks about the DevSecorp real world scenario using ZoolCI. ZoolCI is actually being actively used in Ansible CI power system. So as a DevSecorp practitioner, we can actually apply this change set in a way that verifies the signature we are looking for and potentially preventing the new classification of attacks that an application deployment in development might introduce. Moving on to the security information and event management that is SIM. So if we move on, so we have currently support of IBM Qradar and Splunk and this is basically a use case where we talk about the trials of suspicious activities. So here we are trying to add log source and enable SIM rule to generate offenses. So here we are configuring the IBM Qradar SIM to identify the log data which is coming from checkpoint next generation firewall and to process it and it processes it with appropriate powers and filters. Then we enable a relevant Qradar rule. So you can see, right? Enable remote accessive firewall denies rule. So here we are trying to enable the Qradar rule based on the log source side. So that we can trigger offenses based on the data coming from the log source appropriately. So continuing the same slide, same use case, you can see get info from the Qradar offense, excessive offense. So this actually gives you the detail of the Qradar offense info with the name of excessive offense. And based on that particular trigger, you are actually assigning actions to offense. So you can see, right? We have used a Qradar offense action module with the parameters like ID, status, assigned to, and protected. So if it's coming from a log source, this can be enabled, relevant rules can be enabled, which actually ensures we are getting only relevant alerts, not false positive alerts or the suit alerts. Okay, so this talks about adding log source and enabling SIM rule to generate offenses. So once again, from the developer's perspective, if we try to attempt and bring this to a devop workflow, we'll be able to dynamically add the logs from our new web app into Splunk, okay? As a log source and create a correlation search to enable the creation of investigation into Splunk's enterprise security plugin, SIM plugin. So while this is something we can incorporate into a CI environment, which is likely, which is more likely a common scenario if you are an enterprise structure, this does not do a regular deployment to depth test or stage or production environment. We can ensure during the deployment to your dev environment or the test environment that everything comes into play in Splunk, as would be expected for your stage and production environment. So this is a SecOps slide, which actually talks about the real world scenario, which is an end-to-end workflow for an attack, where an attack is happening and investigation and remediation is happening at the same time. And this allows us to decide how much or little we want to automate the process workflow, which can help us to figure out what would have been done better from automation prospects to avoid any future security breach and in turn, improve the process workflow. So this is a screenshot from our job template. So you can see here we have a tower workflow expression of the process outline in the previous slide, basically. So this shows each step being automated with information between stages of the workflow and remediation tasks to take. If the automation is not successful, then this template will properly alert the SecOps team with the information about the issues so that it may be triaged further. So much like an answerable tower workflow, a CI pipeline is a series of tasks that can spawn one or many stages. Some of it can be in parallel and we can do a conditional approach as well. Okay, so this brings us to the magical future of DevSecOps where it's such that you have some sort of version control system like Git, which is actually the source of truth for all the deployment logic from operations to the application and the security policies with all the appropriate component expressed as an answerable playbook, answerable automation playbooks. And while this can be structured as one of the repositories, whatever makes sense of the organization, the net effect of the workflow is same. This allows, and this actually allows for cross-team collaboration, cross-team training and education because here, your operation team, your security team, your development team sit together and come up with all the approaches. And as we enable a self-service portal for job delegation from SMEs to different groups, all imposed by our back, which is rollback access control. Okay, so as I was talking that I'll be going over all the relevant URLs at the end of the slide deck. So these are all, so you can see, right? Ansible.com, at ansible.com, we have a use case for security automation which talks about what use cases it covers and what it offers. And we have a Mojo page as well, which is actually a redhead internal page. And there is a galaxy from where you can download the collection that I just showed in the examples. So there is Ansible security, which actually has your ACL manager role, your IES rule and there are other roles as well. And apart from that, I talked about IBM Q-radar and Splunk Enterprise Security. So you can find those collection here and you can download it from Galaxy Ansible. So the GitHub link for Ansible security is github.com ansible security. Here is all the content that we are currently working on are there and you can go ahead and try to contribute or you can go ahead and check out all the contents that we are currently offering. We also have a community page for Overviki security automation and we have IRC handle as well as hashtag Ansible security. And as Greg has mentioned earlier as well, that we are not going to provide a security solution. We are trying to come up with the existing thing, whatever there is in the security space and we are trying to integrate with all the security use cases and with the vendors to come up with the automation as a whole, okay? So let's say if you have any use case or anything that you want to talk about from security aspect or you want to come up with the automation of any particular use case, we'd love to chat with you. So please hang out on Ansible security with your questions or queries or anything. Okay, so this brings us to the end of our discussion. Thanks a lot for joining the session and now we are open for the Q&A session. So, well, that was awesome. Well, we have Sumit available. Please feel free to share your questions if you have any. Sumit, I would request you to please click on share audio video button so that you can come on stage and you can join the stage. Sumit, if anybody have any question, please feel free to post in the chat section. We have another one hour for the break, lunch break and after that, we would be having the next session. So if anybody have any question, please feel free to post in the chat. Well, I believe Sumit, okay, you can try refreshing your browser, Sumit, or you can just try to reconnect. Well, we have Craig. Welcome, Craig. Hey, everybody, how you doing? Well, I would love to learn more about DevSecOps, probably I would get in touch with you. That was nice one. Yeah, yeah, look, it's an interesting, that DevSecOps is an interesting and a fascinating topic. I mean, we're hearing about it more and more as I think the whole DevOps matured from past, just the theme to actually getting done to the nitty gritty technical details of getting DevOps working. Same for security now, right? It was more of a goal. But what I'm personally seeing within organizations right now is that it's becoming more of a reality. And with that reality, there's a lot of complexity that comes with it. So that's where automation is really, really important to how will that DevSecOps flow. Hemant, I can't hear you. I'm sorry. As we don't have questions from the audience, probably I would take this opportunity and I would like to understand somewhere you mentioned about the IBM Q Radar. So how do we make use of that product in this process or flow? Because I believe that's the propriety ruin, right? Is it soon it's on? I'm not too sure. Okay, but I'll have a passionate. He's the technical guru, but could you please repeat the question? Okay, so I was trying to understand somewhere he has mentioned about the IBM Q Radar product. So, okay, we have Sumit. Give me a minute, let me just allow him. The experts is online. Hey, Sumit, how are you? Hey, all. Okay, so I think the question is, apart from Ansible Security, the rest of the platform mentioned with security, if I claim a proprietary example, what in it? Is that the question? That's the first question that's come through on the chat. And then Hemant also asked the question about how Q Radar fits into a security incident or response flow. Well, I believe the question is the same question. So, for Q Radar, are you able to hear me? Yes. Am I audible? Okay. So, Q Radar is basically a lock provider's same tool, right? So, we have Ansible Modules with respect to Q Radar. So, you can just create a policy tool for in the Q Radar and then from that, you can, if you have any enterprise end point security like Checkpoint, Fortinet, or any of the friend micro or others. So, in that, you can set up your lock source and then you can start forwarding those logs based on the rules from Q Radar to your firewall manager, like Fortinet, Checkpoint, and others. So, based on your lock source, you can take actions from your firewall manager. So, that's how this entire workflow can be automated on, I think, briefly I talked about that as well. So, yeah, Snot is an open source tool, yeah. That's great as much. Awesome. Thank you for the information. And, apart from that, I see Lenny's questions that, yes. So, Fortinet is a propriety firewall manager, but we have come up with the integration with Fortinet. So, if you see there is a Fortinet collections available on GitHub and you can directly use those modules to automate the, like automate all the configurations based on your firewall using those modules. So, for using those modules, you don't need any license or something. You can just use those with answers. Awesome. So, do we have any other questions? No, that answers my, you know.