DMARC
UPDATES: December 26, 2023: The Department of Defense published for comment a proposed rule for the Cybersecurity Maturity Model Certification (CMMC) 2.0 program. December 7, 2022: DMARC and other specs dropped from CMMC 1.0 have been sent to NIST to be included in future revisions of NIST SP 800-171, which CMMC is based upon. For more recent updates, you can visit the Department of Defense Chief Information Officer webpage. The following was published September 20, 2021. The Cybersecurity Maturity Model Certification (CMMC) is a cybersecurity framework being developed by the Department of Defense (DoD) to protect defense contractors from cyber threats. CMMC measures cybersecurity maturity with five levels consisting of security controls, practices and continual improvement to stop the theft of intellectual property, proprietary information and credentials that threaten economic and national security. When an organization sets out to achieve a particular CMMC level, it must also meet the preceding
Recent discussions in the email security ecosystem have highlighted a security loophole concerning Google’s handling of emails sent to a Google Group. This issue arises particularly when the emails come from a domain with a DMARC policy set to p=quarantine or p=reject. Google Groups functions similarly to a mailing list. When a group address receives an email, Google forwards a copy to each group member, retaining the original From: header. This From: header is crucial, as it’s what recipient systems use to determine which domain to check against for DMARC compliance. In essence, when Google forwards these emails, it’s as if Google is spoofing the domain being forwarded. This becomes problematic with domains like AOL or Yahoo, where the receiving system will reject the email, recognizing that Google isn’t authorized to send on their behalf. How scammers exploit Google Groups’ email forwarding Domain Acquisition: Scammers start by acquiring a new
The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), and Multi-State Information Sharing and Analysis Center (MS-ISAC) have released Phishing Guidance—Stopping the Attack Cycle at Phase One to provide guidance in the ever-waging battle against phishing exploits. The guidance is relevant to all organizations, though it may pose challenges for those with limited resources. To address this, the guide incorporates a section with customized suggestions tailored for small- and medium-sized businesses that may lack the resources for a dedicated IT staff to consistently combat phishing threats. For software manufacturers, the emphasis is on adopting secure-by-design and default strategies. The guidance encourages software companies to create and deliver software that is resistant to common phishing threats, ultimately enhancing the cybersecurity resilience of their customers. In the phishing mitigation guidance for all organizations, CISA, NSA, FBI, and MS-ISAC recommend organizations implement DMARC and other controls
Starting February, 2024, long established email authentication best practices will become a requirement. It’s as simple as that, folks. This news may be alarming to you for a variety of reasons; you may have previously interpreted these guidelines as being optional or didn’t understand the related technical complexities. Or maybe you trusted that your email service provider, or IT Department was taking care of this for you. Whichever camp you may be in, the responsibility is yours to ensure you are compliant and have the proper visibility to maintain that favorable status from that point forward. As abuse continues to mature, so must the controls that have been implemented to secure the email channel. We applaud Google and Yahoo for ushering this new reality in much of the same way that dmarcian has always taken a standards and best practices approach. Our mission has been to spread DMARC across the
Ransomware, Act I The first documented ransomware attack was delivered by the postal service in 1989 when 20,000 floppy discs loaded with malware were sent to AIDS researchers across the globe with the promise of advancing research. When loaded in computers, the discs installed malware and displayed a ransomware message demanding payment to restore data and systems. The attacker, an AIDS researcher himself, took advantage of other researchers to capitalize on the urgency and uncertainty of the AIDS epidemic. Cybercriminals continue to employ similar scare tactics today, using coercion, matters of necessity and social engineering to dupe unsuspecting people. Instead of using snail mail, cybercriminals use unprotected domains to send spoofed emails for deploying ransomware. What is Ransomware? The Cybersecurity and Infrastructure Security Agency (CISA) defines ransomware as a type of malware “cyber actors use to deny access to systems or data. The malicious cyber actor holds systems or data
A domain’s DMARC record can tell the world to send DMARC reports to a different domain. For example, the domain example.org might have a DMARC record of: v=DMARC1; p=none; rua=mailto:dmarc_reports@sample.net This DMARC record tells people to send reports regarding example.org to the email address of dmarc_reports@sample.net. Before reports are sent, sample.net must tell the world that it is OK to send example.org’s reports to sample.net. Otherwise, reports will not be sent to sample.net. Allowing “external” domains to accept DMARC reports is called “External Domain Verification.” For those who like too much information, the DMARC RFC describes in detail how report generators determine if sample.net is allowed to receive reports related to example.org. External Domain Verification is made possible when sample.net publishes a special TXT record at a specific location in the DNS. If example.org tells the world to send DMARC reports to the sample.net domain, people who are sending reports will
Our Single Sign-On (SSO) support leverages Security Assertion Markup Language (SAML) version 2 for Enterprise users. This expedites access to your dmarcian account by letting you sign in with your existing corporate credentials, which means one less password to keep track of. With our SSO, you can easily manage SSO access and user permissions to all of your accounts in dmarcian centrally while adhering to your organization’s security and access policies. Before getting into the details for SSO configuration, let’s first talk about some basic concepts and terminology: Authentication Authentication defines how the user is identified in a system—usually through a login process. Traditionally, a user registers for an account providing authentication credentials (username and password) and uses them to log in moving forward. In the past, this has been sufficient, but it does have limitations. For example, what happens if you have a several employees at your company that you want to grant access
Based on domain events that act as triggers for sending alerts, the highly customizable Alert Central feature on dmarcian’s DMARC Management Platform allows you to monitor your domains without having to login to your dmarcian account. Events could include new or changed DNS records (e.g. we see a new DMARC record) and fluctuation in volume across categories of traffic for your domains. You can choose from common communication channels for alerts—email, Slack, Teams or webhook. The alert will provide you with the details of the event and a link to your dmarcian Timeline for you to get even more information. How does Alert Central Work? Alert Central is based around the dmarcian Timeline. Like the Timeline, you choose which changes to track, and the alerts ensure that you’re aware of the changes in real time. When we notice a DNS change, a change event gets triggered. If a DNS record
Email forwarding can sometimes throw a wrench in DMARC authentication results, and we often get questions about how to manage forwarded emails, especially with mailing lists. Emails are forwarded automatically all the time, more so than most people expect. Forwarding happens automatically when you send an email to myfriend@example.com and that person has set up their email to be forwarded to a separate inbox, like myfriend@dmarcian.com. Another common instance of automatic forwarding is a mailing list, like Google Groups. From the perspective of the email receiver—the one that is generating DMARC XML reports—your email appears to be coming from an infrastructure that has nothing to do with you. In Google Groups, DMARC data that displays forwarding will show your domain as a sender, a Google IP as the sender, and a variety of receivers who send the DMARC report as part of their DMARC check. This number can increase quite
Though Cisco email security appliances (ESA) can be configured to send DMARC aggregate (RUA) reports, they have a limited number of daily DMARC reports they provide. This limit can be easily reached by organizations sending large volumes of email, especially if multiple subdomains are seen in the From header of messages received. The number of subdomains seen is an issue because of a deficiency in how the Cisco IronPort system generates DMARC reports. Instead of creating a single XML report containing data for the top-level domain and any subdomains (e.g. example.com along with www.example.com, server.example.com, etc), each server instance generates a completely separate report for each—this causes the limit to be reached rapidly. Increasing the daily limit will ensure that you have the proper visibility and are helping other organizations with their DMARC projects. The daily DMARC report default setting is 1000, which can be increased only through the command-line