You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In looking at the account_changeschema, I was curious how MFA device (or factor) management should map to account change enums.
Changing passwords, as a sensitive operation, is elevated beyond basic CRUD changes to have its own enums: Password Change and Password Reset. This issue proposes that there should also be enum values representing the manipulation of MFA associated with an account. This type of information is useful to understand e.g. https://attack.mitre.org/techniques/T1098/005/
Many log reporting systems for MFA-capable products have differentiable event information for this type of change, for example:
Certain methods of User registered security info in Azure
My stab at what to add is:
MFA Factor Enabled
MFA Factor Disabled
But I'd welcome suggestions about the right language to use. I picked the noun MFA "factor" to be as broad as possible, and not assume factors are always additional devices. I picked the verbs "enable" / "disable" because I see that language used elsewhere in OCSF schema, whereas I do not see "registered" or "activated".
The text was updated successfully, but these errors were encountered:
alanisaac
changed the title
Add MFA factor registration and de-registration to account change enums
Add MFA factor enabled and disabled to account change enums
Aug 8, 2023
In looking at the
account_change
schema, I was curious how MFA device (or factor) management should map to account change enums.Changing passwords, as a sensitive operation, is elevated beyond basic CRUD changes to have its own enums:
Password Change
andPassword Reset
. This issue proposes that there should also be enum values representing the manipulation of MFA associated with an account. This type of information is useful to understand e.g. https://attack.mitre.org/techniques/T1098/005/Many log reporting systems for MFA-capable products have differentiable event information for this type of change, for example:
user.mfa.factor.activate
in OktaEnableMFADevice
in AWSUser registered security info
in AzureMy stab at what to add is:
MFA Factor Enabled
MFA Factor Disabled
But I'd welcome suggestions about the right language to use. I picked the noun MFA "factor" to be as broad as possible, and not assume factors are always additional devices. I picked the verbs "enable" / "disable" because I see that language used elsewhere in OCSF schema, whereas I do not see "registered" or "activated".
The text was updated successfully, but these errors were encountered: