Approaches to threat data exchange are currently in an active phase of formation and standardization. Today there are a couple of significant standards, namely, MISP and STIX, and entire assemblage of less significant ones that are less commonly used or considered deprecated, such as MAEC, IODEF, OpenIOC (Cybox), CAPEC, VERIS and many others. At that, a decent number of community feeds are still distributed in the txt or csv formats, as well as in the form of human-readable analytical summaries, bulletins, and reports.
This article deals with analysis of the generally accepted practices of data exchange about cyber threats, namely, specialized formats and general-purpose standards designed not only for threat intelligence (TI). At that, purely proprietary, rare and “reinvent-the-wheel” formats, as well as thematic blogs, news portals, messenger communities, and other TI sources in human-readable formats are left out of the scope of the present article. Today the focus is on machine-readable formats.
Let’s start with STIX [1] standard. This standard is quite mature, since it has made ten-year way of development from version 1 to 2.1. It has good descriptive characteristics: thus it allows describing the threat in very detail, all its relationships, and technical artifacts.
The Bank combines a variety of solutions and services for collection and analysis of cybersecurity alerts. To make the incident response process more efficient the bank needed an advanced tool which would allow to relate incident alerts to assets and users, automatically assign tasks to members of the cybersecurity department team, automatically collect context and additional data from multiple sources and automate security operations. The implemented automation had to accelerate incident response and help to minimize the potential damage to the bank.
PoC for Defensys SOAR lasted for a quite long time comparing to the average period of testing Defensys products and proved all the features of the cybersecurity management platform which combines Defensys SOAR and Defensys SGRC products to cope with the tasks.
All critical assets were discovered and structured in the Defensys platform during the testing period. Tight integration with security tools in use and external monitoring services was configured.
By the time of the formal implementation the Bank had a ready-to-use information security management center based on Defensys platform.
Consultants from Defensys’s Center of expertise along with our partners are ready to map the current correlation rules of SIEMs and other security tools of our customers with MITRE tags so that the incident registered in SOAR will already contain all the needed data.
“It’s been almost a year and a half since we started this practise with one of our Telecom customers. At the moment we’ve got all SOAR implementation projects where this mapping exists. This way you can ease the process of incidents classification, adopt proper playbooks, draw metrics with statistics. And of course you can speak the same language with the community when it comes to discuss some interesting or critical cases.” – says Andrey Chechetkin, Deputy CEO of Defensys.
We’d like to remind you that after the implementation of the Defensys SOAR in the incident card a customer is able to see:
The Defensys company issued the fifth version of its SOAR platform which is core solution for building Security Operations Centers (SOC) of different scales. SOAR v 5.0 got a lot of new features. In particular there appeared a native part in the incident card for working with IoCs which come from security alerts and Threat Intelligence platforms. User experience in operating with playbooks updated significantly as well. Besides the overall interface of the system got serious enhancements.
Important changes are ready to be used in the core functional block of incident management. The version 5.0 of Defensys SOAR gives you the opportunity to work with groups of incidents and it helps users conveniently handle cases when several incidents are related between each other. You can simply customize policies for auto filling field values inside this group of incidents. For example the parent incident status could be just inherited in included incidents or the total amount of damage will be automatically placed into the dedicated field in the parent incident. One more important feature is the part of incident card specially tailored to work with IoCs in the most convenient way and of course all the results of operating with IoCs are distributed into the variety of dashboards.