Tales from Trenches: Cybersecurity Tool Depth and Features

“Don’t forget the hole in your pot handle.”

There are things I use every day that have features that I never thought about until I undergo an epiphany I call, “Why is that there?” For example, I like to cook, and one day I wondered why there was a hole in the handle of every single one of my pots. Was it for hanging them? It seemed strange that all manufacturers would add this “feature” so that they could also be hung up as decorations in a kitchen. There had to be another reason. After a quick online search, I discovered the hole was an ingenious way to keep my counters clean while I cook. It turns out that I can put the handle of my spoon there so that the spoon drips into the pot. It’s a built-in spoon rest.

I had another epiphany in my car: I noticed the tiny arrow on my gas gauge. I learned that this feature tells me what side of the car the tank access door is on. After searching more about this, I also learned that some manufacturers put the gas cap on the passenger side for safety so that if I run out of gas, I don’t have to stand on the side of the road closest to cars whizzing by. Things like this have been around for my entire life but, like most people, I missed them because I was simply too busy to notice or just didn’t care – until one day when “Why?” hit me.

Just like these everyday things, in my rush to get basic security appliances or services implemented, I may miss something – perhaps a feature that can make all the difference. In this post, I’ll provide a few real-life security scenarios where my solution was already in my hands – I just needed to really see it. 

Harmony: Secure Access and End-user Convenience

In a former role, I was evaluating the risk of end-user remote access. I knew the organization was not performing any host checks on the VPN concentrator. I took a deeper look at this risk and decided, after performing a risk assessment mixed with some threat modeling, that I needed to develop a solution to reduce risk and yet allow end-users to keep some of the convenience they were used to. The risk assessment uncovered that the use of personally owned devices over VPN was rampant and thus a “bad actor” could move laterally into the corporate network via the VPN if endpoints were compromised. It is important to note that when a device connects via VPN to the corporate network, it’s as though the device is physically sitting on it and the home network (or airport/hotel network) could introduce risk to the corporate network. My assessment results put this risk well over our established risk tolerance. I knew I needed to find a way to mitigate the risk and strike a balance between security and usability. There were legitimate reasons for employees wanting to use personally-owned devices to the network. Retrieving email from personal tablets and phones and accessing files, came to mind. Adding to this is the fact that we had not had a system refresh in a while, so many of our systems were outdated, slow and causing productivity issues. My immediate thought was to reject non-company assets, but, with productivity issues and the mobility benefits of tablets, I knew this might start a mutiny. I also knew I could not enforce the configuration of personally owned devices.

Now that I understood the challenge and requirements better, I could research a solution. I researched and found that the VPN concentrators had the ability to perform a host check and potentially quarantine endpoints if the policy requirements were not met once the end user was authenticated. I realize VPN remote access is so 2010 and BYOD has been figured out. However, my simple example illustrates the power of asking “Why is that there?”. All the connectivity went through a single appliance, so my curiosity and reasoning asked the question, “Wouldn’t be cool if I could make some decisions about endpoint connectivity at that the point of connection?” So, examining capabilities/features I already had, and possible use cases/impacts helped me develop a solution for more secure endpoint remote access. I launched a communication campaign, tested the policy and built “what-if” scenarios for rejections on connectivity, so I could inform end-users what to do if they couldn’t get connected. This also helped me build some “street cred” by leaving flexibility for end-users and giving them the ability to make choices about their own tools for work. My next goal was mobile device management and keeping enterprise data and personal data separate.

Just for Fun: The Firewall Features Example 

While working in a consulting capacity, I was helping a banking client with her security concerns. The CISO was replacing the current firewall with our company’s managed service and newly provisioned internet service. The reduction in firewall management requirements was saving her time and money and she was increasing her internet bandwidth as well as saving money. Just before implementation, she was asking questions about the features and capabilities of our device. We realized that the firewall I had provided was not as feature rich as the one we were replacing. The main concern was that her SMTP gateway functionality was going away. Because I had done my research and knew her network and controls, I reminded her that her enterprise anti-virus product not only provided endpoint security, but that it also included an SMTP gateway. This would improve her security posture by providing malware checks and SPAM control for inbound emails. Prior to my mentioning them, these additional features were not known to her and her team but solved the issue. It is important for security professionals to understand third-party relationships and what is being bought as well as what services are included or not included. I tucked that example away as a lesson that I needed to manage my third-party relationships, capabilities, SLAs and offerings the same way I did when I bought technology to solve a problem.

Caveats: Reactive vs. Proactive

Keep in mind that these examples are reactive approaches to solving issues. A better and more proactive approach would be to apply security architecture principals, such as Sherwood Applied Business Security Architecture (SABSA), to better align business strategies to security objectives while understanding security investments and capabilities. In my first example, understanding my employer’s stance on BYOD and the needs of the business for flexibility would have better prepared me for risky scenarios like the one I encountered. 

In Figure 1 below, I illustrate all the drivers and inputs to my security architecture and program to help drive my decisions on priority and whether the security architecture enabled the business. 

Figure 1 – Important Considerations to Security Program Alignment

Figure 2 below, I illustrate an early pass at business alignment and how the way business was being conducted and daily operations were creating challenges from a risk perspective – so they could be better understood and addressed. 

Figure 2 - Example of Specific Business Alignment to Risk-Based Approach

Inventory. Examine. Apply. Measure.

By simply being more observant and aware of what I had and all the capabilities my security tools included I discovered solutions that didn’t cost me (or my clients) more money or manpower.

Figure 3 – Sample Security Services and Capabilities

As shown above in Figure 3, this is a simple list of security capabilities aligned to a framework. Once this was created, I noted the status, and impact to my organization, this helped me begin to get creative on ways to measure the effectiveness of the controls and create measurements as shown below in Figure 4. 

Figure 4 – Sample Security Capability Coverage Measurement 

Now, if I could only find a way to get the holes in my pot handles to also cook dinner and clean my kitchen!