Why Cisco doesn't buy Splunk or a story about how the Cisco platform works for threat hunting
About once every six months, some American journalist publishes a conspiracy note that Cisco is about to buy Splunk and enter the SIEM segment, since this is exactly what we lack for the final conquest of the global information security market (although we already were named vendor number 1 in March). However, writing journalists usually forget that Cisco has already developed a SIEM, which it called OpenSOC and donated for further development at the Apache Foundation (where OpenSOC is being developed under the name Apache Metron). But this is a joke, but in reality the reason is different. There is no vendor in the world who has a wide product portfolio on information security and at the same time could support the multi-vendor solution SIEM. Rare attempts of this kind either lead to the fact that the vendor cannot make a normal vendor-independent monitoring solution and starts losing to niche players (Splunk, IBM, Micro Focus, Elastic, LogRhytm, etc.) focused only on the development of its flagship product, or to the fact that the SIEM turns into a regular console for its own products without a normal management and response subsystem (all forces rush to monitoring). Cisco, entering the river twice under the name “SIEM” (the first time with CiscoWorks SIMS, and the second with Cisco MARS), today focuses on a slightly different solution, namely Cisco Threat Response , which is a threat hunting platform and that in the future should be a link for all Cisco cybersecurity solutions.
When communicating with customers, they usually describe roughly the same tasks, which sound like this:
')
If it were not for the last desire, one could offer a whole range of different solutions for Threat Hunting, each of which solves its own problem. Or you can offer a “combine” based on any SIEM or SOAR solution, which, however, stands like a spaceship. We decided to do it easier by developing a lightweight and free threat-hunting platform, Cisco Threat Response, which, as an intermediary between SIEM / SOAR and protection tools, allows you to get the most out of using Cisco solutions by combining them into an integrated cybersecurity system.
A year ago, when we just released this platform (it was also called differently - Cisco Visibility ), it could only receive data from three Cisco solutions - AMP for Endpoints, Threat Grid and Umbrella (as well as from an external source of VirusTotal). Over the past year, we have significantly expanded the possible CTR, integrating it with Cisco Email Security and Cisco Firepower. Now we have the opportunity to analyze security events received not only at the terminal device level, but also at the email and network security level.
Let's take a look at how CTR integration with Cisco Email Security (ESA) works. Suppose you receive an email notification from Cisco ESA about a malicious attachment found in one of the email messages. Please note that this is not about detecting a threat on the fly, but about a retrospective analysis, which allowed some time after receiving a letter with an unknown attachment to make a conclusion about its harmfulness. Now we are faced with the task of understanding who “got under the distribution” and who among the recipients did not have time to open the attachment and infect their computer, thereby beginning the spread of malicious code over the corporate or departmental network.
The resulting indicators (in this case, this hash of the attachment) are placed in the initial CTR window. We can copy the text of the entire letter received from Cisco ESA - CTR will pull out all indicators of compromise from it.
Further CTR begins its work and reveals that the attachment fell into five mailboxes. In addition, this file was found on one of the internal nodes of the company.
The user may have already managed to open this attachment or save it on his computer. The user may have received this file in a different way (for example, on a flash drive or by downloading it from any site on the Internet). In this case, we are most likely dealing with the first option, since the name of the compromised computer coincides with one of the mailboxes that received the malicious attachment.
It seems that the problem is solved and we can block this threat using Cisco AMP for Endpoints without leaving the CTR. But within the framework of the investigation, we are also interested in whether the PC with the address 192.168,243.108 has become a springboard for the development of the attack or is it connected to an external command server?
Our suspicions were justified - the victim's computer is connected to an external and malicious host with the address 62.210.170.57, which in turn is associated with two other malicious files that we can, with a clear conscience, blacklist on AMP for Endpoints or other means of protection.
By the way, please note that you can use as indicators of compromise not only hash data that is checked through Cisco Email Security, but also the names of the senders / recipients of email messages, as well as their topics and other e-mail header fields. This feature allows you to turn the CTR into a tool for analyzing not only malicious activity, but also other aspects of the organization’s activities. I dare to call the CTR visualizer for DLP, which is built into the Cisco ESA.
In general, CTR integration with Cisco ESA allows information security analysts to answer the following questions:
At Cisco Live, which took place in San Diego in early June, we announced the integration of CTR with our flagship security tool, Cisco Firepower, a multifunctional security solution. Its next-generation firewall and intrusion detection subsystems can “send” security events to CTR related to malicious activity originating from an IP or URL. This information is displayed in the CTR and is associated with other data received from the terminal device or e-mail. Also through CTR, malicious IPs or URLs can be blocked on Cisco Firepower.
Another new feature in CTR is the Chrome and Firefox browser plugin, which allows you to analyze the current web page and pull out all indicators of compromise “in one click” (for example, from a blog of some company or information security researcher). In addition to automating the process of capturing indicators of compromise and reducing the number of errors when copying them, this plugin allows you to immediately mark for each IOC its status (pure or malicious), and also include the necessary indicators in the corresponding ticket (it is called Casebook), with which you can work in CTR.
One of the functions, the absence of which caused questions from our customers, was the impossibility of enriching IP addresses or file hashes with external sources of Threat Intelligence. At the time of launch, Cisco Threat Response supported only TI sources from Cisco (Cisco Talos, Cisco AMP Global, Cisco Threat Grid, and Cisco Umbrella), and from external sources, only VirusTotal. But now everything has changed - we opened an API that allows you to connect other TI sources, for example, GosSOPKU or FinCERT, BI.ZONE, Group-IB, Kaspersky Lab, or foreign services. Using the API, you can also automate the process of responding to detected incidents through third-party solutions. If your infrastructure uses Cisco security solutions, then response functions are already built into Cisco Threat Response:
In the last article about Cisco Visibility, I was asked if we could integrate not only with Cisco solutions, but also with third-party solutions. Then I answered in the affirmative, and today I can even show one example of such integration. In February, Signal Science turned to us, which is known in the world for its next generation WAF. This company wanted to integrate its solution with CTR. We gave them access to the documentation and code samples and 10 days later (only ten days), we were shown a working integration that allowed us to send data about events recorded by WAF to the CTR, including data on IP, compromise indicators and meta-data related to attack.
If you need more details about the incident, the analyst can open the Signal Science WAF directly from the CTR interface.
Using the API, users of Cisco and Signal Science solutions were able to:
I think you noticed above when I mentioned that this solution is free? Yes it's true. But to access it, you must have one of the following Cisco solutions deployed - Cisco AMP for Endpoints, Cisco Threat Grid, Cisco Umbrella, Cisco Email Security and Cisco NGFW / NGIPS (and other solutions in the future). If you are a happy owner of one of these products, then you can easily try out and start actively using the platform for analyzing threats to Cisco Threat Response. If you are a developer and want to integrate your security solutions with CTR, then you can easily do this after going through a little training and studying code examples on the Cisco DevNet Cisco Community Developer Platform.
When communicating with customers, they usually describe roughly the same tasks, which sound like this:
- we see millions of events from various defenses, but we are not sure whether they are missing something targeted and directed against us
- we have a lot of raw security events and we would like to enrich them with data on threat intelligence
- we receive bulletins from GosSOPKI, FinCERT and commercial companies, but we do not know what to do with them and how to check that the indicators of compromise described in them do not occur, and if they do, then immediately understand where exactly
- We would like to visualize the relationship between various artifacts and indicators of compromise in relation to our infrastructure and understand the scale of the disaster.
- we would like to find the threat, quickly block it in the best way
- we would like to record the picture of the IB at different points in time to track the dynamics
- we would like to share the results of the investigation with our subsidiaries or within a group of companies
- we need something simpler and preferably in one low-cost solution.
')
If it were not for the last desire, one could offer a whole range of different solutions for Threat Hunting, each of which solves its own problem. Or you can offer a “combine” based on any SIEM or SOAR solution, which, however, stands like a spaceship. We decided to do it easier by developing a lightweight and free threat-hunting platform, Cisco Threat Response, which, as an intermediary between SIEM / SOAR and protection tools, allows you to get the most out of using Cisco solutions by combining them into an integrated cybersecurity system.
A year ago, when we just released this platform (it was also called differently - Cisco Visibility ), it could only receive data from three Cisco solutions - AMP for Endpoints, Threat Grid and Umbrella (as well as from an external source of VirusTotal). Over the past year, we have significantly expanded the possible CTR, integrating it with Cisco Email Security and Cisco Firepower. Now we have the opportunity to analyze security events received not only at the terminal device level, but also at the email and network security level.
Let's take a look at how CTR integration with Cisco Email Security (ESA) works. Suppose you receive an email notification from Cisco ESA about a malicious attachment found in one of the email messages. Please note that this is not about detecting a threat on the fly, but about a retrospective analysis, which allowed some time after receiving a letter with an unknown attachment to make a conclusion about its harmfulness. Now we are faced with the task of understanding who “got under the distribution” and who among the recipients did not have time to open the attachment and infect their computer, thereby beginning the spread of malicious code over the corporate or departmental network.
The resulting indicators (in this case, this hash of the attachment) are placed in the initial CTR window. We can copy the text of the entire letter received from Cisco ESA - CTR will pull out all indicators of compromise from it.
Further CTR begins its work and reveals that the attachment fell into five mailboxes. In addition, this file was found on one of the internal nodes of the company.
The user may have already managed to open this attachment or save it on his computer. The user may have received this file in a different way (for example, on a flash drive or by downloading it from any site on the Internet). In this case, we are most likely dealing with the first option, since the name of the compromised computer coincides with one of the mailboxes that received the malicious attachment.
It seems that the problem is solved and we can block this threat using Cisco AMP for Endpoints without leaving the CTR. But within the framework of the investigation, we are also interested in whether the PC with the address 192.168,243.108 has become a springboard for the development of the attack or is it connected to an external command server?
Our suspicions were justified - the victim's computer is connected to an external and malicious host with the address 62.210.170.57, which in turn is associated with two other malicious files that we can, with a clear conscience, blacklist on AMP for Endpoints or other means of protection.
By the way, please note that you can use as indicators of compromise not only hash data that is checked through Cisco Email Security, but also the names of the senders / recipients of email messages, as well as their topics and other e-mail header fields. This feature allows you to turn the CTR into a tool for analyzing not only malicious activity, but also other aspects of the organization’s activities. I dare to call the CTR visualizer for DLP, which is built into the Cisco ESA.
In general, CTR integration with Cisco ESA allows information security analysts to answer the following questions:
- What e-mail messages contain a file with such a name or such and such a hash?
- Which e-mail messages contain such a topic?
- What email messages were sent by such a sender?
- What e-mail messages are associated with such-or-such IP or the sender's domain?
- What are the details of a message with such a Message ID?
At Cisco Live, which took place in San Diego in early June, we announced the integration of CTR with our flagship security tool, Cisco Firepower, a multifunctional security solution. Its next-generation firewall and intrusion detection subsystems can “send” security events to CTR related to malicious activity originating from an IP or URL. This information is displayed in the CTR and is associated with other data received from the terminal device or e-mail. Also through CTR, malicious IPs or URLs can be blocked on Cisco Firepower.
Another new feature in CTR is the Chrome and Firefox browser plugin, which allows you to analyze the current web page and pull out all indicators of compromise “in one click” (for example, from a blog of some company or information security researcher). In addition to automating the process of capturing indicators of compromise and reducing the number of errors when copying them, this plugin allows you to immediately mark for each IOC its status (pure or malicious), and also include the necessary indicators in the corresponding ticket (it is called Casebook), with which you can work in CTR.
One of the functions, the absence of which caused questions from our customers, was the impossibility of enriching IP addresses or file hashes with external sources of Threat Intelligence. At the time of launch, Cisco Threat Response supported only TI sources from Cisco (Cisco Talos, Cisco AMP Global, Cisco Threat Grid, and Cisco Umbrella), and from external sources, only VirusTotal. But now everything has changed - we opened an API that allows you to connect other TI sources, for example, GosSOPKU or FinCERT, BI.ZONE, Group-IB, Kaspersky Lab, or foreign services. Using the API, you can also automate the process of responding to detected incidents through third-party solutions. If your infrastructure uses Cisco security solutions, then response functions are already built into Cisco Threat Response:
- blocking a file with an appropriate hash or quarantining a file / process via Cisco AMP for Endpoints
- domain blocking via Cisco Umbrella
- Mail Email Quarantine via Cisco Email Security (in future releases)
- IP and URL blocking via Cisco NGFW / NGIPS (in future releases)
- URL blocking via Cisco Web Security / SIG (in future releases)
- internal site quarantine through Cisco ISE (in future releases).
In the last article about Cisco Visibility, I was asked if we could integrate not only with Cisco solutions, but also with third-party solutions. Then I answered in the affirmative, and today I can even show one example of such integration. In February, Signal Science turned to us, which is known in the world for its next generation WAF. This company wanted to integrate its solution with CTR. We gave them access to the documentation and code samples and 10 days later (only ten days), we were shown a working integration that allowed us to send data about events recorded by WAF to the CTR, including data on IP, compromise indicators and meta-data related to attack.
If you need more details about the incident, the analyst can open the Signal Science WAF directly from the CTR interface.
Using the API, users of Cisco and Signal Science solutions were able to:
- analyze and correlate data from different information security solutions that complement each other
- combine in a single ticket indicators of compromise from different solutions
- cross-react to threats detected by Signal Science using Cisco solutions.
I think you noticed above when I mentioned that this solution is free? Yes it's true. But to access it, you must have one of the following Cisco solutions deployed - Cisco AMP for Endpoints, Cisco Threat Grid, Cisco Umbrella, Cisco Email Security and Cisco NGFW / NGIPS (and other solutions in the future). If you are a happy owner of one of these products, then you can easily try out and start actively using the platform for analyzing threats to Cisco Threat Response. If you are a developer and want to integrate your security solutions with CTR, then you can easily do this after going through a little training and studying code examples on the Cisco DevNet Cisco Community Developer Platform.
Source: https://habr.com/ru/post/456234/
All Articles