How many times have you heard "identity is the new perimeter" and nodded sagely?
It's not hard to read something about a breach in the press every day anymore. Although there appears to be many more of these than in the past, I am never too sure if this is a product of digital growth and increased security awareness or if there truly is an increase in the number of breaches, all things otherwise been the same. Regardless, digitization is only growing and with it the need for security.
What is confusing is understanding were things failed or the root cause. No two organizations have the same organizational structure and responsibility matrix. Nor do two authors writing about the same breach have the same background or areas of expertise, and hence approach the root cause from the viewpoints of their experience. In fact. I have yet to see a security framework that I feel truly positions IAM correctly as it spans from HR to Sales (I will probably try to build one here at some point). When IAM functions are being performed by a different team, like network, cloud or application security, does that make it any less of an IAM issue? My number one concern for cloud security is that management thinks it changes the identity paradigm, and spin-off dedicated cloud teams. These folks usually have a great understanding of cloud features and DevOps and pipeline, and nearly always want to avoid legacy IAM “issues”, so avoid things like using the same IBoR, entitlement catalogue, PAM program, etc. The result is like the legacy space, IAM functionality is not built into the environment from day one and gets bolted on haphazardly as some necessary evil later on as a separate identity and access management silo.
The difference between a security breach and a security incident is in the case of a breach, data was accessed by someone (an identity) that should not have had access to the data. This can be accidental or deliberate, insider, outsider, etc. It could also be achieved through at least 1 (usually more) levels of the OSI and or application stack. An incident, on the other hand, includes disaster recovery, backup, denial of service and a host of other potential issues.
I have yet to work for a company that does not have more security audit finding related to Identity and Access Management (IAM) than any other area or security discipline and generally the statistics (regardless of source or authors' background) put PAM and IAM failures as the largest root-cause for breeches. This idea is not new with Gartner on record saying 95% of issues are IAM but has had some resistance to accept. Not wanting to put up my hand for more accountability than responsibility, I still feel the need to call it out. All breaches involve some failure in Identity and/or access management failure, regardless of if it is the IAM team or some other performing the function.
The breakdown is usually due to frameworks and organization structures that contain non-mutually exclusive disciplines. Let's take some examples here.
You have probably have heard about Network ACL’s. What does ACL stand for – you right, Access Control List. So when a role in a Web Application Firewall for AWS is “misconfigured”, is that a networking security issue or an IAM issue? Either way, it is a "Capital" offense. The responsibility for the beach should be attributed to the team that misconfigured the role. Who manages roles and access on a WAF and why is this any different than any other application? S3 bucket issue anybody?
Worried about Cross-Sight Scripting (or SQL injections etc). Per OWASP - “XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user.” In other words, its spoofing of the identity of the application.
UEBA (User and Entity Behaviour Analytics). How many organizations have logging and monitoring and incident response driving this strategy and how familiar or these teams with IAM roadmap and strategy?
Now it's important to note, I do not think traditional IAM role and mentality, can suddenly be made responsible for all areas of security. The real point of this post is Does ALL your security and infrastructure teams have enough IAM security knowledge and training? Is it easier to train your IAM staff in emerging technologies, or your emerging technology staff in IAM? Is "greenfield" an opportunity to do everything differently or learn from your past and capitalize on your existing infrastructure and processes honed and audited over the years?
What is promising is that today we have new movements like "The Identity Defined Security Alliance (IDSA)". Organizations that recognize it's not cloud security or configuration security or network security or application security, logging, and monitoring or incident response or IAM, but rather IAM in these areas that is the real challenge.
No comments:
Post a Comment