Alex Makumbi
08 March 2017
Building a secure software product by going through the Software Development Life-Cycle (SDLC) processes (requirements, design, develop, test and deploy) following best practices, one can assume that the product can be built robust enough needing minimum attention once it is in service. That reality does not exist for public actively used software products; even for privately used software products for that matter. Steps have to be taken early in the SDLC to address worse case scenarios such beaches into the product, vulnerabilities found in code etc.
Incident management and patch management plans developed early in the SDLC of a software product aim to establish controls to ensure damage to the product is mitigated or is restored as quickly as possible. Incident management outlines policy guidelines that an incident team must follow which can include for example the duration a software product can be offline (depending on the tolerance level of the organization), how incidents are archived, a team of incident responders is identified, trained and provided necessary tools etc. These guidelines are well documented early in the SDLC before the product goes live.
Patch management carefully outlines policy guidelines on how to approach software patches keeping in mind the time it would take to make patches, how much it would cost to make patches and time and cost of testing. Policies clearly communicate to software engineers what type of patches to prioritize and which tools to use in addressing various patches.
Incident and Patch management are necessary activities that ensure that once the software product is deployed, controls are in place to identify, protect, detect, respond and recover a software product from a breach or vulnerability.
Sources
National Institute of Standards and Technology. (2014). Framework for Improving Critical Infrastructure Cybersecurity. Retrieved from https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf