A relatively new concept in the ongoing debate between information security and employee effectiveness is “context-aware security.” Originating a few years ago as a buzzword for some retailers to socialize in their product offering media and presentations. Specifically, as tools and technologies defending against Advanced Persistent Threats have become more prevalent. Lately, it has taken on true substance as these tools have matured. Unfamiliar with the term ‘context-aware’? In essence, it is the evolution of policy-based controls to be more situationally aware of an action being performed. Recognizing a privileged security action is allowed based on variables of situational information such as location, device, time of day, content of data, and so on, with the controls adjusting according the action. This is a significant step up from actions permitted based on Role Based Access Control (RBAC). But where will automation fit in? Will IT have the bandwidth to do the legwork, and perform constant and real-world, situation-based policy changes necessary to actually implement a fully context-aware, protected, and secure environment? And, how does this differ from the already exhaustive exceptions list most CISO’s are already asked to make work on a daily basis?
Can Context-aware Security Ever Be Fully Automated?
In short, not easily. By definition, context aware security addresses potential abuse of granted role-based security to dynamic behaviors. At best, your policy, and the products you implement can only address known, predictable behaviors. Context aware approaches rely on assumptions. (“We can assume this user will not log in after hours, based on the usage habits of others who have held his role.”) So, perhaps they address 80% of the users, and allow for X% more productivity? Until controls can match the level of military efficiency and monitoring of actions, with the appropriate personnel to maintain those controls on a continuous basis, full automation will remain an elusive IT security goal. This falls back to very basics of IT security prevention where it only takes one new way to compromise a control, followed with a change to close that new exploit.
Is Your Identity Management Policy Ready For Your Company to Really Use a Context-based Approach?
Nod once if this is your company – HR creates user profiles. Don’t go blaming Active Directory, or your CISO, or even your HR teams. This seemed simpler when initially developed. OK, and yes, I’m over simplifying – HR does not take guesses. Instead, the hiring manager provides semi-extensive profile data, listing each of the roles and rights, all systems, each piece of equipment the new hire shall be granted upon his/her hire. Some companies go a step further, and include this same information gathering for employees who are promoted, demoted, transferred, or who terminate employment. But, is there already another identity review process in place at your company? Do you address how many folks log in from multiple products? Who on each team logs in from home at 10 pm? When and why Johnny in engineering may need payroll system access? Collecting metrics to help identify patterns can be another rabbit hole to fall down as they only provide the results for known requested elements. There again shaping a new policy based on what is presently known and factual. Easily leading to a myopic viewpoint for legitimate exceptions or false positive results for actions. Or, is that the exception process, and is your system administrator simply giving out access on a case-by-case basis? Privileged Access Systems (PIIM/PAM) can greatly reduce abuse of power. Simply from the human aspect alone where Johnny has to ask permission and knows that access is logged and tracked. However, this isn’t contextual awareness. It is just another way to skin the known data element protection cat.
Are the Products Ready?
Sort of. Our architects can speak to the countless next-generation firewalls and Intrusion Detection Systems (IDS’s) that can handle virtually any policy-based rule. But, unless your policy is as granular as a true context-aware security approach requires, technology alone will not get you there. But, context is not a product.
Why is this so Difficult?
In and of itself, the only way we are going to succeed in creating a true contextual security framework, is if we all share information. Simple, right? We’re all willing to share threats, minor or major data breaches, user habits, vulnerabilities, etc., so as to use that data to develop true context-based assumptions and rules, right? And, of course, sharing with the hackers themselves is always a risk. Sharing context in the security landscape is anomalistic in that it would require a company to expose its vulnerabilities, and further open itself to breaches.
Compare and contrast security to other worlds in which context-based habits have driven multi-billion dollar industries. Where would we be without Facebook, Google, Caesars and Amazon (among obvious countless others) telling other retailers and casinos the behaviors each can predict. The productization of this information has long since been a valuable commodity, in and of itself. While any given vertical market can be generally containerized to provide suggested controls such as PCI, HIPAA, etc with a framework to match, it doesn’t provide the appropriate “context” to the details and idiosyncrasies of how a given company functions on-the-wire.
So, how can we use this same approach to prevent security incidents, while allowing productivity? I, for one, will be eagerly watching CheckPoint’s IntelliStore and Palo Alto Networks’ and Fortinet’s cyberconsortium.org to see if they can provide some actual, useable context needed for context-based security. Perhaps this the dawn of a new service-based “contextual-aware” solution market where every access to data can be bagged and tagged, but not publicly disclosed. Allowing for the greater masses to create proactive resilience through a combination of people, process, and technology.