WEBVTT 00:07.370 --> 00:12.950 As a cybersecurity analyst, we often look at phishing or spear phishing emails, and we wonder ourselves 00:12.950 --> 00:14.450 how somebody could fall for it. 00:14.480 --> 00:18.410 As a security in the field, you have to remember that you're properly trained and you're constantly 00:18.410 --> 00:23.420 looking at these little hints or clues that identify it as a phishing or spear phishing email. 00:23.450 --> 00:28.070 But what happens when that email is more than just a phishing or spear phishing email? 00:28.070 --> 00:34.250 Maybe it's spoofed and it's coming from what looks to be a legitimate user or legitimate domain. 00:34.250 --> 00:37.010 That's where email analysis really comes into play. 00:37.010 --> 00:41.540 And you, as a cybersecurity analyst, need to be able to identify very quickly. 00:41.540 --> 00:44.090 Is this a legitimate source for the email? 00:44.120 --> 00:48.890 Did it properly come into play and into our environment from a legitimate source? 00:48.920 --> 00:54.230 Email analysis is really one of those things that you have to take for heart and understand the proper 00:54.230 --> 01:00.530 clues and the technology to utilize in order to understand if that email is truly valid, coming from 01:00.530 --> 01:02.050 a legitimate Source. 01:02.110 --> 01:05.260 In this episode, we're going to go over email analysis. 01:05.290 --> 01:10.300 We're also going to talk a little bit about the frameworks associated with how to secure our systems 01:10.300 --> 01:14.950 and the technology that we can utilize, both from a protocol standpoint as well as some of the other 01:14.950 --> 01:20.320 systems that we can use to ensure that somebody that's trying to pull off a spoofing email attack against 01:20.320 --> 01:22.510 our systems isn't successful. 01:22.540 --> 01:28.150 For Cisa exam, you need to understand these technologies, these protocols and how they interact with 01:28.150 --> 01:29.560 our different systems. 01:30.070 --> 01:35.320 Email analysis is more than just understanding if the email is coming from a legitimate source. 01:35.320 --> 01:38.950 We need to be able to analyze the content of the email itself. 01:38.980 --> 01:41.260 Does it have malicious links embedded in it? 01:41.260 --> 01:47.800 Are there attachments that could provide some unfortunate compromises to people that download them and 01:47.800 --> 01:48.610 click on them? 01:48.610 --> 01:54.940 It's not often that we don't see a piece of email with an associated invoice, or a link attached to 01:54.970 --> 01:57.520 it, that is actually leading to a piece of malware. 01:57.520 --> 02:04.320 We need to provide to our organization a clear cut pathway to stop these types of attachments and links 02:04.320 --> 02:06.090 from getting through our systems. 02:06.090 --> 02:08.520 We can also do what's called metadata analysis. 02:08.520 --> 02:13.950 This is where we look at the actual data that's hidden within the email body or the email contacts to 02:13.980 --> 02:16.380 find out where did the data really come from. 02:16.380 --> 02:19.920 We can track the different routers and the source and destination codes. 02:19.920 --> 02:24.270 We can track the legitimate information that's inside the email because it cannot be changed. 02:24.270 --> 02:25.620 It cannot be spoofed. 02:25.650 --> 02:29.940 We can look at the different links within the email, and we can look at the behavior that the email 02:29.940 --> 02:32.340 has when it's going through our system. 02:32.340 --> 02:37.950 All of these forms of analysis that go through our systems provide us a clear direction of whether the 02:37.950 --> 02:41.250 email is legitimate or if it's coming from a malicious actor. 02:41.250 --> 02:43.860 Within the email, there's something called the header. 02:43.860 --> 02:49.020 The header is the portion of the messages that contains details about the actual sender of the email, 02:49.050 --> 02:51.780 the route taken, and who it's going to. 02:51.810 --> 02:57.030 Analysts can use this email to detect whether an email is spoofed or suspicious in nature, and we can 02:57.060 --> 03:02.460 kind of derive from that information if that email has a legitimate purpose on our network. 03:02.490 --> 03:08.050 You can see here that we provided a legitimate header information, and that it shows us that the information 03:08.050 --> 03:10.000 is actually going to a specific user. 03:10.000 --> 03:16.360 If you pay attention, you can see that it goes to past the yahoo.com to yahoo.com dot pH. 03:16.390 --> 03:21.520 This means the recipient of the email isn't an actual user and is most likely spoofed. 03:21.550 --> 03:26.110 It's not often that we don't see someone trying to pose as somebody they're not. 03:26.110 --> 03:28.420 This is where impersonation comes into play. 03:28.420 --> 03:35.050 They spoof the address that the email came from in order to make the victim feel like we are a position 03:35.080 --> 03:41.170 of authority, a close relative, or even a friend, and impersonation is a major form or factor that 03:41.170 --> 03:46.210 can provide the gateway from a legitimate email passing through our security systems, or a phishing 03:46.240 --> 03:47.770 email passing through our systems. 03:47.770 --> 03:50.560 This plays a major role in email security. 03:50.560 --> 03:54.340 There is something called Sender Policy Framework, or SPF. 03:54.370 --> 04:00.250 This works by allowing domain owners to publish their DNS records that specify which email servers are 04:00.250 --> 04:03.300 authorized to send emails on behalf of their domain. 04:03.300 --> 04:05.810 I want you to picture this sort of like a phone book. 04:05.840 --> 04:10.340 I receive a phone call from somebody and that somebody is claiming to be my son. 04:10.370 --> 04:15.260 Obviously, it sounds like my son, because of deepfakes and all this other technology that's out there, 04:15.260 --> 04:17.810 but the phone number just doesn't look right. 04:17.810 --> 04:21.410 I can go through and actually go, hey, who are you calling? 04:21.410 --> 04:23.000 Oh, I'm on my cell phone. 04:23.000 --> 04:28.340 Well, obviously you're not on your cell phone because my caller ID identifies that that phone number 04:28.340 --> 04:29.570 isn't legitimate. 04:29.600 --> 04:32.390 Now, the first thing that comes to your mind is, wait a second. 04:32.390 --> 04:34.430 What if they're spoofing my phone number? 04:34.430 --> 04:40.220 Well, we understand that, but that's where the Sender Sender Policy framework comes into play. 04:40.250 --> 04:47.060 Unlike a phone system, we can actually go back to the DNS and identify is this a legitimate domain 04:47.060 --> 04:49.130 that they sent the email from? 04:49.130 --> 04:49.430 We. 04:49.430 --> 04:55.100 This provides us enhanced email delivery because we know that the domain that they sent it from is legitimate 04:55.100 --> 04:55.820 in nature. 04:55.820 --> 05:01.940 And we can have our systems to identify those legitimate servers as part of our inward ingress into 05:01.940 --> 05:06.520 our system, thereby allowing that email to process more smoothly. 05:06.520 --> 05:09.070 We can also do spoofing protection through this. 05:09.100 --> 05:14.860 If someone's claiming to have a domain such as, I don't know, yahoo.com, but it doesn't come from 05:14.860 --> 05:20.530 a legitimate server, then we can identify that as a spoofing email and protect ourselves from it. 05:20.560 --> 05:27.580 This reduces fraud and increases trust from that server, as we've identified the DNS associated specifically 05:27.580 --> 05:29.170 with that email server. 05:31.030 --> 05:35.470 Domainkeys identified mail, or DKIM, is another feature. 05:35.470 --> 05:40.390 This generates a pair of keys, much like a public private key that we see in encryption, where the 05:40.390 --> 05:46.360 organization's public key is published to the DNS records for later querying and in use by the recipient 05:46.360 --> 05:48.520 when sending a message to Kim. 05:48.550 --> 05:54.610 The sender includes a special signature header containing the hash of the email header, thereby stopping 05:54.610 --> 05:57.610 the or providing integrity for that email. 05:57.640 --> 06:03.040 A hash or a portion of the body and the details about the hash function can then be used to verify the 06:03.040 --> 06:04.960 email came from a legitimate user. 06:04.990 --> 06:07.290 Just like probit private encryption. 06:07.290 --> 06:13.230 We can then see the publisher or the sender of the email, because they've signed the email and provided 06:13.230 --> 06:14.970 the hash value of the content. 06:15.000 --> 06:16.800 This stops man in the middle, attacks. 06:16.800 --> 06:22.860 It verifies the signature of the sender and provides us a true trust determination through identification 06:22.890 --> 06:27.780 of legitimate user, thereby stopping spoofing emails from crossing through our systems. 06:27.780 --> 06:33.120 However, it should be warned that while it does verify the sender information, that doesn't mean that 06:33.120 --> 06:39.930 the sender may have put or implemented spoofing or malware within the email, it only verifies that 06:39.930 --> 06:46.290 the information was sent from a specific server, not that the email doesn't have, uh, malware embedded 06:46.290 --> 06:47.070 within it. 06:47.610 --> 06:52.230 Finally, we have something called domain based message Authentication, Reporting and Conformance, 06:52.230 --> 06:53.070 or dMarc. 06:53.100 --> 06:58.620 That's a mouthful, but this email authentication protocol is designed to empower email domain owners 06:58.620 --> 07:02.520 and prevent spoofing and mitigate spam originating from their domain. 07:02.520 --> 07:07.910 This is done through a series of technology, but provides spoofing prevention DNS record. 07:08.240 --> 07:10.520 Cross examination and cross reference. 07:10.550 --> 07:15.770 It can also be manually queried to ensure that the emails are actually coming from the legitimate server 07:15.770 --> 07:17.870 in which it was supposed to originate on. 07:17.900 --> 07:23.240 This, again, is just one more message protocol that we can utilize to ensure that our emails are safe. 07:23.870 --> 07:29.960 It's not uncommon within our normal emails to see embedded links, whether it's a click here box or 07:29.990 --> 07:31.760 a direct email link. 07:31.790 --> 07:37.400 It doesn't matter what it is, but we see embedded links scouring our different emails from both legitimate 07:37.400 --> 07:40.940 users as well as malicious users in certain contexts. 07:40.970 --> 07:42.830 This isn't always a good thing. 07:42.830 --> 07:49.190 You can see on our example here where we have a legitimate, uh, link or an embedded link within our 07:49.190 --> 07:52.970 system, but it's providing an illegitimate or spoofing link. 07:52.970 --> 07:58.370 If the user were to click on it, they would end up@malware.com or a malware site. 07:58.370 --> 08:05.180 This provides an embedded link or a way for malicious users to provide a quick link for users to utilize 08:05.180 --> 08:08.840 that could potentially lead to an unwanted or unauthorized Authorized website. 08:08.840 --> 08:15.170 This is a major problem with an email today, and we should provide some policies or procedures to ensure 08:15.170 --> 08:16.910 that our users aren't clicking on them. 08:16.910 --> 08:22.160 One of the surefire ways is training, and with training, we can identify and say, hey, don't click 08:22.160 --> 08:27.290 on the links, identify where the link is taking you first, and if it doesn't add up, don't click 08:27.290 --> 08:27.680 on it. 08:27.710 --> 08:30.410 If you don't recognize the user, don't click on it. 08:30.410 --> 08:35.660 A lot of systems in place for many organizations today don't allow embedded links, and if you provide 08:35.660 --> 08:40.250 an embedded link, it tells you exactly what the link is so you don't even have to hover your mouse 08:40.250 --> 08:40.730 over it. 08:40.970 --> 08:45.590 That provides us an additional security layer within our email security protocols. 08:45.590 --> 08:48.590 Within this episode, we covered our email analysis. 08:48.620 --> 08:53.870 We also covered how to look for headers and how headers can be utilized to identify spoofing or malicious 08:53.870 --> 08:54.500 emails. 08:54.500 --> 08:59.480 We covered impersonation and how users or senders aren't always who they say they are. 08:59.480 --> 09:03.980 We've identified different frameworks and protocols that we can utilize to more safeguard our systems 09:03.980 --> 09:10.210 and security within our email program to ensure that authenticity of the email sender as well as the 09:10.240 --> 09:12.550 domains that are supposedly being sent from. 09:12.550 --> 09:17.800 We also talked about embedded links to where we can ensure that our users are only clicking on links 09:17.800 --> 09:23.290 that they know where it's going to, by ensuring that we don't allow the short fuse links in, and we 09:23.290 --> 09:27.640 only provide the long link that actually proves they're going to a safe place. 09:27.670 --> 09:32.770 We also provide training to ensure, on top of those embedded links that users aren't clicking on malicious 09:32.770 --> 09:33.580 software. 09:33.610 --> 09:37.180 Throughout this episode, we've talked about all these different things, but what I really want you 09:37.180 --> 09:42.670 to get out of this is that for Cisa plus, you need to understand the common sense protocols that come 09:42.670 --> 09:48.730 with not only embedded links, but also through domain based authentication, reporting and conformance, 09:48.730 --> 09:50.320 or that dMarc protocol. 09:50.320 --> 09:56.470 The DKIM or Domainkeys identified mail, as well as Sender Policy Framework or SPF. 09:56.500 --> 10:01.840 These protocols you should expect to see on your Cisa plus exam, make sure that you understand the 10:01.840 --> 10:05.560 acronyms associated with them and how that technology is pulled off. 10:05.560 --> 10:10.750 If you can do that, you should be good for those scenario based questions within your Cisa exam.