Personally I disagree, I think `--` is very intuitive.
Maybe it isn't super common knowledge, but `--` is in line with the POSIX argument parsing convention[0] and is used by many (most?) GNU/BSD tools and many other tools such as `kubectl`. This StackOverflow thread[1] also has some information about it.
I think some of the information here is misleading and a bit unfair.
> being too intrusive and affecting their workflow
Kolide is a reporting tool, it doesn't for example remove files or put them in quarantine. You also cannot execute commands remotely like in Crowdstrike. As you mentioned, it's based on osquery which makes it possible to query machine information using SQL. Usually, Kolide is configured to send a Slack message or email if there is a finding, which I guess can be seen as intrusive but IMO not very.
> reading and reporting all files
It does not read and report all files as far as I know, but I think it's possible to make SQL queries to read specific files. But all files or file names aren't stored in Kolide or anything like that. And that live query feature is audited (ens users can see all queries run against their machines) and can be disabled by administrators.
> web browsing history
This is not directly possible as far as I know, but maybe via a file read query but it's not something built-in out of the box/default. And again, custom queries are transparent to users and can be disabled.
> Kolide's whole spiel about "honest security"[1] reeks of PR mumbo jumbo whose only purpose is to distance themselves from other "bad" solutions in the same space
While it's definitely a PR thing, they might still believe in it and practice what they preach. To me it sounds like a good thing to differentiate oneself from bad actors.
Kolide gives users full transparency of what data is collected via their Privacy Center, and they allow end users to make decisions about what to do about findings (if anything) rather than enforcing them.
> It's built by Facebook alumni, after all, and relies on FB software (osquery).
For example React and Semgrep is also built by Facebook/Facebook alumni, but I don't really see the relevance other than some ad-hominem.
Full disclosure: No association with Kolide, just a happy user.
It's news _from_ 2023, not news about things that happened only in 2023. Things might have improved starting years ago but the research to show it wasn't finished until this year, so it's also about celebrating seeing progress and improvements.
Limiting the list to things improving only since 2022 seems unnecessarily restrictive and we'd miss a lot of positive and interesting news.
Great to see your commitment but I'm also curious why you, unlike some other companies, have chosen not to support with any full time employees? It seems your business is largely based on Terraform and saying pretty much "we'll contribute code" doesn't signal too much commitment.
I realize my comment might sound like an accusation but that's not my intention, I want to hear your reasoning about it!
This would require you or the person in the data center to know which customer is using which disk. And data isn't stored on just one disk, it's spread out over multiple disks and many customers have shards of data stored on the same disk. So even if this did happen, the would only get fragments of data.
Part of it, maybe. But the point about it reducing risk by very little is true.
> Did you see other comments in this thread, for example someone bought a drive online and turned out it still had some backblaze data?
Backblaze data is encrypted, or so they claim. Backblaze is also not hosted on AWS. I've also yet to see any evidence of that claim, though I don't dismiss it.
Data is sharded/spread out over multiple disks, you don't have one disk per customer and have all their data there. You'd get fragments of data. If Backblaze was running their servers on specific disks that were not encrypted, not zeroed, and not destroyed, that'll have to stand for them. Backblaze is hosted in a shared data center/colocation, while AWS has their own data centers with their own personnel. Backblaze is a separate company from AWS.
> Do you bother with Spectre mitigations since Amazon policy is to deny service to those who would attack you?
I don't go out of my way to mitigate that, no. Have you seen any real attacks with this? They seem very rare and hard to execute, especially if you have someone specific in mind.
> Do you bother requiring authentication on your database since policy is to use a closed VPC?
Yes. Usually you have multiple services running in the same VPC, by using authentication you limit the potential impact if one service is hacked. Adding authentication to a database that previously had none is also very easy.
> Hell, we haven't seen any man in the middle attacks lately, let's just drop SSL because you know your customers are wired and trust the endpoint networks.
MITM attacks are quite common actually. Internally inside AWS (i.e. between instances) the benefit of TLS is maybe questionable, especially since traffic is encrypted between instances automatically (depending on the instance type).
> Encrypting disks is mandatory and there is zero justification otherwise.
I disagree that there is "zero justification otherwise." I've updated the blog post some and I'm interested to hear your thoughts about it. But in short, adding encryption to an unencrypted machine can take a lot of time and effort. Setting it up correctly from the start is usually easy, but it's not always whoever set it up initially did that. There are many things one can do to improve security, and most things will probably be more beneficial than re-encrypting disks.
It lowers the risk a minimum amount (which makes it not useless, but close to it.) Your resources are limited, so you want to prioritize actions that have good cost:benefit ratio.
Re-encrypting disks is a significant effort (cost), effort that could be spent on something with better benefit. Should you spend a day encrypting a database or should you spend it on looking over publicly exposed S3 buckets? Ideally both, but resources are limited. Doing one action always means you're putting off something else.
I agree. The problem is mainly going from an infrastructure that's not setup like this, to an infrastructure that is.
Usually you inherit an infrastructure, and it's usually not set up in this way (in my experience) and then there is a lot of work to re-encrypt the data in order to use KMS rather than the default key.
> it is typically standardized in an org
I have still not found any SCP I can set that prevent the use of the default key and enforces KMS. If you have one, I'd be happy to take it! If you mean "standardized" as in written on a paper, I'll rely on wishful thinking because people make mistakes or just don't know about it even if it's a standard.
> Saying that something is hard to clean up later isn't “close to useless and potentially harmful”
The "close to useless" is based on it lowering any risk with very little, it's not a big payoff security wise in most cases. "Potentially harmful" refers to the cost of potentially having to re-encrypt data, that is cost/effort that could instead be spent on other security mitigations with better cost:benefit ratio.
You have a limited amount of resources, and with those resources you want to lower the risk as much as possible. I consider re-encrypting data to fare badly in such calculation. It's a high effort low benefit mitigation in most cases. If encryption is done correctly, it might cost little effort and gives little benefit and might therefore be worth it. It's very common to not do it correctly though, and that requires re-encrypting. I have not found an SCP that allows KMS keys but not default encryption keys, which means manual effort is spent on teaching developers and/or build/use tooling.
> And yes, default service KMS keys are unique per account (why would you expect otherwise?).
I expect it to be unique per account, but I would be happy if it was possible to share it with other accounts so one could make cross account backups (it's good practice to have a separate AWS account for backups.) Currently this requires a KMS key, which means data encrypted with the default key must be re-encrypted and that takes a lot of time and effort.
> It’s more that the author is arguing that their inexperience is universally applicable. “Why do banks have guards, I’ve never had someone break into my couch cushions?”
That was not my intention and it's unfortunate that's how it sounds. Just like most people don't need armed guards, most people don't need bank level security for their disks either. Encrypting disk encryption is usually not the most effective thing you can do to improve your security, there are usually other actions with better payoff.
AWS zeroes the disks before they're reused, so from your point of view it's instant. As mentioned in the post, deleting a KMS key takes at least 7 days (and up to 30 days, depending on your configuration.) Regarding other point, that's also mentioned in the post as "if your IAM access configuration is bad your KMS access configuration might save you," which is referring to what you mention.
> It’s something you turn on and basically never think about again - the performance hit disappeared around 2010 and it’s easy to enable globally.
This is true if you, or the one you inherit the infrastructure from, configured it correctly from the start. But re-encrypting disks, databases, S3-buckets etc is time consuming and might require downtime. So it's not always easy or cost free (in terms of labor.) I'm not sure what you're referring to with "easy to enable globally", enable what?
I agree calling it snake oil is a bit too much, because I know there are benefits.
As I mention elsewhere in the thread, I use encryption, but I don't consider it to be of high value compared to other security mitigations one can spend time on.
As mentioned in the blog post, setting up encryption isn't always easy and problem free though.
Regarding 1, disks are physically destroyed if they are inoperable. Thanks for sharing the list of potential problems, it's always interesting to see how other people think and what they worry about!
You put it really well, I think that's close to how I think about it.
Compliance has good sides too though. For example, they force you to think about areas your intuition might otherwise not have gone, so I don't dismiss them but sometimes it makes you spend time on less than optimal things in order to stay compliant.