In the early days of my career, I was the product manager for an industrial control software product. That software had two jobs. The first was to monitor the devices on the manufacturing floor to make sure everything was operating correctly. The second job of the software was to make adjustments to equipment to optimize performance. Essentially, we were doing IoT, but with connected computers and specialized equipment called programmable logic controllers (PLCs are still a thing today, but of course technology has improved).
Self-healing in the age of DOS
It was amazing what our software could do at the time just running the DOS operating system. We had cutting-edge graphics that would show how full a tank is, and display the temperature of the container in the tank. We could show the movement of raw materials through to the end product. We knew whether something in the plant was overheating or the tension of critical component was lower than the specified baseline.
Have you ever read the label on the back of your toothpaste, tomato sauce, or [insert product here] and it says “contains at least x percent of this ingredient and may contain y ingredient”? As amazing our manufacturing plants are, they are not perfect. If you purchased two bottles of toothpaste from the same manufacturer, there is a good chance one has a bit more fluoride than the other one. That said, a good manufacturer has already defined limits of what too much or too little means.
One of the coolest things our software could do was provide the ability for manufacturing plants to define the best practices and standards for how the plant should operate. If a tank got too cold, it could heat it back to the right temperature. If a machine was spitting out too much liquid, it could reduce the amount. We did all this with the combination of a computer running DOS and PLCs that contain specialized logic.
While human intervention was always an option, that potent combination of software plus hardware allowed us to keep a manufacturing plant running at peak performance through these very early self-healing techniques.
Self-healing in the age of cloud computing
The concept of software automatically detecting a problem and healing the problem is nothing new. We all [should] have anti-virus software on our computers so we can at least secure ourselves from the common, known, viruses. If your computer is infected, the software attempts to heal your computer by removing the virus.
As software developers continue their march to the cloud, they are writing software that is not necessarily behind corporate firewalls and is assumed to be more secure than it is. Amazon’s AWS and Microsoft’s Azure are two of the top cloud platforms on the market today, and they both allow you to create databases, APIs, storage containers, and more that are publicly available. While those providers will make sure their platform is secure, it is up to you to make sure the applications you create are secure.
What exactly is application security? Well, that is a whole topic unto itself, but what AWS and Amazon make sure their systems are highly secure and bad actors will not creep around their infrastructure and hack your system. That said if you create something like an S3 bucket that stores all sorts of information, like customer data, important documents, etc. and you do not secure it, then that is on you because that is your application and you did not secure the data. Unfortunately, bad actors are looking for that information, and they do find it. Fortunately, there are nice people out there sending helpful hints to developers to fix the problem.
But here’s the rub: Developers are not necessarily security experts. I do not think developers try to create insecure systems, and they certainly do not want their applications hacked, but they may not be up to speed on the latest and greatest security best practices. Sure, we are defining roles for human beings to address security at a deeper level, hence the job title du jour DevSecOps.
As we know, humans are fallible, and developers are under tight pressure to deliver working code. Organizations create a list of standards and best practices, but you cannot be guaranteed every developer knows and understands those standards, nor can you expect they will always sit down with a checklist to make sure every security item is in place and done so correctly.
Enter self-healing security solutions — or autonomic governance and security. The idea here is to define security best practices up-front, then as the developer is coding their solution, the code build stops (or breaks), warning the developer they are not following a best practice. Further to that, if the code is deployed and is not following best practices, self-healing software automatically closes the security gap and informs the developers of the action taken.
An interview with Josh Stella, CTO of Fugue
Fugue is blazing new trails with its suite of software to provide autonomic governance and self-healing security to developers writing code for the cloud. In this T-Suite Podcast, we talk with Fugue’s Josh Stella about the past, present, and future of self-healing technology and learn more about how developers can make their apps more secure.