Choose the matrix. No, not that matrix.
Last post was a high level discussion of what algebraic models contribute to infosec. The most important thing gained is mathematical verification of technology solutions, often framed around statements about levels of assurance. I can assure you that a lot of what is being used in infosec now is low assurance, so more use of algebraic modelling will help to raise assurance levels. This third part of the discussion on the use and benefits of algebraic modelling will show some of the unique aspects of KSE in this regard, plus how powerful the benefits are.
KSE: one framework to rule us all!
In part 2, I raised the question of what happens when the security primitives built into security technologies are mathematical objects.The answer quite importantly, is that they can’t be bent. If you suspect, intuitively, that this leads to solid components to work your security with, you are correct.
The use of these security primitives in single security mechanisms and in combination, makes it possible to enforce things. Like rules pertaining to access control on a per user basis. I mentioned how the KSE “User to User Ranking Primitive” could be used to prevent system administrators from accessing Bob’s work, here. This capability becomes handy proving due diligence that staff remain separated from enterprise or customer data, and protecting against evil and rogue admins.
Discretionary Access Control Systems -(DAC) cannot address this problem. Traditional Mandatory Access Control (MAC) security systems do address this problem, but are extremely difficult to manage. The primary reason for this is the complexity in specifying the rules. KSE reduces the complexity of this task, but still delivers the high security and assurance.
KSE provides Security Primitives for several other well understood security facilities:
- Least-Privilege System Services
- Labeled Security
- Domain Separation
- Mandatory Access Control
- Mandatory Integrity Control
Along with these security primitives, there are others that power the KSE authorization engine, (reference monitor capability) that deliver technical controls for real-time insider threat protection. These controls not only govern initial access, but the additional behaviours that a user may attempt post-initial access. These common access control facilities are designed in and allow security owners and group managers to create access rules using familiar and intuitive concepts and which follow business activity lines.
While all of this is a huge differentiator in terms of raising defensive capability, this KSE mechanism to achieve this needs more explanation. The security primitives inside Trustifier KSE are what ensures that business security rules can be algebraically mapped to system security rules.
Introducing mathematical bijection
I’ve written in the past that there is a disconnect between the business rules, based on business trust relationships and language, and the IT security rules which are object-oriented and deal with files and directories. Some innovative design based on ownership- and user-centric security allows KSE to bridge this disconnect, but the security primitives are the binding agent that allows the business security rules to be algebraically mapped 1:1 to system security rules within KSE.
This representation of each business rule via algebraic mapping to the corresponding security rule is the key to KSE’s security guarantees. Since the business rule is transformed into a system security rule as a reversible map, the security rule is stored in the kernel AS-IS, and its meaning won’t ever be lost in any kind of translation.
To illustrate this, take a simple binary image of Felix the Cat composed of black and white dots.
Felix can also be represented as a matrix of the numbers 1 and 0, where the number 0 represents a black dot and the number 1, a white dot.
If you send someone the Felix image, they could easily translate it into the number matrix. After that point either the pic or the number matrix, could be sent and easily translated into the other. This is the most basic example possible. (More interesting and fun examples of algebraic transformations can be found here.) As an aside, you might ask, what if the receiver of the matrix wasn’t informed of the number-color relationship and reversed the number scheme for the black and white dots? The image would be reversed to a white cat on a black background, so one could quickly tell that the number 0 is supposed to represent a black dot, assuming that they knew what Felix the Cat looked like, or at least knew he was supposed to be a black cat. We’ve just extended this very simple example of a reversible map to include a result check.
This mathematical function is known as a bijection. The use of this mathematical property in infosec is unique to KSE.
KSE provides a mathematical binding between the enterprise business rules and the IT security rules so that the resulting security is consistent and verifiable.
This illustration is from our design guide paper.
As the diagram shows, the business security rule can transform in its exact original form from the security rule, or vice-versa. Another example may help illustrate the potential implications of this further.
Consider if you can, the make-up of your business enterprise IT as a portrait. Perhaps it’s as classic in your own mind as the Mona Lisa, only this portrait is a mosaic of programmable IT slices, each of which supports some aspect of business functionality and bound by a business rule. Just like Felix the Cat, the portrait could be represent by dots, like Mona to the left is, except each dot represents a slice of IT functionality.
The KSE bijection is the equivalent of a second transparent, tightly coupled, security skin which is adjoined to the IT slice by a mathematical binding. Each slice of IT business functionality is bound to its security skin in order to ensure that any required security around it is delivered as expected, able to resist tampering and interference. Don’t think it’s like when some people glue down or lacquer a favourite puzzle to frame for posterity, never to change though. In our example, the underlying business rule manifested by IT services, and any security rules associated around them, can still be modified or tweaked on the fly as needed, and only with proper authorization. The mathematical binding exacts itself automatically on to the relationship the instant the IT sec rule is created.
For any IT slice making up the mosaic, the intended business rule is entwined with the KSE IT security rule; it can always be determined from the security rule, and will not be opaque to the security rule, even if surrounded or bundled with hundreds or thousands of other rules. It will always be enforced as intended.
Bijections are mathematically consistent; they are guaranteed to be consistent.
Security is all about knowledge. It’s not necessarily just about stopping bad guys from getting in and stopping some stuff from getting out of the enterprise. Some stuff is critical to the mission and is supposed to get out, albeit in a secure way. The point is, you need to know that what is supposed to go out, is going out properly to correct parties only, as well as being sure that what you don’t want to get out, isn’t. This is all part of risk management. Dan Geer occasionally reminds us, that the goal of security is to avoid nasty surprises.
In complex environments, with many security owners, operators and officers it’s easy to forget, lose track of things, commit sins of omission or have things lost in the shuffle of departmental business. KSE and bijection is about more than just context. KSE simplifies the rule making process. They are intuitive since they follow from the business activity. You can set a rule quickly with One-Command. You can quickly tell what rules you have, for any group or user. You can generate the biz rule from the sec rule if you didn’t know it before. That 1:1 mapping is what makes the security robust. It’s clear what it is, and what is to be enforced.
Each KSE rule is independent of all the other KSE rules. There might be thousands of rules floating around but that rule on its own is what is going to be enforced. They are exact and consistent. There is less worry about cracks in the rule setting framework. The rule can say Bob gets to read the file, or Rob can’t read the file, then that is the rule, and it will be enforced, on every KSE protected system to which the security rule has been pushed out to. The KSE rule set supersedes everything else taking place on a node, and the KSE enforcement engine has the last say in the executable chain, so a rule that is set is a rule that gets enforced.
Consider what I just wrote for a second. If I create a rule that says Bob can’t access a file or directory, that rule is going to hold on a KSE protected node no matter else is happening on that system. It won’t matter if there is a misconfiguration or some other error, a stupid user trick or some form of attack, that rule will be enforced as long as it exists.
With KSE it becomes easier to craft proper business related rules governing Bob’s behaviours which follow him across various domains in the enterprise, and then follow him into mobile space, as well as into the cloud. The business rule will be consistent and applied across the board because the security rule can be pushed out where it needs to be.
Other cool things are possible, like scalable MLS or cross domain solutions. How else can you get nodes to act “in sync” in terms of rule enforcement in a zone, across an enterprise, or for single domain separation such as compartmentalizing a whole user group within a flat enterprise network, with some verifiable security guarantees? This has implications for the concept of “remote attestation” which enables potential for possible interactions of distributed systems, when combined with the protections of trusted system hosts on participating nodes.
One may realize that a business rule could generate a number of security rules, perhaps dozens, to provide context for temporal, conditional situations etc.. Not to worry, KSE is able to bundle them tightly so they are entwined, and handles them as a single rule. This is possible because with algebraic modelling, one is adding computational steps to the matrix. When I say choose the matrix, I’m referring to algebraic matrices such as on the left, only they can have hundreds, or thousands of row or columns depending on how many equations are used, being calculated at a fraction of a second.
Despite the possible thousands of rules floating around in an enterprise, each rule is independent of any other and is enforced separately. The benefit here is the simplification of security. Thus in a traditional set-up, someone with 20 roles might require security to set up 120,000 rules (ACLs) to protect this person. With KSE, 20 roles will mean 20 rules. The impact of this in terms of reduction of complexity, administrative overhead, and cost of ownership should be fairly obvious. This is one of the ways that KSE significantly reduces administrative overhead compared to a SELinux or Trusted Solaris solution. (By approximately 2 orders of magnitude, by our estimation.)
Putting it together
KSE presents some powerful innovation, but how can one apply it to gain optimal improvements in defensive capabilities? To start, all kinds of cool protections for controlling access to the IT vulnerability surface become possible. KSE is able to envelop all processes in a “need-to-access” environment, which limits the access of all processes, users, files and data to exactly what is needed for a specific service to operate safely and securely. The algebra backed security mechanisms of KSE can enable a pre-emptive lockdown of the system so that the possibility of external intrusion intending to tamper with system privileges or rules for access becomes an extremely difficult exercise.
Think about it. I’ve written in other posts that KSE is user-centric and default-deny. When you can whitelist user end behaviours for all users, including system administrators, one can set and enforce rules for least privilege access to individual root system calls. For every system call, including root system calls, it boils down to control by a bit flip enforced by a rule. When it’s flipped off it can’t be altered by anyone. Only those rules that have been set are in play. Only authorized persons, and that doesn’t automatically include system admins, can flip it on to make changes. One ends up with just-in-time control over privilege elevation, so the chances of intrusion are reduced by exceptional factors. This is a mechanism that prevents threats from exploiting vulnerabilities, and unauthorized privilege elevation is prevented.
Some are aware of the fact that KSE was designed specifically to protect vulnerable systems, without patching. (That is really the whole purpose of trusted computing after all.) For Red Team challenges, exploitable vulnerabilities are purposely left unpatched to demonstrate this. There are also no conditions or limitations ever placed on tools used, or extent of the attack, made on Red Team challengers. When they can’t gain advantage from external vantage points, we proceed with full bore insider threat testing, signing challengers in as first users, and then admins with passwords. We even point out target directories to them and ask them to reveal the contents. None ever can, and by the way, KSE protection does this without the use of encryption. While some time intensive protections such as SELinux can also protect systems against zero days, they come with a steep learning curve, high admin requirement, and don’t scale across different platforms the way KSE does.
When I point folks to this, the usual response is a bit of the “roaring silence”. Perhaps they suspect some gimmick or trickery involved, or severe good luck that this happened, so maybe this post gives the context that can help one understand that KSE does not work the same as other technologies. (See our response and commentary to the DISA write-up of our defeat of a combined DISA/NSA Red Team here. According to this Red Team, it was the first time in 8k+ challenges that they failed to breach.)
Some people who have read the DISA report have been quick to note that vulnerabilities were found, implying that it was only a matter of time. So I’ll emphasize again that they were left unpatched purposely to demonstrate that KSE would prevent their exploitation, which it did. The whole point is to demonstrate the ability to protect vulnerable systems (without patching). The point of the math, and this blog series, is to explain why it would not be a matter of time, as one usually sees in the typical vuln-centric infosec world view.
We know that when one doesn’t have trusted execution environments, everything else has to be nearly perfect. Are we achieving that, with secure software, APIs etc.? Not even close.
KSE algebraic modelling provides the means for trusted computing to run on COTS systems. KSE provides the trusted execution environments controlling access to, and use of, the IT vulnerability surface. Guess what? Such systems tolerate imperfect software and users. Trusted systems which disallow threats from exploiting vulns are a good thing aren’t they? Reference monitor capability verifies and enforces rules for per user behaviours and operational privileges. Systems that become trustworthy can be combined to build the chains of trust, Defender Chains, and trustworthy zones that infosec needs more than ever.
This is not an automatic process (although KSE is automating more of such processes continually), but contingent upon appropriate rules to protect enterprise assets and govern user end behaviours being created correctly. As always, knowing the assets to protect, as well as understanding business processes, activities, goals, and data flows needs to be the starting point. Then, the algebraically based security sub-system that is KSE adds formidable but highly flexible, extensible and tailorable security mechanisms to the equation.
I’ll repeat myself to remind again, that,
KSE is designed to bring mathematically verifiable trustworthiness to existing COTS systems.
The platforms may be interchangeable, but the math behind the mechanisms securing them, will be a constant. Controls are one thing, but mathematical proofs that your system controls are non-bypassable are another. This is also about making the security of commonly used systems not only much better, but usable and manageable, rather than about developing some geeky solution that few can actually use.
That’s the thing. KSE is amazingly user friendly, and cost-effective compared to traditional high security/assurance systems. When one is able to reduce complexity, and reduce admin overhead, this lowers total cost of ownership. Who talks about this in security?
And as you know, it all adds up, right?
Infosec Moan-A no more! KSE delivers assurance.