Some of the best practices that I feel is as below.
1. The SOC must enable end-to-end network control
Your security operations center protects the enterprise from network threats, but you need to precisely define your network boundaries to achieve this. It is a common misconception that the external network is identical to the public internet, and anything that’s not part of the public internet is safe. CISOs must keep in mind that any third-party network (including and beyond the internet) can be a threat vector.
For modern organizations, API-based app integrations, external device connections via Wi-Fi or Bluetooth, and cloud-shared resources must also come under the definition of external networks.
In the case of internal networks, least privilege access should be your rule of thumb, and no single user should have complete access to sensitive/valuable information. Segregate your internal network into several tiers of access (based on its asset contents), aided by a powerful firewall solution.
2. Pay attention to shadow app discovery
Shadow applications (part of shadow IT) are a growing threat for enterprises. Traditionally, SOCs have restricted software installation on enterprise systems, even if the app came from a trusted source. However, in a remote working world, this becomes a major problem. Remote users could intentionally or unwittingly download malicious applications from the internet, eventually spreading across the entire internal network.
In addition to the firewall, regularly conduct an app discovery exercise to create a full software inventory across the hundreds and thousands of computers on your network. Classify these apps as per their security risks and take action. Also, gain from built-in restrictions that prevent unauthorized users from downloading and installing software on enterprise systems (including servers).
3. Keep a watch on hardware sprawl, even in cloud-first environments
Another myth around the SOC maintenance is that hardware doesn’t fall under its ambit. As most security vectors tend to be software-related (spreading through the cloud or public/private networks), SOCs frequently take a short-sighted view and focus only on software. In reality, hardware sprawl is a risk for every enterprise, adding peripherals like printers, routers, Wi-Fi repeaters, storage endpoints, and other unauthorized components as business needs grow. With each addition comes new security risks.
Make unauthorized hardware connectivity prevention a priority for your SOC. Also, implement processes that restrict employees from copying data for home use or offsite use. If some degree of BYOD is inevitable (as in a WFH scenario), make sure to verify identity through multi-factor authentication. Finally, scan enterprise perimeters for rogue hardware, just like shadow applications, to discover risks on time.
4. Protect SOC logs to aid investigation
Access logs are among your most handy tools when conducting a post-attack forensic analysis. It also helps to root out false positives from genuinely suspicious access behavior. SOC managers typically use logging records to assess the four Ws and one H of a security breach: who, what, why, when, and how.
However, the logs themselves can be vulnerable, and it’s compromise will cripple your ability to assess and respond to any security threat. One of the first things a malicious app will once it enters your systems is to remove any evidence of the attack by rewriting device logs. That’s why it is advisable to store access logs in a separate, high-security zone that is not connected to the device itself.
Further, make sure to synchronize the timestamps across all enterprise devices generating logs regularly. A single, synchronized lock will ensure that all devices follow a central time source, allowing access events to be plotted more easily. In case of a breach, you can reconstruct the incident by piecing together logs across various devices.
5. Have a contingency plan in place via a robust backup
Assuming the worst-case scenario can be extremely helpful when building an SOC, given the unpredictable and fast-evolving nature of security threats. A big part of this is investing in a backup system that can help to restore your digital assets after an attack, even if it can’t prevent malicious parties from getting hold of it.
A cloud-based backup system can accelerate data recovery, particularly if a malicious party goes after your in-house backup service.
While no backup strategy is 100% hackerproof, remember the 3-2-1 rule: 3 copies of information, including primary/dynamic/production data and two backups, where one should be stored off-site – e.g., on the cloud. Ensure your production data is protected by strong authentication measures, and your cloud backup is accessible only to a select group of users during worst-case scenarios, like a ransomware attack.
Search for a product comparison in Information Security and Risk Consulting Services
From my little experience, it's always good to have a good working plan on how you are going to start setting up a SOC and how you are going to gradually mature the SOC. The primary consideration is the availability of 3 components: people, technology and process.
It's very easy to manage the development of SOC when you do it in bits. Talk about technical aspects like SIEM. SIEM might have components like Logs, Network, Endpoint and SOAR. From my own view, it's not an easy thing to plug in all these components at once. You could start with a primary component like the Logs component and gradually build from that. It's also good to have a technology and deployment option that works for your business needs.
On people, it's good to have skilled analysts else you may not get value for your investment in technology and time. Many people take different approaches to sort the issue of the insufficient number of skilled analysts. Some opt to work with MSSP jointly with the team you are developing in-house for a set period of time for the purpose of knowledge transfer.
There should be a clear workflow of activities in case of an incident. What should T1 do before passing the alerts to T2 .. or closing false positive alerts? What are your sources of threat intelligence?
Find out what your peers are saying about Presidio, ScienceSoft, Fortra and others in Information Security and Risk Consulting Services. Updated: December 2025.
Security Incident Response involves the preparation, detection, containment, and recovery from security threats to protect an organization's information assets.Effective incident response is crucial for minimizing damage from security breaches. Solutions in this category provide the tools needed to quickly identify and mitigate threats, enabling organizations to maintain operational continuity. They typically include features for real-time monitoring, threat intelligence integration, and...
Hi @Giusel ,
Some of the best practices that I feel is as below.
1. The SOC must enable end-to-end network control
Your security operations center protects the enterprise from network threats, but you need to precisely define your network boundaries to achieve this. It is a common misconception that the external network is identical to the public internet, and anything that’s not part of the public internet is safe. CISOs must keep in mind that any third-party network (including and beyond the internet) can be a threat vector.
For modern organizations, API-based app integrations, external device connections via Wi-Fi or Bluetooth, and cloud-shared resources must also come under the definition of external networks.
In the case of internal networks, least privilege access should be your rule of thumb, and no single user should have complete access to sensitive/valuable information. Segregate your internal network into several tiers of access (based on its asset contents), aided by a powerful firewall solution.
2. Pay attention to shadow app discovery
Shadow applications (part of shadow IT) are a growing threat for enterprises. Traditionally, SOCs have restricted software installation on enterprise systems, even if the app came from a trusted source. However, in a remote working world, this becomes a major problem. Remote users could intentionally or unwittingly download malicious applications from the internet, eventually spreading across the entire internal network.
In addition to the firewall, regularly conduct an app discovery exercise to create a full software inventory across the hundreds and thousands of computers on your network. Classify these apps as per their security risks and take action. Also, gain from built-in restrictions that prevent unauthorized users from downloading and installing software on enterprise systems (including servers).
3. Keep a watch on hardware sprawl, even in cloud-first environments
Another myth around the SOC maintenance is that hardware doesn’t fall under its ambit. As most security vectors tend to be software-related (spreading through the cloud or public/private networks), SOCs frequently take a short-sighted view and focus only on software. In reality, hardware sprawl is a risk for every enterprise, adding peripherals like printers, routers, Wi-Fi repeaters, storage endpoints, and other unauthorized components as business needs grow. With each addition comes new security risks.
Make unauthorized hardware connectivity prevention a priority for your SOC. Also, implement processes that restrict employees from copying data for home use or offsite use. If some degree of BYOD is inevitable (as in a WFH scenario), make sure to verify identity through multi-factor authentication. Finally, scan enterprise perimeters for rogue hardware, just like shadow applications, to discover risks on time.
4. Protect SOC logs to aid investigation
Access logs are among your most handy tools when conducting a post-attack forensic analysis. It also helps to root out false positives from genuinely suspicious access behavior. SOC managers typically use logging records to assess the four Ws and one H of a security breach: who, what, why, when, and how.
However, the logs themselves can be vulnerable, and it’s compromise will cripple your ability to assess and respond to any security threat. One of the first things a malicious app will once it enters your systems is to remove any evidence of the attack by rewriting device logs. That’s why it is advisable to store access logs in a separate, high-security zone that is not connected to the device itself.
Further, make sure to synchronize the timestamps across all enterprise devices generating logs regularly. A single, synchronized lock will ensure that all devices follow a central time source, allowing access events to be plotted more easily. In case of a breach, you can reconstruct the incident by piecing together logs across various devices.
5. Have a contingency plan in place via a robust backup
Assuming the worst-case scenario can be extremely helpful when building an SOC, given the unpredictable and fast-evolving nature of security threats. A big part of this is investing in a backup system that can help to restore your digital assets after an attack, even if it can’t prevent malicious parties from getting hold of it.
A cloud-based backup system can accelerate data recovery, particularly if a malicious party goes after your in-house backup service.
While no backup strategy is 100% hackerproof, remember the 3-2-1 rule: 3 copies of information, including primary/dynamic/production data and two backups, where one should be stored off-site – e.g., on the cloud. Ensure your production data is protected by strong authentication measures, and your cloud backup is accessible only to a select group of users during worst-case scenarios, like a ransomware attack.
Hi Giusel,
From my little experience, it's always good to have a good working plan on how you are going to start setting up a SOC and how you are going to gradually mature the SOC. The primary consideration is the availability of 3 components: people, technology and process.
It's very easy to manage the development of SOC when you do it in bits. Talk about technical aspects like SIEM. SIEM might have components like Logs, Network, Endpoint and SOAR. From my own view, it's not an easy thing to plug in all these components at once. You could start with a primary component like the Logs component and gradually build from that. It's also good to have a technology and deployment option that works for your business needs.
On people, it's good to have skilled analysts else you may not get value for your investment in technology and time. Many people take different approaches to sort the issue of the insufficient number of skilled analysts. Some opt to work with MSSP jointly with the team you are developing in-house for a set period of time for the purpose of knowledge transfer.
There should be a clear workflow of activities in case of an incident. What should T1 do before passing the alerts to T2 .. or closing false positive alerts? What are your sources of threat intelligence?
Sadly, I cant contribute due to lack of experience in that field. But I would love to read about your findings
https://www.mitre.org/sites/default/files/publications/pr-13-1028-mitre-10-strategies-cyber-ops-center.pdf
Only this :)