January 2, 2020 | By Michael Wainshtain, Technical Team Leader
The email channel is one of the most targeted vectors, simply because this is a real-live-open connection from the outside world (WAN) and your corporate network. Did you know that most cyberattacks begin with a “spear phishing” and\or a “malicious document” email? Basically, we wish to block this kind of threats on the mail relay level and not on the Endpoint.
Highlighted below are the 10 do’s for your email infrastructure, as suggested by TrustNet TSOC. Some are harder to implement but trust us, it’s better to have a few rather than nothing 🙂
Do: Block delivery of PE files, scripting files and password protected files (encrypted).
Why: Malicious files can come in many forms; any file that we cannot inspect or predict what their purpose is must be stopped in the gateway for further checking/analysis.
Do: Use an anti-spam\virus engine to filter out junk\abusive email.
Why: Vendors’ intelligence systems can provide a lot of information about known bad\ unknown email senders.
Do: Make sure to check RBL lists against incoming connection source IPs.
Why: Block bad known senders prior to arriving at your mail gateway.
Do: Annotate external threads (big yellow warning that says this email came from an EXTERNAL source).
Why: This is done as part of awareness and training; the human is the weakest link.
Do: Enable ‘URL’ analysis leveraging vendor reputation and community.
Why: Vendors’ intelligence systems can provide a lot of information about known bad\ unknown email senders.
Do: Monitor external emails that have your domain name in the header.
Why: Anti-spoof protection – threat actors might spoof an email to be seen as it arrived from someone in your organization while the email actually came from another domain\organization.
Do: Configure PTR\SPF to control who can send emails on your behalf.
Why: Configure PTR for your external IP not to be blacklisted by different RBLs. Configure SPF to enforce WHO can send email on your domain behalf.
Do: Make sure to use opportunistic TLS (SMTP over TLS)
Encrypt EVERYTHING for privacy concerns.
Do: **Office 365 users: Create a transport rule to reject every email that DID NOT come from your mail relay.
Why: Threat actors might try to send email directly to your 365 without going via the MX records you have already configured on your domain name.
Why: Configure DKIM\DMRAC
Why: DKIM will confirm the trustworthines of the message to make sure that their content weren’t changed right from the moment the message left the initial mail server. DMARC enables the message sender to indicate that their messages are protected with SPF and/or DKIM.
