Effective email management is an important aspect of productivity and workflow organization. Email management tools help you efficiently manage incoming and outgoing messages, organize your mailboxes, and ensure effective communication. With these tools, you can quickly view, sort, and reply to messages, set filters to automatically sort incoming messages, schedule and remind yourself of tasks, and quickly find the messages you need using the search function. You’ll also be able to set up different mailboxes to separate work and personal mail, helping you stay organized and find the messages you need more easily.
Email management tools improve your productivity, help you avoid losing important information, ensure efficient organization, and facilitate better communication with colleagues and clients. Regardless of the volume of your email, email management tools can help you be more organized and productive in your day-to-day work. Until now, we have conducted phishing attacks and taught users how to spot them. We also talked about how to respond when people fall victim to social engineering despite our training. This section discusses the implementation of technical means of e-mail management, which will help ensure the information security of the organization and remove part of this burden from the user. In addition, we will discuss email programs and services that can filter and manage email. But before we go to them, let’s look at the current standards related to the technical side of email management.
E-mail has evolved along with its security technologies. As these technologies developed, so did attack schemes, turning, like everything else in the field of information security, into a continuous battle of shield and sword. Over time, security experts have proposed, discussed, and approved many standards. When it comes to email security, there are three main standards to remember: Domain Keys Identified Mail (DKIM), Sender Policy Framework (SPF), and Domain-Based Message Authentication, Reporting, and Correspondence (DMARC). We will talk about each of them in this section.
What do these three standards do? A common misconception is that they protect your emails from incoming phishing or spoofing attempts. To some extent they do, but it’s more accurate to describe them as protecting your reputation: if you send email according to these standards, and recipient domains are configured to check related records, they can detect attempts to spoof your domain. Although this may seem illogical and useless from a social engineering perspective, read the rest of this chapter to see how it can help you.
In short, SPF verifies that the host or IP address is in the sender’s list, DKIM sends a digital signature, and DMARC implements both SPF and DKIM in addition to host verification. DMARC also provides reports and notifications. SPF is considered the simplest of security standards. An important point is that the recipient’s mail servers must be configured to check whether the message meets the standards specified when it was sent, and take certain actions based on the results of the check.
To understand how these standards work, you need to understand the different types of fields that indicate the sender of an email. In addition to the “Reply” field, e-mail messages contain “From” and “Mail_From” fields. The From field, also called 5322.From, displays the sender. MailFrom field or 5321. MailFrom is the actual email service that sent the email. For example, if I send emails using MailChimp, my personal email address will be in the 5322.From field, and MailChimp’s server and address will be in the 5321.MailFrom field.
The numbers attached to these fields are taken from the descriptions of the standard in which they were defined. Now let’s take a look at these three standards in chronological order, starting with DKIM.
DKIM became an Internet standard in 2011. It is designed to authenticate emails and prevent spoofing, and requires senders to cryptographically sign parts of the email, including the 5322.From field. Because an attacker likely won’t have access to the private key used to digitally sign the field, email recipients can quickly detect spoofing attempts.
DKIM Header – A special field added to an email message that indicates where to obtain the public key for signature verification. The public key is stored in a DNS TXT record using the DNS domain (d=) and selector (s=) tags found in the email. The DKIM public key is the only part of the infrastructure that the general public can see, but finding it depends on the selector’s knowledge, which you only know if you received an email from a real domain (or managed to crack it).
The DKIM process is as follows. First, you create an email. When you send an email, the private key associated with your DKIM record creates two digital signatures to verify the authenticity of the email. One signature is for the DKIM header itself, and the other is for the body of the email. Each email has a unique pair of signatures. Signatures are put in a cap and sent together with the letter. Upon receipt (if DKIM is configured on the recipient’s mail server), the server authenticates the message using the public key published in the DNS records. If the key can successfully decrypt the email, it means that the email is authentic and has not been spoofed.
At the same time, DKIM is rarely used for authentication. Instead, we primarily use it for authentication and for so-called DMARC hosting, which is discussed in the “Domain-Based Authentication, Reporting, and Message Matching” section later in this section. One of the disadvantages of DKIM is that it is only effective if it is implemented by both the sender and receiver.
Also, even if your organization implements DKIM internally, it can only protect your users from external actors trying to impersonate other internal employees, which is good for your reputation but otherwise does little to ensure security. After all, attackers can spoof a trusted third party. But as mentioned earlier, the recipient must configure their mail servers to check DKIM authentication, which is usually achieved by implementing DMARC. In the absence of DMARC, emails with an authentication error are still delivered to the recipient.
DKIM was first introduced in RFC 6376. Later, RFC 8301 added the following specification for the type of encryption that DKIM can use:
Currently, this specification defines two algorithms: rsa-sha1 and rsa-sha256. Signers MUST use rsa-sha256. Verifiers MUST be able to verify a signature using rsa-sha256. The rsa-sha1 encryption MUST NOT be used for signing or verification.
Another RFC on DKIM was issued in 2018. RFC 8463 adds a new signature algorithm, ed25519, which uses SHA-256 and the Edwardscurve Digital Signature Algorithm (EdDSA) instead of an RSA key.
For DKIM to work effectively, it must be configured not only on the DNS server, but also on the mail server. Otherwise, it will act only as a deterrent. Let’s take a look at how to set up DKIM on a domain hosted through Google Workspace. Other mail servers have similar features.
Regular Gmail uses Google’s DKIM keys by default, as do domains hosted in Workspace that don’t have DKIM configured. You can’t set up custom DKIM for a Gmail account hosted at gmail.com, but you can for a domain using Workspace. According to Google’s support instructions, if the user does not configure their own DKIM public key, Google will use the following key by default: d=*.gappssmtp.com.
Let’s set up our own private key. First, log in to the workspace administrator console as a super administrator. Once logged in to the console, click Authenticate Email as shown in Fig. 11.1.
You will now see the DKIM authentication option and you will be prompted to select a domain to configure DKIM support for (Figure 11.2).
After clicking the Create New Record button, you need to select the length of the key and the selector (Figure 11.3). Please note that some hosting providers and DNS platforms do not support a key length of 2048 bits. According to Google’s instructions, if this is the case, revert to the default 1024-bit keys.
Now select the desired domain and click on Create New Record button. A new key (hidden in Figure 11.4) will be generated. Open a new window to copy and paste the key into DNS. After that, click the Start authentication button.
After this step, log into cPanel, a common domain management tool used by many hosting providers. cPanel should have a DNS zone editor with a field that allows you to enter a public key in a TXT record (Figure 11.5).
Note that DNS record management panels may limit you to 255 characters: too few for the industry standard recommended 2048-bit key. (When this happened to me, I contacted customer support and asked them to manually enter the information on my behalf, which they reluctantly did.)
After the key is saved, it can take up to 48 hours for the record to propagate to DNS hosts. You will need to click the Start Authentication button on the toolbar to confirm once the distribution is complete. Recording a distribution can sometimes take up to 72 hours, depending on infrastructure and provider.
Here’s another important consideration, discussed in the next section: Make sure your hosting and DNS provider support composite DNS records before using anything above a 1024-bit RSA key. In fact, some ISPs impose a limit on the number of characters that can be entered in a single DNS record. Your DMARC implementation will suffer an alignment error if the provider does not support record concatenation (concatenation) because DNS will interpret it as two unrelated TXT records and will not be able to do its job.
To set up DKIM in other email providers such as Exchange, Office 365, and Sendmail, you can find links to several guides at http://email-security.seosint.xyz/.
The encryption used in DKIM has had vulnerabilities for some time. Until 2018, DKIM allowed the use of the SHA-1 algorithm for signing and verification. However, computer security experts have known that SHA-1 has been insecure since 2010, even before the DKIM standard was created. Researchers at CWI Amsterdam and Google have since successfully launched a so-called collision attack on the protocol, after which most cryptography and security experts rejected it. A collision attack allows parties to take the hashes of two mismatched files and create the same hash from them, giving the impression that they match. All major web browser vendors have announced that they will end support for SHA-1 certificates in 2017.
In fact, creating a collision in the right place during DKIM operations still requires a lot of computing power, so only large and well-funded organizations, such as national intelligence agencies or large technology companies, have the technical ability to carry out such an attack. After all, Google was one of two organizations that managed to stage a SHA-1 collision (and it’s unlikely that Google will try to send fake emails to your organization). But if you have the authority to do so, use the more secure SHA-256.
Second, there are vulnerabilities in RSA, which is used as DKIM’s public key infrastructure. As I mentioned earlier, Google’s DKIM tool supports two RSAs: 1024-bit and 2048-bit. The second option for RSA is the current minimum industry standard. There is considerable debate over whether RSA is secure, given the mathematical, computational, and cryptographic advances since RSA’s inception. Several scientists and researchers have claimed that they can break RSA or weaken the RSA cryptosystem. Weakening a cryptosystem is a method of reducing its strength by identifying the large prime numbers used and factoring.
Using 1024-bit RSA is definitely an officially identified vulnerability, while using 2048-bit RSA is not recommended, but not prohibited. From a practical standpoint, without massive computing resources or access to quantum computing tools, neither 1024-bit nor 2048-bit RSA can be broken in less than two million years on a single computing system. Later versions of DKIM added support for the Ed25519-SHA256 algorithm, although it was not widely adopted.
The final weakness in DKIM is not a vulnerability, but a flaw. DKIM is well implemented and can protect an organization’s reputation, but only if the recipient’s email server is configured to verify the DKIM signature and take action on emails purporting to be sent from a DKIM-enabled domain; Otherwise, your organization’s reputation can still be damaged.
Like DKIM, the Sender Policy Framework (SPF) aims to prevent spoofing using DNS TXT records. In these records, SPF identifies domains, lists of hosts, domains and IP addresses, and IP addresses that are allowed to send email from or on behalf of the domain.
Although some sources describe SPF as sender authentication, it is more appropriate to call it data verification; If the infrastructure is configured, the recipient will check the sender information from fields 5322 and 5321 to authorize the senders as defined in the SPF record.
To understand how this works, imagine someone spoofing an email from a domain. The recipient checks the SPF record and notices that the sender’s domain is set to “strict verification” and the sender is not trusted. At the same time, the recipient has an SPF verification policy configured. In this case, the letter will not reach the addressee. If there was no SPF record, if the domain had the soft check option set, or if the SPF check policy was disabled, the email would be delivered to the intended recipient.
Because SPF does not require cryptography, SPF and DKIM are complementary rather than competing. SPF is logic based as it compares the input values against its list. Host, domain or iPad recorded or not. DKIM uses both logic and cryptography in the form of digital signatures. You can read more about SPF in RFC 7208 from 2014.
Let’s implement SPF in Google Workspace. First, identify any service providers, such as Google or Outlook, and the associated domains that are allowed to send email on behalf of your organization. (These domains can be specified in the MX record.) If using an internal mail server, such as Exchange, also define ranges of addresses where e-mail can be sent on behalf of the organization.
Then, for those domains and IP addresses, choose a policy for different situations.
Pass (+): Allows all email to pass (not recommended except for short-term troubleshooting).
No policy (?), neutral: Actually, means no policy.
Soft fail (~): Something in between a hard check and a neutral policy; usually these emails are accepted but marked as suspicious.
Hard fail (–): Rejects the email.
As backups you can set something like +all (not recommended as this will allow all mail), +mx (will allow email from the host specified in the MX record; not recommended if using cloud email such as Google or Office 365) or +nostarch.com (which will allow you to receive emails from nostarch.com).
With this information, you can create a record. To get started, go to the DNS record editor in your hosting provider’s control panel and create a new TXT record. Alternatively, you can edit existing TXT records that have v=spf1 in their body as shown below:
dig walmart.com txt ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> walmart.com txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6907 ;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ; walmart.com. IN TXT ;; ANSWER SECTION: walmart.com. 300 IN TXT "v=spf1 include:_netblocks.walmart.com include:_smartcomm.walmart.com include:_vspf1.walmart.com include:_vspf2.walmart.com include:_vspf3.walmart.com ip4:161.170.248.0/24 ip4:161.170.244.0/24 ip4:161.170.241.16/30 ip4:161.170.245.0/24 ip4:161.170.249.0/24" " ~all" --сокращено-- ;; Query time: 127 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Tue Sep 08 05:42:49 UTC 2020 ;; MSG SIZE rcvd: 1502
Set the packet time-to-live (TTL) value to the default value of 14400. The TTL value is the amount of time that recursive DNS resolvers have to cache our SPF record before retrieving a new record (if it has changed). Some critical resources and load balancers perform best with a very small TTL value. It is recommended to assign higher TTL values to resources that do not require frequent changes or have built-in redundancy (such as MX records). This is done to combat techniques such as fast-flowing or dynamic DNS records, which are commonly used in sophisticated phishing campaigns and attacks on social networking sites.
Then name the TXT record with your organization’s domain name. In the body text type v=spf1 followed by mechanisms and rules as mentioned earlier. To identify these mechanisms, you need to know the five types of allowed fields:
ip4: IPv4 address or CIDR range; ip6: IPv6 address; mx: Sender’s MX record in DNS. a: host address record in DNS; include: a link to another domain’s policy.
Now create a DNS login string. Let’s say you allow hosts to use the nostarch.com MX record in addition to MailChimp and a private, unrouted, hard-to-verify IP range.
The text for the DNS record will look like this:
v=spf1 +mx include:192.168.1.22 include:192.168.2.0/24 include:servers.mcsv.net -all
You can also make this entry in an alternative way. In Chapter 4, you learned that No Starch uses Google Workspace, so you can replace the +mx part with Google servers (found in the Workspace dashboard). To fit this on one line, remove the include for MailChimp SPF.
An alternate entry would look like this:
v=spf1 include:_spf.google.com include:192.168.1.22 include:192.168.2.0/24 -all
After inserting this line into the DNS record, wait up to 72 hours for it to propagate to all hosts. Different DNS servers on the Internet take different times to copy the updated information. This time depends heavily on the TTL setting, which tells servers to cache information for a few seconds before updating. In my experience, SPF can start working almost immediately, unlike DKIM. Whether you use Google as your email provider or not, you can still use the Google Admin Toolbox’s MX Checker site to verify the information provided by the sender. The toolkit can be found at https://toolbox.googleapps.com/ apps/checkmx/. Instructions for setting up SPF on other platforms can be found here: http://email-security.seosint.xyz/.
In Chapter 4, I mentioned that SPF allows attackers to enumerate the domains, IP addresses, and IP ranges that an organization owns or uses. Attackers can also determine whether a target has a hard or soft policy by checking –all, ~all, or ~? (neutral) in the corresponding part of the TXT record. This information can influence their decision on whether to spoof your organization’s domain or perhaps use something else. A social engineer with an eye for detail can even configure DKIM and SPF on their phishing domain to bypass any checks an organization might have if they apply any policies.
SPF can also alert attackers to your working relationships with other organizations. If other domains need authority to send email on your behalf, you may need to create SPF records for them. Examples of domains that require permission to send emails on behalf of the organization are mailing lists such as MailChimp, Mailgun, or Constant Contact. Also consider other providers that send emails on behalf of the organization, such as GoToMeeting or similar collaboration platforms.
The final aspect of SPF is not a vulnerability, but a flaw. Like DKIM, SPF is easy to implement and can protect an organization’s reputation, but only if the recipient’s email server is configured to check SPF records and adhere to certain policies. However, not complying with this requirement can damage your organization’s reputation.
DMARC takes existing SPF and DKIM implementations and leverages them to create a more robust solution to prevent spoofing, corporate email compromise, and reputational damage. First introduced as an Internet standard in 2015 (RFC 7489), it aims to overcome the shortcomings of both SPF and DKIM: it implements both previous standards, but also reports the successes and failures of the sender’s domain. DMARC verifies the location of the email sender, meaning that the 5322.From field matches authenticated domain names. In other words, it verifies that an email with a “From” field purporting to be sent from [email protected] is actually sent from that domain. A spoofed email can pass SPF and DKIM, but will fail when verifying the sender’s location.
This is what happens when DMARC is used to deliver a message. First, the user writes an email. The sending mail server inserts a DKIM header into it and then sends it to the recipient. Next, for an email to pass through an organization with a DMARC policy, two things must happen. First, the e-mail must pass DKIM signature verification (5322.From field, with verification using the public key contained in DNS). Second, it must pass verification of SPF (5322.From) and TXT records. Depending on the results of these checks, the DMARC entry will indicate whether the server should accept or reject the email. All malfunctions are recorded for the report. The email then goes through any processes or filters set by the recipient and, if successful, lands in the recipient’s inbox.
The DMARC protocol has become widespread. For example, in the USA, all federal agencies and government organizations are required to use it. This protocol was implemented especially actively in 2017. In addition to using this protocol, the recipient must independently verify records and apply its own internal policies.
Updates to DMARC are presented in two RFCs: RFC 8553, which introduced underscores in hostnames; and RFC 8616, which addresses the use of ASCII characters in non-international SPF, DKIM, and DMARC characters.
SPF and DKIM should be configured before applying DMARC. Then you need to prepare the information for the TXT record. You can find the full record format defined in section 6.3 of RFC 7489, but you’ll need at least the following:
DMARC version (v): The version of DMARC in use. It is currently 1, then indicates v=DMARC1;
Policy (p): the policy applied to this domain;
Subdomain Policy (sp): A policy that applies only to subdomains of the sending domain, such as emails from [email protected] but not from [email protected]. In the absence of an sp field or a qualifier, the organization will use the main p field;
Percentage of “bad emails” to which the policy is applied (pct): A number between 0 and 100 that specifies the percentage of emails from the domain owner to which the policy is applied; rua flag: The email address to which the reports are sent. OSINT compilers can learn about this address and use it as a weapon, so using an alias is recommended.
All fields in a DMARC record, except version, must contain qualifiers. For example, the policy field is set to none, quarantine, or reject. The noone pointer does nothing, while the quarantine redirects the email to the spam folder or administrators for inspection and rejects Rejects the email.
You can also add security analysis options and an address to forward analysis results reports. The security-based failures (fo) tag specifies which events will generate a report. It has four parameters: 0 generates a crash report if all protection mechanisms have worked; 1 forms a report on the emergency termination of work, if individual mechanisms have worked; d generates a DKIM error report in case of DKIM failure regardless of domain location; and s generates an SPF error report in the event of an SPF failure regardless of the location of the domain. The ruf tag specifies the email address to which reports are sent. OSINT collectors can read it like a rua tag and use it as a weapon, so use aliases.
Two additional fields, adkim and aspf, determine whether the owner needs a mode that specifies what action to take if the email fails SPF or DKIM. Both have possible values of r for soft and s for strict compliance. A soft match requires an exact match for the domain only, while a hard match requires a complete exact match. Both values are optional and default Set the soft check mode.
So we need to specify a lot of different information. Let’s set up a DMARC record for nostarch.com:
v=DMARC1; p=quarantine;pct=95; rua=mailto:[email protected]; fo=1; ruf=mailto:soc@ nostarch.com;
This entry contains the quarantine policy for the domain only. This applies to 95% of emails and any failure results in a security analysis and reports are sent to [email protected]. For general DMARC reports, [email protected] is the designated address.
After creating the string record, you need to add it to the TXT record in the nostarch.com DNS zone file with the name dmarc and TTL 14400.
Other than exposing the same information as SPF, and the fact that recipients of your email may not verify SPF or DKIM, DMARC itself does not pose any significant problems or vulnerabilities.
However, simply creating DNS TXT records for DMARC does not provide immediate protection. For example, it can be easy to make mistakes when configuring a DMARC implementation. When setting up DMARC for the first time, avoid rejecting emails, as this prevents people from validating emails and can lead to interruptions or misdirected messages.
You can mitigate these effects by setting the initial DMARC policy to “none” and scanning 100% of emails (p = none; pct = 100;). Over time, carefully reduce the value of the PCT field until you reach a combination of reporting and performance that you are comfortable with. Once you’ve reached a good level, change the feedback percentage to an acceptable but realistic value. For businesses, I recommend checking between 60 and 85%, depending on your resources. Then update the DMARC TXT record to reflect this change, eg p = quarantine; PCT=75;.
Be aware that attackers using email to gain access to your organization’s secrets may use tools to increase their legitimacy, so don’t rely solely on SPF, DKIM, and DMARC. For example, if an actor hacks another organization with SPF, DKIM, and DMARC configured, and then sends an email to your organization through legitimate channels, it will pass all checks related to these three standards.
Another threat vector not covered by DMARC is encryption. These three standards do not provide a means of encrypting e-mail. Of course, DKIM uses cryptography, but only for signing emails. The following sections describe how to fill this gap.
Originally developed mail protocols SMTP, POP and IMAP did not include encryption. As attacks evolved, mail protocol developers created a Transport Layer Security (TLS) mechanism to encrypt messages. It can sometimes be recognized by the name STARTTLS after the command used to start the service.
This is how STARTTLS works. First, the sending server connects to the receiving server as usual. It then requests an exchange via the enhanced SMTP protocol, which allows images and attachments to be transferred. Next, the sender asks the receiving server if it supports STARTTLS. If the answer is positive, the connection is restarted and the e-mail is encrypted using a version of the SSL or TLS protocol agreed upon by both hosts. If the answer is negative, the email is sent unencrypted. Another option, called Forced TLS, prevents email from being sent if the connection is not secure. The use of forced TLS is not widely used due to mail blocking if encryption cannot be negotiated.
The biggest problem with STARTTLS is that it is an opportunistic protocol, meaning it only uses encryption when it is available. If encryption is not available or supported, the message will be sent in the clear. Another problem with STARTTLS is that the encryption “handshake” (key exchange) itself occurs in plaintext, allowing potential attackers to steal session information or modify messages using man-in-the-middle attacks. You can see both of these problems exploited in STRIPTLS attacks, where the attacker either disables the actual STARTTLS command or simulates a situation where TLS is not available. By configuring SMTP to require TLS for outbound connections, you can reduce the STRIPTLS threat, but you may lose outbound email services if TLS is not configured properly or the recipient has not configured to receive TLS emails or blocked the port.
Another way to mitigate the STRIPTLS threat is with an optional Domain Name System Security Extensions (DNSSEC) feature called DNS-Based Authentication of Named Entities (DANE). A DANE implementation requires organizations to create a DNS record that routes all connections through a specific port or protocol to negotiate a session using a public key hosted in DNS. This information can also be misused or collected as part of an OSINT effort, just like anything else in public DNS records, because an attacker can query DNS records and draw conclusions from the records. While DANE is pretty easy to implement, the same can’t be said for DNSSEC in general, so I don’t see it becoming widespread.
Around the same time that DANE was being developed, another solution to the same problem (STRIPTLS attacks) was proposed: the SMTP protocol MTA Strict Transport Security (MTA-STS).
MTA-STS is another way to implement TLS to protect email messages. In this method, both parties negotiate a TLS handshake using DNS TXT records and files uploaded to specific directories in a predefined public subdomain of the sending domain.
This standard applies only to SMTP traffic between mail servers. Communication between the client and the server is carried out using the HTTP Strict Transport Security (HSTS) protocol. Due to the complexity of implementing MTA-STS, I will not describe this process here. You can find links to tutorials at http://email-security.seosint.xyz/.
SMTP TLS Reporting (TLS-RPT) is a method of collecting statistics about potential failures in TLS negotiation and related areas. This is roughly the same as DMARC if the MTA-STS were a DKIM element. Collected information can be used for troubleshooting or threat analysis.
Setting up TLS-RPT is relatively easy as it only requires a TXT DNS record with _smtp._tls.domain.tld and the report address in the text. If an error occurs in an email that uses an encrypted method (DANE or MTASTS), a notification will be sent to the reporting address. Here’s an example for nostarch.com:
smtp._tls.nostarch.com 300 «v=TLSRPTv1;rua=mailto:[email protected]»
The top line is the field name and TTL. The second line is the value. Here we set the TTL to 300 and send the report to [email protected].
The final step in e-mail security is the use of filtering technologies. This usually means hiring an intermediary or service provider to get your emails to you. The reseller will scan them for signs of malicious mail, which it observes on all clients, and check for SPF, DKIM, and DMARC if configured. Email filtering isn’t perfect, but it takes most of the burden off the technical staff. However, be aware that hiring a vendor will likely require changes to your public DNS records, and an attacker could discover these connections using OSINT techniques, as discussed earlier.
There are many configurations and applications for intermediate filtering. When choosing a service provider, consider their email bandwidth per minute or per second. Also decide whether you need to support email filtering through software, hardware, or a cloud service. Each option has unique challenges, especially in terms of implementation, support, availability, and reporting, and each offers different features. Email filtering is easier to apply in cloud instances because they best protect email availability. However, any solution that requires configuration, especially beyond DNS records, can lead to crashes, crashes, or poor security. If you choose to use a cloud service provider, you will also be subject to the SLA (Service Level Agreement) and your contract with the provider. However, they simplify the process; You are solely responsible for updating the MX record in the DNS zone file and choosing the correct settings.
Some vendors will also support and manage your SPF, DKIM, and DMARC implementations for you. Weigh the risks of what could happen if the system fails against the benefits you will get from using it. Does the vendor provide threat intelligence? Does he specialize in this particular service? What is stipulated in the contract?
As security professionals, we must build our systems so that they can not only handle normal workloads, but also resist abuse in a way that forces an attacker to act long enough to give us time to detect and respond.
When protecting your systems against phishing, we recommend that you implement controls beyond those used exclusively for e-mail. Although we won’t discuss them in this section, implement anti-malware protection, whether it’s an antivirus, endpoint detection and response (EDR), or any other anti-malware product. Most malware enters a company’s network via email when users download it from a link in a phishing email.
Two other technologies can prevent the catastrophic consequences of phishing: file integrity monitoring (FIM) and data loss prevention (DLP). FIM tracks files from a specific list for modification. You can write a simple FIM solution that takes the cryptographic hash of each file and stores it somewhere. The app then verifies that the files haven’t changed, and if they have, it checks to see if the change was authorized. This is important for detecting attackers already on the network. If the contents of a file have been modified without permission, this may indicate the launch or installation of new programs, ransomware, or tampering with important files.
DLP prevents users from sending e-mail files outside the organization, uploading files to public external networks and file sharing services (such as Google Drive or Dropbox), or storing data on unauthorized USB devices (unless the ability to connect such devices is blocked). Many DLP solutions also have the ability to prevent users from sharing sensitive or restricted data, such as customer payment card details. This is important because it prevents users from sharing information that constitutes trade secrets and intellectual property. Having DLP also eliminates many of the reasons users plug a USB drive into their workstations, reducing the likelihood of a successful decoy attack.
We used materials from the book “Social Engineering and Ethical Hacking in Practice”, which was written by Joe Gray.
765 
605 
682 
690 
629 
662 
625 
656 
657 