This may be the 12th post in my series, but I cannot stress the importance of good change control enough. I have said [too] many times that maintaining a good security posture is difficult enough, but to make things easier for bad guys from the INSIDE is just plain dumb.
If nothing in your environment changes, the only way risk can increase is by a change in the external threat landscape. Your Vulnerability Management processes should have this mostly covered.
Like almost every other process in security, change control should start with robust policy and procedure, and a well designed and up-to-date, Asset Management system. If you have not only a complete listing of your physical assets, but your business processes, data stores, system and data ownership, personnel & skill-sets, regulatory dependencies, and system criticality mapped out, you have the foundation for very effective change management. Difficult to create?; yes, difficult to maintain?; only if you don’t do it properly.
Speaking of change management, if you don’t have a change control board, get one. It does not matter what you call it, but it should contain enough of the right people to ensure that both the IT and the business side of the organisation can have full insight into the risk management process, and the upcoming changes to the environment, AND to make sure these changes are in-line with the business’s goals.
Good change control starts with a policy, is clearly explained in procedures, and is central to ANY changes that can affect the continued security of your information assets. From patching, to firewall rules, to application upgrades, to server on-boarding, everything must be reviewed and approved by the APPROPRIATE level of authorisation channel. Change control can never be seen as a bottle-neck or it will be bypassed, so unless you are able to rank your changes into distinct approval channels you will end up doing too much, or too little, neither of which is sustainable.
As far as PCI is concerned, you could email your change requests to whomever is responsible, and maintain the list on a spreadsheet. For small organisations this may be appropriate, but of all things to put online, standardise, and at least partial automate, change control is way up at the top of the list. Right next to your Asset Management System itself in fact. Or even better, PART of it!
Here’s how I think Change Control should be done;
- The ‘Paperwork’: You will need a –
i. Change Control Policy – Keep it simple, even something like; “All changes to IT systems (including, but not limited platforms, application, and data) will be subject to an appropriate review and approval process as determined by the highest data classification.”, is better than most organisations have in place.
ii. Data Classification Policy – Without a data classification policy there is no way to determine the correct level of review and authorisation required. Patching will not go to your review board, but major application upgrades certainly will. Only appropriate processes are sustainable.
iii. Change Control Procedure – Specific and easy to follow instructions enabling EVERYONE in the organisation to request a change in a uniform manner.
- Change Control Board – It does not matter what you call this, Change Control Board (CCB), Change Advisory Board (CAB) or Rumpelstiltskin, the charter is the same; Bring to bear all relevant resources from the business and IT sides (and SMEs if appropriate) to review and approve all changes that meet the established criteria. This should include relevant system / data / process owners where appropriate.
- Integrated Asset Management System (AMS) – Without an integrated AMS you lose the ability to add a second layer of criticality rating to your change requests (Data Classification being your first). A proper entry into the asset register will include process dependencies, regulatory implications, max. data classification, and a system ‘importance’ rank. When these assets are available to the change control requester as a drop-down list, the full impact of the requested change is immediately apparent, and the correct level of review and approval automatically assigned. If each asset also had the system / data / process owners assigned, the review board can be built and perhaps even alerted automatically.
- Change Closure Checklist – Too often changes are closed before the correct testing is performed, but again, what testing and approval is appropriate should be tied to the importance of the change. Vulnerability scan results, penetration testing results, user testing input, and so on are just a sample of the things that could / should be done before any change is closed.
- Periodic Review Against Management Metrics – The change was made for the benefit of the business in some fashion, right? How do you measure success? The answer of course is; “That depends.”, but a specific date / time should be set to review the changes made to ensure that all success criteria are met. This should not be complicated or labour intensive, ever, but the review process is the only way to feed back efficiency improvements into the risk management process. Nothing is perfect.
The above list assumes you have included the basic information required to request a change (Documentation of Impact, Back-Out Procedures etc.), but the PCI minimums are rarely sufficient for an organisation that really cares about this stuff. Again, you don’t want the request process to be ridiculously long or complex, but if you don’t provide enough information up-front, you cannot perform the correct review process, nor can you measure success of the results.
Finally, if your change control process is not owned by your Governance function, you will never be able to bring the correct business oversight to bear. IT and IT Security are only ever enablers, it’s the business side that needs to own the goals.
Another crazy long blog, apologies, but change control is just that important.