When we think of computer security, we think the computer is "making" an access control decision like access granted or access denied. In reality, the computer is trying to make an access control decision. Hackers have known this, and this distinction has fundamental implications for your access control and security architecture.
The big key is not to think of your security architecture as one deterministic thing or a panolopy or products, but rather as a chain of events.
Pat Helland points out a fundamental disconnect in computing:
"Computers always have partial knowledge for a couple of reasons. First, they will always be separated from the real world. Stuff that happens in the real world will, at best, be reflected after the fact in the computer system. Second, a computer system may have other replicas from which it is separated. A computer's knowledge of the world will be partial.
Computers do not make decisions... They try to make decisions.
The best a computer can do is make a guess. It might be a good guess. It might be a bad guess. Either way, there is no certainty, only guesses."
Our security systems always have partial knowledge, because they are are trying to distinguish valid access attempts from malicious ones. The knock on effect here is that instead of dealing with certainty, our computing systems are built up on Memories, Guesses, and Apologies.
Guessing for Fun and Profit
You do not have to look too far to see Guesses in computer security - start with log in.
The request sends something they have and something they know, the server guesses it must be the same "person." All you have to do is look at all the different authentication protocols out there - password, IP whitelisting, Hard token, soft token, geolocation, telephony, smart card, biometrics, and on and on, to see that the story of authentication is a journey to make more precise guesswork. But authentication is still fundamentally a guesswork operation.
Why does this matter? Access control chains begin with authentication and authentication is fundamentally a guess.
Memories Improve Authentication
"It is really nice to remember your guesses... It makes it easier when you guessed correctly. It makes it easier to clean up the mess when you've guessed wrong. Usually, computers remember what they've guessed.
Furthermore, it is nice to share with other replicas. You get all the coolness of replicas,disaster protection, etc. Replication definitely helps with memories."
The next evolutionary step in authentication is risk based access controls. These cover a broad range and its early days for readily available commercial products. Memories play a key role to deal with malicious access and enforce fraud rules. Rate limiting, fingerprinting, device scraping, and other techniques focus on remembering access and assign probabilities to what's granted access. What they all have in common is that the system has to remember a lot more than username and password. Should the system rely on passwords, that should not be the only control. Like we saw in the Apple iCloud attack, iCloud did not have rate limiting in place - the guesses were never committed to memory - leaving iCloud users vulnerable to brute force guessing attacks, unaided by any server side memory. Put another way, your security should not rely solely on guessing.
Most time, effort and expense go into authentication technologies, however if we remember that the access control chain includes authorization and accountability, then we should not limit our investment in the access control chain solely to making a guess and then skip merrily past the other issues. We should instead recognize authentication for it is - guessing - and then proceed to improving the fidelity and integrity of memories and ensure that apologies are issued as efficiently as possible.
Memories Are Fundamental to Authorization and Accountability
Beyond authentication, memories have a role to play in improving authorization and accountability. Authorization logic should not be a guess, almost always its based on business rules and technical realities. What roles and attributes govern who is allowed to access what.But in practice these are delegated to developers to build authorization into code. The memories used for authorization should not be an afterthought of "some things that happen after the user authenticates"; instead authorization policy should get more attention from security teams for design, development and testing. After all, why spend more time in a quixotic pursuit of the perfect guess, when your memories lack integrity?
Speaking of reconciliation, the industry's efforts in monitoring continue to show real progress. The nature of monitoring systems is memorization of events.
Apologies - Manual and Automated
Computer security has lots of experience in apologies. Whole fields of the discipline, like incident response, are devoted to it. On a more simplistic level, the whole password reset exercise could be looked at as an apology exercise. Server tries to guess to see if its you, cannot figure it out, and then the password reset dance begins to reset the memories and update the guesswork.
Are there ways that manual processes for apologies can be replaced with better automation? What apologies are needed to improve the guesses and memories in the system? Beyond password reset, what about using transactional monitoring to detect application issues and address them on the fly? Applications and updates are deployed to the web before they are fully tested, how best can the security team close this gap in finding and fixing vulns?
A key takeaway for me for thinking about security in a traditional way "user uses system, policy fires, decision made, access granted/denied" versus Memories, Guesses and Apologies is to look at a system as trying to be Eventually Secure. Instead of aiming for perfect, find the places where there is sand in teh gears and look for other parts of the system to compensate. Recognize that authentication is imperfect and instead of leaping to the next all singing, all dancing authentication protocol - double or triple the efforts and investments in memories and apologies - authorization, monitoring, testing, and repair.
The key is not to think of your security architecture as one deterministic thing or a panolopy or products, but rather as a chain of events. That means our time should be spent in pursuit of the chain of security responsibilities that govern these events and how they fail.