IncMan SOAR Uses Cases

Read and Learn With Our Practical Use Cases.

Our experts have documented a variety of practical use cases for different types of scenarios including malware and phishing. Read more here.

/ 28 Jan 2019

This particular use case will pertain to privacy breaches. Within the last year we have experienced a couple of the greatest PII beaches in history. Facebook’s Cambridge Analytics, Equifax and NASA have all recently been victims of a breach costing each organization and its victims millions of dollars. Aside from the financial loss, the victims have had there personal information and privacy exposed to the world for monetary reasons. Such information includes social security numbers, home addresses, emails, credit card statements, login information, and access to bank accounts.This type of information is referred to as Personally Identifiable Information (PII). Additionally, when a hospital or healthcare system has been breached all of the information blended with that is termed Protected Health Information (PHI). Both PII and PHI is often sold on the black market and can be very lucrative. Thus, one of the many reasons as to why PII beaches are so prevalent within the theme of cybersecurity attacks.To illustrate this type of attack, we will use a mock PII Breach scenario to help our readers gain a better understanding. This scenario will be used throughout the remainder of this use case to pinpoint several significant elements that are common denominators among the majority of companies and organizations that have been breached in the past. Additionally, we will highlight IncMan SOAR’s PII Breach Incident Playbooks and Runbooks that generate automatic actions based on defined criterias and step-by-step procedures to explicitly follow.Recent Real-World RDP Exploit BreachIn March of 2018 an attack scenario very similar to what we just described actually occurred in Atlanta, Georgia. A couple of hackers were able to gain entry into Atlanta's Government IT Infrastructure through brute-force password attacks on publicly exposed open Remote Desktop Protocol (RDP) ports. This resulted in dismantling Atlanta's court system, police department, and transportation system just to name a few. Georgia is still in a state of recovery and at the moment the current cost is a little under ten million dollars. In theory, once the hackers had gained access into Atlanta's primary government IT system they could have done anything they wanted to. However, they chose to deploy a ransomware attack. This is just one example out of many that are used every day to infiltrate organizations’ technology outfits regardless of the industry it resides in.The threat actors were able to infiltrate the company’s network by exploiting vulnerabilities found in RDP TCP port 3389. RDP was developed many years ago by Microsoft for the purpose of providing its users with a Graphical User Interface (GUI) to conduct business from remote locations. By default, all Windows Operating Systems have RDP port disabled for security purposes and for the sheer amount of vulnerabilities associated with the protocol.Unfortunately, novice systems administrators often forget to close the port once they have finished the need for it, leaving it exposed to the public. If an individual has been able to successfully gain access into a remote computer via the RDP port they will have the capability to conduct any type of business they so wish. This may include malicious acts such as doxxing, creating back-doors, or even dropping rootkits and various forms of malware such as the ransomware strain SamSam. However, speaking from personal experience, using this protocol has proven to be very beneficial and extremely convenient when required to do any type of network troubleshooting or engineering on systems located thousands of miles away.Use Case: PII Breach - Hypothetical ScenarioLet's pretend the scenario was a little different and they had decided to drop a few rootkits, open a few backdoor ports, install some keyloggers and spyware, birth an Advanced Persistent Threat (APT), and finally delete all logs and evidence of any wrongdoings or Indicators of Compromise (IOC). For the sake of this hypothetical attack scenario, we're going to use the same Tactics, Techniques and Procedures (TTPs) that were used by the threat actors who conducted the brute-force RDP exploit.This all too real hypothetical scenario is one of the many ways in which a few of the greatest cybersecurity attacks in history concerning PII and PHI beaches have literally destroyed the lives of many people. We will break down and explain different phases of the attack, numerous tools that are used within those phases, and why Advanced Persistent Threats (APTs) of this nature go unnoticed for so long.There are a significant number of other methods that can be used to gain access into a computer system in order to own the infrastructure. This spans way beyond the scope of this use case but just to name a couple for informational purposes, these might include:Unpatched Assets with Multiple Vulnerabilities for ExploitationInsider Threats (Intentional & Non-Intentional)Social Engineering Tactics & Phishing CampaignsPoorly Written Programs/Applications Containing VulnerabilitiesMalware Embedded Pop-Ups & AdwareHenceforth, we will render a few basic security measures that if implemented would prevent 99% of the large-scale breaches and cybersecurity attacks that we witness every day. Additionally, we will illustrate how specially crafted Playbooks and Runbooks are developed to address these types of attacks in DFLabs’ IncMan SOAR solution. Moreover, we will indicate how IncMan SOAR supports defensive and offensive security measures in an autonomous manner, eliminating the need for continuous human intervention and oversight, which in turn eliminates a lot of remedial tasks and frees your security teams and resources to focus on other important tasks.Use Case: PII Breach ObjectivesConfirm that an actual PII Breach has occurred and if so determine the scope, severity and amount of information disclosed.Document and log all events and actions for the Post-Incident After Action Report (AOR).Verify the TTPs' that were used by the threat actor to identify the vulnerabilities in the network.Illustrate how IncMan SOAR’s Playbooks and Runbooks play a vital role in minimizing the impact of the breach.Contain and isolate all recognized infected systems assets.Eradicate and remediate all malicious content from compromised assets.Prepare public/employee statements and work with the legal and public relations departments for further actions.Conduct post-incident processes such as modifications of the company’s PII Breach policies, debriefings, and lessons learned.Security Tool Integrations Used for PII Incident Response BreachThe tools listed below that will be used in this hypothetical scenario are for training purposes only. There exists no partiality among these tools aside from the fact that IncMan SOAR's integration capabilities are directly partnered with these products and services. Seemingly, the tools chosen for this scenario remain very popular within the cybersecurity industry.These are the specific security tools that are used by the breached organization within their Information Security Department and Security Operations Center. IncMan SOAR guarantees that these devices are fully integrated and are being employed to their greatest potential to provide optimal security measures.ServiceNowCisco Threat GridIBM X-ForceTenableSplunkCarbon Black DefenseFireEyeMcAfee Web GatewayCarbon Black ResponsePII Breach RunbookThe Runbook defines what specific tools, actions, logical decisions, and automation capabilities will occur during an incident. Below you'll find the entire PII Breach Runbook from start to finish with all of the included stages needed to remediate a compromise. We will be going into depth on each of the stages and various tools used in that stage.NotificationCommunication and Notification of an incident are incredibly important. We will be using ServiceNow to create an initial ticket to permit for those that have access to that ticket to provide continuous updates on the current incident. Additionally, an email will be drafted and sent to various stakeholders, key individuals, and distribution groups like incident response teams. Microsoft Outlook will be the application used for email creation distribution.drafted and sent to various stakeholders, key individuals, and distribution groups like incident response teams. Microsoft Outlook will be the application used for email creation distribution.EnrichmentDuring the Enrichment portion, we will be validating the compromise assuring that it is not a false positive. Reputation checks of potentially malicious IPs, URLs, and Domain Names will be conducted by IBM X-Force and Cisco Threat Grid. This will be able to provide us with intelligence about any types of malicious command and control servers that might be being used as a means to store the data that has been excavated outside of the company's network. It will also be essential to initiate a scan on the network assets to determine any abnormalities on the host or other system assets such as suspicious open ports, unauthorized executables and applications, and rogue user or administrative accounts.If there is a particular asset in question that may support indications of already being compromised, a special scan of system processes will be conducted through the use Carbon Black Defense. Moreover, Splunk, which is the company's primary Security Information and Event Management (SIEM) tool will generate a report of the last six months to identify any abnormalities and behaviors, especially those associated with data exfiltration.Once all of the scanning has been complete the reports are available for review and the information will be provided to the appropriate personnel. Analysis of the reports will support the decision on whether or not to follow through with the incident response lifecycle. Additionally, if it turns out to be a false positive it will not warrant any further action.If it is not a false positive and it is an actual breach, then we will continue with the rest of the incident response process. In this case all of the indicators of compromise have validated that it is in fact a breach and the rest of the incident response portion will continue.ContainmentIf the reports generated by the scans and the other intelligence gathered on the incident during the enrichment phase validate that the incident is in fact a true compromise, the containment portion is now enacted. There will be a host of tools and actions to follow that will be necessary to promote a successful triage process. If a company has pre-develop policies and procedures this aspect should run rather smoothly. Additionally, relying on the Playbooks and the documentation associated with each step will be incredibly valuable in eliminating the need for any second-guessing on what procedures to follow. Now that the incident response team has identified the infected host, it will be mandatory to quarantine it among with the rest of the network assets. Once segregation has occurred, all running processes on the host will be terminated and a snapshot of the current state of the asset must be obtained. Generating a snapshot of the infected host for forensics purposes is essential to understanding the TTPs utilized by the threat actors.After the asset image has been obtained, the forensics tools will determined if it is necessary to reimage the entire assets. While this process is taking place the company's security operation center will also blacklist all malicious Domain Names and IP addresses via McAfee’s Web Gateway. Additionally, all users of the network that have Active Directory and email accounts will be required to perform a password reset.Because of the nature of the attack type, threat actors will often create administrative accounts to elevate their privileges gain access to restricted material. This is why it will be necessary to temporarily disable administrative accounts to perform an audit on all users with administrative rights. After the forensics images have been captured and the host have been reimaged and all malicious content and artifacts have been removed, it will now be time to transition into the final phase of Recovery.RecoveryAt this point the containment phase has been completed and all compromised assets have been remediated. Any host needing reimaging has been completed and all users requiring password resets has been done. As part of the triage process, the scanning of network assets will begin again to validate that infected host are in fact remediated fully. Once the scanning reports validate full remediation the assets can now be reintroduced into the network. This also includes reopening necessary ports for business and reinitializing services. Additionally, the original incident ticket created in ServiceNow will be updated and remain open to allow for post-incident information inclusion.PII Breach PlaybookA properly developed Playbook is considered one of the most important aspects to successful remediation. In linear fashion, it explicitly details each step in a systematic manner for each phase of the incident response lifecycle. Below you will find the Playbook developed specifically for a PII Breach. Some of the steps within the categories are universal and can be applied to many Playbooks. There are also multiple steps specific to this compromise. We will not be going into depth on every single step for each stage of the incident response Playbook but will summarize and highlight the key points that should be taken into consideration.PreparationIt is during the preparation phase of the incident response process that identifies each and every aspect of the steps necessary to achieve a successful end-to-end recovery. Preparation is the first stage of the program and it is by far the single most important aspect of the incident response lifecycle. It is during the stage that policies, documentation, and procedures are drafted reviewed and practiced.Specifically concerning the current PII Breach, it will be quintessential in thoroughly reviewing the specific policy on PII Breaches pertaining to the company. It will also be an essential time for all necessary stakeholders, executive staff, incident response teams, and any other individuals that are relevant to the situation. The primary means of communication will be through email chains and via ticketing systems such as the one used in this scenario ServiceNow.DetectionMoving from the preparation to detection phase there will be multiple actions that will occur.This is where enrichment actions pertaining to the portions of the Runbook can be validated and cross referenced with other types of threat intelligence reputation feeds. Being able to successfully validate IP addresses, Domain Names, Geolocations, and infected assets provides the needed information to guarantee that the artifacts and indicators of compromise are in fact malicious.AnalysisDuring the analysis phase we can take all of the information that has been gathered from the logs, along with all of the intelligence data obtained on the artifacts for incident review.This is a very important aspect of the incident response lifecycle because if the information provided turns out to be a false positive the entire compromise will be finalized and no further actions will be taken. If it turns out to be an actual incident then processes associated with prioritization and criticality will take hold and various types of matrices shall be created.ContainmentAfter the analysis phase is complete, the containment of the compromise is to follow.During this stage a multitude of actions will take place, such as isolating the compromised host, requiring users to reset their passwords. The purpose behind this is to ensure that the threat actor that has invaded the system will no longer have their user credentials to traverse through the system. Additionally, it will be necessary to block certain IPs’ and Domain Names that are associated with the incident.EradicationThe eradication portion will conduct certain actions to facilitate in eliminating all malicious artifacts associated with the compromise. This will include reimagining the compromised asset if necessary and performing forensics operations on any other network assets that may have been subject to the attack. It will also be necessary to run another network scan to validate that all remediation on the compromised assets are in fact clear of any residual malicious content.RecoveryThe actions of the recovery phase are very similar to that of the eradication phase in the sense that certain remediation actions go hand-in-hand. For instance, once the compromised assets have been reimaged they will have their network and port configurations reset and introduced back into environment. Moreover, an important aspect about the recovery phase is that all of the status reports of all the phases will be accumulated and prepared for the next phase which is the lessons learned phase.Lessons LearnedThe lessons learned phase could be considered one of the most important aspects of the incident response lifecycle. It is here that all of the documentation and information is stored, reviewed, and used for lessons to be learned.Oftentimes the outcome of the lessons learned phase will result in certain company policies being modified or network systems that may need to be reconfigured, to prevent the possibility of a future compromise such as the one experienced.In SummaryThis will conclude our hypothetical PII Breach attack scenario. Everyday companies both large and small alike are being breached through very simple attack methods. This is why it is incredibly important to have the right security tools in place with the ability to have the functionality of full orchestration and automation. These tools help prevent and combat against not only PII Breaches but also any type of cybersecurity attack. Through the incorporation of IncMan SOAR’s Playbooks and Runbooks being able to fully automate and orchestrate these security tools that an organization’s security program uses will drastically reduce the success of a particular attack type such as the one illustrated above.Download our eBook "The Most Comprehensive eBook on SOAR Use Cases", and learn how to automate your security operations workflow, accelerate the efficiency of your SecOps team, and combat cyber threats with the power of SOAR technology.

READ MORE
/ 09 Nov 2018

This use case will demonstrate how to utilize IncMan’s integrations and R3 Rapid Response Runbooks to quickly alert the security team to a potential phishing attempt, triage any attachments, and take action to delete malicious attachments and reset the affected user’s password.GoalsAutomatically receive potentially malicious email and extract attachmentsEvaluate the attachment and search for other instances of that attachment across the enterpriseGather user information for the affected user and system information for the affected host, including running processesReset the victim’s password and send notification of the recent change to the account userIntegrations UsedExchange EWSRecorded FutureCustom ScriptsEmail NotificationMicrosoft Active DirectoryImplementationCreating an R3 Rapid Response RunbookThe first step necessary to create an R3 Runbook is to outline how the organization will want to handle potential phishing emails. Understanding the processes and procedures for handling this type of event will help lay the foundation for automating the response.Before responding to any type of event an investigator must research aspects of the activity observed. This research is done through Enrichment tasks. These tasks will be based on the assumption that the incoming email contains the following information at a minimum:Recipient’s email addressEmail attachmentInformation Gathering & EnrichmentBefore we can respond to a suspicious email we must first gather information regarding the email and its sender to determine how it should be handled. Our R3 Runbook will begin by searching the EWS instance for additional emails received from the sender and verify the existence of any attachments in the emails located.Once we have queried for attachments our runbook will come to its first conditional argument. If there are attachments present, the R3 Runbook will check the attachment’s MD5 hash against two separate file reputation services. If either of those reputation services reports a risk score above a 50, our runbook will begin to take further containment and notification actions.Containment & NotificationIf the risk score has been confirmed to be above 50, the runbook will simultaneously delete the malicious attachments and query Active Directory for the affected user’s information. Armed with the affected user’s Active Directory information, our runbook will execute a custom script to generate a new random password for this user account. This newly created password will be set for our affected user account, we will force the user to reset their password upon next login, and a notification will be sent to the user containing these new login credentials.Utilizing the R3 Rapid Response RunbookOnce the new R3 Runbook is created, IncMan must be told how and when to automate the use of this Runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for a newly discovered vulnerability. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.In addition to incident information, the Incident Template also allows R3 Runbooks to be automatically assigned and executed each time the incident template is used. Assigning the previous R3 Runbook to the Vulnerability Management Incident Template will cause the R3 Runbook to be automatically run for each matching incident.Finally, conditions must be set to indicate when IncMan should utilize the Exchange EWS Phishing Incident Template. In this use case, the Phishing Incident Template will be used to create an incident each time a potentially malicious email communication is forwarded from an organization’s user.Solution in ActionWhen an email message is received from an organization’s user, IncMan will automatically generate a new incident based on the Exchange EWS Phishing Incident Template.Without requiring any action on the part of an analyst, the Exchange EWS Phishing Runbook is initiated, executing the Information Gathering and Enrichment, Containment, and finally the Notification sections automatically. The following screenshots show some of the information which may be available to the security analyst as a result of the execution of these two sections.SummaryThis use case frees up security teams from having to triage potentially malicious email communications submitted by their users and allows for their time to be better spent on tasks which require human intervention.The automated portions of this R3 Runbook can be executed in less than 60 seconds, orders of magnitude less than it would take an analyst to manually query all of these information sources. By automating responses to these malicious communications, it ensures our attackers would have less time to dwell in our environments and cuts them off at the pass preventing any lateral movement and further destruction or damage.Download our eBook "The Most Comprehensive eBook on SOAR Use Cases", and learn how to automate your security operations workflow, accelerate the efficiency of your SecOps team, and combat cyber threats with the power of SOAR technology.

READ MORE
/ 03 Jul 2018

This use case demonstrates how to use IncMan’s integration with LogPoint and R3 Rapid Response Runbooks to quickly respond to an alert indicating potentially malicious network traffic originating from an internal host, destined for an unknown host on the Internet. Goal: Automatically receive alerts for potentially malicious outbound network traffic from LogPoint, create an Incident within IncMan and use IncMan to perform automated Notification, Enrichment and Containment tasks to assess and mitigate any potential risk to the organization. Integrations Used: LogPoint Hacker Target Palo Alto Networks NGFW Microsoft SQL Server VirusTotal Implementation: Configuring LogPoint to Forward Events Prior to configuring IncMan, LogPoint must be configured to forward relevant events to IncMan. A custom LogPoint plugin is available from LogPoint which makes the setup and maintenance of these forwarding rules quick and easy. LogPoint event forwarding can be configured on a per-rule basis via the alert rule settings, or in bulk via the plugin settings. Once configured, the LogPoint plugin will forward all matching events to the IncMan server via syslog in CEF format. Creating an R3 Rapid Response Runbook The first step in creating an automated response to any event forwarded from LogPoint is to create an R3 Rapid Response Runbook which will perform automated actions as part of the response to the event. We will assume that the alert has provided a minimum of a source IP address and a destination IP address, although the alert will likely contain much more detailed information. In addition to the LogPoint integration, this use case will use integrations with Hacker Target, Palo Alto Networks NGFW, Microsoft SQL Server, and VirusTotal, as well as some of IncMan’s built-in Enrichment functions, to perform Enrichment, Notification and Containment actions. The specific integrations used in this use case could easily be replaced with other similar technology already deployed in the organization. The Runbook begins by performing several basic information gathering Enrichment actions; a WHOIS query, IP Geolocation and a reverse DNS query on the malicious external destination IP address. In this case, this information is not used as part of the automated decision-making process, although it easily could be. Instead, this information will be automatically saved as part of the Incident and will be available to the security analyst to review at any time. Following these basic information gathering Enrichment actions, an integration with Palo Alto Network’s NGFW is used to perform a Containment action, blocking the malicious external destination IP address at the network perimeter. Once the immediate threat has been contained by blocking the malicious external destination IP address at the perimeter, IncMan’s integration with LogPoint is used to query further information from LogPoint via an Enrichment action. A specially crafted LogPoint search query is used to query LogPoint for a list of all IP addresses the internal source IP address has communicated within the past 30 minutes. This list of IP addresses is then passed to an additional Enrichment action which will perform threat reputation queries on each of the IP addresses. In this use case, IncMan’s integration with VirusTotal is used to perform the threat reputation queries, however, another threat reputation source could easily be substituted here as well (for example, Cisco Umbrella, McAfee ATD or Recorded Future). Following the threat reputation queries, a decision point is reached at which point any other external IP addresses the original internal source IP address has been observed communicating with which have now been deemed malicious through the threat reputation service will continue to be processed further. This further processing begins by performing the same set of Enrichment and Containment actions on the additional malicious external IP addresses that the original malicious external IP address received. After basic Enrichment has been performed on these additional malicious external IP addresses and these addresses have been blocked at the perimeter, the Runbook again utilizes a LogPoint Enrichment action to query further information from LogPoint. This time, a specially crafted LogPoint query is used to search LogPoint for a list of any other internal hosts which have been observed communicating with any of the additionally identified malicious external IP addresses. Since these additionally identified malicious external IP addresses have already been blocked at the perimeter firewall, no additional containment actions are necessary at this point. However, it is important that security analysts follow up on each of the internal hosts which have been identified as communicating with malicious external IP addresses. To that end, an Enrichment action is used to query a Microsoft SQL Server database containing the organizations IT asset inventory. While this information is not used in further automated actions, it will help the security analysts identify and prioritize the investigation of these hosts. Finally, to ensure that each additionally identified internal host is properly investigated, a Notification action is used to notify security managers about each individual host which has been identified. Using IncMan’s integration with LogPoint, this Runbook has not only enriched and contained the information from the original alert, it has also pivoted twice; identifying, enriching and containing any additional external malicious IP addresses that the original internal source IP address may have communicated with, then identifying any other internal hosts which may have communicated with these additionally identified malicious external IP addresses. This automated process closely mirrors the manual process security analysts would have taken to handle this alert, however automating this process has saved the security team hours of manual research and information aggregation. Utilizing the R3 Rapid Response Runbook Once the new Runbook is created, IncMan must be told how and when to automate the use of this Runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for potentially malicious outbound network traffic. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident. From the Runbook tab of the Incident Template wizard, the previously created Malicious LogPoint Runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as the source and destination IP addresses will be used as inputs to the Runbook and the Runbook will be automatically executed. Once the Incident Template has been defined, all that is left to do is create the rule which will trigger the IncMan Incident to be created based on the template when a matching event is received from LogPoint. These rules can be based on any component of the event, including application name, rule ID, system attributes or matching text. For example: With the appropriate rule in place, an action must be defined. In this case, the desired action is to create a new Incident using our previously defined Incident Template and assign the incident to the incident queue, as shown: Finally, we define the variable artifacts that should be automatically extracted from the alert and added to the IncMan Incident. Although the previously defined runbook utilizes only source and destination IP address, additional information may be available and could be added to the Incident. In this case, source and destination port, as well as bytes in and bytes out are also extracted from the event. Solution in Action From this point forward, any event received by IncMan which matches the criteria set in the syslog rule will generate a new IncMan Incident according to the previously configured Incident Template and contain the specified variable artifacts extracted from the event. As part of this process, the Runbook created in the previous section will be automatically assigned to the incident and executed, perform Enrichment and Containment on both the original event information, as well as the additional information gathered from LogPoint. What may have previously take hours of analyst time will be automatically executed in a matter of minutes, potentially completing before an analyst would have had time to even acknowledge the alert. Download our eBook "The Most Comprehensive eBook on SOAR Use Cases", and learn how to automate your security operations workflow, accelerate the efficiency of your SecOps team, and combat cyber threats with the power of SOAR technology.

READ MORE
/ 02 Jul 2018

This use case demonstrates how to use IncMan’s integrations and R3 Rapid Response Runbooks to quickly respond to hosts exposed to the Meltdown and Spectre vulnerabilities, reducing the risks posed by these potentially critical issues.Goal:Automatically receive alerts for host which have been identified as being vulnerable to Meltdown or Spectre, create an Incident and perform automated Notification, Enrichment and Containment tasks to reduce the risk these vulnerabilities present to the organization.Integrations Used:JiraMcAfee ePOMcAfee Web GatewayMSSQL ServerQRadarImplementationCreating an R3 Rapid Response RunbookThe first step in reducing the risk from the Meltdown and Spectre vulnerabilities is to create a runbook to handle alerts for newly detected vulnerable hosts. In this use case, we will use integrations with Jira, McAfee ePO, McAfee Web Gateway, MSSQL Server and QRadar to perform Notification, Enrichment and Containment actions; however, this can easily be adapted to include any other technology integrations as well.Using a Jira Notification action, a new Jira issue is created. This Notification action should notify the IT or Infrastructure teams and initiate the organizations normal vulnerability management process.Next, an MSSQL Server Enrichment action is used to query an IT asset inventory for the host name of the vulnerable host, which is passed to the runbook automatically when the incident is created. This asset information is then available to the analyst for further review.Once the IT asset information is retrieved, a decision point is reached. If the IT asset information indicates that the host is a server, one path (the top path) is taken. If the IT asset information indicates that the host is not a server, another path (the bottom path) is taken.If the asset is determined to be a server the Jira Enrichment action is used to update the Jira issue, informing the appropriate parties that the host has been determined to be a server and should be treated as a higher priority. Next, two McAfee ePO Enrichment actions are performed. The first Enrichment action queries McAfee ePO for the system information of the given hostname, providing the analyst with additional information. The second Enrichment action uses McAfee ePO to tag the host with the appropriate tag. Finally, a Task is added to IncMan reminding the analyst to follow up with the appropriate teams to ensure that the vulnerability has been appropriately mitigated.If the asset is determined not to be a server, the two previously mentioned McAfee ePO Enrichment actions are immediately be run (System Info and TAG). Following these two Enrichment actions, a McAfee Web Gateway Containment action is used to block the host from communicating outside of the network. This Containment step is completely optional but is performed here on non-servers only to minimize the Containment action’s potential impact on critical systems.Utilizing the R3 Rapid Response RunbookOnce the new runbook is created, IncMan must be told how and when to automate the use of this runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for a Meltdown or Spectre vulnerability. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.From the Runbook tab of the Incident Template wizard, the previously created Meltdown and Spectre runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as hostname and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.In this use case, alerts from QRadar are utilized to initiate automatic incident creation within IncMan. However, another SIEM integration, syslog or email could also be utilized to achieve the same outcome. A new QRadar Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Meltdown and Spectre Incident Template.Solution in ActionWhen a QRadar Alert is generated matching the criteria defined for a Meltdown or Spectre vulnerability detection, IncMan will automatically generate a new incident based on the Meltdown and Spectre Incident Template.Without requiring any action on the part of an analyst, the Meltdown and Spectre runbook is automatically initiated, performing the defined Notification, Enrichment and Containment actions (in the example shown here, the ‘server’ path is taken).This entire process has taken place in a matter of minutes, likely before anyone has even had time to acknowledge the alert. As an analyst begins to manually examine the alert, many of the mundane tasks have already been completed, allowing the analyst to focus on the tasks which require human intervention and reducing the time required to remediate this issue, ultimately reducing risk to the organization.Download our eBook "The Most Comprehensive eBook on SOAR Use Cases", and learn how to automate your security operations workflow, accelerate the efficiency of your SecOps team, and combat cyber threats with the power of SOAR technology.

READ MORE
/ 06 Jun 2018

This use case demonstrates how to use IncMan’s integrations and R3 Rapid Response Runbooks to quickly respond to an alert indicating potentially malicious network traffic originating from an internal host, destined for an unknown host on the Internet.Goal:Automatically receive alerts for potentially malicious outbound network traffic from a device such as a web gateway or IDS/IPS, create an Incident and perform automated Notification, Enrichment and Containment tasks assess and mitigate any potential risk to the organization.Integrations Used:Cisco ThreatgridHacker TargetMcAfee Web GatewayPostgreSQLVirusTotalImplementation:Creating an R3 Rapid Response RunbookThe first step in creating an automated response to this type of incident is to create an R3 Rapid Response Runbook which will perform Enrichment, and if necessary, Containment actions as part of the response. We will assume that the alert has provided a minimum of a source IP address and a destination IP address, although the alert will likely contain much more detailed information. In this use case, we will use integrations with Cisco Threatgrid, Hacker Target, McAfee Web Gateway, PostgreSQL and VirusTotal, as well as some of IncMan’s built-in Enrichment functions, to perform Enrichment and Containment actions. The specific integrations used in this use case could easily be replaced with other similar technology already deployed in the organization.The Runbook begins by performing several basic information gathering Enrichment actions; IP Geolocation, a WHOIS query and a reverse DNS query. In this case, this information is not used as part of the automated decision-making process (although it easily could be). Instead, this information will be automatically saved as part of the Incident and will be available to the security analyst to review at any time.Following these basic information gathering Enrichment actions, additional Enrichment actions are utilized to query two different threat reputation services. In this case, we have chosen to use both VirusTotal and Cisco Threatgrid, although IncMan also has integrations with several other threat reputation and intelligence services, such as Recorded Future and Threat Connect. Following each of these two queries, an automated decision point is reached. These automated decision points will examine the information returned by each threat reputation service and determine if the results meet a certain user-defined threshold. This user-defined threshold could be based on any of the information returned by each service, such as the overall threat score or the number o records returned.If neither threat reputation service returns information which meets or exceeds the user-defined thresholds, no further automated actions will be taken and the information will be saved as part of the Incident and will be available to the security analyst to review at any time.If either threat reputation service returns information which meets or exceeds the user-defined thresholds, the Runbook will continue by performing a query of the IT asset inventory using a PostgreSQL Enrichment action. Like the previous basic information gathering Enrichment actions, this information will not be used directly for automated decision making; however, it will also be available to the security analyst to review as part of the Incident record.The final Enrichment action utilizes the same PostgreSQL integration, this time to query a database of known-good, or whitelisted hosts to see if the external destination IP address matches a known-good host. This assumes that the organization has pre-populated the table with the IP addresses, hostnames and other information regarding hosts which are known to be non-malicious or should not be blocked for one reason or another.Following this final Enrichment action, another automated decision point is reached. This decision point will determine if the query of the known-good host database yielded any results. If the external destination IP address matches a known-good host, the runbook will conclude without further actions. If no matches were found, a special type of decision point will be reached; a User Choice decision. A User Choice decision will temporarily halt the automatic execution of the Runbook and will prompt the security analyst to make a manual decision. In this case, the security analyst is prompted with the question “Would you like to block the destination IP address?” While the Runbook is temporarily paused, the security analyst has the opportunity to examine the results of all the previous Enrichment actions as part of the manual decision-making process. This step is entirely optional, however, adds an additional layer of assurance that the blocking the destination IP address will not result in adverse consequences. Once the security analyst makes a decision and selects the appropriate option, the automated execution of the Runbook will continue.If the security analyst determines that the destination IP address should not be blocked, the Runbook will conclude without further action. If the security analyst determines that the destination IP address should be blocked, a Containment action will utilize IncMan’s integration with McAfee Web Gateway to block the address. Following this Containment action, the Runbook will conclude.Utilizing the R3 Rapid Response RunbookOnce the new Runbook is created, IncMan must be told how and when to automate the use of this Runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for potentially malicious outbound network traffic. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.From the Runbook tab of the Incident Template wizard, the previously created Malicious Outbound Traffic Runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as the source and destination IP addresses will be used as inputs to the Runbook and the Runbook will be automatically executed.In this use case, an alert received from a simulated web gateway is used to initiate automatic incident creation within IncMan. However, a SIEM integration or email could also be utilized to achieve the same outcome. A new syslog Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Malicious Outbound Traffic Incident Template.Solution in ActionWhen a syslog message matching the criteria pre-defined for the detection of malicious outbound network traffic, IncMan will automatically generate a new incident based on the Malicious Outbound Traffic Incident Template.Without requiring any action on the part of an analyst, the Malicious Outbound Traffic Runbook is automatically initiated, performing the Enrichment actions and pausing at the User Choice decision point. At this point, the security analyst has the opportunity to review all of the information gathered from the previous Enrichment actions, including the information returned from VirusTotal.In this case, VirusTotal has returned dozens of results matching the destination IP address. Based on this information, the security analyst has determined that blocking the destination IP address is the appropriate action and approves the User Choice decision. At this point, the automation continues and the McAfee Web Gateway Containment action is executed before the Runbook execution concludes.This entire process, from receipt to containment, has taken place in a matter of minutes, likely before a security analyst would have been able to even manually acknowledge the alert under normal circumstances. IncMan’s automation and orchestration functions automated the initial response and provided the security analyst with all the information necessary to make an informed decision and contain the threat immediately.Download our eBook "The Most Comprehensive eBook on SOAR Use Cases", and learn how to automate your security operations workflow, accelerate the efficiency of your SecOps team, and combat cyber threats with the power of SOAR technology.

READ MORE

Get Started with a One-to-One Personalized Demo

Dramatically reduce the mean time to detection, response and remediation of all potential security incidents, ensuring no alert goes untouched.
See IncMan SOAR in Action.

Request a demo

Award-Winning SOAR Platform.

Top 100 in Europe

Best Security Orchestration Automation and Response

Security Automation and Orchestration

Security Orchestration, Automation and Response

Best Continuous Monitoring & Mitigation