User Guides
      Back to home
      1. Knowledge Base
      2. General
      3. User Guides

      Best practice guide for recording information in Cydarm

      This guide outlines best practices for effectively recording information in Cydarm, including the use of tags, metadata, notes, STIX data, and forms.

      Introduction

      Cydarm is a comprehensive cybersecurity incident response platform that streamlines the management and documentation of security incidents for security operations center (SOC) managers and Chief Information Security Officers (CISOs). This guide outlines best practices for effectively recording information in Cydarm, including the use of tags, metadata, notes, STIX data, and forms.

      Cases

      Cases in Cydarm come with built-in fields such as assignee, severity, and workflow state. These fields are essential for initial case categorization and tracking the progress of the response.

      Organization

      The organization property of a case identifies the risk owner associated with that case.

      Default ACL

      The default Access Control List (ACL) on a case controls the authorization by users to discover, read, and write to the case.

      Assignee

      Assign cases to the appropriate team member responsible for handling the incident. This ensures accountability and clarity in the response process.

      Severity

      Assign a severity level to each case based on the impact and urgency of the incident. This helps prioritize response efforts and allocate resources effectively.

      Workflow state

      Use workflow states to track the progress of the case through the response process, eg. following SANS or PICERL. This provides visibility into the current status and next steps for the case.

      Tags

      Tags should be used for controlled vocabularies that have a known cardinality. They are useful for categorizing cases based on predefined criteria. By convention, tags are grouped into tag categories, delimited by colons. This allows related tags to be considered together.

      • Best practices for using tags

        • Use tags consistently across cases to facilitate filtering and reporting.

        • Avoid creating too many tags, as this can lead to clutter and reduce their effectiveness.

        • Create a standardized set of tags that reflect common incident types, attack vectors, affected asset types, or source systems. For example, you could use specific tags to categorise Case types:

          • Incident Tag. This tag could be used to mark when an actual incident occurred, distinguishing it from other events. N.b. you may need to add the tag to your system.

          • The tag case-type:incident or similar could be used so that you can have other tag types.

          • By tagging incidents appropriately, you can filter cases in the case list and the Case Details Report to display only those with the Incident tag. 

        • Create customized rules for mandatory tags from particular tag groups based on the status of the case. This ensures that crucial information is consistently collected and tracked throughout the case lifecycle, providing a more streamlined and efficient process. For example:

          • Managers can set tag groups as mandatory depending on the status of a case. When a case enters a status with mandatory tags, the UI will prompt users to add at least one tag from the designated group. For example, while a case is in Analysis the user might be required to characterize the case with a tag from the outcome group, such as outcome:false-positive.

      Metadata

      Metadata should be used for free-form text such as URLs, names of people, or other unstructured information that doesn't fit into predefined categories.

      • Best practices for using metadata

        • Use metadata fields to capture important details that are specific to the incident, such as links back to originating incidents in detection platforms, involved parties, external references, or custom indicators of compromise.
        • Ensure that metadata is entered in a consistent manner to facilitate searching and analysis.

      Notes

      Notes provide a way to document observations, actions taken, and other relevant information during the incident response process.

      • Best practices for using notes

        • Use notes to record chronological details of the response, including hypotheses, findings, decisions made, information sent and received, and rationale.
        • Use notes to record observations from analysis tools such as Queries, scripts, regex patterns
        • Apply significance levels to notes to make filtering and reporting easier.
        • Encourage team members to add notes regularly to maintain a comprehensive record of the response.

      STIX data

      STIX (Structured Threat Information eXpression) data allows for the standardized exchange and representation of threat information.

      • Best practices for using STIX data

        • Use STIX data entry to create threat intelligence for sharing with external parties or other tools.
        • Develop consistent practices for assigning significance levels, credibility of information, and name and description to STIX data.
        • Use STIX data entry to trigger enrichment tasks with external systems.

      Forms

      Forms can be used to standardize the collection of information for specific types of incidents or response processes, or to initiate external actions. Form submissions are indelible, to maintain proof of chain of custody, and fidelity of submitted actions.

      • Best practices for using forms

        • Create forms for common incident types to ensure consistent data collection.
        • Design forms with clear and concise fields to facilitate easy completion by responders.
        • Regularly review and update forms to reflect changes in response procedures or information requirements.
        • Use forms for triggered automations 

      Significance levels

      Significance levels help prioritize incidents based on their impact and urgency.

      • Best practices for using significance levels

        • Define clear criteria for each significance level to ensure consistent application across cases.
        • Use case recommendations for significance level application:
          • Summary - This is the canonical summary of the case. The most recent Summary will appear at the top of the case report. Apply this significance level when generating summary reports or executive summaries of events or incidents.
          • Disclosure Export - Utilize this level when transmitting data to external parties.
          • Disclosure Import - Assign this significance level upon receiving data from external sources.
          • Significant Action - Denote this level when executing critical actions, such as isolating a compromised host from the network. 
          • Significant Decision - Use this significance level when making pivotal decisions regarding action items, such as determining whether to pay a ransom.
          • Significant Finding - Apply this level when you observe critical findings, such as discovering malware on a host. 
          • Comment - This is the default significance level for general comments or notes added to cases or reports. It can be used broadly to provide context without indicating high urgency.
          • Attachment - Assign this significance level when including files, images, or links.
      • Regularly review and adjust significance levels as needed based on changes in the threat landscape or organizational priorities.

      Playbooks and actions

      Playbooks provide predefined response procedures, while actions represent specific tasks within a playbook.

      • Best practices for using playbooks and actions

        • Develop playbooks for common incident scenarios to streamline the response process.
        • Ensure that actions within playbooks are clearly defined and actionable.
        • Regularly review and update playbooks and actions to reflect changes in response strategies or emerging threats.
        • Encourage incident responders to comment directly on actions so that the comments are collated against the action.
        • Use standalone actions (either predefined or on-the-fly) to delegate tasks that are not associated with a specific playbook.
        • Use playbooks for response activities that require later attestation.
        • Playbooks enable less experienced team members to contribute more effectively, and reduce the cognitive burden on more experienced team members.

      Other Cydarm incident management recommendations 

      The following Cydarm recommendations offer practical approaches to categorize, track, and document cybersecurity incidents effectively, ensuring critical details like timelines, actions, and outcomes are systematically captured to improve response efficiency and compliance.

      1. The date the cyber security incident occurred and the date the cyber security incident was discovered:

      You could track key dates related to cybersecurity incidents by considering: 

      • Incident Discovery Date: The case creation date can serve as the discovery date, indicating when the incident was first detected.
      • Incident Start/End Dates: Use the Triage/Closed dates in the Case Details Report to show the timeline of the incident, from start to closure.

      2. A description of the cyber security incident:

      You could implement this by using the most recent ‘Summary’ note. For instance: 

      • When a Case Report is created for a single case, the system would display the latest ‘Summary’ note (which is based on the significance level ‘Summary’ under Notes) in the header fields, alongside other key information such as assignee and severity. 
      • As the ‘Summary’ note is currently only displayed in the Case Report, we have begun to scope a way we could also display it in the case list and/or case details report. We will keep you updated.

      3. Any actions taken in response to the cyber security incident:

      This can be drawn from the case notes in the Case Activity Thread, but ideally is included in the most recent Summary.

      4. To whom the cyber security incident was reported:

      This could be achieved by using:

      • The Contact register (select notified organisation or the individual using a form), or
      • A tag group with prefix notified.

      Conclusion

      Effective recording of information in Cydarm is crucial for efficient incident response and management. By following these best practices, SOC managers and CISOs can ensure that their teams are well-equipped to handle security incidents and maintain a comprehensive record of their response efforts.

       

      For more detailed technical information please refer to our Cydarm API documentation.