Remote support software or remote desktop support software are applications that allow the remote access of another device, typically a computer, for the purpose of controlling the target device.  “Controlling the target device” can have several connotations; while most remote support applications do permit the control of the target computer, some only provide viewing capabilities. By using remote support software, a user can troubleshoot another user’s computer with efficiency and ease.

The method of installation can vary widely between one remote support application and another. Some remote support software applications require both the client and the host to install a small program on their machines. Other applications only require installation on the host’s machine, and the client connects to the remote support session via a web page portal. Finally, a remote support application can be entirely web-based, connecting two machines via a single web portal. 

Remote support software applications can offer a number of features to assist a client.

1. Video recording - enables a host to send a client a video file of all actions performed in the session.
2. Chat - Allows a host to easily communicate with a client while the remote connection is taking place.
3. File transfer - Permits the transfer of files easily between the host and client quickly. A typical use model would be the replacement of a corupt file or installing new software.
4. Reboot/Reconnect - When your dealing with software you will often be required to shut down the PC and log back in. This feature allows the two computers to reconnect after the reboot occurs.

According to the UK’s Office of Government Commerce (OGC), the Information Technology Infrastructure Library (ITIL) Version 2 (v2) is finally being laid to rest. ITIL v2 was lauded as the “most widely accepted approach to IT service management in the world.” In 2007 ITIL v3 was launched with, a few major changes, possibly most significant a key shift in methodology by encouraging inter-department communication between IT and business teams. Having worked on both sides of this equation in different careers, I can attest that improved communication between these departments definitely needed addressing. But as we move into this new decade, let’s look back at some of the stats and the history of ITIL v2. 

• Some general ITIL Information
• A Google search for ITIL v2 returns over 353,000 results
• ITIL v2 was launched in tandem with BS 15000 which later became ISO/IEC 20000
• A Google search for ISO/IEC 20000 returns 226,000 results
• Some notable ITIL adopters: Microsoft, IBM, Cat,and Boeing

The blog IT Skeptic has worked out the cost to obtain full ITIL certification: $60k. This includes hourly rates for your time,travel, etc.  The actual cost, should you choose to obtain just the certification, is probably closer to $20k-30k.

ITIL began with a decision from the UK government recognized a need for a set of standards for IT infrastructure and management.  The original group formed to address this issue was the Central Computer and Telecommunications Agency (CCTA). The CCTA then produced the Government Information Technology Infrastructure Management (GITIM). Yes, that’s a lot of acronyms, but stay with us! So the GITIM lost the G and the M, improvised with library, and the ITIL was born.

History

1989 – ITIL v1, thirty volumes long, is released. 

2000/2001 – CCTA becomes the OGC, which is under the office of the UK Treasury. Perhaps the government suspected that IT service management would yield lots of revenue!

2000/2001 - ITIL v2 is released at a trim eight volumes long, since thirty volumes is a heavy load for a bookshelf!

2006 – The ITIL Glossary is released.

2007 – ITIL v3 is released. It is five volumes long, with a focus on communication with business teams. 

2009 – OGC announces the end of ITIL v2, and there will be no more books or certifications.

2010 – 1 year notification/warning from OGC

June 30, 2011 – RIP ITIL v2

AES stands for Advanced Encryption Standard (AES) and among many other use models such as the NSA, it is the encryption used by ScreenConnect to protect information between clients and hosts. The principal and requirements for AES were dictated by NIST (National Institute of Standards and Technology), however the ciphers themselves and much of the requirements were provided as part of feedback loop organized by NIST with experts and enthusiasts around the world. NIST had several requirements but the two most critical, that the cipher utilize a 128bit block size and have key sizes of 128, 192, or 256bits.

So why did NIST push for a new method to replace its existing DES cipher? Well that has to do with PC boom in the late 80’s and 90’s and the demand for larger amounts of data to be transferred securely. Some really smart people figured out that with a 64bit encryption that the chances of information leaking out would be very probably if the information packaged under one key exceeded 32GB. Therefore by moving to a 128 bit block length the opportunity for information leakage would not be likely until packets reached 256Exabytes which is considerably more than most people are sending today.

But what about brute force, is there a possibility someone can decipher the AES key? Deciphering an encrypted key is similar to figuring out a combination lock, but with a lot more possible combinations. The math is pretty straight forward but Wikipedia has one of the best examples I have seen to explain why breaking a 128 or 256 bit encryption is difficult to say the least. For our example we will ignore the power consumption of the computer assuming that it is possible for the computer to run long enough to crack the code and for the owner to pay the electricity bill. Instead we will focus on the time required to actually test all the possible combinations, but don’t forget even if they figure out the key they would still need software to apply the key, decipher the packet, and determine if the message makes sense. For a 128bit key all of the 2¹²⁸ possibilities would need to be checked. A device that can check one billion possible keys per second would have to run longer than the universe as theoretically existed in order to get close to cracking the code. That’s a long time in case anyone is keeping score.

Do you remember the shell game? The principal was quite simple; there is an object and three cups.  The owner of the game places the object under one of the three cups and then moves them around in what seems to be very unpredictable pattern.  The player has to watch the cup with the object and then find it when the owner stops moving them around.  Well these street games are not always fair, sometimes the owner cheats and removes the object or hides it through some sleight of hand.  But the principal of the game is about confusing the people watching, very similar to the way ciphers are used today to protect information. 

Claude Shannon in his paper Communication Theory of Secrecy Systems published in 1949 outlined the principals that still govern the general design of encryption systems today, confusion and diffusion.  In Shannon’s paper confusion is the process of making deciphering the ciphertext as difficult as possible unless you have the key.  The process involved replacing each character with a representing character or symbol from a lookup table.  Quite often the lookup tables would be quite elaborate not only taking into account the original character but also the neighboring characters and a host of other variables.  The diffusion would represent the next layer of protection, the redundancy of rearranging the characters and then running the ciphertext (the resulting text after the confusion layer) back through the lookup table a second or third time.  The result was a complex spider web of non-linear links and mathematical substitutions that is nearly impossible to backward engineer without the key. 

Mr. Shannon outlined the basic principals used by banks, government organizations, and little remote support tools like ScreenConnect to encrypt and protect information.  To learn more about Communication Theory of Secrecy Systems or Claude Shannon visit Wikipedia.org which provides a good overview of both and has links to other supporting sites.

Remote desktop support solutions provide users the capability to directly interface with a PC over an internal network or the internet for support purposes such as software updates, troubleshooting, etc. The majority of these 3^rd party solutions operate under the software as a service (SaaS) model, requiring users to purchase subscription based licensing to access the software. This has been the widely accepted model for the past decade with companies like LogMeIn and Webex implementing recurring costs ranging from $50-$100/month per user. These solutions have established a solid market and have a huge global customer base, but this model is not ideal for all companies. Small and mid-size businesses (SMBs) and even some large organizations often have a tough time incurring the high monthly cost and there are also the security concerns.  Regardless of the promises, documentation, and visibility provided some customers just do not like their information travelling through the server connections of 3^rd party companies, many military organizations and contractors have implemented their own solutions over the years specifically for this reason.

A result of these concerns has launched a new series of remote support solutions that are designed to be hosted by the user which means all security concerns can be managed internally and the overall cost of ownership is significantly less. With no annual or monthly costs, most users expect to see significantly less feature sets but that is not the case. Our product ScreenConnect provides

1. Support for Linux, MAC, and PC
2. Has screen recording capability
3. Manages UAC for Vista and Windows 7
4. Dual monitor support
5. Can configure theme and external appearance to match company branding
6. Logging
7. And much more

Will self hosted solutions be the direction of the future? Most likely many companies will still see value in hosted solutions, they keep things simple from an infrastructure perspective but you pay heavily for that simplicity. The hopes of tools like ScreenConnect is that we can continually make it easier for business and IT groups alike to adopt and that the cost savings will justify the transition.

ScreenConnect is a self-hosted remote support software solution developed by Elsinore Technologies.  Elsinore has produced several related solutions including Virtual Intercept and IssueNet both highly customizable and cost efficient issue tracking and management solutions.  As with most software development companies remote support solutions were required in order to assist customers with questions, providing consulting, and working on feature issues and enhancements remotely.

Our current solution a 3^rd party hosted model with monthly charges per user worked ok but the cost was significant and we had to direct customers to a different site to establish connections which wasn’t ideal.  The goal was to find a solution that provided the basic remote support capability and features, we required without having to pay for others that provided us little to no value.  We evaluated several solutions with 4 criteria:

1. We needed minimal software footprint on the client machine
2. A reliable solution that worked quickly and efficiently
3. We ideally wanted a self hosted solution so that customers would be directed to our site for support
4. Needed to work with Java , PC, and Mac clients
   

As we evaluated the remote support market we found several software tools with impressive feature sets but none that met all 4 of our criteria.  So since we couldn’t find what we needed we decided to build our own solution, ScreenConnect.

ScreenConnect is a self-hosted, cost efficient, remote support software solution with an extensive feature set.  The solution saved us thousands of dollars in monthly fees and provided us with a support model ideal for our customers.

With the transition from ITIL Version 2.0 to 3.0 and the increasing exposure of Microsoft Operations Framework (MOF) the terminology and organization of the terminology used in the industry is changing and evolving.  But am I confusing my customers when I use the old ITIL terms or am I confusing them worse using the new terms they have less experience with? I need a way to figure out what is still the same and what is different in ITIL version 2 and version 3.

So I looked out to the web to see if anyone had done a direct comparison of the terms and books of ITIL v2 and v3.  I found where someone had done a pretty nice write up and several other sources plagiarized the work; but, it was still all written comparisons and I wanted more of a diagram, a drawing, something with arrows!  I never found what I was looking for so between episodes of NCIS last night I resolved my problem.

So without delay here is the Elsinore Technologies ITIL v2 vs. v3 comparison diagram.  If you note any mistakes on my part please let me know and I will correct my oversight immediately.  Regarding the diagram ITIL v2 books are broken out on the left and v3 on the right, the type of arrow doesn’t matter I used a few different styles for aesthetics only, also I added the service desk and variations thereof to the Service Operations book of ITIL v3.

A higher resolution version can be downloaded from our Oversight website at:

ITILv2-vs-v3-Diagram

u5x47ith3m