WEBVTT

0:00:03.380000 --> 0:00:05.760000
 Hello everyone and welcome.

0:00:05.760000 --> 0:00:09.820000
 In this video we're going to be taking a
 look at Playbooks and more specifically

0:00:09.820000 --> 0:00:12.600000
 how Playbooks are used.

0:00:12.600000 --> 0:00:17.220000
 So you know automating various software
 flows with Playbooks but the examples

0:00:17.220000 --> 0:00:21.100000
 that I'll give you will be really focused
 on you know incident response

0:00:21.100000 --> 0:00:25.260000
 will be really incident response
 playbook examples.

0:00:25.260000 --> 0:00:30.060000
 So you know you may be confused as
 to why I'm going over Playbooks in

0:00:30.060000 --> 0:00:34.460000
 the end but the reality is that you
 know you only realize or recognize

0:00:34.460000 --> 0:00:39.060000
 the importance of Playbooks once you've
 done something manually or for

0:00:39.060000 --> 0:00:41.460000
 that matter any automation system.

0:00:41.460000 --> 0:00:46.220000
 So that's the reason why you seek to
 automate or optimize a process is

0:00:46.220000 --> 0:00:49.600000
 by experiencing what it's like manually.

0:00:49.600000 --> 0:00:58.980000
 In any case in the context of a security
 operation center a playbook is

0:00:58.980000 --> 0:01:03.860000
 a actions that guide analysts through
 responding to specific security

0:01:03.860000 --> 0:01:09.140000
 incidents. So just think of it as a you
 know you being a pilot in an aircraft,

0:01:09.140000 --> 0:01:14.840000
 pilots have checklists you know that
 they need to you know check before

0:01:14.840000 --> 0:01:17.720000
 they take off and you
 know before they land.

0:01:17.720000 --> 0:01:19.840000
 Why are these checklists important?

0:01:19.840000 --> 0:01:25.340000
 Well they're important to ensure that
 the A you know the correct set of

0:01:25.340000 --> 0:01:32.060000
 actions is performed in you know the
 correct sequence but B because you're

0:01:32.060000 --> 0:01:35.860000
 sort of using it as a baseline it can
 be improved over time and you know

0:01:35.860000 --> 0:01:41.100000
 it's structured but more important
 than that it also ensures a certain

0:01:41.100000 --> 0:01:44.840000
 level of consistency with regards
 to the actions taken.

0:01:44.840000 --> 0:01:48.800000
 So these Playbooks help standardize
 and automate the response process

0:01:48.800000 --> 0:01:54.920000
 or processes ensuring incidents are
 handled consistently efficiently and

0:01:54.920000 --> 0:02:00.440000
 accurately. In essence or to summarize
 Playbooks act as a step-by-step

0:02:00.440000 --> 0:02:06.200000
 guide or guides for responding to security
 threats detailing what actions

0:02:06.200000 --> 0:02:11.580000
 should be taken in what order and by
 whom and that's the best way to sort

0:02:11.580000 --> 0:02:14.400000
 of explain it was highlighted
 in red here.

0:02:14.400000 --> 0:02:20.600000
 So the you know it may already seem
 obvious but why use Playbooks in SOC

0:02:20.600000 --> 0:02:25.520000
 operations? Well A standardization
 as I mentioned so Playbooks ensure

0:02:25.520000 --> 0:02:29.880000
 every incident is handled using consistent
 procedures, reducing errors

0:02:29.880000 --> 0:02:32.100000
 and reducing oversights.

0:02:32.100000 --> 0:02:34.940000
 You then have speed and efficiency
 when you have something in front of

0:02:34.940000 --> 0:02:38.780000
 you like a checklist you know there's
 very little thinking and decision

0:02:38.780000 --> 0:02:42.680000
-making which you may think is a bad
 thing but if the Playbooks have been

0:02:42.680000 --> 0:02:47.960000
 defined or developed through experience
 over years and by experienced

0:02:47.960000 --> 0:02:50.060000
 individuals then you know
 you can trust them.

0:02:50.060000 --> 0:02:54.140000
 The bottom line is that it automates
 repetitive and time-consuming tasks

0:02:54.140000 --> 0:02:58.540000
 accelerating the incident response
 process and you know making things

0:02:58.540000 --> 0:03:03.820000
 faster. You then have reducing alert
 fatigue which you know I mentioned

0:03:03.820000 --> 0:03:07.540000
 is a key issue you know for incident
 responders or analysts in the SOC

0:03:07.540000 --> 0:03:16.900000
 in general. So Playbooks automated the
 triage of low severity alerts allowing

0:03:16.900000 --> 0:03:21.000000
 decision-making so it provides a clear
 guide for analysts reducing the

0:03:21.000000 --> 0:03:26.140000
 need for complex decisions in high-pressure
 situations which is very important.

0:03:26.140000 --> 0:03:30.020000
 You then also have an enhancement to
 or you know you're actually learning

0:03:30.020000 --> 0:03:36.200000
 so these Playbooks and I've seen this
 extremely valuable to you know new

0:03:36.200000 --> 0:03:40.400000
 SOC tier one analysts in the sense that
 it helps these less experienced

0:03:40.400000 --> 0:03:47.320000
 analysts by providing a clear repeatable
 response process right.

0:03:47.320000 --> 0:03:50.560000
 So they actually know what
 to do much quicker.

0:03:50.560000 --> 0:03:54.800000
 Now they obviously will need to understand
 a couple of things but the

0:03:54.800000 --> 0:03:59.040000
 Playbooks themselves allow them you know
 to identify what they don't know

0:03:59.040000 --> 0:04:03.200000
 so that they can ask more experienced
 analysts and then finally ensures

0:04:03.200000 --> 0:04:08.340000
 compliance. So it helps Playbooks help
 support regulatory and compliance

0:04:08.340000 --> 0:04:11.680000
 requirements by standardizing and that's
 very important if you've worked

0:04:11.680000 --> 0:04:16.580000
 in a company before standard standardization
 of processes and then of

0:04:16.580000 --> 0:04:21.880000
 course these subsequent documentation
 supporting those processes as well

0:04:21.880000 --> 0:04:26.920000
 as you know helping you to standardize
 reporting so that you know everything

0:04:26.920000 --> 0:04:31.360000
 looks consistent you know in the beginning
 they'll look consistently bad

0:04:31.360000 --> 0:04:35.640000
 but with the Playbooks you get to use
 that as a basis for improvement

0:04:35.640000 --> 0:04:40.620000
 you know otherwise how do you know what
 needs to be improved if you cannot

0:04:40.620000 --> 0:04:44.860000
 point to it you know as an item within
 a playbook or you know a checklist

0:04:44.860000 --> 0:04:48.420000
 a checkbox if you will.

0:04:48.420000 --> 0:04:52.640000
 So how are Playbooks used in the SOC
 well they used for incident detection

0:04:52.640000 --> 0:04:58.700000
 so that's why I did not limit it I did
 not limit my explanation of Playbooks

0:04:58.700000 --> 0:05:02.380000
 in terms of what they are and how they're
 used to incident responses because

0:05:02.380000 --> 0:05:07.360000
 you'll find them used for quite a few
 services or in support of quite

0:05:07.360000 --> 0:05:11.160000
 a few services within a SOC so in the
 case of incident detection the SOC

0:05:11.160000 --> 0:05:15.500000
 detects a potential threat for example
 you know fishing email or malware

0:05:15.500000 --> 0:05:20.900000
 alert there's a playbook on how to deal
 with that then for playbook triggering

0:05:20.900000 --> 0:05:25.720000
 so based on the type of alerts the corresponding
 playbook is automatically

0:05:25.720000 --> 0:05:29.700000
 triggered via let's say something like
 a SOAR platform I've already explained

0:05:29.700000 --> 0:05:33.840000
 it that's why I covered the SOAR first
 or initiated manually by an analyst

0:05:33.840000 --> 0:05:41.340000
 you also have automated actions this
 is another way other playbooks are

0:05:41.340000 --> 0:05:45.300000
 utilized so the playbook initiates automated
 tasks such as alert enrichment

0:05:45.300000 --> 0:05:50.580000
 triage or initial containment you then
 have manual decision points so

0:05:50.580000 --> 0:05:54.180000
 if required the playbook presents decision
 points where an analyst must

0:05:54.180000 --> 0:05:58.760000
 review data and choose the next action
 you then have you know final response

0:05:58.760000 --> 0:06:02.800000
 so the playbook completes the instant
 by ensuring containment eradication

0:06:02.800000 --> 0:06:06.720000
 by ensuring these steps are taken those
 being containment eradication

0:06:06.720000 --> 0:06:11.480000
 and recovery so there's a checklist
 for containment eradication recovery

0:06:11.480000 --> 0:06:16.540000
 and then finally documentation and
 reporting so all actions are logged

0:06:16.540000 --> 0:06:21.080000
 and reports are generated for compliance
 in post incident analysis so

0:06:21.080000 --> 0:06:25.540000
 let's take a look at some examples
 of what a playbook looks like right

0:06:25.540000 --> 0:06:29.420000
 so I've generated one that you know based
 on some of the ones I developed

0:06:29.420000 --> 0:06:34.420000
 like a fish a fishing email response
 playbook so the objective of this

0:06:34.420000 --> 0:06:40.000000
 playbook is to you know provide procedures
 for analysts to you know analyze

0:06:40.000000 --> 0:06:44.640000
 and respond to potential fishing emails
 so playbook procedures step one

0:06:44.640000 --> 0:06:48.720000
 in just the suspicious email alert
 via see more mailbox monitoring so

0:06:48.720000 --> 0:06:52.840000
 that's just collection if you will then
 automated analysis in this case

0:06:52.840000 --> 0:06:57.440000
 the playbook contains automation or
 is built in so check the sender's

0:06:57.440000 --> 0:07:02.500000
 domain reputation what are the sub tasks
 under that analyze or in terms

0:07:02.500000 --> 0:07:07.860000
 of if you're going to automate analysis
 of a malicious email this is what

0:07:07.860000 --> 0:07:12.400000
 would be involved you would do this
 manually so this can also work from

0:07:12.400000 --> 0:07:16.100000
 that perspective but you would start
 off by analyzing email headers and

0:07:16.100000 --> 0:07:21.340000
 attachment hashes against threat intelligence
 feed you then scan the email

0:07:21.340000 --> 0:07:26.860000
 body for malicious links okay so this
 is sequential remember so it again

0:07:26.860000 --> 0:07:31.120000
 let's say you're a brand new sock tier
 one analyst you would be given

0:07:31.120000 --> 0:07:35.680000
 something like this and if you detected
 a potential fishing email via

0:07:35.680000 --> 0:07:40.000000
 the seam then you would essentially
 follow these steps so once you're

0:07:40.000000 --> 0:07:45.280000
 done with analysis you know you then
 typically we can include we can just

0:07:45.280000 --> 0:07:48.660000
 say that the sock tier one analyst is
 going to handle this or is responsible

0:07:48.660000 --> 0:07:53.240000
 for this but we then have containment
 so this is sort of the decision

0:07:53.240000 --> 0:07:59.140000
 points that I was referring to so if
 you do indeed find that the email

0:07:59.140000 --> 0:08:05.760000
 is malicious you what you do is your quarantine
 the email from all mailboxes

0:08:05.760000 --> 0:08:09.940000
 and then you know blocks the sender's
 domain in this in the email security

0:08:09.940000 --> 0:08:15.240000
 system you then notify the user once
 you're you're done with that so you

0:08:15.240000 --> 0:08:18.600000
 send an alert to the recipient explaining
 the malicious nature of the

0:08:18.600000 --> 0:08:22.800000
 email and then you update the detection
 rules so you add new indicators

0:08:22.800000 --> 0:08:26.840000
 to block similar attacks in the future
 and then you document the incident

0:08:26.840000 --> 0:08:32.880000
 so what this means this playbook is
 usually you know is something that

0:08:32.880000 --> 0:08:36.800000
 you'll be given typically in the internal
 documentation something like

0:08:36.800000 --> 0:08:42.280000
 a confluence or whatever or built into
 the seam you know regardless what

0:08:42.280000 --> 0:08:46.680000
 this is essentially telling the analyst
 is when you see a potential fishing

0:08:46.680000 --> 0:08:51.640000
 email this is what you need to do in
 this order and these are all the

0:08:51.640000 --> 0:08:56.960000
 things you need to do you know if a
 particular if a particular logical

0:08:56.960000 --> 0:09:02.200000
 check you know answers yes or no so
 if it's not malicious then you know

0:09:02.200000 --> 0:09:06.080000
 you need to you you can either close
 the case or whatever in this case

0:09:06.080000 --> 0:09:10.060000
 the playbook doesn't include that but
 it only deals with you know if the

0:09:10.060000 --> 0:09:15.500000
 email and the email attachment is confirmed
 as malicious it then tells

0:09:15.500000 --> 0:09:19.380000
 you what to do so you know it's standardized
 there's no hesitation you

0:09:19.380000 --> 0:09:23.680000
 don't need to ask someone you just do
 it and then you finally you document

0:09:23.680000 --> 0:09:27.340000
 the incident and you generate a report
 you either send it or escalate

0:09:27.340000 --> 0:09:34.180000
 it up and you know you've done your job
 so you can start to see why important

0:09:34.180000 --> 0:09:40.300000
 I have another playbook here that's really
 for what you'd consider incident

0:09:40.300000 --> 0:09:46.180000
 responder or sock tear to analysts so
 the objective of this playbook is

0:09:46.180000 --> 0:09:51.560000
 to you know is to deal with you know
 detection and containment of malware

0:09:51.560000 --> 0:09:57.280000
 threats on endpoints so we start from I'll
 just disregard the actual ingestion

0:09:57.280000 --> 0:10:02.760000
 part of it but we start from automated
 enrichment so again in this case

0:10:02.760000 --> 0:10:08.140000
 I've included automation but you know
 we will just we'll treat it as if

0:10:08.140000 --> 0:10:12.980000
 we were doing this manually so what
 we need to do we scan the file hash

0:10:12.980000 --> 0:10:18.000000
 in a threat intelligence database so
 identify the origin of the malware

0:10:18.000000 --> 0:10:23.340000
 you know phishing drive by download
 etc we then move on to containment

0:10:23.340000 --> 0:10:28.540000
 so we need to isolate the affected endpoint
 if it's automated then automatically

0:10:28.540000 --> 0:10:33.660000
 do so and be within need to block communication
 with known C2 servers

0:10:33.660000 --> 0:10:37.760000
 there would be a decision tree there that
 would say if there is C2 communication

0:10:37.760000 --> 0:10:43.600000
 then block it if not check for C2 communication
 if there's nothing there

0:10:43.600000 --> 0:10:48.640000
 move on to remediation so in the remediation
 phase you then run an automated

0:10:48.640000 --> 0:10:52.880000
 malware scan remove and quarantine the
 malicious files you then move to

0:10:52.880000 --> 0:10:58.340000
 recovery and validation whereby you ensure
 the endpoint is clean and reconnected

0:10:58.340000 --> 0:11:02.320000
 to the network and then finally documentation
 record all actions and prepare

0:11:02.320000 --> 0:11:06.640000
 an incident report so this is what
 the playbooks look like don't worry

0:11:06.640000 --> 0:11:09.900000
 we'll get into this now because we're
 at the end of this course we'll

0:11:09.900000 --> 0:11:14.940000
 be you know when we get into the incident
 response courses whether we're

0:11:14.940000 --> 0:11:25.400000
 you know host based analysis or network
 analysis all that good stuff will

0:11:25.400000 --> 0:11:30.420000
 will actually be taking a look at playbooks
 in reality and how they can

0:11:30.420000 --> 0:11:35.880000
 be integrated into a C morris or all
 of that good stuff and finally i've

0:11:35.880000 --> 0:11:40.320000
 given you a treasure trove of what
 i consider to be the the references

0:11:40.320000 --> 0:11:46.620000
 or resources in the form of examples and
 templates you know playbook examples

0:11:46.620000 --> 0:11:53.420000
 and templates for that that encompass
 both general sock operations but

0:11:53.420000 --> 0:11:57.660000
 also incident response so firstly there's
 counter-actives incident response

0:11:57.660000 --> 0:12:03.100000
 plan template that's a github repo there
 please please please take a look

0:12:03.100000 --> 0:12:06.760000
 at the Microsoft incident response playbook
 and i've linked it right over

0:12:06.760000 --> 0:12:11.800000
 here and then i also have some really
 cool repos here like sock fortresses

0:12:11.800000 --> 0:12:16.120000
 playbooks for sock analysts and then
 another great reference it's more

0:12:16.120000 --> 0:12:20.060000
 so a pdf but that's a Caesar cybersecurity
 incident and vulnerability

0:12:20.060000 --> 0:12:26.980000
 response playbooks um a link to that
 pdf has been added there all right

0:12:26.980000 --> 0:12:30.740000
 so that brings us to the end of this
 video and there's really nothing

0:12:30.740000 --> 0:12:34.320000
 much to add there so with that being
 said that's going to be it for this