[NOTE: This Post was continued from Part 1 at VMware SMB Blog]

According to Gartner, midsize businesses[1] account for nearly 40 percent of U.S. server sales.[2] Unlike large enterprises, these organizations have fewer resources to support the deployment and maintenance of new servers in existing IT environments. With the goal of optimizing their entire IT infrastructure, midsize businesses are turning to virtualization.

No longer limited to enterprises with big IT budgets, virtualization has proven to lower IT costs while improving IT agility. Yet, as midsize organizations embrace virtualization, they must also be prepared to address specific IT risks, challenges and opportunities, such as manageability, protection against attacks and unpatched vulnerability exploits in virtualized environments.

In this two-part series, executives from VMware, the leader in virtualization and cloud infrastructure solutions, and Trend Micro, the global cloud security leader, address how midsize businesses can overcome common IT management and security challenges associated with newly virtualized environments.

Brandon Sweeney is Vice President of U.S. Mid-Market and Small Business for VMware.

Dave Asprey is Vice President of Cloud Security at Trend Micro.

Q:   How do virtualization and security solutions for midsize businesses differ from those for large enterprises?

A:    Asprey, Trend Micro: The truth is, they don’t very much in capabilities, but they do vary in size. We put together offerings that are scaled specifically for midsize businesses. As those organizations leverage the power of IT to grow, they often become larger companies, and along the way, they can scale their virtualization and security. One of the benefits of virtualization [ng1] is that you can add more power to a virtual machine as needed, or you can add virtual machines when you need them. This lets midsize businesses get enterprise-grade performance, availability and security, but purchase it as they need it.

Sweeney, VMware: Whether a business is booming or just starting out, technology can be a tremendous differentiator. Midsize businesses want and need the same availability, performance and security for their IT infrastructure as their enterprise peers, but they don’t necessarily need the same scale, and their systems must be easy to manage. Getting enterprise quality at SMB scale is important, which is why we provide solutions that help midsize businesses keep IT up and running, securely, while enabling them to better balance IT resources with demand and increase agility to quickly respond to new business requirements. And we offer our solutions in easier-to-deploy-and-manage configurations.

Q:   What is one piece of advice that you would give to midsize businesses considering virtualization?

A:    Asprey, Trend Micro: Do it right the first time, with full realization that once you virtualize with VMware and Trend Micro, [ng2] you’ll easily be able to add layers of automation and security that put you on the path to creating a very secure private cloud, and it sets you up for using public clouds safely when you decide to do that.

A:   Sweeney, VMware: Deploy a proven solution that doesn’t lock you in. A flexible and scalable solution will provide you with the foundation you need today and give you freedom of choice if and when you decide to extend your IT infrastructure to the cloud. The right solution will better protect your business while helping you simplify IT and save. And work with industry leaders that partner to provide you with

• The most mature and comprehensive technology solution
• Built-in high availability for all your applications
• Unmatched reliability and security
• The fastest and easiest installation

Q:   What advice would you give midsize businesses that have already begun to virtualize their environments?

A:    Sweeney, VMware: Look beyond cost savings and server consolidation. Take a comprehensive look at virtualizing your infrastructure and applications—including security and management—to increase IT efficiency and agility. Check out the first security and operations management bundle for virtualized environments. This joint solution for midsize businesses is the gold standard for virtualization. Offered from VMware and Trend Micro, it provides best-in-class virtualization performance and capacity management together with a next-generation server security platform designed for virtual environments. The benefits: faster management, better security with less risk, and more uptime with fewer outages.

A:    Asprey, Trend Micro: Don’t stop. Adding virtualization is just the beginning. As you increase your use of virtualization, your business agility will increase. You can get more done in less time, and IT cycles become shorter, which leads to increased demand for your IT department to enable projects that do more than just support the business. Along the way, as you keep building security in to your virtualization strategy, you’ll find it’s a natural evolution to start using the cloud.

If you have a midsize business, you can learn more about virtualization at http://www.vmware.com/solutions/company-size/smb/ or www.trendmicro.com/mbvirtualization .

Share/Bookmark

The Cloud Security Alliance recently released a white paper on cloud computing vulnerability incidents spanning the last five years. They looked at more than 11 thousand news articles regarding cloud computing-related incidents to determine the top reasons behind outages. Did you know 64 percent of the outages can be attributed to one of three causes:

• Insecure Interfaces & APIs
• Data Loss & Leakage
• Hardware Failure

If you are developing an application for the cloud or deploying software in the cloud, there is good news: There are some key ways to avoid the majority of outages.

First, ensure you create strong policies and protect your credentials for the cloud APIs. We discussed how to do this with Amazon Web Services in an earlier post. The same advice applies to all of the cloud service providers. Next, secure every external interface from your cloud applications (both web applications and APIs) to protect against a variety of injection, privilege escalation, overflow and other attacks. Prevent data loss and leakage by implementing strong identity and access control to your cloud application and between nodes of your application.  Another way is to confirm all data, whether in motion or at rest, is encrypted to hide it from prying eyes. Lastly, and most importantly – cloud or not – hardware fails! Design your applications to use multiple instances, availability zones and regions for every tier of your application. Some cloud providers offer load balancing, clustered computing and high-availability data storage solutions to make this much easier.

To read the paper from the Cloud Security Alliance and find out more about the working group, visit here.

At Trend Micro, we are committed to cloud security. One of the ways we help is by being involved in organizations like the Cloud Security Alliance through our corporate membership and many individual contributors on working groups. The other is by providing the best products and services to secure your journey to the cloud. Deep Security and Secure Cloud can help you take the next step. We have also recently announced our new Deep Security as a Service for AWS and we encourage you to sign up and see how easy it is to secure your cloud applications with our free trial.

Share/Bookmark

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