Any security control or activity is usually frowned upon as a bottle neck and security is added only as an after thought. When this is the case, how does one handle administration of Security Tools or upgrades of tools? What I see happening across industry, is that the upgrades are planned based on the release life cycle of the underlying software or once in a quarter or half-yearly. But when this is done, only the instructions followed in the upgrade.txt is followed like a text-book pattern and one does not fore-see more than that.
So, what should one do differently?
Step 1: Check what the upgrade mentions and whether there are any red flags associated with the update. One of the security tools in code scanning mentioned that they will flag any code that uses CBC mode in symmetric encryption. The inference you can gather from this is that, you may be having some of our projects in green field until then. Once you upgrade, then if these projects are using the above mode, almost all will fail and suddenly it will look like the entire security control is not working or you become a bottle neck.
Hence, before you upgrade, check whether any of the red flags mentioned in the security release, impacts any of the projects/applications. Notify the IT team. Plan for Risk Acceptance for a short term and remediation for a long term. Then plan the upgrade.
Step 2: Security Tool is also a software and may involve bugs. It is always better to do a version comparison exercise before rolling out the tool. Take a sample set of projects and do an evaluation exercise comparing the result with the earlier version and current version. Only if the results are promising and doesn’t create many false negatives or false positives, go for the upgrade.
Step 3: Try the upgrade in a test environment to check if all goes well.
Step 4: Do an infrastructure sizing, future DB size growth and plan for it.
Step 5: Always notify end users before planning an upgrade.
Step 6: Do the upgrade during non-usage hours.
Step 7: Test out all features after the upgrade.
Step 8: Send a notification to all end users post upgrade along with instructions on what the change is.
Step 9: Allocate man-hours to offer L1 support at least during initial 2 weeks.
Step 10: Monitor the success of the upgrade, note down any learnings and introduce process improvement changes to the upgrade SOP document.
Any thing that you think that I may have left out?