Wednesday, January 20, 2010

Section 6.2.  Evaluating In-House Expertise










6.2. Evaluating In-House Expertise



In an ideal world, every IT organization would have the expertise to execute the COBIT guidelines and implement the necessary open source or proprietary tools identified in this book to obtain compliance with the Sarbanes-Oxley Act. However, as we all know, this is not the case. As a general rule, an IT organization's skill sets and expertise are usually related to its current environment, and not necessarily to another IT discipline not contained within that environment, or introduced by Sarbanes-Oxley. Since the focus of this book is how to effectively use open source to obtain compliance with the Sarbanes-Oxley Act, and since open source primarily runs on Linux and UNIX-based operating systems, any organization that would like to avail itself of the majority of the open source tools should have minimum level of expertise in these areas.


If your company has already deployed open source in your organization to any significant degree, you probably have the necessary expertise to evaluate and implement the necessary open source tools to assist you with your Sarbanes-Oxley compliance. If your organization does not have the aforementioned discipline and/or you are uncertain about your organization's expertise level, it does not necessarily prevent you from taking advantage of the open source tools listed in this book or open source tools in general. However, what it does mean is, prior to committing to open source as part of your Sarbanes-Oxley compliance efforts, or to assist in fulfilling some of the COBIT guidelines, you will first need to determine what skill sets you have in your organization and whether they are adequate. When evaluating the necessary skill set, you will need to look at two general aspects:


  • Linux and UNIX experience

  • Open source experience


It may appear somewhat peculiar to some of you that we've separated Linux and UNIX experience from open source experience, as Linux is considered open source. However, in the context of this discussion, when we say "open source" we are referring to applications versus operating systems, where the expertise needed for each category may be slightly different. We do not want to deter you from using open source by any means, but rather leave you with the knowledge that you might have to consider your options for in-house staff and outsourcing.



6.2.1. Deployment and Support Proficiency Considerations



To properly evaluate the expertise needed to support open source, you must examine your existing infrastructure and determine the extent to which open source will play a part in your overall strategy. One of the advantages of Linux, for example, is that if deployed for a specialized purpose, such as Web servers or databases, there tends to be very good setup and support options for these applications. However, if Linux is going to be deployed on your desktops, the skill sets required to maintain adequate levels of support might be quite different. Universally, it is desirable to have a staff knowledgeable in both operating systems and the applications you plan to deploy and support in your organization, but since this may not be realistic or even necessary, there are a few things to keep in mind. Figure 6.1 depicts the external support options typically available to open source.



Figure 6-1. Open Source Support Stack




At the top of the support chain are large enterprise vendors such RedHat and Oracle. If your intention is to deploy these distributions and applications, the importance of in-house expertise might not be as critical due to the availability of vendor deployment expertise and support contracts. As we covered in Chapter 4 ("Why Open Source?"), often the primary developers of an open source application offer paid-for installation and support, good examples being Sugar CRM and MySQL. Finally, there are companies that specialize in open source support, providing consulting for a wide variety of applications you might want to deploy in your organization. However, your selection may be limited depending on your geographical location, since these companies tend to be local or regional. By far the most common avenues for support are community driven via documentation (some being better than others), mailing lists, forums, and discussion lists. From a SOX perspective, the majority of applications you might considersuch as eGroupware, Nagios, LDAP, Samba, and Webmin (all examples that we use in this book)all have very good to excellent documentation and support channels. Depending on your deployment goals, general skills you will be looking for include:


  • A solid ability to roll your sleeves up and dig in to solve problems that arise. While the mature projects in open source have good documentation and best-known deployment practices, much of Linux and open source can involve trial and error to adapt to your specific needs, which is why the need for an adequate test environment is important and discussed later in the chapter.

  • A good understanding of TCP/IP, networking, and the Linux Standards Base (www.linuxbase.org/), which outlines the general layout of a Linux system so you know how and where configuration files and data are generally stored.

  • Solid research skills to navigate forums, mailing lists, and Internet resources, an important addition to any good system administrator, regardless of platform, and open source is no different.

  • From a SOX perspective, a very good understanding of security in general, OS hardening, PAM/NSS, and file and application security to ensure that your deployments are rolled out in a secure fashion (more on this in Chapter 7, "Domain 3: Delivery and Support").



Tip: To evaluate someone's Linux and open source skills, give him or her a standardized test such as the A.P. Lawrence's Linux Skills Test, which can be found at http://aplawrence.com/Tests/Linux.



6.2.2. Addressing Deficiencies




If after evaluating your in-house expertise you determine that deficiencies exist, there are several ways to effectively address them, each approach with its pro and cons:


  • If time and resources permit you can elect to train existing staff. This could be the best long-term solution, but because of the steep learning curve, mistakes could be numerous in the short term.

  • If budget and management allow, you can elect to hire consultants, which would address your short-term requirements and potentially your longterm requirements. The caveats to our previous statement are 1) you will need to ensure that you source qualified consultants, and (2) the consultant you elect to use should have a methodology and planning for transitioning the new environment to your in-house staff.

  • If budget and management allow, you can elect to hire additional resources to fill this requirement. However, hiring an unknown entity under these circumstances may add more risk of failure to your process.

  • A combination of any of the preceding points.













No comments: