After having identified the set of fundamental skills needed to set up a successful SOC, highlighted the importance of the alignment between SOC and business goals, and understood how people, processes, and technology must work together for a SOC to be successful, we now investigate the next SOC fundamental skill: focus on data through visibility and visualization.
Mastering this fundamental skill is important in order to provide SOC Analysts with a visibility on the constituency assets that is as extensive as possible, and leverage available data to provide meaningful and actionable information for the different SOC processes.
It should be noted that we are dealing with two different topics in the same discussion: visibility and visualization. We will approach them in sequential order starting from the visibility that data can provide to SOC Analysts, and addressing data visualization separately in the next article.
Before we start, it is important to understand where data can contribute in improving the SOC detection and response capabilities. There is a somewhat common belief that information security is part science and part magic (No! We are not referring to any market analysis magic quadrant here). Even though this belief proves to be true sometimes, the concept of a well-functioning SOC does not usually include sorcerers to identify and analyze malicious activities occurring over the network, neither it includes fortune-tellers to provide SOC staff with incident analysis reports and results. What it always does include, instead, is the right input for efficient analysis performed by SOC Analysts. This input comes in the form of data and is directly influenced by a well-designed data collection process. As Jay Jacobs and Bob Rudis state in Data Driven Security, “the era of the security shaman is rapidly fading, and it’s time to adopt the proven tools and techniques being used in other disciplines to take an evolutionary step into Data-Driven Security.”
The intelligence life-cycle has been declined in many different forms, but each of them relies on the right data to be collected before any processing can be applied and any intelligence can be derived. In order to have the right data, in the right format, and at the right time, we must carefully plan the SOC data collection requirements.
Data collection requirements are directly dependent on the objective of the related SOC processes: are we collecting data to enhance incident detection capabilities? Are we supporting the forensic analysis process? Are we leveraging data for threat hunting activities? These are questions we need to answer before planning any data collection as the effectiveness of data may vary depending on the goal we are trying to achieve. As an example, if we were dealing with a system compromise related to a targeted drive-by-download attack, web proxy or IPS logs could be helpful for threat detection; disk or memory images acquired from a compromised host. However, it would definitely be better fitted to support forensic analysis as part of the incident investigation; Indicators of Compromise and the capability to use them performing enterprise wide scanning, would be instead instrumental for effective threat hunting.
If we limit our focus on threat detection only, the requirements of data collection are a direct consequence of the SOC Use Cases we choose to apply in our Incident Detection and Response program. The structure of a complete SOC Use Case has already been introduced on RSA Speaking of Security and will be furtherly described in future articles of this series. Independently of the Use Case model adopted in the SOC, however, one clear assumption is that without proper data sources the Use Case detection logic cannot be fully effective. Historically data sources have been synonymous with “logs”, but the increasing growth of both the attack surface and the sophistication of attacks have determined a shift toward complementary data sources that cannot be considered optional anymore.
Among these data sources we consider anything that is able to provide “context” in order to support the establishment of situational awareness, one of the key elements of the Incident Detection and Response program. Situational awareness is multilayered and at its most basic level relies on security monitoring and intrusion detection, core SOC functions no matter what the SOC mission and scope are. A few examples of these data sources are:
- packet capture (collected at selected network pinch points, like gateways or boundaries across different trust level network zones);
- network flows (collected from equipment across the organization and useful to determine baselines and consequently suspicious behaviors);
- host indicators (collected from endpoints providing visibility well beyond system logs);
- threat intelligence feeds (atomic and computed indicators);
- asset contextual data (e.g. CMDB feed import);
- user directories (e.g. roles, org charts, contacts);
- IT Operations change logs (e.g. planned activities, legit tasks);
- historical security incident analysis (output from past incident handling activities).
The above list can go on and on and the only real limit is the tradeoff between the effort required to integrate additional data into the SOC processes and the benefits this effort can bring.
Having all the required data, however, is a necessary but not sufficient condition for the Incident Detection and Response program to be successful. The other fundamental component is the proper data visualization provided to SOC Analysts, topic that will be the subject of the following article in this series.