Implementing risk governance

Conduct risk governance reasonably

Traditional IT governance often involves extensive upfront protection. Before an application goes online, its operational processes are fully analyzed and potential threats are assessed. The application only goes live after governance measures are deployed on the middle platform. Subsequent application management can only follow pre-approved processes. Any iteration or upgrade to the application requires a new round of assessment. This approach is not suitable for modern cloud computing environments for the following reasons:

• Organizations migrate to the cloud to take advantage of its agility and elasticity. Operations and Maintenance (O&M) for cloud-based IT systems involves frequent and complex changes. Excessive governance can limit the agile development of cloud applications and create conflict between risk governance teams and business teams.
• Threats are a constant factor. The transition during cloud migration can introduce even greater threats. However, not all threats need to be completely avoided. You must fully assess the actual impact of a threat and adopt different response methods.
• The requirements for risk governance vary at different stages of cloud migration or application development. On the cloud, these stages change quickly. No risk governance team can detect all potential threats from the start. Therefore, risk governance must continuously evolve with application development.

Therefore, risk governance teams must find a balance between potential threat control, business development speed, and IT governance costs. This requires adopting different measures for different threats at various stages of business development and continuously iterating the company's risk governance policy.

The starting point of a risk governance strategy

As mentioned previously, threats are constant and ever-changing. For any organization, different stages of cloud migration and development present various threats that differ from traditional IT. As a result, the corresponding risk governance must also be an iterative process.

However, getting started is always the hardest part. Initiating risk governance for a new project is more difficult than continuously iterating an existing risk governance policy. Without a clear understanding of the business logic, it is difficult to create a targeted risk governance policy.

At this point, you must first identify a general set of threats and then create a corresponding general risk governance policy to serve as a starting point. Then, you can continuously iterate the governance policy based on the potential threats your organization faces at different stages.

To establish a general starting point for risk governance, you must first define a general minimum risk set. At this stage, you do not need to consider which specific assets are involved, what data is stored, or what application is supported.

The minimum risk set includes threats that all projects will encounter:

• All assets are at risk of accidental deletion, for example, due to human error.
• All assets are at risk of over-provisioning.
• All assets can be compromised by weak passwords or insecure settings.
• Any asset with an open port exposed to the Internet is vulnerable to attack.

You can create a minimum governance baseline based on the minimum risk set. Then, you can continuously upgrade the risk governance policy as the business develops. This approach will help you start and progress smoothly.

You can create a general policy for risk governance based on the minimum risk set. An organization should define its starting governance baseline based on the actual situation of its initial cloud migration. You should consider the nature of the business, the number of cloud O&M engineers, and the scale of the IT infrastructure to be hosted on the cloud. The following general baseline policies can be used as a reference:

• Define a whitelist and a limit for purchasable cloud resources.
• Tag resources with basic information, such as the department, billing unit, geographic location, Service-Level Agreement (SLA) commitment, environment, application, and owner.
• Restrict the regions where resources can be created.
• Restrict the list of users and roles that can access resources.
• While ensuring O&M feasibility, grant the permissions to purchase and release resources to the smallest possible group of people.
• Follow the principle of least privilege. High-level permissions require strict approval.
• Enforce a strong password policy.
• Enable the deletion protection feature for basic computing and storage resources.
• Disable public network access for key computing and storage resources.
• Most initial cloud migrations involve a hybrid cloud architecture for a period of time. Communication between cloud and on-premises environments must use a Virtual Private Network (VPN).

Iterating the risk governance strategy

When an organization plans its cloud migration, it might initially move some internal platforms and O&M systems to the cloud. At this stage, core business applications are often not involved. Therefore, you do not need to focus too much on data protection, network security, or disaster recovery mechanisms. The minimum governance baseline is sufficient to mitigate the threats of over-purchasing and excessive authorization. However, as the organization migrates its core business to the cloud and that business scales up, you must gradually consider more potential threats and continuously upgrade the risk governance policy based on the minimum governance baseline.

• Migrating business data to the cloud
  • Encrypt all important data at rest.
  • Isolate networks containing important data from other subnets and regularly review traffic.
  • Ensure subnets containing important data cannot be accessed from the public network and must be accessed through an intermediate subnet. Access to the subnet must be scanned and protected by a firewall.
  • Set up automatic Anti-DDoS protection for all public ports.
  • Preset minimum authorization for critical resources and resources that store important data. Use exception policies to grant individual permissions. Regularly review exceptions and ensure that exceptions are time-limited.
  • Enable multi-factor authentication (MFA) for all accounts.
  • Backup policy
  • Audit data access logs.
• Migrating core business applications to the cloud
  • Use hot backup and high availability modes for virtual machines.
  • Define an SLA for recovery. Determine the recovery time objective (RTO) and recovery point objective (RPO).
  • Enable monitoring for all cloud assets.
  • Separate monitoring management and audit management permissions from IT management permissions.
  • Tag resources with criticality labels. Focus monitoring and protection on the 20% of core systems.
• Scaling up
  • Use templates for deployment as much as possible. Templates must include application baselines, risk governance baselines, monitoring and auditing baselines, and security protection baselines.
  • Allocate budgets for cloud applications and set up budget-limiting mechanisms.
  • Monitor the real-time utilization of assets and set alerts for when utilization exceeds predefined limits.
  • Assign an owner to each asset.

• Identity and access governance baseline
• General security governance baseline
• Data security governance baseline
• Cost management baseline
• Business continuity baseline

Summary

The goal of IT risk governance is to support business growth, not to hinder it. It is crucial to adopt sufficient and reasonable management policies at every stage of business development. Today, cloud applications develop rapidly and change often. IT risk governance must also iterate quickly with the business. An organization's IT risk governance team can maintain a full understanding of business threats and reasonably mitigate them only by working closely and communicating fully with business and O&M teams.