7 ms·

I have a lot of thoughts on this, having worked on security teams, and now running a company. 1. Employees and customers are who the company should be serving.

I have a lot of thoughts on this, having worked on security teams, and now running a company. 1. Employees and customers are who the company should be serving. It isn't "employees at the cost of customers", or vice versa. If your business can't do both it shouldn't exist. In this case the thought was "It's worth making employees upset because this addresses a real customer concern". 2. Phishing tests are silly. You should just assume someone will get phished. If you want to do trainings, do trainings. Or, better yet, make phishing pointless - at my company anything important is gated by a U2F token, among other things. We are simply 'immune' to most types of phishing - the one major source left being wire transfer fraud, which is fairly easy to avoid. We only do phishing training for compliance purposes. 3. This is the wrong kind of security. It's "blame the user" security. It's a silly, backwards, outdated, ineffective attitude. If the goal is "Make sure people report phishing", you can do that without trickery. Just send an email and request that users report it to whoever is responsible - you'll soon find who does or does not know how to do so. 4. (Editing in) Security teams should be aware of how what they're going to do is impacting the company. The impact of this phishing test has had public impact on the company - that's a disaster. A security team is about managing risk, and here they've instead subjected the company to concrete, public scrutiny. This was simply the wrong call. Having trust in your security team is really important. Security teams need to do outreach, they need to be friendly, and be people who everyone feels good about going to with a problem. Building animosity for the sake of phishing protection is far more dangerous. > If this was a real phish they'd have leaked real data. Perhaps even your data. That's the security team's problem, not the victims!

xyzelement 6y ago
The term "defense in depth" comes to mind. Of course, ideally the IT team has screened out the phishing attempt and secured systems as much as they can. If they do it perfectly, then your comment applies and nothing else matters. If, however, the security team cannot be perfect, some amount of bad stuff will land with the users. This seems realistic. So training people to be security-minded is useful. It's the next line of defense. How do you train your users? "Just send an email and request that users report it to whoever is responsible" as you mention is one thing. But you can also imagine someone complying with that but then falling for a well crafted phish (that happened to me, as I mention elsewhere in this thread.) Being confronted with falling for something makes people take the threat more seriously. It takes someone's attitude from "it can't happen to me" to "oh, it did happen to me." >> at my company anything important is gated by a U2F token, among other things. We are simply 'immune' to most types of phishing I don't know your business' threats but that seems naïve. Imagine your sales team gets a phish email asking them to list your biggest customers, including contact info and revenue "so that we can send them an appropriate thank you gift for the holidays." If someone replies to this/fills out the form, you have leaked critical information even though nobody has penetrated your system (so your tokens don't help.) Even if this type of thing isn't a problem for your business, you can imagine it is for many.
- staticassertion 6y ago
  > The term "defense in depth" comes to mind. Perhaps my least favorite phrase in security, used constantly to justify weak, meaningless, or harmful work as "another layer". U2F is just one layer. It's a real, meaningful layer - it addresses real threats in a non-phishable way. Gating access by device, acls, etc, or locking down sharing permissions, are other real and meaningful layers. > some amount of bad stuff will land with the users That's the security team's problem to solve. > But you can also imagine someone complying with that but then falling for a well crafted phish (that happened to me, as I mention elsewhere in this thread.) I can just assume that one person will fail the phishing test already, and work from that angle. Way better than assuming I can teach an entire company to be untrickable. > Is there no data that humans can leak out by entering it in the wrong place? Wire transfers were one example - there are others, and we have other ways to mitigate those without assuming users should bear the responsibility. By 'most types' I mean either phishing for credentials or as a delivery mechanism for malware - these would both be extremely difficult to do, or otherwise mitigated by other policies. > but you can imagine that in many businesses there is. That's their security team's problem to solve. Feel free to train users, I have no problem with it. We do it for compliance purposes, but it's also a fun opportunity to engage with people about security, including meaningful security. And you do want people to be able to spot and report phishing, it's just not something you should ever rely on, or compromise for.
  - xyzelement 6y ago
    I can't tell your thesis here. I agree you can't expect people to provide full defense, and it doesn't sound like you disagree that helping people act more securely is important. In my example, there's a difference between whether one sales person leaked their business numbers, or the entire 100 person department did. You train users to minimize the vulnerability even if you can't fully solve it. If you agree that far - then I am not sure where we're disconnecting on this question.
    - staticassertion 6y ago
      I would imagine we're disagreeing with the "at what cost"? As in, is the cost of: 1. Losing the trust of your coworkers 2. Causing public reputation damage 3. Potentially harming coworkers emotionally worth the gain of having a slightly more effective phishing training? I would argue no. I would also say that it isn't nearly as important as implementing other measures - U2F being a big one that I'd mentioned, but there are plenty of others. It's certainly not where I'd recommend anyone start.
nickt 6y ago
Almost sounds like openness and honesty goes a long way!
aeternum 6y ago
You should not assume that U2F makes you 'immune' to most types of phishing. If your assumption is that users will fall for phishing tests then it follows that they will present their U2F token or simply take some action on behalf of the attacker directly.
- staticassertion 6y ago
  The point of U2F is that they can't do that. For example, if I send you a fake Google login page, you can't "trick" me into entering my token - it won't work. Here's a good blog on the topic: https://dropbox.tech/security/introducing-webauthn-support-for-secure-dropbox-sign-in https://dropbox.tech/security/introducing-webauthn-support-f...
  - aeternum 6y ago
    Why do I need your token data when I can just ask you to use your creds to grant me access to my twitter account? Or 'I'm on vacation and left my laptop, could you just run this command on the prod cluster for me so we can avoid downtime over the holidays?'
    - staticassertion 6y ago
      Yeah, if you'll read that blog post it'll explain exactly that. U2F tokens are a second factor for authentication, meaning that to log into your account you need your password and the token. Further, the token takes the domain into account when it's generating the key. That means that you can't just give me a fake Twitter page and then forward the creds/token, it won't be valid. U2F mitigates this entire class of phishing attack. Beyond that, we also only allow logins to sensitive services from employee laptops, validated by a TPM, and multiple other controls, but that's not really the point. > Or 'I'm on vacation and left my laptop, could you just run this command on the prod cluster for me so we can avoid downtime over the holidays?' Right, so this would work, but it's a huge gap between "Hey run this command for me" and the attacker being able to run arbitrary commands. It's a reasonable thing for your security team to consider and attempt to mitigate in other ways.

xyzelement 6y ago

The term "defense in depth" comes to mind. Of course, ideally the IT team has screened out the phishing attempt and secured systems as much as they can. If they do it perfectly, then your comment applies and nothing else matters. If, however, the security team cannot be perfect, some amount of bad stuff will land with the users. This seems realistic. So training people to be security-minded is useful. It's the next line of defense. How do you train your users? "Just send an email and request that users report it to whoever is responsible" as you mention is one thing. But you can also imagine someone complying with that but then falling for a well crafted phish (that happened to me, as I mention elsewhere in this thread.) Being confronted with falling for something makes people take the threat more seriously. It takes someone's attitude from "it can't happen to me" to "oh, it did happen to me." >> at my company anything important is gated by a U2F token, among other things. We are simply 'immune' to most types of phishing I don't know your business' threats but that seems naïve. Imagine your sales team gets a phish email asking them to list your biggest customers, including contact info and revenue "so that we can send them an appropriate thank you gift for the holidays." If someone replies to this/fills out the form, you have leaked critical information even though nobody has penetrated your system (so your tokens don't help.) Even if this type of thing isn't a problem for your business, you can imagine it is for many.

staticassertion 6y ago
> The term "defense in depth" comes to mind. Perhaps my least favorite phrase in security, used constantly to justify weak, meaningless, or harmful work as "another layer". U2F is just one layer. It's a real, meaningful layer - it addresses real threats in a non-phishable way. Gating access by device, acls, etc, or locking down sharing permissions, are other real and meaningful layers. > some amount of bad stuff will land with the users That's the security team's problem to solve. > But you can also imagine someone complying with that but then falling for a well crafted phish (that happened to me, as I mention elsewhere in this thread.) I can just assume that one person will fail the phishing test already, and work from that angle. Way better than assuming I can teach an entire company to be untrickable. > Is there no data that humans can leak out by entering it in the wrong place? Wire transfers were one example - there are others, and we have other ways to mitigate those without assuming users should bear the responsibility. By 'most types' I mean either phishing for credentials or as a delivery mechanism for malware - these would both be extremely difficult to do, or otherwise mitigated by other policies. > but you can imagine that in many businesses there is. That's their security team's problem to solve. Feel free to train users, I have no problem with it. We do it for compliance purposes, but it's also a fun opportunity to engage with people about security, including meaningful security. And you do want people to be able to spot and report phishing, it's just not something you should ever rely on, or compromise for.
- xyzelement 6y ago
  I can't tell your thesis here. I agree you can't expect people to provide full defense, and it doesn't sound like you disagree that helping people act more securely is important. In my example, there's a difference between whether one sales person leaked their business numbers, or the entire 100 person department did. You train users to minimize the vulnerability even if you can't fully solve it. If you agree that far - then I am not sure where we're disconnecting on this question.
  - staticassertion 6y ago
    I would imagine we're disagreeing with the "at what cost"? As in, is the cost of: 1. Losing the trust of your coworkers 2. Causing public reputation damage 3. Potentially harming coworkers emotionally worth the gain of having a slightly more effective phishing training? I would argue no. I would also say that it isn't nearly as important as implementing other measures - U2F being a big one that I'd mentioned, but there are plenty of others. It's certainly not where I'd recommend anyone start.

nickt 6y ago

Almost sounds like openness and honesty goes a long way!

aeternum 6y ago

You should not assume that U2F makes you 'immune' to most types of phishing. If your assumption is that users will fall for phishing tests then it follows that they will present their U2F token or simply take some action on behalf of the attacker directly.

staticassertion 6y ago
The point of U2F is that they can't do that. For example, if I send you a fake Google login page, you can't "trick" me into entering my token - it won't work. Here's a good blog on the topic: https://dropbox.tech/security/introducing-webauthn-support-for-secure-dropbox-sign-in https://dropbox.tech/security/introducing-webauthn-support-f...
- aeternum 6y ago
  Why do I need your token data when I can just ask you to use your creds to grant me access to my twitter account? Or 'I'm on vacation and left my laptop, could you just run this command on the prod cluster for me so we can avoid downtime over the holidays?'
  - staticassertion 6y ago
    Yeah, if you'll read that blog post it'll explain exactly that. U2F tokens are a second factor for authentication, meaning that to log into your account you need your password and the token. Further, the token takes the domain into account when it's generating the key. That means that you can't just give me a fake Twitter page and then forward the creds/token, it won't be valid. U2F mitigates this entire class of phishing attack. Beyond that, we also only allow logins to sensitive services from employee laptops, validated by a TPM, and multiple other controls, but that's not really the point. > Or 'I'm on vacation and left my laptop, could you just run this command on the prod cluster for me so we can avoid downtime over the holidays?' Right, so this would work, but it's a huge gap between "Hey run this command for me" and the attacker being able to run arbitrary commands. It's a reasonable thing for your security team to consider and attempt to mitigate in other ways.