- Overview
- Setting up Continuous Assurance - Step by Step
- Continuous Assurance - how it works (under the covers)
- Updating an existing Continuous Assurance setup
- Removing a Continuous Assurance setup
- Getting details about a Continuous Assurance setup
- Continuous Assurance (CA) - 'Central Scan' mode
- FAQ
The basic idea behind Continuous Assurance (CA) is to setup the ability to check for "drift" from what is considered a secure snapshot of a system. Support for Continuous Assurance lets us treat security truly as a 'state' as opposed to a 'point in time' achievement. This is particularly important in today's context when 'continuous change' has become a norm.
There can be two types of drift:
- Drift involving 'baseline' configuration: This involves settings that have a fixed number of possible states (often pre-defined/statically determined ones). For instance, a SQL DB can have TDE encryption turned ON or OFF…or a Storage Account may have auditing turned ON however the log retention period may be less than 365 days.
- Drift involving 'stateful' configuration: There are settings which cannot be constrained within a finite set of well-known states. For instance, the IP addresses configured to have access to a SQL DB can be any (arbitrary) set of IP addresses. In such scenarios, usually human judgment is initially required to determine whether a particular configuration should be considered 'secure' or not. However, once that is done, it is important to ensure that there is no "stateful drift" from the attested configuration. (E.g., if, in a troubleshooting session, someone adds the IP address of a developer machine to the list, the Continuous Assurance feature should be able to identify the drift and generate notifications/alerts or even trigger 'auto-remediation' depending on the severity of the change).
Besides 'drift tracking' there are also two other aspects of "staying secure" in operations. First of them is the simple concept that if new, more secure options become available for a feature, it should be possible to detect that a particular application or solution can benefit from them and notify/alert the owners concerned. In a way this can be thought of as facilitating "positive" security drift. The other aspect is about supporting "operational hygiene". In this area, we will add the ability to remind an app team about the security hygiene tasks that they need to periodically perform (key rotation, access reviews, removing inactive/dormant power users, etc.). These two capabilities are on our backlog for H1-FY18.
Note: If you have already installed Continuous Assurance using a version prior to 2.2.0, you should run 'Install-AzSKContinuousAssurance' command again by following the steps in the next section.
In this section, we will walk through the steps of setting up a subscription and application(s) for Continuous Assurance coverage.
To get started, we need the following:
-
The user setting up Continuous Assurance needs to have 'Owner' access to the subscription. (This is necessary because during setup, AzSK adds the service principal runtime account as a 'Reader' to the subscription.)
-
Target OMS WorkspaceID* and SharedKey. (The OMS workspace can be in a different subscription, see note below)
*Note CA leverages an OMS repository for aggregating security scan results, you must determine which OMS workspace you will use to view the security state of your subscription and applications (If you don't have an OMS repository please follow the steps in Setting up the AzSK OMS Solution ). This can be a single workspace that is shared by multiple applications which may themselves be in different subscriptions. Alternately, you can have an OMS workspace that is dedicated to monitoring a single application as well. (Ideally, you should use the same workspace that is being used to monitor other aspects like availability, performance, etc. for your application.)
Step-1: Setup
0. Setup the latest version of the AzSK following the installation instructions for your organization. (For MSIT use https://aka.ms/azsdkdocs).
- Open the PowerShell ISE and login to your Azure account (using Login-AzureRmAccount).
- Run the 'Install-AzSKContinuousAssurance' command with required parameters given in below table.
Install-AzSKContinuousAssurance -SubscriptionId <SubscriptionId> `
[-AutomationAccountLocation <AutomationAccountLocation>] `
-ResourceGroupNames <ResourceGroupNames> `
-OMSWorkspaceId <OMSWorkspaceId> `
-OMSSharedKey <OMSSharedKey> `
[-AltOMSWorkspaceId <AltOMSWorkspaceId>] `
[-AltOMSSharedKey <AltOMSSharedKey>] `
[-WebhookUrl <WebhookUrl>] `
[-WebhookAuthZHeaderName <WebhookAuthZHeaderName>] `
[-WebhookAuthZHeaderValue <WebhookAuthZHeaderValue>] `
[-ScanIntervalInHours <ScanIntervalInHours>] `
[-AzureADAppName <AzureADAppName>]| Param Name | Purpose | Required? | Default value | Comments |
|---|---|---|---|---|
| SubscriptionId | Subscription ID of the Azure subscription in which an Automation Account for Continuous Assurance will be created | TRUE | None | |
| AutomationAccountLocation | (Optional) The location in which this cmdlet creates the Automation Account | FALSE | EastUS2 | To obtain valid locations, use the Get-AzureRMLocation cmdlet |
| ResourceGroupNames | Comma separated list of resource groups within which the application resources are contained. | TRUE | None | |
| OMSWorkspaceId | Workspace ID of OMS which is used to monitor security scan results | TRUE | None | |
| OMSSharedKey | Shared key of OMS which is used to monitor security scan results | TRUE | None | |
| AltOMSWorkspaceId | (Optional) Alternate Workspace ID of OMS to monitor security scan results | FALSE | None | |
| AltOMSSharedKey | (Optional) Shared key of Alternate OMS which is used to monitor security scan results | FALSE | None | |
| WebhookUrl | (Optional) All the scan results shall be posted to this configured webhook | FALSE | None | |
| WebhookAuthZHeaderName | (Optional) Name of the AuthZ header (typically 'Authorization') | FALSE | None | |
| WebhookAuthZHeaderValue | (Optional) Value of the AuthZ heade | FALSE | None | |
| ScanIntervalInHours | (Optional) Overrides the default scan interval (24hrs) with the custom provided value | FALSE | None | |
| AzureADAppName | (Optional) Name for the Azure Active Directory(AD) Application that will be created in the subscription for running the runbooks. | FALSE | None |
More about the 'AzureADAppName' parameter:
The AzureADAppName parameter is optional. This represents the runtime account that will be used by the CA runbook to scan the subscription/resources.
- If the user does not specify a parameter, then CA will:
- Find if there is an existing AAD app (from a previous attempt to setup CA) in the subscription that can be reused.
- Else, create a fresh Azure AD app on behalf of the user (in this case the user must have permission to create apps in the tenant).
- If the user specifies an AzureADAppName, then CA will try to find the AAD application corresponding to that name and attempt to use it (in this case the user must have 'Owner' permission on the specified app name).
Here's a quick summary of the permissions required for the user who sets up CA:
- "Owner" access on the subscription
- Ability to create an AAD app in the tenant (this app is used as the runtime account for scanning via the CA runbook)
- "Owner" access to the AAD app if the user specifies one (or CA internally finds a previously created one)
Note-1: Completion of this one-time setup activity can take up to 2 hours. (This is because one of the things that setup does is download and add PowerShell modules for Azure PS library and for AzSK. This is a slow and sometimes flaky process and, as a result, the setup internally retries failed downloads. The Azure Automation product team is aware of this challenge and are working on a resolution.)
Note-2: Due to the complexity of various dependent activities involved, there are multiple places where CA setup can run into issues. It is important to verify that everything has worked without hiccups. Please review and ascertain each of the "Verifying" steps below carefully.
Step-2: Verifying that CA Setup is complete
1: In the Azure portal, select the application subscription that was used above and search for resources of type Automation Account. You should see an Automation Account created by the name 'AzSKContinuousAssurance'. Clicking on it will display the contents of the Automation Account (something that looks like the below, the counts shown may vary a little):
2: Click on 'Runbooks' tile. It should show the following runbook:
3: Click on 'Schedules' tile. It should show the scheduling details of runbook. You can change the schedule timings according to your need. Default schedule is created as below. First job will run ten minutes after the installation:
4: Click on 'Run As Accounts' tile. It should show the following account:
Step-3: Verifying that all required modules are downloaded successfully (after about two hours of starting the installation)
1: Click on the 'Modules' tile for the Automation Account. 'AzSK' module should be listed there. 'Status' column value for all modules should be 'Available' as below.
Step-4: Verifying CA Runbook execution and OMS connectivity
Once CA setup and modules download are completed successfully, the runbooks will automatically execute periodically (once a day) and scan the subscription and the specified resource groups for the application(s) for security issues. The outcomes of these scans will get stored in a storage account created by the installation (format : azsk<YYYYMMDDHHMMSS> e.g. azsk20170505181008) and follows a similar structure as followed by standalone SVT execution (CSV file, LOG file, etc.).
The results of the control evaluation are also routed to the OMS repository for viewing via a security dashboard.
Let us verify that the runbook output is generated as expected and that the OMS connectivity is setup and working correctly.
1: Verify that CSV file and LOG file are getting generated as expected.
- Go to Storage Explorer and look for a storage account with a name in azsk format in your subscription in 'AzSKRG' resource group.
- Find a container called 'azskexecutionlogs' in this storage account.
- There should be a ZIP file named using a timestamp based on the date time for the manual execution in this container (most likely the ZIP file with the most recent creation date).
- Download the ZIP file and extract its contents locally. The folder structure will be similar to how SVTs/Subscription Health scan generate when run locally.
- In a single zip file you will find two folders (name format: Timestamp). One folder contains reports of Subscription Health scan and another folder contains reports of application(s) resource groups security scan.
2: Verify that data is being sent to the target OMS workspace
- Go to the OMS dashboard that we used to setup CA above.
- In the 'Search' window, enter Type=AzSK_CL Source_s=CA. (Source_s used to be 'CC' in the past.)
- You should see results similar to the below:
Once CA is setup in the subscription, an app team can start leveraging the OMS Solution from AzSK as a one-stop dashboard for visibility of security state. Please follow the steps in the OMS solution setup (in Alerting & Monitoring sub-section of this notebook) to enable that part.
The CA feature is about tracking configuration drift. This is achieved by enabling support for running AzSK SVTs/SS-Health via automation runbook.
The CA installation script that sets up CA creates the following resources in your subscription:
- Resource group (Name : AzSKRG) :- To host all the Continuous Assurance artifacts
- Storage account (Format : azskYYYYMMDDHHMMSS) :- To store the daily results of CA scans. The storage account is named with a timestamp-suffix applied to 'azsk'(e.g. azsk20170420111140)
- Azure AD App and Service Principal :- This is used as the runtime identification of the automation runbook. Adds SPN to 'Reader' role on the subscription and contributor role on the resource group containing Automation Account.
- Automation Account (Name : AzSKContinuousAssurance) :- Creates the following assets within the Automation Account,
- Runbook (Name : Continuous_Assurance_Runbook) - To download/update Azure/AzSK modules and scan subscription/app resource groups
- Variables
- AppResourceGroupNames
- OMSWorkspaceId
- OMSSharedKey
- ReportLogsStorageAccountName
- Azure Run As Account - To authenticate runbook at runtime
This account uses below certificate and connection.
AzureRunAsCertificate - This certificate gets expired after six months of installation
AzureRunAsConnection - This connection is created using service principal with a AzureRunAsCertificate - Two schedules to trigger the runbook :-
- CA_Scan_Schedule - This is to trigger job to scan subscription and app resource groups
- CA_Helper_Schedule - This is a temporary schedule created by runbook to retry download of modules
- Modules - Downloaded by the runbook
Once CA is setup in the subscription, an app team can start leveraging the OMS Solution from AzSK as a one-stop dashboard for visibility of security state. Occasionally, you may also feel the need to tweak the configuration of CA. See the "Update" section below about how to do that.
The 'Update-AzSKContinuousAssurance' command can be used to make changes to a previously setup CA configuration. For instance, you may use it to:
- update the target resource groups to include in the scanning
- switch the OMS workspace information that CA should use to send control evaluation events to
- use a different AAD SPN for the runbooks
- etc.
To do any or all of these:
- Open the PowerShell ISE and login to your Azure account (using Login-AzureRmAccount).
- Run the 'Update-AzSKContinuousAssurance' command with required parameters given in below table.
Update-AzSKContinuousAssurance -SubscriptionId <SubscriptionId> `
[-ResourceGroupNames <ResourceGroupNames>] `
[-OMSWorkspaceId <OMSWorkspaceId>] `
[-OMSSharedKey <OMSSharedKey>] `
[-AltOMSWorkspaceId <AltOMSWorkspaceId>] `
[-AltOMSSharedKey <AltOMSSharedKey>] `
[-WebhookUrl <WebhookUrl>] `
[-WebhookAuthZHeaderName <WebhookAuthZHeaderName>] `
[-WebhookAuthZHeaderValue <WebhookAuthZHeaderValue>] `
[-ScanIntervalInHours <ScanIntervalInHours>] `
[-AzureADAppName <AzureADAppName>] `
[-FixRuntimeAccount] `
[-FixModules] `
[-RenewCertificate]| Param Name | Purpose | Required? | Default Value | Comments |
|---|---|---|---|---|
| SubscriptionId | Subscription ID of the Azure subscription in which Automation Account exists | TRUE | None | |
| ResourceGroupNames | Use this parameter if you want to update the comma separated list of resource groups within which the application resources are contained. The previously configured list of RGs will be replaced with the one provided here. | FALSE | None | |
| OMSWorkspaceId | Use this parameter if you want to update the workspace ID of OMS which is used to monitor security scan results | FALSE | None | |
| OMSSharedKey | Use this parameter if you want to update the shared key of OMS which is used to monitor security scan results | FALSE | None | |
| AltOMSWorkspaceId | (Optional) Alternate Workspace ID of OMS to monitor security scan results | FALSE | None | |
| AltOMSSharedKey | (Optional) Shared key of Alternate OMS which is used to monitor security scan results | FALSE | None | |
| WebhookUrl | (Optional) All the scan results shall be posted to this configured webhook | FALSE | None | |
| WebhookAuthZHeaderName | (Optional) Name of the AuthZ header (typically 'Authorization') | FALSE | None | |
| WebhookAuthZHeaderValue | (Optional) Value of the AuthZ header | FALSE | None | |
| ScanIntervalInHours | (Optional) Overrides the default scan interval (24hrs) with the custom provided value | FALSE | None | |
| AzureADAppName | Use this parameter if you want to update the connection (used for running the runbook) with new AD App and Service principal | FALSE | None | This is useful if existing connection is changed/removed by mistake |
| FixRuntimeAccount | Use this switch to fix CA runtime account in case of below issues.
|
FALSE | None | |
| FixModules | Use this switch in case 'AzureRm.Automation' module extraction fails in CA Automation Account. | FALSE | None | |
| RenewCertificate | Renews certificate credential of CA SPN if the caller is Owner of the AAD Application (SPN). If the caller is not Owner, a new application is created with a corresponding SPN and a certificate owned by the caller. CA uses the updated credential going forward. | FALSE | None |
- Open the PowerShell ISE and login to your Azure account (using Login-AzureRmAccount).
- Run the 'Remove-AzSKContinuousAssurance' command as below.
Remove-AzSKContinuousAssurance -SubscriptionId <SubscriptionId> [-DeleteStorageReports] | Param Name | Purpose | Required? | Default value | Comments |
|---|---|---|---|---|
| SubscriptionId | Subscription ID of the Azure subscription in which Automation Account exists | True | None | |
| DeleteStorageReports | Add this switch to delete AzSK execution reports from storage account. This will delete the storage container where reports are stored. Generally you will not want to use this option as all previous scan reports will be purged. | False | None |
- Open the PowerShell ISE and login to your Azure account (using Login-AzureRmAccount).
- Run the 'Get-AzSKContinuousAssurance' command as below.
- Result will display the current status of CA in your subscription. If CA is not working as expected, it will display remediation steps else it will display a message indicating CA is in healthy state.
- Once you follow the remediation steps, run the command again to check if anything is still missing in CA setup. Follow the remediation steps accordingly until the CA state becomes healthy.
Get-AzSKContinuousAssurance -SubscriptionId <SubscriptionId> Note: This command is compatible only for Automation Account installed after 5th May, 2017 AzSK release.
The description so far has focused on setting up CA in a single subscription. When you have multiple subscriptions, you can setup CA individually for scanning each subscription. Alternatively, you can also setup CA in what is called a 'central scan' mode. The 'central scan' mode is more suited for scenarios where a single central team wants to exercise oversight of several subscription using a single master subscription for scanning. This section describes this mode and how to set it up further.
Unlike the 'individual subscription' mode where each subscription get its own instance of CA automation account, runbook, scan logs etc., the 'central scan' mode uses a single 'master' subscription to perform all scanning activities from. Use the following steps to setup 'central scan' mode:
- The user executing this command should have "Owner" access on all the subscriptions that are being enabled for central scanning mode including the master subscription.
- User should have the latest version of the DevOps Kit installed on the machine (>= AzSK v3.1.x)
- [Optional: Have a custom DevOps Kit policy setup for your org. This would provide more capabilities to control the scanning behavior. (See here for more details on org policy.)
When setting up CA with central scan mode, you have a choice regarding division of the scanning workload between automation accounts. You can choose to have all target subscriptions scanned via a single automation account or you can configure multiple automation accounts to divide the scanning workload amongst them by assigning each automation account a subset of the subscriptions for scaning. These two options and when to choose which one are covered below:
With this option, a single automation account will get created in the host (master) subscription, which will scan all the target subscriptions. This mode is suitable for scanning up to a max of 40-50 subscriptions. (As the number of target subscriptions increases, the frequency of scan for each subscription reduces. Ideally each subscription should get scanned at least once per day. The multiple Automation account option might help if the count of subscriptions to be scanned is higher.)
This can be achieved by adding extra params to the existing CA command as shown in the command below:
$SubscriptionId = '<subscriptionId>'
$ResourceGroupNames = '*' #This should always be '*' for Central Scan mode CA
$OMSWorkspaceId = '<omsWorkspaceId>'
$OMSSharedKey = '<omsSharedKey>'
$TargetSubscriptionIds = '<SubId1, SubId2, SubId3...>' #Need to provide comma separated list of all subscriptionId that needs to be scanned.
Install-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -TargetSubscriptionIds $TargetSubscriptionIds
-ResourceGroupNames $ResourceGroupNames -OMSWorkspaceId $OMSWorkspaceId -OMSSharedKey $OMSSharedKey -CentralScanMode
[-LoggingOption '<CentralSub|IndividualSubs>'] [-SkipTargetSubscriptionConfig]The table below lists only the parameters that are mandatory or have specific needs when used in the central scan mode CA setup. For the overall set of parameters, please review the CA parameters table above.
| Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central subscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| TargetSubscriptionIds | Comma separated list of subscriptionIds that needs to be scanned by the central subscription. Host subscription is always appended by default. No need to pass that value in this param | True | The user executing this command should be owner on these subscriptions. | |
| ResourceGroupNames | Comma separated list of ResourceGroupNames | True | Since you are planning to run in the central mode, you should use * as its value. This is because you need not have the same RG across all the subscriptions | |
| OMSWorkspaceId | All the scanning events will be send to this OMSWorkspace. This will act as central monitoring dashboard | True | ||
| OMSSharedKey | OMSSharedKey for the central monitoring dashboard | True | ||
| LoggingOption | "IndividualSubs/CentralSub". This provides the capability to users to store the CA scan logs on central subscription or on individual subscriptions | False | CentralSub | |
| SkipTargetSubscriptionConfig | (Optional) Use this switch if you dont have the owner permission on the target sub. This option assumes you have already one all the required configuration on the target sub. Check the note below | False | ||
| CentralScanMode | Mandatory switch to specify in central scan mode | True |
Note: If you are using switch -SkipTargetSubscriptionConfig, then it assumes you have done all the required configuration on the target subscriptions. Like, adding the CA SPN as Reader on target sub, creating AzSK RG and a storage account name starting with azsk, grant contributor role to CA SPN on AzSKRG. If any of these steps are not done, then central scan automation account will skip those target subscriptions while scan.
In case you want to add/edit subscriptions covered via central scanning mode you can use Update-AzSKContinuousAssurance as shown below. (All other CA configuration settings can also be updated as described in Update-AzSKContinuousAssurance earlier in this document.)
$SubscriptionId = '<subscriptionId>'
$OMSWorkspaceId = '<omsWorkspaceId>'
$OMSSharedKey = '<omsSharedKey>'
$TargetSubscriptionIds = '<SubId1, SubId2, SubId3...>' #Need to provide comma separated list of all subscriptionId that needs to be scanned.
Update-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -TargetSubscriptionIds $TargetSubscriptionIds -CentralScanMode -FixRuntimeAccount
[-LoggingOption <CentralSub|IndividualSubs>] All other parameters as described in the main Update-AzSKContinuousAssurance parameters table apply.
| Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central subscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| TargetSubscriptionIds | Comma separated list of subscriptionIds that needs to be scanned by the central subscription. It would always append the values provided in this param to the current scanning list. | True | The user executing this command should be owner on these subscriptions. | |
| LoggingOption | "IndividualSubs/CentralSub" | False | Only provide if you want to change the logging option | |
| FixRuntimeAccount | This will correct all the permissions issues related to the scanning account | False | Provide this switch only when you want to add new subscriptions for central scanning mode | |
| CentralScanMode | It is mandatory to use CentralScanMode switch | True |
You could run the command below. It would diagnose the Continuous Assurance Automation account running under central subscription
$SubscriptionId = '<subscriptionId>'
Get-AzSKContinuousAssurance -SubscriptionId $SubscriptionId [-ExhaustiveCheck]| Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central SubscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| ExhaustiveCheck | (Optional) By appending this switch it would check whether all the modules installed in central automation account are up to date | False | Only include if default diagnosis is not resulting in any issue |
In case you want to
(a) unregister some subs from central scanning mode, or
(b) to delete the scan logs, or
(c) to remove the whole automation account
$SubscriptionId = '<subscriptionId>'
Remove-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -DeleteStorageReports -CentralScanMode | Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central SubscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| TargetSubscriptionIds | Comma separated list of target subIds which will be un-registered from the central scanning mode. | False | ||
| DeleteStorageReports | Deletes all the scan logs from the azsk storage account based on the logging option and value provided in the target subscription. If used with out CentralScanMode switch, it would remove all logs from the host sub central storage account. | False | Only include if default diagnosis is not resulting in any issue | |
| CentralScanMode | It is mandatory to use CentralScanMode switch | True |
Note If just subscrptionId is passed, then it would check if the host sub is in central scanning mode, if so, user needs to pass CentralScanMode switch specifically. In these scenarios, it would remove the whole automation account from host sub.
If you are trying to scan multiple target subscriptions, then scanning all of them using a single Automation account can reduce the scan frequency. In such scenarios, you can use this approach to categorize your subscriptions into batches and scan these batches using multiple independent automation accounts with in the same host/central subscription. In this scenario, all your logs, scanning configuration, attestation data is persisted under core AzSKRG and each automation account will have its own dedicated RG.
When you have more than about 40-50 subscriptions to scan, it is better to use multiple Automation accounts option of the Central Scan mode. You need to split the overall set of target subscriptions into multiple groups and then decide names to use for the Automation account and the resource groups that will host the CA for each group. Once this grouping and naming is done, you simply run the central scan mode CA setup command once for each group (with additional parameters identifying the Automation account name and the resource group that will serve as the host for scanning the respective group).
$SubscriptionId = '<subscriptionId>'
$ResourceGroupNames = '*' #This should always be '*' for Central Scan mode CA
$OMSWorkspaceId = '<omsWorkspaceId>'
$OMSSharedKey = '<omsSharedKey>'
$TargetSubscriptionIds = '<SubId1, SubId2, SubId3...>' #Need to provide comma separated list of all subscriptionId that needs to be scanned.
$AutomationAccountLocation = '<location>'
$AutomationAccountRGName = '<RGName>' # e.g. AzSK-Category-ScanRG01
$AutomationAccountName = '<accountName> # e.g. AzSKScanningAccount01
> **Note** You should use the unique names for AutomationAccountRG and AutomationAccountName to avoid any conflicts while setup
Install-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -TargetSubscriptionIds $TargetSubscriptionIds
-ResourceGroupNames $ResourceGroupNames -OMSWorkspaceId $OMSWorkspaceId -OMSSharedKey $OMSSharedKey
-AutomationAccountRGName $AutomationAccountRGName -AutomationAccountName $AutomationAccountName -AutomationAccountLocation $AutomationAccountLocation -CentralScanMode
[-LoggingOption '<CentralSub|IndividualSubs>'] [-SkipTargetSubscriptionConfig]| Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central subscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| TargetSubscriptionIds | Comma separated list of subscriptionIds that needs to be scanned by the central subscription. Host subscription is always appended by default. No need to pass that value in this param | True | The user executing this command should be owner on these subscriptions. | |
| ResourceGroupNames | Comma separated list of ResourceGroupNames | True | Since you are planning to run in the central mode, you should use * as its value. This is because you need not have the same RG across all the subscriptions | |
| OMSWorkspaceId | All the scanning events will be send to this OMSWorkspace. This will act as central monitoring dashboard | True | ||
| OMSSharedKey | OMSSharedKey for the central monitoring dashboard | True | ||
| AutomationAccountLocation | (Optional) Location where the AutomationAccount to be created | false | ||
| AutomationAccountRGName | Name of ResourceGroup which will hold the scanning automation account | False | e.g. AzSK-Category-ScanRG01 | |
| AutomationAccountName | All the scanning events will be send to this OMSWorkspace. This will act as central monitoring dashboard | False | e.g. AzSKScanningAccount01 | |
| LoggingOption | "IndividualSubs/CentralSub". This provides the capability to users to store the CA scan logs on central subscription or on individual subscriptions | False | CentralSub | |
| SkipTargetSubscriptionConfig | (Optional) Use this switch if you dont have the owner permission on the target sub. This option assumes you have already one all the required configuration on the target sub. Check the note below | False | ||
| CentralScanMode | Mandatory switch to specify in central scan mode | True |
Note: If you are using switch -SkipTargetSubscriptionConfig, then it assumes you have done all the required configuration on the target subscriptions. Like, adding the CA SPN as Reader on target sub, Creating AzSK RG and a storage account name starting with azsk, Contributor permission to SPN on AzSKRG. If any of the steps are not done, then central scan automation account will skip those target subscriptions.
In case you want to add/update new subscriptions to any of the groups, you can do so using the command below (this is similer to the single Automation account command, except that you have to specify the AutomationAccountRGName and AutomationAccountName):
$SubscriptionId = '<subscriptionId>'
$AutomationAccountRGName = '<RGName>' # e.g. AzSK-Category-ScanRG01
$AutomationAccountName = '<accountName>' # e.g. AzSKScanningAccount01
$TargetSubscriptionIds = '<SubId1, SubId2, SubId3,...>' #Need to provide comma separated list of all subscriptionId that needs to be scanned.
Update-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -TargetSubscriptionIds $TargetSubscriptionIds
-AutomationAccountRGName $AutomationAccountRGName -AutomationAccountName $AutomationAccountName -CentralScanMode -FixRuntimeAccount
[-LoggingOption <CentralSub|IndividualSubs>] | Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central subscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| TargetSubscriptionIds | Comma separated list of subscriptionIds that needs to be scanned by the central subscription. It would always append the values provided in this param to the current scanning list. | True | The user executing this command should be owner on these subscriptions. | |
| AutomationAccountRGName | Name of ResourceGroup which will hold the scanning automation account | False | e.g. AzSK-Category-ScanRG01 | |
| AutomationAccountName | Name of the AutomationAccount which will scan target subscriptions | False | e.g. AzSKScanningAccount01 | |
| LoggingOption | "IndividualSubs/CentralSub" | False | Only provide if you want to change the logging option | |
| FixRuntimeAccount | This will correct all the permissions issues related to the scanning account | False | Provide this switch only when you want to add new subscriptions for central scanning mode or if scanning account credential needs to be updated | |
| CentralScanMode | It is mandatory to use CentralScanMode switch | True |
You can run the command below (see the main section for Get-AzSKContinuousAssurance earlier in this doc for details)
$SubscriptionId = '<subscriptionId>'
$AutomationAccountRGName = '<RGName>' # e.g. AzSK-Category-ScanRG01
$AutomationAccountName = '<accountName> # e.g. AzSKScanningAccount01
Get-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -AutomationAccountRGName $AutomationAccountRGName -AutomationAccountName $AutomationAccountName -CentralScanMode [-ExhaustiveCheck] | Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central SubscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| AutomationAccountRGName | Name of ResourceGroup which will hold the scanning automation account | False | e.g. AzSK-Category-ScanRG01 | |
| AutomationAccountName | Name of the AutomationAccount which will scan target subscriptions | False | e.g. AzSKScanningAccount01 | |
| ExhaustiveCheck | (Optional) By appending this switch it would check whether all the modules installed in central automation account are up to date | False | Only include if default diagnosis is not resulting in any issue |
In case you want to
(a) unregister some subs from central scanning mode, or
(b) to delete the scan logs, or
(c) to remove the whole automation account
$SubscriptionId = '<subscriptionId>'
$AutomationAccountRGName = '<RGName>' # e.g. AzSK-Category-ScanRG01
$AutomationAccountName = '<accountName> # e.g. AzSKScanningAccount01
Remove-AzSKContinuousAssurance -SubscriptionId $SubscriptionId -DeleteStorageReports -AutomationAccountRGName $AutomationAccountRGName -AutomationAccountName $AutomationAccountName -CentralScanMode | Param Name | Purpose | Required? | DefaultValue | Comments |
|---|---|---|---|---|
| SubscritionId | Central SubscriptionId which is responsible for scanning all the other subscriptions | True | This subscription would host the Automation account which is responsible for scanning all the other subscriptions | |
| TargetSubscriptionIds | Comma separated list of target subIds which will be un-registered from the central scanning mode. | False | ||
| AutomationAccountRGName | Name of ResourceGroup which will hold the scanning automation account | False | e.g. AzSK-Category-ScanRG01 | |
| AutomationAccountName | Name of the AutomationAccount which will scan target subscriptions | False | e.g. AzSKScanningAccount01 | |
| DeleteStorageReports | Deletes all the scan logs from the azsk storage account based on the logging option and value provided in the target subscription. If used with out CentralScanMode switch, it would remove all logs from the host sub central storage account. | False | Only include if default diagnosis is not resulting in any issue | |
| CentralScanMode | It is mandatory to use CentralScanMode switch | True |
Note If just subscrptionId is passed, then it would check if the host sub is in central scanning mode, if so, user needs to pass CentralScanMode switch. In these scenarios, it would remove the whole automation account from host sub.
You need to be 'Owner' on the subscription. This is required because, during CA setup, we add RBAC access to an Azure AD App (SPN) that's utilized for running the 'security scan' runbooks in Azure Automation. Only an'Owner' for a subscription has the right to change subscription RBAC.
No. The intent of CA is to scan regularly and be able to monitor the outcomes for security drift. Out of the box, AzSK CA uses OMS for the monitoring capabilities. (Basically, AzSK sends control evaluation results to a connected OMS workspace.)
Check with your service offering leader/org's cloud lead. You would typically use one of the following options:
- Utilize a workspace is shared across a related set of services from your SO
- Create a new OMS workspace and use that exclusively for your service ('free' tier is OK for just AzSK use cases)
- Utilize an IT-wide shared workspace
CA supports scanning a subscription and a set of cloud resources that make up an application. These cloud resources are assumed to be hosted within one or more resource groups. A typical CA installation takes both the subscription info and resource groups info.
You can check using the "Get-AzSKContinuousAssurance" cmdlet. If CA is correctly setup, it will show a list of artifacts that are deployed during CA setup (e.g., Automation account, Connections, Schedules, OMS workspace info, etc.). If CA has not been setup, you will see a message indicating so.
There are 2 important things you should do to verify this: Run the Get-AzSKContinuousAssurance and confirm that the output tells you as in the previous question. Verify that the runbooks have actually started scanning your subscription and resource groups. You can check for this in OMS.
We would like teams to, at a minimum, provide the list of resource groups that cover the most critical components of their application. It is unlikely that you will just have a subscription but no important resources inside it. Still, if you absolutely can't provide a resource group, then specify the "" as the resource group when setting up CA. If you do provide "*" as an option, CA will automatically grow/shrink the resource group list as you add/delete resource groups in your subscription.
That is easy! Just run the Update-AzSKContinuousAssurance cmdlet with the new list of resource groups you would like monitored.
This part is not mandatory for CA itself to work. However, setting up the AzSK OMS solution is recommended as it will help you get a richer view of continuous assurance for your subscription and resources as scanned by CA. Secondly, it will give you several out-of-box artefacts to assist with security monitoring for your service. For instance, you will start getting email alerts if any of the high or critical severity controls from AzSK fail in your service.
Using the following ballpark calculations (and service costs as of Q1-FY18), we estimate that a Continuous Assurance setup along with an OMS workspace for monitoring will cost a little about $80/year for a typical subscription with about 30-40 resources of various types. The average cost of AzSK CA and AzSK OMS solution per Azure resources comes to about $2.7 per year. (So, assuming that a typical app has about 30 resources, we get about $81/year for an application.)
The main/dominant component of the cost is automation runtime (storage/OMS costs are negligible in comparison).
- Typical application = 1 subscription + 3 resource groups (RGs) = ~30 resources (10 resources per RG)
- About 3 min per resource scan (higher side) => max ~100 min runbook time each day
- Central telemetry DB cost is not included (as in our model that’s not borne by individual app teams)
- Rate = $0.002/min of automation job
- For a 100 min runbook == $ 0.2 / day => $80 / year
-
AzSK CA Storage accumulation = 150KB / resource * 30 = 4.5MB per day
-
Average data for the month = 70MB (let’s take 100MB for simplicity)
-
Retention Cost:
- Rate = $.03/50TB/month for GRS-cool SKU => Average for the year ~ 0.6GB => cost = $0.030.612/50000 ~ $4x10^-6/year
-
Access Cost (Listing):
- Rate = $0.2/10000 transactions
- Our usage = ~ 1000 per year => $0.02 / year
-
Access Cost (replication+retrieval):
- Rate = $0.1/GB
- Our usage = ~ 1.2GB per year = $0.12 / year
-
Total Blob Storage Cost (retention + listing + access)
- 0.00 + 0.12 + 0.02 = $0.14/year
-
Assumes that the team is using OMS for monitoring in general, otherwise, just for AzSK, free tier is sufficient.
-
Data Upload
- Rate = $2.3 / GB / month
- Our usage = 10KB / resource scan => 300KB added per day = ~10MB data written for the month = (2.31012/1000) = $0.27/year
-
Retention
- Rate - $0.10 / GB / month
- Our usage = 60MB avg/month (at mid-year) = $0.10 * 0.06 *12 = $0.07/year
-
Total OMS Cost (Upload + Retention)
- 0.27+0.07 = $0.34/year
Please reach out to us at AzSDKSupExt@microsoft.com if you face any issues with this feature.