# Azure Cloud General
This document defines the security controls and lifecycle management for Azure resources. In the scope of this document are all kinds of resources hosted in Azure.
# Tagging
Implemented for: Ability and RA
For proper governance of Azure resources, tagging is mandatory for every resource created in Azure. The following subsections describe the inheritance of mandatory tags.
The following security controls have been implemented by the workflow as seen below:
| Item | Value |
|---|---|
| Workflow Type | Violation |
| Exception Allowed/Owner Review | No |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes |
# Inheritance
Azure resources can be tagged on a target resource level or Resource Group level. If a tag is added on a resource level, then this tag value is the actual(current?) one. If no tag is added on resource level, then the value for a target tag is taken from the Resource Group tag.
# Required tags
The table below shows the required tags for Azure Resources. It is the owner's responsibility to define proper tags for any created resources.
| Name | Is Mandatory | Meaning | Allowed Values |
|---|---|---|---|
| Owner | Yes - on Resource Group level | Owner of target resource | ABB account email. This tag is required on a Resource Group level by the attached policies. |
| Environment | Yes - on Resource Group level | Type of resources | One of the value provided in subsection. This tag is required on a Resource Group level by the attached policies. |
| Version | Yes - on Resource Group level for Test type of the environment | Version of release (e.g. 19.09) which is being tested | Version of release |
| IGar | Yes - on Resource Group level for Production type of the environment | IGar number of the application that has been registered to which resources belongs to | IGar number |
| BN | Yes - on Resource Group level for Test type of the environment | Business Area | This value should contain the abbreviations for the target Business Area. It is assigned by the Operations Team by default. |
| BL | Yes - on Resource Group level | Business Line | For digital resources this tag should have one of the values of Management Groups created under Int-Digital Management group. By default, this value is assigned in resource groups by policies based on the subscription location in management groups. |
| Purpose | No | Detailed description on why this resource is needed | Text |
| Team | No | The team which is using the target resource | Text (Value used from Active Directory - U-Ability-Team) |
# Exceptions
The NetworkWatcher and DefaultResourceGroup resource groups created by Azure Automation are excluded from the lifecycle.
Resource groups created by AKS automation inherit tags from AKS resource if not provided explicitly. Tags are not required for AKS resource groups.
# Environment tag values
Environment tag values are an implementation of the resource types defined in Resource classification. The table below shows all allowed values for the Environment tag.
| Value | Type | Additional information |
|---|---|---|
| Tmp | Temp | |
| Plg | Playground | |
| Dev | Development | |
| Dvo | Development | |
| Bdv | Development | |
| Ops | Development | |
| Tst | Test | |
| Stg | Stage | |
| Prd | Production |
# Lifecycle of resources
Implemented for: Ability and RA
The following subsections describe the lifecycle of resources based on resource their classification.
# Unknown
Unknown resources are defined as resources which did not have the proper tags applied. For these resources, review workflows are disabled until the tag violation is fixed.
# Temp
The temp lifecycle has been implemented as seen in the workflow below:
| Item | Value |
|---|---|
| Workflow Type | Review Workflow |
| Exception Allowed/Owner Review | No |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes | Reviewed after month. Temp resources can last one month - this cannot be extended unless the environment type is changed. |
# Playground, Develop and Test
The Playground and Develop lifecycle has been implemented by workflow as seen below:
| Item | Value |
|---|---|
| Workflow Type | Review Workflow |
| Exception Allowed/Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes | Review is started every 3 months |
# Test
Test environments usage review is implemented in the same way as for Development and Playground. Additional test environments are going to be removed by the Manual removal workflow based on the Version tag.
# Production and Stage
The Production and Stage lifecycle has been implemented by the workflow below:
| Item | Value |
|---|---|
| Workflow Type | Review Workflow |
| Exception Allowed/Owner Review | Yes |
| Stage 1 Days Period | 28 |
| Stage 2 Days Period | 28 |
| Notes | Reviewed every 6 months |
# Exceptions
The NetworkWatcher and DefaultResourceGroup resource groups created by Azure Automation are excluded from the lifecycle.
Resource group lifecycle created by AKS Automation is bound to the AKS resource.
# External Accounts
Implemented for: Ability
# Tracking
Access can only be granted to external accounts which are registered. Account registration is mandatory. Owners are responsible for removing any access to their resources from any accounts that are no longer active.
You can register an external account here. Non-registered external accounts will have their access to resources revoked automatically.
The enforcement of external account tracking requirements has been implemented by the workflow as seen below:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/Owner Review | No |
| Stage 1 Days Period | 0 |
| Stage 2 Days Period | 2 |
| Notes |
# Azure Cloud Virtual Machines
# Disabling public access
Implemented for: Ability
Virtual Machines must not be made publicly accessible. Proper rules need to be applied on every created Virtual Machine to restrict external access via the internet.
All resources will be monitored and disabled if the requirements are not met.
The enforcement of Virtual Machine access restrictions has been implemented as seen in the workflow below:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes |
# Virtual Private Network
It is recommended to protect Virtual Machines by disabling public access, and to connect to that machine only by using a VPN or a Bastion Host.
# References
# Allowlisting
If a Virtual Network cannot be created for whatever reason, then it is recommended to restrict access to the Virtual Machine by adding the necessary rules which can be found in Network Security Groups. In the ABB infrastructure, there are two ways of getting a defined outgoing IP address:
- by using the iBoss proxy - a standard ABB application installed on laptops provided by ABB.
- by using Ability VPN - a solution that allows access to Azure resources with a static IP
You can request access to the Ability VPN by visiting MyIs for Ability (Request Fulfillment -> Add/Remove ABB Ability VPN Access).
iBoss proxy
iBoss outgoing IP information is published and updated every day here. To get Network Security Group iBoss rules updated automatically, contact inmadig@in.abb.com.
By default, the iBoss proxy is used only for http and https communication (ports 80 and 443) to enable forwarding of all ports, create an iboss Secure Gateway Consulting request in MyIs, and ask to add your PC to the !ZH_InternetAccessDev group.
Here is an example of the inbound rules which allow access via Azure Ability VPN and the iBoss proxy.
| Priority | Name | Port | Protocol | Source | Destination | Action | Description |
|---|---|---|---|---|---|---|---|
| 1000 | AbilityVPNGateway | Any | Any | 138.225.1.196, 138.225.1.197 | Any | Allow | Allow inbound connections from Ability VPN Gateways only. |
| 1001 | iBoss | Any | Any | <...> | Any | Allow | Allow inbound connections by using iBoss proxy |
| 65000 | AllowVnetInBound | Any | Any | Virtual Network | Virtual Network | Allow | Default rule |
| 65001 | AllowAzureLoad BalancerInBound | Any | Any | AzureLoadBalancer | Any | Allow | Default rule |
| 65500 | DenyAllInBound | Any | Any | Any | Any | Deny | Default rule |
And here is an example of the outbound rules which allow access to main ABB services.
| Priority | Name | Port | Protocol | Source | Destination | Action | Description |
|---|---|---|---|---|---|---|---|
| 1001 | AllowAbilityPKI | 443 | TCP | Any | 45.60.121.229 45.60.131.229 | Allow | Allow communication to Ability PKI (DigiCert) |
| 1002 | AllowAgentToSOC | 443 | Any | Any | 52.58.127.215 52.29.161.218 | Allow | Allow Cylance Agent communication to ABB SOC |
| 1003 | AllowQualys | 443 | TCP | Any | 64.39.96.0/20 | Allow | Allow Qualys Guard Agent communication |
| 4096 | DenyInternetOutBound | Any | Any | Any | Internet | Deny | Deny outbound Internet communication |
| 65000 | AllowVnetOutBound | Any | Any | Virtual Network | Virtual Network | Allow | Default rule |
| 65001 | AllowInternetOutBound | Any | Any | Any | Internet | Allow | Default rule |
| 65500 | DenyAllOutBound | Any | Any | Any | Any | Deny | Default rule |
# References
# Exceptions
- The platform owner does not need to follow this requirement on platform instances (Req-03-01). This requirement should be considered in platform design and implemented in an automatic way.
# Public IP Addresses
Implemented for: Ability
All Public IP Addresses must be protected by the use of a VPN, allowlisting, a firewall, or any other techniques which allow to filter access only to ABB devices.
All resources will be monitored and disabled if the requirements are not met.
Public IP Address access restrictions have been enforced as seen in the workflow below:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/ Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes |
Protecting Virtual Machines
In order to ensure that your Virtual Machines are protected, we recommend using at least one of the items listed below:
- a VPN
- allowlisting
# Exceptions
- Ability Platform owners do not need to follow this requirement on Platform instances. However, this requirement should be considered in Platform design and implemented in an automatic way.
- Only Web Applications for public services can be exposed - an exception request and approval are required for these.
# Web Applications
Implemented for: Ability
All Web Applications should be secured and protected by the following rules:
- Web Application debugging can be enabled only during troubleshooting
HTTPS Onlyshould be enabledMin TLSversion should be set to 1.2- Only FTPS connections are allowed (no FTP)
- Access to the Web Application Site and SCM Site should be restricted and not exposed to the public (for example, by allowlisting)
All resources will be monitored and disabled if the requirements are not met.
Web Application security measures have been enforced as seen in the workflow below:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/ Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes | Requirements for Web Applications have been implemented by separate workflows. The Web Application Site and SCM Site exposure are checked for the 200 status code response. |
# Exceptions
- Ability Platform owners do not need to follow this requirement on Platform instances. However, this requirement should be considered in Platform design and implemented in an automatic way.
- Only Web Applications for public services can be exposed - an exception request and approval are required for these.
# Incident Monitoring Agent (Cylance)
Implemented for: Ability
Based on: Server Security Policy 2.1
Cylance monitoring agents must be installed on Virtual Machines. Enforcing Cylance installation has been implemented by the workflow below:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes | Proper Zone needs to be setup during agent installation. Workflow is started when Cylance is not installed (or is not reporting) for 7 days or more. |
For Cylance installation instructions, open the appropriate user guide for your system.
During installation, ensure that your VM allows for outbound communication with ABB SOC services. It can take up to 24 hours before an Agent will be visible in your Inventory. In case of any general questions about requirements and installation, contact support for your target Business Area. If you have any technical problems during installation, contact the Cylance team directly by sending them a message: avmservice@abb.com
# Ability internal only
Ability resources are required to provide the Azure_VMs_Digital zone during the installation process. To do that, modify Cylance installation with following step:
- For Windows users, use this VBS script located in the Cylance - Ability folder. When executing the VBS script, enter this command in the command prompt:
cscript <script.vbs> Azure_VMs_Digital
- For Linux users, edit the config_defaults.txt file and apply the following change in the line containing VenueZone:
VenueZone=Azure_VMs_Digital
# Exceptions
- On Tmp resources, agent doesn't need to be installed
- Platform owners do not need to follow this requirement on platform instances. This requirement should be considered in platform design and implemented in an automatic way.
- All other exceptions need to be agreed together with Engineering Security team.
# Vulnerabilities Monitoring Agent (Qualys Guard)
Implemented for: Ability
Based on: Server Security Policy 2.1
It is required to install Qualys Guard monitoring agents on Virtual Machines. Enforcing Qualys Guard installation has been implemented by the workflow:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes | Workflow is started when Qualys is not installed (or is not reporting) for 7 days or more. |
Qualys installation packages for Ability (internal only):
You can find Qualys Guard installation guidelines and packages for your operating system here.
Qualys Installation
To get Qualys installation packages for other Business Areas, contact support for your target Business Area.
During installation, ensure that your VM allows for outbound communication with ABB SOC services. It can take up to 24 hours before Agent will be visible in Inventory. If you have any general questions about the requirements and installation, contact support for your target Business Area.
If you find any vulnerabilities, resource owners will get an email notification regarding which patches should be installed. It is every owner's responsibility to apply the necessary updates and patches on Virtual Machines.
Technical Support
In case of any technical problems during installation, contact the Vulnerability Management Services via MyIs: Order a new item > Information Systems > IS Service Catalog > Security > Vulnerability Management Services
# Exceptions
- On Tmp resources, agent doesn't need to be installed
- Platform owners do not need to follow this requirement on platform instances. This requirement should be considered in platform design and implemented in an automatic way.
- All other exceptions need to be agreed together with Engineering Security team.
# Vulnerability Tickets Resolving
Implemented for: Ability
Based on: Server Security Policy 2.1
It is required to resolve Vulnerability Tickets created for Virtual Machines based on Qualys Guard agent findings. Enforcing this policy has been implemented by the workflow as seen below:
| Item | Value |
|---|---|
| Workflow Type | Violation Workflow |
| Exception Allowed/Owner Review | Yes |
| Stage 1 Days Period | 14 |
| Stage 2 Days Period | 14 |
| Notes | Workflow is started 7 days after due date of unresolved tickets
|
More information about severity descriptions can be found in Qualys Documentation.
Technical Support
In case of any technical problems with remediation, questions regarding patching, or if your ticket is still open after remediation, contact Vulnerability Management Services in MyIs by creating a Consulting request for Vulnerability-Deviation Remediation.
# Exceptions
- On Tmp resources, tickets do not need to be solved.
- All other exceptions need to be agreed on together with the Engineering Security team.