Often times on the surface the idea of building, buying your own gear, and running it on your own may appear to be the more cost effective option. However, if you consider the big picture including the emergence of the managed cloud then outsourcing is not only more cost effective, it makes the most sense.  Consider these factors when comparing outsourcing vs. building it yourself.

1. Capital Depreciation

Outsourcing is considered an OPEX. There is no hardware to have depreciated over time.  When hosting internally you have expensive equipment to purchase as a CAPEX plus maintenance agreements, collocation or utility costs, and other “surprise” investments.  Outsourcing presents a predictable monthly recurring expense.

2. Employee Turnover

Employee turnover can happen at any time for many reasons. If key people running your internal environment leave the company, you could be left trying to pick up and maintain critical pieces. Outsourcing removes this risk as you’re under contract with a business that provides and guarantees these services with complete documentation and continuity.

3. SLA’s

Many web hosts hold strong SLA’s (Service Level Agreement). The SLA may include 100% network uptime, 1hr hardware replacement, 30 minute emergency response, and resource guarantees.  You are in turn, able to offer these guarantees to your own clients giving them added assurance.  It can also help you bring on new customers who may have similar requirements.

4. Buying Back Hardware

Many times companies will balk at moving forward for an externally hosted model because they’ve already invested in hardware.  INetU works with a partner who can buy back your hardware to help cover the investment.  Don’t forget that just because you’ve already invested in hardware it doesn’t mean you must keep running things internally.

5. Flexibility

High level managed hosts should have vast expertise, experience, and resources at your disposal – if the landscape changes or you bring on a customer with unique requirements – an outsourced host should be equipped to swiftly accommodate them.  If something goes wrong, an experienced and competent web host has most likely seen it. They will have the technical expertise in house to troubleshoot the problem immediately. You may not have the ability to do this in house.

6. Scalability

Most outsourced managed hosting providers can add virtual machines to your environment in less than an hour and add physical infrastructure in a day or two.  In addition, at a respected web host you can take advantage of their cloud to combine with your private cloud to accommodate unknown load or a need for having resources available immediately.  Achieving this same thing by setting up in-house hosting would be incredibly expensive and take much longer.

7. Opportunity Risk

Opportunity risk should also be considered as you will require internal IT resources spend their time maintaining the hosted environment in-house.  Externally hosting frees up these resources to focus on tasks more specific to your business.  There is also the opportunity risk of not being able to meet one of your customers’ requirements internally while externally hosting gives you the ability to accommodate most clients’ requirements quickly.

8. RFP Questions

In most cases, the answers you would give in-house would not be as favorable to the answers you would provide in an outsourced scenario. Outsourced hosting allows you to confidently answer questions around  SLA’s, uptime history, certifications (like SAS-70 or SSAE 16, PCI Compliance, HIPAA/HITECH), scalability, etc.  An outsourced web host can assist with these RFP’s and any other customer engagements to truly play the role of partner and extension of your IT staff giving you a better chance to meet your client’s requirements.

9. Security

A managed web host maintains the highest levels of security.  At INetU we perform employee background and criminal checks, video surveillance with records kept for at least 90 days, dual factor authentication to access the facilities, logging of who accessed what and for what reason, and regular training by the SANS Institute.  Not to mention standardized offerings of IPS, WAF’s, SIEM, File Integrity Monitoring, and vulnerability scanning.

10. Compliance/Certifications

Managed web hosts obtain compliance certifications like SSAE 16 Type II, SOC2, SOC3, and PCI DSS certifications to make sure your data is secure.  It is extremely expensive to attain these in house as a service provider to your end clients.  By outsourcing, your solution to your customers becomes encompassed by these certifications essentially which presents an added benefit and significant cost savings.

11. Network Latency

By outsourcing your web hosting needs, this allows you to take advantage of the provider’s subscription to multiple tier 1 providers over Gig-E lines. A complete meshed network redundancy and automatic failover which means your servers are always available 24x7x365 with guaranteed levels of network performance.  Check Netctaft for most reliable web hosts.

12. Monitoring

Any managed hosting solution will include monitoring of your environment.  At the very basic level it should include monitoring of availability and the overall health with alerting to 24x7x365 support teams who can deal with problems promptly no matter what time it is.  This monitoring can even go more in depth depending on the host, right down to the application or transactional level.  Adding this on your own would cost extra to implement and you would still need people to respond to any generated alerts or emergencies.

Hopefully you have seen the advantages of outsourced hosting vs. In house hosting. There’s certainly a lot to consider.  If you have any future questions feel free to leave a comment or email me at rgiunta@inetu.net

Below are a few Gartner resources which also run through the whys and hows of outsourcing vs. building yourself:

http://www.gartner.com/it/content/1580100/1580115/april_7_best_data_center_sourcing_model_rjones.pdf

http://www.gartner.com/4_decision_tools/measurement/measure_it_articles/2002_04/webHost.jsp

The principle around Multifactor authentication is that you are authentication yourself to some system via different factors.  The factors available are as follows:

• Something you know
• Something you are
• Something you have

Most people are aware of the “Something you know”.  This is typically something that the true user would know.  Like a user and password to their account.  Seems secure, and would only be known by the “true” user, right?  Well, not exactly.  How many people out there have given their password to someone else for some sort of use, or for that matter, have it saved somewhere for future reference?  You may have a password stored somewhere on your computer, which would seem secure.  But, if that gets compromised, then that “true” identity is no longer guaranteed to be you.  I bet most people have, and that is what compliance certifications like PCI and such are looking to correct.  By incorporating an additional security authentication factor, they can better guarantee you are who you say you are.  Of course, it gets very hard to guarantee 100%, but as you add factors, it gets pretty darn close.

The other factors which are not as common are something you are and something you have.  Something you have would be an item which is given to you, and is unique to you.  This unique item would be something like a certificate that is issued to you, or some sort of hardware token.  Hardware tokens like RSA key or Yubikeys from Yubico are examples of hardware tokens.  These hardware devices issue OTP (one time passwords) that are unique to that token and unique to you.  Most corporations use this factor for accessing items remotely via a VPN.  So the combination of the Certification/token along with your username/password would provide 2-factor authentication.  Now these 2 items are much more secure than just a username/password.  A hacker/identity thief would not only need your username/password to get in, but also have that unique token you exclusively have been given.  So it gets harder for the identity theft to occur, but not entirely impossible.  For real serious security situations, a 3^rd factor is required.  This factor is something you are.

Something you are is pretty much as it states.  It is something that physically identifies who you are, and is unique to you.  So something like a fingerprint, hand print, retina check to name just a few, would uniquely identify you are who you are.  These are often used in highly secure datacenters to gain access.  Typically, the process would involve a badge/token you carry (the something you have), along with a fingerprint/hand print (the something you are), and finished up with a password of some sort (something you know).  As long as all those security factors succeed, you are more likely to be the person you say you are compared to just a single factor method.  It’s not 100%, as you can often see in some big action films in Hollywood, which multi-factor authentication is broken routinely.  These are often a little far-fetched, but the idea around how they get around it, are usually somewhat sound.

So, based on that information, hopefully you can see the benefit in the multi-factor authentication, and that the security companies are not crazy for requiring it.  It does truly make a more secure proof of identity, but doesn’t ever guarantee it.  I would definitely recommend implementing as many factors as your organization can possibly deploy.

One of the great things about late-model load balancing hardware is the ability to balance on data from the application layer (layer 7 of the OSI model).  Traditional load balancers balance traffic based on the virtual IP that was assigned to a cluster.  Requests sent to the virtual IP are routed to a destination based on the algorithm used on the nodes in that cluster.  With layer 7 load balancing, specific information within the request itself can be used to balance the request to the appropriate destination.

INetU used this technology primarily on our Cisco ACE 4710 load balancers.  This dedicated network appliance is capable of various layer 7 functions, ranging from simple keyword or response code health probes to full-fledged layer 7 load balancing.  A common example of request-based decision making is static content hosting. Images, style sheets, scripts and so on may be served up by a content delivery network that is standalone from an application platform. To implement this, we can simply create a classification on the load balancers as follows:

class-map type http loadbalance match-any PICS
3 match http url /*.jpg
4 match http url /*.png

When the above is assigned to a policy map in a config, any traffic that matches the pattern will divert it to a serverfarm unique to that traffic.  Any traffic not matching will be routed along the standard path to one of the many application server nodes it resolves to based on the conventional distribution algorithm.

In addition to the matching strings within a web request, the load balancer is also capable of injecting its own headers into the request.  This is useful for two reasons.

First, it allows us to configure session persistence based on cookies instead of traditional IP based sticky sessions. Traditional IP based sticky sessions will require the load balancer to generate and record a session based on the source IP address, regardless of how many users are connecting from that IP. Cookie based sticky sessions will allow the load balancer to differentiate connections based on more unique information than the source IP. This allows for greater load balancing accuracy since IP based persistent sessions do not account for proxies. The load balancer can also inject its own headers to keep track of which node a session is associated with.

Secondly, header injection is necessary when the load balancer is utilized for SSL termination.  Offloading SSL connections requires layer 7 load balancing functionality to decrypt inbound traffic; however the load balancer also gains the ability to inject information like source IPs using custom headers after the packet is decrypted.  This behavior is essential for one-arm load balancer configurations.

While the use cases are still fairly limited, this functionality of layer 7 load balancing does open up many possibilities for future use.  As this technology evolves, we will gain the ability to balance additional types of traffic more intelligently.

Explaining the EXPLAIN was the first talk of the two. Ronald Bradford used this presentation to discuss how the MySQL Query Optimizer develops a Query Execution Plan (QEP). He pointed out that EXPLAIN will only work on SELECT statements. This means you may need to re-write a query into a SELECT using WHERE. It’s interesting to note that the QEP is generated every time MySQL actually processes a query. There is no way to guarantee that a query is run in the same fashion as the QEP provided using EXPLAIN but chances are good. I learned that based on how your query is formed and how your tables are built, there are times where MySQL might just completely re-write your query to get the results you are looking for, and the resulting queries could be very expensive.

The second talk was called Idiosyncrasies of MySQL That Bite, also by Ronald Bradford. A lot of what he talked about here was actually familiar to me, but there were some extremely valuable insights that came from his time working with databases in general. For instance, I knew that the default date for a DATETIME column was all zeros, but I never considered how badly this could affect critical data where MySQL has replaced malformed dates with the default. I also never thought about how a misspelled “`ENGINE=InoDB`” or charset mismatch could completely change the way perfectly normal queries could run.  Luckily, MySQL has the SQL_MODE variable which can be used to modify most of this kind of behavior.

Both talks were valuable to me, partly because in each one, the speaker showed us some very interesting quirks to look out for in MySQL, and what to do when you see them, or how to even prevent them all together. He did it in a way that was fun, and easy to understand. I hope you were able to take away some tips as well.

Day 1 was filled with tutorials on many different topics related to administering database servers using MySQL ranging from security to troubleshooting and performance tuning. There were so many to choose from, and we found the biggest problem was choosing which talks to attend.

Peter Zaitsev (Percona CEO) had a tutorial on InnoDB and XtraDB specific performance optimizations while Sheeri Cabral (Mozilla) went over some ways to secure the database and verify security using the same tools that black hats would use. After lunch, Rene Cannao (PalominoDB) discussed measuring performance with proper benchmarking and profiling, and showed specific cases where using the tools he introduced, led to a quick resolution of otherwise difficult to diagnose problems. Baron Schwartz (Percona) also discussed ways to more effectively manage MySQL using the Percona Toolkit while Florian Haas (hastexo) discussed High Availability solutions with Yves Trudeau (Percona).

Day 2 was filled with talks that drilled down into the inner workings of different parts of MySQL, and tools available to help administer more effectively. Ronald Bradford (Effective MySQL) gave a talk on how the optimizer makes decisions, and tools used to predict and understand the choices made while Baron Swartz (Percona) discussed ways to measure scalability and performance using TCP. Other talks included ways to implement full text search, connector specific tuning tips, and backup strategies for larger datasets. We also got a chance to see what’s coming in future versions of MySQL which was really exciting.

On Day 3, Sam Ghods (Box) showed why his company decided that MySQL is still the preferred choice for mission critical data over the new trend of NoSQL, and Representatives from HP, Clustrix, Amazon, McAfee, and Akiban discussed several aspects of the future of MySQL.

In addition to all of the knowledgeable speakers, we also got to walk around the Expo Hall and learn about products that can improve performance by speaking with vendors from many of the sponsoring companies. Infobright and Tokutek showed how their storage engines could help specific use cases in speeding up query times, demonstrating the often forgotten pluggable nature of MySQL. We also met with several hardware vendors offering solutions to improve scalability and performance through caching, replication, and solid state storage options.

This was the first year that Percona led the event since Oracle took over MySQL development, and in my opinion, it was a huge success. We all learned a lot and got a chance to network with the people involved in the development of MySQL and other products related to data storage. I am looking forward to using this information to better assist our clients with their specific needs, and can’t wait to see what comes next in the MySQL ecosystem. Next week I’ll tell you specifics about two useful talks at Percona. Make sure to check back next week. Click Here to read My SQL Tips from Percona Live 2012.

The internet continues to play a key role in simplifying business practices in all industries. The  health care industry is no exception. Many health care organizations are finding it necessary to place Protected Heath Information (PHI) or electronic Protected Heath Information (ePHI) online.  One extremely important factor that health care organizations need to consider is that PHI is covered under the HIPAA and HITECH acts which need to be handled very carefully.

What is HIPAA?

The Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996 to provide privacy standards for the protection of patients’ medical records and other health information supplied to health plans, doctors, hospitals and other healthcare entities.

What is HITECH?

The Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 extends HIPAA coverage by addressing third-party access to protected health information (PHI), increasing compliance obligations and strengthening enforcement penalties.

Why is it Important to Comply with HIPAA and HITECH?

HIPAA and HITECH compliance is imperative to preserve your ongoing business operations.  Failure to successfully meet the standards may result in not only regulatory actions, such as fines, but also loss of business, damage to reputation and loss of public trust.

How to Protect Your PHI?

Organizations looking to transmit or store PHI on the Internet should take a multi-layered approach to their data protection. Here are some areas to address:

• Servers – PHI should be hosted on dedicated servers with hardened operating systems
• Security patches need to be kept up to date. Hard passwords should be used for all login
• Firewalls – A Dedicated Firewall is required
• Intrusion Detection Software should be run to log traffic to and from the servers
• VPN is necessary in most cases, as it helps encrypt data transferred between two locations
• Software - Software should be installed on the server to track changes to files and logwho made a change to and/or viewed PHI, from where and at what time
• Storage – Since PHI and records of access to PHI need to be stored for a minimum of 6years; a backup retention strategy should be put in place that meets that requirement.Typically this will involve off-site archiving of backups. Encryption should be used on PHI and related data stored on portable media

If you need help with HIPAA and HITECH compliance make sure to find a trusted web host who has the right knowledge, experience, and security tools to continuously safeguard your PHI.

Sometimes the precautions don’t always work. No one ever wants their server to be hacked or compromised, but unfortunately it can and does happen. With a little preparation, you can quickly respond to a hacked server so you can smoothly recover your server – ultimately limiting the amount of data exposed or lost and minimizing your downtime. Below are 6 steps that you should immediately do after your server has been breached; they don’t have to be completed in order but will definitely help in mitigating future risk.

Step 1: Know Who is Involved – Of everyone responding to the security threat, make sure everyone knows what their own role is and what the roles of others are. Understanding how to communicate amongst each other will help all of the subsequent steps.

Step 2: Assess the Scope – Understand what has already been observed, what has already been done and what is currently happening. This quick assessment will help determine which steps should be performed next and in what priority to prevent future network security issues.

Step 3: Contain the security breach – These immediate steps will help prevent further damage or information loss. If the attacker is actively on your system, you may need to kill their processes immediately to limit further damage. This may involve blocking the network to a specific block of IP addresses, especially if data is actively being streamed off of the server to the attacker’s machine.

Step 4: Maintain State – Your classification and impact analysis of the compromised system will help determine if the security breach should be contained or the state maintained first. For further forensic work, it is best to leave the system unaltered (or as unaltered as possible). You can copy log files or take an image of the disk for further analysis. This also prevents the attacker for altering the logs.

Here is a simple example of how to clone a block device or partition: On the secure system, run nc -l -p 9999 | dd of=/dev/incident-xyz.dd. Then on the compromised system, run dd if=/dev/sda | nc <ip of secure system> 9999. You can also use dcfldd, which provides hashing on-the-fly among other useful features. To limit the amount of empty space being transferred, you can also use gzip between dd and netcat on both servers.

Step 5: Notifications – Follow the appropriate process for notifying the impacted, may include PCI or HIPAA regulations or federal and state laws depending upon the nature of the data exposed (or potentially exposed).

Step 6: Remediate – Putting the same vulnerable hacked server back online will likely only lead to another incident, so any workarounds or patches should be applied before bringing services back online. This may include data integrity checking or a complete system re-install.

Throughout this process, make sure you communicate with the rest of the team, keep a cool head, make sure you document what you are observing, and what actions are being taken with your network security issue. If you believe your server has been compromised and still don’t know what to do let us know, we can help.

Interested in attending a hackathon? This upcoming weekend INetU is sponsoring a hackathon located in the Lehigh Valley!  We still have some Lehigh Valley HACK 2012 tickets available so contact us if you’d like to attend! Lehigh Valley HACK 2012 is the first of its kind to make it to the Lehigh Valley, so we are enthusiastic to be a sponsor. Join us at this local event to show off your talent.

Lehigh Valley HACK 2012 is a 3 day event that brings together local start-ups, entrepreneurs, software developers, hackers, and technology enthusiasts. A hackathon isn’t stealing people’s personal information; it’s where small teams of software developers and designers combine their powers to develop a new software application. The event will be held at Lehigh University’s Mountain Top Campus in the Ben Franklin TechVentures starting at 6pm on Friday March 30^th and ending at 5pm on Sunday April 1^st.

The hackathon attendees will build, share, and demo a project that they have feverishly built over the weekend. The teams will be present their applications on Sunday April 1, 2012 between 1-3pm.  The top team will be awarded prizes for various categories. The presentation and judging time on Sunday is open to the public, so if you are in the area and are interested in attending, be sure to stop by!

For more information on the event visit: http://hack.lehighvalleytech.org/

“This security update resolves two privately reported vulnerabilities in the Remote Desktop Protocol. The more severe of these vulnerabilities could allow remote code execution if an attacker sends a sequence of specially crafted RDP packets to an affected system. By default, the Remote Desktop Protocol (RDP) is not enabled on any Windows operating system. Systems that do not have RDP enabled are not at risk.”

The bolded text was added by us.  Security vulnerabilities with the potential to allow remote code execution are some of the most severe around.  This means that given the appropriate sequence of packets, an attacker could do anything from creating their own users to simply shutting the server down, without providing as much as a password. Due to these threats, secure data is a must!

Microsoft released a patch for this vulnerability the same day as the security bulletin, and if your servers are currently configured to perform automatic updates, you are likely in the clear for this particularly nasty hole.  However, if you are managing your patches yourself and haven’t gotten around to addressing this one, it would be in your best interest to do so as soon as possible.

At the time the patch was released, no functional exploit code was available.   Since then, however, several IT security professionals have been working to develop a proof-of-concept exploit to take advantage of unpatched systems.  The demand for this exploit even grew so great that a $1,500 bounty had been offered to the first person or team to provide a functional Metasploit security plugin.  Simply the amount of buzz around this vulnerability should be enough motivation to apply the patches as soon as possible.

A security vulnerability with such potential for damage doesn’t come out very often, but when it does, it’s a pretty big deal.  For those of you hosting with INetU, contact support to find out if your server has been patched yet, and if it has not, we can schedule a time to do so immediately.  For those of you hosting elsewhere, you too should make an effort to see that your Windows servers are safe from this vulnerability and other security issues.

Microsoft is designing one operating system for laptops, desktops, phones and tablets. The New ‘Metro’ design is a big change and risk for Microsoft, similar to the Ribbon interface in Office applications, or the big changes seen with Windows Vista. Some will love it and others will hate it, that’s the nature of change.  Here’s what the Metro user interface will look like:

I think overall the Metro interface looks very promising for things like Kinect, Windows Phone and upcoming windows tablets. Touch screens work very well with the new interface and over all things seem to flow pretty nicely. But it may take some getting used to on your PC.

Now what everyone seems to be concerned with is on the desktop and laptop, and the business user. There is no Start button and no easy way to completely turn off the Metro interface. If Windows 8 ends up not supporting a Windows 7 style desktop there will be a tough learning curve and many businesses may skip windows 8.

The new OS of course has dozens and dozens of tweaks and improvements. It should run on any system that can support windows 7, and you can download and test Windows 8 in a VM or on a physical machine now if you like. The OS is going to hook into the cloud more with integration into SkyDrive. You will be able to sign into the computer with your Windows email addresses and there will be a Metro apps ‘App Store’, just like the Apple and Android stores.

Time will tell if the Metro interface ends up being a popular choice and what additional changes Microsoft will make before Windows 8 is released in its final version. Keep your eyes peeled, many say Windows 8 will be released around October 2012!