Today we are excited to announce the latest adaptation of the Identity Defined Security Framework, which offers practical, vendor-neutral guidance on how to achieve identity-centric security. The update is the culmination of numerous whiteboards, conference calls, and a two-day Technical Working Group workshop in San Francisco, where over 15 IDSA member companies came together to discuss and refine the framework along with other topics we intend to cover in 2020.
The mission of the IDSA is to help organizations reduce the risk of data breaches through the adoption of identity-centric security strategies. We address the what, why and how of identity-centric security, by providing education and collective thought leadership through blogs, webinars, whitepapers, and customer stories. The Identity Defined Security Framework is an important product of our efforts and continues to evolve.
Our first foray into identity-centric security started two years ago when we identified 12 technology components (such as Access Management, DLP, PAM, etc.) and then came up with a comprehensive list of capabilities that a vendor should support to meet the inclusion requirement for each technology component. This exercise yielded a wealth of data regarding which IDSA member supported what capabilities. It helped identify potential integrations that could be achieved by combining different capabilities from different vendors to build security controls that addressed a specific customer use case.
In the initial state of this framework, we thought of use cases as practical uses of identity defined security in the enterprise space. Security controls were offerings that addressed an identity-defined use case in a given context, through an integrated set of capabilities spanning one or more technology components to enforce an identity-defined security policy. However, as our thinking evolved we realized that this approach had two shortcomings.
First, it relied on categorization of technology components by forcing companies to align their capabilities along predefined technology component boundaries, for example cloud access security broker. As the industry evolved, these boundaries have blurred and many companies, especially the emerging players, no longer fit in this traditional technology segmentation.
Second, the terms “security control” and to some extent “use case” are overloaded and have different meanings based on audience and context. Our solution to these shortcomings brings us to the framework we are publishing today.
This latest version of the framework is based on a taxonomy that meets the following requirements:
- It can not only scale but can also be tied back to other important security frameworks and approaches in the industry, such as Zero Trust, the NIST Cybersecurity framework or the HIPAA compliance framework. It puts a stronger focus on the role identity should play in these frameworks.
- It identifies specific goals, while illustrating different implementation approaches, and recognizing the need for flexibility in how outcomes can be achieved.
- It is future proof as the industry, requirements and vendors continue to evolve.
Based on these guiding principles we have published the following definitions:
The Identity Defined Security Framework provides practitioners with a set of fundamental building blocks along with blueprints and best practices that help achieve desired security outcomes to address the business need of their customers.
Identity Defined Security Outcome
An Identity Defined Security Outcome is a desired result that improves an organization’s security posture through identity-centric security and reduces the risk of a breach or failed audit.
Identity Defined Security Approach
Identity Defined Security Outcomes can be achieved through many different identity defined security implementation approaches. These approaches are well-defined patterns combining identity and security capabilities that help organizations leverage an identity context to improve security posture.
The foundation of an identity-centric approach to security is ideally a mature Identity and Access Management (IAM) program, but it’s not always sufficient in itself. A set of best practices defined by the IDSA focused on IAM fundamentals, serve as recommended hygiene tips related to the people, processes, as well as technology aspects of an IAM program. These hygiene tips can augment the foundation of an identity-centric approach to security.
Using these definitions, we have published an initial set of Identity Defined Security Outcomes and Approaches and will continue to build out this library. We encourage you to review, comment, and add to this list of Security Outcomes and help us improve our guidance.
Hear more in the webinar – IDS Framework: Achieving Security Outcomes through Identity.
About the Author: Asad Ali, IDSA Technical Working Group chair, is a technologist at Thales with 25 years of experience, and a track record of technical innovation, research, development, team management and product delivery in the digital security space. He currently serves in the CTO office of Thales cyber-security business unit, and has been an evangelist for company-wide adoption of user-centered design and usable security framework. He has also represented Thales in technology Standards bodies (W3C, OpenID Foundation), industry technology alliances (CSA, IDSA), and academia outreach programs. He holds 10 patents and has over 40 publications in peer-reviewed technical journals and international conferences. Asad received a Master’s degree in Engineering from MIT.