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"
        ],
        "Rationale": "Accounts that are a member of these groups without a legitimate business reason increase the risk for your subscription. By carefully reviewing and removing accounts that shouldn't be there in the first place, you can avoid attacks if those accounts are compromised."
      },
      {
         "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-AzSKSubscriptionRBAC'. This command sets up all mandatory accounts on the target subscription. Run 'Get-Help Set-AzSKSubscriptionRBAC -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., security scanning, cost optimization, etc.). Certain other accounts may also be required depending on special functionality enabled in a subscription (e.g., Express Route network management). The script checks for presence of such 'mandatory' and 'scenario-specific' accounts. If these are not present per the current baseline, there may be security/functionality impact for your subscription."
      },
      {
         "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-AzSKSubscriptionRBAC'. You can remove all the deprecated accounts using this command. Run 'Get-Help Remove-AzSKSubscriptionRBAC -full' for more help.",
         "Tags": [
            "SDL",
            "TCP",
            "Automated",
            "AuthZ"
         ],
         "Enabled": true,
         "DataObjectProperties": [
            "ObjectId",
            "ObjectType",
            "Scope"
         ],
         "FixControl": {
            "FixControlImpact": "Medium",
            "FixMethodName": "RemoveDeprecatedAccounts"
         },
          "Rationale": "Deprecated accounts are ones that were once deployed to your subscription for some trial/pilot initiative (or some other purpose). These are not required any more and are a standing risk if present in any role on the subscription."
      },
      {
         "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": "Non-AD accounts (such as xyz@hotmail.com, pqr@outlook.com, etc.) present at any scope within a subscription subject your cloud assets to undue risk. These accounts are not managed to the same standards as enterprise tenant identities. They don't have multi-factor authentication enabled. Etc."
      },
      {
         "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, teams who own these accounts don't exercise due care (e.g., someone may login interactively on servers using a service account exposing 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 attack vectors. (In effect, the subscription becomes accessible after just one factor (password) is compromised...this defeats the whole purpose of imposing the MFA requirement for cloud subscriptions.)"
      },
      {
         "ControlID": "Azure_Subscription_AuthZ_Limit_ClassicAdmin_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 granularity. 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. (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, management certificates were used in the v1 model for script/tool based automation on Azure subscriptions. These management certificates are risky because the (private) key management hygiene tends to be lax. These certificates have no role to play 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 these.)"
      },
      {
         "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-AzSKAzureSecurityCenterPolicies -SubscriptionId '<SubscriptionId>' -SecurityContactEmails '<comma separated emails ids>' -SecurityPhoneNumber '<contact number>'. Run 'Get-Help Set-AzSKAzureSecurityCenterPolicies -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 ASC suspects might be under attack or needing immediate attention). 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": "Consider using Azure resource locks to protect those resources in the subscription that you absolutely cannot afford to be deleted (by accident). You have to identify such resources and apply locks to them. 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. Resource locks can help ensure that important data is not lost by accidental/malicious deletion of such resources (thus ensuring 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-AzSKARMPolicies'. Run 'Get-Help Set-AzSKARMPolicies -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 audit event is generated if someone creates a v1 resource in a subscription.) These policies help by raising visibility to potentially insecure actions. "
      },
      {
         "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-AzSKAlerts'. Run 'Get-Help Set-AzSKAlerts -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 alerts notify the configured security point of contact about various sensitive activities on the subscription and its resources (for instance, adding a new member to subscription 'Owners' group or deleting a firewall setting or creating a new web app deployment, etc.)"
      },
      {
         "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 various 'out-of-box' roles ('Owners', 'Contributors', etc.). As much as possible, teams should use these roles for their RBAC needs. Using custom roles is treated as an exception and requires a rigorous review."
      },
    {
      "ControlID": "Azure_Subscription_SI_Classic_Resources",
      "Description": "Do not use any classic resources on a subscription",
      "Id": "SubscriptionCore260",
      "ControlSeverity": "Medium",
      "Automated": "Yes",
      "MethodName": "CheckPresenceOfClassicResources",
      "Recommendation": "Migrate each v1/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 several security enhancements such as: stronger access control (RBAC), better auditing, ARM-based deployment/governance, access to managed identities, access to key vault for secrets, AAD-based authentication, support for tags and resource groups for easier security management, etc."
    },
      {
         "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"
         ],
          "Rationale": "You should use new AzureRM (v2) resources as the ARM model provides several security enhancements such as: stronger access control (RBAC), better auditing, ARM-based deployment/governance, access to managed identities, access to key vault for secrets, AAD-based authentication, support for tags and resource groups for easier security management, etc."
      },
      {
         "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,
         "Rationale": "Public IPs provide direct access over the internet exposing a cloud resource to all type of attacks over the public network. Hence use of public IPs should be carefully scrutinized/reviewed."
      }
   ]
}