Conducting the Decision Support Phase

The purpose of the decision support phase is to test risks that need to be mitigated against cost to mitigate the risk.  If the cost is too high to warrant mitigating the risk then risk must simply be accepted as part of the business.

Implementing Controls

The process of implementation of the controls determined to be necessary during the Conducting Decision Support Phase requires a risk plan of action to be drawn up and approved by the Security Management Steering Committee.  The plan involves every aspect of the business that will be affected by the new control or controls.  These must be made aware of the changes being made through the Change Management Process which I have already discussed prior on this blog.  Once all decisions have been finalized, all necessary parties notified, and any needed expertise inside or outside the organization acquired the control can be seemlessly implemented without a hitch that would negatively affect the companies business processes.

Maintenance

A security risk score card is developed by allowing for open feedback from all employees and all department heads about how well a security control is working.  This feedback allows us to measure the success the implementation of the control has had on the organization and reducing the mitigated risk.

Following regular maintenance should be regular reviews of possible risks that need to be controlled.  Reading books on the subject of security risk can help.  Also the company may choose to stay abreast of trends in the security field by getting on mailing lists that notify officials about possible security risks.  There are other options too that can be looked into in controlling risk and educating ones self about the risks currently under scrutiny.

Next up on Part 4 of this blog:  Establishing a Security Monitoring and Security Auditing Procedure

Works Cited

Service Management Functions: Security Management. Microsoft Corporation. 2008. Accessed 10/31/2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/mofsmsmf.mspx>.

Part 1 of this blog post identified the Microsoft Security Management Security Management Function and began breaking down its various aspects for you to help you become an informed reader about Service Oriented Architecture (SOA).  Part 2 is going to continue this discussion.  Information regarding this SMF was taken from the Microsoft Security Management SMF Guide located at http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/mofsmsmf.mspx.  For further information please consult the guide as it is quite detailed and will require much in the way of attention to detail.

Establishing a Security Risk Management Process

There are four activities that must be completed when establishing a security risk management procedure.  They are as follows:

• Assessing risks
• Conducting decision support—to identify and evaluate control solutions based on a defined cost-benefit process
• Implementing controls
• Measuring program effectiveness

For more information see the Microsoft Security Risk Management Guide located at http://go.microsoft.com/fwlink/?linkid=30794.  This risk management guide will break down the different necessary aspects of security management for you in more detail.  Thanks to Microsoft for making this information publicly available for different companies to review and bring themselves into SOA compliance.

To begin with Assessing Risk these questions need to be asked:

• What are the company assets which need to be protected from security threats?
• What events might negatively affect any of these assets on an individual basis?
• What weaknesses of the assets might be exploited?
• What is the extent of the potential damage to the asset?
• What current controls are in place to protect the asset or assets?
• What are some ideas that could reduce risk to the asset?

To determine the relative priority of each risk, it is necessary to consider the:

• Asset exposure and asset class combination to determine the overall impact on the business of a threat occurring.

• Likelihood, or probability, of a threat materializing within a certain amount of time.

It is the responsibility of the Security Management Team to keep a prioritized list of risks on hand and to regularly review the list to assure that nothing needs removed, changed, or added to the list. There are many tools available, some free and some with cost, that assist an organization in making this prioritized list.

See the Microsoft Security Management Guide linked to above for more information on possible ways of listing these priorities.

Part 3 of this blog post will continue this discussion.

Works Cited

Service Management Functions: Security Management. Microsoft Corporation. 2008. Accessed 10/30/2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/mofsmsmf.mspx>.

Recently ERP Business Center upgraded its WordPress version.  We apologize if there were any outages during the upgrade and have downloaded a maintenance widget to assist with future upgrades.  Thank you for your patience. 

ERP Business Center Administrator

Web design is a complex undertaking for any company to undertake.  Here at ERP Business Center we have decided to do just that.  Building websites takes planning and execution with proper code construction for future editibility.  It is not recommended that automated tools be used that jumble the HTML together, so that it is unreadable.  Using a qualified CSS (Cascading Style Sheet) HTML (Hypertext Markup Language) programmer will greatly ease the development and stress of developing your website.  Code construction needs to be done in such a way as that the code is readable.  Non-readable code can cause a great deal of problems when developing future website changes and adjustments.  Examples of code will not be listed here.  Our goal is to have you hire ERP Business Center to build your code for you and not otherwise attempt to sculpt the code together yourself.

“Building websites with readable code is a vital part of modern web design and is taught in all the major technical schools,” says Mike Harleman, Web Programmer for ERP Business Center.

Web construction also involves an understanding of certain other languages such as PHP or Java that require interaction with well developed websites. Many websites try to add in a bunch of flash animation, but slower systems find that the code is slow loading and frustrating to the user. Many consumers still use 56K dial-up connections. Mr. Harleman discourages the use of flash animation for that reason.

This blog post is taken from the Microsoft Security Management service management function (SMF) document located in the Works Cited section at the bottom.  Please reference this document for more detailed information about the Microsoft Security Management SMF.  What follows is a synopsis of this information.

Managing an organizations informational assets affects the companies bottom line; because, other companies prefer to do business only with reliable companies.  To do this a company must:

• “Assess business exposure and identify which assets to secure
• Identify ways to reduce risk to an acceptable level
• Design a plan for mitigating security risks
• Monitor the efficiency of security mechanisms
• Re-evaluate effectiveness and security requirements regularly”

According to the Microsoft Security SMF: 

“The Security Management SMF also relates to industry security standards and initiatives, such as the International Standards Organization (ISO) 17799:2000 and the IT Infrastructure Library (ITIL) Best Practice in Security Management.”

This information should concern both those in business and in technical roles of an organization, and specifically those who are considered to be organization leaders.  These would include operation and service managers, security managers, security administrators, and business managers.  The objective of this SMF guide is to explain what to do, not necessarily how it is to be done.  This should be noted when reading this guide and blog post. 

In addition to reading this blog post and the associated SMF document.  The Security Risk Management Guide should be read and understood.  This document is located at the following URL:  http://go.microsoft.com/fwlink/?linkid=30794.  This SMF document did not get into discussing various aspects of security management that are discussed in the Security Risk Management Guide document.

Also this document did not choose to debate in detail the different opinions on exactly what can be applied to various terms used within it.  It does, however, provide a definition for use with the document.  These precise definitions are beyond the scope of this blog post, but are addressed within the cited SMF document.

Security management processes involve establishing and maintaining an organization security policy, a security risk management process, security monitoring and security auditing processes, and an incident response process.  Security objectives fit into three possible classifications to identify them as security concerns:  Confidentiality, integrity, and availability.  If an item does not fit into one of these three classifications then it is probably not a security concern.  Data is not secure if it becomes corrupted, is not available to authorized users, or becomes available to unauthorized access.

To secure data we use different types of control mechanisms.  These include administrative controls, technical controls, and physical controls.  Administrative controls are policies, standards, and procedures.  Technical controls involve hardware and software used to protect systems.  And physical controls involve things like locked doors that control physical access to systems.  Control functions involve protection, detection, defending, recovering, and managing of data and systems.  Installing and maintaining anti-virus software would be one example of using a control.

Security must take into considerations the different layers of an infrastructure in something called the In-depth Defense method.  These are the physical systems, permiter, network, host, application, and data all housed within the policies, procedures, and awareness of the system.  With regard to the host level any network-based computer can be a host for attacks, and each one must have its own defenses to help contain the effects of an attack if one should occur at that particular host.  With regard to policies, procedures, and awareness the system must define what “information security” is for that particular organization by establishing its scope and importance.  These must state what the organization wants to achieve inlcuding goals for security.  They must deliver a concise explanation of the business reasons for implementing a secure environment, and position security within other IT service functions.  They must set expectations of security compliance, general standards for security management, and security policy violations, and organize the heirarchy of related security management documents such as standards and procedures.  And they must develop a program that sets up security awareness.

The SMF document defines the processes involved in security management as follows:

Establishing an Organizational Security Policy

An organizational security policy defines the organization’s security direction and goals and a security policy framework for developing protection strategies with related controls, processes, and mechanisms. The business benefits include:

•	Agreeing on a shared vision for security within the organization and commitment from key stakeholders.
•	Identifying the organization’s security requirements.
•	Identifying the levels of security required for data within the organization.
•	Identifying the security roles and responsibilities.
•	Implementing a regular review process to update security policies in line with business requirements.
•	Establishing an awareness of the importance of security and the rules governing it.

Establishing a Security Risk Management Process

By establishing an effective and regularly-reviewed security risk management process, an organization can ensure that it continues to use its security budget most efficiently to mitigate risks. The business benefits include:

•	Identifying, in line with business requirements, the appropriate level of security for specific information assets.
•	Determining the most appropriate and cost effective type of control mechanism to mitigate each security threat.
•	Establishing regular security risk reviews, to help provide continued protection to the organization.
•	Implementing the right controls for the most pertinent issues in the most effective manner possible.

Establishing a Security Monitoring and Security Auditing Process

An effective process for security monitoring and security auditing an environment will identify potential issues or security problems in an organization. Security monitoring focuses on evaluating system activity, whereas security auditing verifies compliance with corporate policies. Both methods help to ensure that security practices are within policy constraints. The business benefits include:

•	Identifying potential attacks or security issues as they occur.
•	Proactively identifying weaknesses in system configurations.
•	Providing consistent and accurate methods of reporting problems to the appropriate resources.

Establishing an Incident Response Process

An effective incident response process minimizes the impact of security incidents on the business. The business benefits include:

•	Ensuring that all staff know their responsibilities and understand how to respond if an incident occurs.
•	Providing a fast, structured, and deterministic response to security incidents.
•	Establishing the consistent and accurate recording of incidents and their resolution, which provides a body of knowledge that helps to resolve similar incidents and provides input to refine existing security controls and security policies.

All persons within an organization must follow security policies for them to be effective, and they should be written in a language that can be understood by all involved.  A vision statement must be established at the outset of developing security policies, and then a mission statement with clear dates must be set up that defines when things will occur to accomplish the vision statement.  Executive management should first develop a letter that sits on top of the security policy clearly outlining that all are to follow the policy and what the results of non-compliance will be.  Beginning with all inputs to policies required, the scope of an organizations security requirements must be determined following the establishing of the mission statement and executive letter.  This could be determined partially by examining the service level agreement documents the company has developed.

The company must also look at technology trends developing within the organization, so that they can be taken into account when developing policies.  They must define all legal requirements that the organization must meet before developing policies.  For example, a company that manufactures products must adhere to industry standards set out by ISO 9001.  In doing so, documented processes may be of a sensitive nature and fall under the protection of security management.  Also, security management must be careful to fulfill any contractual requirements set out in contracts the company has with others.

Data must be classified according to its level of sensitivity within the organization.  To develop a data matrix, a company must know more specifically what data is sensitive and what data is not as sensitive.  The matrix will describe in detail how much information must be managed by security management.  Data asset labels such as company confidential, private, sensitive, and public must be applied accurately to data.  The data matrix can further be broken down into time constraints.  One question that needs to be asked is:  would unauthorized access to the information mean a material loss for the company?  Once questions like this are answered, then a method of information handling can be set up to specifiy how information can be secured from location to another.

In policy planning, the structure must include format, implementation, and enforcement processes.  The security policy defines these characteristics and needs to have a table of contents and an index to be used for looking up necessary security policies.  A justification should be included for each policy, but this information need be available only to the security management team.  The policy plan must be available to all users, however.

With regard to the organizational security policy the SMF document states:

“The organizational policy provides an overview of the organization’s priorities regarding security, identifies the major security issues that face the organization, defines the security initiatives that the organization has undertaken, and provides a framework within which other policies are positioned.”

Organization policies come from organization standards and are less detailed then the standards.  Procedures contain the most detail and apply to specific pieces of information.  Procedures are updated most often, then standards, and then finally policies.  Building on this structure, there must also be a documented procedure for exceptions to policies which must be approved on a case-by-case basis.

So why is it necessary to have both a security administration and a security management SMF?  Note the following quote from the security management SMF document:

“Both management and administrator roles must exist in an information security organization. The primary function of management is to optimize the protection strategy, whereas the primary function of administration is to monitor the security of information systems and the handling of information.”

The specific roles and responsibilities laid out are beyond the scope of this blog post, but there are specific roles that must be filled by qualified staff.  (See the SMF document for details.)

With regard to awareness the SMF document states:

“A policy is of no use if individuals in an organization are not familiar with its contents. It is also important that staff understand how the policies affect them and their job roles. Creating a security awareness program to keep system users up-to-date on changes and new policies is another aspect of a successful security program. The objective is for all staff to be given the appropriate level of security training for their job roles. In addition to developing understanding of the security policies, staff must be aware of the consequences of failure to comply with security rules.”

System administrators and managers require further training as they have access to sensitive and company confidential information on a daily basis.  When handled on a daily basis like this, this information is at a high level of risk.  It must be assurred that managers do not remove security constraints simply to make their jobs easier and put company information at risk.  Communication policies must be also set up for the communication of policies when a security breach occurs.  Who should be notified and how is an important part of security management.  In doing this a formal risk management process must be set up within the organization.

Establishing a security risk management procedure will be discussed in Part 2 of this blog post.

Works Cited

Service Management Functions:  Security Management.  Microsoft Corporation.  2008.  Accessed 3/18/2008.  <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/mofsmsmf.mspx>

The following is a synopsis to the Microsoft Security Administration SMF located at the document listed in the Works Cited section of this blog post.  Feel free to consult this document for further information about the security administration SMF.  With systems being what they are today, a security breech is almost certian to occur if necessary security precautions have not been taken.  The SMF breaks down the security management process into its components as follows:

“Identification.  Identification is concerned with the user names and how users identify themselves to a computer system.

Authentication.  Authentication is concerned with passwords, smart cards, biometrics, and so forth.  Authentication is how users demonstrate to the system that they are who they claim to be.

Access control (also called authorization).  Access control is concerned with access and privileges granted to users so that they perform certain functions on a computer system.

Confidentiality.  Confidentiality is concerned with encryption.  Confidentiality mechanisms help ensure that only authorized people can see data stored on or traveling across the network.

Integrtiy.  Integrity is concerned with checksums and digital signatures.  Integrity mechanisms help ensure that data is not garbled, lost, or changed when traveling across the network.

Nonrepudiation.  Nonrepudiation is a means of providing proof of data transmission or receipt so that the occurrence of a transaction cannot later be denied.”

• Auditing.  Auditing is concerned with identifying when and where a security breach has occurred.  “Proper audit settings generate an audit log that can help administrators pinpoint the location and perpetrator of the breach.”

When accessing a computer system a user must first be identified by their user ID.  It is vital that good naming conventions be used when establishing a system for user IDs. 

Following identification, a user must be authenticated by use of some mechanism.  This can be a password of course, but additional methods of authentication are available such as a biometric authentication system that identifies a person by qualities that only they possess such as a retinal scan or voice print.  A smart card can also be used as a method of indication where the user is identified by a card about the size of a credit card in addition to needing to know account data such as a password that authorizes use of the card.  Setting up excellent password naming requirements is very important.

A user should be able to access only the necessary functions to perform their job and no more.  A warning should be posted on the login screen stating clearly that the use of the system is limited to business and not to be used for personal things.  In this way even though a user may not read the document, they cannot say that they were not warned about unauthorized access.  User accounts should not be shared with other users.  By specifying that a user ID is proprietary, it is easy to identify what user causes a particular event to occur in security logs.  Also a user should be limited in the number of times that they can attempt to login before they are locked out of the system and an administrator must reset that password.

Users must be prepared and educated on locking their systems before leaving their work station to avoid unauthorized use of their user accounts.  Access roles should be set up that allow a certain group of users to access the system to do their jobs and only their jobs.  Communicatons with the system should be encrypted to avoid unnecessary viewing of confidential data.  Stored data should also be encrypted, so that should a computer component be stolen the information cannot easily be accessed.

When it comes to data integrity, the objective is to ensure that data comes from the source intended.  Therefore, virus software must be installed that prevents a virus from corrupting system data.  Nonrepudiation will ensure that log files are maintained that identifies a user and the access they have chosen to use.  This assists in the prevention of security breaches.

Building a good auditing plan assists in nonrepudiation.  Auditing must be done selectively in order to avoid overburdening the system with security log information.  A good auditing plan will assist in this regard. 

Works Cited
Service Management Functions: Security Administration. Microsoft Corporation. 2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfsecad.mspx>

Testing the Release

Before a change can be released into the production environment, the release must be thoroughly tested to ensure that it meets all necessary requirements.  The ability to back out a release should be given intense testing to be certain that if a release needs to be backed out or rolled back it can be done.  A testing facility must be created that effectively mimics the production environment.  Cost considerations will be taken into account when planning and developing a test environmnet, but it must mimic the production environment as much as possible to allow for accurate testing.

A testing facility is maintained by the test manager.  All changes made to a testing environment must go through the change management process, and the testing manager must keep testing the environment configuration information records in the configuration management database (CMDB).  Testing must continue until confidence has been built up in the ability of a change release package to be backed out if necessary and that it meets the requirement necessary for the change.  Once testing is complete it will be necessary to restore the test environment so full backups must be maintained in order to do this restoration.

Pilot Testing

Despite the level of testing done in the test environment it will still be necessary to run pilot tests in the production environment to ensure the success of a change.  This allows for user feedback to be attained in order to determine how well the change release will benefit customers.  The SMF document located in the Works Cited section of this blog entry states:

“As pilot testing is carried out in production, it poses a number of risks to the availability and integrity of systems within that environment.  In this respect, the release team needs to secure the approval of change management before it can begin to implement the pilot test.  To gain that approval, the release team creates a document outlining the objectives or purpose of the pilot, the rollout (deployment) plan, and the backout process.  It also needs to describe how the pilot will be supported and the amount and type of user and support staff training that will be required.”

Acceptance of the Release

Once testing is completed the release must be accepted by all necessary parties.  These parties may include but are not limited to change management, release management, the change initiator, and a number of other SMFs possibly including partner management if a third-party needed to be involved in the development of the release.  If there are problems with the release then the release must be returned to change management to be reworked.  If problems exist, but it is still determined that it is necessary to deploy the release, all of this information must be recorded and documented.  All decisions and the reasons behind those decisions must be documented prior to implementing a release.

Roles in Release Preparation

The following is taken directly from the SMF document located in the Works Cited section of this blog entry.  It is vital the different SMFs and thier roles be understood, and I cannot do a better job of explaining this than Microsoft does:

• Infrastructure - Provides technical advice and guidance with the release preparation and supports training, logistics, and pre-staging of rollout.  Also provides input into the Release Readiness Review decision (milestone).
• Operations - Provides input into the release preparation that ensures it does not adversely affect the operational environment and ideally can be seamlessly integrated into operational working practices.  Attends training and provides assistance with deployment logistics and pre-staging.  Also provides input into the Release Readiness decision (milestone).
• Partner - Focuses on what a partner or third party is contributin to the release or where the release may affect work done by a partner or third party.  In these cases, provides advice and guidance to the release preparation activities and training resources and also provides additioanl resources for pre-staging activities and logistics to facilitate the deployment.  Also provides input into the Release Readiness Review decision (milestone).
• Release - Owns release preparation and the Release Readiness Review and coordinates the input from all other role clusters during this phase.
• Security - Ensures that release preparation does not undermine any of the organization’s security policies and guidelines.  Also advices on changes to the deployment plan to minimiz security risks.  Provides input into the Release Readiness decision (milestone).
• Support - Helps to ensure that the release is constructed in a way that ensures supportability during deployment.  Involvement primarily limited to assisting preparation to support the deployment.  Attends training and provides assistance with deployment logisitcs and pre-staging.  Also provides input into the Release Readiness Review decision (milestone).
• Service - Ensures the release preparation is aligned to service level requirements and provides input to the Release Readiness Review decision.

Interaction with Change Management

Only change management can approve needed changes to equipment and software that will allow for the implementation of a release.  The release manager will be certain that all necessary resources are available before an implementation takes place, and that change management has approved all necessary changes.

Once these steps have been taken it is necessary that all needed communication to prepare the company for the release has been put out.  Automated tools should be created that, for example, back up a users data prior to replacing a desktop machine so that as little user intervention as possible can be attained.  It is also necessary that any training needed be provided to the end-users of the system, so that they are not caught by surprise by the changes enacted.  Team members who will be maintaining and supporting the release will require additional training, so they can do their jobs effectively.  The SMF document states:

“Note that unless prior agreement is reached with the business, existing service level agreements must be maintained while support staff and administrators are being trained in the new release.”

It is vital that the entire organization or those affected bya release are prepared prior to the release being implemented to support and use the new release.

Backups Are Vital

Backups of necessary resources must be prepared ahead of time in case a release needs to be backed out and the IT infrastructure returned to its previous state.  This requirement cannot be emphasized enough!

Release Readiness Review

The release readiness review is that last step before a release is moved into the production environment.  There are several things to consider during this review such as determining that all necessary sign-offs have been filed and many others.  This review is discussed by Microsoft in its own document maintained at http://www.microsoft.com/mof called the MOF Release Readiness Review, and it is recommended that those who need to review this document and understand it in its entirety.

Deployment

It is best not to make a deployment available to all users when the release is first deployed.  Making it available to a limited number of users reduces the level of risk during deployment.  All user training should take place shortly before the release is rolled out.  If training is done a long time before the users are able to use their new skills, then refresher course may be necessary, so for this reason training should occur shortly before the release is rolled out.  It is helpful to deploy the release outside of normal business hours.  This way less strain is put on normal service level agreements (SLAs).  All changes to the IT infrastructure must be recorded in the CMDB (configuration management database).  All information about the deployment must be documented carefully including anything learned during the deployment about the release.

Following the deployment the release manager should review the deployment to ensure it was successful, and it has resolved the issue for which it was deployed.  While the release manager may be able to get some of this information from tools available, the release manager should also have the service desk check with users to determine if the release has been successful.  If a problem did arise, problem management needs to be called in to find a root cause, and if necessary the release can be backed out with the plan put in place for such an event.

If the releaes was successful then the release can be closed and a check to be sure all necessary information has been recorded in the CMDB should be done.  While the change manager holds a key position in reviewing and in developing a release the actual release plan is done by the change owner.  The change owner is also the single point of contact for the change advisory board (CAB) keeping them apprised of what is going on with the release process.  The communications coordinator is responsible for all necessary communication about the release, and must build confidence in the release.  The coordinator must have necessary authority in the company, and must have excellent verbal and written skills.  The documentation coordinator ensures that all documents are updated and distributed prior to a release to necessary parties.  The testing coordinator maintains the test environment needed to test releases, and communicates about any failure during testing to the release manager.  The change advisory board (CAB) will make any decisions that affect the IT organization and accept or reject any RFCs that are generated.

Release management must provide a package for releases for all changes that are deployed into production.  Release management requires that change management approve and track changes throughout the release process, and that configuration management assess the impact of changes to configuration items and provide a definitive store for the release package.  Release management ultimately affects all other SMFs as releases are rolled out into their area.

Works Cited

Service Management Functions:  Release Management.  Microsoft Corporation. 2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfrelmg.mspx>

Release management is contained within the MOF changing quadrant.  It is designed to package and release changes to the IT environment and is also responsible for working with change management to be certain that a release has been tested fully before being released into the production environment.  Release management makes sure that the quality of the release, release package and production environment readiness, training and support plans, rollout and backout plans, and risk management plan are all ok before releasing a change into the IT environment.  Release management also works with configuration management to be sure new releases are updated in the configuration mangement database (CMDB). and that a good test environment is built and used to test a release package before releasing it into the IT environment.  Release management also, “Needs configuration management to assess the impact of changes to the IT environment and to provide a definitive store for the release package, ” as stated in the release mangement SMF document located at http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfrelmg.mspx.  This document located at the listed link assumes that a person understands and is familiar with the technical aspects of MOF and has a basic understanding of how the different SMFs funciton.  A complete set of technical papers is included at http://www.microsoft.com/mof.  You may direct questions about the SMF guide once you have looked at it to msmfeed@microsoft.com, or you may direct questions about this blog post to m.harleman@yahoo.com.

The goals and objectives of this SMF are as follows:

• Plan releases in line with requirements resulting from approved changes
• Build effective release packages for the deployment of one or many changes into production
• Test release mechanisms to ensure minimum disruption to the production environment
• Review preparation of the release to ensure maximum successful deployments
• Deploy the release in line with structured implementation guidelines

These goals and objectives are directly taken from the Microsoft’s Operation Framework service management function guide located at the link listed under the works cited section of this blog entry for the release management function.  Release management has five sub-processes that follow this SMF guide.  They are release planning, release building, acceptance testing, release preparation, and release deployment in this order.  The release management process follows a request for change after it has been completed for release into the production environment.

Release Planning

The release planning phase involves determining the scope of a release, defining and prioritizing a release, planning and scheduling, determining the release team composition and roles, identifying training, logistics, and communication requirements, documenting the strategy for the release, determining if the release plan changes the requirements, and if it does change the requirements then moving onto the release building phase, or if it does not then returning to the release to change management to be modified.

In planning a release the release manager will need to have access to other SMFs in order to make out and incorporate a project plan.  These include infrastructure, operations, partner, security support, and service.  Infrastructure will provide technical expertise during the release planning.  Operations helps with advice and guidance on how the release can be implemented without affecting the day-to-day operations of the infrastructure.  Partner provides input on how to work with third-party and supplier-related releases.  Security provides advice and guidance on security issues.  Support helps with the expertise on how to ensure a fully supportable release.  Service offers advice and impact on service levels for the affected areas of the infrastructure. 

To begin with the release manager must determine the scope of the release.  That is how the change will affect the production environment and all of its components.  This can be determined by looking at the CMDB, however, if the CMDB is unavailable it is necessary for the release manager to have a good understaniding of the configuration of the infrastructure in order to make out a plan for the release.

When defining and prioritizing a release, it may be most prudent to combine two or more RFCs (requests for change) into one release in order to control the amount of time a system component is down during a release.  However, by keeping RFCs to one at a time, it helps keep down the risk to the production environment when a release is done on the infrastructure.  With regard to the tools used to keep track of changes and releases the MOF document located in the works cited section of this blog entry states:

“The fact that an RFC has been allocated to a release (and the release reference number) should be recorded. The technical needs of defining the scope of a release mean that any tool used on this function must cope with a range of release packages, covering everything from a single component up to a complex suite of interdependent components. The technology used within this space needs to be able to relate to the specific changes and construct release packages out of this. It also needs to have the ability to combine these packages into larger packages. Tools such as SMS can create software release packages that cover a large range of complexities.

As release packages are created, distributed, and implemented, the release team needs tools to track the status of the release and return this information to the change management system. SMS [Microsoft Systems Management Server], for example, provices a status system that provides information that can be extracted and fed directly into the CMDB.”

The release project plan should then be formed and activities for that plan scheduled in order to release the RFC or RFC packages into the production environment.  The complexity of the plan depends highly on the complexity of the RFCs.   The release manager may choose to delegate responsibilities for the plan to other personnel who will care for the release in their jurisdictions, however, the release manager must be responsible for the release ultimately.  The SMF dcoument encourages the use of Microsoft Project for medium to large releases to help in coordination of the efforts made to release RFCs of this size.  Remember that although the release manager can delegate certain responsibilities he/she is still the owner of the release management process and is fully responsible for ensuring that releases go smoothly.

The release manager is responsible for setting up a release team to install a release into the system.  If the release manager finds it necessary he/she may need to get a third-party provider to install a release or work on the release team if nobody has the necessary skill set to install a release.  He/she may find it necessary to bring in employees who are not under the direct control of the release manager in setting up a release.  If this is necessary then the release manager will need to have backups ready to fill the need if the person’s manager places pressure on them to work on other priorities.

When identifying training, logistics, and communications requirements the release manager may find that the resources to institute a release are not available at the time and may need to remove one or more RFCs from a release.  If this is the case the release manager needs to re-plan the release with the new structure.  In this way releases can be completed if the necessary resources are unavailable.  If this is found to be the case, the release manager may need to escalate a release to change management and the change advisory board (CAB) may need to review the release and make adjustments to it, so that it can be released into the environment with the necessary resources allocated to it.

The plan for the release must be documented by the release manager.  Things that need to be included in the plan are:

• Training requirements:  If training is necessary for certain staff then the cost of that training, when the training is to be done, how it is to be done, and the reasons for providing it must be documented.
• Support for the release must be documented in that the service desk and support personnel must be notified as to how they will support the release. 
• The release manager must draw up a plan that states how information is to be comunicated, to whom it is to be communicated, the methods by which it is to be communicated, the frequency with which it is to be communicated, and the requirements for developing and managing a feedback mechanism.
• In preparing the release the release manager needs to provide a roll out plan for the release, and a documented survey may be required that states the necessary resources exist to roll out the plan.
• The release manager needs to know and document the order in which a release is to be completed and regularly review the release to ensure that it is on target.  Changes to the release order may include additional cost considerations and the release manager needs to document these carefully before proceeding with a change to the release order.
• The release manager must be certain that the change advisory board (CAB) has approved the release plan before it is released into the production environment.  This approval must be documented, and then the release manager’s document must be placed in the change log for the RFC to ensure that everyone necessary can access the document.

Once the release plan has been completed the release will move to the release design and build phase.  The necessary tools, processes, and technologies must be developed to deploy the release into the production environment.  The design and build phase involves selecting the release mechanism, designing the release package, building the release package, testing the release package, and if the release meets the necessary requirements following testing placing a copy of the release package in the definitive software library (DSL) and updating the configuration mangement database (CMDB).

Infrastructure performes much of the technical activities associated with the construction of the release package.  Operations will provide input into the buildiing of the release package with testing and how it affects the production environment.  Partner has a small amount of involvement unless there is the need to call in a third-party.  Release management manages all the activities during the building of the release package and coordinates all roles involved.  Security provides advice on security issues.  Support will help with any expertise needed to test the release, and service will give advice on service levels and how the release may affect service levels.

When selecting the release machanism the release manager should try to use the most automated way possible so that the results are repeatable.  The release manager must plan for a way to back out a change if necessary.  The process may be automated where possible or the need may exist to simply document the process and keep the documents in a shared database or knowledge-base.  While performing one release manually may be the best answer such as wen releasing a critical patch, the release manager may find that the resources are too scarce to release every release in this manner and may attempt to automate more releases to maintain service level agreements (SLAs) with the business. 

When designing the release package all tools, procedures, and technologies necessary to deploy the release must be designed.  Again it is important the ability to back out the change be created as well when creating a release.  The SMF document states: 

“To ensure that the desing meets not only the technical requirements of the release, but is also an appropriate fit for technology strategy, organization requriements, and budgetary constraints, the desing should be agreed on by the release team and should be aligned to any strategic guidelines for release packages.”

When building the release package the ability to manually remove the package should be present or workarounds to the potential setbacks should be created. It is important to build the most efficient and cost-effective solution possible. Following this the release must be tested in a test environment to be certain that it meets all requirements. Once the release has been tested to satisfaction the release manager must call together a meeting of all critical stakeholders to review the process and assure all necessary approval has been attained to put out the release.

Definitive Software Library

All software configuration items must be kept in a secure place that requires the use of a web form to add or remove software components from the DSL (definitive software library). The DSL is a secure place to hold all software releases and is always made available to necessary parties. It should be replicated and maintained in different locations in order for it to be recovered in the event of a disaster.

In summarizing the release building process select a suitable mechanism for the change that is repeatable and consistent. Design and buld the release package for the change that allows it to be deployed successfully, and then test the release package to assure it meets all requirements. Finally ensure the release package is updated in the CMDB and that pending release packages and scripts are added to the definitive software library (DSL).

Works Cited

Service Management Functions: Release Management. Microsoft Corporation. 2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfrelmg.mspx>

In determining error resolution priority, it may be necessary not to resolve an error at this time due to various factors such as the phasing out of a system component or a future action that may resolve the issue.  In cases like this the error remains open and is not closed due to future incidents that may occur as a result of the error not being resolved.  Once this decision has been made, it is necessary for the problem resolution staff to regularly review the errors left open to ensure that any that are resolved by future actions are closed out.

Problem records should be linked to enable efficient tracking of the status of currently associated incidents, problems, and changes.  If it is found that an instituted change did not resolve the issue, then a decision must be made whether or not to back out the change.  If the change is, for example, the installation of a service pack that expected to resolve an issue, but did not resolve it, it may be decided not to back the change out due to the service pack’s resolution of other issues that may come up. If the change was reverting back to a previously installed version of a software package to resolve an issue and the issue is not resolved, it may be best to back out the change and return to the later version of the software to resolve other potential issues.

In closing out a problem record, the problem management staff must make sure that the problem details have been recorded, assign a closure category, close the problem, and notify incident management of the resolution if any open incidents are linked to the problem record.  Once notified incident management will perform any necessary actions to resolve issues they are handling and then the incidents will be closed.

The purpose of problem management is to provide a proactive analysis of errors being reported and identify trends that can be used to resolve issues before they become major incidents.  Trends can be identified by answering the following questions:

·         Is the number of incidents of a particular type increasing?

·         Is the number of incidents assigned a particular closure category increasing?

·         Is the number of incidents within a particular site or part of the infrastructure increasing?

·         Is the number of unresolved incidents for a particular category or sub-category increasing?

·         Is the overall number of unresolved incidents increasing?

·         Is the number of unresolved incidents assigned to a particular tier of the support structure increasing?

·         Is the number of unresolved calls increasing within a particular tier group structure?

·         Is the number of calls being resolved within a particular resolution group or tier changing?

Observing the following statistics can aid in noticing problems as well:

·         The number of incidents being logged at each priority coding.

·         The number of incidents being identified as “major incidents.”

·         The number of incidents reaching high priority at some stage during their life cycle.

It is important that certain types of reporting be done by the problem management tool.  These  include management reports on incident, problem, and known error numbers and trends, reports to the incident manager to help monitor the performance of incident management, reports for the service desk manager, reports to service level management, reports to managers of resolver groups, and reports to business managers.  When selecting a tool to be used for problem management the need for these different reports needs to be considered.  A tool that does not allow for producing these reports can seriously hamper the abilities of proactive problem management.

Reviews of major incidents and major problems should be done after these have been resolved to facilitate taking  a proactive approach to preventing future incidents and problems.  The SMF document listed under works cited lists out a full agenda for a major incident review that would be worth your time to examine, so as to understand what must take place when reviewing major incidents.  In both types of reviews, major incident or major problem reviews, a timeline needs to be created showing the different things that took place in resolution of the difficulty.  This timeline should be circulated to those invited to attend the meeting prior to the meeting so that all information is available for the review.  Major problem reviews will concentrate more on what took place then the timeline that things took place in while major incident reviews will be more focused on the timeline aspect of the incident.

Problem management must act as the arbitrator when disagreements over a major incident or major problem occur.  Problem management must have the authority of senior management to accomplish this role.  Inside the problem management SMF there are three different roles listed that must be fulfilled by support staff.  These are problem manager, problem support, and specialist support functions.  The specialist support function can be broken down into several areas of expertise related to the IT infrastructure.  Please see the SMF document listed in the works cited section for more details.

Problem management must work hand-in-hand with the service desk in order to accomplish its objectives.  Problem management must identify workarounds and resolutions that the service desk uses to resolve incidents that are being reported to the service desk; therefore, reducing the number of calls to the service desk.  While problem management is related to incident management it is different in that incident management is focused on quick resolutions to problems while problem management tries to find the underlying causes of incidents.  Problem management retains information about existing problems and known errors in its database.  Incident management uses this information to track down problems that continue to recur to avoid further recurrences. 

When problem management identifies a change that needs to take place to a configuration item, this must go through the change management process to be incorporated into the IT infrastructure.  Problem management uses the CMDB (Configuration Management Database) to identify the relationships between configuration items and compare configuration items to find alternative routes and workarounds to problems.  Problem management also is given access to information recorded about requests for change (RFCs).  Some changes may need to be rolled out as releases and this is done under the release management SMF.

Capacity management will identify potential bottle-necks that need to be alerted to problem management.  Financial management assists in determining the costs to affect changes put out by problem management.  Availability management notifies problem management of availability related problems.  Several other SMFs and their relationship with problem management are discussed in the SMF document listed in works cited. 

Works Cited

Service Management Functions:  Problem Management.  Microsoft Corporation. 2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfprbmg.mspx>

Please see the works cited section of this document for sources to this blog entry.  The problem management service management function aims to find the root cause of problems and incidents in the IT infrastructure, and endeavor to record these root causes and solutions to proactively prevent the same problems from recurring in the future.  Incident management aims to resolve incidents as they occur, but does not attempt to find the root cause of problems affecting the system.  In this way incident management is different from problem management.  Problem management aims to assign ownership of a problem to a particular support person in order to reduce the impact of events on the system and resolve problems at their root.  It attempts to find errors before they occur and turn into incidents.

Problems are first recorded when identified.  They are then classified according to impact on the system and the need for a resolution.  Problems are then investigated and diagnosed with an effort made to identify the root cause of the problem.  Once investigated an error control process is performed that sees the error through to its resolution.  This process works along closely with change management processes.  Problem closure involves recording all information necessary about a problem and its proposed resolution.  A problem implementation review is the final step in which a problem is checked to verify the effectiveness of its solution before closing the problem.

There are several places to look for information about a problem listed.  Some places to get information are external vendors, users of the service, forums and user groups, log files, other incident and problem reports, other service management functions, developers, and the Internet.  Any of these sources can provide necessary information about a problem that has been identified.

Certain criteria must be met in order for an incident to be reported as a problem.  The symptoms of a single incident should not match those of an existing problem or known error that already has a work around or solution presented in the problem management’s records.  However, if analysis determines that the same incidents repeat commonly then a root cause needs to be determined and it should be listed as a problem with an incident count that reflects the number of times the incident has occurred.  If analysis of the IT infrastructure is done, it may identify a problem that could potentially lead to future incidents.  Also another SMF or an external source may reveal an issue that problem management needs to be involved in.  Remember the importance of problem management is that problems are recorded for future reference and root causes are identified.

The SMF documentation for problem management states:

Each problem record should contain the following fields:

·         Contact information of the originator

·         Unique problem ID number

·         Incident count

·         Linking incidents

·         Linked requests for change (RFCs)

·         Data and time stamps

·         Target response time

·         Problem details

·         Priority

·         History

·         Status

·         Workarounds

·         Permanent solutions

With regard to problem details and priority the SMF document states:

Things to consider when assigning a priority to a problem are:

·         The availability of resources or specialist skills.

·         The size, scope, and complexity of the problem.

·         Agreed service levels as these may dictate the order in which problems are addressed.

·         The costs to the business of resolving or not resolving the problem.

Service level agreements and operating level agreements need to be noted in the problem description that are affected by the problem.  The problem record should also show any documentation that might assist in explaining the problem.  Other records of problems that are identical or related to the problem record should also be listed on a problem record.

Problems can either be designated as normal or major.  Major problems generally have a high impact on the IT environment and management of the business.  Normal problems have less of an impact.  A major problem should have a particular person assigned to it and a communications plan set up to notify all necessary parties regarding the progress of the problem.  The SMF document states that the following should be included in a communication plan:

·         A comprehensive list of key contacts who need to be regularly updated with status information.

·         A comprehensive list of primary contacts who will act as onward focal points for information distribution.

·         Contact details for all parties requiring updates.

·         The different types of updates that will be required.  Different update messages may be required, depending on the audience receiving the communication:

o   Senior management update

o   Update all staff

o   Update for customers and business partners

o   Update for customers and business partners

o   Update for staff working on the problem

o   Press/media statement where required

o   Update for emergency services and authorities

·         How often each type of update is required and when the next one is due.

·         Who is authorized to release each different update statement.

·         The mechanism by which each update will be communicated.

In certain instances, it may be necessary to preserve evidence if an incident is felt to have been caused by malicious intent.  In these cases effort should be made to keep a record of log files and other necessary information that identifies the problem as such.  Many operating systems contain event log files, monitors, and trace programs designed to find an isolate the cause of difficulties with the system.  There are also other software utilities that can be purchased to work in finding resolutions to problems.  Problem management should work in tandem with incident management in order to solve problems.  Having the same priority system between the two SMFs will assist in setting priorities for resolutions to be attained. 

Problem Analysis

In problem analysis it is important to first define the problem.  Describe the problem systematically with which part of the service is not functioning correctly, and what exactly the problem is.  State where in the infrastructure the problem occurs and the time that it takes place along with information about the size of the problem.  Then establish possible causes for the problem.  After locating the most probable cause of the problem, test it to ensure that it is the cause by duplicating the problem where possible.  This instills confidence that the cause of the problem has been identified.  Once the problem has been identified state the true cause of the problem.  This method of problem resolution was pioneered by Charles Kepner and Benjamin Tregoe as stated in this SMF document.  See the works cited section for details not available on this blog.

To track down the root cause of a problem, use an Ishikawa diagram or fishbone diagram.  This will display the factors that affect a particular problem.  These diagrams were named after their developer, Kaoru Ishikawa, a leader in Japanese quality control.  Several software tools have been created that will build these types of diagrams.  The main goal of the diagram is the trunk and the branches of the tree are different aspects of that particular goal.  By branching off of the main goal and isolating the problem into manageable chunks, a rather complex problem can not only be identified, but also resolved and assigned to different groups of resolvers.

Sorting events in a timeline can be beneficial for identifying the aspects of a particular problem and therefore assisting in the resolution of the problem.  It may lead to identifying key aspects of a problem not thought of before.  It is important that as a problem progresses its progress is monitored to ensure that proper resources are being allocated to the problem.  It may be possible to provide a workaround to the problem until it can be more permanently resolved, or the management team may feel that the problem is not serious enough and that the resolution may be using the workaround.

Once a root cause or causes have been identified, it should be determined if a known error record needs to be created.  Whether or not a record is created depends on the probability that the problem will repeat itself in the future.  The problem database will be useless if it is garbled with a bunch of unnecessary problem records which cannot be sorted out.  Finding a resolution or a workaround is the responsibility of incident management once an error has been recorded in the database.  An error record is different from a problem record in that it has a proposed workaround or resolution recorded with it.

Problem management should assess an error and determine if it needs to be escalated to a virtual team to resolve it.  This would occur if problem management did not have enough expertise to resolve the conflict on their own.  Should a problem require assistance from a vendor then it should be escalated to the vendor for a proposed resolution.  The problem manager should have a clear procedure to follow when escalating a problem to an external vendor.  The SMF document states the procedure should contain the following:

·         “The point at which escalation will be required according to the length of time that has elapsed or the complexity of the issue being addressed.  This should normally be contained within the underpinning contract or service level agreement.

·         A clear and concise description of the reported known error.

·         Any error messages or issues that the customer has experienced or that have been witnessed by support staff.

·         Any and all resolution techniques that the problem management staff have applied toward known error resolution and the results of each attempt, including a detailed history of the sequence of activity.

·         Other documented material deemed relevant.

·         Any diagnostic tools or methodologies used by the problem support team.”

Part 2 of this document will be posted at a later time.

Works Cited

Service Management Functions:  Problem Management. Microsoft Corporation. 2008. <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfprbmg.mspx>