IAM: Identity and Access Management on the Move

It was impossible not to notice the plethora of breaches that occurred throughout 2013. According to the Open Security Foundation’s “Data Breach QuickView” report, 2,164 incidents were responsible for compromising 822 million records in 2013.

While identity and access management (IAM) failures were not responsible for all of these incidents, “hacking” caused 1,293 incidents, which accounted for over 592 million compromised records. Fraud or social engineering accounted for 152 incidents that exposed over 102 million records. These areas saw attacks originating both internally and externally; when an insider breaks trust, they have the potential to cause significant damage.

Social Engineering and Hacking

There are well-documented and publicized cases of social engineering in which an individual obtains the security credentials of a colleague and engages in data acquisition in the unsuspecting colleague’s name. This is precisely what happened in the Edward Snowden case: He used his social engineering skills to persuade his colleagues to share with him their log-in credentials, which expanded his access beyond his privileges to that of his colleagues. We know how that turned out. With hacking causing 1,293 of the total incidents in 2013, resulting in the exposure of more than 592 million records, it is safe to assume that IAM capabilities have room for improvement regardless of company size or sector.

IAM should have deterred or prevented many of these events, and no doubt those conducting the damage assessments will be reviewing who accessed what, and how, which is at the heart of identity and access management.

• Who is accessing my system? User identity with certification, be it password or password with two-factor authentication, is an essential component of security best practices. The key is to be able to tell who your users are: Are they part of the active directory associated with the enterprise network? Are they coming into the network via an external gateway, an extranet connection or within the intranet? Has access been authorized for these individuals?
• Are they coming from an expected IP address? Is the IP address from which the individual has an established pattern of usage the same IP address with which the individual is currently accessing the network or data stores? If not, the IAM should invoke additional security protocols, pulling from either knowledge-based questions or additional challenges from the support team. While this check might be “spoofable,” it can also serve as an early indicator that an individual’s credentials are on the move.
• Are they using the device I expect? Indexing the devices (laptops, tablets, smartphones, etc.) with which users access the network so that they can be identified and associated with a specific user or group of users adds a level of security by providing the opportunity to challenge or permit access based on the review of additional information (e.g., IP address).
• Are they arriving at the expected time? Schedules or activity windows should be relatively predictable, though some are more eclectic than others. If you know that employees normally only access the network during the 9-5 workday, seeing them log in during “off hours” should trigger an anomaly. Checking the anomaly may be as simple as verifying the IP address and device identity.
• Are they accessing permitted areas? Are individuals using their credentials to enter areas within the enterprise to which they have been granted access? Are they attempting to access areas to which their privileges have not been extended? Following these failed attempts, does the individual continue to “probe,” or do they engage the protocol to acquire permitted access to the restricted data?

All of the above is possible, though it does beg the question of whether our identity and access management systems are obsolete.

Identity and Access Management: Obsolete or Evolving?

IAM are not obsolete, but they are certainly evolving and are on the move. Convenience trumps security with regularity, and if the anomaly checks cause undue inconvenience, both those securing the system and those being regulated will develop work-around methodologies. Therein lies part of the conundrum: Ensuring that the identity of the individual goes through the necessary verifications and validations while not unduly causing a degradation in the experience. While some steps may add a slight degree of latency, the key to garnering acceptance by those most affected — the users — requires assurance that the users understand the “why” behind the IAM challenges and access checks; the 822 million compromised records in 2013 is a good conversation starter.