7

Recently it was discovered that one of the open source packages we were using in our software was deemed vulnerable many years ago. It is no longer maintained. It is also too costly to remove and replace. I informed my Product Manager who responded with “What do you want me to do about it?” My response was that I was informing you because it will have to be reported up the chain. The response back was “Again, what do you want me to do about it?” Weeks later and the manager is still ambivalent. It is a product that is used worldwide. After the manager’s second reply, I stopped responding. We are not able to make changes without the product managers approval.

What would be the correct response in this situation? I showed the response to a coworker and his response was that the manager was in the wrong and shouldn’t have responded that way.

  • 1
    You say it's "too costly to remove and replace" and that you "are not able to make changes without the product manager's approval". It's not clear from this question which changes you are hoping for them to approve. Perhaps the PM is literally looking for recommendations for how to address the problems ("What do you want me to do about it?"). Raising it up chain without a suggested course of action is probably not going to be very productive. – combinatorics Dec 15 '18 at 22:40
  • @combinatorics: at my company, that is the norm. The recommendation was to upgrade it which the PM response was “What do you want me to do about it?” – Brian Dec 15 '18 at 22:49
  • Well, what do you want him to do about it? Did you propose an alternative solution? Is there one? – Seth R Dec 18 '18 at 4:04
  • In all honesty, I would be first more worried about the maintenancy aspect of theatunmaintened component than cybersecurity first. Unless this component play a major role in itself in the security of your application. – Walfrat Dec 18 '18 at 12:45
14

Don't in general go to managers with problems unless you also have a solution.

"This is no longer supported and is buggy" is less useful then "this is no longer supported and is buggy, but I have had a look and cooking up a patch to fix the library will take X days, replacing the library with a more modern one Y days (but then we won't have to keep patching), and doing nothing costs nothing but exposes us to the risks A, B & C, which option would you like me to do?".

Try very hard to never go to manglement with a problem without also offering solutions, it is mostly pointless.

Regards, Dan.

  • 1
    Also, you will have to get much more specific than "this software is vulnerable". To what? Is that risk mitigated in other ways? Could other mitigation be added? Any other options you can think of other than replacing the whole thing? – Peter Dec 16 '18 at 1:35
  • 14
    I find this advice "don't go to your manager with problems if you don't have the solution" quite ridiculous. I am quite capable of finding problems that I have no idea how to fix. Not telling my boss about them would be absolutely irresponsible. Maybe I have had the luck to always work with managers who are not morons who'd rather not hear about problems. – gnasher729 Dec 16 '18 at 15:50
  • 1
    @gnasher729 maybe its just because I do engineering at a reasonably senior level, but even if the solution is "We don't have the in house skills to solve this, but we can use so and so as a consultant", I would always try to offer a fix. Of course going to management to give information "project foobar is running late because..." or to seek information about priorities "We don't have the resources to ship both the projects on time because... Which one should be prioritised?" are entirely valid. Information is good, information with some actionable choices is better. – Dan Mills Dec 16 '18 at 16:19
  • One potential solution would be to have the manager add the issue to the product or companies risk register (if there is no risk register, this should be on the risk register as well). If you have a Risk&Assurance person floating around, you could mention it to them as well. – Jamie Dec 18 '18 at 0:45
  • 2
    @Walfrat I am guessing you run with a different set of developers or a very different culture, because if my management tried that on our dev shop they would find that they didn't have a dev team remarkably quickly. We poke, we prod, we hack, its what we do, and actually if you use libraries in your code the time taken to really understand how they work is generally WELL spent (How else will you know where the odd corner cases are likely to be hiding, much better to find those while playing then when on a deadline). – Dan Mills Dec 18 '18 at 19:47
9

Be honest. Tell your manager that you don’t expect him to do anything, you just want to be able to honestly say that you informed your superior about this issue on a regular basis in the event that using the product as-is results in a breach of some sort. That you understand that it’s not your job to do cost/benefit analysis for fixing, switching or ignoring the issue, but you do feel it is your job to keep management informed of such issues as they become apparent to you.

This probably won’t endear you to your manager...

7

Assess the vulnerability and the cost of implementing fixes or workarounds.

You say that this is an open-source projects that is no longer maintained. You can therefore:

  • Check to see if a maintained fork exists. A 'fork' is where someone took the original code and maintains/updates it as a seperate product.

  • Create a fork and address the security concerns yourself as a company. Bear in mind that if the original code was licensed under the GPL (any version or derivative), you legally cannot keep the code in-house if the software package is being distributed outside of your company.

I would do number one first, then entertain number two. Either way, you have a solution you can give to your project manager.

  • I disagree, doing that require time, time in job means money, money that, unless you're in R&D is not meant to do that but to develops. For me the first step is first to raise an issue, if the one handling it don't want you do take time to even perform an analysis, it's their choice, their responsability. – Walfrat Dec 18 '18 at 12:40
  • @Walfrat "I disagree, doing that require time, time in job means money" and I can guarantee you that having your software hacked with known vulnerabilities to the point where just using your product puts users or their assets in danger costs quite a bit more. "For me the first step is first to raise an issue" The open source package is unmaintained; there is no one to raise the issue to. If you are talking about the product manager, the product manager is asking OP for a solution. – 520 Dec 19 '18 at 18:48
  • I agree, the OP made a good choice, now their manager should decide if he wants to spend time to have OP look for a solution now, later, or drop the problem. The OP could eventually have more information like how long will it take for him to assess the vulnerability. You answer is good I just think it miss that one step. – Walfrat Dec 20 '18 at 10:27
2

I currently work as an analyst on the IT security team at my company, formerly having transferred as an security auditor. I will provide a framework that I think you can use, and for which I have used on numerous occasions with success in my current role.

Analyze the vulnerability found

Your first task prior to escalation should be to analyze the vulnerability. In this step, your goal is to gain as much understanding about the security weakness as possible and to brainstorm how about it may be exploited. Threat modeling would be very useful exercise to do. Some answers that you would want to know are listed below. This list is by no means exhaustive.

  1. Who are the threat actors that could exploit this vulnerability discovered?
  2. How targeted do you believe the threat actors are - I.e: Are they aiming specifically for your company?
  3. What are the pre - conditions necessary for this vulnerability to be exploited?
  4. What adverse impact could result, assuming the vulnerability is exploited? - I.e: what is the inherent security risk? E.g: sensitive data exfiltration

Rank the severity of the vulnerability using a accepted metric such as MITRE CVSS score

Use well known and accepted sources of information for vulnerability ranking and management to increase your authority when presenting to the product manager.

Evaluate security controls currently present to mitigate likelihood of vulnerability being exploited or impact if exploited

Now that you have a good idea of the inherent security risk by evaluating both likelihood and adverse impact of exploitation, you analyze the current security controls and their effectiveness. I am not sure of your role or whether your company has a IT Security function, but work with them to understand what security processes are currently in place. Security controls is a broad term but in general includes detective, administrative, corrective, and preventative controls.

Establish reasonable residual risk ranking using accepted sources and methodology

Your goal in this step is to arrive at a reasonable ranking for residual risk - the risk remaining (business risk, data risk etc.) after application of in - place security controls. In other words, quantity the value of the in-place security controls. A source I have found useful when performing this step is NIST publication SP-800 30 Revision 1.

Translate analysis into business value

From the message the product owner gave you, it seems he is unsure / reluctant to proceed. It is important that you be able to translate the impact of the vulnerability into monetary terms - loss of current revenue, loss of prospective revenue due to customer attrition as a result of reputational damage in case of vulnerability exploitation etc. Assuming the product owner is rational, cares about the product, and is concerned about negative effect on customers, he / she should approve appropriate action such as to update the software.

It is also important to note that one form of management response is to accept the risk. Management may decide that remediation of the vulnerability is too costly relative to its likelihood of exploitation / impact of exploitation. While this may not be what you prefer, it is a valid approach nonetheless.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.