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   ) 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?


Thanks!

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.)

Thanks!

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

Attached Files

Thumbnail(s)
   

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.
   

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?
    

The SOC-CMM is currently aligned with NIST CSF 1.0 and NIST CSF 1.1. Indirectly, this connects the SOC-CMM to other standards, such as: COBIT 5, ISO/IEC 27001:2013 and NIST SP 800-536. What additional alignments could be valueable to the SOC-CMM community?

The SOC-CMM survey has indicated that some users are looking for additions to the SOC-CMM services domain. Which additions should be considered?

The SOC-CMM survey has indicated that some users are looking for additions to the SOC-CMM technology domain. Which additions should be considered?

The SOC-CMM survey has indicated that some users are looking for additions to the SOC-CMM process domain. Which additions should be considered?

The SOC-CMM survey has indicated that some users are looking for additions to the SOC-CMM people domain. Which additions should be considered?