Ad – Amazon Networking Products
Skip to Firewall Approval Section
Change Management, also known as Change Control, is a process or procedure, usually in Information Technology, to minimize disruptions of services or resources for which IT is responsible. The goal is for oversight when IT is responsible for adding, removing, upgrading, or changing hardware, services, or resources. Given the nature of Change Management, I believe the name Change Control is being phased out to get away from sounding or appearing as controlling.
ITIL
Change Management is preferred over Change Control, though both are used interchangeably. From now on, I will refer to Change Management (CM). The Information Technology Infrastructure Library (ITIL) uses the term Change Management, as ITIL is a framework for managing services, processes, and procedures within Information Technology. ITIL is common within IT, and many have adopted most or some of ITIL’s frameworks.
There are certifications in many layers of ITIL, which has become a popular certification, especially for those starting in Information Technology. Chief Information Officers (CIOs) have taken entry-level ITIL courses through the top-level courses and relative certification; CIO has a great article on ITIL: What is ITIL? Your guide to the IT Infrastructure Library. So ITIL is for every level within IT.
Change Management
The CM process is widespread in IT, and I’m aware of where the process is used in other departments like building management. After all, it does make sense to have CM when responsible for electrical, heating, cooling, and plumbing.
When I first heard of CM, I immediately thought of project management, as CM is not project management but possibly another step in a project. Most CM processes usually include a board that may comprise Managers or Directors from different teams, and some I’ve experienced from multiple departments outside of IT. The board oversees the CM process and procedures and is usually the decision maker if a change (add, remove, upgrade, and so forth) is approved, declined, or postponed.
What is the CM process? Throughout my twenty-five-plus-year career in IT, I experienced Change Management (CM) in different ways and stages. I was fortunate to have participated in developing a CM process with one employer and watched it mature into a professional, effective CM process. In at least the five companies I have worked for with a CM process, the process is almost the same, but some minor differences. Here are the most common steps with a CM process.
- A change is needed (add, remove, upgrade, and so forth), so either the Requester or Implementer will submit the Change Request. Most ticket/service software these days, for example, ServiceNow, have Change Management modules for submitting and tracking CM requests.
- One option I favor is that a Manager or Director reviews the submitted change.
- The Change Management Board receives the request, and the request may be reviewed before it is represented at the CM meeting.
- The CM meeting is held weekly, bi-weekly, or monthly. At this meeting, the CM Board is present, and anyone with a change. The Implementer or Requester, or both will be present to represent the requested change.
- If the change is approved, then it is scheduled and the change made.
Who is the Requester or Implementer? The Requester is the individual requesting the change, hence the name, and may often be a Director or Manager. The Requester is sometimes also the Implementer. So, who is the Implementer? The Implementer is the individual (or team) performing the actual change. Sometimes the Implementer is also the Requester.
In my experience, the CM process did not allow the Requester or Implementer to be the same individual for a couple of employers.
Though the process may seem lengthy or tedious, it’s not as bad as it looks. Once all involved are educated on the process and work through it, it becomes natural. There are many benefits to a CM process, including some industry or company compliances.
- The CM process can be a peer review. Colleagues can provide input to the requested change, whether a recommendation, change communication, historical information, or technical details.
- In many of the successful CM processes I have experienced, representatives from all IT teams attended the scheduled CM meetings, if they had a change or not. This helps if a change may affect another IT team, system, or resource.
- One option I’ve seen work well is having a representative of the affected department join the CM meeting/process, which may be a department outside of IT. This has allowed the department to represent their feedback on the change.
- Changes are coordinated, and one team making a change may affect another. Conflicting changes or change windows can cause havoc. Imagine a scheduled network change taking the network down while Application Analysts perform a software upgrade.
- A change may involve multiple teams or departments, and the CM meeting/process allows everyone to be on the same page. True story: I’m at the lake, taking the kayaks off the car’s roof when the phone rings. The Manager of one of the IT teams called me requesting additional ports be open on the firewall for the software change they scheduled. I was out on the day of the CM meeting, but this could have been avoided if someone from my team had attended.
- A couple of times, the CM meeting allowed many people, especially new hires, to learn the function of each person or team or their responsibilities.
This is not a complete list, but based on my experience.
So, is Change Management a waste of time?
Change Management is certainly not a waste of time, and it is a collaborative, informational, and productive process when implemented and managed correctly. Through this process, there is a collective of IT resources and is a way of knowing how often these resources either change, are upgraded or have a problem.
One other note.
With vulnerabilities and bugs in many products and for compliance, it’s important to update software or hardware. Most of the time, this is done off hours. With two previous employers, we set a monthly and quarterly schedule to perform these updates or upgrades. Setting the same day and time each month, the users became used to this schedule, and it got to a point where it was implied. It took time for the IT staff and the users to adjust, but it became natural and beneficial after that break-in period.
For obvious reasons, the CM meetings I attended on Mondays or Fridays were the least attended. The CM meeting should not be held on Fridays as this may provide little or no opportunity for communication. Also, on a Friday, it is possible that any other staff or teams may be involved, and if the change is that weekend, it may not be a reasonable or fair amount of notice.
Conclusion
Change Management is not a roadblock but a review process. The CM process is here and certainly won’t be going away any time soon. If your company or organization does not have a Change Management process, one should be implemented. Many vendors that offer ticket/service software (ServiceNow) usually help implement a CM process in addition to the many resources on the Internet.
Oh, and when I received that call at the lake. Because I had my laptop in the car and hotspot service on my phone, I helped the team that called. A day in the life of a Network/Security Engineer.
Bonus – Firewall Approval Example
Over the years, firewall requests for firewall changes have grown in popularity and are now standard practice. This can be done manually through a change process and using a management and ticketing service like ServiceNow. Many vendors these days provide this through their software or service and integrate it with services like ServiceNow. Some of them provide firewall policy management in conjunction with Change Management. One company that can do this is Tufin.
Below is a firewall request and approval flow I have used for some years, and it works well. It is not a one-size-fits-all but a good baseline to help.
Copyright © Packet Passers 2024