> To be upfront, I do not have access to a full Tanium install;
...
> The entire article will be speculative, based on logical reasoning imposed on information from their website.
I've seen security vendors fail far too often to think they're infallible, but I've also seen overzealous security 'researchers' make incorrect claims about vulnerability based on misconfiguration or lack of product knowledge. This however goes so far beyond... At least he/she had the chutzpa to say it upfront.
There is an undercurrent of "This is completely unacceptable," but anyone who's been a pentester will tell you these are pretty standard enterprise blunders.
Rather than trying to expose malfeasance, try to write with a spirit of helping others correct problems. Everyone screws up security, even HN: https://news.ycombinator.com/security.html
I still don't know what IOC is supposed to be an acronym for. Why do people insist on relying on initialisms, three letter acronyms, and pronounceable syllable salad to evoke an air of super-duper smartness?
Especially security professionals. Especially complaining security professionals. It reeks of bougie, evasive posturing.
> If each workstation is doing data aggregation of the data it’s receiving from its peers, what does that require about its ability to read the plaintext data from its peers?
Uh, nothing? Encryption has existed for several decades?
I mean, I have no idea if they're actually using encryption, but "use logical reasoning" is not an explanation of why they necessarily must not be using encryption.
> As you should have discovered from the previous challenges, it would be impossible for peers to perform deduplication/aggregation with other peers if they were unable to see cleartext/plaintext data.
This is absolutely incorrect.
> The first thing to note is that the "hashing" algorithm appears to be something home grown, as opposed to an industry standard (md5, sha1, etc.).
This needs proof that this is what the actual client does, as opposed to just an example for a human-readable FAQ for readers who don't know what hashing is. (Also, I question the competence of someone who's writing up an analysis and thinks of MD5 and SHA-1 as their first industry-standard hashes.)
(Full disclosure: I am unaffiliated with Tanium and have never used it, but I think a couple of former coworkers from a now-failed startup now work there.)
It has a nice interface for enterprise security staff. It is supposed to reveal security problems for enterprises. While it does a pretty good job to report common attacks, it is useless for identify above average hackers and introduces new vulnerabilities that are a hacker heaven.
In general, anybody that is after the enterprises's data will consider any enterprise software a huge honey pot.
If you are serious about security, invest the money that you pay for Tanium's licenses to hire security experts, instead than IT candies for below average security staff.
There's a lot of talk about data confidentiality, but I would argue that the data you could get from any one endpoint would be useful for reconnaissance within its own peer neighborhood, and not much else, but I welcome use cases where I'd be wrong.
Additionally, downloading a client without getting the public key for the server won't help you - you can't just connect to any server you find. The author then links to a KB article about generating a different key than the one he would need anyway.
Relying on any vendor's documentation for proof of anything is the first mistake this author made. Giving himself an out by not actually trying any of these things, or weighing drawbacks against the benefits, means this is little more than speculative clickbait.
> Additionally, downloading a client without getting the public key for the server won't help you - you can't just connect to any server you find.
Right. The fact that the client is publicly accessible is a point in the vendor's favor, if anything: the fact that this "auditor" seems to think security-by-obscurity is a good idea makes me question why I bothered to read any of it.
9 comments
[ 3.6 ms ] story [ 38.3 ms ] threadI've seen security vendors fail far too often to think they're infallible, but I've also seen overzealous security 'researchers' make incorrect claims about vulnerability based on misconfiguration or lack of product knowledge. This however goes so far beyond... At least he/she had the chutzpa to say it upfront.
Rather than trying to expose malfeasance, try to write with a spirit of helping others correct problems. Everyone screws up security, even HN: https://news.ycombinator.com/security.html
Also, 21 exclamation points are a bit much.
If you're looking for a model for good technical writing, NCC Group makes some of their audit reports available publicly, e.g. https://www.nccgroup.trust/us/our-research/ricochet-security...
Yes, 17 is the limit!
Especially security professionals. Especially complaining security professionals. It reeks of bougie, evasive posturing.
Uh, nothing? Encryption has existed for several decades?
I mean, I have no idea if they're actually using encryption, but "use logical reasoning" is not an explanation of why they necessarily must not be using encryption.
> As you should have discovered from the previous challenges, it would be impossible for peers to perform deduplication/aggregation with other peers if they were unable to see cleartext/plaintext data.
This is absolutely incorrect.
> The first thing to note is that the "hashing" algorithm appears to be something home grown, as opposed to an industry standard (md5, sha1, etc.).
This needs proof that this is what the actual client does, as opposed to just an example for a human-readable FAQ for readers who don't know what hashing is. (Also, I question the competence of someone who's writing up an analysis and thinks of MD5 and SHA-1 as their first industry-standard hashes.)
> 13.x.y.133 Amazon Corporate Services Pty Ltd
... This is an AWS host. Attributing it to Amazon itself is just incompetent. https://ip-ranges.amazonaws.com/ip-ranges.json
(Full disclosure: I am unaffiliated with Tanium and have never used it, but I think a couple of former coworkers from a now-failed startup now work there.)
It has a nice interface for enterprise security staff. It is supposed to reveal security problems for enterprises. While it does a pretty good job to report common attacks, it is useless for identify above average hackers and introduces new vulnerabilities that are a hacker heaven.
In general, anybody that is after the enterprises's data will consider any enterprise software a huge honey pot.
If you are serious about security, invest the money that you pay for Tanium's licenses to hire security experts, instead than IT candies for below average security staff.
Additionally, downloading a client without getting the public key for the server won't help you - you can't just connect to any server you find. The author then links to a KB article about generating a different key than the one he would need anyway.
Relying on any vendor's documentation for proof of anything is the first mistake this author made. Giving himself an out by not actually trying any of these things, or weighing drawbacks against the benefits, means this is little more than speculative clickbait.
Right. The fact that the client is publicly accessible is a point in the vendor's favor, if anything: the fact that this "auditor" seems to think security-by-obscurity is a good idea makes me question why I bothered to read any of it.