NetworldWorld has a fun article up about sysadmins and the Insider Threat! (Here if print link doesn’t work to save you 4 page-clicks.) This is a decent article if you give it a chance through 4 pages, and overlook the fact that it hyper-skims over enough topics to fill a book.
“It doesn’t mean they’re guilty of anything,” Theis adds. “Sometimes they’re just trying to get the job done, but they’re outside the bounds of the organizational policy.”
Sometimes IT workers are pushed by demanding users, such as business and sales managers, to perform tasks in a hurry or to violate official IT policy by, for instance, adding printers on network segments where that’s not allowed.
Many suggestions in the article are correct suggestions, but are appropriate really for larger enterprises, and completely ignore the SMB. To its credit, the article does briefly cover some of what I consider the bedrock approaches to the topic of privileged IT insider threats.
1. Hiring practices. You’re hiring someone who may have access to your entire asset line and data. You better have decent hiring practices in place for background checks, credit checks, proper valuation, and so on. In the SMB, your admins are pretty much gods, even if you don’t want them to be.
2. Management directly. No amount of automation will remove the need for proper, close management of privileged users to determine if they are disgruntled, have pressures going on in their lives, and so on. The warning signs are almost always there.
3. Management protection. Many (all?) times IT staff are just trying to solve a problem. The management needs to be outwordly present to protect their staff from bending to those pressures. Don’t leave your employees to handle the brunt of pissed users who then return back poor customer service reports which influences staff to be more lenient to get better reviews. That’s a downward spiral that will erode security.
4. High-Level policy. There must be policies in place on what the company and management expects for architecture, security stance, behavior, and so on.
5. Standards/procedures. This is a tough one, but there should always be procedures for admins to follow to accomplish common tasks, and guidelines (along with aforementioned policies) when solving new problems. One person should not solve a recurring task in their own way which may erode security. This happens way too often. Collaboration amongst peers helps as well. In the SMB, don’t undervalue consistent verbal standards/policies. (I know, some people will argue and say policies need to be written [*slammed fist*], but I believe the verbal side has realistic weight.)
6. Peer management. No one likes a snitch, but employees are very good at sensing changes and ethics in their peers. If someone is going through a hard time, or suddenly is acting suspicious, or you get an untrustworthy vibe, handling these sorts of things should be encouraged, either through a manager or through interaction. I wonder how many “disgruntled” employees could have been helped through better relationships in the workplace.
7. Awareness of options. This article presents a nice array of options on this topic, but most of them really require additional staff and tools to accomplish, beyond the reach of many SMBs. But it is still nice to know what options are out there and evaluate if something may be appropriate.
8. Audit access. This can either be simple or enterprise-worthy, so I won’t go deep into it. But have some approach for auditing access and who has the ability to use shared accounts, and so on. This can be some quarterly manual review, a brainstorming verbal session, or something vastly larger. The point is not to be surprised by who has access to what.
Got linked to this via the Infosecnews mailing list.