The majority of modern organizations have embarked on the path security operations centers (SOCs) are building. Today, the SOC is not a modern trend; it is a forced restructuring and reorganizing of existing information security or cybersecurity departments. The fact is, the number of incidents is growing continually and the number of threat types is growing year by year, so information security professionals have to orient their information security or cybersecurity services primarily to the detection of incidents, and only then can everything else follow. This situation is well illustrated by these words: “There are two types of companies: those that have been hacked, and those that don’t yet know they have been hacked.”1
SOC and Use Cases
A SOC is a set of staff, processes, technologies and facilities that is primarily focused on identification (detection) and response to cybersecurity incidents that arise as a result of cybersecurity threat realizations. It is widely understood that, unfortunately, it is impossible to cover and resist all types of existing cybersecurity threats since resources are restricted, and, therefore, it is necessary to prioritize actions and projects. The discussion of use cases within SOCs starts here—a mechanism for consistent selection and implementation of cybersecurity incident detection scenario rules, tools and response tasks. A use case can be considered as a specific condition or event (usually related to a specific threat) to be detected or reported by the security tool. It is an analog of a cybersecurity threat model or cybersecurity risk registry, but oriented in the cybersecurity incident management process within the SOC.
The life cycle of use cases (i.e., the use case process) includes:
- Design of the use case
- Development of the use case
- Implementation of the use case
- Application of the use case
The main component of use cases is a cybersecurity incident detection scenario rule (i.e., a correlation rule), which includes:
- Syntax of the rule within a specific security information and event management (SIEM) system
- Event source (any software or firmware [tools] that have logging capability and the ability to provide access to log data)
- Event category or accurate recorded event (log data)
Persons involved in the life cycle of use cases include:
- Designer/analyst (sometimes an external consultant)
- SIEM system engineer/administrator
- Security tool system engineer/administrator (for every security tool)
- System administrator (for every nonsecurity tool)
In reality, every person from the use case team uses his/her own terminology and understanding of the correlation rule (the cybersecurity incident detection scenario rule). However, there is good news: An event category or accurate recorded event (log data) can provide common and clear terminology for all staff. For example, an event category is “logon, logoff”; accurate recorded events within the Microsoft Windows 2008 R2 and 7, Windows 2012 R2 and 8.1, and Windows 2016 and 10 environments are:
- Event ID 4624, Event message “An account was successfully logged on”
- Event ID 4634, Event message “An account was logged off”
However, there is also bad news: There is no full event category catalog. Therefore, it is necessary to prepare a separate event category or accurate recorded event (log data) list (catalog) for every event source. This is a great challenge within a large IT infrastructure because, on the one hand, this catalog must be focused on cybersecurity (it is clear only for the first two persons from the team listed previously) and, on the other hand, the catalog must be focused on specific event sources (it is clear only for the last two persons from the team listed). Experience has shown that without an event category catalog, it is very difficult and sometimes impossible to carry out the design of a use case and, consequently, next steps.
Figure 1 identifies an existing challenge and provides a suggested catalog.
Figure 1—Event Categorie Catalog
|
Number |
Event Source Type |
Event Category Related to Cybersecurity |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conclusion
The suggested catalog uses terminology oriented for every event source type and associated staff (e.g., “role” is clear for a database administrator, “ACL” is clear for a network specialist), so cybersecurity staff does not have to translate key terms, thus saving precious time. Moreover, this list is related to cybersecurity issues and does not include extra information; therefore, cybersecurity resources can be used responsibly within the SOC use case process and remain focused on identification (detection) and response to cybersecurity incidents.
Endnotes
1 Chambers, J.; “What Does the Internet of Everything Mean for Security? Cisco Chief John Chambers Explains,” The Straits Times, 28 January 2015, www.straitstimes.com/opinion/what-does-the-internet-of-everything-mean-for-security-cisco-chief-john-chambers-explains
Aleksandr Kuznetcov, CISM
Is head of the information security department at Vulkan R&D and is a postgraduate of Financial University under the Government of the Russian Federation (Moscow, Russia). He has more than 12 years of experience in information security within Russia and the Commonwealth of Independent States (CIS), including security information and event management and security operations center topics. He is the subject matter expert and manager of several hundred projects, and a regular author in his areas of expertise.