# How does a SOC work? From IT to OT cybersecurity management

> A practical guide to IT and OT security operations: where to invest, how to isolate industrial networks, and how Yellow Cube brings the evidence into one SOC.

- Canonical URL: https://yellowcube.eu/how-a-soc-works/
- Publisher: Yellow Cube
- Language: en

Detect and respond where speed matters. Prevent and isolate where physical safety matters. Build one command center that understands the difference.

01 / The operating model

## [One SOC. Two different responsibilities.](<https://yellowcube.eu/how-a-soc-works/#operating-model>)

A security operations center (SOC) is the team, technology and operating process that turns security signals into decisions. It collects evidence, investigates what matters, contains attacks and improves the defenses for next time. Buying a console is only the beginning: somebody must own every serious incident, including at three in the morning.

In information technology (IT), the priority is to protect identities, applications and data while the business keeps changing. In operational technology (OT), it is to preserve a safe physical process: generating power, treating water, moving trains or running a production line.

These environments benefit from a shared picture of an attack. They do not automatically benefit from the same response. Isolating a compromised office laptop can be sensible. Isolating an industrial controller without understanding its process dependencies can itself cause an incident.

**Yellow Cube’s approach: invest in rapid detection and response in IT; put stronger isolation and prevention around OT; bring the evidence together in one command center.** Automate within an agreed authority boundary, with industrial actions owned by the people responsible for the plant.

1.  Collect evidence
2.  Connect the signals
3.  Decide and respond
4.  Learn and improve

02 / Follow the consequences

## [The same budget. A different center of gravity.](<https://yellowcube.eu/how-a-soc-works/#budget>)

Our starting point for allocating security effort in a mature environment. These are Yellow Cube planning recommendations, not industry averages or a procurement formula.

IT

### Find it. Contain it. Recover.

**30%** prevention **70%** detection & response

Spend beyond the first line of defense: behavior, identity, network visibility, investigation and an effective response team.

OT

### Keep the attack outside.

**70%** prevention **30%** detection & response

Put the weight on isolation, controlled transfers and safe engineering. Retain passive monitoring and a practiced response plan.

Apply this split after agreeing the scope. It does not mean abandoning identity controls, backups, training or safety engineering. Existing maturity, exposure and the consequences of failure determine the actual investment.

Why the balance changes between IT and OT
| Decision | Business IT | Industrial OT |
| --- | --- | --- |
| What must be protected? | Information, identities and service continuity. | People, equipment and the physical process. |
| Can we change the system? | Frequent updates and centrally managed endpoints are often feasible. | Changes depend on vendor support, testing and maintenance windows. |
| Can we reverse a response? | Many actions can be rolled back, although business disruption still matters. | A shutdown or lost control signal may have immediate physical consequences. |
| What does recovery restore? | Tested backups can restore systems; they cannot undo stolen information. | Backups can restore logic and configurations; they cannot repair damaged machinery. |

03 / IT: assume something gets through

## [A clean file scan is not a clean environment.](<https://yellowcube.eu/how-a-soc-works/#it-defense>)

**82%**

of CrowdStrike’s detections in 2025 were **malware-free**.

82% malware-free · 18% other detections. CrowdStrike 2026 Global Threat Report. This describes its observed detections, not the proportion of all attacks worldwide. [\[1\]](<https://yellowcube.eu/how-a-soc-works/#source-crowdstrike>)

That is a compelling reason to look beyond signatures. An attacker may sign in with stolen credentials, abuse a remote administration tool or use a legitimate shell to move through the environment. “Malware-free” is broader than “fileless”: it also includes activity that never needs a malicious program.

Living-off-the-land attacks turn tools administrators already trust into attack tools. The question becomes who used them, on which machine, with what privileges, and what happened next. Endpoint detection and response (EDR), network detection and response (NDR), identity events and cloud logs each reveal part of that story. Extended detection and response (XDR) connects those parts.

### Build a dependable 30% foundation

****10%** Endpoint prevention**

Signature-based antivirus is a baseline, strengthened by behavioral prevention, application controls and exploit protection. A prevention layer still matters even when it cannot see every attack.

****10%** Security posture**

Remove unnecessary exposure, excessive permissions, weak identity settings and risky cloud configurations. Inventory and ownership turn findings into accountable work.

****10%** Vulnerability & patch management**

Prioritize exploitable, exposed assets and business impact. Validate that the fix landed; a patch scheduled is not a vulnerability closed.

AI-assisted research adds pressure to that last category. In March 2026, Anthropic reported finding 22 Firefox vulnerabilities in two weeks with Mozilla. That is a concrete example of accelerated discovery, not proof that AI caused every increase in CVE counts. Our takeaway is practical: shorten the path from a relevant vulnerability to a verified fix. [\[2\]](<https://yellowcube.eu/how-a-soc-works/#source-ai>)

### Make the other 70% operational

Running several competing real-time antivirus engines on every laptop is usually an impractical way to buy confidence: compatibility, performance and operations become the problem. A dedicated file-transfer scanner has a different workload and can combine multiple engines at a controlled checkpoint.

In IT, invest the remaining effort in seeing behavior, investigating incidents and acting fast. Approve reversible responses in advance, such as isolating a non-critical workstation or revoking a risky session. Protect privileged and service accounts with stricter rules. Test backup restoration and disaster recovery; neither should be assumed just because a backup job says “success.”

04 / An attack is a journey

## [Attackers are not born inside the OT network.](<https://yellowcube.eu/how-a-soc-works/#attack-path>)

They need a way in, useful privileges and a way to influence the process. Each dependency is an opportunity to interrupt the attack.

1.  01
    
    ### Gain a foothold
    
    A phished identity, exposed service or compromised supplier device provides initial access.
    
    **Watch: identity, email, endpoint**
2.  02
    
    ### Prepare the route
    
    The attacker discovers systems, collects credentials and looks for a bridge toward operations.
    
    **Watch: EDR, NDR, privileged access**
3.  03
    
    ### Cross the boundary
    
    A remote session, trusted transfer or maintenance device becomes the attempted entry path.
    
    **Prevent: isolation, transfer policy**
4.  04
    
    ### Affect the process
    
    Changes to logic, settings or operator visibility can turn a cyber incident into physical harm.
    
    **Protect: local safety and engineering**

This is an illustrative path, not a promise of hours or days to respond. Some attackers move quickly. Others prepare for weeks. Detecting the IT foothold early can remove the access they intended to use before industrial systems are reached.

Interactive remote control needs a communication path. A correctly designed outward-only diode removes that return path. However, pre-positioned malware, insiders and compromised removable media can act without a live operator typing commands. Isolation and file prevention must work together.

An isolated IT foothold can cut off an attacker who depends on it. It does not prove that an already compromised OT environment is clean.

05 / The reference architecture

## [Unify the evidence. Keep the boundary.](<https://yellowcube.eu/how-a-soc-works/#architecture>)

A central SOC can see both environments without acquiring a remote control channel into the plant.

IT / Enterprise & SOC zone

### Business systems

Endpoints · identity · email · cloud · network

Existing EDR and specialist security controls

↓ Evidence to the SOC ↑ Approved IT response

### Stellar Cyber Open XDR

Correlate → investigate → prioritize

AI-assisted triage + bounded playbooks

**Partner analysts / customer SOC** Cynet CyOps: 24×7 support for the agreed Cynet scope

Isolation boundary

### One-way telemetry

←

**OT → IT only**

Waterfall or OPSWAT hardware-enforced diode / gateway

Approved syslog, alerts and replicated data

No IT → OT session No SOC control channel

OT / Protected operations

### The physical process

Controllers · HMI · SCADA · engineering stations

Local safety systems and operating authority

↓ Passive TAP / SPAN observation ↓ Approved device logs

### OT visibility & collection

NDR sensor / supported industrial monitoring

Local log collector → outbound gateway transmitter

**Local incident coordination** Process-aware decisions by OT engineers

### Separate, controlled import workflow

1.  Supplier file or removable media
2.  OPSWAT scan / sanitize where appropriate
3.  Quarantine + owner approval
4.  Staged offline transfer into OT

No live bridge. In this example, approved files cross through a documented offline procedure. An engineered inbound gateway is a separate design decision with its own trust assessment.

Conceptual architecture, not a product wiring specification. The OT-to-IT arrow carries selected telemetry. IT response remains on the enterprise side; industrial response uses the site’s local operating process.

### What “airgap” means here

A literal air gap has no network connection. This design uses a hardware-enforced unidirectional boundary to preserve isolation while exporting data. It must not be confused with an ordinary firewall rule that can be changed to allow sessions back into OT.

Syslog can be collected inside OT and re-emitted outside it. FTP and other bidirectional protocols require compatible replication or proxy endpoints; a normal FTP session does not simply run through a one-way wire. Waterfall documents this approach for security monitoring, and OPSWAT offers optical diode and gateway options. [\[3\]](<https://yellowcube.eu/how-a-soc-works/#source-waterfall>) [\[4\]](<https://yellowcube.eu/how-a-soc-works/#source-diode>)

### Engineer the whole boundary

Choose the direction, protocols, volume and loss tolerance for each approved flow. Put a collector where it can operate without inbound cloud management, then validate buffering, time synchronization and sensor updates. Verify the selected product combination in a proof of concept.

Inventory every alternative path: vendor VPNs, dual-homed laptops, wireless links, cellular modems and shared administrative trust. A diode protects its own path; an overlooked connection can undermine the architecture. Separate sensor placement from the assumption that every sensor can operate across every diode.

06 / OT: prevent the unsafe condition

## [Inspect the transfer. Protect the process.](<https://yellowcube.eu/how-a-soc-works/#ot-prevention>)

OT gives us an opportunity that a roaming laptop rarely does: concentrate incoming files at a small number of controlled transfer points. Maintenance packages, configuration files and supplier media can be checked before they reach a protected engineering workstation.

OPSWAT MetaDefender Kiosk and Core support this prevention-led approach with multi-engine inspection and, for suitable formats, content disarm and reconstruction. The goal is deeper inspection at the boundary, with an auditable release decision. Scanning is not a guarantee; signed firmware and control programs still need authenticity checks and engineering validation. [\[5\]](<https://yellowcube.eu/how-a-soc-works/#source-opswat>)

1.  **Identify.** Record the supplier, intended asset, file type and business purpose.
2.  **Inspect.** Apply the approved engine set, file policy and sanitization workflow. Quarantine failures or inconclusive results.
3.  **Approve.** An authorized owner confirms that the content is appropriate, compatible and expected.
4.  **Transfer and verify.** Release only the approved artifact, preserve the audit trail and validate its use in the planned maintenance window.

### When patching is difficult, compensate deliberately

OT patching is constrained, not nonexistent. Some assets have long support cycles or narrow outage windows; others cannot accept an agent or an ordinary scan. Maintain an asset and vulnerability inventory, use vendor-approved updates when feasible, and document compensating controls when a fix must wait.

Passive monitoring remains valuable. Unexpected engineering activity, a new device or a changed communication pattern may reveal a problem before harm occurs. But detection after a dangerous control command may leave too little time to intervene. The architecture should prevent access to that command path before relying on a race to detect its misuse.

**You can restore a controller configuration. You cannot restore a broken turbine from a backup.** OT still needs tested backups, recovery procedures, spares and safe restart plans. They address recovery; they do not erase physical consequences. NIST explicitly treats reliability, safety and recovery as part of OT security. [\[6\]](<https://yellowcube.eu/how-a-soc-works/#source-nist>)

07 / Yellow Cube’s universal platform

## [One investigation. The right specialists behind it.](<https://yellowcube.eu/how-a-soc-works/#platform>)

Build around the customer’s assets and operating capability. Keep useful existing controls, close the gaps, and connect the evidence.

01 / Command center

### Stellar Cyber Open XDR

Bring endpoint, identity, network, cloud and security-product evidence into a common investigation. AI-assisted enrichment, correlation and triage help analysts reduce noise and focus on meaningful incidents. Response automation follows approved playbooks and the permissions actually granted. [\[7\]](<https://yellowcube.eu/how-a-soc-works/#source-stellar>)

02 / Visibility

### NDR across IT and OT

Observe traffic where endpoint agents cannot go. Stellar Cyber’s OT guidance supports network sensors and industrial log sources in a shared analysis platform. Confirm protocol coverage and deployment constraints for the plant; “universal” means one investigation model, not identical visibility on every device. [\[8\]](<https://yellowcube.eu/how-a-soc-works/#source-ndr>)

03 / People, around the clock

### Cynet + CyOps

Cynet combines endpoint protection and detection with a 24×7 expert service. Choose the service tier and pre-approved containment authority that fit the customer. Its coverage applies to the agreed Cynet environment; it does not automatically operate every third-party tool connected to Stellar Cyber. [\[9\]](<https://yellowcube.eu/how-a-soc-works/#source-cynet>)

04 / The industrial boundary

### OPSWAT + Waterfall

Use MetaDefender for controlled file inspection and transfer workflows. Select an OPSWAT or Waterfall unidirectional solution for the approved data paths. These are complementary architecture roles; the exact combination, protocol support and maintenance process are validated with the partner.

### Make the rest of the portfolio part of the story

A suspicious shell means more when it is connected to the email that preceded it, the identity it used and the data it accessed. Depending on the project, Yellow Cube can add these specialist capabilities. Connector availability and response permissions are verified individually.

**Stop and expose the entry path**

IronScales for email defense; Whalebone for DNS security; WithSecure or Cynet for endpoint protection; iVerify for mobile-device risk.

**Control access and movement**

Stormshield for network segmentation; Imprivata for privileged access; A10 Networks for DDoS and application/API protection.

**Understand intent and impact**

Group-IB for threat intelligence and external exposure; Varonis for data security; Teramind for insider-risk context. MailStore supports email archival, a distinct requirement from system backup.

**Prove the operating capability**

Cymulate for control validation; CYBER RANGES and Yellow Cube HackLab for practical exercises, investigation skills and rehearsed escalation.

[Explore the full product matrix →](<https://yellowcube.eu/cyberdefense-product-matrix-and-contribution-to-a-well-maintained-cybersecurity-posture/>) [Place the controls in the architecture →](<https://yellowcube.eu/purdue-model-architecture/>)

08 / AI with an operating boundary

## [Automate the work. Define the authority.](<https://yellowcube.eu/how-a-soc-works/#response>)

AI can enrich an alert, connect related events, summarize an investigation and propose or execute a permitted response. It can also be wrong. Treat false-positive suppression as a tuned process with audit and review, not a promise that every closed alert was harmless.

Agree an action matrix before the first incident. Confidence, asset criticality and business context decide what runs automatically. Keep the evidence, the decision and the action together so an analyst can reconstruct what happened.

Automate by policy

### Routine IT containment

Collect evidence, open a case, notify the owner and isolate an explicitly approved class of non-critical endpoint. Record the action and provide a recovery path.

Require approval

### Actions with wider impact

Disable a privileged account, isolate a shared server or change network access only under the agreed escalation rules. A service account may power more than one business process.

OT authority remains local

### Changes to the plant

Escalate to operations and safety personnel. Use validated local procedures for controller changes, process shutdowns and restart. An enterprise SOC playbook must not blindly trigger them.

An attacker may want the defender to overreact. A false alarm that causes a needless production stop can still achieve disruption. The answer is not to ignore OT alerts: it is to combine the SOC’s evidence with engineering authority and a safe decision process.

09 / From concept to an operating service

## [Start with one real site. Prove the complete workflow.](<https://yellowcube.eu/how-a-soc-works/#implementation>)

For partners, the commercial opportunity is an operating capability: design, integration, validation and continuous service around the customer’s existing investment.

1.  01
    
    ### Map the environment and consequences
    
    Identify critical processes, IT dependencies, existing tools and every IT/OT connection. Agree which systems may be isolated and who owns each decision. The output is a scoped architecture, not a generic bill of materials.
    
2.  02
    
    ### Prove the data paths
    
    Connect a representative set of IT sources and passive OT telemetry. Test parsing, timestamps, diode replication, buffering and collector health. Demonstrate that the monitoring path cannot become a control path.
    
3.  03
    
    ### Rehearse the response
    
    Exercise an IT compromise, a rejected maintenance file and an OT anomaly. Confirm who receives the case out of hours, what they may do and how plant personnel are reached. Validate recovery as well as containment.
    
4.  04
    
    ### Operate, measure and improve
    
    Track telemetry coverage, time to investigate, approved containment time, transfer exceptions and recovery exercise results. Review changed assets, new connections and expiring maintenance exceptions with the customer.
    

### Bring us your network sketch and current security stack.

We can work with you on the boundary design, missing visibility, product fit and 24×7 operating model. Together, we can define a practical proof of concept and a service your team can confidently deliver.

[Discuss your SOC architecture ](<mailto:hello@yellowcube.eu?subject=IT%20and%20OT%20SOC%20architecture%20workshop>)[Explore 24×7 managed security →](<https://yellowcube.eu/soc/>)

## [Sources & further reading](<https://yellowcube.eu/how-a-soc-works/#sources>)

Product capabilities and research checked September 2026. The budget allocation and reference design are Yellow Cube’s recommendations.

1.  [CrowdStrike · 2026 Global Threat Report briefing](<https://www.crowdstrike.com/en-us/resources/crowdcasts/global-threat-report/>) — 82% malware-free detections in 2025.
2.  [Anthropic & Mozilla · Firefox security research, March 2026](<https://www.anthropic.com/news/mozilla-firefox-security>).
3.  [Waterfall · Security monitoring through unidirectional gateways](<https://waterfall-security.com/wp-content/uploads/2023/03/Waterfall-for-SecurityMonitoring.pdf>).
4.  [OPSWAT · MetaDefender Optical Diode](<https://www.opswat.com/products/metadefender/optical-diode>).
5.  [OPSWAT · MetaDefender Kiosk](<https://www.opswat.com/products/metadefender/kiosk>) and [MetaDefender Core](<https://www.opswat.com/products/metadefender/core>).
6.  [NIST SP 800-82 Rev. 3 · Guide to OT Security](<https://csrc.nist.gov/pubs/sp/800/82/r3/final>) and [2026 OT backup guidance](<https://www.nist.gov/news-events/news/2026/06/nccoe-two-pager-now-available-effective-ot-backup-management>).
7.  [Stellar Cyber · Human-Augmented Autonomous SOC](<https://stellarcyber.ai/news/press-releases/stellar-cyber-debuts-the-human-augmented-autonomous-soc-powered-by-agentic-ai-at-rsac-2025/>).
8.  [Stellar Cyber · OT deployment guidance](<https://docs.stellarcyber.ai/6.4.xs/Common/OT-deployment-Best-Practices.htm>).
9.  [Cynet · CyOps service scope and response models](<https://www.cynet.com/platform/cyops/>).

## Before we design your SOC

### Do we need to replace our existing EDR or SIEM?

Start with what works. Open XDR can bring supported data sources into one investigation. We validate connector coverage, retention, duplication and response permissions before recommending consolidation or replacement.

### Does strong isolation mean we can stop monitoring OT?

No. Passive monitoring and local incident readiness remain essential for insider activity, maintenance mistakes, malicious imports and unexpected connections. Prevention reduces exposure; monitoring checks whether the assumptions still hold.

### Who owns an incident outside business hours?

Agree this explicitly in the service design. Cynet CyOps covers the contracted Cynet scope. The partner, customer and any additional SOC provider must define ownership for other sources, escalation to plant staff and authority to act. A shared console does not replace a service agreement.

### Can we start with IT and add OT later?

Yes. Establish the IT detection and response foundation, then add OT visibility through approved paths. Map industrial dependencies at the start so early IT automation cannot accidentally disrupt operations, and build the boundary before connecting the plant.

## Let’s Build Smarter Cyber Defenses Together

Partnerships are the foundation of everything we do — built on trust, expertise, and shared success. Whether you’re looking to grow your business, strengthen your cybersecurity offerings, or bring innovative solutions to new markets, Yellow Cube is ready to be your committed, long-term ally.

[Get in touch with Yellow Cube](<mailto:hello@yellowcube.eu?subject=Partnership>)

## Attribution and scope

This Markdown representation is generated from the same approved content records as the canonical HTML page. Cite the canonical URL above when referencing this material. Product and service descriptions are informational; confirm project-specific requirements with Yellow Cube.
