This blog covers the risks of creating security exceptions – often overlooked, manipulated and out of control – and how to reengineer the process to maintain a secure environment.
Picture a company that’s the envy of its peers from a compliance and risk perspective. This respected firm has robust staff in its internal audit, security, risk management, and related departments. It has a fully functioning GRC system and tracks control effectiveness globally under multiple compliance frameworks.
When the company’s employees attend conferences and events, they are flooded with questions about “how they do it” or what “mature” looks like in their environment. With all these things in place, the risk of a significant breach, control failure, or risk event should be low. However, this program has one glaring hole – which happens at nearly every company – the security exception program lacks maturity and has spiraled out of control.
What Are Security Exceptions?
A security exception is when a policy, procedure or control is temporarily bypassed, using an exception process, for valid business reasons. It’s an “exception to the rule” justified by the company’s business mission, so to speak. All companies have a legitimate need to grant information security exceptions. You can never say never when it comes to information security, considering the unlimited ways technologies are used and how quickly they’re emerging.
Common security exceptions include:
- A firewall port must be opened or a ruleset must be modified to support a critical business operation or application.
- A specialized vendor system was configured to enforce a user password that does not meet the organization’s password policy requirements (e.g., expiration, length, complexity, and more).
- A proprietary business system allowed for only one admin ID, yet a team of admins supported it, resulting in noncompliance with the policy prohibiting shared user IDs.
- Some laptop operating systems used within the organization did not support policies for USB blocking or whole-disk encryption.
- A (very old) legacy system was depended upon for business processing but did not have the options available to meet compliance with some of the information security policy technical requirements. For example, all users were given admin privileges in the application.
- A key business system support employee was in an accident, requiring an exception to the access policy to allow a co-worker to use the employee’s ID and cover time-critical business processing requests because no backup process was in place.
Security exceptions are not explicitly addressed by any published security or control framework, which makes them easy to overlook and inadvertently exclude from risk and control programs.
Risks of Creating Security Exceptions
Creating security exceptions opens new risk vectors that are difficult to manage without a formal, repeatable and scalable process and should not be taken lightly. The following are risks of creating security exceptions:
- Weakened layers of security due to lack of thought around ripple effects.
- Poor tracking of exception expiration, leading to “permanent” exceptions.
- Absent or deficient communication to all stakeholders.
- Key controls not performed over long periods.
- Regulatory violations and associated fines and punishments.
Maintain a Secure Environment by Reengineering the Process
An effective way to identify improvements, efficiencies and automation opportunities is to revisit stale processes. This is also true for security exceptions. Mapping the current process is a great start to reengineering a new one that will meet the risk mitigation needs of an organization.
1. Out With Old, in With New
Security exception listings can quickly get out of control without a refined process. Hasty approvals, missing expiration dates, and lack of tracking compensating controls can create problems. A great place to start a process-refinement analysis is to ask questions that may clarify the challenges of the current security exception environment.
Working through these preliminary questions will help identify exceptions with a defined business need. On the other hand, most companies find they can modify or completely discard many of their current exceptions. This exercise can immensely reduce an organization’s risk profile. While some manual investigation and stakeholder interaction may be involved, it will create future efficiencies.
2. Implementation
After redesigning a new process, implementation is the next challenge. You need to consider many things during implementation, including stakeholders, roles, enterprise risk management, criteria, and service level agreements. These program pillars (stakeholders, roles, enterprise risk, and so on) are critical to the success of the overall information security exception management process, and you must apply them strategically and methodically.
The key to success is having a security exception management process in place and consistently following it. Some components to consider include centralized exceptions, compensating controls, approvals, accountability, time limits, escalations, monitoring, renewals, and removals.
3. Risk, Oversight and Governance
Mature information security exception programs will be well-defined at the governance level and involve regular input from subject matter experts. For example, someone who lacks proven firewall management experience should not decide for a requested exception to a firewall rule change.
Conversely, there must be a governance process to support the enterprise risk criteria of the organization. In this situation, just because the firewall subject matter expert approves the exception exclusively from a perimeter defense perspective doesn’t mean it should be automatically granted. The exception could increase the risk to the organization. The decision-making process should examine enterprise risk, suitable governance, subject matter expertise, and appropriate oversight.
4. Reporting and Training
It’s essential to get valuable data into stakeholders’ hands to manage the security exception process effectively. Proper reporting will help avoid the pitfalls of the past and improve the process moving forward.
Ongoing reporting of exceptions should include the following items:
- Trends (root cause analysis).
- List of policies that have exceptions.
- Remediation status.
- Risk profile at any point in time.
It is unlikely that patterns will become apparent if several different manual solutions are used to handle exceptions. This is a serious deficiency, as trend analysis may only identify root causes. In some cases, you can reduce or eliminate exceptions by modifying the process in which they occur.
Many employees view dealing with exceptions as a “necessary evil.” However, exceptions are also an opportunity because they provide a direct view into how well policies and standards are being followed and, in some cases, whether those overarching documents are the problem. Proper training and reporting on the process can prevent many pitfalls.
Incorporating Automation
With the proper systems in place, managing exceptions moves from a manual to an automated process, instantly delivering value. This happens by tracking the exception requests and overlaying them with the underlying assignee or program data to identify trends.
Yet, you should approach automation cautiously: Adopting technological measures to prevent individuals from intentionally or unintentionally bypassing the process also helps implement the new program successfully. Before considering automation, you should examine the current process and map out the desired process. As every business environment is different, automation will make sense in some cases but not in others.
Automation of exception management provides an opportunity to make an unpleasant task more palatable and efficient. This can lead to a shorter time to resolution and help bend employees’ perceptions in a positive direction. More importantly, automation provides management of the tools to get ahead of the requirements and better evaluate the underlying policies and standards.
As an example of how automation can greatly improve a complex security exception process, a Fortune 500 organization found that 84 percent of nearly 750 exception requests submitted in a given year received approval. This high percentage indicates it was too easy to gain approval of an exception.
Meanwhile, the organization’s security team spent roughly 40 minutes managing each exception, creating an additional $90K cost for approving exceptions – the equivalent of a full-time employee. Using a system to collect and track the data, the organization set up automatic approval thresholds and tweaked policies, dramatically reducing the time spent managing the exceptions while improving the overall user experience.
Security Exceptions – The Ultimate Weakness
The reasons for nonperformance of a policy, procedure or control may include business needs, technological limits, staffing issues, and more. Controls and procedures are established to make organizations more secure and ensure management’s objectives are met. Creating exceptions to these rules opens a new risk vector that is difficult to control and track and should not be taken lightly.
Nonetheless, exceptions to information security policies are inevitable. That’s why all organizations must be prepared by designing, documenting and implementing an effective information security exception management process. An effective program once rolled out or re-engineered, commonly shifts a culture.
Like change management’s impact on many organizations, information security exception awareness will require a new set of supporting, repeatable processes. These new practices will require top-to-bottom buy-in to prevent employees from bypassing the process. While this is crucial for maintaining a secure environment, so are the documentation and supporting processes needed to comply with a wide range of requirements.
Bottom line: every business needs a comprehensive, consistent, regularly updated policy for determining when to make security exceptions, and when to remove them, with protocols and instructions that are easily understood, and implemented, by all stakeholders involved in this process.