Our system uses machine learning to learn the coordinates of the sites which is visited by the field

Any organization can achieve its security objectives through a well-thought operating model as against adopting a common setup practice established across industries.

In our experience, while consulting organizations across multiple sectors, we have understood many focal areas are often overlooked by managers and entrepreneurs while setting up their Security Operations Center. There is a common thought amongst stakeholders investing in infrastructure alone will control the entire security architecture and generate returns immediately. In our second article on the SOC series, we cover certain failure points in SOC that will lead to an ineffective security design.

Common Practices of SOC that we have experienced while consulting organizations.

1. Return on Investment is instantaneous

Generating RoI from SOC yield over time; the characteristics of an early-stage setup are different from those of a mature one in organizations. While RoI is key to decision-making for all CXOs, there is a notion that this investment’s returns are tangible and can be seen in the shortest possible time.

2. Recruitment of untrained manpower

To substantiate CAPEX returns, managers proceed to recruit untrained manpower. Like any other major CAPEX investment ( machinery, aeroplanes, ships, bullet trains) requires specific skills to achieve optimum utilization; failing which the returns are not generated as the utilization is scarce or inaccurate.

3. Placements of Surveillance Equipment without a clear objective Placing equipment across areas without any substantiated data or assumed hypothesis, and expecting the SoC to monitor or control risk will not yield an accurate response from the operations team

4. Utilizing SoC only for Post Incident Scenarios SOCs are designed with the thought of controlling post-incident analysis in the majority of organizations. This makes it tough for the organizations to effectively monitor risk real-time

5. Ineffective use-cases Not designing accurate use-cases for SOCs to monitor or control puts tremendous pressure on the existing resources and infrastructure to have basic monitoring practices in place. While the above points are certain practices we experienced that led to an ineffective SoC design, we further detail out the points of failures:

Lack of a Security Strategy for SOC

Lack of strategy in SOC clearly defines that the stakeholders do not have any road map to follow or refer to when running their daily operations. The security function can face severe consequences when it lacks strategy. It will lead to inaccurate allocation of resources, unclear organizational structure, and a bad communication flow. An example of an effective and simple strategy for SOC would be to ‘monitor the life-cycle of all elements through computer vision programs in our premises and communicate immediately on any deviations to control any potential losses’

2. Poor SOC Design Expected outcomes from the security function, key performance metrics of the SOC, failure to consider use-cases, risk management practices, simulation, or poor training programs lead to a poor SOC design.

3. Lack Training and Skilling Program Risk is dynamic in nature and often resources are untrained to respond to events in the majority of the cases resulting in potential business losses. Organizations do not have scheduled training and upskilling programs for their resources deployed at SOC. This lack of training leads to low utilization of tools and frameworks used at SOC and the capabilities of the resources are not built with changing risks profile of the environment. A training program for SOC would consist of weekly scheduled hours on communications, simulation activities, software utilization, business processes as well as upcoming technologies in monitoring.

4. SOC Processes are not integrated with business processes All core business processes are not factored into security monitoring processes and are exclusive of each other. SOC processes need to monitor the systems, people, and processes that augment business processes. An example of a well-integrated system would be payroll and access controls integrated.

5. Inaccurate Technology Systems Procurement Without optimum use-case and software, organizations are unable to exploit the infrastructure capabilities; resulting in laborious tasks for the manned resources. A typical SOC should be empowered with automated alarms capabilities, ticketing systems, incident protocols systems, communication systems, automated MIS capable systems & recognition software.

6. Inaccurate Hardware Procurement SOC hardware comprises adequate multiple monitors to manage triage operations, communicate with resources while generating reports. Without video walls, communication devices, GIS systems, or, an integrated PSAP or mass communication systems will lead to reliance on stand-alone CCTV systems and manual workflows themselves. During calamities, without the pre-requisite hardware systems, the entire SOC capabilities are limited.

7. Implementation does not factor in non-security functions While SOC monitors multiple functions even though it is a core security function, the entire implementation does not consider respective functions use-cases. SOC’s noncore activities can include supporting non-security functions to an extent and during the implementation phase, such features can be incorporated by the SOCs. Examples of implementation with non-security functions include sharing or department wise visitor reports with the managers periodically

8. Not Evolving the SOC Function Once SOC is established in organizations, rarely there are instances of modifications and additions to the features or workflows, changes in the hardware or upgrades made to the software systems, or additions to the training content for the manpower. TAKEAWAYS

Describe your SOC Strategy in detail prior investments and recruitments

Design your SOC workflows, emergency response mechanism, organizational hierarchy, communication workflows & processes and procedures

Have a dedicated training and skilling program for your resources

Capture as much as a business process in your SOC system protocols and procedures

Prior procurement of technology systems, enumerate all your respective use-cases.

Hardware procurement should be done post-use-cases & environment analysis

Include all non-functional security departments in your implementation strategy

Evolve your SOC design periodically to address and manage key risks.