Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

Auditing for configuration management

Keeping track of changes is a critical functionality in every configuration management system. Not only for operational reasons, but also because there are legal requirements like SOX (Sarbanes-Oxley Act) that require it. This article looks at different approaches to handle things.

One of the most critical parts of a configuration management system is to keep track of  changes. Fundamentally that importance comes from two areas. The first is operational safety. Being able to trace back your steps, when (not if) something goes wrong, is crucial. The other reason are legal requirements like SOX (Sarbanes-Oxley Act).

For the implementation there are basically two ways:

  1. Feed the configuration management with data that are already audited.
  2. Have the configuration management system do the audit itself.

The first approach will usually involve a Version Control System like Git or Subversion. This has the huge advantage that it is already established in the organization and its processes. It also means that dependencies between a certain configuration item and the code that makes use of it are implicitly covered. In other words: If you check in your code change, make sure to include all relevant changes to configuration items and everything will work.

That sounds great, doesn’t it? No additional tools, processes, or organizational challenges to deal with and everything works by definition. Unfortunately life is not that easy. Here are just a few areas where this approach falls short:

  • Emergency changes: If every seconds counts to fix something, you don’t want to wait even for the best CI/CD pipeline in the world. If you have the latter, that is.
  • Non-developers: You typically have people involved in changing configuration details who are no developers. Good luck teaching someone Git just for performing a small configuration change.
  • Separate process: It is more than likely that some configuration changes (although not an emergency) need to happen outside of the normal deployment cycle. It may be an option in your organization to just adjust the deployment. But what if that is not an option?
  • Approval process: If you have an approval process, hopefully implemented in some kind of workflow tool, how do integrate that with your Version Control System or CI/CD pipeline?
  • Security: You typically have different rules and people involved for production systems vs. earlier stages (especially development). Quite often it is therefore not even allowed to have certain values under version control.

The list above, although certainly not complete, should be more than enough to convince you that relying only on something like Git is not a great idea.

So the configuration management needs to support auditing by itself as well. The detailed functionality can, to an extent, be derived from the aforementioned situations. So whenever a certain requirement or situation does not lend itself (well) to be dealt with by a Version Control System, that is already a candidate.

As a minimum the delta of every change needs to be saved, together with relevant metadata. So the old and new value, the user that performed the change, the IP address from the change originated, etc. In addition it should be possible to provide some kind of information as to why the change was done. The rational is the critical aspect here. Because we can automatically capture the old and new value(s) with much more precision than what people will usually enter. But to know the intent behind the change is really important.

If required, and you should assume that this will come up sooner or later, it should be possible to connect the audit with a GRC system (Governance, Risk Management, and Compliance) or legal frameworks like the aforementioned Sarbanes-Oxley Act.

But the possibility for integration should not be limited to GRC systems. Ticket systems like JIRA and workflow tools are just as important. And with proper APIs only your fantasy will limit the options. Experience teaches us that customers have always many more idea for connecting software than the developers who build it. So to not only have specific integrations (which are usually very comfortable to use) but a generic way for connecting is crucial.

That’s it for today. I am aware that there is a lot more to this subject than what I have covered. But I wanted to start with the fundamentals first and take it from there.

If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.

© 2024 by Christoph Jahn. No unauthorized use or distribution permitted.

Share:

Facebook
Twitter
Pinterest
LinkedIn

One Response

  1. Good one Jahn .
    I completely agree that a robust configuration management system should support auditing by itself and capture not only the changes but also the intent behind them. Your mention of integration possibilities with GRC systems, ticket systems, and workflow tools highlights the need for flexibility and adaptability in such systems.

    Overall, this article serves as an excellent foundation for understanding the fundamentals of configuration management, and I look forward to reading more on this topic in the future

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Microservices and code reuse for integration platforms

Today I want to write about a software development approach I was able to put into practice a few years ago. I was myself very much surprised how well things worked out, and especially how fast I was able to see tangible benefits for the business side.

Custom logging with Log4j on Integration Server

Every serious IT system needs proper logging. This article describes how I use Log4j v2 with webMethods Integration Server. There is no need to change anything on the system, just install the package and it works.

External Java libraries in webMethods Integration Server

To get most out of your Integration Server you will sooner or later need to leverage the functionality of existing Java libraries. Common examples are Log4j or Apache POI (for working with Excel or Word files). Here is a short guide for this.

Running webMethods Integration Server in containers

Organizations are moving from traditional deployments to containers and Kubernetes to increase business agility. This article discusses a lot of topics that are relevant to actually reach the goal of faster delivery of value to the business through software. Because if you do it wrong, you just end up with yet another technology stack. And, as always, technology is not your biggest challenge.