What constitutes a security relevant change – Change management is a key control in many security standards & frameworks, but organizations always debate which “changes” require a formal process.
In the below LinkedIn post, Ron Ross, one of the authors of the NIST Risk Management framework and various NIST Special Publications, give some great examples that you can use when designing your change management process.
Source LinkedIn post: https://www.linkedin.com/feed/update/urn:li:activity:7337231871287660544
He basically provides two set of examples and says that it needs to be analyzed if it represents a change to the security posture of the system.
Direct quote from his post:
Changes to a system that may trigger an event-driven authorization action can include:
- Installation of a new operating system or application
- Modifications to system ports, protocols, or services
- Installation of a new or upgraded hardware platform
- Modifications to cryptographic modules or services
- Modifications to security requirements or controls
- Modifications to how information is processed, stored, or transmitted
Changes to the environment of operation that may trigger an event-driven authorization action can include:
- Moving to a new facility
- Hiring new people
- Adding new organizational missions or business functions
- Being subject to new laws, policies, or regulations
- Threat intelligence that the organization is being targeted
These examples are quite valuable because even standards are not clear about what constitutes a change (ISO 27001’s control “8.32 Change management” for example, does not explicitly define what should be considered a change).
Ron Ross has extensive experience with developing security standards and working with security sensitive organizations in the US government. So, I am guessing this is most definitely informed by his experiences. I think more people within standard bodies and regulatory organizations should provide concrete guidance (like this) for practitioners.
