- API & Integration
- SparkPost vs SendGrid
- Learn More
- Volume Pricing
Choose your sending volume and get up and running in minutes.
- Add-on Plans
Combine with any volume tier for a custom tailored plan.
- Get Started for Free
From start-up to enterprise, we deliver customer success.
Expand your service with add-on, solution and integration partners.
- User Community Slack Channel
- Help & Docs
- Deliverability Guide
- Case Studies
- Email Explained
- White Papers & Guides
- Webinars & Videos
Attestations Don’t Always Measure your Defensive Posture
An attestation, by definition, is an indication that makes something evident. In the case of the security, specifically security programs it means to certify in an official capacity.
People often ask me what makes a good security program. As much as I would like to point to one aspect of my security perimeter to use as an example, there are multiple items to highlight. The industry relies on attestations and certifications to measure your security defenses. Engineers and operators will tell you that your actual security perimeter and threat assessment capabilities define your security program. I will tell you it is both compliance attestations as a measurement and the operational capabilities of your security team that define your program. Though attestations alone are not an accurate benchmark to measure a program.
Attestations are an industry necessity to ensure compliance with federal, local and state statutes as well as industry best practices. ISO, NIST or DoD standards form the baseline of most attestations. NIST, for example, publishes a set of standards and technical guides to help organizations build perimeter defenses that are “acceptable” to the government. As I will outline however, just because the standards are set doesn’t mean implementation is always stellar.
Deployment of a Tool Doesn’t Mean it is Providing Value
Controls allow for flexibility in implementation and operational growth and innovation over time. Unfortunately some organizations use the flexibility to check the box, but have no real defenses in place.
A prime example of this problem is intrusion detection/protection systems (IDS or IPS). Like virus scanners, most organizations invest in IDS/IPS as a matter of standard security practices to guard against malicious traffic and data exfiltration. The industry is replete with vendors making various forms of IDS/IPS systems. However, some organizations build systems rather than buy.
I recently left one such organization that “built” their own intrusion detection system from open source tools. Auditors were told the system was a “fantastic tool”, and even given examples of traffic. When I dug deeper into the telemetry the tool was providing, I realized that traffic was not being analyzed at all. Rather, passing through the sensor as it was not configured to capture any traffic or alert at all. Furthermore, the credentials used to administer the tool were set up by a previous employee and were never updated after his departure. So essentially, the tool was sitting idle for months without any human intervention. Not only does this put the company at risk, but it also compromises the perimeter.
A savvy auditor wouldn’t have caught the issue because the attestations don’t look for “operational” information on all systems – the standard is literally one layer of question and answer. In fact, most attestations measure simply if the tool exists, not operational viability. Additionally, most auditors are not technical enough to discern a functional IDS/IPS from a non-functional. The meat of the audit relies on the company to put their best foot forward rather than answer tough questions. Auditors also have to cover a vast array of controls during an audit so time is a large factor in the quality of their analysis.
An attestation alone will tell you that a company has a mature security program with controls. Requiring a potential partner to complete a vendor survey won’t provide you confidence either. Surveys merely outline the same information in a different format. So how do you evaluate a mature security program?
Evaluate the Entire Cloud Security Program
First, you should review at a minimum the attestations and the findings report, not the executive summary. That will provide you with an overview of the program reviewed by a third party. Second, you should definitely review if the company undergoes a third party penetration test or bug bounty program. Personally I am not a fan of bug bounties, but I am a fan of third party penetration testing on an annual basis. Pentesting provides you with a structured test of your defenses and real feedback on vulnerabilities. Finally, review the security documents (usually table of contents) the company utilizes as a basis for implementation. This includes (but certainly is not limited to) a security policy, incident response and vulnerability management. An experienced security team will offer to share those documents and artifacts as a part of normal business.
I make it a matter of course to evaluate every vendor and partner from the perspective of access to company data. Meaning if the partner or vendor manages company data, they’re subject to more scrutiny than a vendor that does not. Keep in mind the business purpose when evaluating a security program. I review the business purpose and type of information involved, then evaluate from that perspective, rather than handle all partners and vendors the same. When in doubt, always ask for more information.
— Steve Murray
Protecting Your Brand Against Threats
Your brand has a reputation and beware, because criminals want to ruin it through email. Yes, unfortunately, there are a lot of bad people sending email out there. We like to classify them into three categories: spammers, phishers (or scammers) and spoofers.
You’re already familiar with spammers, they send you unsolicited email. Phishers try to get you to divulge your personal information. Lastly, Spoofers impersonate your brand and send email as you to your customers in hopes of phishing, scamming or worse, bringing your business to its knees. Yikes! Sounds like a security nightmare, and it is.
When your email is spoofed, your reputation gets tarnished among ESPs, which means sending even legitimate email will be hard. This can be worse than having your company’s servers hacked.
Don’t fret because there are things you can do to prevent these types of security breaches from happening to your brand and they’re incredibly easy to set up.
In our upcoming webinar on February 7th, Bulletproof Your Email in 2017, join SparkPost CISO Steven Murray and ValiMail’s CEO and co-founder, Alex Garcia-Tobar, as they talk about the importance of email authentication, how impersonation attacks can slip through conventional defenses, and how to protect your brand against various security threats in 2017.
So, in this upcoming webinar we’ll review:
- Different types of security threats we’re seeing
- How this impacts your brand’s reputation
- How to combat these criminals and protect your email and your brand
You won’t want to miss this! Register today for the Bulletproof Your Email in 2017 Webinar on February 7, 2017 at 10am PT/1pm ET.
Bonus: Be one of the first 500 people to sign-up and have a virtual coffee on us!
In the meantime, you can keep yourself busy with Steve’s blog on Debunking the Myths of Moving Your Email to the Cloud or Alex’s post on Three DKIM Challenges You Might Not Know About. See you soon!
If you’ve followed technology industry trends for the past several years, you know that all manner of business and consumer technologies have been moving from stand-alone, on-premises systems into the cloud. In fact, we’ve reached the point where we no longer speak of the cloud as the future of software—it’s the present.
For most of us considering developing a new system, there’s really very little debate about whether or not it should be built in the cloud. The answer is a clear yes. But not all of us have the luxury of a greenfield implementation—and as with past shifts in system architecture, how best to deal with legacy systems is a question that requires careful thought.
Shifting marketing and transactional email from on-premises systems to a cloud-based email delivery service is one example of this challenge. Let me try to debunk some of the myths surrounding email security when moving your email from on-premises to the cloud.
Myth: Cloud email services are less secure than using on-premises software.
Email services are neither inherently more or less secure in the cloud. The truth is, email security has much more to do with configuration and practice than with system architecture. And on those fronts, the cloud actually offers some security benefits.
First, the security perimeter is smaller and more defined than in a corporate setting. Second, the user base is easier to move and administrate in a cloud setting, and access is more robust and easy to maintain for users and administrators. Finally, the cloud affords security administrators benefits like:
- Centralized attachment scanning and blocking
- Unified storage and lower cost administration and access controls
- Ease of auditing and monitoring
To my mind, helping security administrators do their job more easily and effectively is the surest route to an overall improved security stance.
Myth: I will lose control over my data by moving my email service to the cloud.
This is an easy myth to debunk. In SparkPost’s cloud infrastructure, email and associated data are still controlled by the customer. Data management remains with the customer regardless of the hosting environment.
Myth: Anyone can access my data in the cloud. Plus, if it happened to Yahoo, couldn’t it happen to me?
A good cloud infrastructure (including Amazon Web Services, the cloud infrastructure used by SparkPost) has a lot of security baked-in and tested in ways few vendors can match. However, there’s no magic bullet here. Odds are that breaches can and will happen to everyone at some point, whether on-premises or in the cloud. Defense is expensive and hard. Even with the best defense, there is always an opportunity to be compromised. The key to success is to practice good data management, backup, and security. So encrypt your volumes, use multi-factor authentication—and most of all, enforce strong standards and procedures. Educate your user base to look for anything unusual and stay alert to the current attack trends. As with so many routines, complacency kills. Stay alert!
Myth: There are no steps I can take to make my cloud infrastructure secure.
Technology is good, however, it’s only as good the processes and controls that enforce it. By that, I mean putting policies and standards in place to enforce strong authentication and data security protocols. Use Multi-Factor Authentication (MFA), VPN, and other protections to control access to the production instances and email services. Drive your user base to use multi-factor authentication and connection protocols requiring multiple steps to access data. Encrypt your data at rest and in motion. (If you look at data breaches historically, the most destructive have been those that gained access to data that wasn’t encrypted. Never assume your fortified perimeters will save you.) Audit your user base and ensure only the right population has access and appropriate user rights. Enforce attachment scanning. Enforce perfect forward secrecy protocols. Are you seeing the pattern here?
Don’t take shortcuts, even though every developer and every user wishes you would for their convenience. Those extra steps, as tedious as they sometime seem, are the keys to keeping your instance secure.
Myth: I’m not sure I’m ready to move all of my data at once and it seems that it’s all cloud-or-nothing.
No, there’s nothing that says cloud use cases have to be all-or-nothing. It’s really a question that depends upon the needs of your particular business and velocity. You will have to determine the best course of action for your business case. For highly sensitive data, an incremental migration or hybrid cloud setup may be the way to go until there is enough trust in the new solution to fully commit. In other instances, you may want to rip the band-aid off and move it all at once, because the benefits of the cloud outweigh the risks. Regardless, ensure you have a good working backup solution during the migration and a solid continuity plan before you move any data.
Myth: It will take a long time to realize the benefits of moving to the cloud.
This is something I could talk about for hours. There’s so much good for both the business and for the technology team. But really it comes down to this: the cost/benefit of email in the cloud seems simple, but the truth is it’s even better than you think. The cloud really has upended the economics of software development and enabled genuine business innovation. Flexibility, scalability, shifting costs from capital to operational expenditures—these are all benefits that business execs love. Technology teams get to offload the operation of infrastructure to service providers who can do it more reliably, with better deliverability, and operate it at lower cost. It frees internal development teams to focus on unique functionality and business differentiators. It’s one of the clearest examples of win-win I’ve seen in my career in tech.
Myth: I won’t save much money by moving to the cloud
Between the costs of hardware, physical plant, and operational staff, operating your own on-premises infrastructure is a significant drag on business flexibility and budgets. SparkPost surveyed several real-world businesses and crunched the numbers. Afterward, we found that moving email delivery infrastructure to the cloud is a strategic win for companies that send high volumes of commercial and transactional email. In fact, a business that sends 750 million emails a year can save up to 40% by migrating email infrastructure to the cloud.
What is the onboarding process like if I choose to move my email service to SparkPost?
At SparkPost, onboarding involves several interactive tools and resources to ensure a successful start for all of our users. For our enterprise customers, the experience also includes the expert support of our Technical Account Managers (TAMs). In fact, the “white glove service” our TAMs deliver is one of the things I’ve consistently heard from our larger customers has helped them to succeed. They help senders lay the groundwork for the highest performance, make sure implementation is successful, help with the go-live transition, and then provide proactive ongoing support. It’s a real differentiator from other email delivery services.SparkPost © 2017 All Rights Reserved