denial of service attacks have been a mainstay in cyber security for years in the past it required a fair amount of technical knowledge in order to execute one of these kinds of attacks but now all it takes is for someone to rent a bot to disrupt their competitor's website every second of downtime can lead to a rise in user abandonment and i.t operations and security teams struggle with these denial of service attacks because of two main reasons first they have limited visibility into the source of the attack and second they can't gauge the business criticality of the attack until it's too late in an ideal world these two teams need to work in tandem to thwart these attacks the scenario we'll look at in this video we'll demonstrate exactly how they can do that this demonstration starts with our network operation center operator naomi logging into her workspace after logging in she notices that the rewards processing service has turned red along with two technical services on the filter services by alerts section we also see that there is a single group alert that's affecting these services now these alerts have been grouped because a pattern was identified based on temporal or time based and topological configuration item relationship reasons this is important because a denial of service attack is going to be an event storm and has the ability to create thousands of events being able to correlate these events into a few alerts and incidents can be of immense importance for knock operators as we click on the alert it launches into the alert overview of the group alert we can see that there are three impacted services we can click on this tab and see exactly which services and by clicking on one of them we can open up the service map this will give us a detail of the topology of the components that are affected on the service act we get several insights to help diagnose the issue first we see that there is a vulnerability on the tomcat server as indicated by the vulnerability icon second there are several alerts on the load balancer and tomcat server and one of these alerts indicates there's an increase in the number of requests we'll get more information about this by clicking on the advanced map in this full view we can see a topology of the service a timeline of what happened the related alerts and a single alert in which they were correlated now note that we can see the individual configuration items as well as the vulnerable item that is affecting the tomcat server now the operator analyzes the service map and figures out the tomcat server is being impacted different metrics are being impacted such as a high ram usage high cpu utilization and increasing in spike of requests and increase in processing time in addition the operator also sees the h a proxy node has been impacted notices again that that vulnerable like that vulnerability icon on the tomcat server and we can see that vulnerable item at this point naomi derives the conclusion that there may be a vulnerability that's being exploited and hence the other metrics are also being impacted naomi then decides to create a security incident to involve the security team in the scenario so the proper remediation can be done now that naomi has this context she goes back into the alerts details section from here we can see that the various alerts were combined into a single alert from here we can go into the alerts and group and open up one of these alerts and then create a security incident directly from this field once the security incident is created we can see that here and here we'll switch over to the security analyst view and pick up from there so as the security analyst i log into my security incident workbench and i can see all of the security incidents that are currently open and use a quick filter to show the five new security incidents now the one that i want is at the top and i'm going to go ahead and click on that now once i do this i can see some information right off the bat first it shows me the configuration item in question it also shows me the affected user and some notes that were automatically attached to the security incident now as a security analyst i can do some uh different things to determine the root cause for the security and security incident such as taking a look at the observable information now by clicking on observables we can see that there's already been some automation performed for the security incident before i even opened it i can see that the observables have automatically had threat intelligence uh lookups performed on them and the finding is that this particular observable that is affecting the nodes in question is in fact a known malicious ip address now because i have this information i'm going to go ahead and make a determination on what kind of category and subcategory this particular security incident is in this case it's a denial of service attack and it's an inbound denial of service attack so i'm going to go ahead and click save and you'll note that a playbook was automatically attached to the security incident now this is important because this allows me to follow my organization's best practices for this particular type of security incident that's really what the power of the playbook is it allows you to craft best practice steps for your organization for the different types of things in the run book so for example denial of service attack malware fishing etc those can all have playbooks associated with them that the security analysts will then know which steps to take as they go through the security incident so let's start with our remediation flow now the first task in our flow is to decide whether or not this particular threat is from an internal attacker now you'll also note that there is there is a space to add work notes as well as a knowledge base article that's automatically been attached so it's another benefit to the playbooks is that it allows the organization to guide the security analyst on exactly what steps need to be taken in order to handle this particular step in the playbook now we know that this is not an internal attack so we're going to say no and click submit and you'll note that it automatically adds additional steps now if we had said yes these steps might have been different now the next step is to notify the denial of service protection provider or isp if needed i'm going to start this task and directly from this pane i can initiate an email i can use one of these email templates or craft a whole new one in this case for the purposes of the demonstration we'll use an email template it's going to automatically fill in the email address the subject line and some information that we want to send to the isp and i click send and once that's sent we'll mark this as complete now the next step is to initiate a firewall block request so we'll go ahead and get that started now this shows the orchestration capabilities of servicenow security incident response i can click the check box next to the observable and then i have a few different options here if i would like to do a citing search i can look for additional instances of this particular ip address that may show up in other security incidents but in this case i'm going to do a block request and this is going to send a request to the firewall block list i'm going to send it to the palo alto network's firewall global i p block list and click block now that that ip address has been added to the block list any additional instances of that are automatically going to be blocked by the firewall once that's done i can move on to the next step is the vulnerability being exploited well we know that there is a vulnerability on the tomcat server and that that is most likely the reason why the denial of service attack is is successful so we're going to say yes to this and click submit now the next step is to create a request to remediate the particular vulnerability we're going to start this task and add a manual task here now this is where we can reach out to the it team and ask them to apply a patch to remediate this vulnerability i'm going to choose the tomcat server i'm going to change this priority to critical make sure that the assignment group is correct and then add a brief description and then click add task so that's automatically going to create a task for the application security team and we'll assume for the purposes of this demo that they have applied that so we will mark this as complete and we're going to then move on to the next step which is validating the integrity of the attack systems now again this is going to be something for the purposes of the demo that we're going to assume has been done that the systems have been successfully patched and the vulnerability no longer exists on the the tomcat server i'm going to mark that as complete next let's go back to the it operators dashboard and see the services and make sure that they're back up and running once the remediation steps have been completed by the security and i t teams we can see that the services are back in green and everything is good to go this has been a quick demonstration of the integrations between itom and security operations if you'd like to learn more please visit us at www.servicenow.com