If you would like to read the other parts in this article series please go to:
- Security: A Shared Responsibility (Part 1)
- Security: A Shared Responsibility (Part 2)
- Security: A Shared Responsibility (Part 3)
- Security: A Shared Responsibility (Part 5)
- Security: A Shared Responsibility (Part 6)
In this multi-part series, we’re taking a look at the big picture of security areas of responsibility and how each component (internal job position or external entity) fits into the puzzle, with a discussion of the importance of defined areas of responsibility. In the first article of the series, we looked closely at the role of the CSO or CISO, at the top of the IT security structure. In Part 2, we continued the discussion with an examination of the security role(s) of IT administrators, and then we talked about the responsibilities of outside contractors, consultants and partners to whom you grant access to some or all of your IT resources.
In Part 3 we started looking at the security responsibilities of end users and how you can turn them into responsible members of the security team. In this, Part 4, we’re going to continue that discussion.
Don’t over- or underestimate users
In the previous installment, we talked about how IT admins often see end users as their adversaries and how this is detrimental to accomplishing your objective, which is to get them to engage in best security practices to help protect the network. Another mistake that admins make is either overestimating or underestimating users’ technical knowledge and abilities.
We touched on that briefly in regard to end user security awareness training; however, it applies not only in the classroom but also when dealing with users in the daily work routine. Overestimating users means expecting them to understand nuances of security that you, as an expert, understand. Many of the security principles that seem obvious to you aren’t to your users, and most (though not all) of the time, users who commit serious violations of security best practices do so out of ignorance rather than intentional malice.
Users have a role and responsibilities regarding security, but remember that it’s not their primary job. They are focused on getting the financial report out on time, or selling the product or service to the client, or getting the marketing presentation ready, or whatever tasks are top priority in their particular positions. They can’t be expected to have the expertise or care as much about security as you do.
Underestimating users refers to the assumption that none of them are clever enough, tech savvy enough or in some cases malicious enough to circumvent your security mechanisms intentionally. There will always be a handful of users who see it as a challenge. Another thing that you might want to keep in mind is that some users who do have a bit of technical knowledge may feel insulted by having to follow the same rules as the technically clueless. However, that doesn’t mean they know as much as they think they do, or that it’s safe to allow them special privileges. The key is in how you handle them, and the goal is to enlist them in the security efforts by making them feel that you recognize their abilities while still explaining the necessity for the controls and why they apply to everyone.
Define end user responsibilities
In keeping with the caveat that you can’t expect users to “just know” what does and doesn’t constitute good security practice, it’s important to define users’ responsibilities in writing – and ensure that the users sign off on having received and understanding those policies.
Policies should be clear-cut and actionable. For example:
All end users are expected to:
- Enable logon authentication on personally owned or company devices with strong password/passphrase, smart card, token or biometric authentication.
- Never divulge your password/passphrase or loan your smart card to anyone else.
- Never log on and allow another user to use your device under your logon credentials.
- Lock the device whenever you leave it and enable automatic locking after [defined] period of idle time.
- Keep personally owned devices up to date by applying operating system and application security updates on a regular basis [specifically define the regularity, i.e. weekly, bi-weekly, monthly. Don’t leave details open to interpretation].
- Install and use anti-virus and anti-malware software on all devices and keep definitions up to date.
- Install and enable a firewall on all devices and/or install and configure a hardware firewall on the network when working remotely.
- Configure web browser security settings to the highest level that will allow you to get your work done.
- Use [specified] secure methods when transferring company or work-related files.
- Never share work-related files with others within or outside the company without authorization.
- When sending email or documents containing [defined] sensitive company information, always use encryption and rights management services to control who can access the content and what they can do with it. Restrict copying, forwarding, and modifying content.
The above is only a sample of a set of end user policies and you will most likely have more. It’s intended as an example of how to write concise, simple, easily understood definitions of user responsibilities in the form of policies.
Be forewarned, though, that it’s best to keep your policy to a minimum. If you make it too long, users will just skim over it and not really think about understand the requirements. A good rule of thumb is that they should be able to read it in 10 minutes or less. Attention spans today – especially in the fast-paced business world – are short.
While you don’t want to come across as too heavy-handed, the policies should also clearly state what the consequences for violation are. Otherwise, they’re not rules; they’re merely recommendations. Responsibilities come with consequences but you can’t penalize users for violating the policies if they haven’t been told what those consequences are. And it can’t be stressed enough that the rules have to be applied equally – those consequences should be the same for every user; otherwise, the company could find itself facing consequences of its own on the legal front.
Finally, each policy should have a corresponding procedural guideline so that end users have a reference where they can go to find out how to do what’s necessary to comply with the policy. If you require them to encrypt their email, you need to provide documentation of the procedure for doing so. If you require that they check to ensure that Windows updates are installed, the procedural document needs to explain how to do that. Never assume that users know how to do something just because it’s second nature for you. Give your users the tools they need to carry out their responsibilities.
Consider the human factor
Remember that you’re dealing with people whose actions may be driven by feelings rather than logic at least some of the time. We mentioned the user with some degree of technical knowledge who takes offense at being restricted in the same way as less technical astute users. Another example is the user who is a perfectionist/over achiever in other areas of life, and makes security blunders because he/she is embarrassed to admit to not understanding and doesn’t want to ask questions about how to do something.
There are countless other situations where users’ fear, anger, guilt or other emotions can interfere with their ability or desire to do the right thing from a security standpoint. Social engineers are notorious for taking advantage of human emotions. A user who knows better might give out a password to a social engineer who is intimidating and makes the user feel that not doing so will result in repercussions from higher-ups. Or a user might be persuaded to reveal information out of sympathy if the social engineers convinces the user that he will lose his job if he isn’t able to get into the system.
Another element that comes into play in terms of the human factor is that it’s human nature to want to take the easy way out. Users may abandon best security practices when they’re in a hurry and under pressure to get things done, or when they’re tired or don’t feel well, or just because they’re lazy.
Technology, as frustrating as it can be at times, is generally easier to deal with than human beings because there is (most of the time) an underlying logic to the way it behaves. Many IT admins are “geeks” by nature, and that often includes being more of a loner and perhaps not particularly polished in social skills. That makes it more difficult for IT people to handle end users in the most effective ways, because getting the users on your side often requires you to be a “people person.”
Uncomfortable as it might be at first, it’s well worth spending some times to develop your people skills, since the payoff isn’t limited to better interactions with end users but will also benefit you tremendously in communicating with your superiors, outside persons (vendors, clients) and in many ways in your personal life.
In this, Part 4 of our multi-part series addressing security as a shared responsibility, we wrapped up the discussion of end user responsibilities. In Part 5, we’ll talk about the responsibilities of software vendors.
If you would like to read the other parts in this article series please go to: