4 ms·

Well... I am not in favor of fine grained severities, personally, but that's what I'm asking. Where in the patch response decision tree do I plug in HIGH vs CRI

Well... I am not in favor of fine grained severities, personally, but that's what I'm asking. Where in the patch response decision tree do I plug in HIGH vs CRIT? For people who do play this game, now that this vuln is apparently both CRIT or HIGH depending, how do I know which value to plug into my response decider?

kdmccormick 4y ago
Do you actually want this spelled out for you? * CRIT - Wake an engineer up at 3 AM to apply the patch. * HIGH - Apply the patch in the next 24 hours. * MEDIUM - Apply the patch in the next week. * LOW - Apply the patch in the next month. I'm making these time frames up, but I'm doing it to illustrate a point: different vulnerabilities have different priority levels. If you consider EVERY VULNERABILITY IN EVERY PACKAGE TO BE AN EMERGENCY then your on-call engineers aren't going to get a lot of sleep, and they'll probably find work somewhere less alarmist. Library maintainers like OpenSSL provide these severity levels to assist you in that prioritization game. If you don't trust them, which might be warranted in some systems, that's fine; you can always read every single CVE for every package yourself (or pay someone to do so).
- 0xbadcafebee 4y ago
  More realistically: * CRIT - The CEO called my boss and asked if we were patched yet, so I will be working 16 hour days until it's patched, even if the vuln can't be exploited * HIGH - My boss told his bosses we have a deadline of other work to meet, so I have until the end of next week * MEDIUM - Put it in the backlog * LOW - We will upgrade or sunset the product before it gets patched
  - SoftTalker 4y ago
    Nice that you have a CEO who is has ever heard of OpenSSL much less is monitoring patch advisory notices.
    - 0xbadcafebee 4y ago
      They don't, but sometimes a big vuln makes it into The New York Times or something and they get panicky
      - midasuni 4y ago
        When the json thing came out I think it was late night Thursday on HN. I’d checked and patched our applicable servers on Friday and carried on The panic set in over the weekend as managers decided to issue major panic stations, bronze and silver bridge calls, etc - after it had reached the more general press. Told them to f-off, public facing servers had been automatically patched, most of the rest manually done and triaged.
  - deleted 4y ago
    [deleted]
hosh 4y ago
My experience playing strategy games (like Go) is that, it's not always about plugging in numbers like that, at least for human decision makers. Mainly: - There are limited resources (time and money) - Which of the other seemingly urgent things also need to be done? If you don't differentiate between finer-grained severities, then you won't be able to differentiate or triage between existential threats, and something that can hurt and be ok. And probably more controversially for people who don't know Go, sometimes you accept losses in order to capture greater gains elsewhere. No action will always guarantee a risk-free decision, so this is about managing or mitigating risk, rather than become risk-free. There are the risks that are statutory, and therefore requires compliance in order to stay legal. And then there are the risks that are not legal, and depends upon an organization's appetite for risk. Risk is something that is always present in some form (we don't have perfect-information for every decision we want to make, let alone know all of the available choices), so it is up to each individual organization and individual to make. Being able to differentiate between severity allows an organization to weigh risk against cost, time, and opportunity. And if we want to eliminate this whole class of problems (like stack overflow), we could also look at using something like rust instead. And that's also not getting into nation-state actors sabatoging standards so that vulnerabilities in OpenSSL keep popping up. In this particular case, the response my team is doing is inventorying our existing systems to find anything using OpenSSL 3.0.x, and therefore vulnerable. So far, all the systems we have found are using OpenSSL 1.1.1 ... as is probably the case for most organizations.
deleted 4y ago
[deleted]

kdmccormick 4y ago

Do you actually want this spelled out for you? * CRIT - Wake an engineer up at 3 AM to apply the patch. * HIGH - Apply the patch in the next 24 hours. * MEDIUM - Apply the patch in the next week. * LOW - Apply the patch in the next month. I'm making these time frames up, but I'm doing it to illustrate a point: different vulnerabilities have different priority levels. If you consider EVERY VULNERABILITY IN EVERY PACKAGE TO BE AN EMERGENCY then your on-call engineers aren't going to get a lot of sleep, and they'll probably find work somewhere less alarmist. Library maintainers like OpenSSL provide these severity levels to assist you in that prioritization game. If you don't trust them, which might be warranted in some systems, that's fine; you can always read every single CVE for every package yourself (or pay someone to do so).

0xbadcafebee 4y ago
More realistically: * CRIT - The CEO called my boss and asked if we were patched yet, so I will be working 16 hour days until it's patched, even if the vuln can't be exploited * HIGH - My boss told his bosses we have a deadline of other work to meet, so I have until the end of next week * MEDIUM - Put it in the backlog * LOW - We will upgrade or sunset the product before it gets patched
- SoftTalker 4y ago
  Nice that you have a CEO who is has ever heard of OpenSSL much less is monitoring patch advisory notices.
  - 0xbadcafebee 4y ago
    They don't, but sometimes a big vuln makes it into The New York Times or something and they get panicky
    - midasuni 4y ago
      When the json thing came out I think it was late night Thursday on HN. I’d checked and patched our applicable servers on Friday and carried on The panic set in over the weekend as managers decided to issue major panic stations, bronze and silver bridge calls, etc - after it had reached the more general press. Told them to f-off, public facing servers had been automatically patched, most of the rest manually done and triaged.
- deleted 4y ago
  [deleted]

hosh 4y ago

My experience playing strategy games (like Go) is that, it's not always about plugging in numbers like that, at least for human decision makers. Mainly: - There are limited resources (time and money) - Which of the other seemingly urgent things also need to be done? If you don't differentiate between finer-grained severities, then you won't be able to differentiate or triage between existential threats, and something that can hurt and be ok. And probably more controversially for people who don't know Go, sometimes you accept losses in order to capture greater gains elsewhere. No action will always guarantee a risk-free decision, so this is about managing or mitigating risk, rather than become risk-free. There are the risks that are statutory, and therefore requires compliance in order to stay legal. And then there are the risks that are not legal, and depends upon an organization's appetite for risk. Risk is something that is always present in some form (we don't have perfect-information for every decision we want to make, let alone know all of the available choices), so it is up to each individual organization and individual to make. Being able to differentiate between severity allows an organization to weigh risk against cost, time, and opportunity. And if we want to eliminate this whole class of problems (like stack overflow), we could also look at using something like rust instead. And that's also not getting into nation-state actors sabatoging standards so that vulnerabilities in OpenSSL keep popping up. In this particular case, the response my team is doing is inventorying our existing systems to find anything using OpenSSL 3.0.x, and therefore vulnerable. So far, all the systems we have found are using OpenSSL 1.1.1 ... as is probably the case for most organizations.

deleted 4y ago

[deleted]