Resiliency Part 2: Using Misinformation and Intentional Failures to Your Advantage

Part 1: What is Resiliency and How Can We Apply to All Phases of Attack?

Part 2: Using Misinformation and Intentional Failures to Your Advantage

Part 3: Cattle, Not Pets, Leveraging CI/CD Practices and the Concept of Reverse Uptime

In my last post about resiliency, we explored a number of ways to make a hacker’s life more difficult, including OTP and other forms of multi-factor authentication and related strategies. The tiny cost of a momentary delay in user experience raises the cost for the attack by orders of magnitude, making the service resilient to the compromise of passwords. While we last explored examples of how this has made personal banking, for example, more secure, the spirit of this mechanism (making attacks more costly for the attacker) can also be applied to other attack scenarios.

One recent and relevant example of shifting the advantage from attacker to defender through disinformation unfolded on the world stage of politics. In the face of credential attacks against then-candidate, but now French President, Macron, a cybersecurity team defending the campaign observed a number of phishing attacks directed toward campaign members. Recognizing that such attacks tend to continue until a user inevitably clicks a bad link that yields results for the attacker, the cybersecurity team set out to make those efforts more costly.

President Macron’s cybersecurity team responded with misinformation, inundating the password phishing sites with freshly created fake accounts, non-existent accounts, perhaps even real accounts with incorrect passwords. This frustrated their adversaries’ efforts, as now the value of any successfully phished password might not be realized considering the cost of sifting through all of the false information. Even if a username and password worked, the attackers were forced to distinguish if it was it the real user account.

Let’s take this idea of misinformation a step further and examine it through the lens of more dynamic, resilient response. At times when I have been a consultant performing penetration tests, I have used tools to analyze the web pages of target organizations to extract N-grams, basically word pieces and text phrases, for use in constructing dictionaries to be used in password cracking for common or default accounts. This worked well because a common theme among companies is to have a default password for new accounts, comprised of words or phrases from company themes or product names.

Consider if the same sort of misinformation was applied by the defenders to their website, embedding invisible specially-crafted strings in the page, such that users wouldn’t notice anything new, but the N-gram scraping tools employed by the attacker would collect these text sequences. Now what if the defenders then monitored for password attempts using these special strings, in order to automatically identify attack attempts and block IP ranges. This now adds automation to counter the automation employed by the adversaries, and makes the web login actively resilient to password cracking. Keep in mind that special considerations should be made in the era of ML and big data analytics – i.e., offensive machine learning.

Moving away from credential theft, let’s explore resilient defense ideas for infrastructure. I’ll start with an existing example outside of security. Resiliency has become a key element in the success of large technology companies focused on preserving their ability to deliver products and services despite the chaos and obstacles presented at scale. Big tech companies have built their infrastructure to support elasticity by scaling, making their environments fault tolerant, where traditional servers are replaced with sets of swappable, ephemeral microservices. One driver for this has been the movement towards Continuous Integration, Continuous Delivery – or CI/CD, the software engineering practice that enables the constant deployment of new code. One of the advantages of this practice is having resilience in the ability to conduct dynamic and partial rollouts to production. Automated fallout recovery mechanisms can then account for crashes or faults by replacing faulty instances with new instances of the same microservice. A phrase commonly used when in the DevOps community referring to these ephemeral instances is “cattle, not pets.” When one is corrupt or causing a problem, it’s simply culled from the herd. It is assumed that at any given time, a certain percentage of instances will be failing and will need to be culled.

In my next and final post in this series on resiliency, we’ll take a look at how such automation techniques can and are being applied in security settings. We’ll also explore the concept of “reverse uptime” in the age of microservices, containers and serverless environments and reveal ways you might sew uncertainty into the minds and machines of your adversaries.