Watch for bold keywords which make excellent talking points with technical advisers.
When I speak about using secure passwords, it’s often met with eye rolling, sighing, or recounting of frustrations with remembering passwords. I get it, but I can’t really change my message. It’s a core tenant of basic security practices. But people are dismissive of more than just long passwords; it’s security-related inconvenience in general — especially when related to computers and accounts.
I’d like to highlight the value of difficulty and hopefully alter your paradigm.
Let’s start with a story
It’s raining and you arrive home and have a double-armload of groceries to carry into the house. Approaching the door, you’ve forgotten to get your house key out, so you dig for it. Struggling and juggling, a glass jar and several other items crash to the ground. Soaked, you finally find the key. Once you get the door unlocked, you sop inside, frustrated with the whole process.
An alternate story
It’s raining and you arrive home with the same armload of groceries. Getting inside quickly is no sweat, since you left the front door wide open to make it easy to get in and out. You hurry inside, barely wet, and put away your groceries, patting yourself on the back for how convenient you’ve made your life.
I'm sure you see where I’m going. Essentially, it’s OK for some things to be hard. If you came home to see your front door open, what would you feel in the pit of your stomach? Would you call the police? We keep our homes and cars locked, even though it might cause us to be stuck in the rain or we might lose our keys and be locked out. We do this because it is an acceptable inconvenience. We see the value of locks, despite the extra effort required. Security is all about making something difficult for others to access. So if a slight inconvenience to you adds significant difficulty for an attacker, there's really no more evaluation needed.
Why don’t we feel the same about securing our computers as we do about securing our homes?
How sensitive or critical is the information accessible from your computer, your phone, and your online accounts? Isn’t that worth some effort protecting? If an attacker can get into your email, he can use it to reset all your online account passwords while you sleep. How much of your life could be controlled from just your email account?
Of course, there is deeper value for you and your business. Following security best practices may yield lower cyber insurance insurance premiums and protect against actual and reputational damage or fines. Demonstrable competence in security can also boost client or employee confidence (tip: avoid security theater, which leads to a false sense of security). The benefits of security are myriad, though are often difficult to quantify, especially from your IT guy; for an insightful read, lookup “Security’s Value Proposition” from CSO Online.
So, what to do now? To begin with, if you can be considered important in any way, you should be using 2-factor authentication on every account you can. Do this today. As for your business, request a discussion with your IT department or service provider about the CIS Top 20 Controls, which lists the most effective controls to reduce security risk. Agree on one at a time and pursue each as a little project. Quarter-by-quarter, this will drastically reduce your business' risk.
A last thought: insurance is not a substitute for security. Insurance cannot bring back your data or reputation, so it’s important to protect and maintain it properly.
When it's time to make an important decision, you should lean on proven methods. This is one of those methods.
View our actual SOCaaS Weighted Decision Matrix here. Feel free to make a copy and use it for yourself.
The winner of our SOCaaS WDM process was Perch Security. The next-closest was only 80% of Perch's score.
Watch the video here. (If you end up pursuing a relationship with them, please mention us as your referral source!)
If you need to evaluate SOCaaS providers, have a look at the actual weighted decision matrix we used to make our decision. Since even a 19% margin of difference between your requirements/scoring and ours still leaves Perch in the lead, if your evaluation crieteria are anything close to ours, we've probably saved you a lot of work. Just go with Perch.
(This article is a part of a series on email and domain protection)
DMARC's role is twofold: 1) It is used to specify what to do with incoming messages, based on whether they align with SPF and DKIM records of a given domain; and 2) It generates reports back to a domain owner regarding email volume, sources, and what policies were applied to those messages.
While there are plenty of how-to guides out there, the purpose of this article is to give a helpful overview of exactly what DMARC is and why it's important for everyone to implement on every domain.
Without SPF and/or DKIM records in place, DMARC still has some value (reporting), but no power to accomplish anything. At a minimum, an SPF record is required in combination with DMARC in order for receiving servers to apply any policies to inbound messages.
DMARC Message delivery workflow
For domains that send mail, DMARC is a huge step in protecting not only IP-based reputation, but also domain-based reputation. The domain administrator publishes an SPF or DKIM record (preferably both), then a DMARC record. The DMARC record specifies what to do with messages that don't align with SPF or DKIM, as well as where to send reports on the quantity and sources of email received on behalf of the administrator's domain.
For any domain that sends mail, it is recommended to start with a DMARC policy of "none," which does nothing to break any mailflow, but allows for reporting. The often-underrated significance of this reporting is that the administrator gets to see how many messages are coming from his domain as a whole, including servers not under his control. Anyone can read the logs of their own equipment, but when, for example, a Russian spam server is sending mail from that same domain without permission, there is no other way to get reporting on that than DMARC. DMARC allows receiving servers to report back to domain owners exactly what is being sent on their behalf.
These reports help domain owners to understand what email is being sent in their name, both legitimate and illegitimate. These reports can be used to ensure all legitimate sources of mail have been accounted for before tightening down the SPF policy from ~all to -all. The reports continue to be useful in fine-tuning DMARC policy when switching from "none" to "quarantine" and again from "quarantine" to "reject."
After accurately accounting for all legitimate sources of mail and accommodating them in SPF/DKIM records, the DMARC record can be changed from "none" to "quarantine." Note, as in the illustrated example above, the policy is only applied to messages that fail both SPF and DKIM. If both exist and the message aligns with either of them, the DMARC policy is not applied.
Quarantining a message generally means shoving it into a SPAM folder. For the smoothest application of a policy of "quarantine" or "reject," DMARC allows for the policy to be applied to any percentage of messages, rather than all of them. For example: when quarantining messages, it's prudent to start with 1% and wait for reporting to come in, then use the forensic reporting to view the raw HTML body of the affected messages. Once comfortable that all the quarantined messages are illegitimate, the percentage can be increased so more and more messages are delivered to the spam folder instead of the inbox. Gradually, this percentage is increased until all messages not aligning with SPF/DKIM are quarantined, then the process is restarted with a policy of "reject."
Domains that send no mail should have both a "null" SPF policy and a DMARC policy of "reject."
Further monitoring revealed a peak fraudulent output of >6 million messages in a month, 99.99% of which were being blocked.
SPF - Sender Policy Framework
SPF (v1) provides a framework for domain owners to effectively whitelist authorized email sources (servers by IP, not persons who send) for a given domain.
What about domains that don't send mail? All domains need an SPF record. It's simple: create a "null" SPF record to specify that nobody is authorized to send mail from that domain. It's a whitelist that's blank, thereby eliminating the opportunity for malicious persons/organizations to send fraudulent mail on behalf of a legitimate domain. Just because a business or person doesn't USE a domain to send mail doesn't mean someone else can't maliciously spoof the FROM as that domain. Why leave it unprotected when a 2-minute task can secure it?
Create standard SPF record:
Larger organizations or those who think there is even a chance there is another 3rd party sending legitimate emails on their behalf (think: confirmation emails, receipts, marketing departments that don't coordinate with the IT department, etc) should use the ~all instead, as it will not cause messages to be rejected. Messages from sources not whitelisted in the record receive a "soft-fail" mark which increases their chance of being delivered to spam if there are any other red flags in the message source, subject, or body.
Until additional visibility into mailflow and sending sources can be obtained, it is recommended to keep the soft-fail mechanism in place.
The next step in protecting a domain's reputation and preventing spoofed messages is either DKIM, DMARC, or both. DMARC provides reporting on all mail purporting to be from a given domain, and gives excellent insight into sources that may not have been known by the IT department. It can be used for a thorough "discovery" process and SPF/DKIM records can be adjusted before rejection policies are made strict. This process preserves legitimate mailflow alongside the illegitimate, but prevents legitimate messages from being rejected or stuffed into spam folders.