Initial documentation Ideas

Attendees

• Jeremy McKowski
• Kevin Vasquez
• Corbin Jay
• Marlene Cowans
• Joshua Ford

TL;DR:

We need to capture general documents on different types of documentation. This document is a general outline of the types of documentation we should be collecting, general policy guidance and is not a complete or comprehensive list. This is general guidance, and will be updated as needed. There will be a procedures guide that will highlight more details on the explicit HOW-TO on specific topics.

15 NOV

• Example: For a specific event you do XYZ procedure.

SOC Roles & Responsibilities

Primary focus for SOC Analyst - Monitoring, Investigating, and finding a solution (Recovery).

• Monitoring

• Identifying suspicious activity (brute force attacks, malware alerts, etc.)

• Ensuring that alerts are logged appropriately

• Checking severity

• Follow standard operating procedures

• Investigating

• Investigate once an alert is initiated. As a SOC analyst, it’s important to follow an established process of gathering evidence and documenting anything that may need to be reported.

• Using SIEM logs for investigation (In our case, Wazuh)

• Coordinate with other deployment teams if needed

Recovery

• Finding our problem and solving it. It includes containment, service restoration, and final documentation of how the solution is fixed.

A recovery list of questions:

• What was done to stop an attack?
• Was any software applied?
• What future changes are recommended?
• Incident Responses Documentation
• What to do about them
• For your documentation be detailed on anything related to the event
• What was the event?
• Who caused it (internal or external)
• Was the incident an exercise? Was it real?

What to do during/after

Event Documentation - Policy on what to document

WHY

• List itemTo capture what we do, when we do it, and provide a chain of thought for how to move forward from different events

• Events include but are not limited to, installs, upgrades, and major changes to the system as a whole, or in part.

WHAT

• How did you do it? Why did you do it? WHere did you do it
• Was there anything of note in what you did?
• Was it difficult? Was it easy?
• What problems have you had? What issues arose, were you able to solve them? If not why?

WHEN - Ideally as it is being done

• Can be done after as a more after action report style report Etc

• Anything that is of note that is not mentioned here and would help another group to continue work and the like

• All events should have some limited documentation (procedures on how to do those is forthcoming) Chain of communication

• How do we communicate issues to the people who need to know? Send an email and ensure to cc all individuals that will need to know.

• Who is the emergency contact list for each position? The emergency contact would be the on-call person if there is one, or the person that is the lead for the particular area that is having issues.

• What kind of schedule do we need, who can we call and when do we call them / how do we escalate.

• Given this is unpaid class scheduling is going to be difficult, maybe we should aim to be available to respond as we are able - if this was the real world then we - would need someone on call at all times who knows what to do in emergencies.

• During active cyber-attacks we need to call whomever the most appropriate contact for the situation might be, or when we detect a critical event we need to inform everyone in the soc of what is happening via a group email or group chat.

• How can we make this simple and automate it with something like Power BI or Microsoft Power Automate, maybe some kind of email alert system that will send to people in a document at different times like a schedule : could one of the coding guru’s come up with something that may work better? We will need to evaluate this one at a later time, I know that power automate can send emails when forms are completed, maybe we could