If you still believe that your systems management consoles should be running on servers in your data center, you’re definitely from the pre-cloud era. Even if you believe your systems management and security consoles should be running on infrastructure as a service instances you control, you’re also out of date.

The evidence is in, and your control systems should absolutely reside in the cloud, even if the systems they control are not in the cloud. Cisco’s recent acquisitions are a reminder, and so is this week’s launch of Trend Micro’s new Deep Security as a Service that secures AWS instances.

Cisco just provided a reminder about the growth of  cloud management in the enterprise by recently reporting their second quarter fiscal 2013 earnings, which showed a massive push to grow their data center business. One of the unique highlights of the quarter for Cisco was their $1.2 billion acquisition of midmarket networking vendor Meraki (they build cloud managed wireless and wired access points as well as provide network acceleration and security capabilities) which was first announced in November of 2012.

Meraki developed an incredibly compelling cloud managed networking solution – enough to be named a Gartner Magic Quadrant Visionary – that will greatly aid Cisco in its exit from the home networking market and its intention to increase its presence in the networking mid-market. With Meraki’s product, an enterprise has the ability to centrally manage everything related to their network in the cloud from a single portal. This gives the enterprise complete control over all users, applications, and devices and means that there is no longer any controller hardware or management software to install and maintain. This secure cloud infrastructure can scale to million-user deployments and eliminates the need for administrators to configure devices by logging in to each one directly.

If a trend is big enough to be worth a billion dollar acquisition, it’s beyond the early days. Since I joined Trend Micro almost 3 years ago as its cloud technology evangelist, I’ve been pushing the idea that control systems are safer and higher availability when you put them in the cloud, compared to where most of them sit today in enterprises. This is doubly true for security systems.

That’s why I’m incredibly excited that this week Trend Micro is formally announcing Deep Security as a Service. It protects Amazon Web Services instances with a security console that is hosted, managed, and updated in real-time by Trend Micro.

Security and management control systems work exceptionally well in the cloud, as we have heard for years, and with Cisco’s Meraki deal and Trend Micro’s announcement, we are seeing the next stage of the evolution.

Remote management is something, you may recall, that Cisco had some very significant, and very public issues with – the company’s customer base erupted when Cisco chose to update its home Wi-Fi routers to use a web-based service, which in turn stoked privacy fears.  People revolted because Cisco owned the portal and gave its users no local option to update the firmware.

Unwarranted cloud fear, I say. Cisco just didn’t handle the communication very well. Had they explained to end-users that they would get a faster, more responsive, and better service, people would have adopted the service in droves. The very same people who complained about managing their routers from the clouds are already using email that runs in the cloud, which represents a much greater privacy risk.

This was such an issue that it gave Cisco cause to pull back and reevaluate just how they were going to deploy their cloud based service that integrated into its residential/home routers. Obviously, bringing Meraki into the fold has been part of the strategy to not only be a major player in the enterprise business market, but also have the technology and capability in house to prevent such fiascos in the future.

Furthermore, Meraki’s technology far transcends just a plug for Cisco. The new acquisition has been transformed into Cisco’s new Cloud Networking Group and will serve as the foundation for the its planned, larger cloud networking offers, and an aid to ‘cloudify’ numerous products already in Cisco’s enterprise networking portfolio.

There is no question in my mind that in the very near future, we will see Software as a Service networking management tools like Meraki’s, and security tools like Trend Micro’s, quickly evolve into the only way we manage our networks and security. Yes. The only. It just makes too much sense from every perspective of systems management.

Management systems for devices are subject to release cycles that are slow, whereas Software as a Service offerings deliver weekly release cycles. By deploying a SaaS service in your enterprise, you are assured to get a regularly updated system, and your networking and security vendors will deploy their development assets to their core functions, rather than supporting ancient versions of their management tools on random platforms.

Meraki’s (now Cisco’s) tools are transformative in how they will revolutionize the work of the network administrator. The new Deep Security as a Service offering will revolutionize the work of securing the cloud.

As an IT professional, you should be deploying your time and attention to maintaining and securing systems in the cloud, not to maintaining and securing the control systems for systems in the cloud. It is not worth your time, and it significantly slows your vendors ability to create responsive systems that actually protect your assets in the cloud.

Share/Bookmark

Over the past weeks we have been reviewing the top 10 tips for securing instances running on Amazon Web Services. We walked through the critical controls as part of the AWS shared security model. As noted in these tips, host-based security capabilities such as intrusion detection and prevention, anti-malware, and integrity monitoring are critical for protecting your applications and data.

While some of these recommended tips involve configuring and tuning AWS itself, some require the use of third-party tools. So when looking for candidates for securing your cloud projects, here are five questions to ask potential vendors:

1. Are newly created instances automatically recognized? One of the benefits of the cloud is also one of its biggest challenges: elasticity. Often instances are automatically created, for example, in response to increased load. If those automatic instances are not also automatically protected, you can be left vulnerable.
2. Does your policy speak AWS? All instances are not the same, and the security policy may vary depending on the type and purpose of the instance (for example, database versus web server). The policy engine needs to understand the information being served through AWS, and apply appropriate policies accordingly.
3. Will I need to change my deployment process? A variety of commercial and open source deployment tools are used in managing today’s AWS deployments (RightScale, Chef, Puppet, CloudFormation, to name a few). Being required to change those processes to fit security solutions means time, expense, and the potential for something to go wrong in the deployment process.
4. Can I manage my security in one place? Having to manage multiple security policies, alerts, dashboards, etc… is both time-consuming and complicated – and increases the risk of missing key information that can impact the security of your deployment.
5. Am I considered to be on the ‘bleeding edge’? It is great to be an early adopter, but not if doing so risks the security of your cloud deployment. Make sure the technology being used to secure your instances is established, and that the policy templates provided have already been proven in real-world deployments.

What challenges are you seeing in securing AWS? Let us know in the comments!

These questions highlight one of the challenges in securing AWS deployments: finding proven technology delivered in a way that takes full advantage AWS. That’s why we are so excited to announce that our Deep Security as a Service for AWS is now available. Based on Trend Micro’s proven Deep Security product, the service runs on AWS and is specifically designed to provide the range of security capabilities to protect AWS instances. So you can set up your account and secure your AWS instances, literally in minutes.

You can check out and explore Deep Security as a Service by signing up now for a full, free trial at deepsecurity.trendmicro.com.

Share/Bookmark

Amazon Web Services did it again. Its new service, OpsWorks, is an application management service with the ability to manage applications of any scale or complexity in the AWS cloud. This integrated system manages resource provisioning, configuration management, application deployment, software updates, and monitoring and access control.

The service is another offering from the leader in cloud computing poised to disrupt a market, in this case, Platform as a Service (PaaS). OpsWorks will compete directly with PaaS mainstays Heroku, Engine Yard and AppFog. Given the speculation that AWS is working on a graphical interface to ease complex deployments, systems integrators and consultants, who traditionally worked with administrators on such deployments, may also be affected.

Functionally, AWS OpsWorks enables developers to use ‘layers’ which serve as structures for whatever instance a developer deploys. Every instance deployed by AWS OpsWorks “must be a member of at least one layer, which define an instance’s role in the stack and manage the details of setting up and configuring the instance, deploying applications, and so on.”

While the AWS OpsWorks console only permits an instance to be a member of one layer, using the AWS OpsWorks API gives the option of letting instances optionally be a member of multiple compatible layers. For example, if you wanted to use on of your application servers for administration, you could create a custom administrative layer and add one of the application server instances to that layer. The administrative layer’s recipes configure that application server instance to perform administrative tasks, and install any additional required software. The other application server instances are just application servers.

Operational control, automation, and flexibility are central to the OpsWorks offering. For a developer to define and deploy apps, all he has to do is instruct OpsWorks where the code resides and the service takes it from there, handling deployment tasks such as database configuration. Because OpsWorks uses the Opscode Chef framework, developers can use existing recipes or choose from an extensive offering of community-built configurations.

Did I mention that Trend Micro’s Deep Security service runs on AWS and is best set to be deployed automatically by Chef, which works with OpsWorks?

Werner Vogels has a detailed post that outlines both OpsWorks and the general AWS strategy. Amazon first rolled out its core services of storage database and computing and then added advance offerings such as DNS, messaging, etc., and now receiving management tools. OpsWorks is an important next step in revealing the AWS approach to the development of their service offerings. OpsWorks is a solid management tool that increases user options significantly, and adds to AWS’ growing number of different Application Management Services. It looks like part of a greater push to garner wider enterprise adoption, as confirmed by this recent article.

Old Cloud gurus know that OpsWorks was invented in Germany and is based on the Scalarium technology of Peritor. Scalarium was bought in 2012 by Amazon.

Share/Bookmark

In last week’s post, we gave a high level overview of vulnerability assessments. This type of assessment results in a prioritized list of vulnerabilities in your deployment. It’s an excellent first step in knowing the state of your deployment.

The next step you should take is to conduct a penetration test.

The Test

A penetration test (or simply, pentest) is an active test of your defenses. You’re hiring a trusted 3rd party to attack your deployment in order to find exploitable vulnerabilities. The theory is that it’s better to have someone working with you do this before a malicious attacker can.

The test report is going to provide detailed information on how the attacks were conducted, what was successful, how defenses could be improved, etc.

Setting up a Test

Pentests can vary greatly depending on their goals, your deployment, timelines, etc. A few key tips for organizing a pentest on AWS include:

1. Use a trusted 3rd party to conduct the test
2. Give AWS a heads up
3. Establish a time frame but not a testing time

Trusted 3rd Party

While you might have the skill set on your security team, it’s usually best to have a trusted 3rd party conduct the penetration test. Penetration testing is as much an art as a science. A good penetration tester is going to be able to ferret out issues with your deployment that you never saw coming.

If you use an internal resource, they will approach the test with a biased mindset. The most typical issue that surfaces is that an internal resource will either attack the most common–and well known–weak spot or avoid that option entirely. Either way, that type of test is not a close enough simulation of a real attack.

A trusted 3rd party will approach the test methodically. Working through your exposed attack surface gradually finding issues with your deployment and mapping your exploitable vulnerabilities.

Give AWS a Heads Up

AWS requests that your provide them with notification before any vulnerability scanning or penetration testing is done. They provide a convenient form to help make that process as easy as possible.

As part of the form, AWS requires:

• information about the instances to be tested
• the time frame for the testing
• agreement with their terms & conditions
• appropriate use of the tool set used during the test

Completing the form only takes a few minutes and will save a lot of headaches. Be sure to take the time to fill it in with the details of your test.

Establish a Time Frame

The first time you have a pentest done, it’s extremely tempting to provide a specific time at which the test will be conducted. In fact, that’s one the pieces of information that AWS requests up front.

Within reason, keep this information compartmentalized. Don’t tell your security team, your ops teams, or support.

Why not? Because if any of the teams normally involved in incident response knows about the test ahead of time you won’t be testing the right things.

The ideas behind the pentest is to measure you current security posture at any given time. If everyone knows ahead of time that they’re going to be tested, they are going to prepare ahead of time. While you may look better on the test report, you’re doing yourself a disservice.

When a real attack happens, no one calls ahead.

The Report

So your “attacker” has tested your defenses and found a few holes. Maybe they’ve even been able to breach all of your defenses and gain access to key customer data. Don’t panic. That’s OK. This is the whole reason you run a pentest. It’s much better to have your known testing attacker reach your customer data than an unplanned attacker with actual malicious intent.

At the end of the test, you should receive a comprehensive report detailing the results. This should include:

• how far the tester was able to breach your defences
• details of the vulnerabilities exploited
• suggestions for mitigating these issues
• another other issues found or observations of the tester

Even though it may be hard to read the results, take them to heart. Work through each of the issues raised in turn and fix the problem. This is the crucial step. You have to take action on the results.

Stronger Than Before

After you’ve worked through the issues raised in the report, your defenses should be stronger than ever. Better yet, you know your defenses work. They’ve been actively tested.

While no security is perfect, by following the tips in this series you can be confident that you’ve taken reasonable steps to ensure that only the most determined attackers are going to have a chance at breaching your defenses.

How do you handle penetration testing in the cloud? Please share your tips in the comments! And if you’re interested in securing your EC2 or VPC instances, check out our new Deep Security as a Service for cloud servers, currently in free Beta.

Share/Bookmark

As a Product Marketing Manager for Trend Micro™ Worry-Free™ Business Security Services, I hear a lot of objections about the product, and in particular, a lot of cloud-related fears. Some examples of things I hear from customers and partners are:

“I wouldn’t be secure if my Internet connection went down.”

“I don’t want to put all my data in the cloud.”

“I don’t want to waste all my bandwidth, uploading everything to the cloud to be scanned.”

The cloud is becoming better understood by the average person these days, thanks to companies like Google, Apple, Netflix, and other consumer-oriented companies that have spent a lot of marketing dollars. They are helping their customers understand cloud-related products, and how those products are delivered. Fortunately, this knowledge spills over nicely to small business owners and employees who are consumers of these cloud-based services at home.

I don’t want to get in to a deep technical explanation, but for the purposes of this article, it will help you to understand the architecture of Worry-Free Business Security Services. It is an endpoint security solution, purpose built for small and medium businesses (SMBs) to protect you and your data on these three types of devices: Windows, Mac, and Android. There are two components that make up this solution.

The first component is what I call the management console. It is what you would use as an administrator to manage the product, configure policies, review log files, run reports, and do any day-to-day tasks related to the product. The management console physically resides in a highly-secure Trend Micro data center.

The second component is called the client. It is what gets installed on each device (Windows, Mac, Android) and is responsible for providing the actual protection of the device. This component handles the scanning of files, blocking of malware found, and reporting of results to the management console.

“I wouldn’t be secure if my Internet connection went down”

Now that you understand the architecture, it should be pretty easy to see why this objection is not a valid one. Logically speaking, if all the security is provided by the client that resides physically on the device, how can you possibly be less secure without an Internet connection? The answer is, you aren’t less secure. Everything the product needs to protect your device is on the device, no Internet connection required.

“I don’t want to put all my data in the cloud”

Since the management console is physically located in the cloud, there is a minimal amount of information residing in the cloud. So on the surface this may seem like a valid objection, depending on how you define “all my data.” The only information that does get saved in the cloud is log data generated by the client, and any additional comments/notes added to the console by you, the administrator.

The product does not copy any of your existing items, such as documents, spreadsheets, files, etc. and move them to the cloud. Bottom line, none of your stuff is moved to the cloud. We only store data about detected malware such as time stamp, computer name, virus name, and other relevant metadata in the cloud.

“I don’t want to waste all my bandwidth uploading everything to the cloud to be scanned”

Going back to the architecture discussion, I mentioned that all of the protection is provided by the second component, the client, which is physically located on the device. All the scanning, analyzing, and remediation are done on the device so this objection is not valid.

The product does have some innovative technologies such as Smart Scan that leverages updates delivered from the cloud. However, ironically, these features actually result in less bandwidth utilization, not more. Files that are being scanned never leave the device and are never uploaded anywhere, including the cloud.

Are you still scared?

In summary, there is really no reason to be scared of the cloud as it relates to a security solution like Worry-Free Business Security Services. It does not depend on an active Internet connection to provide maximum security, nor is your data “taken” from you and stored in the cloud.  And it doesn’t shuttle your files out to the cloud and back to scan them because it is all done locally.

Share/Bookmark

In this series, Mark and I have talked about hardening your AWS resources (both inside and outside of your instances) and preforming ongoing monitoring. The last two tips are around measuring your overall security so that you can understand your risks and measure your progress.

It may be an old adage but it still rings true… You can’t manage what you can’t measure. You may have layer upon layer of defense, but unless you conduct a vulnerability assessment you don’t really know where you stand.

Assess Your IaaS

Conducting a vulnerability assessment includes identifying and prioritizing vulnerabilities in all areas of your system. You start by cataloging the vulnerabilities through a mixtures of tools, services and manual evaluation. Then you move on to prioritizing the vulnerabilities and evaluating ways of mitigating.

Tools and services often take two forms, network scanners or host-based. Within these two forms there are passive and active scanners. Some vulnerabilities can only be detected on the instance or with privileged network access.

If you are running a network scan against your AWS instances, you need to fill out the AWS Vulnerability / Penetration Testing Request Form. This way, AWS knows you will be conducting a scan and your connectivity won’t be disrupted.

Feeling Vulnerable?

Once you know where you stand, its time to work towards improving your security posture. You start with the most serious vulnerabilities and work your way down the list.

Remediation can take many different forms. It may be as simple as closing a port, or turning off a service. In other cases it requires a software patch or a rule from an intrusion prevention system. No matter how you remediate, it is important to verify that remediation is in place and protecting the vulnerability.

The number of unmitigated vulnerabilities in your application makes a great metric to track over time in order to understand if you are continually improving.

Stay tuned for the next (and final) tip where we look at another important way to evaluate your security.

Have any tips for how you conduct vulnerability assessments on AWS? Please share them in the comments! And if you’re interested in securing your EC2 or VPC instances, check out our new Deep Security as a Service for cloud servers, currently in free Beta.

Share/Bookmark

Remote management module (RMM) vendors frequently offer an integrated security solution with their core product. But how does the security featured in these integrated products compare? In a previous blog, I wrote about the five questions to ask your RMM vendor about integrated security offerings. Now, here are five more questions to make sure you know what’s covered and what isn’t in these solutions.

What is the process for acquiring licenses for an integrated security solution?

Sometimes you are required to make significant up-front purchases of security solution licenses in order to get specific pricing, or simply because they are sold in blocks and you don’t have the flexibility to increase and decrease your license count on-the-fly to match your business needs.

Separate from the pricing and any up-front costs, how do you obtain those licenses? Do you have to place an order through your RMM vendor and then wait a period of time until they can supply those licenses, because they – in turn – have to request them from the security solution vendor? What happens if you are doing a new roll-out on the weekend and you didn’t initiate that process in time? Can you get licenses on demand, 24x7x365?

What is the process for obtaining support for the integrated security solution?

RMM vendors aren’t the most qualified to support a security solution due to their lack of knowledge and expertise (which is expected since they didn’t build the security solutions). So how do you get support? Can you contact the security solution vendor directly? Or do you have to submit tickets/cases through your RMM vendor and wait for the escalation process to get to the security solution vendor? What is the average response time you can expect when you open a case? And more importantly, how long will your customers have to wait?

How long is your contract with the security solution vendor? And what happens when that contract expires?

Just like in your business, where you negotiate term-based contracts with your customers, RMM vendors negotiate contracts with security solution vendors that have a term associated with them. It’s important to be aware of the implications if that term happens to expire and the RMM vendor decides not to renew it, and switches to another security solution.

Will they renew the contract with no impact to you? Or will they decide to partner with another vendor? And what does that mean for you and your customers?

If you change the integrated security solution, how does that impact me?

Unfortunately for you, if your RMM vendor decides to switch security solutions, you will most likely be forced to follow suit. This means despite all the effort you spent deploying the security solution in the first place, you will have to do it again.

Don’t expect any help from the outgoing security solution vendor either, as they have no incentive or motivation to make that process easier for you. There’s also the challenge of re-training your entire staff on the new solution. How much time is that going to take? And what impact will that have on your bottom line? What will the RMM vendor do to mitigate that impact?

What happens if you get acquired, consolidate, or go out of business?  Are my customers still protected?

The RMM market is extremely crowded, with at least 30 different companies offering a similar product with similar functionality. All are vying for a piece of the MSP market that is on a rapid upward trajectory.  These are ripe conditions for consolidation, acquisition, and – in some cases – closing up shop.

If your RMM vendor is the victim of one of these events, the integrated security solution they offered may become a casualty.  Contracts may not carry over or be honored by the acquiring entity, or the acquiring entity may have a relationship with a different security solution, forcing you to rip out and replace everything.

If your RMM vendor goes out of business, don’t expect the integrated security solution vendor to keep providing the security solution at the same price, or at all. What assurances does the RMM vendor have in place for this situation?

With these questions in hand, you should be prepared to learn all you need to know about the integrated security in RMM solutions. Have others that we should add to this list? Let us know in the comment section below!

Share/Bookmark

“Software defined” is the latest buzzword in IT and cloud. Some people hate it because marketers are jumping on ”software defined” almost as fast as they jumped on the word “cloud” years before they had real cloud products. Cloudwashing was a real phenomenon, and it was easy to say. “Software Defined Washing” just doesn’t roll off the tongue the same way, and it implies IP-enabled virtual laundry.

Here is an explanation of why you should embrace the term (I like it even more than cloud) and a view what we called it before “software defined” became in vogue.

In vogue it is. VMware likes “software defined” so much that they bought SDN vendor Nicira for the Software Defined Data Center. EMC is all over Software Defined Storage. My friends at Arista Networks talk about Software defined cloud networking and may well have been the originators of the SDN term. (If I’m wrong and you know who invented the term, please tell me – @daveasprey)

The truth is that the idea is not new. Here’s what we used to call “software defined”.

Policy based whatever

In 1999, I co-wrote a 350 page book called “Business Class Internet” for Prentice-Hall that never got published thanks to the dotcom bust. In it, I wrote extensively about how policy-based and policy-driven architecture was required for the Internet to reach the levels of availability and security that enterprises expect. Network engineers have been talking about policy and policy-based architecture for more than a decade now. VLAN policies are even today a fundamental part of keeping cloud networks segmented.

The difference between software defined and policy-based is… marketing. Then again, marketing matters enormously. The proto-cloud service I created years ago at Speedera (now Akamai) was called “flex computing” because I didn’t have the marketing smarts to think of the word “cloud.” At the end of the day, it did exactly what infrastructure as a service clouds do: provision new instances based on rules or policies. But it had the wrong name!

In the current software defined world, no one has a nausea reaction when they hear software defined, but at some level the word “policy” is neurologically linked to unthinking, inflexible bureaucracies and slow-moving systems. The truth of the matter is that policies are amazing, as long as you are the one who gets to write them. But let’s wisely discard that term, as Arista has, because it doesn’t work. Software-defined it is.

Software Defined Software

Back in the day (i.e. 1994), CASE tools were all the rage (Computer Aided Software Engineering). If you ever had the displeasure of working with such tools, they allowed you to define very high level software policies, which the systems would then (hopefully, if you wrote very careful policies) compile into high-quality, defect-free, and maintainable software products.

Look at Opscode Chef, which AWS is uses for automation, and Facebook also uses. It reminds me of computer-aided software engineering. You simply define cloud deployment policies, and the systems get deployed as high quality, defect-free, maintainable cloud services. The difference between automatically deploying a complex system across tens of thousands of instances and automatically creating and then compiling code to work with millions of logic gates is not large. Orchestration offerings like VMware’s vCloud Director are another example – you can set policies to configure virtualized compute, networking, storage, and security automatically.

As Trend Micro’s cloud security guy, I feel obligated to point out that my company’s Deep Security ties in to vCloud and Chef so you can automatically build security into cloud environments as they are provisioned in a software defined world.

As long as it’s easy to create policies, manage policies, and enforce policies in the system, it doesn’t matter if you call it “software defined,” cloud, orchestrated, policy based, CASE, or something else. Just don’t create extra security and availability problems caused by human error or waste time doing things manually, and it will be a better IT system.

In all these cases, you need a system to manage the system. And that is the essence of “software defined.”

Share/Bookmark

Last week, we tackled the basics of monitoring your AWS deployment. This week we’re going to shift gears and take a look at encryption.

Data Drives Your Business

Your business runs on data and information. One of the biggest concerns about moving to the public cloud is the safety of that data. With a little due diligence, you can put those concerns to bed.

There are three key steps to protections your data in the cloud:

1. Identify and classify your data
2. Protect your data at rest
3. Protect your data in motion

Identify & Classify

You can’t take steps to protect your data until you understand what you have, what it’s worth to you and your customers, and where it’s stored and processed.

Looking at your network, what type of customer data do you store? Any intellectual property that gives you a competitive advantage? Access credentials for your systems?

Start by taking an inventory of your data.

Now, go through that inventory and try to prioritze the data. How important is it to your customers? Your business operations? Your reputation? You don’t need hard values for the data, just a rough idea of what’s important to your business.

Once you have that list, track down where and how you store that data and where it is processed. These are the areas you should focus on securing first.

Protect Your Data At Rest

How you protect your data at rest depends heavily on where you store it. If you’re storing your data as files on a drive, you can either encrypt the entire drive or encrypt file-by-file. If your data is stored in a database, you can either encrypt the entire database or encrypt value-by-value.

In both scenarios–file or database–your choice really boils down to:

1. Encrypt the underlying storage so everything get encrypted automatically
2. Encrypt each piece of data as it’s stored

From a usability perspective, the less you need to worry about encryption for day-to-day operations, the better. This usually leads to the encryption of the underlying storage. However this can also impose a performance penalty on your deployment.

A quick note for S3 users; you can either either use S3 server-side encryption or AWS’ envelope encryption feature to help encrypt your data.

Regardless of the solution you choose, it’s important to test which ever method you choose to ensure that it meets both your security and performance requirements.

Protect Your Data In Motion

While protecting your data at rest involves some performance testing and hard decisions, protecting data in motion doesn’t. Use encrypted communication channels throughout your deployment.

Use SSL/TLS for any HTTP traffic (that’s the “S” in “HTTPS”) with a validate certificate from a trusted 3rd party¹. If you’re deployment isn’t using HTTP as a transport, find the encrypted equivalent for the protocol you use.

The performance impact of an all encrypted communications channel in negligible. There is no reason not to use an encrypted transport.

Protect Your Data Everywhere

Encryption can be a tricky subject to address but there’s no need to be intimidated. Take an inventory of your data, prioritize it by value. Work through the inventory applying the appropriate level of encryption to each data store in turn. Make sure that all communications within your deployment are encrypted.

Taking these simple steps will greatly increase the security of your data at rest and in motion.

What do you do to protect your sensitive data in the cloud? Please share your tips in the comments! And if you’re interested in securing your EC2 or VPC instances, check out our new Deep Security as a Service for cloud servers, currently in free Beta.

¹Full disclosure, Trend Micro is in the SSL certificate business but a certificate from any trusted 3rd party will get the job done. A quick search for “SSL certificate vendors” will turn up quite a few possibilities.

Share/Bookmark

Remote management and monitoring (RMM) vendors often offer an integrated security solution with their core product. But how does the security offered by these integrated options compare? Below are the questions to ask your RMM vendor to make sure you get the full picture of the security being offered.

1. Is the security solution included with the RMM platform really free?

RMM vendors and security solution vendors are for-profit businesses and are not going to make money by giving something away for free. While the security solution may be advertised as free, the most likely scenario is that the cost is baked into the total price of the RMM platform – and you are paying for it, whether you use it or not.  Don’t be surprised if your RMM vendor gives you a lower price for the RMM platform if you ask them to remove the security solution from your license.

2. Does the security solution have all the same features as the standalone solution? What is missing/different?

Contrary to popular opinion, security solutions integrated in to an RMM platform are not the same as the product you could buy directly from the security solution vendor. In most cases, the “integration” is a complex set of scripts combined with some HTML/CSS that acts as a wrapper around the security solution that leverages limited command-line functionality built into the core product.

What this means is that you are either managing a solution with stripped-down functionality (because they don’t make every single option available via the command-line), or the security solution vendor had to purpose-build a different version/product specifically for the integration, which means it won’t have all the same features as the standalone product because that’s too much work for them.

This also means that it probably won’t have the same priority for patches/hotfixes/upgrades as the standalone version, since a lot more customers use the standalone products than the ones integrated in to your RMM platform.

With five new threats discovered every second of every day, make sure you know if your security solution may make you wait days, weeks, or months for an integrated solution fix/update/upgrade to provide the same timely coverage as the standalone product.

3. Does the integrated security solution work on all the devices I manage (servers, workstations, laptops, Macs, Androids)?

Some security solutions that integrate with RMM platforms may lack the broad platform support provided by more robust security solutions. There have been instances in the past where an integrated security solution only worked on workstations/laptops and not on servers. This meant you went without coverage (bad idea) or you had to use a separate security solution, thus completely negating the “single pane of glass” benefit you signed up for in the first place!

Additionally, the technology landscape is changing quickly. You need a security solution that can protect all the devices your customers are allowing their employees to bring into their work environment (aka BYOD), such as Mac laptops and Android devices, along with traditional Windows servers and workstations. It’s important to make sure the integrated security solution can protect all of these devices, or else you once again lose the “single pane of glass” benefit.

4. What features does the integrated security solution offer? And how does it compare to industry-leading standalone security solutions?

It may surprise you to learn that when security solutions were originally integrated in to RMM platforms, they were usually the free options available on the market at the time. Financially speaking, this makes sense in a low-margin, fixed-fee business model where it is important to find every way to save that you can to maximize profit. However, RMM vendors and MSPs quickly realized the truth in the old adage, “you get what you pay for.” Soon they moved away from integrating the free options towards the low-cost options.

Today, the integrated security solutions in RMM platforms are a broad spectrum of the low-cost options on the market. This generally means they lack the features found in the industry-leading products. It is important to understand:

1. What’s missing
2. What you are going to have to pay extra for
3. That you’re going to need to augment with another tool from another vendor (and use another management console for) to provide the maximum level of protection your customers demand

It is no longer good enough to just offer basic antivirus. Does the integrated solution offer advanced reputation-based protection? And do they provide additional integrated features like URL Filtering, Behavior Monitoring, POP3 scanning, Firewall, Mac, and Android protection?

5. Why do you offer both an antivirus solution AND a separate anti-malware/spyware solution? And do I have to pay for both of them separately?

A number of RMM vendors have been forced to add secondary security solutions to their platform because the primary one may be lacking in some way or another. These products are generally divided between antivirus functionality and anti-malware/antispyware functionality. Don’t expect to get both of these for the same low price you were originally quoted, and make sure you ask how much it will cost you for both solutions.

If two solutions are offered, there is a reason for it (read: the first solution isn’t good enough on its own). So consider it a warning that your costs will go up or your security coverage will suffer.

If you don’t buy that second solution, expect to be rolling trucks to your customer sites to clean up those nasty infections that can’t be cleaned remotely because you have to boot in to Safe Mode to clean them up. Expect to lose some customers too when they are either crippled to the point that they go out of business, or they get tired of your technicians coming onsite to clean up what the first security solution missed.

What are your concerns with integrated security in RMM solutions? Let us know in the comments!

Share/Bookmark