Dome9 - Secure Your Cloud » Press Releases

Meet the Dome9 Team at AWS Summit Events

admin — Sun, 14 Apr 2013 10:30:14 +0000

Dome9 is a proud sponsor of three AWS Summit events, taking place this April 2013

Meet Our Team

We invite everyone to visit our teams, introduce themselves and get a preview of what’s coming up from Dome9 later this year. You’ll have a chance to meet the team building our groundbreaking service and grab a cool t-shirt.

Cloud MSPs Wanted!

Dome9 SecOps for AWS is an innovative solution for managing EC2/VPC security, and it has become a critical component for many Cloud MSPs offering managed services on top of AWS. With our ultra granular access controls, Cloud MSPs could allow their customers to manage some aspects of the AWS environment, while maintaining overall policy ownership, visibility and keeping and audit trail.

Don’t hasisitat to send us a note and schedule a meeting with our team, to sales [at] dome9.com

New Cloud Security API & Amazon SNS Intergation

Roy — Thu, 21 Mar 2013 17:02:34 +0000

I’m excited to announce the availability of our new cloud developer API to our rapidly growing community of users, developers, IT experts and security geeks.

The new API, available at developer.dome9.com, allows you to programmatically interact with our service and tightly integrate our secure access leasing with your applications and infrastructure. With this, you can seamlessly grant users and systems secure access to your cloud network and server resources. Let me give you an example.

Developer API in Action

Imaging you want to allow an automated batch process to securely access remote resources. For example, you want to grant a bash script that utilizes FTP (god forbid) or SCP secure access to download data from your cloud servers, without having to leave that service port (FTP) open to the world 24/7.

By using the Dome9 Developer API in your script, you can automatically create a secure access lease and open FTP dynamically just for your two servers, so they can only communicate with each other to transfer the files at the point in time they need. Then, once the transfer is complete, FTP on both server firewalls is automatically closed again, securing them. This is automated, pinpoint secure access between cloud applications and infrastructure.

We’ve been using our API internally for our Chrome extension and iPhone app, but now we’re made it available in the wild so you can use it too in your everyday environments as part of your application architecture. The API is compatible with both Dome9 Agents and Dome9 protected AWS EC2/VPC and HP Cloud Security Groups.

Another powerful feature of our API is the ability to create access leases for IP address other than the one initiating the API request. With this, you can create additional authentication processes on a separate server that, only after successfully completing, whitelist your user’s IP address on the application server. Our API credentials can even be restricted to access specific servers and services, for ultra-granular automated access controls.

To get started with our developer API, visit http://developer.dome9.com. You can review the specs and use our API Console to try it out on your account. Don’t have one? Create one free for 30-days (no credit card required).

New Security Event Notification Service

The API isn’t the only thing we’ve released. We’ve also just added real-time security policy change notification and audit streams for all cloud and application servers via AWS Simple Notification Service (SNS) and AWS Simple Queueing Service (SQS).

Now you can add Dome9 to any cloud or application server and receive an instant notification any time there’s a security policy change and/or access via a user or application.

The benefit: Know immediately when an application or user gains access to your cloud servers and take immediate action. This is extremely important in complex distributed environments where developers, IT and third parties share application responsibilities.

Have questions? Drop us a line at contact@dome9.com. We’re here for your questions, comments, suggestions and complaints.

Roy

5 Reasons VPNs Suck in the Cloud

Dave — Thu, 14 Feb 2013 17:26:18 +0000

If you’ve been around the block a few times, you’re probably wondering why the title of this post isn’t, 50 Reasons VPNs Suck in the Cloud.

VPNs have long been the bane of both administrators and users (and lets not forget, support). They’re clunky, complex, and costly, and the same is true when they’re deployed to secure cloud access.

Today, VPNs are increasingly used to connect to cloud computing resources. Either by routing traffic back through the corporate network or direct to the cloud provider, VPNs offer authentication and transport-layer encryption to keep the bad guys out and sensitive information secure. But at what cost?

Both VPN configurations (corporate and provider) are complex to set up, require client agents with loads of support, and can be expensive to maintain. Arguably, there’s room for – and exists – a better approach to securing access to cloud servers.

We’ll get to what that is in a coming post, but for now we thought we’d share a few reasons why VPNs suck in the cloud, in reverse order (for effect).

5 Reasons Why VPNs Suck in the Cloud

#5: Cloud VPNs Don’t Scale

Is your cloud spread across multiple regions? Get ready to spin up multiple VPN servers (for HA) in each. The larger, more distributed your cloud is, the more backend infrastructure, complexity, and cost you’ll have just to support VPN.

#4: Local VPN Clients Never Work

OS updates, routing and NAT complexities, and frequent VPN client updates make client-side VPN apps a real hassle. How many times have you been at a conference or in a hotel, and your VPN client can’t connect? Well, the same is true for your peers, and your support team feels the pain every time they pick up the phone.

#3: No Audit Records

When a user VPNs directly to the provider, you might be able to get some audit details showing when they connected, for how long, etc., but only when you retrieve this info manually from your VPN service. Alternatively, if you’re VPN’ing back through corporate, you won’t have an audit trail to see who’s accessed your cloud server, when, from where, and for how long. It’ll all just look like corporate network traffic. So, if ever there’s an incident, you’re likely left high and dry.

#2: VPNs Don’t Work the Way You Do

You don’t have one device; you’ve got many. You work from home, you work on the road, you use your mobile, etc. Does your VPN? Is your VPN client supported on all your devices? Does it let you connect from your in-law’s machine when all hell breaks out during the holidays? Probably not.

#1: VPNs Don’t Do Much

You spin up a VPN to secure your cloud resources, but the truth is VPNs are redundant and often over expose your cloud servers.

Anyone that authenticates via VPN has unfettered access to all of the services in your cloud. Hence, cloud VPNs overly expose your resources. Even with a VPN, you still need to manage your firewall policy, which can be used to more efficiently augment/replace VPN, since your protocols are encrypted anyway.

What’s worse, VPNs don’t really do much to secure your cloud infrastructure. They don’t manage or work in combination with your firewall policy, encrypt the data on your server, or audit for compliance – they’re merely a method of transport-layer protection to encrypt what’s typically an already encrypted tunnel (e.g., SSL, SSH, etc.). See our post: Why VPNs Clients are Dead in the Cloud. So with VPNs, you’re basically just protecting something that’s already secured.

So, if VPNs suck and just about everyone hates them, then why are they so popular? Well, VPNs are what most people know from traditional IT. Your probably, however, haven’t had experience with new, innovative technologies like Dome9. But that’s why you’re here, reading this post, and we invite you to try our service free, for 30 days.

In the words of the great Doctor, Dr. Seuss, “Try them! Try them! And you may. Try them and you may I say.”

Want to add your thoughts? Visit the comments section below, and stay tuned for more posts on this topic.

Patriot Act vs Data Protection Laws – USA vs Europe

Dave — Wed, 06 Feb 2013 17:08:30 +0000

This is a guest post written by our friends at Lunacloud.

Security and Privacy are two sides of the same coin. You don’t want to risk your information by having the wrong policies or wrong technology in place. But in the legal landscape your information or your customer’s information can be sent to a third-party, without any breach in security.

This “third-party” is governments all around the world. This is why it is critical that when you choose a cloud provider you know exactly which legislation they and you have to comply with and know your risks.

Much has been said about the US Patriot Act, under which companies based anywhere in the world, provided they have a US parent company, have to disclose information about their customers (without their knowledge or consent) to US law enforcement. You might think that if you are in Europe (or in another country) with similar Data Protection Laws you are safe. The Data Protection Laws in the 27 countries of the European Union prohibit the disclosure of personal information without the owner’s knowledge and consent. However, this conflicts with the provider’s obligation to comply with the US Patriot Act, if the provider is a subsidiary of a US company. In practice, when facing this conflict, providers will disclose customer information to US authorities. Of course, this is only applicable if you fall under suspicion for some reason and the US authorities want to know more about you.

One might think that if you choose a cloud provider not based in the US, but based in Europe (for example, if you choose Lunacloud instead of Amazon or Rackspace), the Patriot Act doesn’t apply and you’re “safe”. It’s true that the Patriot Act doesn’t apply and your information won’t be disclosed to the US government. However, you are not “safe”. Have a look at Hogan Lovells White Paper on Government Access to Data. It goes into more detail on this topic and “reveals that every jurisdiction examined vests authority in the government to require a Cloud service provider to disclose customer data”.

In conclusion, your information is subject to be disclosed to governments. When choosing your cloud provider, you are only choosing which legislation your provider will have to comply with, but in general, one is not better than another when it comes to developed countries (and if you think of putting your information elsewhere, you will have a lot more risk).

If you really, really care about the privacy of your information, then it all comes again to policies and technology (and encryption technology in particular).

António Ferreira
CEO

Lunacloud Cloud Servers and Cloud Storage

5 Biggest Mistakes Admins Make With Cloud Firewalls

Zohar — Mon, 04 Feb 2013 18:24:46 +0000

The Cloud can be a great investment for most organizations. It offers the promise to significantly increase capacity and agility, while simultaneously reducing costs. Companies invest significant resource to attain a great ROI in the cloud, but if that investment isn’t secured, migrating could turn out to be a disaster.

Most cloud adopters underestimate the philosophical and technological change required to security when migrating to the cloud. It’s a problem that affects organizations of all sizes, whether they have a few or a few hundred cloud servers. So, to help these and others, we’ve put together the following list of the five most common cloud server firewall mistakes to avoid:

#1: Too many rules == Trouble

In development, you typically start with just a few rules in your cloud firewall or Amazon Security Groups. By the time you get into production, however, the list of rules and policy exceptions has grown considerably, creating a complicated mess that you’ll later be too scared to touch for fear of breaking your application or service.

Our suggestion: Limit the number of rules in any single firewall or security group to just ten. This will significantly simplify your administration and prevent accidents down the road, and to re-architect your Security Groups and split complex policies to manageable functional sub-policies.

#2: Beware of the hidden 0.0.0.0/0

When a rule is set to open a port to 0.0.0.0/0, that service is exposed to the public Internet, and supersedes any other rules or limited scopes in the policy. This mistake significantly compounds mistake #1 (too many firewall rules) because it’s difficult to detect amidst the tangled web of rules. Unfortunately, this is a very common mistake, including in AWS VPC, so be sure to check your exceptions to make sure no ports are open to 0.0.0.0/0.

#3: Enforce authorization policy

Not every developer and administrator should be able to configure your security groups. Unfortunately, many organizations do not enforce a strict IAM policy to restrict who can configure their security policy. Be sure to implement IAM controls, and keep close track of who has these rights.

#4: If you use ELB, make it the only entrance

If you use ELB as part of your AWS deployment, you can use it to shield your web servers. By configuring the web tier security group to allow HTTP & HTTPS only from the ELB, it limits the exposure level of your web server’s tier. We suggest you use ELB as the only trusted source for your web tier – no exceptions.

#5: Not all “private” 10.x networks are indeed private

Your cloud instances comes with internal and external IP addresses. Users tend to have 10.x internal network set as a trusted network. This gives the cloud providers more control (in comparison to the external network), but often organizations don’t invest to make their internal network ultra secure. What’s more, in contrast to traditional infrastructure, the cloud’s internal network is actually a semi-public environment, shared by many of its customers. Thus, to protect your environment from your internal network, we suggest using VPC to isolate your own private network in the public cloud.

Final Words

The greatest incentive to move to the cloud is to reduce cost, and organizations invest a lot to that end but that investment is for not if your cloud isn’t protected. At Dome9, we believe that security must be a core component to your cloud adoption plan. In order to execute that plan effectively, without incurring significant risk, you must be able to create a strong, front-line perimeter with your cloud server firewall. We hope that, in sharing these five common mistakes, you’ll now be able to safely adopt the cloud.

[Posted originally at http://www.newvem.com/the-5-biggest-mistakes-made-with-cloud-firewalls/]

New AWS Security Monitoring & Alerting

Dave — Tue, 29 Jan 2013 06:58:47 +0000

Monitor, audit, and get alerts for your Amazon cloud

We’re pleased to introduce an all-new set of capabilities for AWS EC2 and VPC.

Available with our SecOps for AWS service, Dome9 can now monitor security policy for your entire global AWS infrastructure, including:

• Monitor one or more AWS Security Groups for changes and security risks;
• Audit all policy changes to AWS Security Groups made within the AWS console for compliance reporting; and
• Alert when users alter AWS Security Groups or instances are exposed.

Monitor Your AWS Security

Select the AWS Security Groups in each region that you’d like Dome9 to monitor. Selectively apply monitoring (or full protection) to any region / instance.

Dome9 takes a snapshot of your current policy and alerts you to any changes in real-time, whether they’re made in the AWS console, ours, or via API. Now you’ll know immediately when someone adds or changes a rule in your Security Groups!

Audit Policy Changes for Compliance

Independently record all policy changes made within the AWS console or via API. Filter and report on firewall policies for PCI and other compliance requirements, and track changes over time to ensure your computing resources are consistently secured.

Get Alerts if Your EC2 or VPC is Exposed

Dome9 automatically scans your policy configuration and alerts you to potential risks in Security Group rules. Dubbed the ‘co-pilot’, our service tells you if your AWS instances are at risk, and provides recommendations for how to protect them.

Dome9’s new security monitoring and alerting lets you quietly scan and monitor your AWS EC2 and VPC infrastructure for threats. See something you don’t like, and you can simply switch from monitoring to full protection and use Dome9 to secure your Amazon cloud!

Also New – Bird’s-Eye View

In addition to monitoring and alerting, Dome9 now supports global AWS account management. Simply enter your weakened (Security Groups only) API credentials once into Dome9 Central, and instantly select the regions and AWS Security Groups you’d like to monitor and/or protect. Our consolidated credential management gives you purview over your entire AWS infrastructure.

Our new security monitoring, auditing and alerting is included in our SecOps for AWS service, and is available free during your 30-day trial period.

Sign up now to give it a try!

PCI Compliance for AWS EC2 & VPC

Dave — Wed, 16 Jan 2013 18:17:04 +0000

Making sure you’re PCI compliant in Amazon Web Services

We recently published some information on PCI Compliance in the Cloud, highlighting how Dome9 can help with several sections of the PCI DSS regulation for cloud computing.

As a follow up, we thought we’d dive a bit deeper into how this applies within AWS EC2 & VPC, specifically – arguably the most widely used cloud computing platforms on the market today.

First of all, we have to tip our hat to Amazon Web Services team and give them much deserved credit. They’ve built a tremendous platform rich with security controls, so by no means is this post meant to diminish that in any way. In fact, we’ve written a paper on AWS EC2 & VPC security, which you can read here.

Compliance, however, is about how you – the user – implement policy and controls, so the focus here is on how you, the AWS customer create, manage, monitor, and enforce good policy for PCI compliance in AWS EC2 and VPC.

Access Controls for PCI Compliance in AWS

Most folks think encryption when they think of PCI. And, certainly, if you’re not encrypting your CCNs / PANs, you’re not in compliance. But while encryption is a critical component to PCI DSS (section 3, specifically), policy, monitoring, access controls, etc. are too.

AWS IAM provides controls for access management to your EC2 and VPC console, which helps check off part of the requirements of PCI DSS. But these controls are limited to the AWS resources – not your servers and applications, where PCI compliance is arguably most critical. So, when it comes to access to your instances, where your applications and data live, you also need to ensure you’ve got the proper set of access controls.

Don’t let, for example, vendors and employees have unfettered SSH, RDP, SQL, etc. access to your servers. Most people leave these services open and restrict access based on credentials. But doing so leaves them open to the world, and just about anyone (employee, partner, or not) can attempt to access your machines. Worse yet, the bad guys can easily exploit vulnerabilities in the protocol (see our post on the Morto worm) to gain access without ever having to enter a username and password. So, make sure you implement strong user access controls for each individual or group of instances, and set your policy to close administrative ports on your servers at all times and open them only when, for whom, and for as long as is needed.

AWS Security Groups do a nice job of letting you configure what services are open and closed, and for what IP addresses. There are limits, however, and the larger your infrastructure gets the more cumbersome it is to manage and keep organized. Inevitably, you’ll have gaps. Moreover, if you place service and port-level restrictions in your policies, you may end up unnecessarily managing IAM repeatedly. There are terrific ways to streamline this process through technology.

With Dome9 SecOps for AWS, for example, you can configure dynamic access, on-demand… click the Dome9 Get Access button and instantly your port (e.g., 3306 for SQL) is open for your IP address for the next hour. This alleviates the need to manage IAM in AWS for the users that need access only to your instances, and not your infrastructure management. What’s more, you can centralize and automate your security group management across multiple AWS regions. Together, this helps satisfy PCI DSS 2.2, 7.1, 7.2, and 8.5.6.

Monitoring Users and Policy for PCI Compliance in AWS

We jumped ahead pretty quickly into access controls. Let’s now back up to cover policy and monitoring – sections 1, 10, and 11 of the PCI regulation, which are more focused on policy, configuration, and monitoring, respectively.

As mentioned, AWS Security Groups let you configure your firewall policy for groups of instances. What it lacks, however – which is critical to PCI compliance, is the ability to:

1) Display your policy configuration across all EC2 and VPC regions, and alert you to any potential misconfigurations. (sections 1.1, 1.2, 1.3, 11.2, etc.);

2) Retain an audit trail of all policy changes, and store those independently of the infrastructure so they can’t be altered (sections 10.1, 10.2, 10.5, etc.); and

3) Link access to instances to individual users, and log their activity as well as any policy changes. (sections 10.1, 10.2, 10.3, etc.).

If you’re serious about PCI compliance in AWS EC2 and/or VPC, you need to be able to do the three items above.

Dome9 for AWS PCI Compliance

Dome9 SecOps for AWS provides advanced security and compliance controls for AWS EC2 and VPC. Dome9’s SecOps service includes:

➢ Compliance auditing, independently recording policy, access, and configuration changes across your entire AWS infrastructure.
➢ Centralized policy management for your entire cloud, with controls to map user access privileges to only authorized instances.

➢ Tamper and vulnerability protection with intelligent alerting for misconfigured systems and unauthorized access and policy edits.

➢ Dynamic access controls with time-based leasing for employees and vendors, coupled with full auditing for PCI compliance reporting.

To learn more about Dome9 for a PCI compliance cloud, visit our PCI Compliance page at http://www.dome9.com/security-challenges/pci-cloud-compliance

To learn more about Dome9 SecOps for AWS, visit http://www.dome9.com/secops-for-aws or sign up and try it free for 30-days.

5 Cloud Security Tips for 2013

Dave — Tue, 08 Jan 2013 16:03:02 +0000

If you’re like most, cloud is going to be a big part of your life in 2013. So to help you start the year off right, we’ve prepared the following tips for securing your cloud servers.

Here are your 5 cloud security tips for 2013 (in no particular order):

Tip #1: Lock down the server firewall
Big surprise – a firewall management service provider telling you to lockdown the firewall, but putting aside the brand of our soap box, the firewall is the front-line defense for all security. In fact, 73% of IT professionals agree, according to the Ponemon Research study on cloud security. But while there’s a general consensus to use the firewall, few know how to do it properly.

So here’s one little tip from the experts: Make sure you only open admin and other service ports when, for whom/what, and for as long as you need. Don’t, for example, leave SSH open to 0.0.0.0/0 or every bad guy out there will be brute force attack your servers. The same is true for RDP (which is often vulnerable to zero-day attacks (see Morto worm) and other protocols.

Tip #2: Log, log, log, log, log It’s really hard to defend against attacks that you don’t see and/or record. And it’s impossible to demonstrate compliance with regulations if you don’t log. The cloud is especially difficult to log because: A) it operates outside your traditional infrastructure, where many of your monitoring solutions/services don’t operate, and B) logs stored on your cloud server are vaporized when you tear down machines.

So make sure you’re using a 3rd party logging service, either built within your security tool and/or as an additive service, to log who’s accessing your servers, when, from where, for what, and for how long, as well as applications, attacks, and anything and everything else possible so that you can audit and report on policies, activities, compliance, and events.

Tip #3: Encrypt your data And by encrypt the data, we mean before it’s written to your cloud server. Use an encryption gateway (e.g., CiperCloud, Porticor, etc.).

Most folks forget that many of our common transport layers are already encrypted (e.g., SSL, SSH, etc.). So VPN isn’t critical to cloud infrastructure, especially if you’re using Dome9 (see our post on VPN Clients are Dead in the Cloud). But it’s critical (and required, by law in some cases) to encrypt your data, so do it.

Tip #4: Use strong authentication
Strong passwords are not enough. Too many of today’s major breaches and security events are the result of –at least in part – vulnerable and/or stolen passwords. Make sure you use 2-factor / strong authentication to remove (at least in part) the all-too-fallible human quotient from the authentication layer.

There are several ways to do this – explicitly, with a 2-factor authentication solution / service, and implicitly with a methodology or process-driven technology like Dome9, which closes the login service altogether unless the user authenticates independently first with another source. We recommend both, naturally.

Tip #5: Take responsibility
The Ponemon Research study found that most people don’t know who’s responsible for their cloud security. When asked, responsibility was almost evenly assigned to the customer, provider, or both. But this ambiguity leads to big gaps. In the same study, 42% said they wouldn’t know if their cloud was hacked, and 39% thought their provider would tell them (wishful thinkers).

The net is, take responsibility. Because if you think someone else is responsible, you’re setting yourself up. You may not be the “security guy” – that may be someone else’s “job.” But you can schedule a meeting, set up a committee, instigate a discussion – whatever – to build a plan, drive action, and make security a priority.

Think we’ve missed something? Feel free to comment or reply to let us know!

The Dome9 Security Team

It’s Here – Stone Cold Blacklisting [Updated]

Dave — Mon, 10 Dec 2012 18:03:47 +0000

It’s probably been our #1 most requested features, so we’re pleased to announce that Dome9 now boasts blacklists for servers securef via the Dome9 Agent.

Last month we unveiled our IP Lists feature, which lets you define lists of IPs that you can use in rules spanning multiple servers and clouds. Now, added to this, is the ability to create a blacklist – a set of IPs that prohibits traffic to/from one or more servers and clouds.

Many of you have been asking for blacklist support for a while now. It’s useful when you want to disable access to one or more servers from a specific set of IPs. For example, if you happen to notice suspicious activity in your logs from a rogue IP, or unauthorized access attempts to a publicly available login, you can create a blacklist in your Dome9 account and shazam – traffic from that IP is blocked indefinitely across all of your cloud servers.

Creating an IP blacklist is super easy. Simply go to the Manage tab and select Blacklist. You can define your list either in our GUI or as plain text. Once created, all of your agent-secured servers will automatically receive an update to block traffic from IPs in that list.

The Dome9 Blacklist feature is limited to 800 entries and is not intended to block the entire Internet. It’s currently available only for servers protected via the Dome9 Agent – support for AWS and HP Cloud is coming soon.

So what are you waiting for? Give our new blacklists a try – block your friends, enemies, colleagues – whomever you’d like. And, as always, let us know what you think!

P.s. Our new blacklist feature is just the start… Stay tuned for more exciting things to come as we make blacklisting automatic! ☺

New Dome9 Pricing Plans

Dave — Thu, 15 Nov 2012 18:26:26 +0000

As you may have heard, we recently changed our pricing plans. So we thought we’d take a minute here to explain what exactly has changed and why we did it.

What’s changed, and why?

Frankly, a lot has changed and for good reason! We changed our billing model from utility to flat-rate, we added a bunch of new plans, and we added an all new service for AWS power users called SecOps for AWS.

Changing the Model
First off, we’ve migrated from a utility-based billing model to a set of flat-rate, monthly plans. This means we no longer charge per server, per hour at the end of each month. Instead, we now charge a flat-rate monthly fee, paid at the beginning of each month, based on the number of servers, users/admins, and features you choose.

The new Business Cloud has several available plan options, including the:

Starter Plan – $19/month Secure up to 2 servers with 2 admins;
Growth Plan – $79/month Up to 8 servers and 4 admins, extended auditing;
Large Plan – $249/month Up to 25 servers and 10 admins, unlimited 2-factor auth;
XL Plan – $749/month Up to 75 servers and unlimited admins, priority support; and
Enterprise Plan Unlimited everything, Support and Service SLA & more.

Why’d we make this change? Predictability! Your infrastructure costs may be variable, but we don’t think your cost of security should be too. We want our customers to know in advance how much their security is going to cost each month, and let them select the plan (upfront) that best suites their needs. No ambiguity – just pure simplicity!

SecOps for AWS
Secondly, we’ve introduced a new service offering called Dome9 SecOps for AWS. This is a powerful new tool for managing large-scale AWS environments across multiple regions and/or accounts, including EC2 and VPC environments. It provides an array of AWS-specific features, and is priced based on the number of regions and features, not the number of instances.

Just like the Business Cloud, the SecOps for AWS plans are paid at the beginning of each month. However, unlike the Business Cloud, each SecOps plan supports an unlimited number of instances and is based on the number of regions – as the following SecOps for AWS plan names indicate:

SecOps R2 – $249/month Unlimited instances across 2 AWS regions/accounts;
SecOps R5 – $749/month Unlimited instances across 5 AWS regions/accounts; and
SecOps Unlimited Unlimited instances and regions. Support and Service SLA and more.

We’ve introduced the new SecOps service to provide AWS-specific features for AWS-specific environments, where customers typically have less foresight into the number of instances that’ll be online in any given month (e.g., bursting into AWS). The new SecOps service is tailor-made for AWS power users, with features specific to developer and production driven EC2 and VPC environments.

Limits on Free
Third, we’ve limited our free, Lite Cloud, to 1 user / admin and up to 5 servers. We want everyone to have Dome9 for their cloud servers, and there’s plenty of value in our service to justify a small monthly fee for commercial use. And that’s exactly what the new plans aim to do – provide a free plan for personal use (i.e., 1 user), and a flexible set of paid plans for business use.

So that’s that. If you have any questions, check out our pricing FAQ, or drop us a line at accounts@dome9.com.