IBM QRadar SOAR

IBM QRadar

Join this online topic group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.


#Security
#QRadar
#SecuringhybridcloudandAI
 View Only

  • 1.  Parent Child Incidents function

    Posted 10/16/19 09:06 AM

    Hi all,

     

    As part of our on-going requirements/enhancements in our organization we have a new requirement as follows :-

     

    R1. Function/feature to create child incident

    • When the function is invoked from incident A, a new incident B should be created.
    • The incident A's field "Child incident" should be added with the incident B's ID.
    • The incident B's field  "Parent incident" should be set to incident A.

     

    Note: A parent can have multiple children incidents. As a result, the child incident field should be accepting multiple values: ID1, ID2, ID3

     

    R2. Copy fields, artifacts and artifacts

    Additionally, the above function should take 5 parameters as input to be passed from workflow as follows:-

     

    • List of Fields api names: Example: co_categorization, co_Killchain
    • Copy artifact: Yes/No
    • Copy Attachments: Yes/No
    • Case_Type
    • Name

     

    • For the fields in the list above, same value from Parent incident should be copied to child incident created.
    • If copy artifact is selected by user as "yes", artifacts in Parent incident will be copied to created child incident
    • If copy attachment is selected by user as "yes", artifacts in parent incident will be copied to child incident.

     

    As of now we do not see any in-product function or feature to accomplish this, can anyone please provide us a solution as per the requirements mentioned above?



    ------------------------------
    Arjun Jaiswal
    ------------------------------


  • 2.  RE: Parent Child Incidents function

    Posted 10/16/19 03:13 PM
    R1. This functionality does not exist. You could loosely link incidents through the use of clever rule sets involving fields, but that is about it. See the aha.io idea here.

    R2. This function can be created via a custom-built function that passes the fields to the function. The Resilient API will be required to modify multiple incidents. I have not seen this published by anyone as of yet, so you would need to create this yourself.

    ------------------------------
    Jared Fagel
    Cyber Security Analyst Intern
    Public Utility
    ------------------------------



  • 3.  RE: Parent Child Incidents function

    Posted 10/17/19 01:22 PM
    Edited by BENOIT ROSTAGNI 10/17/19 01:27 PM
    To avoid starting from scratch, there was a work created by a former TechSales that was a Parent-Child work, selecting multiple incident and deciding which one was the parent, all IOC were copied to it, and all tasks done on parent where mirrored to children, Top Down propagation, for a Batch type work on same type of incidents.

    Note by the Author:
    Collector package content: 10 functions, 6 workflows, 18 rules, 1 script and 4 data tables.
    The Collector integration is for DEMO PURPOSES ONLY. I strongly advise against any type of POC usage, let alone Production usage.
    Use only for demo, strictly under your control and narrative. 
    - Do not share the code with prospects/customers. 
    - Do not let prospects/customers explore the Collector functionalities on their own.
    - Do not change or adapt the code for any other purpose than demo (enhancement). If you do, I will not take any responsibilities.
     
    Remarks:
    1) There's some limited hardcoded stuff:
    - You need to copy the attached json's in directory .resilient/samples/
    - In function fn_collector_task_change.py(line 44) change the task owner "api@acme.com" to the your Resilient orchestration/integration/bot User.
    2) The integration supports creating a collector independent of an existing incident by manually selecting the incident types for the new collector. This support is not being used using the package as is. In the end I decided that this went too much against Resilient design, but I left the supporting code in the relevant functions. The collector will be therefor be created based on running the "create collector" per existing incident, as shown in the demo recording.
    3) The code is hardened as much as I could think of, with error and info log messaging. However, you might run into a condition that I didn't anticipate.
    4) The code is relatively clean with explaining comments. However, there could be still some debug lines left and traces of test/dev code (commented) lines.

    Apparently the create package doesn't include this. It should imo. Anyway:
    Incident Types:
    "Collector"
    "In Collection"
    Artifact:
    "Collector ID"
     

    ==> So no support from me on this code, and the author left IBM :)

    ------------------------------
    BENOIT ROSTAGNI
    ------------------------------

    Attachment(s)

    zip
    collector.json.zip   9 KB 1 version
    gz
    collector.tar.gz   45 KB 1 version
    Original Message


Related Content