5 ms·

Is this really a criticism? Because this has been the case forever with all security and SIEM tools. It’s one of the reasons why the SIEM is the most locked dow

Is this really a criticism? Because this has been the case forever with all security and SIEM tools. It’s one of the reasons why the SIEM is the most locked down pieces of software in the business. Realistically, secrets alone shouldn’t allow an attacker access - they should need access to infrastructure or a certificates in machines as well. But unfortunately that’s not the case for many SaaS vendors.

st3fan 2y ago
But why only forced on MacOS? I think some configurability would be great. I would like to provide an allow list or the ability to redact. Or exclude specific host groups. We all have different levels of acceptable risk
- btilly 2y ago
  Conspiracy theory time. Because Apple is the only OS company that has reliably proven that it won't decrypt hard drives at government request.
  - vagrantJin 2y ago
    This is a true conspiracy .
    - jordanb 2y ago
      Seriously? Crowdstrike is obviously NSA just like Kaspersky is obviously KGB and Wiz is obviously Mossad. Why else are counties so anxious about local businesses not using agents made by foreign actors?
      - smolder 2y ago
        KGB is not even a thing. Modern equivalent is FSB, no? I'm skeptical. I don't think it's obvious that these are all basically fronts, as much as I'm willing to believe that IC tentacles reach wide and deep.
  - iml7 2y ago
    It depends on the country it is in, it rejects the US government's request. But it fully complies with any request from the Chinese government
    - EE84M3i 2y ago
      I'd be interested to learn more about that. My mental model was that Apple provides backdoor decryption keys to China in advance for devices sold in China/Chinese iCloud accounts, but that they cannot/will not bypass device encryption for China for devices sold outside of the country/foreign iCloud accounts.
    - throwaway48476 2y ago
      The venn diagram of users who don't want the government to access their data and crowdstrike customers is two circles in different galaxies.
  - xnyan 2y ago
    It's probably being run on an enterprise-managed mac. The only person who can be locked out via encryption is the user.
immibis 2y ago
The certificate private key is also a secret.
meowface 2y ago
All SIEM instances certainly contain a lot of sensitive data in events, but I'm not sure if most agents forward all environment variables to a SIEM.
- hello_moto 2y ago
  Agents don't just read env vars and send them to SIEM. There's a triggering action that caused the env vars to be used by another ... ehem... Process ... that any EDR software in this beautiful planet would have tracked.
  - st3fan 2y ago
    No it logs every command macOS runs or that you type in a terminal. Either directly or indirectly. From macOS internal periodic tasks to you running “ls”.
worik 2y ago
> Because this has been the case forever with all security and SIEM tools. Why? There is no need to send your environment variables.
- gruez 2y ago
  Otherwise malware can hide in environment variables
  - llm_trw 2y ago
    Ok, suppose you're right. Why are they only doing it for macs then?
    - batch12 2y ago
      I don't think this is limited to just Macs based on my experience with the tool. It also sends command line arguments for processes which sometimes contain secrets. The client can see everything and run commands on the endpoints. What isn't sent automatically can be collected for review as needed.
      - st3fan 2y ago
        It does redact secrets passed as command line arguments. This is what makes it so inconsistent. It does recognize a GitHub token as an argument and blanks it out before sending it. But then it doesn’t do that if the GitHub token appears in an env var.
    - st3fan 2y ago
      It may depend a bit on your organization but I bet most folks using an EDR solution can tell you that Macs are probably very low on the list when it comes to malware. You can guess which OS you will spend time on every day ...
      - llm_trw 2y ago
        So because macs are not the targets of malware ... we're locking them down tighter than any other system?
deleted 2y ago
[deleted]
chelmzy 2y ago
Most sane SIEM engineers would implement masking for this. Not sure if CS still uses Splunk but they did at one point. No excuse really.
wbl 2y ago
What do you think grants the access to the infra or ability to get a certificate?
ants_everywhere 2y ago
Ideally secrets never leave secure enclaves and humans at the organization can't even access them. It's totally insane to send them to a remote service controlled by another organization.
- Natsu 2y ago
  I mean it's right there in the name. They're not really secrets any longer if you're sharing them in plaintext with another company.
- cj 2y ago
  Essentially, it’s straddling two extremes: 1) employees are trusted with secrets, so we have to audit that employees are treating those secrets securely (via tracking, monitoring, etc) 2) we don’t allow employees to have access to secrets whatsoever, therefore we don’t need any auditing or monitoring
  - ants_everywhere 2y ago
    You give employees the ability to use the secrets, and that usage is tracked and audited. It works the same way for biometrics like face unlock on mobile phones
  - stogot 2y ago
    Exporting to a SIEM does not correlate to either of those extremes. It’s stupidity and makes auditing worse
    - cj 2y ago
      SIEM = Security Information & Event Management Factually, it is necessary for auditing and absolutely correlates with the extreme of needing to monitor the “usage” of “secrets”. In a highly auditable/“secure” environment, you can’t give secrets to employees with no tracking of when the secrets are used.
      - Aeolun 2y ago
AmericanChopper 2y ago
Keeping secrets and other sensitive data out of your SIEM is a very important part of SIEM design. Depending on what you’re dealing with you might want to tokenize it, or redact it, but you absolutely don’t want to don’t want to just ingest them in plaintext. If you’re a PCI company then ending up with a credit card number in your SIEM can be a massive disaster. Because you’re never allowed to store that in plaintext, and your SIEM data is supposed to be immutable. In theory that puts you out of compliance for a minimum of one year with no way to fix it, in reality your QSAs will spend some time debating what to do about it and then require you to figure out some way to delete it, which might be incredibly onerous. But I have no idea what they’d do if your SIEM somehow became full of credit card numbers, that probably is unfixable…
- ronsor 2y ago
  > But I have no idea what they’d do if your SIEM somehow became full of credit card numbers, that probably is unfixable… You'd get rid of it.
  - AmericanChopper 2y ago
    If that’s straightforward then congratulations, you’ve failed your assessment for not having immutable log retention. They certainly wouldn’t let you keep it there, but if your SIEM was absolutely full of cardholder data, I imagine they’d require you to extract ALL of it, redact the cardholder data, and the import it to a new instance, nuking the old one. But for a QSA to sign off on that they’d be expecting to see a lot of evidence that removing the cardholder data was the only thing you changed.
Aeolun 2y ago
If my security software exfiltrates my secrets by design, I’m just going to give up on keeping anything secure now.
benreesman 2y ago
Arbitrary bad practices as status quo without criticism, far from absolving more of the same, demand scrutiny. Arbitrarily high levels of market penetration by sloppy vendors in high-stakes activities, far from being an argument for functioning markets, demand regulation. Arbitrarily high profile failures of the previous two, far from indicating a tolerable norm, demand criminal prosecution. It is recently that this seemingly ubiquitous vendor, with zero-day access to a critical kernel space that any red team adversary would kill for, said “lgtm shipit” instead of running a test suite with consequences and costs (depending on who you listen to) ranging from billions in lost treasure to loss of innocent life. We know who fucked up, have an idea of how much corrupt-ass market failure crony capitalism could admit such a thing. The only thing we don’t know is how much worse it would have to be before anyone involved suffers any consequences.
kmacdough 2y ago
"Oh, but our system is so secure, you don't need other layers."
lolinder 2y ago
> Realistically, secrets alone shouldn’t allow an attacker access - they should need access to infrastructure or a certificates in machines as well. This isn't realistic, it's idealistic. In the real world secrets are enough to grant access, and even if they weren't, exposing one half of the equation in clear text by design is still really bad for security. Two factor auth with one factor known to be compromised is actually only one factor. The same applies here.

st3fan 2y ago

But why only forced on MacOS? I think some configurability would be great. I would like to provide an allow list or the ability to redact. Or exclude specific host groups. We all have different levels of acceptable risk

btilly 2y ago
Conspiracy theory time. Because Apple is the only OS company that has reliably proven that it won't decrypt hard drives at government request.
- vagrantJin 2y ago
  This is a true conspiracy .
  - jordanb 2y ago
    Seriously? Crowdstrike is obviously NSA just like Kaspersky is obviously KGB and Wiz is obviously Mossad. Why else are counties so anxious about local businesses not using agents made by foreign actors?
    - smolder 2y ago
      KGB is not even a thing. Modern equivalent is FSB, no? I'm skeptical. I don't think it's obvious that these are all basically fronts, as much as I'm willing to believe that IC tentacles reach wide and deep.
- iml7 2y ago
  It depends on the country it is in, it rejects the US government's request. But it fully complies with any request from the Chinese government
  - EE84M3i 2y ago
    I'd be interested to learn more about that. My mental model was that Apple provides backdoor decryption keys to China in advance for devices sold in China/Chinese iCloud accounts, but that they cannot/will not bypass device encryption for China for devices sold outside of the country/foreign iCloud accounts.
  - throwaway48476 2y ago
    The venn diagram of users who don't want the government to access their data and crowdstrike customers is two circles in different galaxies.
- xnyan 2y ago
  It's probably being run on an enterprise-managed mac. The only person who can be locked out via encryption is the user.

immibis 2y ago

The certificate private key is also a secret.

meowface 2y ago

All SIEM instances certainly contain a lot of sensitive data in events, but I'm not sure if most agents forward all environment variables to a SIEM.

hello_moto 2y ago
Agents don't just read env vars and send them to SIEM. There's a triggering action that caused the env vars to be used by another ... ehem... Process ... that any EDR software in this beautiful planet would have tracked.
- st3fan 2y ago
  No it logs every command macOS runs or that you type in a terminal. Either directly or indirectly. From macOS internal periodic tasks to you running “ls”.

worik 2y ago

> Because this has been the case forever with all security and SIEM tools. Why? There is no need to send your environment variables.

gruez 2y ago
Otherwise malware can hide in environment variables
- llm_trw 2y ago
  Ok, suppose you're right. Why are they only doing it for macs then?
  - batch12 2y ago
    I don't think this is limited to just Macs based on my experience with the tool. It also sends command line arguments for processes which sometimes contain secrets. The client can see everything and run commands on the endpoints. What isn't sent automatically can be collected for review as needed.
    - st3fan 2y ago
      It does redact secrets passed as command line arguments. This is what makes it so inconsistent. It does recognize a GitHub token as an argument and blanks it out before sending it. But then it doesn’t do that if the GitHub token appears in an env var.
  - st3fan 2y ago
    It may depend a bit on your organization but I bet most folks using an EDR solution can tell you that Macs are probably very low on the list when it comes to malware. You can guess which OS you will spend time on every day ...
    - llm_trw 2y ago
      So because macs are not the targets of malware ... we're locking them down tighter than any other system?

deleted 2y ago

[deleted]

chelmzy 2y ago

Most sane SIEM engineers would implement masking for this. Not sure if CS still uses Splunk but they did at one point. No excuse really.

wbl 2y ago

What do you think grants the access to the infra or ability to get a certificate?

ants_everywhere 2y ago

Ideally secrets never leave secure enclaves and humans at the organization can't even access them. It's totally insane to send them to a remote service controlled by another organization.

Natsu 2y ago
I mean it's right there in the name. They're not really secrets any longer if you're sharing them in plaintext with another company.
cj 2y ago
Essentially, it’s straddling two extremes: 1) employees are trusted with secrets, so we have to audit that employees are treating those secrets securely (via tracking, monitoring, etc) 2) we don’t allow employees to have access to secrets whatsoever, therefore we don’t need any auditing or monitoring
- ants_everywhere 2y ago
  You give employees the ability to use the secrets, and that usage is tracked and audited. It works the same way for biometrics like face unlock on mobile phones
- stogot 2y ago
  Exporting to a SIEM does not correlate to either of those extremes. It’s stupidity and makes auditing worse
  - cj 2y ago
    SIEM = Security Information & Event Management Factually, it is necessary for auditing and absolutely correlates with the extreme of needing to monitor the “usage” of “secrets”. In a highly auditable/“secure” environment, you can’t give secrets to employees with no tracking of when the secrets are used.
    - Aeolun 2y ago

AmericanChopper 2y ago

Keeping secrets and other sensitive data out of your SIEM is a very important part of SIEM design. Depending on what you’re dealing with you might want to tokenize it, or redact it, but you absolutely don’t want to don’t want to just ingest them in plaintext. If you’re a PCI company then ending up with a credit card number in your SIEM can be a massive disaster. Because you’re never allowed to store that in plaintext, and your SIEM data is supposed to be immutable. In theory that puts you out of compliance for a minimum of one year with no way to fix it, in reality your QSAs will spend some time debating what to do about it and then require you to figure out some way to delete it, which might be incredibly onerous. But I have no idea what they’d do if your SIEM somehow became full of credit card numbers, that probably is unfixable…

ronsor 2y ago
> But I have no idea what they’d do if your SIEM somehow became full of credit card numbers, that probably is unfixable… You'd get rid of it.
- AmericanChopper 2y ago
  If that’s straightforward then congratulations, you’ve failed your assessment for not having immutable log retention. They certainly wouldn’t let you keep it there, but if your SIEM was absolutely full of cardholder data, I imagine they’d require you to extract ALL of it, redact the cardholder data, and the import it to a new instance, nuking the old one. But for a QSA to sign off on that they’d be expecting to see a lot of evidence that removing the cardholder data was the only thing you changed.

Aeolun 2y ago

If my security software exfiltrates my secrets by design, I’m just going to give up on keeping anything secure now.

benreesman 2y ago

Arbitrary bad practices as status quo without criticism, far from absolving more of the same, demand scrutiny. Arbitrarily high levels of market penetration by sloppy vendors in high-stakes activities, far from being an argument for functioning markets, demand regulation. Arbitrarily high profile failures of the previous two, far from indicating a tolerable norm, demand criminal prosecution. It is recently that this seemingly ubiquitous vendor, with zero-day access to a critical kernel space that any red team adversary would kill for, said “lgtm shipit” instead of running a test suite with consequences and costs (depending on who you listen to) ranging from billions in lost treasure to loss of innocent life. We know who fucked up, have an idea of how much corrupt-ass market failure crony capitalism could admit such a thing. The only thing we don’t know is how much worse it would have to be before anyone involved suffers any consequences.

kmacdough 2y ago

"Oh, but our system is so secure, you don't need other layers."

lolinder 2y ago

> Realistically, secrets alone shouldn’t allow an attacker access - they should need access to infrastructure or a certificates in machines as well. This isn't realistic, it's idealistic. In the real world secrets are enough to grant access, and even if they weren't, exposing one half of the equation in clear text by design is still really bad for security. Two factor auth with one factor known to be compromised is actually only one factor. The same applies here.