Security is a big deal. Why not make a big deal out of someone trying to subvert it?
I never minced words with developers I was assisting, just said "turn around while I log in, please" and then if I had belatedly noticed they were looking, I changed any relevant passwords after we had parted company on that occasion. But I was usually working with their setups anyway, in their presence, so the security of my own login data was rarely an issue.
After I started working in data security, no developers tried to cop my passwords anyway: they mostly just stopped stashing their own login data under their keyboards or on their monitors, at my request, whenever I happened to notice stuff like that while in their cubes to help them with space requisitions or test setups etc.
On the third cruise-by and seeing a developer still in noncompliance on stupid stuff like that, I used to go back to my office and change the passwords for all his or her accounts without notification, as well as changing any passes that other devs had "lent" to him or her and that I had seen end up posted in plain view with a username and password.
They all knew in advance that all that was going to be the drill. Shrug. Live and learn. Some people apparently prefer to get schooled instead of acting like wusses or whatever they used to think basic IT security compliance was about.
Where do we draw the line? After we catch a dev using a production password he nicked somehow, so as to skip making tests of some "simple fix"?? I kept the pressure on right at the level of developer setups so it was clear that username/pass security all mattered, bottom to top... unless it was the CEO talking to me or the SVP of my own section. Then I did whatever they wanted, but documenting it every step of the way and leaving my fingerprints in the system complete with comments.
Security compliance is not a popularity contest, but further it's only as good as who's willing to pay for it and have it enforced. The enforcer is sometimes caught in the middle because it's really and fairly obviously true that no corporation's interested in security that actually prevents conduct of business.
The only way to deal with that fact as a security manager is to document the exceptions one can be asked to make by someone who has the power to make the request stick. I never figured a developer was in that position, because he wasn't. I was willing to say no or make a security patch that inconvenienced him, and then if his boss or his client's boss wanted to pursue that with someone who could change my mind about it, that was fine too.
Sometimes it was fun listening to those guys try to justify what they had asked me to do. Even as it rolled off their tongues you could see the wheels turning as they listened to themselves and considered the risks they had taken. Sometimes you can end up feeling like corporate officers shouldn't talk trash to security managers in the middle of the night without their house counsel present lol.
The funny thing is that I didn't care one way or another, it was just my job. I cared exactly as much as that CEO or SVP cared, full stop. If I'd been a developer I'd have been angling to run as root all the time...
I never minced words with developers I was assisting, just said "turn around while I log in, please" and then if I had belatedly noticed they were looking, I changed any relevant passwords after we had parted company on that occasion. But I was usually working with their setups anyway, in their presence, so the security of my own login data was rarely an issue.
After I started working in data security, no developers tried to cop my passwords anyway: they mostly just stopped stashing their own login data under their keyboards or on their monitors, at my request, whenever I happened to notice stuff like that while in their cubes to help them with space requisitions or test setups etc.
On the third cruise-by and seeing a developer still in noncompliance on stupid stuff like that, I used to go back to my office and change the passwords for all his or her accounts without notification, as well as changing any passes that other devs had "lent" to him or her and that I had seen end up posted in plain view with a username and password.
They all knew in advance that all that was going to be the drill. Shrug. Live and learn. Some people apparently prefer to get schooled instead of acting like wusses or whatever they used to think basic IT security compliance was about.
Where do we draw the line? After we catch a dev using a production password he nicked somehow, so as to skip making tests of some "simple fix"?? I kept the pressure on right at the level of developer setups so it was clear that username/pass security all mattered, bottom to top... unless it was the CEO talking to me or the SVP of my own section. Then I did whatever they wanted, but documenting it every step of the way and leaving my fingerprints in the system complete with comments.
Security compliance is not a popularity contest, but further it's only as good as who's willing to pay for it and have it enforced. The enforcer is sometimes caught in the middle because it's really and fairly obviously true that no corporation's interested in security that actually prevents conduct of business.
The only way to deal with that fact as a security manager is to document the exceptions one can be asked to make by someone who has the power to make the request stick. I never figured a developer was in that position, because he wasn't. I was willing to say no or make a security patch that inconvenienced him, and then if his boss or his client's boss wanted to pursue that with someone who could change my mind about it, that was fine too.
Sometimes it was fun listening to those guys try to justify what they had asked me to do. Even as it rolled off their tongues you could see the wheels turning as they listened to themselves and considered the risks they had taken. Sometimes you can end up feeling like corporate officers shouldn't talk trash to security managers in the middle of the night without their house counsel present lol.
The funny thing is that I didn't care one way or another, it was just my job. I cared exactly as much as that CEO or SVP cared, full stop. If I'd been a developer I'd have been angling to run as root all the time...
