Cybersecurity policies that reduce risk

Why your current cybersecurity policies are probably ineffective

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

🔒 Related Stories: Cybersecurity for Executives | Penetration Testing

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The next question in my series on Cybersecurity for Executives is: “Do we have policies in place that limit mistakes that can lead to increased security risk and potentially a data breach?” Follow this with, “How are they enforced?” Prepare yourself. I’m going to tell you some stories to show that your existing security policies are not working. By the end of this book, I hope to provide strategies that help you fix that problem.

What are your cybersecurity policies?

Most large companies have formal, written, cybersecurity policies, standards, and processes. Someone, somewhere, writes down all the things people at the company must do to maintain system security and prevent data breaches.

Sometimes these policies are sent to employees to read and sign. In some large organizations, I have had to watch training videos and answer questions. I’m about to tell you why all that is mostly ineffective. I’ll also tell you how to fix it partially here, but in further detail in an upcoming post.

Typically an organization has different types of documents which may include the following as defined by NIST:

Policies: What people should do or not do.

Processes: How people must carry out the policies, step by step to achieve the objective.

Standards: The specific technology and configurations used to deploy systems, such a specific configuration of a particular operating system.

Hopefully, these documents follow security best practices like those documented by in the NIST (National Institute for Standards and Technology) Cybersecurity Framework or the Center for Internet Security or your favored and trusted organization and references. You could use some of the recommendations in this book to help you formulate a policy. All these recommendations and best practices are great — if you can get people to follow them.

Keep the policies up to date

After creating policies, standards, and procedures, they need to be updated when standards, technologies, and best practices change. I helped with one audit, where I found encryption algorithm standards were out of date. The vendors the company was using and approved didn’t even offer the out of date algorithm options. I’m sure it was an oversight as the team was very competent. Make sure that if you have policies and related documents that you provide time to review and update them periodically.

Policy updates include the changes required to operate in cloud environments. One company I worked with enforced specific open source license policies. Then the company moved into the cloud, and all the developers started using the software tools offered by the cloud provider. When I tried to get one of these tools into our software component repository, it got rejected by the legal team. I responded to them that this might be the policy, but thousands of developers throughout the organization were already using the tool and asked what they would like to do about it. As you can imagine, the policy was updated to match reality.

Communicating the policies to those who must comply

Once you have policies and procedures, these need to be communicated to the people who are supposed to abide by them and carry them out. The security team might be passionate about security and sure that their policies are very important because that is the reason their job exists. Now consider the person who works in Human Resources and is trying to get payroll out the door to avoid lawsuits and government fines. How about the developers with a product manager breathing down their neck asking, “Is it done yet?” every few hours. These people are focused on other priorities. It’s not that they don’t care about security, it’s just that reading your eloquently crafted security policy document and memorizing every word of it is not high on their agenda.

The other thing is, even if they do read it, is it relevant and meaningful to that person? Do they know why it matters? Can they understand the technical jargon? And will they remember it 24 hours after they signed it? In most cases, probably not.

Here are are some examples of security policies that were not particularly effective:

Do the employees in your company know what policies and procedures exist? I remember my teammate and I meeting with someone at a particular company. A meeting appeared on our calendar to meet this person, and we didn’t know why. It was some new process, or so we thought.

I had been a development lead at the company for a couple of years and finagled my way into architecting systems without being on the architecture team. The architecture team pontificated a lot but didn’t build things. I don’t think the architects liked this either. I wanted to implement things that solved business problems.

Perhaps they gave me the boring projects initially because I was a woman, and then didn’t pay attention to me as a result. I didn’t mind. The projects dealt with massive data sets and interesting nerdy problems from my point of view — taxes for billions of dollars of assets under management and things like that. Eventually, my team went on to implement archiving customer service data into SalesForce, sweep accounts, cost basis, online account transfers, and dividend processing, among other things.

As our team proved to be successful, we got more challenging projects, and it seemed that more and more roadblocks appeared — until the point I couldn’t take it anymore and left — but that is another story. Somewhere along the way before that point, this meeting appeared on our calendar. We went to the meeting. The person who scheduled it seemed very annoyed with us and told us that every project at the company goes through him before any system deployment. OK…the person and I who went to the meeting didn’t even know who he was. It turns out, he was a nice guy, but clearly, no one ever communicated this policy to the people they intended to be following it, nor was it being enforced (not to mention it was not a great policy!)

When I moved to another part of the company, I was working on a new, critical initiative for the company. I was concerned about security and asked if I could see that the policies were related to a particular technology implementation. The security professional said that I couldn’t see those policies because they were confidential. So, how was I supposed to follow a policy I couldn’t read?

In another case, when I asked for the security policies for a particular issue, the person who was responsible for a particular aspect of security as part of the overall security team sent me a link to a folder. When I looked in the folder, it contained about 50 documents. Yeah. Thanks. I’ll get right on reading every last one of those documents.

In other cases, people know that they don’t have to follow the rules because no one enforces the policies. I worked with someone who stated in a meeting that it didn’t matter if we implemented insecure networking rules because no one was going to check. He said it didn’t matter because no one was paying attention. He got promoted that same year.

I witnessed a director state in a training session that security told him not to do something be we were going to do it despite these directives — in front of about 100 developers. This blatant disregard for security was running rampant in the organization. This could be due to the fact that policies were previously so stringent the organization was stagnated and couldn’t move projects forward. The pendulum swung too far the other direction and the organization later paid a price for this disregard of basic security principles.

I caught a person on the security team bypassing a network compliance tool that would roll back an unauthorized change in three minutes. He figured he could add the unauthorized rule, do what he needed to do, and get out before the rollback. “It’s a stupid tool anyway,” he said. “Anyone could get around it,” he said. I mentioned this to someone else on the security team. Nothing happened. My feeling on this matter was that the person was not adequately trained on proper network security in the first place. He initially had free reign to build the networking, but he implemented it with Internet access directly to the hardware security modules (HSMs) that stored encryption keys for the company. I already explained in a previous post the risk associated with direct Internet access to sensitive data and secrets.

These are all examples that hopefully illustrate the problems with mandated but ineffective security policies. The organization needs to communicate the policies in a way that is relevant to each person’s job and point of view. People need to understand why the policies exist, so they see the value and how the policy prevents a breach. They need to be reasonably easy to follow and allow people to do their jobs. I’ll talk more about that in my post on automation. Finally, people need to know the repercussions of not following the policies — and the organization needs to enforce the policies from the top.

Who writes and enforces these policy documents?

I’m guessing most executives at the highest level think writing and enforcing security policies is someone else’s job, they are doing it, and if something goes wrong, it is that person’s fault. Typically everyone thinks that is the CISO’s (Chief Information Security Officer) job if you have one. When the breach occurs, naturally, everyone blames the CISO because he or she is responsible for security. In many of the massive breaches, the CISO loses his or her job or at least gets demoted.

You may have noticed CISOs don’t stay in their jobs for more than two years at many companies. First, they come in, and anything that goes wrong gets blamed on the prior CISO. Then, they leave before the next breach hits that could be pinned on them — when they are in an impossible situation. Often, they are responsible for security but can’t fix it. Security staff may want strict security policies, but then business executives force them to loosen them to enable companies to meet business objectives.

In reality, executives at every level who make poor security decisions due to lack of training or other priorities are responsible for breaches. Product managers who forgo security to get a product out the door and project managers who push developers to take security shortcuts to get things done are responsible. Managers who don’t send developers to security training are responsible. Top executives who want a “yes” person in the CISO role instead of someone who stands up to them and pushes for secure solutions are responsible. If the CISOs say yes when they know they should not, then they are responsible for the breach. Many CISOs are doing their best to balance security with keeping their jobs by not saying “No” too often.

Often the CISO cannot fix the issue because they lack authority. How can we shift the blame in the next breach to the responsible party? First of all, the company needs a security policy that works and that it can enforce. The CISO needs to get support from the top executives to enforce the policy. The tools need to be in place to gather the appropriate metrics to determine if employees are following the policy or not. When someone does not follow the policy, the organization needs to take appropriate actions to make it clear that knowingly and blatantly disregarding the policy has consequences. If you can’t do that, forget the policy. It’s useless.

Here is an example. A company had a policy to disallow the use of a particular service for corporate data. Let’s say it was a cloud document sharing service called OutBox. The security team had a tool that could tell every time someone went to OutBox on the network. They could technically block access to OutBox using the corporate firewall.

The problem was that the company allowed the use of OutBox for personal use on the corporate network. Some of the top executives in the company used it for personal files and got annoyed when it was blocked. The corporate firewall can’t tell whether the files sent to OutBox are business or personal data. Of course, the security team can get into those streams and see what the data is, but that takes a great deal of time, and the security team doesn’t want to be accessing all that sensitive data and looking at personal information — especially that of top executives.

The intriguing thing was that this company had a network for personal devices. They could have let people use personal laptops, cell phones, or tablets to connect to the personal network and use OutBox. However, no one in the company even knew the personal network existed, and the company wanted to be kind to employees.

This example demonstrates an unenforceable policy. If you have an unenforceable policy, get rid of it. The top executives should sign off on it and accept the risk. If you have a policy but don’t enforce it, this could increase the risk for the company. One person I know had to explain to law enforcement when they showed up why the organization wasn’t following and enforcing a policy he wrote. He said he learned the importance of policies that day!

When a CISO lacks authority to create an effective policy, he or she needs to document recommendations and have the other top executives agree to accept the risk in writing. This approach is a well-known strategy in cybersecurity and something Ira Winkler talked about in the video I included in a prior blog post. When the CEO overrides the recommendation of the CISO, that is acceptance of risk, which then becomes the responsibility of the CEO.

The CEO may think the blame can always be passed off to the CISO, but as I mentioned in my very first post in this online book, many CEOs end up testifying to congress after a breach. Some of them lose their jobs. How can the CEO avoid this and shift responsibility in the case of a breach? Enforceable policies and metrics that help pinpoint security gaps and policy rule breakers so they can be dealt with appropriately can help. By showing who is blatantly disregarding the security policy after being provided explicit and easy to follow instructions, executives can not only shift the blame but hopefully improve training and stop the breach from occurring in the first place.

Tracking policy enforcement

The next part is the hard part. The organization needs a means of tracking who is and is not following the policy. Tracking risk is an area that I feel is lacking in every organization I ever worked at or helped with security consulting when I had visibility into how they track or don’t track decisions that increase security risk.

One of the reasons for this is that I have not seen many tools that help with this problem. Those that exist only help with subsets of the entire problem, or involves a lot of customization and manual effort. The other reason is that this type of tracking costs time, and money to implement and maintain. Security teams don’t usually have the resources or authority to track metrics to a meaningful level of detail. An organization is continuously weighing risk, and potential losses again cost of implementation. Often they choose to invest in other priorities. Risk calculations are always somewhat subjective, so it’s hard to implement something accurate. Processes that implement tracking may also slow down progress and get bypassed during critical projects or incidents. The other issue is that it is hard to get visibility into all aspects of security throughout an organization.

Although it is not easy, companies can start with basic things like the questions in this book to track the issues most likely to lead to a data breach. Get a macro view of risk at a high level with broad questions that cover the most common causes of security incidents. You can start with a spreadsheet. Over time the organization can build or buy tools that help automate tracking risk.

Stolen credentials via malware, misconfigurations, or phishing are one of your most significant risks, as noted in previous posts. One company I know measures how many applications within the organization implement multi-factor authentication (MFA) and SSO (Single Sign-On) as a key performance indicator (KPI). If your policy requires that every application has MFA and SSO, then track your applications and which do or do not implement it. Try to quantify the risk and potential losses that could ensue from a breach of credentials lacking these critical security controls based on the number of records and sensitivity of the data.

It’s hard to track all the applications manually across and organization, so you may want to implement a system that helps you with this. Track which applications are most risky based on whether or not they comply with security policies. A Cloud Access Security Broker (CASB) can help you find cloud applications in use within your organization and some will associate risk scores with the services they discover, but be prepared to hire additional people to configure and manage it. Implement systems that automate and streamline tracking applications in use and requests to use or deploy new applications. Add monitoring to deployment systems to track new systems coming online. I’ll talk about more automation strategies that help with this in an upcoming post.

Distributed responsibility

Some organizations assign the responsibility of tracking whether or not applications meet security policy requirements to a business unit. The responsibility may roll up to a higher level officer who makes sure each business unit is performing its duties. The individuals responsible for data at the business unit level are sometimes called data stewards. Auditors can validate that each business unit is following the defined security policies and that policies follow best security practices.

When using this distributed approach to track the implementation of security policies, executives need to receive the appropriate security training. Executives may not know what security policies exist or what they mean. Generally, some collaboration must exist between the security or IT department and the business unit to ensure teams implement policies correctly. A business unit may believe the policies are correctly implemented when they are not.

Organizations need to clearly define who is responsible for creating and enforcing policies and accepting configurations that deviate from policies and best practices. The people responsible for enforcing and tracking adherence to policies and making decisions at any level need proper security training, especially if you are distributing this responsibility. Documentation and a video once a year is not the most effective means of enforcing policies as I explained through several examples.

Organizations should also find ways to track which systems and employees that are out of compliance with security policies. Tracking exceptions is the topic of my next post. I realize I did not give you a way to solve these problems in this post completely. The right kind of security training so people understand not only what to do, but why, can make a big difference, in my experience. As hinted at here and explained in more detail later, automation is also the key to solving some of these problems and improving the ability to track risk throughout an organization. I hope you keep reading!

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 Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow 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