Timeline for Handling fallout due to new security policies
Current License: CC BY-SA 3.0
19 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 4, 2021 at 22:33 | vote | accept | Anthony | ||
Jan 4, 2021 at 0:50 | answer | added | mxyzplk | timeline score: 7 | |
Jan 3, 2021 at 22:32 | answer | added | Beth | timeline score: 1 | |
Dec 12, 2017 at 4:18 | vote | accept | Anthony | ||
Jan 4, 2021 at 22:33 | |||||
Nov 30, 2017 at 9:21 | answer | added | Fildor | timeline score: 5 | |
Nov 30, 2017 at 5:09 | answer | added | cjs | timeline score: 9 | |
Nov 14, 2017 at 3:32 | history | edited | Anthony | CC BY-SA 3.0 |
Edited to respond to questions in comments
|
Nov 9, 2017 at 15:09 | comment | added | JAB | Why do your end users need production server access often enough for this to be a problem? Production servers should not be used for dev work and if they're constantly having to make changes to production then something's being done wrong in their workflow. (Of course, if this is a startup where people are used to doing things in an unstructured manner and don't have a strict dev-to-production protocol then it would make some sense why such procedures aren't already in place.) | |
Nov 8, 2017 at 12:08 | comment | added | Brandin | How did you notify the affected persons of the changes? A company-wide e-mail might have been ignored, only skimmed, or forgetten. Something like a reminder banner near the top of affected pages might help. | |
Nov 8, 2017 at 12:00 | comment | added | Brandin | "the new security measure are getting in the way of them performing their jobs" - What about finding a technical solution to specific problems? "Getting in the way" is not specific. Example: "I didn't need to supply my password every time on this page before; now it is slowing down my work." Solutions: password-less logins using private/public key pairs, use a password manager, etc. | |
Nov 8, 2017 at 10:09 | history | tweeted | twitter.com/StackWorkplace/status/928202902182744064 | ||
Nov 8, 2017 at 9:24 | comment | added | Lilienthal♦ | @Anthony Thanks for clarifying. Are these policies motivated by legal requirements or is it simply a matter of increasing operational security in an era of leaks and highly visible public security scandals? And has either reason been clearly comunicated to your end users? What I mainly wanted to ask in my first comment is what your main goal right now is. I assume that given your description there's no real way for users to not comply and you're just trying to find a strategy to mitigate the grumbling and get users to see why you're making things more complicated for them? | |
Nov 8, 2017 at 1:05 | comment | added | Anthony | @Lilienthal - yes end users are complaining that the new policies are cumbersome and slowing down users work. I only used one new policy as an example. I also added more description on the reasoning for implementing such policies as you had requested. | |
Nov 8, 2017 at 1:02 | history | edited | Anthony | CC BY-SA 3.0 |
Edit to explain reasoning for policy change as requested by a commenter
|
Nov 7, 2017 at 7:53 | comment | added | Lilienthal♦ | What's the actual problem? Non-compliance? Grumbling? The latter is to be expected when policies change. How you can sell something like this depends on details you haven't provided, specifically the actual reasons you're implementing changes. | |
Nov 7, 2017 at 5:28 | answer | added | DarkCygnus♦ | timeline score: 8 | |
Nov 7, 2017 at 5:11 | answer | added | Kilisi | timeline score: 10 | |
Nov 7, 2017 at 4:39 | comment | added | Patricia Shanahan | How much involvement did the users have in reviewing and testing the policies before they went live? | |
Nov 7, 2017 at 4:26 | history | asked | Anthony | CC BY-SA 3.0 |