WEBVTT 1 00:00:00.090 --> 00:00:01.380 In this lesson, 2 00:00:01.380 --> 00:00:04.470 we will learn about email security. 3 00:00:04.470 --> 00:00:07.800 Email security protects email communications 4 00:00:07.800 --> 00:00:10.350 from threats like phishing, spoofing, 5 00:00:10.350 --> 00:00:12.870 and unauthorized access. 6 00:00:12.870 --> 00:00:17.370 Email security concepts include sender policy framework 7 00:00:17.370 --> 00:00:18.980 or SPF, 8 00:00:18.980 --> 00:00:22.980 DomainKeys identified mail, or DKIM, 9 00:00:22.980 --> 00:00:25.950 domain-based message authentication, 10 00:00:25.950 --> 00:00:29.010 reporting and conformance or DMARC, 11 00:00:29.010 --> 00:00:32.880 and secure/multipurpose internet mail extensions 12 00:00:32.880 --> 00:00:34.530 or S/MIME. 13 00:00:34.530 --> 00:00:37.470 SPF, the sender policy framework 14 00:00:37.470 --> 00:00:40.200 is an email validation protocol 15 00:00:40.200 --> 00:00:42.030 that allows domain owners 16 00:00:42.030 --> 00:00:45.540 to specify which mail servers are permitted 17 00:00:45.540 --> 00:00:48.330 to send emails on their behalf, 18 00:00:48.330 --> 00:00:50.880 preventing email spoofing. 19 00:00:50.880 --> 00:00:55.260 DKIM or DomainKeys Identified Mail 20 00:00:55.260 --> 00:00:58.350 adds a digital signature to emails, 21 00:00:58.350 --> 00:01:00.570 allowing recipients to verify 22 00:01:00.570 --> 00:01:03.300 that the message has not been altered, 23 00:01:03.300 --> 00:01:07.560 and that it truly comes from the legitimate sender. 24 00:01:07.560 --> 00:01:12.560 Next DMARC, domain-based message authentication, reporting 25 00:01:12.990 --> 00:01:14.340 and conformance, 26 00:01:14.340 --> 00:01:17.760 provides a framework for email authentication 27 00:01:17.760 --> 00:01:19.650 and policy enforcement 28 00:01:19.650 --> 00:01:22.740 to protect against email based attacks 29 00:01:22.740 --> 00:01:27.660 based on the results of SPF and DKIM checks. 30 00:01:27.660 --> 00:01:31.470 Finally, S/MIME the Secure/Multipurpose 31 00:01:31.470 --> 00:01:35.340 Internet Mail Extensions enhance email security 32 00:01:35.340 --> 00:01:37.260 by enabling encryption 33 00:01:37.260 --> 00:01:40.830 and digital signatures in email messages. 34 00:01:40.830 --> 00:01:45.830 Let's learn more about SPF, DKIM, DMARC, 35 00:01:46.140 --> 00:01:48.030 and S/MIME. 36 00:01:48.030 --> 00:01:53.030 First, we have the Sender Policy framework or SPF. 37 00:01:53.190 --> 00:01:55.260 SPF is a protocol 38 00:01:55.260 --> 00:01:57.990 that helps prevent email spoofing. 39 00:01:57.990 --> 00:02:01.650 SPF works by allowing the owner of a domain 40 00:02:01.650 --> 00:02:04.980 to specify which mail servers are authorized 41 00:02:04.980 --> 00:02:07.560 to send emails on their behalf. 42 00:02:07.560 --> 00:02:09.690 When someone receives an email, 43 00:02:09.690 --> 00:02:12.810 the receiving sender can check the SPF record 44 00:02:12.810 --> 00:02:14.640 of the sender's domain 45 00:02:14.640 --> 00:02:18.930 to verify if the email is from an authorized server. 46 00:02:18.930 --> 00:02:21.810 This way, if an unauthorized server 47 00:02:21.810 --> 00:02:26.430 tries to send an email pretending to be from that domain, 48 00:02:26.430 --> 00:02:29.430 the email can be flagged or blocked. 49 00:02:29.430 --> 00:02:31.860 Think about sender policy framework 50 00:02:31.860 --> 00:02:34.620 like a guest list at a fancy event. 51 00:02:34.620 --> 00:02:37.380 If you are hosting the fancy event, 52 00:02:37.380 --> 00:02:40.260 you create a list of people who are allowed to get 53 00:02:40.260 --> 00:02:41.820 into the event. 54 00:02:41.820 --> 00:02:44.850 If someone shows up who is not on the list, 55 00:02:44.850 --> 00:02:47.820 your security guard will not let them in. 56 00:02:47.820 --> 00:02:52.820 Similarly, SPF creates a list of approved mail servers 57 00:02:52.860 --> 00:02:55.740 that can send emails from your domain. 58 00:02:55.740 --> 00:02:59.520 If an email comes from a server that is not on the list, 59 00:02:59.520 --> 00:03:02.610 it is rejected or marked as suspicious, 60 00:03:02.610 --> 00:03:06.240 helping to prevent email spoofing attacks. 61 00:03:06.240 --> 00:03:09.450 SPF records are stored as text records 62 00:03:09.450 --> 00:03:12.630 in the domain name system or a DNS, 63 00:03:12.630 --> 00:03:14.490 and specify the domains 64 00:03:14.490 --> 00:03:16.620 and IP address ranges 65 00:03:16.620 --> 00:03:20.850 authorized to send emails on behalf of a domain. 66 00:03:20.850 --> 00:03:24.420 These records identify which mail servers 67 00:03:24.420 --> 00:03:27.480 are allowed to send emails for the domain, 68 00:03:27.480 --> 00:03:30.090 helping to prevent email spoofing. 69 00:03:30.090 --> 00:03:34.170 Each SPF record includes a policy symbol 70 00:03:34.170 --> 00:03:37.470 such as the tilde, which is a soft fail, 71 00:03:37.470 --> 00:03:40.260 or a dash, which is a hard fail. 72 00:03:40.260 --> 00:03:44.970 These indicate how strictly the policy should be enforced. 73 00:03:44.970 --> 00:03:48.990 Overall, SPF policy helps mail servers decide 74 00:03:48.990 --> 00:03:53.990 whether to flag or reject emails from unauthorized sources. 75 00:03:54.270 --> 00:03:58.350 However, SPF alone is not foolproof. 76 00:03:58.350 --> 00:04:02.760 While it can block unauthorized servers from sending emails, 77 00:04:02.760 --> 00:04:06.450 it does not prevent someone from forging the from address 78 00:04:06.450 --> 00:04:08.340 in an email header. 79 00:04:08.340 --> 00:04:11.400 This means that an email could still appear 80 00:04:11.400 --> 00:04:13.830 to come from a trusted sender 81 00:04:13.830 --> 00:04:17.430 even if the SPF check doesn't pass. 82 00:04:17.430 --> 00:04:20.820 Additionally, if a legitimate organization 83 00:04:20.820 --> 00:04:25.020 uses a third-party service to send emails on their behalf, 84 00:04:25.020 --> 00:04:27.210 such as for surveys, 85 00:04:27.210 --> 00:04:29.940 then those emails, though legitimate, 86 00:04:29.940 --> 00:04:32.610 might fail an SPF check. 87 00:04:32.610 --> 00:04:35.700 For this reason, SPF is often used 88 00:04:35.700 --> 00:04:39.630 in combination with other protocols like DKIM, 89 00:04:39.630 --> 00:04:43.770 the DomainKeys identified mail, and DMARC, 90 00:04:43.770 --> 00:04:46.860 domain-based message authentication, reporting, 91 00:04:46.860 --> 00:04:51.120 and conformance to provide stronger email security. 92 00:04:51.120 --> 00:04:55.740 Second, we have DomainKeys identified mail or DKIM. 93 00:04:56.790 --> 00:04:59.700 DKIM adds a layer of security 94 00:04:59.700 --> 00:05:04.410 by attaching a digital signature to every outgoing email. 95 00:05:04.410 --> 00:05:08.370 This signature is generated using a private key, 96 00:05:08.370 --> 00:05:12.630 which only the owner of the sending domain possesses. 97 00:05:12.630 --> 00:05:16.680 When the recipient's email server receives the email, 98 00:05:16.680 --> 00:05:19.380 it uses the domain's public key, 99 00:05:19.380 --> 00:05:22.350 which is stored in a text record in the DNS 100 00:05:22.350 --> 00:05:25.650 or domain name system of the sender's domain 101 00:05:25.650 --> 00:05:28.620 to verify that the signature matches. 102 00:05:28.620 --> 00:05:30.300 If the signature is valid, 103 00:05:30.300 --> 00:05:33.450 it confirms that the email has not been altered 104 00:05:33.450 --> 00:05:35.100 during transmission, 105 00:05:35.100 --> 00:05:39.450 and that it truly originated from the claimed sender. 106 00:05:39.450 --> 00:05:42.720 This ensures the integrity of the message 107 00:05:42.720 --> 00:05:45.570 and helps prevent email tampering. 108 00:05:45.570 --> 00:05:49.890 So you can think of DKIM as a verification 109 00:05:49.890 --> 00:05:54.890 of a fancy party guest's invitation at your fancy party. 110 00:05:55.020 --> 00:05:59.490 Someone shows up with an invitation that looks suspicious, 111 00:05:59.490 --> 00:06:02.550 you have a guest list, which is like SPF, 112 00:06:02.550 --> 00:06:06.330 and a special stamp, which is like DKIM, 113 00:06:06.330 --> 00:06:09.660 to confirm the invitation's authenticity. 114 00:06:09.660 --> 00:06:11.820 So you take out your stamp 115 00:06:11.820 --> 00:06:15.570 to check to see if it matches the one on the invitation. 116 00:06:15.570 --> 00:06:19.320 If it does, you know the guest was truly invited 117 00:06:19.320 --> 00:06:22.410 and the invitation hasn't been tampered with. 118 00:06:22.410 --> 00:06:25.320 If it doesn't match, you know something is off 119 00:06:25.320 --> 00:06:28.620 and they might not be who they claim to be. 120 00:06:28.620 --> 00:06:33.620 Similarly, DKIM ensures that an email hasn't been altered 121 00:06:33.630 --> 00:06:36.810 and that it comes from the legitimate sender. 122 00:06:36.810 --> 00:06:39.870 So if the digital signature matches, 123 00:06:39.870 --> 00:06:41.940 the email can be trusted. 124 00:06:41.940 --> 00:06:45.810 Overall, the DKIM plays an important role 125 00:06:45.810 --> 00:06:47.490 in email security 126 00:06:47.490 --> 00:06:50.940 by preventing attackers from modifying emails 127 00:06:50.940 --> 00:06:53.040 after they have been sent. 128 00:06:53.040 --> 00:06:58.040 However, like SPF, DKIM is not perfect on its own. 129 00:06:58.650 --> 00:07:01.860 While it does protect the integrity of the email, 130 00:07:01.860 --> 00:07:06.240 it does not provide a full solution to email spoofing. 131 00:07:06.240 --> 00:07:10.980 For example, while DKIM verifies that the content 132 00:07:10.980 --> 00:07:13.680 of the email has not been altered, 133 00:07:13.680 --> 00:07:16.890 it does not authenticate the from address 134 00:07:16.890 --> 00:07:18.510 in the email header. 135 00:07:18.510 --> 00:07:21.570 This means that an attacker could still forge 136 00:07:21.570 --> 00:07:24.840 the from address to make an email appear 137 00:07:24.840 --> 00:07:27.750 as though it is coming from a trusted sender, 138 00:07:27.750 --> 00:07:31.560 even if the DKIM signature is invalid. 139 00:07:31.560 --> 00:07:35.190 This is why DKIM is often combined 140 00:07:35.190 --> 00:07:38.490 with domain-based message authentication, reporting 141 00:07:38.490 --> 00:07:40.800 and conformance, or DMARC. 142 00:07:40.800 --> 00:07:43.651 DMARC ensures that both SPF 143 00:07:43.651 --> 00:07:47.340 and DKIM align with the from address, 144 00:07:47.340 --> 00:07:48.750 allowing domain owners 145 00:07:48.750 --> 00:07:51.780 to specify how emails should be handled 146 00:07:51.780 --> 00:07:54.300 when authentication checks fail. 147 00:07:54.300 --> 00:07:57.600 This combination provides a stronger defense 148 00:07:57.600 --> 00:08:01.620 against emails spoofing by verifying both the sender 149 00:08:01.620 --> 00:08:04.470 and the integrity of the message. 150 00:08:04.470 --> 00:08:08.430 Third, we have domain-based message authentication, 151 00:08:08.430 --> 00:08:11.850 reporting and conformance, or DMARC. 152 00:08:11.850 --> 00:08:15.390 DMARC builds on SPF and DKIM 153 00:08:15.390 --> 00:08:18.420 to provide a more comprehensive framework 154 00:08:18.420 --> 00:08:20.700 for email authentication. 155 00:08:20.700 --> 00:08:24.360 It allows domain owners to publish a policy 156 00:08:24.360 --> 00:08:26.850 that tells receiving mail servers 157 00:08:26.850 --> 00:08:31.850 what to do if an email fails SPF or DKIM checks. 158 00:08:32.880 --> 00:08:36.960 For example, the policy could instruct a mail server 159 00:08:36.960 --> 00:08:39.750 to reject the email, quarantine it, 160 00:08:39.750 --> 00:08:42.750 or simply flag it as suspicious. 161 00:08:42.750 --> 00:08:45.420 Think of DMARC as setting the rules 162 00:08:45.420 --> 00:08:48.780 for handling guests at your fancy party. 163 00:08:48.780 --> 00:08:51.930 If a guest shows up who isn't on the list, 164 00:08:51.930 --> 00:08:54.270 which is like failing SPF, 165 00:08:54.270 --> 00:08:56.910 or whose invitation is suspicious, 166 00:08:56.910 --> 00:08:59.640 which is like failing DKIM, 167 00:08:59.640 --> 00:09:02.160 then DMARC tells your security guard 168 00:09:02.160 --> 00:09:04.380 how to handle the situation. 169 00:09:04.380 --> 00:09:07.740 Should the guest be turned away, asked to wait outside 170 00:09:07.740 --> 00:09:10.020 or let in with caution. 171 00:09:10.020 --> 00:09:12.270 This policy-driven approach 172 00:09:12.270 --> 00:09:15.960 helps ensure that only legitimate emails are delivered 173 00:09:15.960 --> 00:09:18.270 and fraudulent ones are dealt with 174 00:09:18.270 --> 00:09:22.200 according to the rules set by the domain owner. 175 00:09:22.200 --> 00:09:25.530 DMARC also provides reporting features, 176 00:09:25.530 --> 00:09:28.620 which allow domain owners to receive feedback 177 00:09:28.620 --> 00:09:31.320 about how their emails are being handled 178 00:09:31.320 --> 00:09:33.240 by receiving servers. 179 00:09:33.240 --> 00:09:35.730 This reporting helps identify 180 00:09:35.730 --> 00:09:38.340 potential email spoofing attempts 181 00:09:38.340 --> 00:09:42.210 and allows administrators to fine tune their policies 182 00:09:42.210 --> 00:09:44.910 to improve email security. 183 00:09:44.910 --> 00:09:49.320 By using DMARC, organizations can take proactive steps 184 00:09:49.320 --> 00:09:52.950 to protect their domain from being used in phishing 185 00:09:52.950 --> 00:09:54.930 or spoofing attacks, 186 00:09:54.930 --> 00:09:59.880 helping to maintain trust with their users and customers. 187 00:09:59.880 --> 00:10:01.740 Fourth and last, 188 00:10:01.740 --> 00:10:06.420 we have secure/multipurpose internet mail extensions 189 00:10:06.420 --> 00:10:08.130 or S/MIME. 190 00:10:08.130 --> 00:10:13.020 S/MIME is a standard that allows non-text based emails, 191 00:10:13.020 --> 00:10:16.170 such as those containing graphics, videos, 192 00:10:16.170 --> 00:10:20.490 or emojis to be sent securely over the internet. 193 00:10:20.490 --> 00:10:24.600 So when we send emails with these elements, graphics, 194 00:10:24.600 --> 00:10:26.220 videos, or emojis, 195 00:10:26.220 --> 00:10:30.870 we use multipurpose internet mail extensions or MIME. 196 00:10:30.870 --> 00:10:32.130 When we want to encrypt 197 00:10:32.130 --> 00:10:35.100 or digitally sign these emails for security, 198 00:10:35.100 --> 00:10:39.210 we use secure/multipurpose internet mail extensions 199 00:10:39.210 --> 00:10:40.770 or S/MIME. 200 00:10:40.770 --> 00:10:45.030 S/MIME relies on public key cryptography standards 201 00:10:45.030 --> 00:10:49.740 to provide confidentiality, integrity, authentication, 202 00:10:49.740 --> 00:10:54.390 and non-repudiation during an email transfer. 203 00:10:54.390 --> 00:10:57.510 Protocols like secure socket layer 204 00:10:57.510 --> 00:10:59.850 and transport layer security 205 00:10:59.850 --> 00:11:03.030 do an excellent job of securing the connection 206 00:11:03.030 --> 00:11:05.550 between a client and a server, 207 00:11:05.550 --> 00:11:09.360 but they do not protect individual messages. 208 00:11:09.360 --> 00:11:12.120 So once the connection is closed, 209 00:11:12.120 --> 00:11:14.940 the messages are no longer secure. 210 00:11:14.940 --> 00:11:17.400 This is where S/MIME comes in, 211 00:11:17.400 --> 00:11:21.570 because it applies security measures such as encryption 212 00:11:21.570 --> 00:11:25.530 and digital signatures to individual emails, 213 00:11:25.530 --> 00:11:28.680 ensuring protection at the message level. 214 00:11:28.680 --> 00:11:32.970 S/MIME is widely supported by most email clients, 215 00:11:32.970 --> 00:11:37.740 including Microsoft Outlook, Apple Mail, and Gmail. 216 00:11:37.740 --> 00:11:41.760 It secures emails by creating a unique session key 217 00:11:41.760 --> 00:11:44.850 for every message sent or received. 218 00:11:44.850 --> 00:11:49.350 So, if you and I wanted to exchange encrypted emails, 219 00:11:49.350 --> 00:11:52.680 we would begin by exchanging public keys. 220 00:11:52.680 --> 00:11:55.350 To do this, you would send me an email 221 00:11:55.350 --> 00:11:57.030 that includes your public key 222 00:11:57.030 --> 00:12:00.330 and sign the message with your private key 223 00:12:00.330 --> 00:12:02.460 to confirm its integrity. 224 00:12:02.460 --> 00:12:04.170 When I receive your email, 225 00:12:04.170 --> 00:12:07.290 my email client would check your public key 226 00:12:07.290 --> 00:12:09.120 with a certificate authority 227 00:12:09.120 --> 00:12:11.790 to verify that it is legitimate. 228 00:12:11.790 --> 00:12:14.640 I would also validate your signature 229 00:12:14.640 --> 00:12:17.280 using the public key you sent me 230 00:12:17.280 --> 00:12:20.970 to confirm that the email truly came from you. 231 00:12:20.970 --> 00:12:25.140 Next, I would reply to your email with my public key 232 00:12:25.140 --> 00:12:28.200 and sign my message with my private key, 233 00:12:28.200 --> 00:12:32.760 allowing you to verify the authenticity of my message 234 00:12:32.760 --> 00:12:35.340 just like I verified yours. 235 00:12:35.340 --> 00:12:39.090 Once our public keys are exchanged and validated, 236 00:12:39.090 --> 00:12:42.630 we can securely exchange confidential emails, 237 00:12:42.630 --> 00:12:45.630 but instead of encrypting the entire email 238 00:12:45.630 --> 00:12:47.310 with your public key, 239 00:12:47.310 --> 00:12:51.240 my email client will generate a unique session key 240 00:12:51.240 --> 00:12:53.610 for that specific message. 241 00:12:53.610 --> 00:12:57.930 This session key is used to encrypt the email content 242 00:12:57.930 --> 00:13:00.630 because symmetric session keys 243 00:13:00.630 --> 00:13:03.960 are faster for encrypting bulk data. 244 00:13:03.960 --> 00:13:08.190 So, I would encrypt the session key with your public key 245 00:13:08.190 --> 00:13:10.710 and send both the encrypted message 246 00:13:10.710 --> 00:13:13.740 and the encrypted session key to you. 247 00:13:13.740 --> 00:13:15.540 When you receive the email, 248 00:13:15.540 --> 00:13:19.110 your email client will use your private key 249 00:13:19.110 --> 00:13:21.480 to decrypt the session key. 250 00:13:21.480 --> 00:13:23.520 When the session key is decrypted, 251 00:13:23.520 --> 00:13:27.600 you can then decrypt the message content that I sent. 252 00:13:27.600 --> 00:13:29.700 Now, by signing each method 253 00:13:29.700 --> 00:13:32.550 with our respective private keys, 254 00:13:32.550 --> 00:13:36.510 we ensure that email maintains confidentiality, 255 00:13:36.510 --> 00:13:38.970 integrity, authentication, 256 00:13:38.970 --> 00:13:43.680 and non-repudiation throughout our entire communication. 257 00:13:43.680 --> 00:13:46.950 While S/MIME provides excellent security, 258 00:13:46.950 --> 00:13:49.620 it has a potential drawback. 259 00:13:49.620 --> 00:13:52.740 For example, attackers could use S/MIME 260 00:13:52.740 --> 00:13:55.590 as part of a social engineering attack 261 00:13:55.590 --> 00:13:58.740 by sending encrypted malware in an email. 262 00:13:58.740 --> 00:14:01.530 Since S/MIME encrypts the entire email, 263 00:14:01.530 --> 00:14:03.420 including its contents, 264 00:14:03.420 --> 00:14:05.700 the malware could go undetected 265 00:14:05.700 --> 00:14:09.990 through boundary protection devices or email filters, 266 00:14:09.990 --> 00:14:12.000 since they may not be configured 267 00:14:12.000 --> 00:14:15.000 to decrypt and inspect email. 268 00:14:15.000 --> 00:14:17.310 This is because without access 269 00:14:17.310 --> 00:14:19.500 to the recipient's private key, 270 00:14:19.500 --> 00:14:22.890 security devices cannot inspect, detect, 271 00:14:22.890 --> 00:14:25.080 or block malicious content. 272 00:14:25.080 --> 00:14:27.510 Therefore, when using S/MIME, 273 00:14:27.510 --> 00:14:30.270 especially for external communications, 274 00:14:30.270 --> 00:14:33.390 it's important to weigh the benefits of encryption 275 00:14:33.390 --> 00:14:35.550 against potential risks. 276 00:14:35.550 --> 00:14:40.550 So remember, email security protects communications 277 00:14:40.590 --> 00:14:43.380 from threats like phishing, spoofing, 278 00:14:43.380 --> 00:14:45.780 and unauthorized access. 279 00:14:45.780 --> 00:14:48.240 Key email security concepts 280 00:14:48.240 --> 00:14:52.347 include sender policy framework or SPF, 281 00:14:52.347 --> 00:14:56.100 DomainKeys identified mail or DKIM, 282 00:14:56.100 --> 00:14:59.070 domain-based message authentication, reporting, 283 00:14:59.070 --> 00:15:01.410 and conformance or DMARC, 284 00:15:01.410 --> 00:15:05.340 and secure/multipurpose internet mail extensions 285 00:15:05.340 --> 00:15:06.750 or S/MIME. 286 00:15:06.750 --> 00:15:11.700 SPF helps prevent email spoofing by allowing domain owners 287 00:15:11.700 --> 00:15:15.390 to specify which mail servers can send emails 288 00:15:15.390 --> 00:15:17.070 on their behalf. 289 00:15:17.070 --> 00:15:20.070 DKIM adds a digital signature 290 00:15:20.070 --> 00:15:22.710 to verify the email's integrity, 291 00:15:22.710 --> 00:15:26.880 and to prove that it truly comes from the claimed sender. 292 00:15:26.880 --> 00:15:30.330 Next, DMARC provides an overall framework 293 00:15:30.330 --> 00:15:32.940 for enforcing email authentication 294 00:15:32.940 --> 00:15:35.220 and handling fraudulent emails 295 00:15:35.220 --> 00:15:38.850 based on SPF and DKIM results. 296 00:15:38.850 --> 00:15:42.000 And finally, S/MIME provides encryption 297 00:15:42.000 --> 00:15:46.170 and digital signatures to ensure the confidentiality 298 00:15:46.170 --> 00:15:49.860 and integrity of individual email messages, 299 00:15:49.860 --> 00:15:53.880 making sure that only the intended recipient 300 00:15:53.880 --> 00:15:56.700 can read the content of an email, 301 00:15:56.700 --> 00:15:59.943 and that the email has not been altered.