Hacker News new | past | comments | ask | show | jobs | submit login

inside job?



Anything's possible, but the simplest explanation (per Occam's razor) is just that the employee was fooled.

Is it plausible that if a good social engineer cold-called a bunch of employees, they'd eventually get one to reveal some info? Yes, it happens quite frequently.

So any suggestion that it was an inside job, or used deep fakes, or something like that would require additional evidence.

Kevin Mitnick's "The Art of Deception" covers this extensively. The first few calls to employees wouldn't be attempts to actually get the secret info, it'd be to get inside lingo so that future calls would sound like they were from the inside.

For example, the article says the caller was familiar with the floor plan of the office.

The first call might be something like "Hey, I'm a new employee. Where are the IT staff, are they on our floor?" - they might learn "What do you mean, everyone's on the 2nd floor, we don't have any other floors. IT are on the other side of the elevators from us."

They hang up, and now with their next call they can pretend to be someone from IT and say something about the floor plan to sound more convincing.


how's that Zero Trust architecture working out for everyone ?


They mention in the article that their zero-trust architecture is what prevented the attacker from gaining access to on-prem data. So it seemed like it worked pretty well in mitigating the damage.


I'm curious if they actually mean "Zero trust" in the "perimeterless" sense (https://en.wikipedia.org/wiki/Zero_trust_security_model) or if they just mean their on-prem solution doesn't require trusting some central service operated by Retool.


The latter


What’s this got to do with zero trust?


it is a cynical comment that is meant to hilite the relationship between humans where oppressive and untrusting employment leads to increase in antipathy, ill-will, feelings of being abused and all of that leading to insider theft and serious pre-meditated betrayal ?


Zero Trust is such a bad branding for how the architecture works. It's just "always prove" architecture.


“Always prove” and “zero ambient trust” are basically the same thing, no?

Perhaps “authenticate everything, everywhere” is better, but falls into the trap of trying to define “everywhere” and “everything”: should every single client application have to authenticate? Should you have to authenticate Ethernet frames?


I think we may mean the same thing, but zero trust has a connotation of negative rights, versus always prove is a way of framing things in a more positive assertion. At least that's worked for me at the last couple of places i've been.

Should every client application have to authenticate and authorize? Probably not every but the overwhelming majority probably and those that don't should have a good justification as to not. The challenge after that is "how long is this good for?".


It does seem to sound pretty well on the mind of the executives signing the deals that hear the marketing talk




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: