Security professionals are fraught with crazy obstacles unseen in other parts of the technology space. For example, we are often fighting enemies we cannot see. They out-maneuver us by attacking our partners, informational supply-chain, and even the people. But they are not completely invisible if we know what to look for.
There was a recent thread on the SIRA mailing list that discussed the concept of “non-observables,” or elements in the security space that cannot be feasibly observed by defenders. These elements, in theory, would be critical in event detection, thus providing defenders with better capabilities to shrink the window of vulnerability.
This is a foolish notion that leads security people into an unnecessary state of helplessness. Consider Locard’s Exchange Principle.
The perpetrator of a crime will always bring something into a crime scene and leave with something from the crime scene. Thus, any action will invariably cause the exchange of matter between the two parties (or evidence of a crime in the case of something committed at a distance).
This notion transfers well into the electronic crime world, but it requires better visibility into our infrastructure. We have to have better ability to collect events of all kinds, however innocuous they appear, and build analytics and trends across them. Attackers will leave traces of their actions as they interact with systems, just artifacts of our systems will be left on their machines (albeit, often temporary).
I argue there are no such things as non-observables in the security space, at least nothing relevant to a defender. Everything is observable, as long as you have the right technology. Some argue that a user forgetting his password is a non-observable event. Since we do not yet have the ability to read minds, we can’t tell if a user remembers his password either (and frankly, that is irrelevant). We can only observe his behavior when he interacts with the system—either a successful or failed authentication.
“Now Branden,” I can hear you ask, “that doesn’t necessarily prove that the successful authentication wasn’t performed by an unauthorized user!” Correct, but that authentication in context with any other actions become a fingerprint for the interaction. Where is the user originating from? What does this user typically do? Are they operating in a way that is typical, or atypical?
We can only understand the answers to these questions when the actor makes a move on the system in question. Once an action is taken, we observe what happens, and then make our move (to defend the system or to do nothing… remember inaction is still an action). We can do this with ample data and analytics, but we must choose to capture and use it. Behavior-based controls are the present (future) of defense.
Would we invest in this for compliance? No way. But then again, we shouldn’t be spending only for compliance, now should we?
Possibly Related Posts:
- Selective Domain Filtering with Postfix and a SPAM Filtering Service
- Preventing Account Takeover, Enable MFA!
- Proofpoint Patches URL Sandbox Bypass Bug
- Improve Outbound Email with SPF, DKIM, and DMARC
- Life after G-Suite/Postini