In previous blog posts, we touched on how important IT infrastructure is for our modern society and why IT security vendors need to deliver robustness. It would appear that notions of agility and robustness go against each other. After all, if something is way too speedy – say an aircraft – it may reach its breaking point velocity and things will go south?! Yes, it is a valid and important question. If done right, both robustness and agility can be inherent qualities of a product or a service, and both deliver value, in some senses completing each other.
For this blog, we discuss agility from the perspective of an IT security vendor and look at it from three aspects:
- Development – why we have agile product development methodology
- Delivery – how efficient our products and services are
- Cryptography – how to change or replace underlying cryptographic mechanisms
Life before agility (was slow and boring)
In the IT industry, the use of the word ‘agile’ came from a desire to describe something better than traditional methods of designing and delivering software. Back in the days, it was more probable to break deadlines, under-deliver or just plain miserably fail, than to deliver in time and according to the specifications. I know I use a wide brush here, but that is essentially how the IT software industry was operating.
As a young industry, the IT industry looked at other sectors and tried to adopt best practices in engineering. My favorite analogy – the bridge – comes in handy again. When we are about to build a bridge, we know the overall ‘user experience’ – get folks across the river – and we also want a bridge that will last say 100 years. So, we give it to smart engineers to design, considering the geological characteristics of the terrain, suitable materials, as well as budgeting and procurement aspects. Then the bridge can be built.
The first problem here is that even traditional industries suffered from occasional hick-ups in design, broken budgets, or delayed deliveries – so, no wonder that we in IT inherited all of this. The second and larger problem is frequent changes – of general requirements, intended use, admissible load, and so on. After all software is “soft” unlike a bridge, and one can simply rewrite some things, right? Wrong!
While software is more flexible than a bridge, there are limits of what and how we can change safely (intelligently). And these limits are often hit pretty darn quick. We cannot change a two-lane bridge into a six-lane bridge halfway into the construction, nor decide that the bridge needs to be moved 2 km further east and at 100 m different altitude. While we are at it, we also want to be able to land an airplane on that bridge. Sounds like clear exaggerations but not too far off if you would ask a modern-day software product manager.
To address these frequent and often incompatible changes, smart people have suggested improved methodologies that essentially allow us to build the bridge and continuously morph it to adopt to whatever new thing we would want to put on our bridge.
The agile process – if applied to building a bridge
The agile building process goes like this: Connect the end points of the bridge with anything available – like plywood with duct tape – even if we know it will not be usable long-term. Then we transport something over to the other side of our infant bridge – clearly not an entire train but perhaps something small, like a box of chocolate – to make sure we know it comes across. If we are happy, then we move to improve some components, say suspension, so it can carry across five boxes of chocolate, check if the folks on the other side are happy. Then to the next small improvement, say a second track and ask the folks on the other side to send a little something, say a fruit basket, back to us… You get the point – small, incremental improvements, all the time validating that the current bridge works well, and all time expending the scope of its usability. Eventually, we get the bridge, and since we have been checking if it worked well for every single iteration, we know that we are fine with the final product.
This would be the agile process for building a product. This process is remarkably well applicable to building any software – be it IT security, computer games or online services. We as a vendor apply these methodologies in our product development, hence being able to deliver faster and with the desired quality. This method “never stops”. Even after the initial delivery, we continue to build and re-build the bridge – coming with new improvements and features, using the same methodology. That is how our flagship product EJBCA, now version 7.8.1, full 20 years after the initial release, is arguably the best PKI out there. She is our pride and joy!
Need for speed – manage changes in a softwarized world
Let’s widen the perspective of our metaphor, from a single bridge to the entire ground transportation network. There are zillions of cars, trucks and trains, transporting gazillions or humans, products, food, what have you – that make the society work. Now imagine that all of these are using software, in some way or the other. This is actually not a big stretch of imagination – modern cars and trucks have dozens of computers built-in already and railway control centers are unimaginable without IT systems to support signaling and scheduling. Heck, even cows are tagged and monitored for their well-being and optimal milk production.
So, then imagine we must change something quickly, say that winter season arrives too early and everyone needs to switch to winter tires. In this softwarized world, how do we enable that all tires get changed over just one night? It is hard, but not impossible. In fact, it is probably unrealistic to go for everything in one shot, given that there are ‘legacy’ cars out there that need to drive to the workshops or perhaps stay the winter in the garage. Nevertheless, with the current technology advances it is possible to imagine that your car does it by itself, overnight, while you are asleep! The car gets informed that snow is coming in a few days, it ‘unparks’ itself, drives nicely to the workshop and gets the tires changed. When you wake up in the morning, the car waits for you and is ready to safely take you on that icy road.
In the IT industry, this is achieved through ‘integration points’, APIs, open protocols that are flexible enough to change gears and tires overnight (sometimes in milliseconds!). Furthermore, if you are a company you want to get a good sense for how many cars that need to change tires, how many have engines running close to life expectancy, and how many are running with depleted disk brakes with leaking oil, so that you can schedule maintenance, upgrades or replacements. Then you push all these changes and replacements and – voilà! – your fleet can continue operations in the most optimal way.
Too good to be true? Yes and no. The metaphor used here is, if you like, a naïve agility, and it works well on modern systems and to certain extent. If all you’ve got is a veteran car, you might be out of luck in snow. If you’ve got a modern car, but you need to change something major like a broken engine, it will take time.
Agility in the IT security environment
To switch to the real world for a moment here – we at PrimeKey by Keyfactor deliver products to help with situations such as:
- an expired certificate on a customer-facing service that negatively reflects on your revenues
- an upgrade to a critical security system must not disrupt some of your revenue-generating activities
- a new service from your DevOps team that must be secure and your team needs efficient and easy to understand methods to do so
- with the growing business you want to be sure your IT systems will cope with the growth instead of the dreaded “this service is not available at the moment, please try again later”
All these examples save time and prevent headaches. Or another way to look at it – if we as a vendor are agile enough to deliver efficacy and efficiency – we are then delivering value to our customers. Then, our customers can engage on the digitalization journey and make their businesses thrive in the 21st century. In a sense, Uber is just a company that fully embraced transformative nature of software; and they did it as agile as anyone can dream of.
True crypto agility is anything but trivial
Crypto agility sometimes feels as a voodoo magic mix of wishful theories and insufficient practices. Crypto agility is akin to changing nuts and bolts – say you must change half of the bolts on the Golden Gate bridge in one go, over one day while still having it operational – “no disruptions during office hours”. And certainly, you don’t want it to collapse.
That was the easy part! Now imagine we need to make these changes to all bridges across a country. In addition to this, someone decided we must change half of all traffic lights from the red-yellow-green to blue-brown-pink and in a horizontal position. Of course, like our warming-up exercise with the Golden Gate – we need to do it in one go, perhaps we get some slack, say over the weekend. Also, we are going to be responsible for any mess in traffic on Monday when the drivers start discovering that pink is the new green.
This sounds as mission impossible and it is more likely that pigs fly before we can do this colorful transformation. You may think this comparison is way too far out there? Well, let’s look at what Wikipedia says:
Nope, I am not too far out here. "OK", you may say, "are there any good news here?" Yes, there are. First, the Wikipedia uses the example of X.509 certificates to illustrate crypto agility. That is something we at PrimeKey have done for our bread and butter in the last 20+ years. (No, we have not influenced the content on Wikipedia; the contributors used this example as the most prevalent and easy to understand.)
In a nutshell, a certificate is a data structure with many fields, amongst which are key type, key length and signing algorithm, including the hash function. To get agile, you could just change the key type and length – and you are done. As you may imagine, this is easier said than done.
Multiple certificate types and vendors make it complicated
If certificates are your nuts and bolts on the bridge, then we need the blueprint for the bridge to know where they are. Unfortunately, there is no blueprint. Companies use many systems and services, and there is no way a human can collect all locations and create a blueprint. We need some software that does it for us. Say we get all this (from us at Keyfactor and PrimeKey, of course); then what? We get ready with the new parts to replace the old ones. When it is a static thing, as a bolt, or say a handful of them, it might get done. Suppose now that we had different manufacturers for different kinds of the bolts. Well, we better figure out who made what, reach out to the manufacturers for the replacements, and shop around if anyone can make us spares for those parts made by closed businesses. This too can be done. Again, please reach out to us!
It can get even more complicated: When the certificates are used for these colorful traffic lights, then we risk getting out of our lucky strike. Mixing the pink and the green will make some cars (we call them ’non-interoperable‘) crash (we call it ’breaking dependencies‘). In other words, we need everyone to understand what we changed, and to know how to act from now on. This is the really hard part - the ’cryptographic primitives‘ and ’security protocols‘ in the definition from Wikipedia. Yes, you guessed it - we at PrimeKey do that as well. We also look at all this from the supply chain security perspective and we have all the relevant crypto stuff (the primitives and protocols) in-house.
Even if you are already our customer, you still want to assure your organization to avoid getting into the pink-and-green calamity. It is a must to have processes in place to avoid getting into the situation where you must change every nut and bolt on every bridge in your company, since at that stage any help may only recover part of the damage and cost.
There is plenty of good free stuff out there – in particular from different governmental agencies that worry night and day about folks not getting prepared for the rainy days. For instance, NIST has great publications; you may start browsing through some of the NIST Special Publications in the 800- series. For instance, the 800-131A – written by real cryptographers – talks about ’transitions’ and tells us for what and how we need to get prepared. Taxpayer money at its best!
We all stand on the shoulders of giants
I do hope you have an understanding of me and all these metaphors I use. I am passionate about our products and very proud of the great and hard work our engineers put into them. All of them – from the crypto gurus and software engineers, to our support and delivery service teams are my heroes. Often, only after the s*** hit the fan, folks get to appreciate how great value our products deliver, and regret not using them ahead of a predicament. In addition to prevent calamities, I mentioned that our products can help your business transformation journey. So why not?
Finally, not all comparisons with bridges and transportation should be negative. On the contrary – we stand on the shoulders of giants of engineering one way or the other. If you are a nerd like me, you will enjoy Impossible Engineering on TV – no politics, no rubbish, just great engineering. I learned that the concept of ’load balancing’ was implemented in the most elegant way more than 100 years ago – way before us IT nerds even existed. Look at the Pont Gisclard bridge by the French engineer Albert Gisclard. Or google for the Lethbridge viaduct – a ginormous self-constructing bridge?!!
The next and last blog in this series, will go on to discuss the third must-have quality of cryptography: ubiquity.