Identity Defined Security Alliance

Putting Identity at the Center of Security

2020 Framework Modification - Security Control Methods (now called Security Outcomes)

This topic is to consolidate all IDSA security control methods (SCM) submitted by the membership as part of the Framework modifications happening in 2020. Please reply to this topic with your SCM submission - please use the template below, which is also included in the Security Control Method Process. IDSA Security Control Method Process.pdf (406.3 KB)

Use Case Addressed << Explain what use case will be addressed by this Security Control Method. It is possible, in fact likely, that the same use case can be addressed by multiple security control methods. We therefore start with use cases so that multiple Security Control Methods can be created under them, as needed >>
Title << Enter a short title of the Security Control Method >>
Short Description << Enter a short description of what the Security Control Method is about. This text will go into the main tile for security control method when posted on IDSA portal >>
Value Description << Explain what value/benefit this security control method brings once it is implemented >>
Technology Components << List the technology components for this security control method. At least one component should be related to Identity. Submitter can specify “Other” in case none of the existing technology components match >>
Control Description << Describe how the control method works, i.e. what happens when the control is implemented >>
Pre-requisites << Explain what pre-requisites, if any, must be in place before implementing the Control >>
Capabilities (optional) << For each of the technology components mentioned above, optionally list the corresponding capabilities that will have to be integrated to implement this security control method. This section can serve as a worksheet to identify potential members that will eventually support the security control method. It should be used only if this information will help identify companies, otherwise the list of capabilities is not required. Furthermore, it should be understood that support of a particular capability does not necessarily imply support of the complete security control method >>
Supporting Members << For each of the technology components mentioned above, list member companies that not only support the corresponding component specific capabilities relevant for this security control method, but also offer the inter-component interoperability, configurability, integration necessary to make the control work. Provide evidence or references that can validate support for these capabilities. The submitter of security control method should work with rest of IDSA members to determine if they support it. Alternative, once a security control method is posted as draft, member companies can point out capabilities they support, to add their name. >>
Context Transfer (optional) << What if any Context Transfer is required to enable this Control? >>
IDSA Match (optional) << Explain how does this security control method fit into IDSA framework/approach (e.g., IDSA/Zero Trust…ISDA/NIST, IDSA/CARTA) >>

During our TWG last week, this template was refined a bit further - use cases have been renamed “identity defined security outcomes.” For each outcome, there are a myriad of implementation approaches or identity defined security implementation approaches. The following 16 security outcomes will be focused on initially. Would love to hear from members and from the community - please post your thoughts/additions on this initial set.

  • User accounts and entitlements are granted through governance-driven provisioning
  • Privileged accounts and entitlements are granted through governance-driven provisioning
  • User accounts and entitlements are removed through governance-driven de-provisioning
  • Privileged accounts and entitlements are removed through governance-driven de-provisioning
  • Application access is transparently audited and enforced
  • Device characteristics are used for authentication
  • Expected user behavior is used for authentication
  • All privileged access requires MFA
  • Access is revoked upon detection of high risk event associated with that identity
  • Re-attestation is triggered based on a high risk event
  • All privileged access is periodically attested
  • Access to sensitive data is periodically attested
  • All privileged access rights are continuously discovered
  • All user access rights are continuously discovered
  • User access rights are granted according to the Principle of Least Privilege
  • Privileged access rights are granted according to the Principle of Least Privilege