But protect/control is not all – we also need to focus on detect/respond. Unfortunately, as has been shown by the recent “Target hack”, current detect-and-respond approaches often fail because the well-intended tools are usually implemented without sufficient policy configurations. As a result, Security Incident and Event Management (SIEM) products produce way too many incidents for anyone to realistically get through and act upon within a useful timeframe (note that the “Target hack” SIEM detected the incident, but it was drowned out by hundreds of thousands of other incidents).
IAM needs to tie into monitoring and log aggregation to solve some of these issues: IAM’s incidents are usually more like “attempted policy violations”, for example if access to some information on some system was requested but denied in the specific context of the request. Knowing how such “white list” incidents relate to the policy makes it much easier for analysts to figure out criticality. Note that collecting other incidents the traditional way is also still necessary, but a lot of incidents can be discarded automatically thanks to the tie-in with the access policy.
Access federation and authentication federation
Federated identity management is a huge misnomer in IdM, and even federated access management usually is: What most products actually provide is “federated authentication management” based on cryptographic tokens that convey an authentication result. Turns out that this is different from actual “access federation”, sometimes referred to as “AuthoriZation Based Access Control” (ZBAC), and implemented – if done correctly – by using standards such as OAuth3. The idea is related but different from authentication federation in that the tokens provided by the access federation service are not tied to an authentication, but rather include permissions (authorizations) for the token holder. In the real-world the distinction would be (somewhat along the following lines):
- Authentication token: the use of a notary who certifies that a document is authentic (or a signature to have been made by the person claimed to be the signatory). The content of the certified document can be trusted as long as the notary is trusted.
- Access/Authorization token: A car unlocks with a car key. The car key is an authorization token, granting access to the car. Someone gives you a car key. The car does not care about who holds the car key as long as they hold the correct car key.
The assumption in both cases is that, as long as the producer of the token is trusted, the information conveyed in the token is also trusted.