2 ms·

The lesson here is this: if you make it too inconvenient for people to do their jobs, regardless of why, people will work around you to get things done. Effecti

The lesson here is this: if you make it too inconvenient for people to do their jobs, regardless of why, people will work around you to get things done. Effective security policy must take this into account.

korethr 5y ago
I can't upvote this enough. I have worked IT long enough to see some impressive creativity by users to defeat security policies getting in the way of doing their jobs. I have argued that the raison d'etre of security policy is to ensure the existence and continuity of an environment in which work can get done. I've been told about the importance of the C.I.A triad and other things as though they were refutations of my point, often in tones of voice implying an attitude that this not-security|compliance-tech-is-incapable-of-knowing-what-he's-talking-about-and-therefore-can-be-ignored. I counter-argue that C.I.A et. al. are not refutations of my thesis, but in fact support it. If you can't ensure the confidentiality, integrity, and availability of information or systems for yourself or your customers, you do not, and/or will not, have an environment in which work can get done. So, for the love of getting shit done, stop masturbating with broad and blind application of checklists, and take the time to sit down, really look at what you're trying to do and why, and develop actually useful risk models. And then develop security policies against those risk models. Yes checklists and various standards are useful tools that can help you cover a lot of common stuff, but are not the whole picture.
- SAI_Peregrinus 5y ago
  A bad security policy is an attack on the Availability part of C.I.A. Your security policy definitely shouldn't lead to leaking information or falsifying data, why is it so acceptable to make system availability go to shit?

2 ms·

The lesson here is this: if you make it too inconvenient for people to do their jobs, regardless of why, people will work around you to get things done. Effecti

by AnIdiotOnTheNet 5y ago

korethr 5y ago
I can't upvote this enough. I have worked IT long enough to see some impressive creativity by users to defeat security policies getting in the way of doing their jobs. I have argued that the raison d'etre of security policy is to ensure the existence and continuity of an environment in which work can get done. I've been told about the importance of the C.I.A triad and other things as though they were refutations of my point, often in tones of voice implying an attitude that this not-security|compliance-tech-is-incapable-of-knowing-what-he's-talking-about-and-therefore-can-be-ignored. I counter-argue that C.I.A et. al. are not refutations of my thesis, but in fact support it. If you can't ensure the confidentiality, integrity, and availability of information or systems for yourself or your customers, you do not, and/or will not, have an environment in which work can get done. So, for the love of getting shit done, stop masturbating with broad and blind application of checklists, and take the time to sit down, really look at what you're trying to do and why, and develop actually useful risk models. And then develop security policies against those risk models. Yes checklists and various standards are useful tools that can help you cover a lot of common stuff, but are not the whole picture.
- SAI_Peregrinus 5y ago
  A bad security policy is an attack on the Availability part of C.I.A. Your security policy definitely shouldn't lead to leaking information or falsifying data, why is it so acceptable to make system availability go to shit?