How do you handle cybersecurity policy exceptions?

To show your security training expertise to clients, you need to have a deep understanding of the latest threats and trends, be able to communicate complex concepts clearly, use a variety of teaching methods, tailor your training to your clients' needs, and provide ongoing support. You can also share your insights and stories from your own experience, use effective methods and tools to deliver your training, and get feedback from your clients.

It is equally important to have the business leader's name that is accepting the risk on behalf of the company so that when bad things happen, the right person is held accountable.

Optimally, you will quantitatively identify the amount of risk you are accepting above the policy baseline. For example, if you are making an exception to your vulnerability management policy, you will state something like "we are accepting an additional $100,000 in annual loss expectancy (ALE) above our risk appetite." Focusing on individual vulnerabilities doesn't really make that much sense, because the cumulative risk surface of your network is what matters.

Exceptions can be created in many ways Three form of exception - false positives - risk acceptance with mitigation - risk acceptance A false positive is an indefinite risk acceptance for something is known to be not true Risk acceptance with mitigating controls is the acceptance of the risk a vulnerability introduce with some mitigation Overall risk acceptance is a bad practice because can leave indefinite risk open

In the end, the only reason to approve an exception is if the potential reward of granting it outweighs the risk incurred by doing so. This is why cyber risk quantification is so important: it allows you understand the costs of a potential action in terms of marginal risk taken on. Business leaders can weigh this directly against the gain to be had, e.g. increased revenue, to make an informed decision.

Policy exceptions should be granted sparingly and only when there is a clear need and when the risks have been carefully assessed and mitigated. When evaluating a policy exception, it is important to consider the following factors: Security objectives Risk appetite Compliance obligations Pros and cons of the exception Alternative solutions It is also important to consult with the relevant stakeholders to get their input on the exception. If the exception is approved, it is important to document the decision and the reasons for the decision. It is also important to implement any necessary compensating controls to mitigate the risks associated with the exception. In summary, policy exceptions should be treated with caution.

Having a strong process for ownership and traceability of risk is key to manage the various risk level An owner is supposed to review the risk, evaluate if something has changed in the risk position and propose action or mitigations

An exception should only be granted on a temporary basis, with a mitigation plan and temporary compensating controls. If the exception is 'permanent'/long duration, instead change the policy, to avoid recurring admin.

A single cross-functional business or mission owner should make the decision about whether to accept marginal risk above a certain point through a policy exception. That is because these people are the ones who have the best understanding of all of the risks facing the organization, whether they be competitive, technological, regulatory, or cybersecurity. Security, privacy, and legal teams should not approve or deny policy exceptions. They should only provide an analysis of the potential outcomes of making such an exception. Otherwise, they will be put in an odd position of needing to analyze risks outside their areas of expertise, e.g. a lawyer evaluating how much revenue is at stake or a CISO evaluating contractual risk.

Perspective: Policy exceptions should be approved with a view to the long-term security of the organization. The decision-maker should carefully consider the impact of the exception on the organization's security posture, risk level, and compliance status. The decision-maker should also ensure that the exception is properly monitored and reviewed to ensure that it is still necessary and that the risks are being managed effectively.

Just because the exception may appear reasonable, make sure to consider downstream effects on others that are dependent on the service or team that requested the exception. When the impact of the exception impacts others, they should be included in the discussion.

Exceptions tracking is critical in vulnerability management to ensure that there is a documented reason why an exception was made. Exceptions also should be revisited often to ensure that appropriate mitigations and controls are in place. Also consider re-evaluating if risk has changed over time and if an exception might no longer be appropriate.

One thing to keep in mind is that exceptions are really vulnerabilities. You’re knowing accepting a gap or weakness that could be exploited. So tracking them your other vulnerabilities and findings is essential. You must know what assets this exception impacts, what threats could be exploited because of it, and how much the exception increases your risk posture. Ensuring those relationships exist and are visibly is essential for proper risk management.

Once the policy exception has been approved, it is important to implement it carefully and monitor it regularly. Communicating the exception to affected parties Providing guidance, training, and support Monitoring the exception for performance, compliance, and risk Reporting any issues, incidents, or changes to the decision-maker and stakeholders Reviewing the exception periodically to evaluate its validity, relevance, and impact. It is important to manage policy exceptions carefully to ensure that they do not compromise the organization's security posture. This means monitoring the exceptions regularly to ensure that they are still necessary and that the risks are being managed effectively.

Managing exception is key to application and infrastructure security. A well defined process enables - acceptance with deferral to later time - exception of false positives - exception with compensating controls While a vulnerability might not be applicable at a point in time an exception should be periodically assessed

If you find yourself dealing with an array of exception requests, it might make sense to review your policy and the risk appetite which it establishes. Constant requests for exceptions to policy may indicate: 1) The resources dedicated to security are insufficient to comply. For example, if you constantly need exceptions for outstanding vulnerabilities, you may not have sufficient engineers - or the right tooling - to meet policy requirements. 2) The policy establishes an implied risk appetite that is too low for the business to operate. A single business leader should own the policy and set the risk appetite to avoid this situation, which will directly lead to situation #1 as a result.

A CISO has a goal is to protect the organization's data and systems from cyberattacks, and that means ensuring that our security policies are effective and that any exceptions are properly managed. When evaluating a policy exception request, I consider the following factors: The rationale for the exception The benefits of the exception The risks of the exception and how they will be mitigated The duration of the exception The conditions under which the exception will end How the exception will be monitored, reported, and reviewed I also consult with other stakeholders, such as the security team, the compliance team, and the business unit, to get their input on the exception.

Although calling these things "exceptions" is common practice, I prefer calling them "risk acceptances." That is because: 1) You don't want to have to do gymnastics when explaining that you are in compliance with your policies, minus a bunch of exceptions. 2) It makes clear exactly what you are doing...accepting marginal risk above your pre-existing appetite. 3) Allows you to consider risk acceptances across multiple functional areas and policies in a cumulative manner. What really matters it the total magnitude of risk you are accepting as an organization. Adding together all of your risk acceptances holistically and tracking the net amount is more revealing than tracking exceptions to individual policies.