40 lines
1.6 KiB
Org Mode
40 lines
1.6 KiB
Org Mode
:PROPERTIES:
|
|
:ID: e3296579-2f2e-4f23-92e2-1ce9fef6fe04
|
|
:END:
|
|
#+TITLE: Cisco Team History
|
|
#+Author: Yann Esposito
|
|
#+Date: [2021-09-18]
|
|
|
|
- tags :: [[id:91f33b35-6e4e-4213-b214-972ee20722df][Cisco]]
|
|
- source ::
|
|
|
|
* Incident Merging / Playbooks
|
|
|
|
I would like to add my view about the Incident merging.
|
|
|
|
I think it is important to keep in mind the history of this team.
|
|
This team was built to be "the future" of Cisco Security.
|
|
The idea was lead by Dean and Craig.
|
|
The central notion of the product was /Playbooks/.
|
|
|
|
To my understanding, the main idea behind Playbooks was to have a kind of
|
|
meta system built by domain experts to greatly improve Threat hunting.
|
|
Typically by being able to discover complex links between different
|
|
warnings from different places in the system and how to react to them.
|
|
|
|
For example one of the first mission given to the rule engine was to
|
|
generate COAs (Course of Actions) from Sightings.
|
|
This give a better idea about what the engine could bring to the product.
|
|
|
|
Regarding using the engine to manage the incidents look a bit strange to
|
|
me.
|
|
As you all pointed out, if an incident is like a github-issue, having too
|
|
much github issue should be fixed at the source of the problem.
|
|
Prevent the automatic creation of too much similar issues.
|
|
If that could help to put the engine in a place where they could show their
|
|
strength I am all for it.
|
|
|
|
Mainly I think that keeping this idea of "Playbook" gives a better argument
|
|
about what problem is trying to be solved by the incident merging.
|
|
I think the main problem to solve might not be for the user but to give the
|
|
engine a real concrete use case.
|