This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Welcome, Guest
You have to register before you can post on our site.



Search Forums

(Advanced Search)

Forum Statistics
» Members: 332
» Latest member: pokerjakarta
» Forum threads: 17
» Forum posts: 32

Full Statistics

Latest Threads
Forum: SOC-CMM community forum
Last Post: Trustconsulting
Yesterday, 10:36 AM
» Replies: 0
» Views: 6
Forum: SOC-CMM development
Last Post: robvanos
09-11-2019, 11:50 AM
» Replies: 2
» Views: 2,356
Which additional alignmen...
Forum: SOC-CMM development
Last Post: jvbon
08-16-2019, 09:10 AM
» Replies: 3
» Views: 2,178
SOC Certification Body
Forum: SOC-CMM community forum
Last Post: ViliusBenetis
06-08-2019, 09:24 PM
» Replies: 2
» Views: 2,478
Security Monitoring - Use...
Forum: SOC-CMM community forum
Last Post: robvanos
06-05-2019, 01:52 PM
» Replies: 0
» Views: 1,326
Which extensions should b...
Forum: SOC-CMM development
Last Post: robvanos
05-07-2019, 10:06 AM
» Replies: 2
» Views: 2,197
Minor error - incorrect d...
Forum: SOC-CMM bugs and issues
Last Post: robvanos
04-16-2019, 07:00 PM
» Replies: 1
» Views: 1,973
NIST 800-62r2 Not Availab...
Forum: SOC-CMM bugs and issues
Last Post: robvanos
04-16-2019, 06:59 PM
» Replies: 1
» Views: 1,637
Asset Management Integrat...
Forum: SOC-CMM community forum
Last Post: robvanos
04-16-2019, 06:38 AM
» Replies: 1
» Views: 1,728
Secure Event Transfer - S...
Forum: SOC-CMM community forum
Last Post: robvanos
04-16-2019, 06:35 AM
» Replies: 1
» Views: 1,798

Posted by: Trustconsulting - Yesterday, 10:36 AM - Forum: SOC-CMM community forum - No Replies

Hi Rob & Community, 

I want to perform a SOC assessment using SOC MM,

Can you provide more details about business drivers, because as i know the SOC is combination of People Process and technology, ?


Hemza | SOC Analyst

Print this item

Posted by: robvanos - 09-06-2019, 08:06 AM - Forum: SOC-CMM development - Replies (2)

I'm happy to announce the release of the SOC-CMM for CERT, a version of the SOC-CMM specific for incident response teams. Earlier this year, I did a presentation at FIRST.ORG TC on the SOC-CMM. FIRST has expressed interest in the SOC-CMM, especially if it could be made more specific for CERT teams. I have been working on a version of the SOC-CMM that aims at measuring capability maturity in CERT teams. I've used the original SOC-CMM (version 2.1) as a starting point, and combined it with information from various other sources such as NIST SP800-61r2, the CREST incident response handbook, the SIM3 model and the GMU CSIRT social maturity handbook. The result is an assessment tool that allows for in-depth analysis of your CERT team. Some of the improvements made will eventually be integrated into the SOC-CMM.

Some of the major differences between the regular SOC-CMM and this version are:

- General: All questions rephrased to focus on CERT
- Business: 'privacy' updated to more generic 'laws and regulations'
- Process: use cases changed to scenarios
- People: different set of roles, added team and multi-team management
- Technology: added incident tracking system, removed SIEM, IDPS and big data analytics
- Service: removed all services, execpt for security incident management. Added many capabilities to the list and grouped these capabilities in logical groups

Suggestions for improvement can be made as replies to this post or via any other way. I will make it an official release towards the end of the year after I've processed your comments and suggestions. I'm looking forward hearing your opinion.

Attached Files
.xlsx   soc-cmm for CERT.xlsx (Size: 1,012.03 KB / Downloads: 500)
Print this item

  Security Monitoring - Use Case Frameworks
Posted by: robvanos - 06-05-2019, 01:52 PM - Forum: SOC-CMM community forum - No Replies

Security monitoring use cases are the beating heart of any security monitoring system. Even when a system is equipped with ‘out-of-the-box’ detection capabilities, there’s still use cases running underneath the hood. This is true for SIEM systems with default content packs as well as intrusion detection systems and more advanced network traffic analysis systems.

The only exception here would be systems that apply unsupervised machine learning. This is because there is no true use case, only statistics and thresholds that are applied to differentiate ‘normal’ from ‘abnormal’ behavior. The lack of a use case in these systems is, in my opinion, exactly the reason why such detection capabilities often provide little added value.

Back to use cases. An important question to ask is: what exactly is a use case? In security monitoring context, I believe that a use case is “a security monitoring scenario that is aimed at the manifestation of a cyber threat”. This is the definition that we created as a working group of the Dutch FI-ISAC when we created the MaGMa use case framework ( I know that this is highly simplified (there are many elements to consider), but I think it captures the essence of use cases. To break down a use case into useable parts, it is worth looking at use cases from different levels:

  • A high level that explains the use case in terms of risk. Use this level to talk to stakeholders and business.
  • An intermediate level that explains how the high-level risk could be exploited by cyber criminals. Use this level to integrate with threat intelligence TTPs.
  • A low level that shows how detection of that exploitation is implemented in detection technology
These levels correspond to the MaGMa L1, L2 and L3 levels respectively. The MaGMa use case framework can be used to structure use cases, document them and, most importantly, measure their performance through 3 metrics.
Using the MaGMa framework has brought us 4 important benefits:
  1. It has provided us with insight into which areas of security monitoring require improvement: low level use cases with low scores.
  2. It has provided us with insight into gaps in security monitoring: intermediate level use cases that have no or insufficient coverage in the
  3. It has provided us with guidance for replacing security components in the network. These security components are tied to use cases. The framework has helped us identify which use cases and the current shortcomings.
  4. It has helped us show how detection use cases reduce high-level risks.

Does anyone have any experiences with a security monitoring use case framework? Which one do you use, what are it’s core features and how has it helped you to evolve your security monitoring service?

Print this item

  SOC Certification Body
Posted by: darren.bnm - 05-16-2019, 06:43 AM - Forum: SOC-CMM community forum - Replies (2)

Hi Rob, 
Do you know of any SOC Certification Body?
For example, Head of Cybersecurity wants to prove that its SOC is an advanced SOC with all the top-notch technologies, processes, and people.
Is there any well-known third party that can certify this?

Best regards,

Print this item

  NIST 800-62r2 Not Available Yet
Posted by: darren.bnm - 04-16-2019, 08:17 AM - Forum: SOC-CMM bugs and issues - Replies (1)

Hi Rob,

Did u mean NIST 800-61r2?

Because there is no 800-62r2 available yet.


Attached Files Thumbnail(s)
Print this item

  Secure Event Transfer - Syslog
Posted by: darren.bnm - 04-12-2019, 08:22 AM - Forum: SOC-CMM community forum - Replies (1)

Hi Rob,

[Technology - SIEM Tooling - 1.6.25 Secure Event Transfer - Support for secure event transfer and the actual implementation of secure transfer (e.g. regular syslog is not secure)]

My environment using UDP/514 (not even TCP  Confused ) when sending syslog from a firewall to SIEM.

For best practise, do you recommend rsyslog TLS or TLS/6514 or syslog-ng with encryption enabled?


Print this item

  Asset Management Integration Vs Asset Context Integration
Posted by: darren.bnm - 04-12-2019, 07:27 AM - Forum: SOC-CMM community forum - Replies (1)

Hi Rob,
Under Technology Domain - SIEM Tooling, may I know what are the differences between Asset Management Integration and Asset Context Integration?
Because to me, they are the same thing.
Do you have any good examples?

Asset management integration:
Integration into the asset management process for automated adding of assets to the SIEM for monitoring

Asset context integration:
Integration of asset management information into the SIEM (asset owner, asset location, etc.)


Print this item

  Minor error - incorrect description
Posted by: darren.bnm - 04-11-2019, 08:46 AM - Forum: SOC-CMM bugs and issues - Replies (1)

Is the SOC management process regularly reviewed?
-Governance process is reviewed in an ad-hoc fashion

Attached Files Thumbnail(s)
Print this item

Information Follow-up of SOC-CMM assessments - Best practices
Posted by: robvanos - 04-10-2019, 11:57 AM - Forum: SOC-CMM community forum - No Replies

I've often received questions on follow-up of assessments. The survey also revealed that more guidance for follow-up would be appreciated. The SOC-CMM can never provide a tailored advice for improving your SOC. You will need to analyze the results to determine the exact next steps. However, I'd like to share some best practices regarding follow-up that I've used personally.  These may overlap somewhat with the sheet that is already part of the SOC-CMM.

  1. Compare results to target levels to determine which areas require most improvement. The SOC-CMM output sheets should provide the desired insight into areas for improvement. The output sheet does not contain a drill-down function, so you should navigate to the appropriate sections to determine which elements affect the score the most. In the basic version, you only need to look at the scoring column. In the advanced version, you will need to look at the importance column as well (that is, if you've changed any values).
  2. Perform a root cause analysis. A root cause analysis will be required to find common causes obstructing growth of the SOC. These root causes can be addressed to improve in multiple aspects at once.
  3. Determine a path for improvement. There are many factors that contribute to this path, but some of the most common factors are:
    A. associated risk. Every aspect that needs to be improved carries some level of risk. Ask yourself the question: what happens if we do not invest in this aspect? Is there an immediate impact? For example, contractual agreements are not met, or security incidents are not properly handled. Or a long-term impact? Not having a charter may not cause immediate problems, but in the long run, it may obstruct growth of the SOC due to lack of management support. The risk can be used to prioritize improvements. Use a MoSCoW method (Must haves, should haves, could haves, won't haves) to further structure this analysis.B. ease of improvement. Complexity could be caused by dependence on other teams or departments within the organization. Complexity can also be caused by internal politics and lack of management support or budget. By focusing on low-hanging fruit, quick wins can be made.C. interdependency. Some improvements may depend on each other, so there is a natural order in which they should be addressed.D. same or similar root cause. Improving the SOC by addressing root causes will likely have a positive effect across multiple domains and thus contribute greatly to improvement. Use the output from the root cause analysis from step 2.
  4. Define a formal (improvement) track or project. With many things that need to be improved, it is wise to create a project or program for monitoring progress and success. This track could be monitored from within the SOC or by a project manager outside the SOC. The size of the improvement program and the organizational culture determines which is best suited.
  5. Follow-up with a new assessment to measure and show progress. Note that this also requires taking notes during the assessments, especially for those parts of the assessment that raised a lot of discussion regarding interpretation. Otherwise, different questions may be interpreted differently in the second assessment.
Following these 5 steps should help you to get to the next step in your SOC's maturity.

If any one has other best practices to share, please do so.

Print this item

  Agile in Security Operations Centers - what's your take?
Posted by: robvanos - 03-21-2019, 03:55 PM - Forum: SOC-CMM community forum - No Replies

Our entire organisation has chosen to shift towards an agile approach. We've been doing agile (to be exact: scrum) in our security operations center for about a year now. I wanted to share some experiences and lessons learned:

  1. Moving to a scrum approach is not an easy transition to make. It takes some time and some frustration among your team members. It is important to keep an open culture in which you can express concerns and frustrations and address them.
  2. Scrum revolves around teams of a maximum of 7 people. A higher number is possible, but will make sessions longer and more complex. It may be difficult to find a way to split your team into smaller teams, while still supporting your SOC services and sharing knowledge within the teams. You should also be careful not to introduce process handovers between teams that introduce additional overhead.
  3. Scrum is not intended for operational departments. This means you shouldn't be too strict in implementing scrum rules. In short: make agile work for you, not the other way around.
  4. If you want to make scrum work, you will need a dedicated scrum master. This could be someone from the team. Just realise that this person will be tasked with optimizing the way in which the team works and matures in its agile approach and will have little time left for actual operational security tasks.
  5. There's overhead in the scrum process. It will likely replace several team meetings, but introduces other meetings. This overhead does serve a purpose: to gain visibility in the team workload and make the activities of the team more transparent.
  6. If done properly, scrum can help you accelarate the improvement of your SOC. This is because there's a clear understanding of the tasks at hand and a continuous flow of improvements (stories) that can be conducted.
  7. Not everything is a 'story'. Don't put eveything in your backlog, just the improvements. Operational stuff, such as monitoring duties should not be in there. That's just administration for the sake of administration.
  8. Kanban may solve some of your problems, but introduces others. There's still sessions, there's still planning and there's still a backlog. The basics are similar.
  9. Leave enough room in your sprints (if you've adopted scrum) to do ad-hoc stuff that wasn't foreseable.
  10. Seek to understand and optimize the amount of work a team can perform in any sprint while also responding to ad-hoc requests while having an acceptable workload.
  11. Backlogs can be used as an excuse not to act immediately. This actually makes you less agile. While this seems to be a contradiction, it wil happen if the team has a high workload.
  12. Clean you backlog every now and then. If a certain task wasn't given sufficient priority in the last few months, why should it get any priority in the next months?
Note: scrumban (a combination of scrum and kanban) is also possible. We're only just looking into this, so no lessons learned here yet.

I'm curious as to the experiences of others regarding implementing agile in security operations. What added value did or didn't it bring to your SOC?

Print this item