Welcome to CYDERES
CYDERES is providing the world's first EMDR offering fueled by Chronicle. Chronicle brings some of the same security capabilities that Google's security is building into their products and tooling as well as borrowing from core Google products like searching and indexing in order to give good the advantage.
What is Chronicle
Chronicle's purpose is to fulfill the need to ingest telemetry, capitalize on unlimited storage capabilities, and augment data with threat intelligence directly tied to the most ubiquitous security tool that exists, VirusTotal. This platform disrupts the traditional models constrained by computational sizing, volume limits, and inability to normalize data from disparate platforms.
What are Integrations
Integrations exist to get data from various log sources into CYDERES-supported security platforms. Currently, only Google Cloud's Chronicle and Microsoft Azure Sentinel are supported as outputs for CYDERES integrations.
Prepare to Send Data
Data can be consumed in a number of different ways including local syslog forwarder, GCP/S3 data buckets, flat file, packet capture, Splunk query, or a managed ingestion service depending on the data source. These options allow Chronicle to be incredibly flexible in design choices when planning how to get data into the platform. Review the corresponding integration guide for each technology the most preferred and any optional paths in order to gather data.
Events versus Context/Metadata
There are two basic types of data that CYDERES collects.
This includes all events, whether they be logs, telemetry, metrics, alerts, etc. Typically, this type of data will have a timestamp representing the time of occurrence or measurement. These are the most common integrations as context/metadata does not hold much value without data to enrich.
Context data is typically not time sensitive like events are and can be used to enrich ingested data. Examples include: IoCs, user metadata, and asset metadata. These are typically collected on a daily basis. Support for enrichment is highly dependent on the security platform. In this case, Chronicle is the only platform that really supports this, and in current state, only two sources are supported: Azure AD and Okta. Please contact a CYDERES customer success representative if there is interest in adding to this list.
Data types are a concept that are leveraged for parsing with CYDERES integrations. Data types should be determined by data structure and content, not product or format. The reasoning behind this is that it allows for parsers to be short and simple. However, because each security platform expects different results, this must be done differently for different platforms and may not be equivalent.
Syslog is the most common form of this integration. It leverages network layer 4 (TCP/TLS/UDP) to push data. In the current state, this expects telemetry to be new line delimited but does not actually require data to follow syslog format.
- CYDERES leverages a syslog forwarder that is meant to be more modern. Instead of having to vertically scale it to support voluminous sources, it is meant to scale out horizontally. That means that ideally products that send syslog data will get the best performance if it supports sending data over multiple TCP connections.
- UDP offers no guarantees of reliability and should not be used for mission critical data. Due to no formal connection actually established, data loss is impossible to detect and data corruption cannot be corrected.
These integrations call an API of some sort to retrieve data. This can include anywhere from a traditional REST API that must be polled (ex: Microsoft Graph API), a message bus (ex: Apache Kafka, AWS SQS/SNS, GCP Pubsub, or Microsoft Azure Eventhub), or cloud storage (ex: AWS S3, GCS, or Azure Blob Storage). These typically come in two different forms: stream or poll. Pollers are the more common form and require CYDERES to periodically reach out to the API and grab data within a time range. Streamers are less common but as the name suggests, they stream data to the integration once connected and are similar to syslog but instead rely on network layer 7.
- Not all APIs are created equal, so not all integrations will have the same expected reliability. While CYDERES tries to work around the API as best as possible, there are limitations on what is possible to fix.
Similar to API integrations, this leverages the HTTP protocol and REST to send data. However, instead of the integration pulling from a source, the product is expected to push data to the integration. This is similar to syslog but at a higher network layer (layer 7). Typically, JSON is expected but other formats could be supported as needed.
Data Agnostic Integrations
Many CYDERES integrations are data type agnostic meaning they support any type of data (with exceptions). For example, the CYDERES forwarder that is used for TCP/UDP integrations can support any data that comes through it, not just syslog. The requirement is that it must leverage new line characters to delimit the end of a single event (this being an exception noted above). AWS S3 or GCS are other prime examples but are typically more complex than TCP/UDP connections because both file structures are involved as well as MIME types, and in some cases, logs that may not be new line delimited requiring more involvement from the CYDERES side (but not net new engineering effort).
In addition to new line delimited, another restriction would be binary data such as those used by Google protocol buffers. To be able to understand this data, engineering effort is required to read these correctly and send them on to downstream security platforms in a way that they also understand.
On-Premise vs Cloud
CYDERES engineered CYCLOPS with the future in mind and can support select integrations running on CYCLOPS VMs or running in the CYDERES cloud environment. Integrations that do not require dependencies external to the on-prem network are prime for deployment on CYCLOPS, the most common being TCP/TLS/UDP integration (ex: CYDERES forwarder or the Chronicle Forwarder).