If you have read any of my posts or attended my webinars about security awareness, training, compliance, or other IT risk management items, you will notice a recurring theme: expecting technology to do all of the work in preventing a security or risk-related event is not the correct mindset. Rather, creating a culture of risk management is the key. This means that the staff of an organization feel like stakeholders and want to protect technology and data assets.
One of the early steps in establishing this culture is creating a suitable Acceptable Use Policy. Before I get into how to approach this policy, let’s review how this policy is defined.
An Acceptable Use Policy is a series of rules that define what end users may or may not do with their technology. Usually, this policy requires some kind of acknowledgment that the rules are well understood, including potential consequences of violation, before issuing any kind of log into the system. A good policy not only outlines these rules but also explains the general rationale for their existence, so staff will ultimately buy into the concept and not see the rules as arbitrary or unreasonable.
An organization that wants to protect any assets from a technology perspective should have an Acceptable Use Policy. Unless you define the rules for using your technology (even if you fear your staff will not follow them to the letter), there is no reason for you to expect your employees to act responsibly. Frankly, I would expect staff to abuse provided technology unless rules are clearly outlined.
While it may seem like the best policy is for management to lock everything down and restrict staff, a good Acceptable Use Policy should be far more nuanced. Here are a few items to consider when drafting and distributing your Acceptable Use Policy:
1. Consider Impacts Before Establishing Rules
As I mentioned earlier, your policy should make sense so that staff understand why it exists and buy into the culture of compliance. Therefore, the rules you build for a good policy should be practical. If something bad were to happen (regardless of whether it had to do with the end user), what would be the consequence to the organization? Would it lead to system failures impacting the organization and its partners?
If so, the policy should focus on those kinds of issues and the behaviors associated with preventing those consequences. For example, if an organization is handling Social Security numbers, which could be highly consequential if leaked, then the policy should specify the sensitivity of this data and the specific ways it can be handled.
On the other hand, you will want to consider the impacts in context. Any organization could create rules about browsing the web and establish overly restrictive rules that only permit a small number of websites. In some cases, that’s not a bad idea because it could be the right policy rule. However, you also need to be reasonable and allow people to work and use technology in a flexible way.
If an employee is using their computer to order lunch, maybe that’s not the intended purpose for the technology, but it’s really not going to create much goodwill restricting this kind of mostly benign personal use of computers. Staff will find ways to work around a policy if they feel it is not reasonable, and that’s the kind of behavior you want to avoid.
If you haven’t gone through the process of identifying risks and the impacts of those risks, it’s really important to have some kind of discussion or risk assessment before drawing up rules that may or may not fit your organization.
2. Define What Data Matters and Why
Staff needs to know what the organization cares about when it comes to data. What needs to be backed up? What should be encrypted in transmission? Why is that data valuable? Is it a legal matter, a trade secret, or perhaps just sensitive and embarrassing if leaked or lost? When this is well defined up front, it will create an expectation that staff can apply generally even if they forget a specific rule defined in the policy.
3. Define Any Compliance or Legal Concerns
Some rules should be based on best practices, or business impacts, and these don’t necessarily have to do with the government or a compliance standard. But for a number of organizations, there are specific regulatory concerns such as HIPAA, PCI, SOX, etc. A good policy should speak to both best practices and compliance standards.
Additionally, while many organizations may not need to comply to a standard at present, they may need to in the future, and a good policy should be flexible enough to adjust. This leads me to my next point…
4. Solicit Feedback From Stakeholders and Revisit Policy
It should come as no surprise that as technology changes, so should the associated policies with that technology. Even if things are going well and you have established a strong culture, your policies will need to adjust over time. New staff will come on board, and they will need to be taught the proper rules, as well. Plus, everyone needs a refresh once in a while. This feedback loop is very important and will help make policy stronger and easier to manage.
5. Consider Personally Owned Devices That Access Company Data Assets
Ultimately, the most valuable part of your system is the data you control. In general, organizations that have major breaches or loss of data face significant challenges moving forward. Therefore, your policy should focus on controlling and securing data. As such, I would encourage any organization that allows staff to “Bring Your Own Device” to consider device usage as part of their Acceptable Use Policy.
While not a substitute for a Mobile Device Management (MDM) technical control, there should be clear rules about what organizational data is allowed on mobile devices and expectations regarding how that data is stored and transmitted. A MDM solution may allow you to establish things like forced passwords or device wipes, but the Acceptable Use Policy should create the expectation that, for instance, sending unauthorized text messages with organization data is a serious issue. This will also reinforce the idea of general user awareness for the proper use of company data regardless of the device being used at the time.
6. Social Media
This can be tricky. Social media can be a very productive tool for organizations but obviously, it can also be a time waster and, even worse, a potential outflow of sensitive information or a tool as part of a phishing scam. Social media also transcends the IT infrastructure of the organization, so it’s important to take a broad view of this just like you would with personally owned devices.
7. Utilize Existing Policy Tools and Templates
I work with a number of small businesses, and most of them don’t hire high-priced attorneys to draft complicated documents every time they want to establish a new rule for staff. Fortunately, there are groups like SANS that provide useful templates, free of charge, to management who wish to utilize these (and other) policies. Granted, these templates should be used as a starting point to establish things like policy format and general ideas, so it is important to customize your policy to fit your organization’s needs.
This is not an exclusive list of considerations, and ultimately, I can’t prescribe a perfect Acceptable Use Policy unless I know your organization personally. What is right for you probably won’t be right for others. However, if you are mindful of these considerations and use the vast online resources available as well as professionals who can give you personalized advice, an Acceptable Use Policy can help reduce the risks associated with day-to-day IT management.
About the Author: Ben Schmerler is a vCIO Consultant at DP Solutions, one of the most reputable IT managed service providers (MSP) in the Mid-Atlantic region. Ben works with his clients to develop a consistent strategy not only for technical security, but also policy/compliance management, system design, integration planning, and other business level technology concerns. You can follow DP Solutions updates on LinkedIn or their website: www.dpsolutions.com.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.