The Importance of the DMARC Record - Protecting Your Domain Against Spoofing Attacks These days, it has never been easier to establish an online presence, and having your own domain is a key component of that. However, with great domain ownership comes great responsibility, as do the problems that can follow your presence. As such, when managing individual DNS records, all users should stay up to date on the latest trends with regards to safeguarding their domain’s reputation, as well as all the persistent problems that come with online communication. Spoofing is one of those age-old issues when using e-mail as a contact protocol, and when it comes to spoofing protection, Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) are usually identified as a consistent “best practice” standard. However, they themselves are not enough to prevent modern spoofing techniques, even if both of these DNS records are both useful in their own way.

Though Amazon’s Relational Database Services (RDS) can make hosting a database much easier, using them can also present new challenges, including some that crop up when you’re trying to scan against security benchmarks or meet compliance initiatives.

Employees are one of the weakest links in any business’ security defenses, especially if there is a lack of awareness about criminal attacks that are designed to obtain sensitive information from organizations.

Many of the requests that we receive are limited in scope to Internet facing assets. A true understanding of the threats facing your networks requires a complete evaluation of all possible threat vectors. So what kinds of vulnerabilities does an internal test find that an external would miss? Schellman was recently engaged to perform an external and internal penetration test for a software development firm. The external test revealed very little about the company. Strong firewall rules opened only the most necessary of ports (80 and 443) to the Internet. All external facing servers were well patched, running modern operating systems and lacked any exploitable vulnerability. However, the internal assessment told a completely different story. We began the test with no credentials on a “rouge device” that was placed on the internal network. A database server running an automation tool exposed a scripting console that allowed unauthenticated commands to be run on the underlying OS. A VBS script that downloaded an executable was run followed by another VBS script that executed the shell program. With this foothold, we impersonated the token of a database administrator who also happened to be a Domain Administrator. A few commands later, we’d taken over the domain. If our client had only engaged us for an external test, none of this would’ve been found.