3 ms·

I do not agree. This should also be implemented in financial institutions and any company that has access to overly sensitive information, especially that whic

I do not agree. This should also be implemented in financial institutions and any company that has access to overly sensitive information, especially that which you can not easily change or that would put your family at risk of harm. I would add in my proposal that if a percentage of employees under a director fall for it, the director gets let go. If a number of directors are let go, the C-Level is let go and so on.

noxToken 7y ago
Like the sibling comment, I think it all should depend on the roles of the people as well. You need strict access controls in place to ensure that access rights are well defined such as no/read-only access for certain data in certain environments, physical access control, etc. Someone who does client-facing retail at a financial institution should not have access to production data. As such, them getting phished won't have the same impact as senior developer with production read access.
- LinuxBender 7y ago
  I completely agree. If the company has performed proper compartmentalization of access and clearly documented who has access to what and it isn't just pencil-whipping, but you can prove the access is really compartmentalized, then the risk is reduced. I mention the pencil whipping because I have seen financial institutions put on a really good show, but under the covers they are not doing proper management of ssh key trusts, ssh multiplexing, port forwarding, sudo or network access or encryption keys and they know which engineers to put in front of the auditors.
- cryptonector 7y ago
  In practice there's often a way to escalate privilege. Defense in depth requires that one be good at each layer. Being good against phishing attacks is important even when the victim has apparently-inconsequential access.
GFischer 7y ago
At a financial institution I worked for, they had a separate entrance with separate badges and alarms for the really sensitive stuff. I only entered that area once, as I was a low-level programmer. It was also the only company where I never ever made a query on the production server :) (I worked for another financial institution on a more senior role and I did have scary access to the production DB).

noxToken 7y ago

Like the sibling comment, I think it all should depend on the roles of the people as well. You need strict access controls in place to ensure that access rights are well defined such as no/read-only access for certain data in certain environments, physical access control, etc. Someone who does client-facing retail at a financial institution should not have access to production data. As such, them getting phished won't have the same impact as senior developer with production read access.

LinuxBender 7y ago
I completely agree. If the company has performed proper compartmentalization of access and clearly documented who has access to what and it isn't just pencil-whipping, but you can prove the access is really compartmentalized, then the risk is reduced. I mention the pencil whipping because I have seen financial institutions put on a really good show, but under the covers they are not doing proper management of ssh key trusts, ssh multiplexing, port forwarding, sudo or network access or encryption keys and they know which engineers to put in front of the auditors.
cryptonector 7y ago
In practice there's often a way to escalate privilege. Defense in depth requires that one be good at each layer. Being good against phishing attacks is important even when the victim has apparently-inconsequential access.

GFischer 7y ago

At a financial institution I worked for, they had a separate entrance with separate badges and alarms for the really sensitive stuff. I only entered that area once, as I was a low-level programmer. It was also the only company where I never ever made a query on the production server :) (I worked for another financial institution on a more senior role and I did have scary access to the production DB).