Cybernetic Security: Adaptation, Regulation, and Complexity Management
from Security Through the Looking Glass
This is the second entry in a series. If you haven't read the previous one, now might be a good time. If you're all caught up, then let's get into it.
Viable systems exist within an environment. They adapt to the environment, but they may also change the environment as they adapt and grow. Beavers evolved to build dams, and in doing so they changed the ecosystems in which they evolved. A successful company will change the market. A successful non-profit will change their domain. But even a stable company is only one entity within the environment. Other companies, NGOs, consumers, and the public sector all exist within this same environment. Regulations, technological advancement, and customer tastes all shift the environment.
Within this dynamic environment, what are you doing to track changes that impact your viability? How are you connecting environmental changes, such as regulation, to internal constraints, such as those that drive compliance enforcement and verification?
A security program will need to focus on a specific subset of this question. How do you monitor threat actors? The evolution of threat actors and their attack profiles must inform your risk model and prioritization. As defenses evolve, threat actors adapt and their attack patterns change. How do you collect data? How do you process it into intelligence that's actionable by people on your team?
Similarly, a security program will need a mechanism to track external changes to its attack surface in the form of supply chain risk management. What mechanisms do you have in place to track vulnerabilities in third party libraries, applications, and appliances that you use? How do you make sure that information (and specifically that information, not a flood of false positives) gets to people who can act on it?
We will come back to threat actors and vulnerability management in other articles.
Keeping track of you constraints as they evolve is only half of the constraint management equation. The other half is algedonic signaling. How do you know when constraints are violated?
In the body, an algedonic signal is a basic “pleasure or pain” signal, like those we started with. When your body is hungry, you feel it. When you get hungry enough, it hurts. The signal isn't detailed. It doesn't provide much information. It's simple and generally easy to investigate. Many signals, such as hunger, are intuitive. We learn to understand them immediately and without investigation.
All constraints should be tied to “algedonic” signals that trigger when they violated. But are they? If you've recorded your constants (as described in the previous article) then you can perform a gap analysis.
For each constraint you have identified, write down the signals that fire when those constraints are violated. For any gaps you identify, and figure out a plan to close them. Are there constraints you have listed that you would feel comfortable not being alerted of in case they are violated? Those are not really constraints (at least not at your level) and they should be removed from your constraint list.
Anyone who has worked in tech long enough has seen some variation of alarm fatigue. Perhaps it has even been you who has had an email filtering rule that dumps alerts into a folder that is periodically cleared without any messages ever being read. Many security engineers will have had the experience of pointing to a vulnerability found by some automated scanner or other, a vulnerability which has since been then verified by a security engineer, and asking, “why was this been marked as a false positive?” Perhaps you've observed to someone frantically clicking through a series of dire warnings, recognizing that the warnings intended to stop them have simply trained them to click fast without thinking. Too many signals can overwhelm a system. Notice that I'm not specifying spurious signals. Accuracy is also a problem, but sheer volume of accurate signals can be enough.
Then what is the mechanism by which signals are reduced? Common frameworks can address common vulnerabilities. Many security programs will look for security violations: insecure software being used, vulnerabilities in software being developed, and so on. There are infinitely many ways to implement software insecurely. There may well be as many ways to implement software securely. Sorting between these sets requires tremendous knowledge and has a high probability of failure. By restricting the definition of “secure” as complying with a specific set of vetted patterns, software, hardware, configurations, and the like, the verification work is reduced.
Security Engineering can work on identifying common problems, addressing them with vetted patterns, and ensuring deployed patterns are updated as needed. This internal optimization work helps make the external signals around supply chain risk into something manageable. These restrictions are enforced not by complete refusal to use software, hardware, or configurations not explicitly allowed, but by adding friction, in terms of additional auditing or monitoring requirements, for teams trying to use them. Critical deviations will still be possible, at a cost, and most users will choose the path of least resistance.
Compliance work may revolve around understanding what regulations apply to software, what assets regulatory bodies need, and making sure those assets can be delivered. But it can be easy to miss that compliance can reduce regulatory risk through early intervention. By providing guidance that allows software to be designed in a way that avoids falling under regulation, or by concentrating regulatory risk in a smaller set of components, complexity, and the risk of signal overwhelm, can be reduced.
While cybernetics foregrounds the importance of complexity management, encapsulated as Ashby's Law of Requisite Variety, security program leadership can struggle to see the forest for the trees. In the frantic struggle to fight all the fires, it can be difficult to even notice the larger patterns. This is exactly where cybernetics can help us most.
The VSM defines a set of metasystemic subsystems that manage any system. In the first article we talked about the system itself as an entity surviving within and adapting to an environment. We connected that to the Identity subsystem, and how invariants inform constraints through identity.
In this article, thus far, we have talked more about that dynamic environment and how we need an Awareness subsystem to track environmental changes. We've also talked about managing complexity through synergy using an Optimization subsystem. This leaves two more metasystemic components to cover: Internal Audit and Learning, and Harmonization. Before we talk about those, let's jump down the stack one more time. What are these subsystems learning about, auditing, and harmonizing? All of these metasystemic functions exist to support the Operational Units. Operational Units “do all the work that keeps the system alive.” In the body these are the muscles and organs that breath air, find food, digest food, and remove waste.
While the brain, the metasystem, directs the activity, it is the rest of the body that realizes that activity. It is important to keep this fact in mind as we try to understand the role of security in an organization. With this in mind, let's return to where we were.
The Optimization subsystem can passively coordinate optimization opportunities that are identified by subsystems, but it can also look actively collect data. Internal Audit and Learning is a subsystem of optimization that performs audits and looks for anomalies. Security folks may well be taking notice, recognizing some of our own work in this subsystem. But it's a little more complex than that. Let's talk about the Harmonization subsystem.
The function of the Harmonization subsystem is, essentially, to keep operating units from interfering with each other. If Operational Units are sharing compute resources, for example, Harmonization would include things like permissions and quotas. The VSM says that operational units should have maximal autonomy, but each Operational Unit must be prevented from threatening the viability of the system itself.
Now we, security, can really see ourselves in our familiar role with our familiar problem. Each operational unit may be trying to create a product, ship software or hardware, or to provide a service, but in doing so they can increase the attack surface. Promotion driven development may push team leads to compete to get software out faster and cheaper, incentivizing them to cut corners wherever they can. They ask if they can reduce the scope of a review, or push now and fix later. They may even push features that change the threat model but are, somehow, also “too minor for a security review.”
They each individually peruse their own objectives, and in doing so threaten the security of the organization as a whole. But when vulnerabilities are found, and perhaps even exploited, within a team's code the company as a whole bears the burden. Isn't it interesting that security tends to behave similarly to police, when, in actuality, our job is that of commons management.
Customer trust and internal funds are parts of the internal commons threatened by through a company's collective attack surface. The job of security is to coordinate teams across the company to ensure attack surface is minimized. Security works to protect customer trust from reputational threats, and funds from regulatory action and illegitimate compute usage.
Companies mature enough to understand that “policy enforcement” needs to have teeth, often become too big for that same enforcement role to maintain visibility. Companies that haven't reached that level of maturity simply don't give “policy enforcement” the tools to actually “enforce” anything. “Policy enforcement” creates an adversarial relationship between security and operational units that makes everyone's job harder. By recognizing security as a support role, rather than an authority that demands obedience, we can focus on building the relationships we need to protect the organization that we all share.
The economist Elinor Ostrom worked extensively on commons management, but the rules she developed are outside the scope of this work. That said, we will briefly touch on five rules for commons management will help simplify our work:
- Commons must have clearly defined boundaries.
- Commons must be monitored.
- Those who abuse the commons must be sanctioned.
- Commons management must have authority.
- Commons management works better when the specific commons exists within a larger commons framework.
We have already touched on both the “authority” and “abuse” elements, though we'll need to come back to those later. In the next section we'll align all of these into a process that's driven by a new threat modeling methodology. This new methodology will pull from the information we established in the first section, and the program we build around it will revisit many of the concepts we've introduced in this section.
⠀⠀
বহুকাল আমি নিজেকে একজন ভুল মানুষ ভেবে এসেছি। আমার পৃথিবীটা ছিল কুয়াশায় ঢাকা, যেখানে স্পষ্ট বলতে কিছুই ছিল না। আমার ভেতরে নিজেকে প্রকাশ করার এক তীব্র আকাঙ্ক্ষা ছিল, কিন্তু যতবারই আমি মুখ খুলতে চেয়েছি, ততবারই মনে হয়েছে যেন কেউ একজন আমার কথাগুলো বন্দি করতে ছুটে আসছে। ভয় ছিল আমার ছায়াসঙ্গী। তাই আলো থেকে পালিয়ে বারবার আমি ফিরে এসেছি আমার পরিচিত অন্ধকারে, আর সেই অন্ধকারই হয়ে উঠেছিল আমার একমাত্র পরিচয়। আমি মেনেই নিয়েছিলাম- আমি আদি থেকে অন্ত পর্যন্ত ভুলে ভরা এক মানুষ, যার জন্মই হয়েছে ভুল করার জন্য।
