Every other day, you hear about some major security flaw letting hackers steal credit card information, steal passwords, social security numbers or something equally serious. Such news can seem remote, but not for the organization that gets impacted by such news. In such an organization, the impact of such security lapses can be shocking and dramatic, including people getting laid off and stock prices getting impacted (unless it is a mega-billion revenue earning organization which need earth shaking news to cause upheaval, small scale security scares are something that they are used to).
You might think that this is something that does not impact you too much, since nothing major has happened in the past and you are not likely to be the target of hackers. However, it is not necessary that hackers directly target you, but that there are some problems in the code that has been discovered that is not yet fixed (or fixed and not incorporated by customers) which can cause security related attacks. What is a likely scenario ?
Most large or even medium scale projects use external components for features that they need to deliver - my favorite example has been the use of decoders for handling the different image, audio and video formats, as well as the inbuilt capability within the Operating System. It is impossible for most applications to write their own software for such purposes, and they use external components for such purposes (paying a license fee or royalty or using free software for the same purpose). There are numerous other examples of the use of external components. Now, when you have incorporated an external component, it is practically a part of your own software and gets distributed with it.
If a security hole or some other such problem is there in the external component, then till the time it is patched and the patch is incorporated in your software and installed with components, there is an ongoing risk. It becomes even easier since there are numerous tools that become available which allow even non-hackers to exploit such holes or security issues.
So what is the method to reduce the risk of your customers getting impacted by such a problem? You can never entirely reduce the risk to zero, but there are a couple of strategies you can do to learn and handle the issue.
- Have a matrix of the various components you use, the critical nature of these components, is their usage such that they can be exposed for a security attack
- For each component, how would your team get informed that there is a new security flaw with the component, the severity of the flaw, when it is likely to get fixed and who is the person within your team who has the primary responsibility for evaluating any such flaw
- Detail the next step of action were such a flaw discovered. This would of course depend on the nature of the flaw, how likely it is to be exploited and other such factors, but you need to have a pre-defined strategy on how to respond (you cannot try to detail such strategies when the issue is faced, it can lead to a flawed execution)
- This one is more tricky. What should you do if the issue is found in the last released product / previous releases. This depends on the level of support you provide for previous fixes and the evaluation of the previous steps. For example, for a release that was done 2 versions back, if a small security flaw is found in an external component, and the presumed impact is minor, you may choose to not provide a fix
- Define a communication strategy for customers to let them know and to alleviate any concerns that they might have
You might think that this is something that does not impact you too much, since nothing major has happened in the past and you are not likely to be the target of hackers. However, it is not necessary that hackers directly target you, but that there are some problems in the code that has been discovered that is not yet fixed (or fixed and not incorporated by customers) which can cause security related attacks. What is a likely scenario ?
Most large or even medium scale projects use external components for features that they need to deliver - my favorite example has been the use of decoders for handling the different image, audio and video formats, as well as the inbuilt capability within the Operating System. It is impossible for most applications to write their own software for such purposes, and they use external components for such purposes (paying a license fee or royalty or using free software for the same purpose). There are numerous other examples of the use of external components. Now, when you have incorporated an external component, it is practically a part of your own software and gets distributed with it.
If a security hole or some other such problem is there in the external component, then till the time it is patched and the patch is incorporated in your software and installed with components, there is an ongoing risk. It becomes even easier since there are numerous tools that become available which allow even non-hackers to exploit such holes or security issues.
So what is the method to reduce the risk of your customers getting impacted by such a problem? You can never entirely reduce the risk to zero, but there are a couple of strategies you can do to learn and handle the issue.
- Have a matrix of the various components you use, the critical nature of these components, is their usage such that they can be exposed for a security attack
- For each component, how would your team get informed that there is a new security flaw with the component, the severity of the flaw, when it is likely to get fixed and who is the person within your team who has the primary responsibility for evaluating any such flaw
- Detail the next step of action were such a flaw discovered. This would of course depend on the nature of the flaw, how likely it is to be exploited and other such factors, but you need to have a pre-defined strategy on how to respond (you cannot try to detail such strategies when the issue is faced, it can lead to a flawed execution)
- This one is more tricky. What should you do if the issue is found in the last released product / previous releases. This depends on the level of support you provide for previous fixes and the evaluation of the previous steps. For example, for a release that was done 2 versions back, if a small security flaw is found in an external component, and the presumed impact is minor, you may choose to not provide a fix
- Define a communication strategy for customers to let them know and to alleviate any concerns that they might have
No comments:
Post a Comment