To firebreak your network there are four phases for detection which few solutions today are providing, even more so when you review the balance of technology, process and people for success. A firebreak is more than a point solution or another box, it is the detection you need when preventive defenses fail.
First, you need to collect a rich set of data with continuity. Network traffic, system logs, IDS alerts, vulnerability assessments, inventory of HW and SW, AD access and firewall event logs, and application and database events are a solid start. The supporting architecture needs to support data volume, velocity and variety. Cloud scale and serviceability supports the first two requirements while big data tools (e.g. ELK stack) support data variety.
Second, you need to analyze the data and here a data correlation model continually optimized for detection comes into play. More than basic log event management or out-of-the-box SIEM rules, it requires data normalization and correlation tuning with an analytics mindset to discover security risks and anomalies. Running the same reports and rules time over time creates blind spots.
Third, you need to reduce big data down to small data that is relevant to your network. While it is interesting to read about nation-state cyber techniques in reports, your network and what the firebreak can detect are more important. Getting alerts from another box or a service is just more noise, the goal is to reduce the noise and false positives.
Fourth, the processes need to repeat daily. While simple to state, in practice it can be challenging with limited resources and time. Detection is the highest known activity cost with labor being the highest cost component when fighting cybercrime. These can both be reduced from the security intelligence provided by a firebreak detection service.