Carbon Black - Technology Integrations

Document created by Michael Wolff

on Nov 1, 2017•Last modified by Jason Tan on Nov 30, 2020

Version 4Show Document

Like • Show 0 Likes0
Comment • 4
View in full screen mode

RSA READY Technology Partner for light backgrounds.png

Cb Response is a purpose-built Endpoint Detection and Response solution for enterprise SOC and IR teams with a streamlined UI that’s built for speed, unlimited historical data retention, and unlimited scaling to fit even the largest enterprises. Achieve full visibility combining Cb Response with RSA NetWitness Suite for complete context of threats affecting the Enterprise.

Partner Product	RSA Product	Documentation & Downloads
Carbon Black Cb Response	RSA NetWitness	Parser Implementation Guide Parser Source Package

2 people found this helpful

Attachments

Outcomes

4 Comments

Vladimir Previn Jan 12, 2018 12:18 AM
it would be helpful to also get some sort of CB cloud to RSA integration , is that in the works.
the difference is - CB cloud (unless you allow syslog from the net ) can't syslog in.

so technically we'd need a CB API to LEEF connector
I've opened a corresponding topic on CB https://community.carbonblack.com/message/22386
Like • Show 0 Likes0
Actions
- Matthew Chase @ Vladimir Previn on Jan 12, 2018 2:39 PM
  Thanks for the suggestion, Vladimir. I'll add it to my list of 2nd level partnerships and discuss it with cb.
  Like • Show 0 Likes0
  Actions
- Jesse Lyon @ Vladimir Previn on Feb 27, 2018 10:52 AM
  When it comes to importing logs for web services that rely on APIs I've found a few ways to collect the logs. Your first option is to try to develop a plug in to support native calls from a VLC to the API service. I've found this is a bear to configure, but if you're comfortable with Python and not afraid to poke around in a VLC it can be done. This also gives you the option of creating a transform file to edit the data coming in to support any format or syntax you would like. This solution has a high degree of flexibility, but is also incredibly complex. Since this is a supported methodology from RSA it also has the benefit of being configurable via the SA GUI once you have successfully configured the poll. Another option is to stand up a middleware server to host the API calls, write the logs to a flat file on that host, and then use something like SNARE Epilog to pick up the flat file, wrap it in syslog, and feed into your existing logging topology. If you have a VLC in a DMZ you could also host the calls to the API service on that VLC, write the logs to a file, then use the file reader service on the VLC to ingest the logs. This is the quickest, easiest method to ingest logs via the API, but unlike using the plugin to structure the call you must build and manage all the logic via CLI.
  Like • Show 0 Likes0
  Actions
  - Vladimir Previn @ Jesse Lyon on Mar 6, 2018 12:02 AM
    Thanks Jesse
    
    for now we're just waiting on a VLC in the DMZ for SYSLOGTLS -> VLC . In terms of architecture though , the preference is still pull. [not sure how flexible the source IP restrictions for CBER cloud will be for writing FW rules for inbound syslogtls ]
    
    >to support native calls from a VLC to the API service
    
                    we've seen that done in the AWS cloudtrail plugin, is there any documentation for writing generic web collection ones [perhaps a useful use case will be generic s3 bucket collection + json to syslog – similar to what’s done with cloudtrail]
                    is there any documentation on writing the transforms for JSON files [I guess for CB there's 2 choices - LEEF or JSON]
    
                    ideally with proxy support for the API HTTPS reqs.
    
    >Since this is a supported methodology from RSA it also has the benefit of being configurable via the SA GUI once you have successfully configured the poll
    
                    i thought it was what the customers wanted documented but was only 'supported by paying money to prof services to develop for you' ?
    
    >SNARE Epilog
    
                    thanks, that looks interesting.
    
    >If you have a VLC in a DMZ you could also host the calls to the API service on that VLC, write the logs to a file, then use the file reader service on the VLC to ingest the logs.
    
                    interesting, haven't thought of doing that... We do that for IIS, but the uploading and incremental bits are managed by SFTPNIC agent.
    Like • Show 0 Likes0
    Actions

Carbon Black - Technology Integrations

Attachments

Outcomes

Related Content

Recommended Content

Incoming Links