As a part of Secureworks’ Incident Response Team, Secureworks® is continually performing incident response tabletop exercises to help our customers prepare for a potential cybersecurity incident. Each exercise is a bit different and may have different goals; for example, one customer may place emphasis on increasing familiarity with how to respond to a cybersecurity incident while another customer may desire to stress test their plan.
Regardless of the specific goals for the tabletop exercise, common trends emerge between different customers regardless of their industry vertical or maturity.
For Whom Security Policies Do Not Apply
An exceptionally common finding during tabletop exercises is the practice of granting individual users or departments the right to operate outside the purview of information security policies and controls.
We can all agree that information security policies and controls exist for good reasons. It makes sense to have a password complexity policy and technical controls that ensure a user cannot define their password as “password.” It also makes perfect sense to have an information security policy that prohibits users from e-mailing work data to personal e-mail addresses with technical controls to reaffirm this policy.
But what happens when users are exempt from these security controls based on their job function?
Part of our job during a tabletop exercise is to poke and prod commonly known risk factors. While some vulnerabilities may be unique to the customer’s vertical, there are several well-known vulnerabilities that run astray of codified information security policies are observed time and time again.
For example, two common situations that we commonly encounter often run afoul of information security policies:
- Communications and marketing personnel who monitor social media accounts at all hours of the day are using personal devices to monitor said accounts and post content. When several of those personnel have responsibility for posting, passwords are often shared among team members, fail to meet password complexity requirements and rarely leverage multi-factor authentication.
- A law firm partner, professor at an educational institution or business owner is using devices for convenience purposes that are not built or configured to the organization’s standard and may not be supported by security tools.
For both of these situations, almost always, there is an information security policy that should have prevented the events from occurring.
Special Cases Cause Special Incidents
Unfortunately, the aforementioned situations serve only to increase risk to the organization. Time and time again, Secureworks assists on cybersecurity incidents that do not originate from a breakdown in security controls aligned with information security policies, but instead from situations where users operate in an ambiguous gray area with partial (or no) adherence to said policies, providing fertile ground for risk and leading to cybersecurity incidents.
Certainly, ironclad adherence to policies without exception is not advisable. There are almost always reasons to deviate from a policy; however, it is important to establish a deviation process that enables the organization to understand the risk and determine if the risk is acceptable or if alternate solutions exist. At the very least, the organization should be aware of, record and monitor the risk via a risk register. Deviations to information security policies should never be spurious, nor haphazard.
Where to go From Here?
There are many reasons why employees engage in the kinds of risky behavior described in the scenarios above. Here are some of those reasons and what you can do to change the paradigm:
- A lack of executive buy-in regarding the information security policies: start at the top when you establish policies and ask for an executive sponsor to help reinforce them.
- Information security policies that do not provide a deviation process: establish a process and ensure the business doesn’t have an overly cumbersome evaluation to deviations.
- A lack of accountability: should a deviation be approved, a defined group should be on record as willing to accept the risk for the deviation.
- No risk register: documentation enables a periodic re-evaluation of the risk as well as a method to re-certify its existence.
- No way to test the policy and process: (*plug!*) an outside expert can conduct a tabletop exercise designed to look for those common deviations. Organizations and people aren’t static, so testing also ensures that policies evolve with the business.
Connect with author: https://www.linkedin.com/in/lelewski/
