Authorization - The Forgotten Second A
It seems that everyone in InfoSec is focused on solving three problems: identity, identity, and identity. Its the Who Are You? track on endless repeat. The focus is entirely on the first A of AAA, Authentication, Authorization, and Accountability. Security vendors are pitching adaptive authentication with everything from geo-location pattern awareness to typing rhythm detection. Dont get me started on biometrics that will soon have our laptops be certified as medical devices, measuring heartbeats, pheromones, and blood type. So what exactly happens once we figure out you are who you say you are? Now what? You still have the information access issues that have been around since mainframe days. Have we forgotten about the second A? I predict 18 months from now everyone will be pitching authorization solutions or more specifically continuously-adaptive authorization solutions. After who are you its the natural okay, so what do you want? While adaptive authentication raises the barrier to entry, effective beefing up the logical perimeter, data access and subsequent user actions are where the risks become viable. Keeping the bad guys out while the good guys have access is the old Castle theory elevated to cloud-levels (note to self: Moat-as-a-Service). We can no longer assume the bad guys are only outside the walls. Indeed, we have a mix of bad and good on our payroll, and in particular good guys that turn bad a day before they put in their resignation notice. The next generation of identity solutions (first A) will include an advanced form of adaptive authorization and auditing (last two As) using data science and behavioral analytics. Keep in mind both Edward Snowden and Private Manning were fully authenticated users. Even Aaron Swartz at MIT! Their identity was known and they were authorized to access the data they exfiltrated. No identity solution would help in these cases because an account was not compromised; a valid account was used to make valid requests. The obvious use case for adaptive authorization is within cloud environments. In most cases, cloud providers support purpose-driven application platforms with enormous data mining capabilities. By exposing the power of these platforms to security administrators, it is entirely possible to build adaptive authorization tools to secure one of the biggest security risks in the public/private cloud deployments: excessive but authorized access. nbsp; nbsp; nbsp;nbsp; Profiling and LearningThere are a number of ways to reduce an attack surface; the simplest of these is disabling or disallowing unused access. When organizations hire employees they invariably grant access and entitlements via a new user template, or duplicating the permissions of an existing user in the same department. In less strict environments, a new user might be granted full non-admin rights to everything (It just makes everything easier is the refrain from the chorus). Over the next few months, that individual develops a clear pattern of behavior within their job function. While that is likely to change as the person grows with the company but that change tends to be gradual without dramatic deviations from day-to-day. By monitoring each users workflow and computing patterns, we could programmatically identify and disable over-provisioned access. If the person needs access to a resource for which they were originally entitled, kick off a workflow approval to grant or re-enable the access.nbsp; This isnt about detecting the anomaly of behavior. This is about detecting the *ABSENCE* of usage to rights that were previously given, and removing them. Think of it more as expiring access than revoking. You are granted access to every database, but over a long period of time, your access to the 90% of databases you never touch becomes stale and expires. A less dramatic approach could grey-list that access afternbsp;a period of time, say 90 days, where the systems alerts on any access and expires after 180 days of inactivity. nbsp; It easy to see a next generation authorization system capable of pruning access per-resource, based on usage and access patterns. Unlike heuristic based network IDS, anomaly detection in software applications is far easier to identify - we have context! If an individual has read access to 2000 DB tables when they join a company and have only accessed 500 after three months, using analytics we may automatically scale back (expire) their resource permissions to match what is actually required. Reducing that individuals potential (future) insider threat profile by 75%.nbsp; nbsp; nbsp; Mitigating Data ExfiltrationSometimes good people do bad things. The insider threat is well documented but most folks throw their hands up and say we tried DLP and that failed or worse “we’ll let the lawyers handle that.” Why? It is possible to implementnbsp; highly accurate monitoring solutions that will detect a change in behavior. A user who typically accesses a database 10 records at a time probably doesn’t access 100,000 all of the sudden. Maybe they have a perfectly legitimate reason to do so, let’s verify with an authentication challenge or a second level approval to confirm they really need to perform that action. While we are at it, let’s send that to the alert operations team just in case.nbsp; For an analogy in the physical world, let’s look at Bob. His job is to carry out boxes to trucks everyday, usually nbsp;2-3 boxes, Bob is authorized to do that and nobody doubts that its really Bob (his name is on the uniform, after all). Well one day, we see Bob trying to carry out 10,000 boxes at once. Hes authorized to access all the boxes at the warehouse, and we can double-confirm he really is Bob. But we might say “Hey Bob, whatcha doin?” and just make sure everything is above board.
"A user who typically accesses a database 10 records at a time probably doesn’t access 100,000 all of the sudden. Maybe they have a perfectly legitimate reason to do so, let’s verify with an authentication challenge or a second level approval to confirm they really need to perform that action. While we are at it, let’s send that to the alert operations team just in case." Authentication is an ongoing process, no just a 'front door' process. Secure information or assets should always have individual and discrete authentication, but this might be assumed based upon a previous login. This is a design paradigm behind the way Forticode has solved the authentication problem.
Great article.