Nomenclature Reclamation: Taking "Hardening" back to Principles and Practices

The term "hardening" is originally sourced from the metallurgical (material sciences of the time) practices around creating processes and alloys to produce a physically harder structure according to the Mohs scale. The term transitioned to military use describing the process of making assets more resistant to attack, and subsequently information warfare with the same connotation. Commercial interests in the information technology space adopted the term; and through repeated misprints, misunderstandings, and a healthy dose of posterior-sourced speech, have diluted the term to a point where people have trouble deriving the same meaning from it. To compound matters, varying degrees of technical competencies in the engineering, decision making, and business logic domains of business entities denote not only different meanings for this term, but different domains of concern around it.

A common example of this issue is the proliferation of "Next-Gen" firewalls as the as the knight in shining silver armor (which does not rate favorably on the Mohs scale) come to save all systems pushing data across them. They tout the ability to inspect and decode all manner of traffic and "intelligently" delineate the malicious from the benign, with varying degrees of technical, functional, and business logic accuracy in their statements. Prospective clients are told that the obscene cost of these systems is justified by the level of protection they will have from inbound and client-side attack vectors (as they inspect client traffic), and the global peace of mind that this state of the industry defense should bring to the client. The client themselves however see the function and benefits (hopefully at least) from each of subject domains listed above - engineering, management, business objectives.

The business-logic parties will hear that they are protected, see a checked box on industry-standard defenses used in peer organizations, maybe a silver lining of being able to tell their clients that (their vendor told them) they are at the cutting edge, and some honestly deserved peace of mind for the protections actually provided. The decision makers will see that the business wants the promised functions and hear that they are delivered by this product, making their decision to realize the purchase and have engineering implement it. Engineering implements with accommodations for the environmental/technical requirements, and considers the assets behind the device protected from harm. Exploit uniquely encoded into a client-side context passes the (actually signature based, not some AI magic) defenses establishing a custom-encoded (or just a noise-socket/TLS1.3) tunnel back out, and the benefit is all in the attacker's favor: nobody thinks this can happen because the business trusted the vendor and the engineers worked through their chain of command. Hardening a business requires "vertical integration" in understanding of the problem domain, such that all parties are working toward the same defensive objectives. Replay this paragraph for AV, a WAF, or any other point-defense put in place with the intent of denying ground to the adversary or deterring their advance as a solution to all of life's security problems.

The military paradigm and practices for hardening are most applicable in this context because at the end of the day, this is (information) warfare. Information is no longer simply intelligence, it is now functionally weaponized as exploits and post-exploitation tooling. The intelligence aspect remains - a proper engagement is still 80-95% reconnaissance with the rest being execution and consolidation. So if this paradigm for hardening has practices associated with it honed by centuries of world militaries' expertise, which tactics and strategies apply to hardening the business in the information age?

The first step to hardening any asset is to identify, locate, and qualify the subject of said defense - what matters, where is it, why does it matter? A bridge across a muddy river or a cluster chalk full of privileged data are things which matter to the owner their managers/lieutenants and the executing defenders. Where they are won't change relative to their terrain, and they matter because they provide critical function to their owners. Once everyone is on the same page about what they're protecting and and have an initial sense of prioritization, they must assess the terrain around what they have chosen to defend. What are the approaches, the choke points, the micro terrain advantages for cover and concealment on approach? The engineers, managers, and business must agree on which "ways in" are needed to provide the access (data or function) needed by consumers, and narrow the definition of those needs to the minimum possible constraints. Permissible approaches are then sectioned off into fortified zones of quarantine and control while the remainder are simply walled off permitting a "trust but verify" white-listing model for everything in and out of each subject area. Implementation for each section's defensive attributes is guided by managers driving the business' vision and executed by the engineers/defenders assigned to that section of approach.

Going back to the organization buying peace of mind by implementing "Next-Gen" firewalls at the edge of their network, it effectively selected to protect the entire kingdom with one outer wall. The gates may have guards, and even if they can ensure valid credentials of anyone going in and out, they cannot tell if someone coming into their fair kingdom bears the plague to be distributed to everyone inside the wall. There is no one-size-fits-all castle, moat, or even fighting hole dug in history. Successful hardening of any position requires understanding the avenues of approach, and context-specific mechanisms to deny or deter advancement by the adversary.