6 ms·

Quarterly password resets, five different "single sign on" services, no admin for devs. Sometimes I feel like the idea is just to kill productivity.

by edrxty 5y ago

ok123456 5y ago
When I have to work in a "no admin for devs" environment, I just take admin access one way or another. They kill productivity in exchange for job security.
- goldenkey 5y ago
  There's no shortage of privilege escalation bugs in Windows, Mac and Linux. Hell, if you spend a week with a decent dissasembler, even an amateur can probably find a 0-day.
- SV_BubbleTime 5y ago
  I’m CTO and have an admin account for whatever i need but… I STILL have an off domain laptop for emergency or diagnostic or debug use.
- AnIdiotOnTheNet 5y ago
  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?
nine_k 5y ago
According to NIST, quarterly password resets are useless. If your SSO isn't, use a good password manager. Admin access for devs should be audited, and devs should understand that now they need some opsec. Like, separate work and personal machines; if not physically, at least use a different account, better yet, a VM. To say nothing about adding suspicious email / IM attachments. Remember, devs: you are a potential attack vector, a very efficient one.

Quarterly password resets, five different "single sign on" services, no admin for devs. Sometimes I feel like the idea is just to kill productivity.

by edrxty 5y ago

Quarterly password resets, five different "single sign on" services, no admin for devs. Sometimes I feel like the idea is just to kill productivity.

ok123456 5y ago

When I have to work in a "no admin for devs" environment, I just take admin access one way or another. They kill productivity in exchange for job security.

goldenkey 5y ago
There's no shortage of privilege escalation bugs in Windows, Mac and Linux. Hell, if you spend a week with a decent dissasembler, even an amateur can probably find a 0-day.
SV_BubbleTime 5y ago
I’m CTO and have an admin account for whatever i need but… I STILL have an off domain laptop for emergency or diagnostic or debug use.
AnIdiotOnTheNet 5y ago
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?

nine_k 5y ago

According to NIST, quarterly password resets are useless. If your SSO isn't, use a good password manager. Admin access for devs should be audited, and devs should understand that now they need some opsec. Like, separate work and personal machines; if not physically, at least use a different account, better yet, a VM. To say nothing about adding suspicious email / IM attachments. Remember, devs: you are a potential attack vector, a very efficient one.