Why doesn't Cisco buy Splunk or a talk about how the Cisco platform works for threat hunting

    About once every six months, an American journalist publishes a conspiracy note that Cisco is about to buy Splunk and enter the SIEM segment, as this is exactly what we lack for the final conquest of the global information security market (although we already were named vendor No. 1 in March). However, writing journalists usually forget that Cisco has already developed SIEM, which OpenSOC calledand gave it for further development at the Apache Foundation (where OpenSOC is already developing under the name Apache Metron). But this is a joke, but in fact the reason is different. There is no vendor in the world who would have a wide product portfolio for information security and at the same time be able to support the SIEM multi-vendor solution. Rare attempts of this kind lead either to the fact that the vendor cannot make a normal vendor-independent monitoring solution and it begins to lose to niche players (Splunk, IBM, Micro Focus, Elastic, LogRhytm, etc.), concentrating only on the development of their flagship product, or to the fact that SIEM turns into a regular console for its own products without a normal control and response subsystem (all forces are thrown to monitoring). Cisco, entering the river twice under the name “SIEM” (the first time with CiscoWorks SIMS, and the second with Cisco MARS),Cisco Threat Response , which is a threat hunting platform that should become the link in the future for all Cisco cybersecurity solutions.

    image

    Communicating with customers, they usually describe about the same tasks, which are as follows:

    • we see millions of events from different remedies, but we are not sure if they are not missing something targeted and directed specifically against us
    • we have a lot of raw IB events and we would like to enrich them with threat intelligence data
    • we receive newsletters from GosSOPKI, FinCERT and commercial companies, but we do not know what to do with them and how to verify 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 to understand the scale of the disaster
    • we would like to find a threat to quickly block it in the best way
    • we would like to capture the picture of IB at different points in time to track the dynamics
    • we would like to share the results of the investigation with our subsidiaries or as part of a group of companies
    • we need something simpler and preferably in one inexpensive solution.

    image

    If not for the last wish, one could offer a whole range of different Threat Hunting solutions, each of which solves its own problem. Or you can offer a “harvester” based on some SIEM- or SOAR-solution, which, however, is like a spaceship. We decided to do it easier by developing the lightweight and free threat-hunting platform Cisco Threat Response, which, as an intermediate between SIEM / SOAR and security tools, allows you to get the most out of using Cisco solutions by combining them into a single cybersecurity system.

    image

    A year ago, when we first released this platform (then it was also called differently - Cisco Visibility), it could receive data only from three Cisco solutions - AMP for Endpoints, Threat Grid and Umbrella (as well as from an external source VirusTotal). Over the past year, we have significantly expanded the capabilities of CTR by integrating it with Cisco Email Security and Cisco Firepower. Now we have the opportunity to analyze security events received not only at the level of terminal devices, but also at the level of email and network security.

    Let's see how CTR integration with Cisco Email Security (ESA) works. Suppose you receive an e-mail notification from Cisco ESA about a malicious attachment detected in one of the mail messages. Please note that this is not about detecting a threat on the fly, but about a retrospective analysis, which made it possible to draw a conclusion about its harmfulness some time after receiving a letter with an unknown attachment. Now we are faced with the task of understanding who “fell under the distribution” and if any of the recipients managed to open the attachment and infect their computer, thereby giving rise to the spread of malicious code over the corporate or departmental network.

    image

    The resulting indicators (in this case, an attachment hash) we put in the initial CTR window. We can copy the entire text of the letter received from Cisco ESA - the CTR itself will pull out all the indicators of compromise from it.

    image

    Further, CTR begins its work and reveals that this attachment fell into five mailboxes. In addition, this file was found on one of the internal nodes of the company.

    image

    Perhaps the user has already managed to open this attachment or save it on his computer. Perhaps the user received this file in a different way (for example, on a USB flash drive or by downloading from a website on the Internet). In this case, we are most likely dealing with the first option, since the name of the compromised computer is similar to the name of one of the mailboxes that received the malicious attachment.

    image

    It seems that the problem has been solved, and we can block this threat using Cisco AMP for Endpoints without leaving the CTR. But as part of the investigation, we are also interested in whether this 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?

    image

    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 more files whose verdict is not yet known and which, after investigation, we can blacklist on AMP for Endpoints or on other means of protection.

    image

    By the way, note that you can use not only hash data that is verified through Cisco Email Security as indicators of compromise, but also the names of senders / recipients of email messages, as well as their subject and other e-mail header fields. This feature allows you to turn CTR into a tool for analyzing not only malicious activity, but also other aspects of the organization. I dare to call the CTR visualizer for DLP, which is built into the Cisco ESA.

    In general, the integration of CTR with Cisco ESA allows IS analysts to answer the following questions:

    • What e-mail messages contain a file with such a name or such a hash?
    • What e-mail messages contain such a subject?
    • What e-mail messages were sent by such a sender?
    • What e-mail messages are associated with such IP or sender domain?
    • What are the details of a message with such a Message ID?

    At Cisco Live, which was held in early June in San Diego, we announced the integration of CTR with our flagship security tool, the Cisco Firepower multifunctional security solution. Its next-generation firewall and intrusion detection subsystems can “send” to the CTR security events associated with malicious activity originating from an IP or URL. This information is displayed in the CTR and associated with other data received from the terminal device or email. Also, through CTR, malicious IPs or URLs can be blocked on Cisco Firepower.

    image

    Another innovation in CTR was the plug-in for the Chrome and Firefox browser, which allows you to analyze the current web page and pull out all the indicators of compromise “in one click” from it (for example, from the blog of a 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 flag its status for each IOC (clean or malicious), and also include the necessary indicators in the corresponding ticket (called Casebook), which you can work with later in CTR.

    image

    One of the features, the lack of which raised questions from our customers, was the inability to enrich IP addresses or file hashes from external sources of Threat Intelligence. At the time of launch, the Cisco Threat Response supported only TI sources from Cisco (Cisco Talos, Cisco AMP Global, Cisco Threat Grid, and Cisco Umbrella), and from external ones only VirusTotal. But now everything has changed - we have 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 IB security solutions, then the response features are already built into Cisco Threat Response:

    • blocking a file with an appropriate hash or quarantining a file / process through Cisco AMP for Endpoints
    • domain blocking through Cisco Umbrella
    • Email Quarantine through Cisco Email Security (in future releases)
    • IP and URL blocking through Cisco NGFW / NGIPS (in future releases)
    • URL blocking through Cisco Web Security / SIG (in future releases)
    • Quarantine an internal host through Cisco ISE (in future releases).

    In a previous article about Cisco Visibility, I was asked if we can 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 contacted us, known worldwide for its next-generation WAF. This company wanted to integrate its solution with CTR. We gave them access to documentation and code examples and after 10 days (ten days in total) we were shown a working integration that allowed us to send data about events recorded by WAF to the CTR, including data on IP, indicators of compromise and meta-data related to attack.

    image

    If the analyst needs to move to a more detailed view of the incident, you can open the Signal Science WAF interface directly from the CTR interface.

    image

    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 indicators of compromise from different solutions within a single ticket
    • Cross-react to threats detected by Signal Science with Cisco solutions.

    I hope that my statement about the free CTR caught your attention? Yes it's true. But to access it, you must have deployed one of the following Cisco solutions - 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 the proud owner of one of these products, then you can easily test and start actively using the Cisco Threat Response threat analysis platform. If you are a developer and want to integrate your information security solutions with CTR, then you can easily do this after going through a little training and studying sample codes on the Cisco DevNet Cisco community platform for developers.

    Also popular now: