Jump to Page Content
Ed Welsh, Director, Security & Compliance

Comparing managed service providers: SERVICES vs services

Posted by Ed Welsh, Director, Security & Compliance on February 22, 2010 10:50 AM

Part of selling GSI's managed services is dealing with the competitive comparison issue, as prospective clients attempt to determine which managed service provider is the best fit for their IT management needs. The need to compare GSI versus our competition is understandable, but what do you do when there is little to compare us against?

The old and overused idiom, "Apples to Oranges" comes to mind, but does not accurately describe the situation. GSI is most often compared to "hosting" companies because we have hosting capabilities, but to say we are just a hosting company is grossly inaccurate. GSI is a managed services company with hosting capabilities. We provide the entire service – soup to nuts. Most competitors, while they claim to offer a total solution, barely get to the soup.

Maybe a metaphor using the auto repair industry can help clarify our situation as it relates to comparison shopping.

Comparing managed services versus MANAGED SERVICES

  • Space. Every auto repair shop must have a garage in which to put the equipment and vehicles involved. Much like IT hosting companies must have data centers. It is a given that one garage looks much like another. Picking an auto repair shop solely on the presence of a garage would not be prudent. The need for them to have a workable and available garage is a requirement, but you need more criteria to narrow down your comparison. The same goes for hosting companies and their data centers.
  • Range of services. Another area of comparison is the type of auto repair services and the expertise with which they are provided. A lot of shops provide standard services and have qualified technicians to provide those standard services on the most common vehicles. These services work fine for a standard high-production vehicle. What happens if your vehicle is a specialized, custom-built unit? The number of auto repair shops that can provide you services drastically decreases. Your selection now depends on the unique traits of the specialized services you require. This applies to IT services, as well. IT systems requiring advanced security and regulatory compliance necessitate specialized services, and narrow your service provider options.
  • Who performs the actual work? Let's muddy the waters a bit and carry the metaphor further. Say you have narrowed your auto repair provider selection down to three shops. They all three advertise knowledge of your specialized vehicle. Each shop defines their services using similar terms. Even so, as you dig into one shop's methods, you find that they provide work space and tools, but do not actually do the work. You and your brother-in-law will need to be available to actually perform any work. This kind of discrepancy can be very difficult to discover when picking an IT services provider, and it is painful to realize it after contracts have been signed with an auditor breathing down your neck.
  • Do they need direction from you? So, now you are down to two shops that may be able to perform work on your specialized vehicle. As you question the two, you again find a deficiency in one of them. They have the capabilities, the tools and the space, but they can only do exactly what you tell them to. They cannot or will not assist with designing your solution, and cannot point out issues you will encounter, much less account for them. This, again, puts you in a hot seat. Your services contract has turned into space and tools for you to implement.
  • Finally ... the needle in the haystack. The last shop you review meets all the requirements and represents the complete solution. Almost like having a dedicated race crew to work on your specialized vehicle. Clearly this is the best choice for the services you need, but it was not easy to identify them. There were not many clues to lead you to them. All the same terminology was used to describe the services, and all three shops were giving assurances that you would get the services you expect.

There are only a small handful of managed security service providers that actually take on the specialized tasks for regulatory compliance, yet you will find many claiming to do so. They all use the same language to describe what they provide, but many simply provide the tools. Since most regulatory requirements include an analysis component, any service provider that is not doing analysis along with data collection will not meet the requirements. Yet they will advertise a fully compliant service offering by assuming the client will spend the time necessary to cover the analysis needs.

When GSI states that a service we provide can meet a requirement, we mean that the service fully meets the requirement. Just as if a full IT team were hired on. The challenge is educating prospective clients on the difference when being compared to providers with less-developed ideas about services.

Robin Greenhagen, President/CEO

Building the Secure Cloud

Posted by Robin Greenhagen, President/CEO on August 28, 2009 11:40 AM

Are you a skeptic in your passion for all things cloudy? Companies buying and selling cloud-based services have had to deal with an attitude shift to "where is my data?" fear and loathing. This angst is understandable, especially when protecting data that can make or break your company's reputation, business transactions, or even worse, data that potentially belongs to your clients.

GSI's complex managed hosting and PCI-DSS compliant hosting clients simply wouldn't/couldn't fathom not knowing where the bits live, and EXACTLY how we were protecting them, feeding them and watching over them every minute of every day. We went for true enterprise virtualization when we built our Matrix virtualization/cloud offering. Tools like VMWare Enterprise, NetApp Storage, Cisco and Force10 Networking, Dell/AMD Servers, etc., have proven themselves over and over again both in our shop and in nearly every IT organization we meet.

If one of our clients wants to know where their data is, we can point it out, both logically and physically. We can explain the security protocols, lockdowns, and testing that is performed to ensure the integrity of their data. We show them our PCI-DSS audit of our Matrix Virtualization platform and enable them to sleep at night knowing that the cloud won't "swallow" their corporate or client data.

We wanted to make sure that our cloud was anything but secret sauce. It's mustard, ketchup and some pickle relish (actually Enterprise Pickle Relish 2.1c).

<analogy alert> I see hosting in the cloud a bit like taking my eight-year-old niece and nephew on a trip to the mall. Most cloud offerings would say, "Go ahead, just drop them off and let them run around our semi-structured environment." Well, besides that fact that there are occasionally a few undesirable people at the mall, I just don't trust that my precious assets will be safe. When I ask for details and get "non-specific" answers on their security, activities, whereabouts and planned activities, I am definitely not going to let them have the run of the place.

However, I have no problem dropping them off at their school, because I know there is a structured security plan, trained professionals that cater to their needs, and at any time, if I need to, I can identify where they are and who they are playing with at recess.

GSI has been offering PCI-DSS compliant virtual machines for a couple of years already. We started by virtualizing environments for individual clients, and in January 2009, we announced our Matrix Virtualization platform, which has been fully validated as part of both our SAS70-Type II and PCI-DSS compliance assessments (yes, we are a PCI-DSS Level 1 Service Provider). PCI in the cloud can be done, and is being done.

Further Reading

GSI's Matrix Virtualization Platform

Ed Welsh, Director, Security & Compliance

Change Management: Identifying Unauthorized Changes - Part 3 of 3

Posted by Ed Welsh, Director, Security & Compliance on August 21, 2009 10:22 AM

In my three-part discussion on change management, I've covered its importance as a formalized strategy, and how to deal with security event volume. This last section will briefly touch on the role of change management in identifying unauthorized change.

The value of this capability for risk control is very high. A single case of file change without a corresponding change authorization can highlight troubling issues and generate activities in relation to them.

Scenarios that generate unauthorized change events are numerous.  Is it a policy breach where someone neglected change management? Then education is applied. Has an attacker modified a vulnerable web site? Then an incident response plan is engaged and protection put in place.

The same model works for other security software, as well. Intrusion detection systems (IDS) are notorious for being event generators. Being able to match IDS events to a recent change drastically reduces the investigation time.  An example could be the installation of a new product that includes a browser "help" bar, which is also spyware. This example would generate both IDS and anti-spyware alerts, both of which would be matched back to the approved installation of new software. The administrator working the event can use this information to directly address the issue.

Change management is classically an operational tool for preventing system outage. It should also be well-respected by the savvy security professional as another tool for reducing risk and acting as a force multiplier.

Further Reading

Change Management: A Hidden Security Tool - Part 1 of 3
Change Management: Event Volume - Part 2 of 3

Ed Welsh, Director, Security & Compliance

Change Management: Event Volume - Part 2 of 3

Posted by Ed Welsh, Director, Security & Compliance on August 14, 2009 5:02 PM

In my first article, I introduced how companies can benefit from a formalized change management strategy. This week, I want to talk about a second important factor related to change management – dealing with security event volume.

Every serious information security wonk understands that security software can generate large numbers of events. The volume can be staggering with just a few systems, and for each increase in the number of systems, the event volume grows exponentially.

Logins, object access, file changes, internet attacks, virus alerts and intrusion detection events can have the combined effect of disabling a security team's capability to detect risk. Highly secure or compliant environments could easily require a security staff similar in size to operational teams just to control risk while providing for regulatory compliance. GSI takes a delegated approach.

It turns out that most data center operational teams have significant amounts of down time. GSI is more than just a data center operator; we are more of a secure data systems management company that happens to run a few data centers. Even so, the operations staff still has floating downtime when all they do is monitor system status. So I use that time for security events.

Every operations member is obsessively focused on our support ticketing system and rightly so. It is the primary mechanism for supporting our clients. Additionally, operations must respond and address every support ticket within time limits to meet service level agreements. It turns out that if I can put security tool events into the support system and provide specific instructions, then my capability to work events is equal to that of a security team the size of operations. A discussion of the need to engage an entire IT staff in security functions is not for this posting, but you get the idea.

So we have our security software events and we have a staff of folks to review and work them. How does change management affect how the events are worked?

The easiest example to explain is File Integrity Monitoring (FIM). GSI currently uses TripWire for FIM to detect changes in files deemed critical for risk control. The file list is long and amounts to operating system files, configuration files and website source files. A single MS patch cycle can generate thousands of events across hundreds of servers at once.

We use our change management system to track and approve patches to systems. Before the first file change occurs, the change management team will review and record approval for it to happen. When the FIM system generates alerts about file changes directly into the support ticket system, any team member on duty can check for "approved" changes associated with the affected system. A positive identification of authorized change stops the investigation with no more time dedicated to the issue. More poignant, for security at least, is that an unauthorized change is just as quickly identified. Stay tuned for next week's posting, when I talk about the value of change management in identifying unauthorized changes.

Further Reading

Change Management: A Hidden Security Tool - Part 1 of 3
Change Management: Identifying Unauthorized Changes - Part 3 of 3

Ed Welsh, Director, Security & Compliance

Change Management: A Hidden Security Tool - Part 1 of 3

Posted by Ed Welsh, Director, Security & Compliance on August 7, 2009 10:53 AM

This is the first of three postings I will share pertaining to change management.

The importance of change management for the stable operation of data support systems cannot be denied. Data center operations literature, such as ITIL guidelines, have change management looming large as part of any solution. One of the metrics I have heard is that 80% of system outages can be attributed to a change event.

As a hosting services company, GSI takes change to any environment very seriously. Controlling that change can, literally, affect our bottom line. Even so, change management is one of the "behind-the-scenes" services and processes that is rarely advertised directly or attributed with value. A system outage will bring attention to a lack of change management, but never is change management mentioned when it prevents outages. Much like a utility provider being discussed when a home's power is on, but let the power go out and the first discussion is about the provider.

Since becoming Director of Security and Compliance at GSI, I have become familiar with GSI's role in securing our client's data. I realize that change management and the well-designed implementation of it, are a critical piece of my security software suite. Of course, the PCI DSS includes a requirement (6.4) for change management, but it could be more emphasized and has missed the true security value.

How important is implementation?

I will take a few lines here to briefly discuss GSI's implementation of our change management methods. The implementation, in many ways, is as important as the use of the result.

Who
Any operational staff or client can generate a change request. It is very important that accessibility to the change management system be open. Restricting it to special access would prevent its usage which defeats the purpose of its existence. Power to approve changes is purposefully kept to a small number of management staff, but submitting a change is open.

When
Everyday. A selected team at GSI reviews change requests every day. An hour of every day is set aside by operations managers and me to review change requests for approval. It can be tedious given that any client or operational staff member can submit requests, but the value of discussing, understanding and debating changes is well worth it. Scheduling the review for every day allows us to granularly adjust the amount of impact in data systems due to change. It also supports security efforts.

What
All hosts. The structure and restrictions for controlling change are applied to data systems with regards to their criticality. The change management support systems and procedures are built to accommodate that need. This flexibility allows GSI to apply levels of change management even when tolerance for the control is very low. Compliant systems are held to strict standards of control, and the procedure provides that capability, as well.

Obviously there is more to the entire system than described here, but you should get the notion that implementation must be robust.

Next week, I'll share another article where I talk about the role of change management in dealing with security event volume.

Further Reading

Change Management: Event Volume - Part 2 of 3
Change Management: Identifying Unauthorized Changes - Part 3 of 3

Subscribe to the GSI Hosting blog Email an expert