It’s Q4, is your house in order?

4^th Quarter always seems to be the busiest quarter of the year; add in elections and you have a quarter fraught with disruptions. For CIO's and IT Directors, it's the inevitable question – "did my team contribute to the success of the company this year?" There should be metrics readily available to prove or disprove this question. Hopefully, the question isn't, "Did my team's dysfunctions take away from the stability of the company this year?" If so, there are bigger issues that probably can't be resolved by (successful) strategy meetings with the business before the end of the year.

I'm sure there are some that are thinking, it's December 1, what can you possibly accomplish in 30 days? Actually, plan on 19 work days. Many of those days for IT employees will mean catching up with vacation time that you couldn't take at any other time during the year. But, let's take a stab at making that timeline productive. The chances are good more of the business is taking vacation, so, overall, the office should be quieter than the norm.

Day 19 – Pull in your management team or leads and review with them what the purpose of the strategy meetings is going to be – determine how to provide excellent IT services in a manner that supports the business.

Days 18-14 – prep for meetings with the business

• Review year to date outages
  
  • Do you have metrics necessary to segregate the outages by function and reason?
    
    • If not, you need to create an independent Incident Management team
      
  • Have the issues that caused the outages been worked through?
    
    • If not, you need to establish a stronger root cause analysis protocol and create an independent Incident Management team to manage those type of incidents
      
  • Have either quick-fixes or permanent solutions been implemented?
    
    • If not, you need to create an independent Incident Management team to manage that process
      

Note, the recurring theme. If sufficient focus is not being given to understand, shorten and preventing outages, you have zero credibility with the business. Not a good place for a CIO or IT Director to be in.

• Review incident and problem ticket totals
  
  • Do you have the metrics necessary to segregate the incidents by business unit, infrastructure component and application?
    
  • Are issues being resolved within the established Service Level's (SLA's)?
    
  • Are customers complaining?
    
  • Does someone in IT have regular meetings with the business to go over problem tickets? If not, why not?
    
    • An IT team that has regular meetings with the business to HEAR their issues is an informed team.
      
      • The takeaways from those meetings should be ACTIONABLE. Otherwise, the business will become impatient. The purpose of the meetings should be clearly understood – you tell us what's wrong, we'll present you with solutions.
        
      • If the complaints are too ambivalent, meet with management to get to the bottom of the ambivalence.
        
    • The business needs to feel that they are heard or they will stop listening to the IT team and go elsewhere.
      
• Review IT Spend
  
  • Where did you spend money this year?
    
    • This should be fresh in everyone's minds as the 2013 budget planning sessions should have been completed just months before.
      
    • Money follows problems so if the money you are spending or planning to spend is NOT being used to a) understand, shorten and prevent outages and b) correct problem and incident ticket issues – you may have a disconnect that needs to be resolved.
      
    • Are you spending sufficiently to hire and train IT staff? Are you offering CBT and online training courses? Are you insuring they have sufficient time within the workday to keep up with evolving technology?
      
    • Are you providing your IT team the tools they need to efficiently do their jobs in a timely fashion?
      
  • Are you planning more spend to support or grow your business?
    
    • Does that coincide with the business leader goals?
      

 

Now that you have this information at hand, you can begin strategy meetings with the business. Better late than not at all. The best scenario here is for you to already have regular strategy meetings with the business and you can simply review where you and they are and what you can do to make the coming year better for both teams.

Days 13, 11, 9, 7 – Meet with the business

Days 12, 10, 8 and 6 – Meet as a team to review the information provided by the business and brainstorm as to resolutions. Include as many of your IT team as you can. They need to feel engaged and part of the solutions. While it may slow the process a bit, you need to embrace the craziness that is your team. The brightest IT people are not always managers or leads. Make the situation work for your whole team. If staffing is an issue, rotate in and out the IT team members that can attend.

[Separately, the CIO or IT Director should provide feedback to the business of what was heard. This may or not match up with what the business meant. BE SURE.]

• No idea should be thrown off the table
  
• All ideas should be assigned to someone other than the person proposing it to look at pros and cons
  
• This should be a collaborative effort, but the person proposing the idea has "game" in the solution, you want this to be a fair collaborative effort.
  
• Part of this process should be comparing the results of your prep meetings with the responses from the business and where each business issue fits.
  
  • If there is not a direct correlation, in theory, there should be. Investigate. It is your job to support the business.
    
  • You won't be effective in the business' eyes if your goals don't coincide with and support the business focuses.
    
• Invite trusted vendor partners to review your feedback. Ask what they are seeing in the industry.
  
• Meet with peers to ask what they are doing in problem areas.
  

  
   

Day 5 – Meet with Managers and Leads again to review progress, status and plans. Now is the time to trim out the proposed solutions that are a) too costly, b) too obscure that would take focus off of your core competencies and environment.

Day 4 – Prioritize your efforts and narrow the scope. If you don't narrow the scope you'll be playing darts with dull points because nothing will actually get accomplished.

Day 3 – Communicate with the business what your plans and takeaways are. Give them proposed timelines, letting them know that the dates could shift.

Day 2 – Call today IT Appreciation Day. Make it an annual event. Invite everyone to nominate someone for appreciation. Invite vendor partners to donate giveaways.

Day 1 – Actually appreciate everyone. IT teams love food. Give them silly awards that they can keep on their desks. Have drawings for the partner giveaways. Give away tickets to the local NFL football team or the Christmas concert being held or "something".

I don't honestly think IT Teams are appreciated enough because no one really understands what they do. So, to all the IT Teams out there, good job.

 

Access Review in light of Patraeus Scandel

Although I focus on technology risk discussions for the most part, and prefer to avoid politics in a public forum, the discussion about security clearance and access to confidential documents bring to light another aspect of risk management that I believe is highly relevant. I thought this even more so with the Jill Kelley involvement. Paula Broadwell and Jill Kelley represent two civilians that These two women were evidently granted security clearance based upon access they wanted to have to environments and individuals that average individuals don't have. I don't intend to go off as a moral compass for either General Patraeus or General Scott's alleged actions. This is simply about access rights.

Let's take Paula Broadwell first.

• I can understand Broadwell's access being granted to talk to Patraeus based upon them meeting and his feeling comfortable with a potential Biographer.
  
• I can understand Broadwell's being allowed to speak with Patraeus' colleagues and staff.
  
• I can understand Broadwell being granted a basic visitor badge to public areas within the buildings and locations that Patraeus worked in. (give her to the bathroom, to the kitchen and vending machines IF she didn't have to pass through any potentially secure areas to get there)
  

Questions I have:

• Was Broadwell provided with any level of security training prior to being granted her access?
  
• Was her role defined and boundaries discussed?
  
• Was her access reviewed by an independent source with no "game"?
  

Now, Jill Kelley.

• Mrs. Kelley is a civilian who because of her social standing was given a title of "honorary consul general". I don't know about you but that title is impressive. Take away the "honorary" and I'm really impressed.
  
• The State Department and the Department of Defense stated that Mrs. Kelley was a volunteer.
  
• As a social liaison to MacDill Air Force Base, Mrs. Kelley had access to a number of individuals she otherwise would never have met but no real paid responsibilities even though she worked with South Korea
  

  
   

Questions I have:

• Any volunteer can walk into Central Command at will?
  
• Were there limitations on where Mrs. Kelley could enter?
  
• Was there any type of review as to Mrs. Kelley's credit worthiness to hold that type of clearance?
  
• Was Mrs. Kelley's access fitting for her every day role? Was it on the same level as a janitor, a cafeteria worker or the person who takes care of the plants?
  
• Why did she have any expectation of protection for her role when she called 911 or sent emails to the Mayor of Tampa?
  

It would seem from the outside that both Mrs. Broadwell and Mrs. Kelley overstepped their boundaries and were allowed to do so because of their connections to senior military and government officials. From what the media has published, it would seem that both women had extraordinary access to resources the average person could only dream of.

I recognize some of these questions may appear naïve. Patraeus was, after all, the head of the CIA. What is disconcerting though is that there are people who are above scrutiny. If our national security is important to us, then no one person and no one person's access should be considered above question or reproach. At a minimum, those with security clearance should be reviewed and approved granted based upon a specific criteria.

I'm sure a lot more will come out about the scandal but at the root of it all, people were given access to places and persons that could have endangered the national security of our country. But is it possible that it boils down to access control and review?

 

Is your IT team the weak link?

A recent article in "Bank Info Security" http://www.bankinfosecurity.com/fraudsters-target-bank-employees-a-5269?rf=2012-11-09-eb&elq=7cc1647406704dd7bc60a34c9d54e8b0&elqCampaignId=5063, tells of a breach disclosing hundreds of thousands of customer's records. Experian, the credit reporting group, revealed that the reason for the breach was due to lax security at a credit union's IT department. This has to be especially vexing to those customers who then had to monitor their credit and lose sleep at night about the potential impact to their finances, present and future.

In IT, there has to be a balance between effort required to do your job and reward for discouraging data loss. The balance depends upon the potential liability to the company for data loss.

While it's difficult to insure a breach will not occur, there are some basic fundamental safeguards an IT department can take that will create a layered security approach and deter a breach from having a payoff.

• Create, follow and periodically test adherence for policies and procedures that support an established risk appetite
  
  • Separation of Duty
    
  • Implement Least Privilege Principle
    
    • Establish a reporting system for certain Privileged Account uses and insure review is performed on a regular basis
      
    • Create multiple logins for system administrators with access to vulnerable environments
      
    • Require management approval for privileged account creation
      
    • Work with system vendors to establish granular permission requirements
      
    • Where possible, limit the scope for system accounts
      
• Beginning with development, consistently follow a documented and socialized SDLC (Software Development Lifecycle) – including using either masked data or non-customer data for testing environments
  
• Establish periodic security and risk training for IT employees
  
• Establish architectural guidelines with management sign-off on any system changes that modify security parameters
  
  • Include a review by selected Security personnel
    
  • Include a sign-off from business to insure they are aware of security changes to applications
    
• Use Role-Based Access Controls
  
• Limit data transmissions from end user subnets
  
• Secure all data transmissions containing customer data
  
• Limit and monitor physical access to sensitive systems
  
• Implement an Incident Response Team to insure consistent response in the event of a breach.
  
• Implement a strong problem management/resolution process. Although this is not specifically security-related, it supports a consistent business approach to issues.
  

For the most part, none of these are expensive requirements. They do require a mature process attitude but there are a lot of positive benefits that come from this attitude including improved system availability, less overtime for IT staff and most definitely an improved technology risk footprint.

These steps will compliment and support a rigorous risk attitude in an environment where data loss could be costly. At a minimum, they instill a disciplined approach to managing the IT environment. You never go wrong by emphasizing this type of approach in IT

 

 

Detour, Detour

I don't think many people consciously sit down to create an application or environment thinking, "I'm going to create an insecure and potentially costly-to-remediate system today". I'm also confident that few people intentionally put their company's intellectual property or customer data at risk. That's what I'd prefer to think at least.

It's unfortunate that bad habits permeate the intricacies of technology to a point where I doubt, anyone, can attest to the actual cost of true security remediation. Potential Privileged Account misuse is a situation of "running amuck" that has to be addressed in companies, regardless of size or regulatory requirements. How many privileged accounts should there be in an environment? Should there be one super user account that is used across the enterprise? Who should have access to the privileged account information? How often should it be changed? Should it be more than 8 characters? Should the userid and password be prevented from matching? Should there be a use-on-demand policy with approval at an senior level? Would any of these help?

Let's talk about Detour. I got a call a few years ago from a former colleague who wanted to vent. Detour was the name of a service account so engrained in an environment he worked in that it would, according to the development manager, take thousands of man hours to remediate the millions of line of code Detour had been used in. Why would you want to remediate something like that? I guess I shouldn't have asked that question. The response was that the password was also "detour". Evidently every developer who had worked for the company for the previous ten years knew about Detour, detour. Additionally, it was used across an entire suite of applications for the developer's convenience. There was no supporting documentation; there had been no code review. The account had been set up in Active Directory with instructions that the password should never be changed or it would break multiple revenue generating applications.

The reason for my former colleague's frustration that particular day? An application support guy was troubleshooting an issue and tried to logon as detour, detour. Unfortunately, he kept mistyping detour when he typed in the password. The Active Directory setting for number of mistyped passwords before lock-out? 3. The Application Support guy didn't realize what he had done but monitoring screens in the Ops area turned red with all of the applications that were suddenly down. The development manager who also functioned as the application support manager called screaming bloody murder and threatening someone's job if Ops didn't figure out what was going on and get it corrected ASAP.

While there were a number of issues that needed to be corrected about the above scenario, the aspect that caught my interest the most was that there was a significant single point of failure in a company that appeared to either be undocumented or unrealized. It was obvious I didn't have to start naming the number of issues with the scenario, my former colleague got it.

• Same userid used across multiple environments
  
  • Creating no separation of duty across a suite of products
    
  • Creating a single point of failure
    
• Matching userid and password
  
  • A 5-character password made up of only letters can be hacked in nanoseconds
    
• Development and application roles being shared
  
• Developers, and thereby application support, having access to userid and passwords used in both development and production environments
  
  • Terminated employees had knowledge of this userid and password combination
    

    
     

I'm not a developer so I can't say that the development manager was exaggerating about his estimate of thousands of man hours to remediate the userid and password issue but I am fairly intelligent. I did take a few programming classes in college before I decided I wasn't interested in developing code. I have been an alpha and beta tester for multiple applications so have "some" knowledge of programming. At a minimum, I would like to see a report with the number of times the userid and password appear in the application's code. Then, someone could make an educated decision about the remediation efforts and whether the effort was greater than the potential liability. Perhaps that had already been done in the organization. Perhaps my former colleague was an alarmist who was constantly seeing threats where there were none.

 

A few steps that would help prevent this type from event from occurring in environments would include:

• Service account guidelines including password complexity and lifecycle
  
• Separation of duty between development and production environments
  
• Separation of duty between development and application support roles
  
• Risk documentation and analysis of the potential liability and threat of the perceived threat
  
• Documented SDLC (Software Development Lifecycle)
  
• Peer Reviews
  
• Architectural Reviews prior to a system going into production with sign-off and approval by multiple managers (this should include a risk matrix documenting inherent and residual risks)
  
• Accountability and consequences for non-compliance (REAL consequences and accountability not management turning a blind eye because someone says it'll take a lot of time)
  
  • I know red flags are going up for people here. In certain environments, this could be called whistle blowing. NOT if the facts are presented without an agenda other than securing the environment. If so, "it is what it is".
    
  • There should be assigned roles with responsibilities and timelines with reports to the business and IT executives until such time as the issue has been corrected. This gives the business the opportunity to be aware of the recognized risk.
    
• Privileged Use Monitoring (this can get really pricy so the cost would have to be justified by the potential liability)
  
• Maybe, a discussion with HR about appropriate behavior for managers with a bad temper.
  

  
   

While this company may never suffer a breach due to the lack of security surrounding detour, detour, doesn't it speak to an overall attitude regarding ease of support versus providing secure environments?

Do you know where your data is? Who else does?

A few months ago I visited a Chinese Restaurant for lunch. I was with a client and although I don't normally eat at Chinese Buffets, that was his pick, so we ate there. Critical information? No, except for one aspect of the visit – we were seated behind a group of employees from a local company who spent the hour talking about their "P drive".

I'm not sure what prompted the discussion but after sitting behind them for about thirty minutes, I can tell you their company leaves a lot to be desired as far as data governance is concerned. I'll provide a few more details about the mystery company. They are a fairly large and well-known company in Jacksonville. The Jacksonville office is their headquarters. They have offices up and down the east coast but also in other southern states. They are not in a regulated business but they do business with regulated companies. How do I know all of this? The answer is far easier than you could imagine. The company employees were wearing logo'ed shirts. Combine the loose lips with poor data governance and it could be a recipe for disaster if anyone sitting around the employees were hackers. I can assure you I did not have to go to a lot of effort to hear the conversation. The client that was with me does use that company's services and was horrified.

From the conversation, I gathered that the company's P drive is a dumping ground for anything that an employee wants to share with another employee. NTFS permissions (what secures the file and directory security) were inconsistent and anyone could create a directory off the P drive. Keep in mind; this was idle conversation between a bunch of guys at lunch. It's entirely possible that what was represented was not completely correct – but the gist of the conversation was that they had, at different times, stumbled across data that should have been considered private employee information and/or corporate intellectual property.

What's wrong with this picture?

A lot of companies choose to use specific network drive letters to help end users remember common repositories. For example, "P" for this mystery company stands for Public. Other common drive letters used are the "H" for Home directories, "U" for User directories and as already stated "P" for Public directories. Generally however, that is the end of the rules for data. Without a documented data governance plan however, a company can end up with data being stored in shares, directories and email mailboxes that were never intended for such use.

Problems created:

• Sensitive employee data can be exposed,
  
• Corporate strategies or plans can be delivered to the wrong individuals,
  
• Intellectual Property such as trademarked material can be viewed,
  
• Customer data can be exposed,
  
• eDiscovery and litigation efforts can be exponentially prolonged,
  
• It would be difficult to create a true business continuity plan without a full system recovery,
  
• It would be difficult to document application workflows,
  
• It would be impossible to secure all of the critical data
  

  
   

How do you go about creating a successful data governance plan?

• Define what data can be housed by your corporation,
  
  • While this may seem like a curious statement, unstructured corporate file servers are ripe for employees to use as storage repositories for music and pictures
    
• Define who will own the data,
  
  • What will be the record of source?
    
  • Who can access the data?
    
    • Create a review process to confirm the access accuracy
      
  • Can the data be copied or shared?
    
    • If so, who makes that decision?
      
    • What manner will be used to copy or share the data?
      
  • The data owners or their designated person should become data governance advocates in order to insure adherence
    
• Define the lifecycle of the data,
  
  • Confirm the legal requirements for data retention
    
• Define the data backup schedule and methodology
  
  • Confirm that this makes sense for recovery needs
    
• Define who makes the governance decisions regarding data access
  
  • This should NOT be the technology department. The technology department will create the shares and grant the permissions the business requires but should have no part in the decision making process.
    
• Educate end users on the criticality of maintaining the data structure once created.
  

 

What ELSE should be done in the "mystery environment"?

• Educate end users on information security to include social engineering concerns
  
• Include business leaders and technologists in all discussions regarding data governance
  
  • Data governance HAS to be a top-down initiative
    
• It probably wouldn't hurt to talk to employees about avoiding bringing up specific information about their environment while in public (that's what water coolers are for)
  

 

 

 

Bring Your Own APPROVED Device

BYOD – how to manage the flood without getting swept under by the wave.

 

According to Gartner, 48% of employees chose smartphones without regard for IT support. It's time for security and risk professionals to rethink their approach to enterprise mobility. BYOD HAS to become BYOAD or corporate IT departments will be releasing control and security to hackers. It's possible personal devices in the workplace could become a thing of the past, but not until the new smart phone love affair cools down. There are a lot of legal questions that arise when a company allows employee property to be used at the office.

• How is the employee reimbursed for the company-used portion of his service?
  
• Who handles replacement if the device breaks?
  
• How is personal information kept separate from corporate? Is it kept separate?
  
• How does the corporation handle device wipes in the event the employee leaves the company?
  
• How would the company handle e-discovery?
  
• Are texts considered business property?
  

 

All of these questions and more should be discussed and policies written to support the company's stance. Otherwise, these unknowns could bite an IT group where it hurts the most – credibility and security.

 

MDM – Mobile Device Management is yet the latest case of many IT departments trying to capture the horse running out of the barn. Frequently, the business is out the gate leaving IT in their dust or in hard pursuit, trying to get ahead of the race. (I promise that's the last of the analogies).

 

It's a fine line that IT departments walk as far as locking down desktops, browsers and devices. Who can remember when desktops were locked down and suddenly people couldn't play Solitaire at lunchtime? In their minds, it wasn't because managers had requested it. "IT" DID IT. In order to be as successful as possible

 

• First- understand what the business wants/needs the devices for. Is it for convenience? The cool factor? Ease of doing business?
  
• Second – research the market to see what's currently available and what vendors are advertising as their next generation release. Without a Ouija board, that's the best you can do.
  
• Third – research MDM vendors to identify which fits your business model. Which companies focus on being the market leader in releasing gadgets versus who focuses on securing and segregating personal data from business? Ask the question, what is your company's risk footprint? How will Mobile Device support impact your IT department? Is containerization critical to you?
  
• Fourth – perform a pilot program. Document details such as ease of administration, configuration and Use. Use. Include a use-scenario for performing remote wipes.
  

 

Gartner's Magic Quadrant published their MDM Software edition in June, 2012. They reviewed approximately 20 different vendors offering Mobile Device Management solutions. Of those, you have the names you would expect to see in the Leader Quadrant, Fiberlink, Good Technology, and AirWatch. Of these vendors, all market to large enterprise environments.

• AirWatch has a strong focus on security and can easily support to scale. It has a strong administrative interface according to Gartner.
  
• Good Technology (the one I am most familiar with), has strong security capabilities with multi-factor authentication. It comes at a high cost per client because its mobile management component is part of an Enterprise package. Good does not support Blackberries which may or may not be meaningful to your environment.
  
• FiberLink's product (MaaS360) does not support an in-house solution. They have strong feedback on integration with cloud email services. The only negative that would discourage shops is that the management approach is device centric versus user centric which means that IT support requirements would be greater than with user centric products.
  

  
   

In the Challenger's quadrant, you find SAP and Symantec, neither of which have a strong focus on mobile device support.

 

In the niche player quadrant, you have a number of players including McAfee, Trend Micro, LanDesk and Amtel. Of these, McAfee and Trend Micro have strong reputations for security focus. As far as support is concerned, I've used McAfee, Trend Micro and LanDesk and have high regard for their support. For MDM however, I don't know that I would recommend any of these products. LanDesk's interface is complicated and not user-friendly. McAfee hasn't gone a long way toward making their product a priority, rather it is an offering bundled with other products. TrendMicro is focusing on their current customer-base and integrating their product with their other bundle. While this may not be a relevant point if you already are a TrendMicro shop, it's a consideration.

 

In the visionary quadrant, you have IBM and BoxTone. Of these, IBM is not a mobile-focused vendor, it's solution provides minimal reporting features and it only supports native device encryption. On the positive side, if you are an IBM-centric customer, you will receive world-class support. BoxTone really stood out in my estimation. They have a long history with focusing on mobile devices, particularly enterprise-sized. They are strong components of a multilayer-defense approach to security and can remediate policy and compliance violations. The only negative that was disconcerting is that application containerization is not used for native apps on the device – such as Apple email client. It does have a version of NitroDesk's TouchDown app for Android and supports Good.

 

Whichever MDM solution you decide upon, make sure it fits your corporate risk footprint, the IT support model you can afford and the needs of your business. Do your research. If you'd like a copy of Gartner's report, email me at cgarland@cgsolutionsofjax.com and I'll be happy to forward it to you.

210 reasons not to outsource IT Operations

There are a lot of good reasons to outsource IT Ops but I've never seen the topic discussed in quite this way. Why WOULDN'T you want to outsource IT?

First of all, let's talk about the reasons Hosting companies tout for moving forward with outsourcing:

• You don't have to carry as many IT persons on your payroll,
  
• You don't have to maintain certifications and training levels for IT personnel,
  
• Around the clock eyes on the environment,
  
• You don't have to pay for real estate to maintain a server farm environment (nor pay for air conditioning and electricity for support environment)
  

Refuting those points:

• No you don't have to carry as many IT persons on your payroll, but you have to pay for the Hosting company's IT personnel.
  
• No, you don't have to maintain certifications and training levels for IT personnel, but you do have to pay for the Hosting company's personnel to maintain their certification levels.
  
• Around the clock monitoring, call-home and self-healing technologies can provide the around the clock eyes on your environment w/o undue load on your IT staff.
  
• You will be paying not only for the real estate for the server farm but also for the A/C and electricity to support them. Add in the cost of additional bandwidth necessary for your employees to work across your pipe to the Datacenter and these costs add up. While in a hosted environment, you can share the hardware costs with other environments, does that meet your regulatory requirements? Would that pass a regulatory audit?
  

It's critical for companies considering outsourcing to be aware of the terms in their contracts. What are you paying for? Are you paying for additional costs associated with upgrades or change management? Are you paying for electricity use above and beyond a specific threshold? Are you paying for hands-on support in the event of a hardware failure? Hosting companies are not in business to be philanthropic. They are making money. How? Virtualization, lights off utilities in the form of less electrical consumption during non-populated timelines, automation tools, low footprint server farms and yes, server and system consolidation. Are there build-out terms in the event your environment grows beyond your current needs? Is there cage space that can be guaranteed so that you don't have to move your entire environment and incur downtime?

Have you ever read a Service Level Agreement (SLA) or Operating Level Agreement (OLA) for a Hosting facility? Average SLA's are for four hour response time. It could be that your SLA is for eight hour response for less- critical systems with four hours being set up for your mission critical environments. That's not resolution time, that's response time. Are there Resolution time contract terms? There need to be. You can contract for ASAP response time but at what cost? Is the sum cost-prohibitive? Find out.

Now let's go back to those 210 reasons. In an in-house supported environment, I've never seen an Ops team wait four hours to respond to an incident. Generally, teams respond as soon as they receive alerts and resolve the issue as quickly as possible. This would generally lead to a 30 minute response time with less than an hour resolution time. 30 minutes versus 4 hours equates to a difference of 210 minutes in response between in-house support and a Hosted provider. While I'm not saying every Hosted provider is going to wait for four hours before responding to an incident, what is the inducement for them to do so? If it isn't in the contract, it doesn't matter that they have a great facility and really nice engineers. They are, as you should be, looking out for the bottom line.

In order to move to a hosted solution with support included, a company needs to have a stable environment. Are you applications problematic? Have you had consistent policies and procedures in place that easily translate to a hosted environment? Do you have experience with managing vendor relationships? All of these are questions that need to be addressed prior to signing off on outsourcing Ops.

How much revenue or missed opportunity does that 210 minutes represent to you? If you are in a regulated business, those 210 minutes could be costly in terms of fines. Either way, those 210 minutes are going to be paid for. The question is – are the 210 minutes worth the price?