Web applications are an important part of your business and a vital part of how customers interact with you. Unfortunately, web applications also give attackers another gateway into your critical assets and data.

In fact, web application attacks have more than tripled since 2014, making them the leading cause of breaches. 

Web app attacks have more than tripled since 2014, making them the leading cause of data breaches. Learn how to protect your data from malicious web app attacks and close gateways to your organization’s critical assets with this infographic.

While these statistics are alarming, with a comprehensive security plan customized to your business’ needs you can safely protect your data.

INAP’s Shield Managed Security ensures your web applications are protected from every angle with enterprise-grade technologies backed by around-the-clock service and support from certified professionals. Powered by industry leading partner, Alert Logic, Shield is offered at three levels, offering a comprehensive security approach tailored to your needs.

Updated: January 2019

For most organizations, cloud backup and Backup as a Service (BaaS) solutions are quickly replacing traditional data backup solutions. Why the mass adoption? In this post, I’ll quickly detail the underlying reason for the shift, define the scope of BaaS and other cloud backup solutions, and provide a quick list of qualities you should look for in potential providers.   

The 3-2-1 Rule of Backups

Data is quickly becoming a company’s most valuable asset (besides its people, of course). And while many of us are backing up our data on-premise, there is more we can be doing to ensure our critical data has the redundancy and security it needs to mitigate an ever increasing risk landscape. 

As we covered in a previous post, on premise backups only go so far in protecting us from unforeseen downtime.  On premise backups are a start, but a more comprehensive strategy is needed. After a bit of searching for backup strategies on the web, you will likely come across a common term: the 3-2-1 rule.

Its meaning is a relatively straightforward: Store three copies of your data, two of them on different medium and one of them offsite. While this looks easy on paper, there are actually quite a few considerations that must be planned out to achieve such levels of protection.  

Does your current backup software allow you to protect physical and virtual machine data?  Does it have the ability to send data to an off-site repository?  Do you have to rely on tape backups and an external security service to come pick up physical tapes or drives?  Should you send our backups to AWS or Azure?  If you are asking yourself “Where do I even start?,” you’re in luck.  

Understanding Backup as a Service (BaaS)

With continued growth of services we consume through the internet, the “cloud” has given rise to numerous Cloud Service Providers who offer a wide variety of services to businesses and consumers. These “as a Service” products work especially well for organizations who lack the infrastructure or expertise to deploy such services in house. This includes Backup as a Service.  

Backup as a service (BaaS) is a strategy for backup and recovery that involves purchasing these services to be managed by a Cloud Service Provider. Instead of performing backup with centralized on-premises equipment and personnel, BaaS connects IT systems to a private, public or hybrid cloud managed by the Cloud Service Provider. Why worry about rotating and managing tapes or hard disks to get your data offsite, when data storage administrators can offload maintenance and management to the provider?  

With a Backup as a Service offering, many of the complexities of a varied backup strategy are offloaded onto the service provider.  In return, the service provider may charge a monthly rate depending on the level of service offered. Take the offsite repository for example. In order to get a copy of your backup data offsite, you would need to invest in IT facilities, hardware, and support personnel if you were to do it yourself.

Advantages of Cloud Backups and Backup as a Service

With a Cloud Service Provider however, the following list of benefits can be applied to your new backup strategy:

• No upfront investment in infrastructure or expertise needed
• Pick and choose from varying levels of managed services
• Store data in the cloud on enterprise-grade equipment
• Data is protected in secure facilities or data centers
• Guaranteed SLAs and support
• Access to technology for monitoring and automation

Use this list to evaluate different Cloud Service Provider offerings and make the best choice for your business.  Achieving a 3-2-1 backup strategy has never been easier thanks to Backup as a Service offerings provided by service providers like INAP!

Updated: January 2019

Medium-sized organizations face many of the same IT challenges as large enterprises, but with far fewer resources to solve them. One challenge, in particular, is how to approach the multicloud world we are progressively moving toward and operating within.

For CIOs, now is the time to get on the multicloud bus before their organizations are outpaced by the competition. This post explores important rules for considering the multi-cloud approach.

First, it’s important to understand that ‘Multicloud’ is not a thing, it’s a strategy. Your organization is likely already using more than one cloud service, but there’s also a good chance you have not thought through that usage in a meaningful way. These four rules should jumpstart that thought process.

Rule 1: Application First, Cloud Platform Second

Your applications are core to multicloud planning and strategy. Understanding your application landscape, the requirements of each application, how and when they need to run, and external services required to interact is the starting point. Here are some specific questions to ask about your applications before considering the cloud platform best suited to them.

• What interoperability is required?
• What compliance or governance is required?
• How much data does it produce/transfer?
• What deployment tools or services are required?
• What are the usage and load patterns?
• What risks are associated to operating the particular application on one platform versus another?
• What are the unit economics I need to measure?
• What level of automation is needed?
• What is the security strategy?

These are just some of the questions to consider about your applications prior to evaluating the potential cloud platforms to support and power them.

Rule 2: Pay Attention to Cloud Economics

All clouds are not created equal. This is true both from a feature perspective, but also for economics. Running an always on, high I/O, high data transfer workload on AWS is not usually the best choice financially. For example, we’ve worked with many customers during their evaluation phase, comparing a hosted private cloud to AWS or Azure, and have shown anywhere from 20-45 percent savings to run the same application in a hosted private cloud. However, if you have workloads that are highly burstable or that only run for a few hours a day, AWS will generally be more economically viable because of the on/off capability and short term billing.

The term ‘rightsizing’ is often referred to when it comes to the economics of cloud hosting. If your virtual server options come in three sizes, but your application requires a size somewhere in between, you still end up paying for the additional resources you are not using. This is the typical scenario for most public clouds. On the other hand, you could opt for a model that allows you to select the exact amount of resources you need now, and then scale them as you need. We see this with customers using a hosted private cloud deployment model.

The net of the economics discussion is that there is no one-size fits all and that careful consideration should take place before making a selection of the right cloud platform.

Rule 3: Review Platform Feature Set Availability

What cloud platform features are vital to IT’s ability to execute on the broader organizational strategy? Once again, not all clouds are created equal in this regard. In fact, there are even nuances inside the word cloud that can blur this decision process. Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) are all flavors of cloud that could have the right feature availability for a given need.

If we stay focused on IaaS for a moment, we get into areas such as API availability, automation capabilities, and native feature sets that allow an IT organization to achieve a growing list of outcomes. AWS, for example, regularly releases an average of 500-700 new features per year, not including upgrades or enhancements to existing features. Approximately 720 features in 2016 alone, with an additional 400 upgrades or enhancements. On the surface this seems great for IT orgs, but what it really means is an increasing amount of complexity and a decreasing ability for the average IT department to keep up. More features generally means more cost as well.

A laundry list of features could be useful in some scenarios, but overkill in others. You have to decide on which features are important to your particular scenario, run your cost benefit analysis, determine if you have the skills to implement, and then move forward. If you’re not equipped to do this evaluation or would like a second set of eyes, our team of certified solution engineers are here to help.

Rule 4: Have a Plan to Manage Multiple Cloud Platforms

Last, but certainly not least, is the question of how you will manage the cloud platforms in your multicloud strategy. Leading CIOs are working hard to reduce complexity, not add to it, so being able to manage as many cloud services from one place is a key to success.

“Do more with less” is a theme for most IT organizations, so asking the team to manage many cloud services each with their own tools, reporting, billing, monitoring, and so on becomes quite daunting even for the most savvy of teams. This is why it’s important to seek out the ability to bring everything under one roof, so to speak. Having a single pane of glass to monitor, manage, and report from reduces complexity and ultimately gives valuable time back to focus on more strategic initiatives that are important to the business’s bottom line.

The four points above boil down to a single sentence: A multicloud strategy should enable your organization to meet specific workload or application requirements—both technically and commercially.

Updated: January 2019

Discovering the Monster

If you ever have to manage an IT system migration, you will have plenty of potential conflicts. Based on what I have experienced in over a decade in the field, you may encounter something like this:

You accept a job at a great company managing a pretty sizeable IT environment. You’ve been made aware that stability and cost control will be your primary concerns. This includes moving the majority, if not all, of your infrastructure to “The Cloud” in the next 6 months!

You arrive enthusiastic, but, after a major outage in your first week, you try to triage with a root cause analysis. Each department in IT can only give an account of a few specific systems, so you ask for access to monitoring systems and to be added as a recipient of all critical alerts to get an overhead view.

That’s when you find out that such a system doesn’t exist in the department. You ask why, and one of your employees explains, “Johnny DBA doesn’t want us to monitor his program because he says he owns it.” Suddenly you realize why stability and cost control are your navigational goals: territorial thinking and departmental silos have led to a dysfunctional organization.

You ask your team for an inventory of all the systems, and over the next few weeks you dig further, uncovering more and more gaps in the inventory and even a feeble attempt at a coup, which results in the termination of one of the most tenured system admins. With his termination, knowledge of the oldest systems still clinging to the infrastructure leaves with him.

It’s at about this point that you realize you’ve inherited a monster:

• Outdated servers running critical systems
• Questionable backup processes
• A staff with entrenched territorial thinking

I call this the Frankenstein of IT, and I learned early on in my career that only a formal inventory could protect my IT environment from the monster.

Taming the Monster

Introducing INAP’s AgileMigration Service

As the leader of your IT organization, the need for accurate and detailed reports is critical to your success. This includes things like:

• The physical infrastructure – What hardware and how old
• The application stack including versions, service packs and patches
• Resource utilization – What is assigned to the host or guest v. how much is really needed

To migrate any environment, then, you want to call out gaps and issues as quickly as possible so that you can set real expectations. Performing a data audit will help you determine what budget is likely needed, who you will need to manage, and how to migrate the environment. You need to understand not only the infrastructure being moved, but also the inter-application dependencies and affinities. In other words, you need to know how any system works with each other system for any given report or service.

In talking with our customers, we found that they struggle to get this information in a timely manner. This was the primary driver for launching AgileMigration, a comprehensive white glove migration service.

The AgileMigration solution is comprised of three distinct phases: Map, Manage, and Migrate. In the Map phase, our noninvasive technology collects a complete inventory in the environment, including the application workloads and dependent systems across the network. In the Manage phase, detailed infrastructure inventory reports compiled from the data create a clear plan to migrate.

Finally, our technology will Migrate your entire environment from your existing platform or cloud provider to new environments with minimal or no downtime.

Discovery is the First Step

Whether you are looking to use INAP services or you have no intention to move but you need assistance auditing your environment, we can help. The AgileMigration service is made up of discovery tools, migration tools and professional services, each with a unique role to play.

For discovery, we will provide you with a physical or virtual appliance to set up in your environment to collect the details you need. We typically like to run the collection for a period of no less than two weeks, but we recommend at least a month to capture any end-of-month activity.

Our Agentless Deployment provides you with the following benefits:

• No Software Prerequisites or server reboots
• Lightweight, Quick implementation
• No port scanning or packet interrogation
• Affinity mapping
• Discovers all equipment (servers, networking, security appliances and storage appliances)

To get the most from your discovery, Customized Detailed Reporting allows you to configure the information you need in exportable spreadsheets.

Banishing the Monster

Our AgileMigration service will lower your project costs by reducing personnel hours associated with manual discovery efforts and eliminating challenges associated with subjective data.

More importantly, you will be able to keep skilled IT staff on projects that add value to your organization’s mission. Finally, our discovery provides a “source of truth”: using hard data for planning will help break down silos.

Once you have completed Discovery, you have several options for how to use the information. In the next blog post, I will detail how INAP can help your company through the Mapping and Migration phases.

Editor’s Note: We’re happy to present the following guest blog, courtesy of DePaul University Law Professor  Anthony G. Volini.

IP disputes have a multibillion dollar annual impact on the U.S. economy, affecting companies large and small. This briefly explores a basic question of when is an IP plaintiff a “troll” and discusses some common strategies in IP disputes.

So, what’s a troll anyway?

Troll is a subjective term. Some folks might broadly characterize a patent troll as someone suing for patent infringement who is not actually making and selling the invention himself (i.e., often called a non-practicing entity/NPE). But, it’s not that simple! For example, if Thomas Edison patented some brilliant new light bulb design and saw someone else selling his invention, we would probably not refer to Edison as a troll for enforcing his patent rights even if he were not making and selling the invention.  

What about an NPE enforcing patent rights on some technologically uninspiring patent who is solely in the business of buying and asserting patents? In such instances, there may be differing views of whether that NPE is a troll. Of course, if you’re the one being sued, you’re more likely to call the plaintiff a troll!

Over the years, I have encountered vague software patents where the invention sounds like it broadly protects acquiring data, changing it, sending it somewhere else, etc. (e.g., a claim that seems to cover just about any computer technology!). Some NPEs might jump on buying this type of patent because it can confuse defendants on what the invention is. A plaintiff might attempt to capitalize on that confusion, relying on the fact that many defendants can’t afford to hire a law firm to figure out what the invention is or is not and then defend the suit. Therefore, many defendants would rather quickly settle than embark on this costly journey.

Regarding patent troll status, it’s a matter of perception whether a particular plaintiff seems like a troll or someone who is enforcing legitimate IP rights. It’s probably unfair to refer to all NPEs as trolls.   

A “troll” is probably a subset of “NPE.” One other main distinction between trolls and other NPEs could also potentially be that trolls generally do not engage in additional research, advancing some field of technology. Universities are another good example of NPEs that people might feel uncomfortable labeling “troll,” as they continue to engage in research and generate additional IP.

So, what’s a copyright troll?

A copyright troll is typically a movie owner who sues large numbers of defendants for unauthorized BitTorrent downloads and who uses unfair or seemingly unethical litigation tactics.  His sole evidence is that a defendant’s IP address was used in the alleged download.  In some past cases, plaintiffs essentially blackmailed individual defendants into settling out of fear that their names might be published in a federal suit where the alleged download was a porn movie.  Some cases have involved fairly shady plaintiffs who seeded the bittorrent sites with their movies in the hopes that people would then download the movie, enabling the plaintiffs to sue.  In one case, a court found that the plaintiff had seeded the movie and that one of the copyright owners was a convicted felon. The judge referred the case to the U.S. Attorney’s office to investigate criminal conduct.

In theory, a BitTorrent plaintiff could be legitimately enforcing rights to a valuable movie to deter unauthorized downloads. However, I wonder if requiring ISPs to suspend accounts would be a more practical deterrent than filing federal lawsuits against individuals, many of whom are innocent? I’m curious if courts will ever embrace a theory that an IP address alone is an insufficient allegation to sue for one alleged copyright infringement when balanced against the potential for abusive suits.

Some copyright plaintiffs don’t want to pursue the suit past the complaint filing (i.e., the complaint is essentially a bluff). Instead, they see how many defendants can be quickly pressured into settling. They might back away from a defendant willing to put up a good fight and focus their efforts entirely on those they can quickly settle with. Sometimes a particular plaintiff is analogized to a criminal out trolling the streets for easy prey who avoids a large man, who might put up a fight, and instead targets a weaker elderly person.

Do Patent NPEs always start off with filing a complaint?

Being served with a complaint isn’t always the first step in patent licensing discussions. Some NPEs may not have the resources to actually pursue litigation, and putting a troll-esque patent before a district court creates a huge risk of invalidation and tanking the rest of the troll’s campaign. Eligibility under § 101 is usually fought over early on in the case. To the extent a company receives a pre-suit notice letter, the other option is to ignore the claim completely.  

This is actually one option the USPTO suggests (in a trademark context): https://www.uspto.gov/trademark/i-received-letter. However, assuming the letter constitutes sufficient notice of possible infringement, this could expose the company to potential willfulness damages, so it’s best to consult your attorney whether to completely ignore the claim or take other steps!

Defense Strategies

You and your attorney can gauge whether and to what extent the particular plaintiff wants to fight versus moving on to another target.   

Will it help to publicize the suit?

Many defendants hope that publishing a plaintiff’s identity, and the perceived unfairness of the suit, will scare the perceived troll into the shadows and stop his evil deeds. However, this is often not the case. When a plaintiff rolls up his sleeves to pick a fight, he is often expecting, and prepared for, bad press.

Team up with other defendants?

Various sites suggest teaming up with other defendants to share legal costs and share information. This seems like a good idea if you can make it work!

Settle the patent suit?

In addition to assessing whether and to what extent the plaintiff is willing to fight you versus merely bluffing, there’s certainly an economic analysis to consider: the cost of settlement versus legal expense and your time and energy to defend the suit.  

Use the Patent Office to bypass litigation?

Your attorney may be able to challenge a patent’s validity in the patent office, perhaps through an IPR (Inter Partes Review) which can be cheaper and faster than litigation in federal court.

One other benefit to filing IPRs while facing a district court action is that frequently the district court action is stayed while the IPR runs its course.  

The patent office PTAB kill rate in IPRs seems very high. An October 2016 patent office report noted that out of 145 completed cases, 118 of those cases had a finding that all claims were unpatentable. See page 11 of the report.

Are you reselling a product or making it yourself?

In some cases, a supplier may be responsible for indemnifying and defending the suit for a product you are merely reselling. (In many states, sale of a product automatically carries with it an implied warranty of non-infringement unless expressly disclaimed.)

Want to learn more?

As of this writing, I noticed this site, which addresses a variety of patent defenses with some good detail.

*This article is for informational purposes and does not constitute legal advice. Views expressed herein are Volini’s and are not made on behalf of DePaul University.

Updated: January 2019