5 ms·

One things I always wonder - Why do IT folks, people who are supposedly expert in computers, fall for phishing emails etc? You'd think they'd know better. Coup

One things I always wonder - Why do IT folks, people who are supposedly expert in computers, fall for phishing emails etc? You'd think they'd know better. Couple of years ago I was working at the offshore office of a large internet company. They claimed that their platform touched nearly 15-30% of internet users. They had a large Security Operations Center to ensure every threat was monitored and mitigated. Our software and systems were frequently flagged for security issues. Any suggestions to alleviate the issue fell on deaf ears. The onshore US IT team always complained about how security changes will make life difficult for them. The biggest critic was someone who had once opened a phishing mail and got his password stolen (using memory dumps in Windows). While the offshore team was afraid that pushing US onshore team too hard might put their jobs in danger. And as if getting hacked wasn't enough, these guys exchanged plain text files containing everyone's salary via email. No amount of training or meeting helped. Finally, a roundabout solution was put in place. Give US folks two laptops - one with heavy encryption for work and second, for checking mails. But they wouldn't budge on spending salaries in plain text. They said, it was easier for them to manage this way.

TeMPOraL 8y ago
> Why do IT folks, people who are supposedly expert in computers, fall for phishing emails etc? Phishing is a numbers game. Make it convincing enough, send to enough people, and wait for someone who's too busy/tired to think to fall for it. > The onshore US IT team always complained about how security changes will make life difficult for them. Because that's absolutely true and valid complaint. From their point of view, they're being paid for doing jobs, and then the company starts spending money to prevent them from doing their jobs. I've been on the receiving end of this in the past, where only sanity of our internal IT team prevented making all software development take 3 times longer, because the company decided to apply some completely bullshit "security practices" they found in ISO-whatever compliance handbook. Security needs to work with people, not against people. You can't just announce security changes that utterly destroy existing workflows, without helping develop equivalent replacement workflow (with all corner cases accounted for), and while still expecting the same amount of work from people. You'll just see people push back hard, and then ignore the new changes to the extent possible while still trying to meet their deadlines.
- keanebean86 8y ago
  The dumbest security restriction I've dealt with is not giving devs local admin access to their work compeers. In a previous job I had to contact my manager every time I needed to install or update software. Sometimes he had to get approval from the IT gods before he could do anything. I usually just figured out ways to run applications without installing them. It was a huge waste of time. From what I understand a dev installed something bad one time so they punished everyone. Then again that's usually how these things happen.
  - TeMPOraL 8y ago
    Oh yes. Taking away admin access was one of the dumb ISO-whatever security restrictions they tried to impose on us top-down. We could retain it iff we signed a form that put any and all responsibility and blame for any problems coming from our admin access on us personally. Fortunately, right people in the right places arranged it so the forms got "lost", and admin access was not taken away.
  - 666lumberjack 8y ago
    I'm in a similar situation right now. In order to install new software onto my computer I have to get IT to add it to a company-wide whitelist, so I don't bother.
  - closeparen 8y ago
    This is a pretty good “culture fit” question to ask a prospective employer in an interview. If the answer is wrong it won’t be the only thing wrong.
  - nieve 8y ago
    At a previous employer that policy was continually causing problems and I'd been able to fly under their radar since all they did was issue hardware to myself and my minions†. Eventually IT staff came around needing the root password for my dev machine and things got awkward very quickly when I explained they didn't have internal clearance to log into it, much less view any data, and they'd have to go ask a senior vice president for direct approval in writing. They were some of the best IT people I've worked with, but they'd just run into a situation where they were the people who needed permission and they had to create exceptions on the fly. There's always going to be a place where the process breaks down and either you give the IT people room to adjust their policies or you make them sit on their hands and pretend nothing is going on. † Not my terminology.

TeMPOraL 8y ago

> Why do IT folks, people who are supposedly expert in computers, fall for phishing emails etc? Phishing is a numbers game. Make it convincing enough, send to enough people, and wait for someone who's too busy/tired to think to fall for it. > The onshore US IT team always complained about how security changes will make life difficult for them. Because that's absolutely true and valid complaint. From their point of view, they're being paid for doing jobs, and then the company starts spending money to prevent them from doing their jobs. I've been on the receiving end of this in the past, where only sanity of our internal IT team prevented making all software development take 3 times longer, because the company decided to apply some completely bullshit "security practices" they found in ISO-whatever compliance handbook. Security needs to work with people, not against people. You can't just announce security changes that utterly destroy existing workflows, without helping develop equivalent replacement workflow (with all corner cases accounted for), and while still expecting the same amount of work from people. You'll just see people push back hard, and then ignore the new changes to the extent possible while still trying to meet their deadlines.

keanebean86 8y ago
The dumbest security restriction I've dealt with is not giving devs local admin access to their work compeers. In a previous job I had to contact my manager every time I needed to install or update software. Sometimes he had to get approval from the IT gods before he could do anything. I usually just figured out ways to run applications without installing them. It was a huge waste of time. From what I understand a dev installed something bad one time so they punished everyone. Then again that's usually how these things happen.
- TeMPOraL 8y ago
  Oh yes. Taking away admin access was one of the dumb ISO-whatever security restrictions they tried to impose on us top-down. We could retain it iff we signed a form that put any and all responsibility and blame for any problems coming from our admin access on us personally. Fortunately, right people in the right places arranged it so the forms got "lost", and admin access was not taken away.
- 666lumberjack 8y ago
  I'm in a similar situation right now. In order to install new software onto my computer I have to get IT to add it to a company-wide whitelist, so I don't bother.
- closeparen 8y ago
  This is a pretty good “culture fit” question to ask a prospective employer in an interview. If the answer is wrong it won’t be the only thing wrong.
- nieve 8y ago
  At a previous employer that policy was continually causing problems and I'd been able to fly under their radar since all they did was issue hardware to myself and my minions†. Eventually IT staff came around needing the root password for my dev machine and things got awkward very quickly when I explained they didn't have internal clearance to log into it, much less view any data, and they'd have to go ask a senior vice president for direct approval in writing. They were some of the best IT people I've worked with, but they'd just run into a situation where they were the people who needed permission and they had to create exceptions on the fly. There's always going to be a place where the process breaks down and either you give the IT people room to adjust their policies or you make them sit on their hands and pretend nothing is going on. † Not my terminology.