[Music] hello everyone welcome to today's webinar related to security incident response that is part of servicenow's security operations portfolio first and foremost i hope you're all well and safe my name is deepak kolingiwadi i'm the director of product management for the security incident response product at servicenow and i'll be your host today and joining me today as guest speakers are two key members of servicenow's very own infosec team akilah managoli and jerome cruz aquila and jerome play a part in defending and protecting servicenow's i.t infrastructure they also play an instrumental role in automating servicenow's security operations and they have led the development of many playbooks three of which we are going to be discussing today akilah and jerome a warm welcome thank you so we're going to be here together for a little less than an hour we will discuss how aquila's team will shape the development of the security operations playbook in security incident response and there is so much credibility for our listeners today to hear this from real world psychological practitioners that they can relate to easily and achiel i believe you're going to be demonstrating one of these play books in action is that right that's that's right deepak we'll be showing the demo today akilah and jerome can you tell us uh more about your world what do you live and breathe within servicenow's infosec group for our audience today good morning and good afternoon to everybody uh we're depending on wherever you are um i'm a kilimanagoli i'm staff information security engineer and my colleague jerome is an information security engineer you're a part of service intelligence and global incident response operations team and we are dedicated to provide them with all the tools and the integration that the incident response team needs so we are a team of servicenow developer and admin so the main goal of our group along with the incident responders is to protect the uh servicenow's cloud infrastructure and also our corporate infrastructure that's our main goal and while doing so you know you cannot do it manually right and there has to be automation in place and of course you know we have used our own platform uh and have built more than 60 different categories for which we have built more than 60 plus workflows uh i certainly don't envy your position and the job on hand and like they say uh companies have to get security right every time and the attacker only has to get it right once and with that i think it's a good segue into talking about some of the challenges in numbers that are in front of us as an infosec team we all know that cyber attacks light up the threat landscape the kovid 19 pandemic has affected a dramatic shift on this landscape so some industry data first roughly half of all businesses report that they've had a breach within the last two years and what's truly regrettable is that most of these breaches could have been avoided actually 60 of the companies that were hit said the breach may have happened because they didn't either apply a patch or they did not affect a counter measure and it's always a race against time to test stage and roll off this patch stats are there that once a patch is released for a high priority vulnerability it takes on an average only about 43 days to see a cyber attack so time is really the enemy here and finally you know it also takes an average of 31 hours from the time a cyber incident is detected until the threat is completely eradicated that's like more than a day the attacker has to go deeper and deeper into your organization so why am i sharing these stats i think servicenow is no exception to this landscape we are part of the business fraternity that also gets attacked and aquila i'm sure you have a better ringside view to this threat landscape so why don't you tell us more about what you're doing about this your team's mission to protect our customers and what you do today things that you're going to share how is that going to be relevant for our audience you know before talking about how where we are today i just want to take a step back and you know tell where we were when we started right a few years back before the security instrument response module was even even out there we were using our own custom version of idsm and you know like our homegrown a little bit i can say and then we were doing things manually with with totally a swivel chair approach the instrument response team you know if an attacker would an advantage would initiate a threat and you know the response team will go hunt for it and you know grab the data they would have to go to multiple different tools manually be it splunk or proof point or aws get the data and basically detect it right and then come back to the servicenow instance and then you know create a record that they are analyzing the security incident and then from there on to analyze it again they were going to multiple different tools to gather the information to analyze threat itself again that was a lot of manual steps there you know you go to a different portal like virus total anomaly and ground strike and to gather that the worry talk about it after different uh you know indicators of compromises is this is it a true positive or a false positive is it malicious things like that right and to by the time they were to come to cup step contain again they had to go to different systems to gather more information like cmgp right and and jams and then while doing so as you talked about it it was taking you know most easily 31 hours to to get to a contained level and that gives so much time for adversaries to get deeper and deeper into the infrastructure right so to eliminate that you know the first thing we start we did at the moment the security instrument response model was out there the first step in our journey was to install that our out-of-the-box version of the security instrument response uh we have we have our own instance which on which we deployed that and from there on you know we have our dedicated team like myself and jerome and our team we totally managed that instance and the processes and the tools for the insurance response team so we went out and we integrated with all the security tools that were required for the instrument responders and we configured and customized whatever was required to get it up and running right and as a next step what we did is you know we developed a very good knowledge base knowledge base is so important for security and responders because every time they have to respond to an incident they need to have a procedure documented to do that you know we had to spend a good amount of time and create a good knowledge base um in a repository and that really helped us to standardize their procedures and processes globally because we have a global injury response team and hence you know we wanted the articles to be standardized across the board so with all in that place then we started digitizing our workflows because you know you cannot just jump to automating the uh the processors right you have to backtrack and see where are the different manual steps start you'll start from there and start automating one step at a time so we got our tools in place we got you know the article and articles in place and then we took a step of digitizing our workflows and again you know when you talk about these workflows it's constantly changing the threat landscape is constantly changing so is our instant response procedures like you have to keep up with the changes so we keep updating our knowledge with articles and then along with that we update our uh automated workflows and flow that we develop to uh to respond to those security incidents awesome i can't wait to see what you're going to be uh demoing as a killer surety but there are three already shared on the developers of portal and their password spray playbook uh endpoint detection playbook and typoscored domain playbook but what i'm going to do today is i'm going to walk through the password spray playbook you know in completely like how we built it what we did and i'm going to show the flow designer that we have used to build it and also i'm going to show the whole playbook in action those of you who don't know this is how a servicenow instance looks you know you would just type a flow designer and i would navigate it opens in a different tab the flow designer this is the um the newest way of you know the platform provides this tool to automate anything that you want basically right it's a really low code low code way of automating things so let me open up the flow that we have built and i'll walk you through real quick how we built it the password spray you know as you know that this is one of the very common everybody will uh be posed with right okay i'll just walk through the the flow first so to build the flow what we did is you know it needs a trigger condition right as you see here you have a bullet trigger condition so i'll keep it very simple the short description starts with possible password spray and as you can see there are all and conditions so you can build your condition that suits your um use case right you can add uh i can say a category if so and so right or you can say subcategory so and so or you can say the um attack vector affected whatever is the r case right you can add uh the additional conditions to build on the trigger condition so that the flow triggers only for that particular use case right so once you do that the next part is building the actions so what we did is you know we took our approach of creating playbook tasks that way this will guide the incident responders through how to actually work the security incident so while doing so you know we work very closely with the security incident response team and as i said you know we created a very good knowledge base and that run book is what we converted to a playbook so the first step in this playbook is create playbook task with um state update p1 i'm going to go explain that in short so are the activities originated from customer ip address this is the first task that's going to get created and this is nothing but it's a action to create a task so out of the box there's already a action available to create tasks and what we did is we took that out of the box task and customized them a little bit because we know for our use case we're going to have all these different fields over and over again so we didn't want to be you know add a field and a value and a field and a value every single time so we took that out of the box create task action we customized it by adding few more fields that are very repeatable for us that way you can just you know use this action and every time you don't have to keep adding the action and the uh the field and the values right you just have to go about adding the values because the fields are already there for you so you pick the different values like the the parent task the security incident for this test and put the short description and in the description we typically put what what is needed to guide the uh analyst themselves right once they read it they have to be there to understand what to do at the next step or what to do in this step basically right and along with that we are also updating the security incident state uh i'll show you in action what is this actually translate to right and then you can add the close quote close notes whatever the additional fit data you want to put in and once you create the stats the next is you know as you see the if condition so if the first you know in this task you see that we have outcome type outcome type is s or no based on whatever the analyst picks chooses is yes or no the flow continues forward right if this if they pick yes we would go to review process if it's no then it goes to next step the same thing is happening uh along the way so um i'll just quickly highlight what's the review process here right so we have uh again it's it's very our process within service now we have incorporated a review process for every flow that we have developed there are a couple of reasons for review process uh what that what the review process does if an analyst worked and if he wants that to be if he or she wanted to be peer reviewed there's a place where they i mean this kind of acts as a blanket place where they can get it peer reviewed and then close the security incident right or we also have another use case where we have l1 l2 model and if the instant accuracy was handled by a l1 team you know it goes back to l2 team and they review it before closing it making sure that you know all the steps were taken and all that is mitigated before the security incident itself was closed and uh we kind of made it a sub flow the review process the reason being um you know when when it comes to review test step as you see here if if the um the answer to the first task is yes we go to review and in review task you know if the answer to review is yes the security instrument gets closed automatically right it saves time for the analyst again there and if the answer is no we open a task called advanced shooting again it opens up a task for them hey something was missed out you know go ahead and do the uh the work that was missed out so just kind of give them that space and not like oh my god i closed my security and said what do i do now right so they have a step where they can stop and think and and make sure all the um containment is complete and everything is all the action items are complete and then print security incident so this gives them that space right so i will um quickly show this in action so let's open up our uh the new ui which is the instant responders ui i'm going to create a new incident and as i said my um short description i'm just copying it here so i can create that so this is my short description so you can add anything after that because i think i'll just starts with this string right you can add anything after that and the category let's say it's an unauthorized access because we're talking about password spray and subcategory can be put forth and let's say create okay the instrument is created and the analysis when it lands on the incident you know typically a lot more data right based on if it's coming from a different surface we already had an integration it would have based on that it would have the um the customer ip address and so on and so forth or the type here that the instant originated from additional leaders will be there on the incident when the analyst lands on this incident typically right but if you focus on the left right hand side of the playbook section you see here that the task already created for the analyst he you know when analyst lands on the incident we should not spend time that you know what do i do next how do i respond to this right the task waiting for them as to to guide them as to what to do next right the first as you know um as i was showing in my flow designer the first ask is uh the activities originated from the customer ip address and you the same task here right and then as i was saying in the description they have additional details as to what they should be doing here what they should be looking for and not only that you know you can kind of provide the link to the the knowledge article on the runbook itself within this task it's totally um doable right and for the sake of the demo i'm going to say that you know i read through it and okay um the activity is not it's not originating from a customer ip address so i'm going to say um oh sorry i'm going to say it's yes right it's it's coming from a customer right here just let's say i'll select the outcome as yes and say submit so i wanted to pay attention on the incident state it got updated to review state uh which they don't have to do it manually because uh you know when a response analyst is working through a security incident they have to take the instrument to different states and that's already automated it saves them for more time there and also additionally you see there's another task that's open for them as we were saying in the flow uh if it is yes to this it would go to the review process and the debit has got open right and as i was explaining the review process in detail you know let's say i'm going to just select yes for this and submit let's see what happens okay the tasks are completed and the incident got updated to closed let's look at the different fields on the instrument itself the closure information it populated closed code as false positive and closed nodes as activities originated from customer ip address so as you can see you know um it uh so many of the steps gets automated right away based on the input from the analyst so uh this kind of concludes my demo how did you like the demo oh this is this is great and uh uh quickly did any of these uh playbooks uh automate procedures with third-party services yes and that's a very good question but as a matter of fact um you know the one we have published on the developer portal the type of spotted domain uh we have an uh there was a need to grab the screenshot um and attach it to the security incident so we have uh you know we build an integration with the uh api screenshot layer and then that module is already in that uh playbook so users can definitely go take a look at that awesome awesome so there is indeed uh an integration now that you built from scratch and that's available for our customers to see how you went about doing that so that's perfect so yeah so so uh so what you demonstrated akilah what is showcased here is to leverage the platform capability of using flow designer and build a playbook using the natural business language style i think you took advantage of playbook actions already shipping with the security incident response product and i think your team smartly extended those out of the box actions so you you designed those actions to to deflect many a number of uh manual steps away from actual uh analysts involvement uh so a perfect set of practically relevant response procedures that our customers can consume they can take what you've created here make it their own and even adapt it for the right to suit their incident response process as needed like hello why don't you share with us about literally you know how has this benefited your teams what were your learnings and and what were some of the takeaways for you yeah so uh deeper before jumping into the outcomes i kind of wanted to highlight a bit on the key learning one thing that really stands out to me is you know the random book needs to be formatted at the playbook so when we started building our playbooks right the automated playbooks if the first playbook it literally took us three to four weeks like almost a month time to format existing run book in a format in the form of a playbook because you know the any procedure that you have you would you would have a run book right that that's only documented but to take that and convert it into a playbook it's an effort and then it has to follow this model of you know going from task to task right so we went back and forth we meaning us and the instrument response team we've come we really you know worked together and went back and forth iterated through and and and decided how to you know really format it in a playbook style and once we got that right you know there was a no looking back now we have really standardized that it has built into our process today before we onboard any new threat or any new use case you know we we make sure that the run book is already formatted in a playbook uh style in the get go that way when we onboard a new alert or a new u we uh the moment it starts becoming a security incident for the instant response team we can already behind the scenes start building this automated uh you know playbook for them so that was a big learning right and along with that you know we had to standardize the processes right because we need to have consistent close quotes and close notes so that the automation can close the security incidents if we don't have those standardized it's very difficult for the admin or developer who is developing these playbooks to put those values in place so those have to be summarized we again we work very closely with the the internet response team on that and of course i talked about customizing the actions right so out of the box a lot of you know there are amazing actions available you know some of them when i i was trying uh recently uh you know converting uh inbound emails into different there are a lot of good attaching attachments you know how to grab it um attach attachments to the different uh records there are a lot of very good actions available right on the floor designer module but at the same time you know not all some of them as i showed the create task is great but for our use case we had to customize a little bit so that you know every time we don't have to spend time when we create tasks we could just uh pop in different values for the field that we know that we require right so those were some of the key learnings and coming to outcomes you know if you look back for the last couple of years it's been really great you know the response time has gone 20 faster because the lot of places you know some of them you don't realize like going and updating the state of the incident that takes time and the user lands on an incident and then looking for you know hey what is the verdict of all this uh observables that's automated right all these things you don't realize but they add up so much time and and we if we now look back it has gotten twenty percent faster and of course you know this has uh affected in fifty percent cost production for the insulin response team but the one thing that really stands out to me personally is the satisfaction for the insulin responders that has gone up 80 so we're talking about the swivel chair and the issues that they were going through before to now the way they're able to do their work in single screen and single pane that's really is helping them right to focus on the real threat and and focus on what what they need to be doing yeah a lot of uh nuggets of wisdoms best practices around things that you've done towards successfully creating those playbooks i think first documenting the procedures and doing that as part of run books and knowledge base articles within the servicenow platform i think uh you know gives a great head start i think you can probably kill two birds in one stone they're your documented things and you also kept it within the instance so that you can link them up to playbooks and looks like some real hard roi that you were able to achieve by automating these playbooks and i'm sure you know these are not just uh restricted to the three playbooks that we shared today but the many more playbooks that you had shared with us earlier on as part of your team starter so now we can transition to q a and i'll ask jerome to probably call out any key questions that may have uh come up uh yeah a few very interesting questions is this an additional license or does this come with secops security now or snow module no good question so these playbooks are built for the community and by the community right you know so these are not like product built playbooks right you know so these are developed by servicenow's infosec team and they are sharing it for our other customers to take advantage of and we hope that through this kind of sharing mechanisms we'll have more and more sharing by other members of the community by other customers partners anybody you know who's working with servicenow's security incident response can share the content that they develop to benefit the community at large so there's no cost in downloading and using these playbooks and i'll walk you through maybe at the end how do you actually grab these playbooks the one playbook where there is the integration with the third-party servers that'll obviously require you to have the necessary orchestration license that is standard for any uh orchestration you would do from the servicenow platform so you'll just need to pay attention to that one part based on your entitlement but the other areas you know uh you know you know be the set of response procedures that has been codified into the playbook and all of those i don't think you know they should not require any further entitlement apart from having of course security incident response because these playbooks have been created within the scope of security incident response so so you as long as you have a security insurance response you should be good other question do you recommend sierra running its own instance in order to facilitate agile response detect landscape changes so we we do have a lot of our customers actually running security incident response on the same instance as it primarily you know for two reasons you know one is they can take advantage of native uh workflows where if a recovery action needs to be performed by an i.t they could easily pass it off to help test teams they could also take advantage of asset intelligence coming from uh cmted so that's another advantage and and as we continue to tie in more and more servicenow applications uh be it the vulnerability response module uh or the uh governance risk and compliance the grc module customers will see a lot more you know better together stories uh when all of these apps exist and are sharing context uh across these applications and within each other so so the recommendation is to go with the same instance another question here do you need to be global servicenow admin to use the flow designer our team are sir admins but not global admins as our instance is just a module within the larger platform flow designer comes with its own admin role the security admin for sar does have the rights to administer flows obviously you know this could this will be something that you may want to review with your platform admin uh just to be sure that they are they're comfortable but flow designer itself is scoped so you can have restrictions or access based controls put in place that will ensure that only certain roles or certain app roles can edit and modify the flows so so those access-based restrictions are not available uh natively as part of flow design another question is it not possible to execute all the shared knowledge between instances via api but service now you know it's a it's a choose your own uh venture and i'm sure there's always a way to uh get that done i feel that will really depend on on how much complexity would working with multiple instances introduced and if the organization is ready to take on that complexity and and if they feel that's the right architecture then yes that is a possible route but i think it's going to be on a case-by-case basis that organizations will have to evaluate can these playbooks be used for vulnerability management threat intel and cmdb to flag high risk remediation requirements so floor designer the underlying technology that was used for creating these playbooks is common for any application that resides on the servicenow platform so what you just saw is not something that's exclusive to sar you saw the application offload designer for security incident response playbooks you can very well create your own playbooks for the other products that was just mentioned via vulnerability response or even drawing information from other areas of the products for example our automated phishing and malware playbooks we do have an action there that actually uh calibrates the severity of the incident based on either knowledge of the user if they use if the user is a vip user then we would calibrate the severity of the incident uh differently or based on the class of the asset if the asset is a server for example we do that by looking into the cmdb then we would actually calibrate the severity differently so we do have an example action that goes beyond the scope of a security instant response into other areas within the platform to grab information and act accordingly one last one how many playbooks are there out of box so we do have uh playbooks available through the store so we have automated and manual versions of fishing and malware playbook a fail login playbook a child security incident playbook and then in our community uh website you know we do have uh playbooks for repeat detection uh fishing incidents uh we do have a spoof detection playbook where there is uh a trusted brand that is being spoofed and then uh we just released these three new uh playbooks this is going to be a growing set of playbook for our customers to use both within the product and as part of the community right you know so what you're seeing here is the the starter or the beginning set with more to come so let's quickly take a look at how you can grab these playbooks this is a view of developer.servicenow.com and how you can actually register for an account uh it's available for everybody you'll be given a service now id uh once you register and after you register uh you can actually search for any uh you know share projects share projects are ones that the community is actually sharing uh within each other so if you hit on connect and you don't share the marked area you'll be able to actually look for share projects and you can actually look for a specific project by searching for it so so or you can you know look into all projects and when you click on view all projects in the next slide you'll see the listing of these projects by areas or by products so you see security operations listed out as an area and then when you click on security operations you will see all of the playbooks that we've been uh releasing as well as what the community has been posting so so the three playbooks the type of squad and domain playbook the endpoint detection playbook and the passwords spray playbook are available listed here you can go into each of those so if you were to double click into let's say one of those playbooks the password straight playbook in the next slide you will see how that particular listing will look like the related files section will give you access to uh documentations and update sets so all of these playbooks are made available as update sets that you can import into your servicenow instance familiar way to get content into servicenow nothing specific for these playbooks after you import the update set and commit the update set you'll be able to see how do these uh playbooks actually uh look like so you'll see them reflect in flow designer akilah any other best practices you would like to highlight for our audience today on how to operationalize these playbooks yes one thing i can definitely think of is you know what i highly suggest that take these playbooks in your subproduction or non-production instance and try them out first and you know make it change it or customize it to fit into your needs before putting it on production yeah you know that's an important uh kind of a consideration in the tip i want to conclude by uh just asking you to go to uh share and download these playbooks uh test them out give us feedback post questions on the community forum we are eager to get your feedback and know how you benefited from these playbooks or if you would like to see any other playbook developed and made available to you for use please let us know we are always here to to help you as a product team aquila's team or you know as they create more playbooks our endeavor is to bring those playbooks out to our other customers as well and with that thank you all and you have a great rest of the day or the rest of the evening