Framework/Configurations/SVT/SubscriptionCore/SubscriptionCore.json
|
{
"FeatureName": "SubscriptionCore", "Reference": "aka.ms/azsdktcp/sshealth", "IsManintenanceMode": false, "Controls": [ { "ControlID": "Azure_Subscription_AuthZ_Limit_Admin_Owner_Count", "Description": "Minimize the number of admins/owners", "Id": "SubscriptionCore110", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckSubscriptionAdminCount", "Recommendation": "There are 2 steps involved. You need to clean up (1) unexpected 'Classic Administrators'and (2) unexpected 'Owners' on the subscription. (1) Steps to clean up classic administrators (a) Go to https://manage.windowsazure.com/ --> settings tab -> administrators --> select and remove unwanted administrators using remove icon on the bottom ribbon (2) To remove unwanted members from the Owners group simply run the command 'Remove-AzureRmRoleAssignment -SignInName '{signInName}' -Scope '/subscriptions/{subscriptionid}' -RoleDefinitionName Owner'.", "Tags": [ "SDL", "Best Practice", "Automated", "AuthZ" ], "Enabled": true , "Rationale": "Each additional person in the Owner/Contributor role increases the attack surface for the entire subscription. The number of members in these roles should be kept to as low as possible." }, { "ControlID": "Azure_Subscription_AuthZ_Justify_Admins_Owners", "Description": "Justify all identities that are granted with admin/owner access on your subscription.", "Id": "SubscriptionCore111", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "ValidateCentralAccountsRBAC", "Recommendation": "There are 2 steps involved. You need to clean up (1) unexpected 'Classic Administrators'and (2) unexpected 'Owners' on the subscription. (1) Steps to clean up classic administrators (a) Go to https://manage.windowsazure.com/ --> settings tab -> administrators --> select and remove unwanted administrators using remove icon on the bottom ribbon (2) To remove unwanted members from the Owners group simply run the command 'Remove-AzureRmRoleAssignment -SignInName '{signInName}' -Scope '/subscriptions/{subscriptionid}' -RoleDefinitionName Owner'.", "Tags": [ "SDL", "Best Practice", "Automated", "AuthZ" ], "Enabled": true, "DataObjectProperties": [ "Owners.ObjectId", "Owners.RoleDefinitionId", "Owners.RoleDefinitionName", "Owners.Scope", "CoAdmins.RoleDefinitionName", "CoAdmins.Scope", "CoAdmins.SignInName" ] }, { "ControlID": "Azure_Subscription_AuthZ_Add_Required_Central_Accounts", "Description": "Mandatory central accounts must be present on the subscription", "Id": "SubscriptionCore120", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckApprovedCentralAccountsRBAC", "Recommendation": "Run command 'Set-AzSDKSubscriptionRBAC'. This command sets up all mandatory accounts on the target subscription. Run 'Get-Help Set-AzSDKSubscriptionRBAC -full' for more help. ", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true, "DataObjectProperties": [ "ObjectId", "ObjectType", "RoleDefinitionName", "Scope", "Enabled" ], "FixControl": { "FixControlImpact": "Medium", "FixMethodName": "AddRequiredCentralAccounts", "Parameters": { "Tags": "" } }, "Rationale": "Certain central accounts are expected to be present in all subscriptions to support enterprise wide functions (e.g., for security scans, cost optimization, etc.). Certain other accounts may also be required depending on special functionality enabled in a subscription (e.g., for Express Route-network support/compliance checks). The script checks for presence of such 'mandatory' and 'scenario-specific' accounts." }, { "ControlID": "Azure_Subscription_AuthZ_Remove_Deprecated_Accounts", "Description": "Deprecated/stale accounts must not be present on the subscription", "Id": "SubscriptionCore130", "ControlSeverity": "Critical", "Automated": "Yes", "MethodName": "CheckDeprecatedAccountsRBAC", "Recommendation": "Run command 'Remove-AzSDKSubscriptionRBAC'. You can remove all the deprecated accounts using this command. Run 'Get-Help Remove-AzSDKSubscriptionRBAC -full' for more help.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true, "DataObjectProperties": [ "ObjectId", "ObjectType", "Enabled" ], "FixControl": { "FixControlImpact": "Medium", "FixMethodName": "RemoveDeprecatedAccounts" }, "Rationale": "Further to the above RBAC check, some accounts were once deployed across subscriptions for some trial/pilot. These accounts should not be retained any more in any role. The script warns about presence of such 'deprecated' accounts as well." }, { "ControlID": "Azure_Subscription_AuthZ_Dont_Use_NonAD_Identities", "Description": "Do not grant permissions to external accounts (i.e., accounts outside the native directory for the subscription)", "Id": "SubscriptionCore140", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckNonAADAccountsRBAC", "Recommendation": "Run command Remove-AzureRmRoleAssignment -SignInName '{signInName}' -Scope '{scope}' -RoleDefinitionName '{role definition name}'. Run 'Get-Help Remove-AzureRmRoleAssignment -full' for more help.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "OwnerAccess", "GraphRead" ], "Enabled": true, "DataObjectProperties": [ "ObjectId", "RoleDefinitionId", "SignInName", "Scope" ], "Rationale": "All access to subscriptions, resource groups or individual resources at Microsoft must be gated via Microsoft corporate AAD (tenant) identities (replicated across from the corporate AD forest). The script checks that non-AD accounts (such as xyz@hotmail.com, pqr@outlook.com, etc.) are not granted permission at any level within a subscription." }, { "ControlID": "Azure_Subscription_AuthZ_Dont_Use_SVC_Accounts_No_MFA", "Description": "Service accounts cannot support MFA and should not be used for subscription activity", "Id": "SubscriptionCore150", "ControlSeverity": "High", "Automated": "No", "MethodName": "CheckSVCAccountsRBAC", "Recommendation": "Run command Remove-AzureRmRoleAssignment -SignInName '{signInName}' -Scope '{scope}' -RoleDefinitionName '{role definition name}'. Run 'Get-Help Remove-AzureRmRoleAssignment -full' for more help.", "Tags": [ "SDL", "TCP", "Manual", "AuthZ", "OwnerAccess", "GraphRead" ], "Enabled": true, "Rationale": "Service accounts are typically not multi-factor authentication capable. Quite often, sloppy use of service accounts by teams who own them (e.g., to login interactively on servers) exposes their credentials to attacks such as pass-the-hash, phishing, etc. As a result, using service accounts in any privileged role in a subscription exposes the subscription to credential-theft related risks. (In effect, the subscription becomes accessible after the single-factor protection is compromised?defeating the pervasive multi-factor authentication (MFA) requirement we aim to enforce.)" }, { "ControlID": "Azure_Subscription_AuthZ_Limit_CoAdmin_Count", "Description": "There should not be more than $($this.ControlSettings.NoOfClassicAdminsLimit) classic administrators", "Id": "SubscriptionCore160", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckCoAdminCount", "Recommendation": "You need to clean up any unexpected 'Classic Administrators'. Please follow these steps: (a) Logon to https://manage.windowsazure.com/ (b)Navigate to the Settings tab and click the administrators tab to list all administrators (c) Select the account that has to be removed and click on the Remove icon on the bottom ribbon (d) Perform this operation for all the co-administrators that need to be removed from the subscription.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ" ], "Enabled": true, "DataObjectProperties": [ "RoleDefinitionName", "Scope", "SignInName" ], "Rationale": "The v1 (ASM-based) version of Azure resource access model did not have much in terms of RBAC support. As a result, everyone who needed any access on a subscription or its resources had to be added to the Co-administrator role. These individuals are referred to as 'classic' administrators. In the v2 (ARM-based) model, this is not required at all and even the count of 2 classic admins currently permitted is for backward compatibility purposes. (Some Azure services are still migrating onto the ARM-based model so creating/operating on them needs 'classic' admin privilege.)" }, { "ControlID": "Azure_Subscription_AuthZ_Remove_Management_Certs", "Description": "Use of management certificates is not permitted.", "Id": "SubscriptionCore170", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckManagementCertsPresence", "Recommendation": "Logon to https://manage.windowsazure.com/ --> Settings tab --> Management Certificates tab --> Delete unwanted management certs using delete icon on the bottom ribbon.", "Tags": [ "SDL", "TCP", "Automated", "AuthZ", "OwnerAccess", "GraphRead" ], "Enabled": true, "Rationale": "Just like classic admins above, management certificates were used in the v1 model for script/tool based automation on Azure subscriptions. These management certificates are highly risky because the hygiene around protection of the private key for these certificates tends to be lapse. These certificates have no place in the current ARM-based model and should be immediately cleaned up if found on a subscription. (VS-deployment certificates from v1 timeframe are a good example of this.)" }, { "ControlID": "Azure_Subscription_Config_Azure_Security_Center", "Description": "Azure Security Center (ASC) must be correctly configured on the subscription", "Id": "SubscriptionCore180", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckAzureSecurityCenterSettings", "Recommendation": "Run command 'Set-AzSDKAzureSecurityCenterPolicies -SubscriptionId '<SubscriptionId>' -SecurityContactEmails '<comma separated emails ids>' -SecurityPhoneNumber '<contact number>'. Run 'Get-Help Set-AzSDKAzureSecurityCenterPolicies -full' for more help.", "Tags": [ "SDL", "TCP", "Automated", "Config", "SOX" ], "Enabled": true, "DataObjectProperties": [ "id", "properties.logCollection", "properties.recommendations", "properties.securityContactConfiguration.areNotificationsOn", "properties.securityContactConfiguration.securityContactEmails", "properties.securityContactConfiguration.securityContactPhone", "properties.securityContactConfiguration.sendToAdminOn" ], "FixControl": { "FixMethodName": "ConfigureSecurityCenter", "FixControlImpact": "Medium", "Parameters": { "SecurityContactEmails": "", "SecurityPhoneNumber": "" } }, "Rationale": "The Security Center feature in Azure helps with important central settings for the subscription such as configuring a security point of contact. It also supports key policy settings (e.g., is patching configured for VMs?, is threat detection enabled for SQL?, etc.) and alerts about resources which are not compliant to those policy settings. Correctly configuring ASC is critical as it gives a baseline layer of protection for the subscription and commonly used resource types." }, { "ControlID": "Azure_Subscription_Audit_Resolve_Azure_Security_Center_Alerts", "Description": "Pending Azure Security Center (ASC) alerts must be resolved", "Id": "SubscriptionCore190", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckAzureSecurityCenterAlerts", "Recommendation": "You need to address all active alerts on Azure Security Center. Please follow these steps: (a) Logon to https://portal.azure.com/ (b) Navigate to Security Center. (c) Click on Security Alerts under Detection category. (d) Take appropriate actions on all pending alerts.", "Tags": [ "SDL", "TCP", "Automated", "Audit" ], "Enabled": true, "Rationale": "Based on the policies that are enabled in the subscription, Azure Security Center raises alerts (which are typically indicative of resources that are not compliant with some baseline security protection). It is important that these alerts/actions are resolved promptly in order to eliminate the exposure to attacks." }, { "ControlID": "Azure_Subscription_AuthZ_Dont_Add_SPNs_as_Owner", "Description": "Service Principal Names (SPNs) should not be Owners or Contributors on the subscription", "Id": "SubscriptionCore210", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckSPNsRBAC", "Recommendation": "If this SPN needs access to your subscription, make sure you add it at the specific permission scope and role required for your scenario. For example, sometimes ‘Contributor’ access at ‘Resource Group’ scope might work. In other scenarios you may need ‘Reader’ access at ‘Subscription’ scope. Exact permission will vary based on your use case. If you want to remove the SPN, run command Remove-AzureRmRoleAssignment -ObjectId '{objectId}' -Scope '{scope}' -RoleDefinitionName '{role definition name}'. Run 'Get-Help Remove-AzureRmRoleAssignment -full' for more help.", "Tags": [ "SDL", "Best Practice", "Automated", "AuthZ", "OwnerAccess", "GraphRead" ], "Enabled": true, "DataObjectProperties": [ "ObjectId", "ObjectType", "RoleDefinitionId", "RoleDefinitionName", "Scope" ], "Rationale": "Just like AD-based service accounts, SPNs have a single credential and most scenarios that use them cannot support multi-factor authentication. As a result, adding SPNs to a subscription in 'Owners' or 'Contributors' roles is risky." }, { "ControlID": "Azure_Subscription_SI_Lock_Critical_Resources", "Description": "Critical application resources should be protected using a resource lock", "Id": "SubscriptionCore220", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckResourceLocksUsage", "Recommendation": "Run command 'New-AzureRmResourceLock'. Run 'Get-Help New-AzureRmResourceLock -full' for more help.", "Tags": [ "SDL", "Best Practice", "Automated", "SI" ], "Enabled": true, "Rationale": "A resource lock protects a resource from getting accidentally deleted. With proper RBAC configuration, it is possible to setup critical resources in a subscription in such a way that people can perform most operations on them but cannot delete them. These protective mechanisms can help ensure that important data is not lost by accidental/malicious deletion of such resources (and ensure that availability is not impacted)." }, { "ControlID": "Azure_Subscription_Config_ARM_Policy", "Description": "ARM policies should be used to audit or deny certain activities in the subscription that can impact security", "Id": "SubscriptionCore230", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckARMPoliciesCompliance", "Recommendation": "Run command 'Set-AzSDKARMPolicies'. Run 'Get-Help Set-AzSDKARMPolicies -full' for more help.", "Tags": [ "SDL", "Best Practice", "Automated", "Config" ], "Enabled": true, "DataObjectProperties": [ "policyDefinition", "policyDefinitionName", "scope", "enabled" ], "FixControl": { "FixMethodName": "ConfigureARMPolicies", "FixControlImpact": "Medium", "Parameters": { "Tags": "" } }, "Rationale": "The AzSDK subscription security setup configures a set of ARM policies which result in audit log entries upon actions that violate the policies. (For instance, an entry is generated if someone creates a v1 resource in a subscription.) The health check script checks for the presence of these policies are present in a subscription.(Note that ARM policies are specific to ARM operations on resources and different than ASC policies mentioned in the ASC check above. ASC policies are more general things such as 'enable auto-patchin', etc.)" }, { "ControlID": "Azure_Subscription_Audit_Configure_Critical_Alerts", "Description": "Alerts must be configured for critical actions on subscription and resources", "Id": "SubscriptionCore240", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckCriticalAlertsPresence", "Recommendation": "Run command 'Set-AzSDKAlerts'. Run 'Get-Help Set-AzSDKAlerts -full' for more help.", "Tags": [ "SDL", "Best Practice", "Automated", "Audit" ], "Enabled": true, "DataObjectProperties": [ "Name", "OperationName", "Severity", "Enabled" ], "FixControl": { "FixMethodName": "ConfigureAlerts", "FixControlImpact": "Medium", "Parameters": { "SecurityContactEmails": "", "Tags": "" } }, "Rationale": "The AzSDK subscription security setup configures Insights-based alerts for sensitive operations in the subscription. These use the Azure Monitor feature to generate email notifications when sensitive actions happen in a subscription (e.g., if someone adds a new person to the Owners group or if a new certificate is uploaded to a web site). The health check script verifies if all such alerts as defined in the AzSDK alert configuration have been configured on a subscription.(Note that the AzSDK supports setting up alerts via OMS as well. This is an alternate mechanism that may be used. In the OMS-based approach, Azure activity logs are piped into an OMS workspace and alerts are configured on the OMS side based on various conditions.)" }, { "ControlID": "Azure_Subscription_AuthZ_Custom_RBAC_Roles", "Description": "Do not use custom-defined RBAC roles", "Id": "SubscriptionCore250", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckCustomRBACRolesPresence", "Recommendation": "Run command 'Remove-AzureRmRoleDefinition -Id {id}'. Run 'Get-Help Remove-AzureRmRoleDefinition -full' for more help.", "Tags": [ "SDL", "Best Practice", "Automated", "AuthZ" ], "Enabled": true, "Rationale": "Custom RBAC role definitions are usually tricky to get right. A lot of threat modeling goes in when the product team works on and defines the different out-of-box security roles. As much as possible, teams should use the out-of-box roles for their RBAC needs. Using custom roles is treated as an exception and requires a rigorous review." }, { "ControlID": "Azure_Subscription_AuthZ_Classic_Resources", "Description": "Do not use any classics resources on a subscription", "Id": "SubscriptionCore260", "ControlSeverity": "Medium", "Automated": "Yes", "MethodName": "CheckPresenceOfClassicResources", "Recommendation": "Migrate each VM/ASM-based resource in your app to a corresponding v2/ARM-based resource. Refer link https://docs.microsoft.com/en-us/azure/virtual-machines/windows/migration-classic-resource-manager-overview for resource migration.", "Tags": [ "SDL", "Best Practice", "Automated", "AuthZ" ], "Enabled": true, "DataObjectProperties": [ "ResourceId", "SubscriptionId" ], "Rationale": "You should use new AzureRM (v2) resources as the ARM model provides stronger access control (RBAC) and auditing features." }, { "ControlID": "Azure_Subscription_SI_Dont_Use_Classic_VMs", "Description": "Do not use any classic virtual machines on your subscription.", "Id": "SubscriptionCore261", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckPresenceOfClassicVMs", "Recommendation": "Migrate each v1/ASM Virtual Machine in your subscription to a v2/ARM-based VM. Refer link https://docs.microsoft.com/en-us/azure/virtual-machines/windows/migration-classic-resource-manager-overview for resource migration.", "Tags": [ "SDL", "Best Practice", "Automated", "AuthZ", "SI" ], "Enabled": true, "DataObjectProperties": [ "ResourceId", "SubscriptionId" ] }, { "ControlID": "Azure_Subscription_NetSec_Justify_PublicIPs", "Description": "Verify the list of public IP addresses on your subscription", "Id": "SubscriptionCore270", "ControlSeverity": "High", "Automated": "Yes", "MethodName": "CheckPublicIpUsage", "Recommendation": "Verify the list of public IP addresses used and delete the unwanted and unused ones immediately! To delete run 'Remove-AzureRmPublicIpAddress -ResourceGroupName {ResourceGroupName} -Name {PublicIpAddressName}'. You might encounter an error if the public IP resource is associated with some other resource. Refer link: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-public-ip-address#view-change-settings-for-or-delete-a-public-ip-address for more details.", "Tags": [ "SDL", "Automated", "Access", "NetSec" ], "Enabled": true } ] } |