Change that Change Control

A change control procedure is a crucial part of any security strategy.  Without one, organisations can lapse into bad habits, make frequent ad-hoc changes, become vulnerable to human error and ultimately run the risk of a security failure.  In this article, Simon Heron provides practical advice on how to establish (or improve) your change control procedure to provide effective protection for your organisation. If an organisation has no change control procedure (or a procedure that is inadequately enforced), it is at risk.  It’s as simple as that.  Anyone can make changes to the primary security defence with potentially disastrous results and there is little protection against human error.  A procedure should be in place, so that if and when a vulnerability is discovered, whoever makes the discovery knows exactly what needs to be done and when.   Equally, if a change subsequently needs to be reversed, it should be possible to find out who did what and when they did it. Change control in this context is the formal process of controlling changes made to a system, network or application.  It ensures that any changes introduced are done so in a co-ordinated, planned and thought-out way. If changes to a system are not controlled formally, or are not properly thought-through, they will often end up leading to security problems, or even reverse previously made system changes.  Implementing proper change processes should result in minimal disruption and faster implementation time. Businesses that rely on one person to make changes to their networks wrongly assume that the individual will not make a mistake. In fact they probably already have made them, and placed the organisation at risk. Having a change control solution in place reduces the risk of undetected human error. In an ideal world, the team in charge of change control is separate from the team implementing the change (this is a good way of ‘catching’ any changes that might cause network problems; it also make collusion much more difficult).  Alternatively, this could entail using a managed service company that would incorporate some of the change control function, or, if this is not possible, it could be as simple as being a formal process you go through with a colleague not involved in the change. An effective change control process should include the following basic steps:

1. Limit who is authorised to make changes to a system.  Ensure that this policy is not broken, and that all requests for change go through an authorised administrator.  Put in place limited user rights, so the system cannot be tampered with by unauthorised people.  In larger companies, this could be done by using a ticketing system, which places a formal ‘request’ for the change, documenting it, and only allowing authorised (via password) team members to deal with the request.  Involve at least two people if possible – often two people will come up with a more effective change plan than someone working in isolation.
2. Agree a set of change criteria: why do you need the change? What is the impact of it on the business?  And what is the impact of implementing it?  Often changes are made for no real business benefit, but with a great deal of disruption.  For example, in the past, we discovered that an IT manager was dropping his company firewall late at night, so he could play games with friends over the Internet.  Clearly not a business critical change!  This can be a lot more serious where one person is making changes as it might be for personal gain.
3. Document a set of criteria that must be met for any changes to be made, taking into account impact on the business, network downtime, cost and business need.  This does not have to be long or involved; just brief sentences where relevant.
4. Assess the risk of making the change.  This can be done through a formal risk assessment procedure (for larger companies), or by simply answering a set of questions that consider the impact of the change on other parts of the network or application, for example.  Will the change have knock-on effects?  Has it been tested?  Include anyone who will be affected to ensure nothing is forgotten.
5. Record the change details as part of the formal change process. This is extremely important both in terms of identifying when and how the change was made, and also in case it needs to be reversed at a later date.
6. Test the impact of the change on security.  Often, we find that vulnerabilities in network security are caused not by malicious attacks, but by poorly-executed changes to the system that, for example, bypass security measures unintentionally.
7. Plan the change. Inform teams if there is likely to be any impact on productivity, or network availability.
8. Build and test the change – in a closed environment, if possible – to make sure the implementation has been done correctly.
9. Have a plan B.  If the change doesn’t work, or causes an unforeseen glitch, or has some other unexpected results, ensure it can be reversed, quickly (see point 4) to its previous, safe configuration, while a review is done.  In an uncontrolled environment it’s not unusual for so many changes to have been made together that it becomes impossible to undo an error – which can be extremely costly to put right.
10. Implement the change.  Timescales should have been agreed with all those involved (see point 6), and users briefed / trained as necessary on using the new system.
11. Review its success.  Has the change been worth it?  Has it had a positive impact on the business?  Are individuals within the business using it in the correct way?  It is important to review user implementation regularly and get feedback from them; this should influence future changes.