Hacker News new | past | comments | ask | show | jobs | submit login

If you want to get employees to lock their workstations, make it a policy and fire the ones who repeatedly break it. If you have to get their attention via childish pranks it's a waste of everyones time.

Also, the IT provider has put a lot effort into security for a reason. The second any employee starts shell coding of any type, it becomes a risk to the company. Management, as always, is blind to this and is probably why they rewarded the author. What they should have done is fire the person for breaching the company's User Access policy. (You do have one, right?)

It may be the employees lunch hour, but it's not their right to abuse company property.




> the IT provider has put a lot effort into security for a reason

It really depends. All too often the reason for various restrictions IT set up is to limit their own workload. It sometimes goes to the point of making everyone else's work harder. It's especially irritating in schools and universities, where I could swear IT departments often live by the idea of "if we make a system X completely unusable, nobody will use it, so we won't have people breaking things".


I can safely say that it's never to limit our own workload. Considering we'd get paid less if we had nothing to do, it would be pretty dumb to work towards that goal. It's to save the company from going bankrupt with explosive costs of maintaining infrastructure in a hostile environment.

Any and all restrictions are there to prevent risk, to both data security and operational costs. There's nothing worse than allowing a user to do as they please because as Bruce Schneier once said, "A user will choose dancing pigs over security every time."

This is why we work with management to show them the costs of allowing users the ability to roam free. Management makes the decisions, IT implement it.

Security is hard. It is highly invasive to usability. It's not your IT department's fault, it's actually yours.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: