While defining SOC mission and goals are key starting points, defining SOC scope is crucial to manage the overall SOC project and break a large multi-year project into smaller phases and milestones. This also helps in managing cost and simplify implementation. My suggestion is to divide a SOC project over multiple phases, each of which should be about six months long. Following are some key areas to consider when defining the scope of each phase.
Log sources vary widely starting from security device logs, network components, applications, devices and many others. Collecting logs also needs significant investment in log storage and processing infrastructure. You want to prioritize log sources that bring the most value from security monitoring perspective. For these reasons, you should start with a small subset of logs and expand the scope of log collection over time (in future phases of the project). While making the initial log collection, you can consider the following:
- Value of logs for identifying security events (proactive)
- How a particular log source can help in incident investigations (reactive)
- Amount of log data that you can handle
- Compliance needs and requirements
Typically, you should start with logs coming from security devices (firewalls, IDS, content filtering and proxy servers, identity management systems, etc. The second preference may be operating systems and public facing web server logs. Then you can move to applications, and so on. There is no prescribed order and you should define your own scope based upon your particular situation and which systems play a key role inside your organization.
You can also use threat modeling techniques to identify critical log sources and prioritize these accordingly.
Time of Day
Although we want 24×7 SOC but that is not always possible due to different constraints. An 8×5 (8 AM to 5PM) or single-shift SOC may be a great starting point for many organizations, at least in the initial phases of SOC implementation. Once the initial phase is complete, you may want to add a second shift before going to full 24×7 implementation. Global organizations may also start with a single SOC and then use follow-the-sun model to achieve 24×7 coverage.
Large organizations have multiple business units and all of these units don’t need to be under SOC scope, or at least not in the first phase. While each organization may have a different criteria to identify which business unites to cover, some considerations may include:
- Criticality of a business unit for the organization
- Type of data
- Compliance needs and local rules/regulations
Selection of business units may also be phased approach.
Multinational organizations may decide SOC scope based upon preference of specific geographic locations, among other criteria.
Fast emergence of new technologies including Internet of Things (IoT), blockchains, autonomous vehicles, drones (and others) is also impacting security business. While this may not be the case for some, others may deem these technologies as business critical based upon their impact. Following are some technologies that you may want to cover in different phases of a SOC project.
- Machine Learning (ML), deep learning and other artificial intelligence related technologies
- Internet of Things or IoT, collecting data from IoT devices and managing threats from IoT botnets, identities and other aspects of IoT
- Operational Technologies or OT that cover factories, industrial controls, SCADA systems
- Block Chain
- Autonomous vehicles
Your business is potentially already provider or consumer of at least some of these technologies. You may also be interested in bringing these under SOC scope because you may be a service provider. In any case, threats to these and other emerging technologies are only going to grow as their deployment and use grows.
A solid definition of SOC scope is key to build not only for the business case but also a successful SOC. While the above list includes key considerations for defining SOC scope and build implementation phases, there may be other aspects that you may want to consider depending upon your particular business situations.
This article is part of my “Business Case Development” of my upcoming book about planning and building a successful SOC.