El famoso analista Marc Andreessen acu\u00f1\u00f3 la frase “El software se est\u00e1 comiendo al mundo” en un art\u00edculo de opini\u00f3n del Wall Street Journal en 2011. M\u00e1s de una d\u00e9cada despu\u00e9s, esto no podr\u00eda ser m\u00e1s cierto con m\u00e1s dispositivos, ejecutando m\u00e1s software y creando una superficie de ataque m\u00e1s grande y m\u00e1s compleja para combatir y administrar. Sin embargo, todav\u00eda confiamos en los m\u00e9todos criptogr\u00e1ficos creados hace casi medio siglo. Cuando crece la complejidad de los sistemas, tambi\u00e9n lo hace la complejidad de sus problemas. La industria de la defensa es perfectamente capaz de construir m\u00e1quinas fiables a partir de piezas no fiables. Entonces, \u00bfpor qu\u00e9 tenemos tantos problemas cuando se trata de software?<\/p>\n
Famed venture capitalist Marc Andreessen coined the phrase, \u201cSoftware is eating the world\u201d in a\u00a0Wall Street Journal<\/i><\/a>\u00a0op-ed<\/a>\u00a0back in 2011. More than a decade later, this couldn\u2019t be truer with more devices, running more software, and creating a larger, more complex attack surface to combat and manage. Yet, we still rely on the cryptographic methods created nearly half a century ago.<\/p>\n When complexity in systems grows, so does the complexity of its problems. The defense industry is perfectly capable of building dependable machines out of unreliable parts. Why then do we struggle so much when software is involved?<\/p>\n Across industries, better systems have been built by standing on the shoulders of its prior successes. Just as advances in materials science have led to higher speed turbines and subsequently lighter, faster, and more maneuverable aircraft, modern software systems have been built on advances in technology. In the software world these advances come in the form of packages or libraries. By splitting functionality in these libraries, we\u2019re able to differentiate and specialize.<\/p>\n A simple example to reinforce the point follows. The very first applications were monolithic running on a specific hardware platform. Differentiation gave rise to specialization, and so the database was separated from the presentation layer and user interface. The business application logic was separate again still. This allowed databases to advance in terms of speed and scale independently from UIs, networking, and even the storage layer underneath.<\/p>\n This specialization drove costs down and performance up. It also gave rise to a supply chain, where various independent vendors create and contribute different parts to the overall product. At a macro level, complex systems such as the aircraft make use of many components, each having its own software systems. All parts standing on the fruits of prior success. As system complexity grows, the ability to understand the \u201cknock-on\u201d effects of failure of individual components reduces. It also presents the opportunity for remediation.<\/p>\n In an aircraft there are several different ways to measure key telemetry i.e., airspeed, altitude, etc. Each has different measurement criteria, different vendors, different software stacks. This diversifies away the risk of one single component being unreliable.<\/p>\n Software systems, unfortunately, are not designed in a manner where redundancy is built in. Instead, modern software systems rely on patching and updates as flaws are found. This approach has consequences. System downtime is often incurred as a patch is created and applied \u2013 and only if the failure is noticed. This hits cryptography especially hard, as failures in cryptography allow an adversary to eavesdrop \u2013 and when one is successfully spying, they tend to keep that fact a secret.<\/p>\n In the world of cryptography there is a widespread belief that it is somehow unbreakable because it is based on mathematics. This couldn\u2019t be further from the truth. The merits of the math notwithstanding, implementations have bugs \u2013 on average 10 to 20 bugs per 1,000 lines of code. Keys and certificates sometimes leak. Human error is usually present, either in the form of insufficient programming skills, lack of ongoing training, or simple implementation errors.<\/p>\n The fact is single points of failure in cryptography exist and are commonplace. Yet, the industry suffers from crypto amnesia and a scattered way of looking at cryptography which has allowed breaches to take place and attacks to happen.<\/p>\n This begs the question: how can we build resilient software systems out of unreliable parts? The earlier observation has a direct applicability: redundancy in algorithms, implementations, and software components are all solutions to diversify away the risks, just as we do in physical engineering where lives are at stake. Engineering disciplines, outside of software, are acutely aware of the need to build-in redundancy and create a management layer to administer this added complexity. In software, no such management exists.<\/p>\n The answers lie in policy control and interoperability.<\/p>\n Policy to encode the rules of governance, and interoperability to enable the required redundancy and agility to continue operating under degraded conditions. For system integrators, most of which have written software, a deliberate emphasis must be made on resiliency.<\/p>\n The software engineering culture, starting at the product management level, must demand that the software system is able to continue to serve, even as individual components are defeated. Software engineers too must evolve their thinking, asking themselves, \u201cwhat if the component I use no longer serves as I expect?\u201d<\/p>\n And finally, as it pertains to cryptography, keep in mind that one might never know that a component has failed. Only as we evolve our thinking in software engineering will we be able to get away from the culture of panic patching and updating.<\/p>\n