The focus of this article is cover such rare cases and briefing the readers on how to handle such cases.
Objective
The aim of this article is to introduce users to organizational exceptions and highlight the importance of dealing with these exceptions. Readers will learn how to deal with these exceptions in a formal manner and track these exceptions to closure.
Exception management
We are not talking about exceptions encountered by a program or application when it is running or the exception handling we have heard about in software development. The concept we are going to discuss, though, is pretty similar. It is best to explain this concept using an example: Let’s assume that an organization has a policy to fix all open security issues within six months from the date of reporting. The organization has recently undergone a security assessment from an external security auditor who has raised multiple security issues in third-party libraries used by the application which was assessed for security vulnerabilities. From the auditor’s perspective, it is very easy to say that organization should upgrade the vulnerable library to the latest version in a penetration testing report. However, practically upgrading the libraries or any other open source software which is in use by the organization is not straight forward. Most modules will technically start bombing because of upgrade; getting things to work takes time. If the product is huge – for example, operating system software – it may not be feasible to fix it in a time frame of six months. But at the same time, there has to be a logical solution to this problem. This is where exception management comes into picture. These kinds of rare cases or “exceptions,” as they are generally known, need special attention.
Need for exception management:
There can be many such cases where a security team might be required to work with the business on an exception basis. The following are some of scenario’s where it may be applicable:
Legacy Applications Applications that are not active Dependencies on Third Party Libraries Vendor Dependency
There can be many such incidents where an organization has to approve exceptions for some time until an amicable solution is found.
Implementing exception management as a part of secure development framework
Let’s take one more step and go a little further. Why not implement exception management formally in our Secure Development Framework, where we can handle such exceptions and have proper policies and procedures defined for the same? This will not only help us handle exceptions, but will also boost Senior Management’s & Application Development Team’s Confidence in the Secure Development Framework. This way, the organization will see Security Framework as business friendly, rather than considering it as a procedural hurdle. We’ll need to do multiple things before we can incorporate exceptions into Secure Development Framework. We need to take into consideration following requirements:
Identify the stakeholders Implement a Roles & Responsibilities Matrix Associating Timeline with each & every Exception Extending Exceptions on a need to basis Accepting irresolvable Exceptions Defining Policies and Procedures to formalize Exception Management
I’ll explain each of the above requirements in detail:
Identify the stakeholders
This is a key step; we need to identify people who’ll be involved in managing exceptions. Normally, application owners own the exceptions and someone from the Security Team will approve such exceptions. There will be additional stakeholders who may have to be informed as well. The number of stakeholders will differ from organization to organization, based on their software development process and the way in which the Secure Development Framework is designed.
Implementing roles & responsibilities matrix
Once we have identified the stakeholders, we need to create a roles and responsibilities matrix which will clearly define which stakeholder needs to do what. A Roles and Responsibility matrix is a formal way to communicate every stakeholder’s accountability & responsibility and circulate it for future reference. This way, everyone will be on same page and there will be no confusion on which activity falls into whose bucket.
Associating timelines with each & every exception
This requirement is very important for any exception. Exceptions, as we previously discussed, are deviations from a process. However, they are provided so that the business is not hurt and both, the security and business can function together. It is imperative that these deviations shouldn’t be taken for granted; otherwise people will use this window to escape from the Secure Development Framework. Hence, when an exception is granted, the concerned exception owners and Security Team’s focal who is granting exception should mutually discuss and arrive at a timeline by which the exception needs to be resolved. This way, there will be a logical deadline implemented and these exceptions can be tracked. All open exceptions can be reported to Senior Management. Thus, the Security Team will not only be able to achieve their task of highlighting the risk to Senior Management, but also work constructively with business ensuring that business functions are not hurt.
Extending exceptions on a need to basis
Sometimes, it may so happen that a business is working towards resolving their open exceptions, however, due to dependencies involved, it may not be possible to close the exception. There could be various challenges (e.g. Non Responsive 3rd party vendors or lack of support for open source libraries used in the software) that will prevent the organization from successfully handling the exception. It would be unfair to blame business for everything; sometimes these challenges are genuine and it might not be possible to close exceptions immediately or within any set time frame. They may have anticipated that support from a third party will be received, however, a delay from the vendor’s end would cause a delay towards the exceptions resolution. In such cases, giving the business a breather is good idea, as abruptly closing the vulnerable service or forcing to take down a vulnerable product will hurt the revenue it generates or force the business to look for an immediate alternative, which may not be available. Sometimes, pushing business too hard can bounce back as Senior Management can force the Security Team to roll back the push if the application or service in question is critical for management. Although working with business is good, as a security analyst, you need to ensure that someone takes the responsibility for such extensions from the business end. The Security Team should explain the pros and cons of extending such exceptions. Stakeholders taking the responsibility should be fully aware that in case of a system compromise that happens due to such an extension to exceptions, they will be entirely their responsibility and they need to explain it to higher management – which can be a big problem for everyone involved.
Accepting irresolvable exceptions
Some Exceptions just can’t be resolved. For example, think about a legacy payroll application hosted on a mainframe server. Getting rid of payroll is a very tedious task, as it is huge move for any organization. There is a lot of cost involved in migrating from older technology to a newer technology. There can be technological vulnerabilities associated with the technology and platform in use and upgrade of the technology may be difficult; also, junking the same and moving to a completely new solution can’t happen overnight. Budgets have to be approved for getting rid of the existing solution and businesses may not be interested in investing such a huge amount for something they don’t deem absolutely necessary or beneficial. So what to do in such a situation? We can’t fix the vulnerability and business is not ready to invest in a technology upgrade or a move to alternate solutions. While the application team can log the exception and commit for a deadline initially, they’ll eventually understand when they go and ask for additional funding to resolve the exception. There is no solution in sight for such exceptions. In this situation, the Security Team can allow the business to continue; as long as the stakeholder(s) accept the risk associated if this exception is accepted as irresolvable. It should be understood that the Security Team’s job is to highlight all possible risks to Senior Management so that they can make an informed decision by weighing all the factors and decide whether to plug a hole or not. This way, even if there is an issue which crops up later on, business won’t be shocked to see such incident and invoke the back-up plan they may have otherwise designed when such a situation arises. The following picture demonstrates the sample life cycle of an extension. It should be noted that there can be more iterations than demonstrated in the picture. Some exceptions could have been closed in single iteration, while others may take multiple cycles for closure. Depending on the deadline associated, the number of iterations may vary from exception to exception. If even after multiple iterations and missed deadlines, the closure of an exception is not in sight, the Security Team can propose an acceptance.
Developing supporting policies & procedures
If we want to enforce exception management as a part of standard Secure Development Framework, then we need to develop supporting policies and procedures which formally document how to handle exceptions in every possible scenario, including long-term exceptions and detailed in this article. Once we have proper documentation in place, we can integrate it into the existing Secure Development Framework.
