Security exceptions are the norm
Do you know who is causing the most exceptions — and why?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Related Stories: Cybersecurity for Executives
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My last post in my series on Cybersecurity for Executives was about security policies. The next logical question pertains to exceptions. How many exceptions has the organization granted to your security policies? How much do they increase the chance an organization suffers a data breach?
Ideally, a security team writes a perfect policy, and everyone follows it precisely because it is the right thing to do. Anyone working on or with a security team in a large organization knows this does not happen! Exceptions happen.
Rather than defining a policy and expecting everyone to follow it in all circumstances, plan for exceptions in advance. How will people request policy exceptions? Will approval be automatically granted, and the exception simply tracked? Will exceptions need to go through a formal evaluation and review? Will you have automatic exceptions for specific scenarios? Will exceptions last indefinitely or have a time limit? What if the reasons for which the organization granted the exception change?
Why do we have exceptions?
I would venture a guess that most exceptions happen as a result of a business initiative that is blocked by security, resulting in a business executive complaining up the chain top executives how much business the company loses if they cannot get an exception. The security team, on the other hand, talks about potential security breaches, the number of records and types of data that stolen, and how the attackers may do it. The executive makes arguments in business terms, while the security team makes arguments in technical terms. The business wins.
Another type of exception I’ve witnessed involved product managers who did not want to follow best practices they felt would take too long and delay getting a product to market. Although I’ve heard business executives say they want security and security is a priority, this does not seem to be the case in reality when you dig deeper into business decisions made at all levels throughout the organization. The security speech was just talk, whether the business executive meant it to be or not. The rhetoric coming from leadership was similar at the same time the security policy violations were occurring that I recounted in my last post.
Often at the same time executives are giving the organization speeches about security, conflicting priorities are handed down with seemingly equal weight. People have to make choices. Completed features and more money are easy to see and measure. Security is more esoteric and typically not well measured or understood. The debates that lead to exceptions and disputed decisions are often not tracked. When a breach occurs as a result of an exception, it may be hard to determine the decisions the led to the security incident, who made them, and why.
Another type of exception occurs when a parent company forces a change on a business unit that has conflicting security policies. Executives higher up the chain override the policies at the business unit that may be enforcing a more secure policy. The business unit may have little room to object, and the parent company may not consider it an exception.
Yet another common source of exceptions occurs when one company buys another. Companies may not perform adequate due diligence on the security controls at the company they are purchasing. Sometimes executives accept the risk associated with security problems to get the deal done. In other cases, the acquired company is allowed to operate independently and outside the standard corporate security policies.
Integrating systems and processes after the acquisition of another company are always challenging. Having been through multiple acquisitions, I have witnessed this first hand. I’ve also performed due diligence for venture capitalists and corporate mergers and acquisitions. I’ve witnessed exceptions to best practices in all these cases to move integration and business deals forward. There may be a good reason for initially accepting the risk, but a plan, with a deadline, should be created to fix it. Whatever the time estimate for that plan is likely needs to be doubled or tripled.
Sometimes those who want to make the purchase are overly optimistic when it comes to integration. Later, those same individuals push for cutting corners to meet stated deadlines. Security is usually the first to go, followed by a robust architecture that performs adequately. Integration needs proper testing, including security testing. Lack of doing so results in system downtime or security breaches that impact brands and revenue, based on personal experience and publicly available information.
The Marriott breach is an example of security flaws related to an acquisition. Marriott bought Starwood Hotels. Likely exceptions were made to existing security policies, or perhaps due diligence missed something during the review process. It is hard to tell exactly what happened based on public information. We do know that the initial breach occurred before the acquisition. It took years to discover the breach. The New York Times writes:
[…]
What about tracking exceptions created by vendors accessing company data? Are your vendors following your security policies? Vendors may have a completely different set of security policies and may thereby increase the risk to your business.
Evaluating the risk posed by an exception
Is it wrong to choose business over security when approving an exception? It makes sense that a business would forgo the extra effort to implement security if the security policy is creating excessive expenses and delays that negatively impact the business. If a business doesn’t make money, it may not be a business much longer.
A problem exists, however, when those who granted the exception did not properly evaluate the risks and costs associated with the decision to forgo best practices and security team recommendations. In some cases, the better decision for the business is to implement security, but the calculation of potential loss was not adequate or accurate. The proposed security control may not have been the most cost-effective solution to the problem. A more in-depth analysis may indicate the overall improvement of security processes and systems would be beneficial when evaluating security holistically throughout the company.
The first post in this series covered the cost of a data breach. When looking at a particular exception, have all the potential costs and losses been evaluated in that context? Is the cost of implementing proper security more or less that potential losses? Remember to consider the cost of stolen intellectual property, infiltrated executive communication, and lost business opportunities while dealing with the breach. Understand that insurance may or may not cover the losses. Consider the much more significant issues in that post related to national security and privacy. If companies do not proactively improve in these areas, governments may step in, and companies are going to face more costs and delays due to increased regulations and fines.
Cumulative Risk
Those responsible for reviewing exceptions often do so on an individual basis. The cumulative risk of many exceptions should be considered. Each exception increases the chance a company may face an attack or accidentally expose data. Each additional exception may increase the risk of a breach. Tracking exceptions throughout an organization helps determine whether the overall risk is going up or down. The increasing risk may indicate a systemic problem exists.
Tracking security policy compliance should include deviations from those policies in a quantifiable manner. Each of these exceptions should have an associated risk metric. If you have ever read a penetration test report, you may have noticed that the report lists the highest risk items first. Tracking risk associated with exceptions helps you determine where to focus remediation efforts. Quantifying risk is not a perfect science, even with the formulas that help you do so. However, some of the information I have provided throughout this cybersecurity book can help you better understand the threats and associated risks.
Calculate the potential losses from the risk. No matter how fancy the formula is, it is always subjective and dependent on your organization and the data you store. Hopefully, you have someone who can make an honest attempt to give you an idea of the potential business risk and loss associated with an exception.
I have been in meetings where someone attempted to get a group in agreement by quantifying a decision with numbers. As soon as I entered the room, I knew what was going on. The executive wanted to take a course of action even though I and others had called out security deficiencies with a particular choice. He created categories to evaluate the options, including security and other business factors. He put weights on each category. As he took each step to build his metrics, he looked around the room and said, “Right?”
I knew this was an exercise designed to obtain agreement on the desired outcome. By this point in my career, I knew better than to try to sway opinions in such a meeting. The meeting had a specific objective, and dissent would be futile and career-limiting, though I had probably already limited my career by going against the desired opinion in the first place and calling out the security flaws. I nodded with everyone else. “Right.” When he got to the end of his analysis, he said, “So we all agree this is the better choice, right?” Everyone in the room nodded. It was obviously the best choice because numbers don’t lie. Right?
Alternatively, I could have walked up to the board and slightly altered the weights on a few categories like security issues and flipped the result. I just wanted to get the meeting over with, so I could leave and do something that would be a better use of my time. If people are doing funny math with your risk analysis, it’s not useful.
That’s why I wrote the questions in this book. They are hopefully straightforward ways to quantify cybersecurity and reduce risk at a high level by eliminating some of the most common causes of data breaches. There are nuances and details associated with each question. Still, you can track the questions and eliminate the gaps you find without doing complicated risk metrics and arguing about risk scores, weights, and other subjective matters. I hope the questions are mostly simple enough to track in a way that eliminates obvious security risks such as administrative ports open to the entire Internet.
Tracking exceptions
Here is an example of an exception. Let’s say you have a rule that every website in your company must have a Web Application Firewall (WAF) and a Content Security Policy (CSP) with a particular configuration protecting it.
Further analysis may prove one system is less risky than others because it is hosting public, static content and has no forms where an attacker can input malicious characters or content. All the data on the site is publicly accessible, and none of the attacks the WAF or CSP protects against are applicable.
For example, a SQL injection attack does not apply because no relational database exists. The site does not have any type of authentication. It is updated manually. When you scan your site for vulnerabilities using tools like Burp Suite, it warns you if you do not have a CSP, CSRF tokens, HSTS, and XSS headers. A student in my class scanned the current iteration of my web site, and it got a grade of F because I don’t have all those headers on my site. This analysis is one of the things a pentester has to know when testing websites — what matters and what doesn’t. Some of those things protect against attacks that won’t do any good on the current iteration of my four-page static website. If there’s an attack against authentication that leverages cookies for session management and the site uses a different form of authentication, all those cookie attacks don’t really matter.
In this example scenario, let’s say the company wants to avoid the time and cost of implementing these things because they do not provide additional benefits. They decide to grant an exception for this website, so the developers do not have to implement a CSP or WAF protections.
Track all such decisions for exceptions in your security compliance tracking system that I outlined in my last post. It could be a homegrown system, an Excel spreadsheet, or an off-the-shelf program. You may also incorporate automated tracking into your deployment systems, as I’ll explain further in a future post. Include information like the following, and whatever else you may need to remember later. For example, you might need to recall why the exception is in place, whom to contact about questions if a vulnerability related to the exception is exploited, who is responsible for reviewing and updating related information, and when.
What is the policy related to this exception?Why was the exception granted?Who requested the exception.Who approved the exception.Who is responsible for reporting system changes?Who is responsible for monitoring the exception?What is the associated risk (high, medium, low)?What are the potential financial losses?When was the exception granted?When does it expire?You may also evaluate other risk frameworks and tools for tracking risk and exceptions. If you want a more formal way to manage risk, consider using the NIST Risk Management Framework, or something similar. Some of these frameworks align with compliance requirements to help you determine if your systems are meeting compliance standards or not. However, the focus of this series of blog posts is on fixing things that commonly cause data breaches, not just help you obtain compliance. If you use formal methods traditionally tracked with manual documentation, try to find ways to automate the processes and manner in which you gather and report on risk metrics.
If you have defined secure base policies that prevent the top cause of security breaches, the risk associated with compliant systems is hopefully low. Then as you track cumulative exceptions, you can see if your overall risk level is going up or down within the company. You can also track who are the riskiest decision-makers and which systems, departments, or lines of business pose the most risk to your organization.
Who is creating the most exceptions?
When you track exceptions, track who is requesting and who is approving the most exceptions as this data gives you some insight to help improve the security and productivity within your organization.
First, in terms of security, you may have a culture or attitude in a particular part of the organization that disregards security. The people making the exception requests or approvals may not understand the risk. Organizations can solve this problem with security training that explains why specific actions are a risk, shows how the vulnerabilities can be attacked, and includes case studies, examples, and possibly hands-on labs. I have noticed that real-world stories help best illustrate security risks.
The other problem you may have when it comes to repeat offenders is an insider threat or person inside your company whose intent is to steal your data. Foreign governments and criminal organizations offer people money to steal secrets. The person may be using exceptions to create weaknesses to steal data from the company for personal use or at the behest of a third party. Alternatively, the person is a risk to your company either due to blatant disregard of security policies because they think they are a waste of time and unnecessary, or inability to follow them for any number of reasons.
Exceptions may have other causes that are not the fault of the individual requesting exceptions or generating security violations. A high number of exceptions could be the result of system or network architecture problems that get in the way of people doing their jobs, a misaligned security policy that doesn’t work for newer technologies, lack of communication, or a problem with a system or process.
At one company, I got a notice at some point that I had several security violations while using a particular system to make production changes. The root cause was that the company moved me into a role in a hurry to resolve other business issues and provided no training on how to the system. No one told me that exceeding the time limits set in that system would produce violations. Other people were setting the time limits, and I hadn’t even noticed them. Going forward, I was careful to make sure the time limits were appropriate and follow the rules.
Everyone disliked that system to a greater or lesser extent, by the way. It was cumbersome to use, and no one understood how to get requests into the system that someone would not reject without a coherent explanation. If you track things like violations of policy and rejected requests, you can find underlying problems that are hurting releases cycles and creating angst within your organization. By tracking exceptions, you can delve into the details to find problems that are preventing people from working efficiently and look for alternate solutions to improve productivity.
Change management is helpful, and the point when systems change is an excellent time to look for security exceptions. Still, an organization needs to align the process with workflows and technologies so people can follow it with a reasonable amount of effort. Hopefully, your change management system has a decent user interface that is intuitive, and communication on how to use it is clear. Alternatively, you can let people make changes who have the authority to do so, monitor changes, and block unwanted changes automatically. I explain that further later in this series of blog posts.
Expiration
It is a good idea to set a time limit on an exception, especially if it is a risky exception. Perhaps an urgent business need exists to migrate or integrate systems due to an acquisition. Set a deadline for resolving the issue that caused the exception.
Periodically review exceptions and perhaps warn people when exceptions are about to expire. Creating a risky exception for something temporary and then never following up to see if it got fixed may lead to an indefinite risk that slipped everyone’s mind. Items that organizations set aside to fix later are known to as Technical Debt. Often technical debt never gets paid, to stick with the analogy. Put a deadline on it to have a chance that upon revisiting the matter, someone fixes it. When an organization has many exceptions of a single type or category, it may have an opportunity to fix an underlying problem that resolves many exceptions at once.
System changes
Changes to systems and technology is another good reason to set an expiration on an exception. Let’s say that static web site got moved to a WordPress content management system so the pages could be updated more easily. The pages now contain dynamic content with data stored in a relational database. The developers added a few web forms. WordPress systems have an administration interface for updating content that has been subject to many CVEs over time. When developers implement this system change, the exception is no longer valid. The website implementation should then include a CSP and a WAF.
Who is responsible for revisiting the exception when someone is implementing this change? Will the system developers remember that this site has a security exception? What if a new team is implementing the WordPress site? By having a periodic review of exceptions, hopefully, you can find this issue before an attacker does.
Better yet, use a different architecture to protect the site. That’s something I explain to developers in my cloud security class because, at the time of this writing, WordPress and other content management systems are a source of the e-skimming breaches. I was recently at a presentation by the US Secret Service and FBI explaining how attackers break into the content management system (CMS) and insert malicious code into the web site to steal credit cards as people check out. Perhaps you have a policy for securely implementing CMS architectures. A periodic review of exceptions helps you find these types of changes where the risk associated with the exception has increased.
Exception Metrics
Organizations may want to track security in a more quantifiable way. The process for doing so is never perfect, and a crafty attacker finds their way around security at some point, no matter what. However, implementing some form of tracking basic security hygiene helps organizations eliminate fundamental security problems and make it harder for attackers to exploit systems. As organizations improve and mature, attacks require more skill and cost attackers more time and money. At this point, they may even choose to go after easier targets.
My background is not only security but also software engineering. I’ve worked in industries and on systems including financial, sales, telecommunications, publishing, healthcare, marketing, retail, oil and gas, manufacturing, security products, venture capital, and many others. I see many ways businesses can leverage automation and deployment systems to improve security and risk reporting. I’ve helped companies improve marketing metrics, reduce system errors, align technical and business processes for greater efficiency, and improve system performance. I did this using improved communication, training, automation, architectural and user interface changes, and analytics. Organizations can improve security too with additional metrics, education, security testing, and automation. Keep reading for more on those topics.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2019
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab