4 ms·

I think people rip on EDR and security when 1. They haven’t had it explained why it does what it does or 2. It is process for process sake. To wit: I have an o

I think people rip on EDR and security when 1. They haven’t had it explained why it does what it does or 2. It is process for process sake. To wit: I have an open ticket right now from an automated code review tool that flagged a potential vulnerability. I and two other seniors have confirmed that it is a false alarm so I asked for permission to ignore it by clicking the ignore button in a separate security ticket. They asked for more details to be added to the ticket, except I don’t have permissions to view the ticket. I need to submit another ticket to get permission to view the original ticket to confirm that no less than three senior developers have validated this as a false alarm, which is information that is already on another ticket. This non-issue has been going on for months at this point. The ops person who has asked me to provide more info won’t accept a written explanation via Teams, it has to be added to the ticket. Stakeholders will quickly treat your entire security system like a waste of time and resources when they can plainly see that many parts of it are a waste of time and resources. The objection isn’t against security. It is against security theater.

MichaelZuo 1y ago
This sounds sensible for the “ops person”? It might not be sensible for the organization as a whole, but there’s no way to determine that conclusively, without going over thousands of different possibilities, edge cases, etc.
- dghlsakjg 1y ago
  What about this sounds sensible? I have already documented, in writing, in multiple places, that the automated software has raised a false alarm, as well as providing a piece of code demonstrating that the alert was wrong. They are asking me to document it in an additional place that I don't have access to, presumably for perceived security reasons? We already accept that my reasoning around the false alarm is valid, they just have buried a simple resolution beneath completely stupid process. You are going to get false alarms, if it takes months to deal with a single one, the alarm system is going to get ignored, or bypassed. I have a variety of conflicting demands on my attention. At the same time, when we came under a coordinated DDOS attack from what was likely a political actor, security didn't notice the millions of requests coming from a country that we have never had a single customer in. Our dev team brought it to their attention where they, again, slowed everything down by insisting on taking part in the mitigation, even though they couldn't figure out how to give themselves permission to access basic things like our logging system. We had to devote one of our on calls to walking them through submitting access tickets, a process presumably put in place by a security team. I know what good security looks like, and I respect it. Many people have to deal with bad security on a regular basis, and they should not be shamed for correctly pointing out that it is terrible.
  - MichaelZuo 1y ago
    If your sufficiently confident there can be no negative consequences whatsoever… then just email that person’s superiors and cc your superiors to guarantee in writing you’ll take responsibility? The ops person obviously can’t do that on your behalf, at least not in any kind of organizational setup I’ve heard of.
    - dghlsakjg 1y ago
      As the developer in charge of looking at security alerts for this code base, I already am responsible, which is why I submitted the exemption request in the first place. As it is, this alert has been active for months and no one from security has asked about the alert, just my exemption request, so clearly the actual fix (disregarding or code changes) are less important than the process and alert itself. So the solution to an illogical, kafkaesque security process is to bypass the process entirely via authority? You are making my argument for me. This is exactly why people don’t take security processes seriously, and fight efforts to add more security processes.
      - MichaelZuo 1y ago
        So you agree with me the ops person is behaving sensibly given real life constraints? Edit: I didn’t comment on all those other points, so it seems irrelevant to the one question I asked.
        dghlsakjg 1y ago
        Absolutely not. Ops are the ones who imposed those constraints. You can't impose absurd constraints and then say you are acting reasonable by abiding by your own absurd constraints.
        MichaelZuo 1y ago
        How do you even know it was a single individual’s decision, let alone who exactly imposed the constraints?

MichaelZuo 1y ago

This sounds sensible for the “ops person”? It might not be sensible for the organization as a whole, but there’s no way to determine that conclusively, without going over thousands of different possibilities, edge cases, etc.

dghlsakjg 1y ago
What about this sounds sensible? I have already documented, in writing, in multiple places, that the automated software has raised a false alarm, as well as providing a piece of code demonstrating that the alert was wrong. They are asking me to document it in an additional place that I don't have access to, presumably for perceived security reasons? We already accept that my reasoning around the false alarm is valid, they just have buried a simple resolution beneath completely stupid process. You are going to get false alarms, if it takes months to deal with a single one, the alarm system is going to get ignored, or bypassed. I have a variety of conflicting demands on my attention. At the same time, when we came under a coordinated DDOS attack from what was likely a political actor, security didn't notice the millions of requests coming from a country that we have never had a single customer in. Our dev team brought it to their attention where they, again, slowed everything down by insisting on taking part in the mitigation, even though they couldn't figure out how to give themselves permission to access basic things like our logging system. We had to devote one of our on calls to walking them through submitting access tickets, a process presumably put in place by a security team. I know what good security looks like, and I respect it. Many people have to deal with bad security on a regular basis, and they should not be shamed for correctly pointing out that it is terrible.
- MichaelZuo 1y ago
  If your sufficiently confident there can be no negative consequences whatsoever… then just email that person’s superiors and cc your superiors to guarantee in writing you’ll take responsibility? The ops person obviously can’t do that on your behalf, at least not in any kind of organizational setup I’ve heard of.
  - dghlsakjg 1y ago
    As the developer in charge of looking at security alerts for this code base, I already am responsible, which is why I submitted the exemption request in the first place. As it is, this alert has been active for months and no one from security has asked about the alert, just my exemption request, so clearly the actual fix (disregarding or code changes) are less important than the process and alert itself. So the solution to an illogical, kafkaesque security process is to bypass the process entirely via authority? You are making my argument for me. This is exactly why people don’t take security processes seriously, and fight efforts to add more security processes.
    - MichaelZuo 1y ago
      So you agree with me the ops person is behaving sensibly given real life constraints? Edit: I didn’t comment on all those other points, so it seems irrelevant to the one question I asked.
      - dghlsakjg 1y ago
        Absolutely not. Ops are the ones who imposed those constraints. You can't impose absurd constraints and then say you are acting reasonable by abiding by your own absurd constraints.
        MichaelZuo 1y ago
        How do you even know it was a single individual’s decision, let alone who exactly imposed the constraints?