Not yet.
However, we plan to have a self-serve capability in the near future, for the moment, if you wish to trial the product, a SOC.OS engineer will be virtually present to guide you through the process, answer questions, and get you live and using the product as soon as possible.
We’re constantly integrating with new security solutions.
If you don’t find your security tool on our current compatible devices list, don’t worry, as long as it produces alerts in machine-readable format and you’re able to export it into SOC.OS (either via syslog or an API), we’ll be able to integrate with it.
We schedule a 3 hour virtual on-boarding meeting. However, the current time to beat is 1.5 hours, which was based on integrating 2 on-premise and 2 cloud-hosted security tools.
We’re all too familiar with the pain associated with setting up a new tool such as a SIEM, and how integration efforts can last many days, weeks and sometimes months. At SOC.OS we’ve worked hard to optimise the SOC.OS on-boarding process to ensure it is as simple as possible.
On-boarding and set up takes place fully remotely and a SOC.OS engineer will be virtually present to guide you through the process, answer questions, and get you live and using the product as soon as possible.
For on-premise tooling, security alerts are forwarded over syslog from the alerting systems to the SOC.OS agent; which is a lightweight executable that can run on almost any operating system (technical details about the software agent can be found in our product sheet).
The installation of the agent takes a matter of minutes, and once configured works autonomously to forward alerts to the SOC.OS cloud platform. Cloud-based security tools are even simpler – provide SOC.OS with the API keys to read security alerts from that system, and it will automatically poll for new alerts. Once you’ve provided a few key details about your network – internal domains, IP address ranges, etc. – SOC.OS will get to work correlating alerts into clusters. You can then log into the SOC.OS portal to start viewing and investigating these – no more swivel chairing across your multiple security portals.
The 3 prerequisites are as follows:
If you wish to integrate on-premise tools with SOC.OS, which means you’ll need to deploy the SOC.OS agent, please build the machine that will host the SOC.OS agent prior to the on-boarding meeting. During the on-boarding meeting itself, the SOC.OS team will help install and test the SOC.OS agent on the machine. For more details about the agent, please see Installing the SOC.OS Agent.
Please ensure the following table of source systems and subsequent ingestion mechanism is completed. We always recommend integrating a minimum of 2 tools for the PoC and suggest where possible to choose tools already on our current compatible devices list, which just further reduces the time to go-live. Please also ensure that the relevant team members who understand and can make changes to the security tools and the relevant areas of the network are prepared prior to the onboarding call. Note: if there is a change advisory board or similar construct within your business which will need to be involved before changes can be made to these source systems, please also have this sorted before the call.
| Name of security tool SOC.OS will be integrating with. Examples below. | Full version number of source system. Please also list any additional modules you have (the more detail the better). | Is this tool on-prem (i.e. sending alerts via syslog to the agent) or cloud hosted (i.e. alerts will be sent to the SOC.OS cloud directly via an API)? |
|---|---|---|
| Next Gen Firewall (IDS/IPS) | ||
| Endpoint (AV) | ||
| O365 | ||
| DarkTrace |