Cybersecurity Simulation for the Enterprise: Taking Threat Assessment Into Your Own Hands
Chuck McAuley learned from his father to tackle problems with lateral, non-linear thinking, seeing things from every direction to find unconventional, and often the most straightforward, solutions. Chuck brings that philosophy to his work at the Keysight cybersecurity center of excellence, working on ways to provide a more secure environment for 5G/6G and enterprise networks. He is dedicated to unearthing potential avenues of attack before they can disrupt these networks and our daily lives that depend on them to be available and secure.
Chuck’s journey as an inventor is the latest story in our Refusing Limits series, where we dive deeper into the unique approach each Keysight inventor brings to solving problems. The series also explores how these inventors are refusing limits to help Keysight and its customers push the boundaries of technology.
Cybersecurity seems to be this vast, yet abstruse market now. Is it difficult to innovate in this space?
Honestly? No. There are so many problems in search of a solution, the real difficulty is assigning priority to the problems that exist that would yield the most benefit for the most people. There are a million inventions that already solve some small piece of the cyber puzzle, but there are still a million more needed to make the world a safer place.
My interest was piqued when I was asked to help invent a solution to better track the certificates of calibration of Keysight equipment. Keysight makes a lot of equipment that require yearly calibration to validate that the measurements the equipment makes are still within spec. Traditionally, this calibration certification occurs with a tech taking measurements and then printing out a sheet of paper that states the equipment is good for “X” amount of time until needing further calibration. The mechanisms used to perform that calibration also need to be calibrated occasionally. There's a big long chain of calibration that ends up at some very expensive equipment that provides the gold standard of calibration somewhere at the top of the food chain, so to speak.
This traditional calibration model works well, but we wondered whether there could be ways to improve it with modern techniques. A colleague in R&D, Ian Reading, approached me as we had worked on some ideas while researching blockchains, and he was curious if there was an application of that technology or something similar to help with calibration management. My input on the idea, that eventually led to a Keysight patent, was that we should adopt a common principle used to validate identity and data integrity in the digital world: certificate chains of trust. Commonly used by web browsers to validate the identity and establish secure communications with web servers, certificate and certificate structure, can be used for a variety of purposes. They have a hierarchical nature, provide means of mutual authentication, and don't get lost in a drawer. Using certificate chains would provide a means of expiration, validation, and an easy way to problem solve any calibration problems.
This is sort of how I see the application of most cybersecurity techniques. Whether you are on the offensive or defensive side of cyber, you see a lot of tool and technique reuse. Take for instance the offensive side of cybersecurity, also known as red teaming. Hackers are people, not applications, right? They may be targeting new network technologies for vulnerabilities, but the tactics and techniques they use end up very similar to what’s worked in the past. That future network is going to be attacked the same way as the old networks were, yet many in the cybersecurity business look to invent new solutions when most of the time we can adapt existing measures for new, complex networks and systems.
I’ve noticed that while we are talking about high-tech innovation, we don’t seem to be talking much about technology.
Good point. While a lot of inventions are focused on getting more performance out of a technology or extending its use, cybersecurity is often focused on filling the gaps where we don’t know what we don’t know. As people work to secure complex networks and systems, they have to make many assumptions about adversaries and rely on their own experience. Oftentimes, this leads engineers to think more about what they perceive as important to guard rather than what an outsider might view as a valuable target. A good hacker or problem finder, isn't going to try to defeat your specification, they will look for the easiest way in.
This leads engineers to think more about what they perceive as important to guard rather than what an outsider might view as a valuable target.
I'm currently exploring the threat landscape of mobile networks. For example, 5G service providers have to start thinking about how they plan to secure the computing environment which hosts their applications, whether it is on some dedicated server or they run in the Cloud as-a-service. There is the risk of making too broad of an assumption on what is safe and isn't safe, and what needs additional protection and doesn't. The trouble is that there might be too narrow a scope that leaves very little room to think about possible "what if" scenarios. For instance, "what if someone makes it into the 5G core? What damage can they do then?" When the answer to a question like that is commonly, "but they won't make it there" or "it's protected on the perimeter," then you know it hasn't been adequately threat modeled or explored. Your threat model needs to account for scenarios that challenge the existing status quo of thinking and explores uncomfortable possibilities.
That presents a large field for exploration—systematically finding all those vulnerabilities, myopic design decisions, and programming failures.
We don’t know what we don’t know. That seems like something that’s hard to capture on a spreadsheet.
Funny that you say that because I've got a 5G spreadsheet open in front of me right now with dozens of different proprietary network interfaces…and I’m picturing the network stack for each of these and how they are defined, and how someone might maliciously go about finding them on the Internet, and how they might go about disrupting one. Then I put on my mobile operator hat and think about what I, as that operator, would be worried about and what I would forget about being worried about. And then I put my hacking hat back on and start digging into the things the mobile operator isn't thinking about.
Forget to be worried about?
Yeah, our knowledge bank has to be cumulative. Networking protocols like Ethernet have been around for a while, and although we’re not investing in new versions of Ethernet that need to be tested, these technologies are still widely in use and need to be on our vulnerability radar.
Maybe we should step back a bit. Security tends to be viewed as a cost center by most organizations, right? It’s going to slow down an organization and it risks them being first to market. So, then we layer on this whole other discipline of risk modeling and cyber insurance to give us comfort if we don’t get it 100% covered. Assumptions we make in the planning phase get baked in and rarely revisited. And there’s just the human element that we have to recognize for what it is: if an engineer is staring at a code review and it’s five o’clock on a Friday afternoon, they might be tempted to let something slide if it’s deemed "not a big deal."
Assumptions we make in the planning phase get baked in and rarely revisited.
Hackers know this. They are doing a more thorough QA, quality assurance, of your own product. Looking for those mistakes. I do this—that's my day-to-day job. And we bring that into the products we offer within the Keysight umbrella.
People make mistakes. That’s a fact of life, well, maybe until machines take over writing protocols. How do those mistakes reveal themselves?
Most mistakes are made because people don't know the right questions to ask during the design phase. You can't protect against what you don't know is a threat. That's why it's so important to have domain knowledge of what are common attack patterns and how to protect against them. It doesn't matter if you are a hardware engineer or write Python scripts for provisioning servers, every electrical device has its own threat landscape, and you as a designer of that product need to understand the correct threat model you need to apply to keep your product from being hacked. And when you do end up making a mistake, have a plan in place to manage expectations and provide a timely fix.
It's so important to have domain knowledge of what are common attack patterns and how to protect against them.
Most new technology can be a bit fragile, and yes, that’s a bit terrifying. When we were researching LTE early on, we were able to crash the packet core elements in something like five minutes. So, we learn from those tests and apply them to 5G and 6G, especially as we open up these access networks to anyone who wants to jump in the game with some off-the-shelf hardware and an open-source software package.
You need to be aware that you can't know everything. And you need a plan to handle those events when they happen. You also want to close as many gaps as possible in your organization, which means you need to test your defenses continuously.
What’s next? Where are the biggest opportunities now to innovate in this field?
Endpoint security testing. One of the biggest strides we have made recently has been with our Keysight Threat Simulator. Cyber testing tools, which allow you to “attack yourself,” were mostly in the hands of service providers and device manufacturers. That left enterprises to either go with expensive consultants to perform what's known as a "penetration test" that would find weak spots in their defenses or simply to trust that everything was set up correctly. With Threat Simulator, we are able now to bridge that gap between the lab and the real world, enabling a much larger customer base to stress and test their security defenses in real time in their real deployments.
We will continue to innovate our research tools—from firewalls to email security systems, IoT devices, and endpoint security— so that our customers can narrow the gap between known knowns and known unknowns, keeping themselves safer and able to focus more on the next big problem.