Agree with the sentiment of letâs not get hung up on category labels. In practice youâll have playbooks that do two or more of these categories anyway.
From: email@example.com <firstname.lastname@example.org>
On Behalf Of Allan Thomson
Sent: Thursday, February 6, 2020 11:04 AM
To: Vasileios Mavroeidis <email@example.com>; Andrew Storms <firstname.lastname@example.org>
Cc: Bret Jordan <email@example.com>; firstname.lastname@example.org
Subject: [External] Re: [cacao] Preventative Action
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
I suggest mitigation is not just a retroactive action.
Mitigation embodies the active engagement of a threat or threats. Retroactive implies the threat already took place and you are âreactingâ to the threat.
Regardless of what the decision is, I feel that this is debatable and not that important in the scheme of work we have to do.
Whether you label a playbook preventative or mitigative, it matters more what the playbook actually does.
And we are not stopping anyone from defining a playbook that has multiple categories of actions. In many cases, playbooks will start with an investigation before taking a preventative or mitigative step next based on the investigation.
So I suggest we focus on the details of how a playbook is constructed and let the label/categorization just be informational at best. Weâre not going to stop people from mislabeling or mischaracterizing their playbooks to share. Most people
who will consider using a playbook in their environment would look at the details of what it does not just a label. Then they can consider whether its valuable or not from that.
A Prevention playbook should be considered a pro-active mechanism.
Mitigation for me is retroactive, But we can talk about risk mitigation which in this case would be considered a proactive mechanism. On the other hand, risk mitigation can be defined as a preventive mechanism as long as the playbook can
control potential side-effects ( such as loss of data ). So even though that you cannot patch a machine (for a, b reason) you have still control over your machines and your networks, such as the case that the machine is isolated.
Maybe we can just include one extra word in the description of each terms (proactive vs retroactive)
I read those in the doc and was the source of my question. I read that definition of Preventative Action and asked myself what is the difference between prevention and mitigation.
Harking back to my CISSP days, we typically used risk management terms of: accept, mitigate or remediate.
So I attempted to find the uniqueness of Preventative by making a quick matrix which used the examples in the docs. I was hoping it would help to better define Preventative.
I just want to be more clear with Preventative Action and see if we can provide some clarification. I think an example would be helpful. If we say that Mitigative and Remediative
essentially happen after we learn of a potential attack method. And Preventative is more like a hygiene/best practice/configuration change/pro active steps? Is that inline with what you are thinking?
I think it is important that we all use the same definitions for things. I have called these out the documents to help in this regards. I have heard many seasoned security
analysts and security architects use these terms incorrectly.
From the requirements document:
Investigative Action - This is an action that is used to gather information relevant to the construction
or modification of cyber security playbooks. This includes gathering of information about a possible incident, problem, attack, or compromise. In some cases, an investigative action could require changes to the systems, networks or application behaviors in
order to facilitate a deeper understanding of the investigation and resultant potential response.
Mitigative Action - This is an action that is used to respond to problems that can occur from an incident,
problem, attack, or compromise. This is often done when a remediative action is not currently possible. For example, when a system patch is not yet available, one might deploy compensating controls such as moving the system into a sandbox virtual lan (vlan)
or deploying more stringent firewall rules.
Remediative Action - This is an action that is often used with a goal of eradicating an issue, problem,
attack, or compromise on one or more systems that have been determined to be compromised or involved in the particular event.
Preventative Action - This is an action that is used to help ensure that an issue, problem, attack, or compromise
does not happen in the first place. In some cases, preventative actions may overlap with certain mitigative and remediation actions.
So a preventative action could be like deploying the CIS Top20 security controls. Or could be deploying a block on the firewall for the next HeartBleed
before you get compromised.
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
I'd like some help in better understanding the Preventative action type.
What is unique to a Preventative action that is different from Remediative or Mitigative? I recognize that there is some overlap, however it would be great to have 1 example to demonstrate the uniqueness of Preventative that would qualify it as needing its
own action type.
In order to try and get my head around this, I did a quick matrix of the current examples and mapped them to each action type. What I'm not seeing is a use case where Preventative
would not have already been categorized as either mitigative or preventative.
Does anyone have a good and unique example for Preventative?
VP of Security Services
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by
you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of
internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement