How to get started

Scenario 1

You must check a core switch for a particular configuration. The first time you do it, it takes two days. What is the acceptable amount of time when you have to do it again?

ITOM process: The ITOM process here is checking a core switch. The process narrative must have a well-documented procedure for this process. For more information on how you can nail your documentation efforts, refer to this section in our e-book, A CIO's guide to rethinking compliance.

The core ITOM procedure for checking a core switch must be elaborated with enough diagrams to explain it to an engineer. Let us now analyze instances for this process.

Instance 1: Instance 1 could have taken place on a particular day with a certain objective. Maybe it had to do with a specific type of inbound access. This instance will be recorded with the date, objective, challenges faced, and solutions implemented.

Instance 2: This instance could have taken place six months later for a type of outbound access. This instance will be recorded the same way as instance 1.

There could be any number of instances, and each will provide some deeper insight into the process. The next time an engineer wants to check a core switch, these instance-based documents will save them time by telling them exactly what access needs to be allocated based on the situation. Let us take a look at another scenario.

Scenario 2

An experienced engineer can create a new set of firewall rules with ease. Will a new team member be able to do it as easily as the experienced engineer?

ITOM process: The ITOM process narrative will have all the details about the firewalls in the company, including how all the DCs will likely have the same firewall model or vendor. When creating new firewall access, the process narrative will explain how to log in, provide incoming to outgoing access for users, create addresses, create roles for people, add it to the policy, and finally enable it. There are different sets of checklists for different variations of this process.

If the base ITOM process narrative is created end-to-end like above, a new member on the ITOM team will be able to replicate the process easily. As they document their instances, they will get better with experience and improve the process itself over time.

ITOM process checklists

You can use the following checklist for network operations:

• An overview: Determine the scope of the NOC team, where it operates from, who is responsible for major decisions, and the list of DCs and corporate offices.
• Access controls: Establish physical and logical access controls to define access to physical spaces and to various tools used by the NOC team, respectively.
• Asset and inventory management: Maintain a list of all the available network devices (switches, routers, firewall devices, and their components). Document the process of who purchases network assets and how the return of assets is handled.
• Network monitoring: List the procedures for monitoring the various parameters of switches, firewalls, and routers along with the required tools and the people involved.
• Backup management: Make adequate backups of network configurations on a daily and weekly basis. You can include clauses for these in your network policy.
• Change management: List the detailed procedures for all types of changes, like general changes (device additions, replacements, upgrades, provisioning, and configuration changes), VLAN changes, and firewall rule changes. Include details like tools, approvals, and responsibilities for each type of change.
• Planned maintenance: This will be necessary when you make major device or configuration changes. Document the process with details like who requests the maintenance, who approves it, and what criteria they use to approve it.
• Incident management: Your team must collaborate with the incident management team to resolve incidents quickly. List the various types of incidents (security, availability, and privacy) and describe how each of them will be resolved by involving your team.
• Access to your VPN: Determine how access to your VPN is provided and who monitors it.
• Vulnerability management: Outline the role of the NOC team in assisting the information security team to implement fixes for vulnerabilities.
• References: Documents concerning the network policy, roles and responsibilities, and links to applications used by the NOC team should be made available in a database for reference.

For processes involving DCs, you can additionally include these sections:

• Server procurement: Elaborate on the process of how servers will be purchased and who makes decisions.
• Additional access controls for DCs: Define the physical, logical, and enhanced data security controls for entry into your DCs.
• Availability: List your availability goals and explain how you will achieve them.
• A business continuity plan: Explain how you plan to keep the business running during emergencies or disasters.
• OS patch management: Explain in detail the procedure for running patches along with safety measures, alternatives, and approvals.