Every risk has different probabilities of occurrence, potential damages, and prevention costs, and the risk management process helps us balance the costs and benefits of various security methods. When it comes to securing a home, the most effective protection comes by using layers of different methods … To prevent a home invasion, you might lock your door, train your dog to make intruders into chew toys and have an alarm system installed. Even if an attacker can get a key to the house and bring some leftover steaks to appease the dog, the motion detectors for the alarm are going to have the police on their way quickly. (Or you could violate every HOA regulation known to man by digging a moat around the house, filling with sharks with laser beams attached to their heads, and building a medieval drawbridge over the moat.)

I use the example of securing a house because it’s usually a little more accessible than talking about “server security.” Server security doesn’t have to be overly complex or difficult to implement, but its stigma of complexity usually prevents systems administrators from incorporating even the simplest of security measures. Let’s take a look at the easiest steps to begin securing your servers in the context of their home security parallels, and you’ll see what I’m talking about.

Keep “Bad People” Out: Have secure password requirements.

Passwords are your keys and your locks — the controls you put into place that ensure that only the people who should have access get it. There’s no “catch all” method of keeping the bad people out of your systems, but employing a variety of authentication and identification measures can greatly enhance the security of your systems. A first line of defense for server security would be to set password complexity and minimum/maximum password age requirements.

If you want to add an additional layer of security at the authentication level, you can incorporate “Strong” or “Two-Factor” authentication. From there, you can learn about a dizzying array of authentication protocols (like TACACS+ and RADIUS) to centralize access control or you can use active directory groups to simplify the process of granting and/or restricting access to your systems. Each layer of authentication security has benefits and drawbacks, and most often, you’ll want to weigh the security risk against your need for ease-of-use and availability as you plan your implementation.

Stay Current on your “Good People”: When authorized users leave, make sure their access to your system leaves with them.

If your neighbor doesn’t return borrowed tools to your tool shed after you gave him a key when he was finishing his renovation, you need to take his key back when you tell him he can’t borrow any more. If you don’t, nothing is stopping him from walking over to the shed when you’re not looking and taking more (all?) of your tools. I know it seems like a silly example, but that kind of thing is a big oversight when it comes to server security.

Employees are granted access to perform their duties (the principle of least privilege), and when they no longer require access, the “keys to the castle” should be revoked. Auditing who has access to what (whether it be for your systems or for your applications) should be continual.

You might have processes in place to grant and remove access, but it’s also important to audit those privileges regularly to catch any breakdowns or oversights. The last thing you want is to have a disgruntled former employee wreak all sorts of havoc on your key systems, sell proprietary information or otherwise cost you revenue, fines, recovery efforts or lost reputation.

Catch Attackers: Monitor your systems closely and set up alerts if an intrusion is detected.

There is always a chance that bad people are going to keep looking for a way to get into your house. Maybe they’ll walk around the house to try and open the doors and windows you don’t use very often. Maybe they’ll ring the doorbell and if no lights turn on, they’ll break a window and get in that way.

You can never completely eliminate all risk. Security is a continual process, and eventually some determined, over-caffeinated hacker is going to find a way in. Thinking your security is impenetrable makes you vulnerable if by some stretch of the imagination, an attacker breaches your security (see: Trojan Horse). Continuous monitoring strategies can alert administrators if someone does things they shouldn’t be doing. Think of it as a motion detector in your house … “If someone gets in, I want to know where they are.” When you implement monitoring, logging and alerting, you will also be able to recover more quickly from security breaches because every file accessed will be documented.

Minimize the Damage: Lock down your system if it is breached.

A burglar smashes through your living room window, runs directly to your DVD collection, and takes your limited edition “Saved by the Bell” series box set. What can you do to prevent them from running back into the house to get the autographed posted of Alf off of your wall?

When you’re monitoring your servers and you get alerted to malicious activity, you’re already late to the game … The damage has already started, and you need to minimize it. In a home security environment, that might involve an ear-piercing alarm or filling the moat around your house even higher so the sharks get a better angle to aim their laser beams. File integrity monitors and IDS software can mitigate damage in a security breach by reverting files when checksums don’t match or stopping malicious behavior in its tracks.

These recommendations are only a few of the first-line layers of defense when it comes to server security. Even if you’re only able to incorporate one or two of these tips into your environment, you should. When you look at server security in terms of a journey rather than a destination, you can celebrate the progress you make and look forward to the next steps down the road.

Now if you’ll excuse me, I have to go to a meeting where I’m proposing moats, drawbridges, and sharks with laser beams on their heads to SamF for data center security … Wish me luck!

-Matthew

The Missing Link in Managing Cloud-Hosted Applications

Would you agree that one of the factors impacting the Quality of Service delivered by your applications is the availability of resources required for their execution? If you do, then you may wonder – as I do – why there aren’t more tools available to help you monitor and manage application resource consumption.

DevOps and operations teams use Cloud Resource Monitoring to keep track of the health and utilization of cloud resources, Real User Monitoring to ensure that their users experience the Quality of Service they expect, and Application Performance Management to find and fix performance issues in their applications.

What’s often missing is the ability to:

• Monitor and manage the use of resources at application level
• Ensure availability of resources
• Help in root cause analysis
• Improve resource utilization
• Do better capacity planning

Our Silverline Application Resource Management service fills this void by providing you detailed, application level data on the consumption of server resources (processor, memory, disk I/O and network I/O) and on the “demand” for these resources (i.e. how much of each resource an application would use if not restricted by resource availability). You can use this information to detect sudden changes and unusual patterns in resource consumption, identify situations in which applications are starved for resources, and to do capacity planning.

Silverline also allows you to guarantee availability of resources for individual applications or groups of applications, by setting resource quota. It guarantees that an application always receives resources up to its quota if it needs them but lets other applications use resources while it doesn’t need them. This makes it possible to run multiple applications on a server instance and guarantee that they will not interfere with each other, while at the same time improving the utilization of resources. It also allows you to make sure that critical applications (e.g. for collecting diagnostic data) are never starved for resources.

As a special case, you can use quota to let background workloads “harvest” spare resources: Simply set their resource quota to zero and they will only use resources not required by higher priority applications.

Silverline’s event handling feature allows you to set thresholds on resource consumption that can be used to send alarms or initiate automated actions. This allows you to receive early indications of problems like when an application’s resource consumption is exceeding normal levels or there is a significant gap between its resource use and resource demand. You can also take automated actions like killing rogue applications that consume too many resources.

If you’re looking for ways to improve the performance and availability of your SaaS or PaaS solution or to improve the utilization of your Softlayer cloud resources, give Silverline a try.

-Fred van den Bosch, Librato

Measure Everything!

If you’re a SaaS or PaaS provider, making sure that you deliver the Quality of Service that your users expect is probably your highest priority. This means that you rely on continuously monitoring all aspects of your operation that can alert you to unusual events and help you find and fix the root cause of any service degradations. User complaints cannot be the first sign of trouble, and there is no time to hunt for data that has not already been collected.

This need for information is the main reason why “Measure Everything” is the new principle by which SaaS and PaaS clouds are managed and why many DevOps and Operations teams are using a variety of open source and commercial tools to monitor their infrastructure. In addition they often need to monitor data that is collected with custom tools because it is specific to their application environment. Since each tool comes with its own user interface, alerting mechanism and set-up requirements, the monitoring work-flow is disjointed, wastes time, and – most importantly – introduces problems when trying to correlate data from different tools for rapid root cause analysis.

Wouldn’t it be nice if – just as there are standard Database Management platforms – there were Time Series Data Management platforms that provide uniform visualization, correlation and alerting, and a scalable, redundant repository for your metrics? Ideally, that platform would be delivered as a service and could even be embedded by SaaS and PaaS vendors to allow users to monitor their services directly.

Librato Metrics is the platform we built to meet that critical need. Designed from the ground up with an “API first” approach, Metrics allows customers and partners to easily send it any time series data and understand how that data fits with other data they are collecting.

If you want to provide your users with monitoring capabilities, you can integrate and embed Metrics at whatever level best fits your needs: data repository, instruments for your own dashboards, or complete “white label” dashboards. By programmatically creating user accounts and transparently signing your users onto the Metrics platform, you can deliver a seamless experience.

We used “flexible,” “affordable” and “simple” as our key mottos in developing a business model for Metrics. Our goal was to make the platform easy to adopt and completely transparent, empowering every organization to take advantage of the “measure everything” philosophy. We charge a modest amount (in “micro-dollars” actually) per measurement, provide a 30-day free trial, and charge you monthly for what you have used … there are no minimum fees or lock-ins.

To make it easy to adopt Metrics, we provide connectors for a variety of popular collection agents such as StatsD, CollectD, and JMX. To help build a broad collection of useful collectors and connectors to existing tools, we’re building a community and ecosystem where Metrics users and tool developers can contribute. We hope you’ll try out the platform and help us grow our community!

-Fred van den Bosch, Librato

Knowing Your Apps Are Up and Running = Peace of Mind

Whether you are building or managing apps in the cloud, it’s important they stay up and running optimally. With cloud performance monitoring by CopperEgg you can do just that! RevealCloud Pro takes less than 10 seconds to install and provides performance monitoring so you can rest assured and know your apps are up and running smoothly.

With RevealCloud Pro you gain real-time insight into the speed and availability of services by monitoring CPU, network load, uptime, blocked processes, memory space, disk space and more. At the first sign of trouble, RevealCloud Pro can immediately alert you email, SMS or Pagerduty when performance in one or more areas is outside of normal ranges. You can even take action via a webhook. This enables you to uncover and correct performance issues often before the system goes down. In addition, historical tracking over the last 30 days enables you to uncover trends in performance and capacity that could otherwise go unnoticed.

With a rapidly growing customer base spanning over 50 countries, we know we are on to something good! Read what they have to say…

Customer Speak
Eduardo Fernandez, president of Shuttle Cloud, is a current Softlayer customer, and he shared a little about his experience with RevealCloud Pro:

“Our business is built in the cloud so monitoring performance is critical. With RevealCloud Pro, we have an easy to install and easy to use product that gives us everything we need to monitor our instances and ensure our systems are running optimally. I like the high level view RevealCloud provides of all instances on one screen so I can see the health of our systems at-a glance. By contrast, members of my team need to know in real-time if any of our instances are either not responsive or have a very high load, memory or processing issue. By receiving alerts as soon as an issue occurs via cell or email means we can address things immediately. We also use the historical tracking to monitor trends and look at activity during the overnight hours.”

In addition to cloud performance monitoring, RevealCloud Pro also works on servers located on premise, in the data center, or in virtual environments. RevealCloud Pro makes viewing multiple systems simple, and is ideal for those who want to compare performance among their servers with no hassle.

Offer for SoftLayer Customers
Experience RevealCloud for yourself … It’s addictive! Try RevealCloud Pro for free today.

- Mike Raab, CopperEgg

How You Should Approach Monitoring in the Cloud

Monitoring in the cloud may sound like it’s easy, but there’s one important thing you need to know before you get started: traditional monitoring techniques simply don’t work when you’re in the cloud.

“But why?” you may ask. “Why can’t I use Polling and Byte Code Injection in my cloud infrastructure?”

With Polling, you miss incidents between intervals, you only get the data that you requested, and you can only monitor parts of the application but not the whole thing. If you choose to use Polling for your cloud monitoring, you’ll have to deal with missing important data you need.

And with Byte Code Injection, you only get data from within the language run-time, meaning you don’t have the real data of what is happening across your application stack. It is inferred.

Using our own product on our production systems, we have learned three lessons about running in the cloud.

Lesson #1: Visibility = Control
By definition, running in the cloud means you are running in a shared environment. You don’t have the CPU cycles your operating system reports you have, and sometimes, the hypervisor will throttle you. In our experience, some cloud vendors are much better at managing this than others. When running in some clouds, we’ve had huge variations in performance throughout the day, significantly impacting our end-users experience. One of the reasons we chose SoftLayer was because we didn’t see those kinds of variances.

The reality is until you have visibility into what your application truly needs in terms of resources, you don’t have control of your application and your user’s experience. According to an Aberdeen study, 68% of the time IT finds out about application issues from end users. Don’t let this be you!

Lesson #2: It’s Okay to Use Local Storage
The laws of physics reign, so the disk is always the slowest piece. No getting around the fact there are physical elements involved like spindles and disks spinning. And then when you share it, as you do in the cloud, there can be other issues … It all depends on the characteristics of your application. If it’s serving up lots of static data, then cloud-based storage can most likely work for you. However, if you have lots of dynamic, small chunks of data, you are probably best served by using local storage. This is the architecture we had to go with given the nature of our application.

With servers around the world streaming application behavior data to our production system all the time and needing to process it to make it available in a browser, we had to use local storage. In case you are interested in reading more on this and RAM based designs here are some posts:

• High Scalability – Are Cloud Based Memory Architectures the Next Big Thing?
• Thinking Out Cloud – Memory-Based Architectures and the Cloud
• AppFirst – A RAM Based Data Architecture

Lesson #3: Know the Profile of Your Subsystems
Knowing the profile of your subsystems and what they need in terms of resources is imperative to have the best performing application. A cloud-only deployment may not be right for you; hybrid (cloud and dedicated physical servers) might work better.

As we discussed in Lesson #2 you might need to have local, persistent storage. Again, some vendors do this better than others. SoftLayer, in our experience, has a very good, high bandwidth connection between their cloud and physical infrastructure. But you can’t make these decisions in a vacuum. You need the data to tell you what parts of your application are network heavy, CPU intensive, and require a lot of memory in certain circumstances. We have learned a lot from using our own application on our production system. It’s very quick and easy for you to start learning about the profile of your application too.

We are constantly learning more about deploying in the cloud, NoSQL databases, scalable architectures, and more. Check out the AppFirst blog regularly for the latest.

We’d like to give a special shout out thanks to SoftLayer! We’re honored to be one of your launch partners in the new Technology Partners Marketplace.

-AppFirst

The core product works through a piece of software that gets installed on a customer server called a robot. The robot in turn allows probes to be run on the server. The different probes collect various data points from the OS and applications. As the probes collect data they pass the information onto some intermediate backend servers, and eventually end up on our brand new HBase data warehouse (HBase is the massively scaled database for large amounts (petabytes) of data). This is the corner piece for the scalability of the offering. So, robot is the main software and the probes are the application watchers that run inside the robot framework.

There are additional features outside of the process mentioned called ‘Offbox Monitors’ or ‘Offbox Probes.’ These are probes that live on servers in the SoftLayer data center. The idea behind these is that we are able to let customers have network services they want to monitor from a remote location. An example would be url_reponse, which monitors if a url is active and passing data (along with some other pieces of data people might be interested in like response time).

What it can monitor? The better question might be what can’t it monitor? The SoftLayer offer comes in three packages – Basic, Advanced and Premium. Basic is a free package that monitors core hardware (CPU, memory, disk) along with simple process and services. Advanced moves into deeper system monitoring, and Premium adds more application monitoring (like databases, web services etc.). This offering is available for hardware, Monthly CCI’s and hourly CCI’s – basically for everything we sell. Customers can order the software from all order forms (external, internal, cci, server etc.) as well as add the service post deployment from the advanced monitoring portal page.

The service offering has two distinctive reporting features that we call graphing and alarms. Graphing allows customers to (yep, you guessed it) graph all the data we collect. For example, we can show a graph of CPU usage over time. Alarms are notifications that services are outside of a predetermined range. For example, you could setup an alarm when CPU usage goes above 90%. Alarms can be tracked from the customer portal, or email alerts (SoftLayer calls this list ‘Alarm Subscribers’) can be setup by the customer.

All the features of the product are accessed via the customer portal, or via SoftLayer’s internal portal. Configuration, graphing, and alarm management can all be done from one management page in the customer portal. In near real-time customers can change configurations directly on their server or cloud computing instance (CCI) for the various data points they want graph and alarm. It’s pretty slick, and it adds to the SoftLayer secret sauce. We have also added a feature that allows the customer to save configurations on a particular server and “redeploy” them on different servers or future servers they may add. This feature makes it easier to scale and customize for a particular customer’s needs.

As time goes on we will continue to add more probes and more features. This is just the beginning – make no mistake it’s pretty damn cool.

-@quigleymar