Identification, assessment and reporting of security vulnerabilities in applications, databases, systems, networks and perimeters is the first step towards information security management to adhere with organizational policy, client requirements and applicable regulatory & legislative requirements. But with companies deploying more and more apps, vulnerability management is getting complicated by the day. And the real challenge lies in addressing, i.e. mitigating, reducing and accepting the reported security findings that require support from management and commitment from platform owners and application owners. Management of security vulnerabilities with appropriate patches, updates or upgrades is found to be very complex particularly for the application platforms in live production environment as the change management process demands a lot of preparation prior to planning the downtime and obtaining business approvals.
It is more difficult to manage vulnerabilities for applications than infrastructure vulnerabilities as it involved the coordination of the security teams with software and application development teams. This leads to issues of time management and coordination between teams considering the fact that software development teams are already cramped with development and release schedules. Additionally, the loophole plugs require changes to custom application code and application-specific business logic instead of the typical patches and configuration changes that are mostly enough to address infrastructure-level vulnerabilities. The key to address this is to strike a tandem between the vulnerability management practice of the security team and the defect management practice of the development teams.
Besides, there is also an understanding gap from a business perspective between the teams who face the problems and teams who are supposed to fix them. Therefore, it is advisable to treat security vulnerabilities as software defects. The software teams should track the vulnerabilities in the defect management system, in other words the typical ‘bug tracker’ and then select the defects to be addressed in each development cycle or release. The fact of the matter is that, finding vulnerabilities is good, but that doesn’t mean anything until and unless they are fixed.
Given the constraints that the application world functions in, a wise approach for teams is to calculate the risk quotient for the vulnerabilities, then make the effort estimate for fixing the vulnerabilities and prioritize accordingly. Whether we like it or not, vulnerabilities are there. And the known ones are better than the unknown ones which we cannot even do anything about. But, if we do not take care of the known ones; that is a situation we don’t even want to be in.
