Technical Insights > Network Visibility + Security

From Chaos to Control – Test, Validation and Digital Transformation

2020-08-25  |  7 min read 

First, some numbers.

  1. 80% of unplanned downtime is caused by human error.
  2. Bugs found in development are 90-100 times cheaper to fix than those found in production.

Most unplanned downtime is due to human errorSince our founding in the HP garage in Palo Alto in 1939, we have had literally decades of experience as the source of truth for millions of engineers in the world of electronic test and measurement. One of the lessons we have learned is that while humans are really good at many things including creativity, outside the box thinking and the like, there are some things that they are not really good at. One of those things is perfect attention to detail in complex, dynamic environments.

For example, let’s say you are a firewall admin. A colleague is working on a project where it would be exceptionally useful to open a couple of ports, say 135/TCP and 445/TCP (maybe she is creating some AD trusts or something). You do so, with the understanding that these ports will be closed up as soon as possible. Everyone agrees and then multiple firedrills happen.

After the dust clears, other things come up. Soon everyone has forgotten all about the temporary but gruesome holes…

What if you had a way of finding things like this forgotten but temporary (LOL) tweak? What if you had a way of testing other firewall rules to ensure that they are actually working the way that you think they are? Even better yet, what if you had a tool that would not only look for problems like this but would also give you concrete, easy to follow instructions for addressing the inevitable issues and gaps discovered?

Actually, such a tools exists. It’s called Threat Simulator. We even have a Dummies Book about it – Breach and Attack Simulation for Dummies.

Fixing bugs - 90-100x cheaper in dev than prodShifting gears (not sure if we are downshifting and punching it or upshifting at redline) I come from a line of somewhat hard, oldschool yankees out of New Hampshire. One approach that was always hammered home was to measure twice and cut once. Materials were far more costly than labor. Even in environments where labor is where the money goes, this is still a winning move.

As part of our mission to help secure and connect the world, we are often called on to be the source of truth with regard to test and measurement and this goes double in the network world. One of the things we found there, particularly in hardware, is that bugs found in development are 90-100x cheaper to fix than those found in development.

As a network architect or secops person or someone in IT in some role, you may not view yourself as squashing bugs in mainline gear (ahem, “Hello support, I think I have discovered another feature…”), although you probably do have some handrolled apps or scripts doing useful work somewhere in your network.

That said, you can look at the 90-100x cost of bugs multiplier in a couple different ways. If you were a network equipment manufacturer, finding those bugs early on is an obvious win, especially if you catch them before the hardware is nailed down. Same for anyone else who makes and ships widgets.

If you are a normal enterprise, this can still apply but you need to squint a little bit. Instead of finding bugs in hardware, think instead of finding problems or gaps between your requirements and the ability of the network gear you are thinking about deploying, be it firewalls, switches or whatever, to perform in a live network. Sure, things may spec well on the data sheet, but data sheet specs may be generated in conditions that are significantly different from those on your network.

That is why it is better to test and validate performance before committing to a significant purchase. Better to spend a little time and money up front rather than roll out what shoud be a shiny new network only to have it crumble when you throw the switch. Once you are at that point, scaling out or rip and replace start to get real expensive not to mention politically awkward.

Anyway, here we are. You are facing all the challenges that digital transformation can throw at you, and maybe more with global pandemic, greater climate volatility, wild fires and other challenges all converging to make this year particularly fun. Undoubtedly some will be grappling with the budgetary/political layers of the OSI model while others face limited staffing. Regardless of the details, it’s rough out there.

Keysight’s own Daniel Munteanu has done a great job capturing some of the ways that a healthy dose of measure twice, cut once can contribute to a life of less pain and smoother sailing in Chaos to Control: Validating Distributed, Disaggregated Digital Transformation. We invite you to read this paper. We also invite you to learn more about our test portfolio including our protocol and load testing offerings and our network security lineup.

Thanks for reading.

Stay safe.