There is a new term that has popped up in the IT security landscape: SecMonOps.

So what is SecMonOps?  And why do we need another acronym in IT?

Think of a Venn Diagram. IT Security is one big circle. IT Operations (ITOps) is another big circle. Where they overlap, is what is referred to as SecOps.


SecMonOps is a subset of SecOps and fits in the intersection of IT Operations and Security.


Knowing how it fits in today’s IT and Security Operations framework, it still dos not answer the the question “What is SecMonOps?”

SecMonOps is at its core the governance, policies, procedures, and KPIs for gathering log data, searching logs for new vulnerabilities, anomalous behavior, and bad actors, and alerting the SOC of what was discovered.

You may ask yourself – isn’t that just a SIEM (Security Incident and Event Management Solution) tool? Actually, the SIEM is a tool of SecMonOps. Without SecMonOps, the SIEM is more likely to discover anomalous behavior by luck that by design.

As you can see below, security monitoring is much more than just capturing a few logs, searching, and generating alerts.

  1. Implementing a SIEM is not a plug and play solution.To be effective, SecMonOPs requires clearly defined and documented scope, policies, and procedures. Governance of SecMonOps includes establishing objectives for the Program including KPIs to evaluate whether the SecMonOps is meeting its intended purpose – finding new vulnerabilities and identifying bad actors in a way which is sustainable.

  2. SIEM– Security Incident and Event Monitoring.   The core technology for security monitoring – whether it is on premises or delivered by a Managed Security Services Provider (MSSP) – is fully dependent upon all the pieces surrounding it on the graphic below. Failure in one or more of the inputs, the outputs, secure log storage or fundamentals and the ability for the SIEM to identify anomalous activity and new vulnerabilities is greatly diminished.

  3. Asset Inventory. Security Monitoring is dependent upon at a minimum monitoring all critical assets within its scope. If inventory is not accurate, then it can be assumed that assets which should be monitored are not being monitored. Missing assets means the SIEM misses the signatures of the bad actor or fingerprints of a bad actor.

  4. Log Content. The data captured about each event has to be sufficient to uniquely identify the event, the source of the event, time and date of the event, and enable a Security Analyst to have a starting point to research the event. Without, the difficulty in distinguishing between authorized versus unauthorized events becomes much more difficult if not impossible.

  5. Security Tools. Your Security tools (e.g., IDS, AV, FIM, DLP, NTP, DNS, WAF, etc) need to be properly configured to ensure that alerts are being issued properly, and responded to in a timely way. In addition, regardless of whether alerts are issued directly to your team or through the SIEM, directing logs to your central log store provides additional information which can be utilized by machine learning, AI, and other threat hunting tools which are found in many SIEM products and services ;

  6. All Assets Reporting to SIEM. The asset inventory is accurate ad critical assets are identified. Yet, there are devices which are not reporting to SIEM. Are you able to identify them easily? Does the SIEM report what assets have been regularly shipping log event data and suddenly stops? Missing log data for critical assets can be a sign of a bad actor concealing their activity on your network.

  7. Use Cases. The SIEM needs to be configured appropriately to ingest the logs and generate alerts which are actionable. You need to consider:

- Are the use cases which guide the interrogation of the logs generating alerts that are in alignment with the current threat landscape?

- Are they in alignment with areas that need additional monitoring because of issues identified in a risk or security framework assessment.

  1. Does the SIEM provide the required reporting outlined by the security framework you use so you are in compliance?

  2. Logs are being securely stored so that they cannot be modified.  Access is restricted to this datastore is provided to a few persons with a need to access. Logs are stored to meet regulatory, industry and business requirements. And, the log store is actively monitored for access attempts and tampering.  

  3. And, there’s more. Much, much more to ensure you have an effective Security Monitoring Operations program which can identify new vulnerabilities, identify threats posed by known vulnerabilities, and identify the fingerprints of bad actors.


For more information about this emerging topic, be sure to check out more of David’s SecMonOps blogs here: 

The Problem With the SIEM


5 Keys to Making SecOps Work in the Real World