Posts Tagged 'Authentication'

November 14, 2012

Risk Management: Securing Your Servers

How do you secure your home when you leave? If you're like most people, you make sure to lock the door you leave from, and you head off to your destination. If Phil is right about "locks keeping honest people honest," simply locking your front door may not be enough. When my family moved into a new house recently, we evaluated its physical security and tried to determine possible avenues of attack (garage, doors, windows, etc.), tools that could be used (a stolen key, a brick, a crowbar, etc.) and ways to mitigate the risk of each kind of attack ... We were effectively creating a risk management plan.

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

December 30, 2011

The Pros and Cons of Two-Factor Authentication

The government (FISMA), banks (PCI) and the healthcare industry are huge proponents of two-factor authentication, a security measure that requires two different kinds of evidence that you are who you say you are ... or that you should have access to what you're trying to access. In many cases, it involves using a combination of a physical device and a secure password, so those huge industries were early adopters of the practice. In our definition, two-factor authentication is providing "something you know, and something you have." When you're talking about national security, money or people's lives, you don't want someone with "password" as their password to unwittingly share his or her access to reams valuable information.

What is there not to like about two-factor identification?

That question is one of the biggest issues I've run into as we continue pursuing compliance and best practices in security ... We can turn on two-factor authentication everywhere – the portal, the vpn, the PoPs, internal servers, desktops, wireless devices – and make the entire SoftLayer IS team hate us, or we can tell all the admins, auditors and security chiefs of the world to harden their infrastructure without it.

Regardless of which direction we go, someone isn't going to like me when this decision is made.

There are definite pros and cons of implementing and requiring two-factor authentication everywhere, so I started a running list that I've copied below. At the end of this post, I'd love for you to weigh in with your thoughts on this subject. Any ideas and perspective you can provide as a customer will help us make informed decisions as we move forward.

Pros

  • It's secure. Really secure.
  • It is a great deterrent. Why even try to hack an account when you know a secondary token is going to be needed (and only good for a few seconds)?
  • It can keep you or your company from being in the news for all the wrong reasons!

Cons

  • It's slow and cumbersome ... Let's do some math, 700 employees, 6 logins per day on average means 4200 logins per day. Assume 4 seconds per two-factor login, and you're looking at 16,800 extra seconds (4.66 hours) a day shifted from productivity to simply logging into your systems.
  • Users have to "have" their "something you have" all the time ... Whether that's an iPhone, a keyfob or a credit card-sized token card.
  • RSA SecureID was HACKED! I know of at least one financial firm that had to turn off two-factor authentication after this came up.
  • People don't like the extra typing.
  • System Administrators hate the overhead on their systems and the extra points of failure.

As you can start to see, the volume of cons out weigh out the pros, but the comparison isn't necessarily quantitative. If one point is qualitatively more significant than two hundred contrasting points, which do you pay attention to? If you say "the significant point," then the question becomes how we quantify the qualitativeness ... if that makes any sense.

I had been a long-time hater of two-factor authentication because of my history as a Windows sysadmin, but as I've progressed in my career, I hate to admit that I became a solid member of Team Two-Factor and support its merits. I think the qualitative significance of the pros out weigh the quantitative advantage the cons have, so as much as it hurts, I now get to try to sway our senior systems managers to the dark side as well.

If you support my push for further two-factor authentication implementation, wish me luck ('cause I will need it). If you're on Team Anti-Two-Factor, let me know what they key points are when you've decided against it.

-@skinman454

November 29, 2011

SoftLayer Mobile v. 1.1 on Windows Phone: New Features

I was on a Caribbean cruise during the second week of November, and I kept telling myself that the first thing I needed to taste was a delicious mango. Even though I knew it's out of season, I still had hopes. I had a chance to indulge in that tropical fruit, and I couldn't help but think about a mango that gets tastier with every day: the new Windows Phone OS 7.1, codenamed "Mango."

I'm not going to talk about Mango or its new sensational features, but I do want to share a few of the changes that we pushed out to the Windows Phone Marketplace as a version 1.1 of SoftLayer Mobile. While I could ramble for pages about all of the updates and our strategy in building out and improving the mobile platform, but I'll try to be brief and only share four of the biggest new features the team included in this release.

Verisign Authentication
The first update you'll notice when you fire up SoftLayer Mobile 1.1 on Windows Phone is the security-rich inclusion of VeriSign authentication. You are able to activate an additional layer of security by requiring that users confirm their identity with a trusted third party tool before they get access to your account. In this case, the third party vendor is VeriSign. Every customer looking to bake in additional security on their account will appreciate this addition.

SoftLayer Mobile WP

VeriSign authentication in SoftLayer Mobile on WP7

Device-Based Bandwidth
The next big addition to this Windows Phone app release is the inclusion of device-based bandwidth for two billing cycles – your current cycle and the previous cycle. In v. 1.0 of SoftLayer Mobile, users were only able to see bandwidth data for the current billing cycle ... It's useful, but you don't have a frame of reference immediately available. This release provides that frame of reference. One of the coolest parts is the aesthetically pleasing presentation: our metro-style container, "pivot control." Just slide through and see your billing cycles in one long view!

SoftLayer Mobile WP

Billing cycle view along with a button to view graph for that cycle

Bandwidth Graphs
If you didn't notice from the picture, its caption or the heading of this section, the next big update is the inclusion of bandwidth graphs! The bandwidth graph page gives you a bird's eye view of your bandwidth activity for any selected billing cycle. You'll see the max "Inbound," "Outbound" and "Total" values. Those different marks are very useful if you're tracking which days your device uses the most bandwidth and when those surges subside. The application uses the built-in charting functionality that comes with Silverlight libraries. Since we're taking advantage of those goodies, you can bet it looks beautiful. No, it's not a bitmap image ... it's a real bandwidth chart. As with the other bandwidth update, the graphs are available for both the current and the previous billing cycle.

SoftLayer Mobile WP

Bandwidth chart for a previous billing cycle

Ticket Updates
The next addition to the family is a new way to visually distinguish your unread updates on tickets while viewing a ticket list page. The "toast" notification for the ticket list view gives flags unread ticket updates, and the ticket list will feature bold text on the ticket's subject if that ticket is marked with an "unread update" *ndash; meaning an employee or someone has an update to that ticket which you haven't seen yet. This is very much Outlook-y style and very native to Windows Phone.

SoftLayer Mobile WP

Toast notification along with Outlook-style unread ticket

What's Next?
With this release, we're not resting on our laurels, so what are we doing in our labs? Right now we're working on OS migration to move our existing app from OS 7.0 to the new Mango-flavored Windows Phone 7 version I mentioned a little earlier. Now you see why I was so fixated on mangoes while I was on vacation. The migrated mango app will only be available to devices that are mango-licious (Upgraded to 7.1).

Stay tuned, and you'll see some of the other new features we're working on very soon. If you have a Windows Phone, you need to download SoftLayer Mobile, rate it and give us your feedback!

-Imran

February 17, 2011

API Basics: REST

What is REST?
"Representational State Transfer," or REST, is a style of software architecture designed to relate different types of hypermedia to each other for distribution. The basic concept of REST is that a client application can request information from a server in the form of a representation of a resource without actually downloading an entirely new resource. This is how the World Wide Web works.

The World Wide Web
A browser is a client side application which requests information from a server; the server then accepts the request and transfers data back to the browser. The data transferred is not an application; it simply gives instructions to the client-side application (the browser), which then uses those instructions to properly display some information. Downloading information from a server changes the application state of the browser. The result of that change in state is a new website, which is therefore named the new state, so when new websites are downloaded by a browser, it is transferring representational data for a new application state.

How does REST relate to SoftLayer's API?
SoftLayer's API has many different avenues for implementation; one of these avenues is simple data transfer using the GET method in HTTP. Hyperlinks are one of the most basic examples of REST in action. When the user clicks on the hyperlink it requests information from the server and responds by transferring back representational data, in this case the data is expressed as either XML or JSON.

What are the disadvantages of using a REST API?
REST requests must contain all information, including authentication, within the URL. This can lead to security threats somewhere down the line. Luckily, SoftLayer allows you to add any number of users to your account, and then restrict their access to specific servers/services. This way your customers can utilize SoftLayer's API without a security risk to you or each other. They can even create their own users and further restrict access.

What are the advantages of using SoftLayer's REST API?
Direct client to server communication is the biggest advantage of using REST. The other protocols that SoftLayer uses to communicate data to the API require server-side scripting; this means that you will have to program your websites to use the host server as a proxy for calling SoftLayer functions. With REST you can directly link to the information that you want to display, using XLST or JavaScript to display it. You can also use AJAX with JSONP or script injection to dynamically update your webpage.

REST
The REST archetype is the most natural API for HTTP. This sets it above others in that there are no secondary programs needed to interact with HTTP (like SOAP), which means less computing time and better performance. REST APIs also don't need to use a proxy server for remote procedure calls. This decreases server load and bandwidth usage and further increases website performance. SoftLayer's REST API is easy to implement, and with SoftLayer's tiered user system its security flaws can be eliminated. This is why I prefer SoftLayer's REST API over the others.

Basic REST function calls are detailed in the SoftLayer Development Network (SLDN) here.

-Kevin

Subscribe to authentication