GCP Security best practice: Data Protection and Monitoring Handling Procedures

This Google Cloud Platform security best practice is part of the Data Protection security domain.

Procedures for labeling, handling, and protecting the confidentiality and integrity of personal information, test data, production data, and data involved in online transactions to prevent contract dispute and compromise of data shall be established. Mechanisms for label inheritance shall be implemented for objects that act as aggregate containers for data.

Areas where potential information leakage can occur shall be identified, and appropriate controls to mitigate it shall be implemented.

Customers can use Cloud DLP API to better understand and manage sensitive data. It provides fast, scalable classification and redaction for sensitive data elements, like credit card numbers, names, social security numbers, US and selected international identifier numbers, phone numbers, and GCP credentials. VPC service controls and org note policies can be used too.

GCP Security best practice: Data Ownership & Inventory

This Google Cloud Platform security best practice is part of the Data Protection security domain.

Appropriate ownership to data and establish procedures to classify, monitor, and update data in accordance with its classification policies. Policies and procedures shall be in place to inventory, document, and maintain data flows to ascertain any regulatory, statutory impact, and to address any other business risks associated with the data.

This is a customer responsibility. The Cloud Data Loss Prevention (DLP) API can help scan PII (credit card numbers, names, social security numbers, US and selected international identifier numbers, phone numbers, and GCP credentials) data and classify sensitive data within text content.

GCP Security best practice: Security-related alerts and error conditions for all released applications

This Google Cloud Platform security best practice is part of the DevSecOps and CI/CD security domain.

Customers can create and manage alerting policies with Stackdriver Monitoring (using the console or the Stackdriver Monitoring API). Also export logs to SIEMs and detect any threats or anomalies.

Automated code analysis tools with specific components for monitoring for security issues shall be used.

Customer can integrate with GCP → Security Command Center, Google App Engine → Cloud Security Scanner and Google Kubernetes Engine → Container Registry Scanning.

Container Registry scans for vulnerabilities and identifies package vulnerabilities for your container images. This page describes how you can view the vulnerabilities using Google Cloud Platform Console, the gcloud command-line tool, and Container Analysis API.

Cloud Security Command Center integrates with Google Cloud Platform security tools like Cloud Security Scanner, the Cloud Data Loss Prevention (DLP) API, and third-party security solutions from Cloudflare, CrowdStrike, Dome9, Palo Alto Networks, Qualys, and RedLock.

GCP Security best practice: Software Engineering shall use automated tools to evaluate operational environment and application-specific health

This Google Cloud Platform security best practice is part of the DevSecOps and CI/CD security domain.

Customers can use Cloud Security Command Center, which is designed to enable users to monitor the inventory of their cloud assets, scan storage systems for sensitive data, detect common vulnerabilities, and review access rights to critical resources.

Customers can also use Stackdriver Monitoring to provide visibility into the performance, uptime, and overall health of applications in GCP

GCP Security best practice: A training and awareness program focused on cloud product security shall be in place

This Google Cloud Platform security best practice is part of the Governance Risk and Compliance security domain.

The training program shall include:

  • Reviewing risks
  • Reviewing actions each group shall take to treat risks
  • Training and testing participants in their responsibilities
  • Requires passing before being allowed to participate in the development and support of cloud products

Remediate and track progress toward remediation for areas of noncompliance to include:

  • Developing a plan of action and milestones for the information system to document planned remedial actions to correct weaknesses or deficiencies noted during the assessment of the security controls, and to reduce or eliminate known vulnerabilities in the system
  • Updating existing plan of action and milestones at each quarter, based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities

GCP: Google Cloud Platform Security best practices

Over the next few days will publish a series of articles that describe some of the best security practices for GCP. Those security practices are mapped to the ISO 27002:2013 controls and standards.

The security domains that we are going to cover:

  • Governance Risk and Compliance
  • DevSecOps and CI/CD
  • Data Protection
  • Vulnerability and Threat Management
  • Logging and Monitoring
  • Incident Response Management
  • Network & Infrastructure Security
  • Identity and Access Management
  • Business Continuity & Disaster Recovery

You can find all the related articles by searching for “GCP best practice” in the Tag cloud below:

azure Azure Best Practice Azure Firewall Azure Lighthouse azure migration Azure Policy Azure Security Azure Security Center backup CIS cloud migration cloud security cybersecurity databasesecurity devops disaster recovery GCP GCP best practice GCP security Google Cloud Security Identity Management ISO 27001 iso 27002 managed draas Managed Security Services Microsoft 365 Business Premium microsoft 365 security Microsoft365Business nist nist 800-53 PCI DSS Security Compliance Security Controls sqlsecurity vdi virtual desktop wfd windows virtual desktop workfromhome wvd

GCP: CIS 1.0.0 Security controls for Google Cloud Platform

The following security controls are part of the GCP CIS 1.0.0 specifications and they can audited by our managed GCP security services. Please note the standard has more security controls that unfortunately cannot be audited at this time, due to lack of APIs from the Google platform. Our Managed GCP Security Services can audit and help you remediate most of the technical controls listed below:

CONTROLDESCRIPTION
1.1 Ensure that corporate login credentials are used instead of Gmail accountsUse corporate login credentials instead of Gmail accounts.
1.3 Ensure that there are only GCP-managed service account keys for each service accountUser managed service account should not have user managed keys.
1.4 Ensure that ServiceAccount has no Admin privileges.A service account is a special Google account that belongs to your application or a VM, instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren’t directly involved.
1.5 Ensure that IAM users are not assigned Service Account User role at project levelIt is recommended to assign `Service Account User (iam.serviceAccountUser)` role to a user for a specific service account rather than assigning the role to a user at project level.
1.6 Ensure user-managed/external keys for service accounts are rotated every 90 days or lessService Account keys consist of a key ID (Private_key_Id) and Private key, which are used to sign programmatic requests that you make to Google cloud services accessible to that particular Service account.
1.8 Ensure Encryption keys are rotated within a period of 365 daysGoogle Cloud Key Management Service stores cryptographic keys in a hierarchical structure designed for useful and elegant access control management. Access to resources.The format for the rotation schedule depends on the client library that is used.
2.1 Ensure that Cloud Audit Logging is configured properly across all services and all users from a projectIt is recommended that Cloud Audit Logging is configured to track all Admin activities and read, write access to user data.
2.2 Ensure that sinks are configured for all Log entriesIt is recommended to create sink which will export copies of all the log entries.
2.3 Ensure that object versioning is enabled on log-bucketsIt is recommended to enable object versioning on log-buckets.
2.4 Ensure log metric filter and alerts exists for Project Ownership assignments/changesIn order to prevent unnecessarily project ownership assignments to users/service-accounts and further misuses of project and resources, all `roles/Owner` assignments should be monitored.
2.5 Ensure log metric filter and alerts exists for Audit Configuration ChangesGoogle Cloud Platform services write audit log entries to Admin Activity and Data Access logs to helps answer the questions of “who did what, where, and when?” within Google Cloud Platform projects.
2.6 Ensure log metric filter and alerts exists for Custom Role changesIt is recommended that a metric filter and alarm be established for changes IAM Role creation, deletion and updating activities.
2.7 Ensure log metric filter and alerts exists for VPC Network Firewall rule changesIt is recommended that a metric filter and alarm be established for VPC Network Firewall rule changes.
2.8 Ensure log metric filter and alerts exists for VPC network route changesIt is recommended that a metric filter and alarm be established for VPC network route changes.
2.9 Ensure log metric filter and alerts exists for VPC network changesIt is recommended that a metric filter and alarm be established for VPC network changes.
2.10 Ensure log metric filter and alerts exists for Cloud Storage IAM permission changesIt is recommended that a metric filter and alarm be established for Cloud Storage Bucket IAM changes.
2.11 Ensure log metric filter and alerts exists for SQL instance configuration changesIt is recommended that a metric filter and alarm be established for SQL Instance configuration changes.
3.1 Ensure the default network does not exist in a projectTo prevent use of `default` network, a project should not have a `default` network.
3.3 Ensure that DNSSEC is enabled for Cloud DNSDNSSEC in Cloud DNS enables domain owners to take easy steps to protect their domains against DNS hijacking and man-in-the-middle and other attacks.
3.4 Ensure that RSASHA1 is not used for key-signing key in Cloud DNS DNSSECDNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.
3.5 Ensure that RSASHA1 is not used for zone-signing key in Cloud DNS DNSSECDNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.
3.9 Ensure VPC Flow logs is enabled for every subnet in VPC NetworkFlow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC Subnets. After you’ve created a flow log, you can view and retrieve its data in Stackdriver Logging.
4.1 Ensure that instances are not configured to use the default service account with full access to all Cloud APIsTo support principle of least privileges and prevent potential privilege escalation it is recommended that instances are not assigned to default service account `Compute Engine default service account` with Scope `Allow full access to all Cloud APIs`.
4.2 Ensure “Block Project-wide SSH keys” enabled for VM instancesIt is recommended to user Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances.
4.3 Ensure oslogin is enabled for a ProjectEnabling OS login binds SSH certificates to IAM users and facilitates effective SSH certificate management.
4.4 Ensure ‘Enable connecting to serial ports’ is not enabled for VM InstanceIf you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address.
4.5 Ensure that IP forwarding is not enabled on InstancesForwarding of data packets should be disabled to prevent data loss or information disclosure.
5.1 Ensure that Cloud Storage bucket is not anonymously or publicly accessibleIt is recommended that IAM policy on Cloud Storage bucket does not allows anonymous and/or public access.
5.3 Ensure that logging is enabled for Cloud storage bucketsIt is recommended that storage Access Logs and Storage logs are enabled for every Storage Bucket.
6.1 Ensure that Cloud SQL database instance requires all incoming connections to use SSLIt is recommended to enforce all incoming connections to SQL database instance to use SSL.
6.2 Ensure that Cloud SQL database Instances are not open to the worldDatabase Server should accept connections only from trusted Network(s)/IP(s) and restrict access from the world.
6.4 Ensure that MySQL Database Instance does not allows root login from any HostIt is recommended that root access to a MySql Database Instance should be allowed only through specific white-listed trusted IPs.
7.1 Ensure Stackdriver Logging is set to Enabled on Kubernetes Engine ClustersStackdriver Logging lets you have Kubernetes Engine automatically collect, process, and store your container and system logs in a dedicated, persistent datastore.
7.2 Ensure Stackdriver Monitoring is set to Enabled on Kubernetes Engine ClustersStackdriver Monitoring to monitor signals and build operations in your Kubernetes Engine clusters.
7.3 Ensure Legacy Authorization is set to Disabled on Kubernetes Engine ClustersIn Kubernetes, authorizers interact by granting a permission if any authorizer grants the permission. The legacy authorizer in Kubernetes Engine grants broad, statically defined permissions.
7.4 Ensure Master authorized networks is set to Enabled on Kubernetes Engine ClustersAuthorized networks are a way of specifying a restricted range of IP addresses that are permitted to access your container cluster’s Kubernetes master endpoint.
7.5 Ensure Kubernetes Clusters are configured with LabelsA cluster label is a key-value pair that helps you organize your Google Cloud Platform resources, such as clusters. You can attach a label to each resource, then filter the resources based on their labels.
7.6 Ensure Kubernetes web UI / Dashboard is disabledDashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster itself along with its attendant resources.
7.7 Ensure `Automatic node repair` is enabled for Kubernetes ClustersKubernetes Engine’s node auto-repair feature helps you keep the nodes in your cluster in a healthy, running state. When enabled, Kubernetes Engine makes periodic checks on the health state of each node in your cluster.
7.8 Ensure Automatic node upgrades is enabled on Kubernetes Engine Clusters nodesNode auto-upgrades help you keep the nodes in your cluster or node pool up to date with the latest stable version of Kubernetes.
7.10 Ensure Basic Authentication is disabled on Kubernetes Engine ClustersBasic authentication allows a user to authenticate to the cluster with a username and password and it is stored in plain text without any encryption. Disabling Basic authentication will prevent attacks like brute force.
7.11 Ensure Network policy is enabled on Kubernetes Engine ClustersA network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.
7.13 Ensure Kubernetes Cluster is created with Alias IP ranges enabledGoogle Cloud Platform Alias IP Ranges lets you assign ranges of internal IP addresses as aliases to a virtual machine’s network interfaces.
7.14 Ensure PodSecurityPolicy controller is enabled on the Kubernetes Engine ClustersA Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification.
7.15 Ensure Kubernetes Cluster is created with Private cluster enabledA private cluster is a cluster that makes your master inaccessible from the public internet. In a private cluster, nodes do not have public IP addresses, so your workloads run in an environment that is isolated from the internet.
7.16 Ensure Private Google Access is set on Kubernetes Engine Cluster SubnetsPrivate Google Access enables your cluster hosts, which have only private IP addresses, to communicate with Google APIs and services using an internal IP address rather than an external IP address.
7.18 Ensure Kubernetes Clusters created with limited service account Access scopes for Project accessAccess scopes are the legacy method of specifying permissions for your instance. Before the existence of IAM roles, access scopes were the only mechanism for granting permissions to service accounts.
1.7 Ensure that Separation of duties is enforced while assigning service account related roles to usersIt is recommended that the principle of ‘Separation of Duties’ is enforced while assigning service account related roles to users.
1.9 Ensure that Separation of duties is enforced while assigning KMS related roles to usersIt is recommended that the principle of ‘Separation of Duties’ is enforced while assigning KMS related roles to users.
3.6 Ensure that SSH access is restricted from the internetGCP `Firewall Rules` are specific to a `VPC Network`. Each rule either `allows` or `denies` traffic when its conditions are met. Generic `(0.0.0.0/0)` incoming traffic from internet to VPC or VM instance using `SSH` on `Port 22` can be avoided.
3.7 Ensure that RDP access is restricted from the internetGCP `Firewall Rules` are specific to a `VPC Network`. Each rule either `allows` or `denies` traffic when its conditions are met. Generic `(0.0.0.0/0)` incoming traffic from internet to VPC or VM instance using `RDP` on `Port 3389` can be avoided.
3.8 Ensure Private Google Access is enabled for all subnetwork in VPC NetworkPrivate Google Access enables virtual machine instances on a subnet to reach Google APIs and services using an internal IP address rather than an external IP address.
4.6 Ensure VM disks for critical VMs are encrypted with Customer-Supplied Encryption Keys (CSEK)If you supply your own encryption keys, Google uses your key to protect the Google-generated keys used to encrypt and decrypt your data. By default, Google Compute Engine encrypts all data at rest.
7.9 Ensure Container-Optimized OS (cos) is used for Kubernetes Engine Clusters Node imageContainer-Optimized OS is an operating system image for your Compute Engine VMs that is optimized for running Docker containers.
7.17 Ensure default Service account is not used for Project access in Kubernetes ClustersA service account is an identity that an instance or an application can use to run API requests on your behalf. This identity is used to identify applications running on your virtual machine instances to other Google Cloud Platform services.

GCP: List of Security Controls that we check

This is a partial list of default security controls that we check as part of our managed security service for GCP (Google Cloud Platform):

Open DNSDetermines if TCP or UDP port 53 for DNS is open to the public
Open SSHDetermines if TCP port 22 for FTP is open to the public
Open CIFSDetermines if UDP port 445 for CIFS is open to the public
Open FTPDetermines if TCP port 20 or 21 for FTP is open to the public
Open Hadoop HDFS NameNode Metadata ServiceDetermines if TCP port 8020 for HDFS NameNode metadata service is open to the public.
Open Hadoop HDFS NameNode WebUIDetermines if TCP port 50070 and 50470 for Hadoop/HDFS NameNode WebUI service is open to the public
Open KibanaDetermines if TCP port 5601 for Kibana is open to the public
Open MySQLDetermines if TCP port 4333 or 3306 for MySQL is open to the public
Open NetBIOSDetermines if UDP port 137 or 138 for NetBIOS is open to the public
Open OracleDetermines if TCP port 1521 for Oracle is open to the public
Open PostgreSQLDetermines if TCP port 5432 for PostgreSQL is open to the public
Open RDPDetermines if TCP port 3389 for RDP is open to the public
Open RPCDetermines if TCP port 135 for RPC is open to the public
Open SMBoTCPDetermines if TCP port 445 for Windows SMB over TCP is open to the public
Open SMTPDetermines if TCP port 25 for SMTP is open to the public
Open SQLServerDetermines if TCP port 1433 or UDP port 1434 for SQL Server is open to the public
Open TelnetDetermines if TCP port 23 for Telnet is open to the public
Open VNC ClientDetermines if TCP port 5500  for VNC Client is open to the public
Open VNC ServerDetermines if TCP port 5900 for VNC Server is open to the public
Open Oracle Auto Data WarehouseDetermines if TCP port 1522 for Oracle Auto Data Warehouse is open to the public
Multiple SubnetsEnsures that VPCs have multiple networks to provide a layered architecture
Default VPC In UseDetermines whether the default VPC is being used for launching VM instances
VM Max InstancesEnsures the total number of VM instances does not exceed a set threshold
Instances Multi AZEnsures managed instances are regional for availability purposes.
Key RotationEnsures cryptographic keys are set to rotate on a regular schedule
DB RestorableEnsures SQL instances can be restored to a recent point
DB Automated BackupsEnsures automated backups are enabled for SQL instances
DB Multiple AZEnsures that SQL instances have a failover replica to be cross-AZ for high availability
DB Publicly AccessibleEnsures that SQL instances have a failover replica to be cross-AZ for high availability.
Bucket VersioningEnsures object versioning is enabled on storage buckets
Bucket LoggingEnsures object logging is enabled on storage buckets
CLB HTTPS OnlyEnsures CLBs are configured to only accept connections on HTTPS ports
Excessive Firewall RulesDetermines if there are an excessive number of firewall rules in the account
Open All PortsDetermines if all ports are open to the public
CLB No InstancesDetects CLBs that have no backend instances attached
Flow Logs EnabledEnsures VPC flow logs are enabled for traffic logging
Autoscale EnabledEnsures instance groups have autoscale enabled for high availability
Service LimitsDetermines if the number of resources is close to the per-account limit.
Private EndpointEnsures the private endpoint setting is enabled for kubernetes clusters
Monitoring EnabledEnsures all Kubernetes clusters have monitoring enabled
Private Access EnabledEnsures Private Google Access is enabled for all Subnets
Instance Level SSH OnlyEnsures that instances are not configured to allow project-wide SSH keys
VM Instances Least PrivilegeEnsures that instances are not configured to use the default service account with full access to all cloud APIs
IP Forwarding DisabledEnsures that IP forwarding is disabled on all instances
Connect Serial Ports DisabledEnsures connecting to serial ports is not enabled for VM instances
CSEK Encryption EnabledEnsures Customer Supplied Encryption Key Encryption is enabled on disks
Storage Bucket All Users PolicyEnsures Storage bucket policies do not allow global write delete or read permissions
Security Policy EnabledEnsures all backend services have an attached security policy
CLB CDN EnabledEnsures that Cloud CDN is enabled on all load balancers
DNS Security EnabledEnsures that DNS Security is enabled on all managed zones
DNS Security Signing AlgorithmEnsures that DNS Security is not using the RSASHA1 algorithm for key or zone signing
OS Login EnabledEnsures OS login is enabled for the project
Database SSL EnabledEnsures SQL databases have SSL enabled
Service Account Key RotationEnsures that service account keys are rotated within 90 days of creation.
Service Account Managed KeysEnsures that service account keys are being managed by Google.
Cluster Least PrivilegeEnsures Kubernetes clusters are created with limited service account access scopes
Project Ownership LoggingEnsures that logging and log alerts exist for project ownership assignments and changes
Storage Permissions LoggingEnsures that logging and log alerts exist for storage permission changes
SQL Configuration LoggingEnsures that logging and log alerts exist for SQL configuration changes
Audit Configuration LoggingEnsures that logging and log alerts exist for audit configuration changes.
Custom Role LoggingEnsures that logging and log alerts exist for custom role creation and changes
VPC Firewall Rule LoggingEnsures that logging and log alerts exist for firewall rule changes
VPC Network Route LoggingEnsures that logging and log alerts exist for VPC network route changes
VPC Network LoggingEnsures that logging and log alerts exist for VPC network changes
Alias IP Ranges EnabledEnsures all Kubernetes clusters have alias IP ranges enabled
Legacy Authorization DisabledEnsure legacy authorization is set to disabled on Kubernetes clusters
Master Authorized NetworkEnsures master authorized networks is set to enabled on Kubernetes clusters
Cluster Labels AddedEnsures all Kubernetes clusters have labels added
Web Dashboard DisabledEnsures all Kubernetes clusters have the web dashboard disabled.
Default Service AccountEnsures all Kubernetes cluster nodes are not using the default service account.
COS Image EnabledEnsures all Kubernetes cluster nodes have Container-Optimized OS enabled
Automatic Node Repair EnabledEnsures all Kubernetes cluster nodes have automatic repair enabled
Automatic Node Upgrades EnabledEnsures all Kubernetes cluster nodes have automatic upgrades enabled
Network Policy EnabledEnsures all Kubernetes clusters have network policy enabled
Pod Security Policy EnabledEnsures pod security policy is enabled for all Kubernetes clusters
Any Host Root AccessEnsures SQL instances root user cannot be accessed from any host
Service Account AdminEnsures that user managed service accounts do not have any admin owner or write privileges.
Service Account UserEnsures that no users have the Service Account User role.
Service Account SeparationEnsures that no users have both the Service Account User and Service Account Admin role.
KMS User SeparationEnsures that no users have the KMS admin role and any one of the CryptoKey roles.
Audit Logging EnabledEnsures that default audit logging is enabled on the project.
Log Sinks EnabledEnsures a log sink is enabled to export all logs
Private Cluster EnabledEnsures private cluster is enabled for all Kubernetes clusters
Logging EnabledEnsures all Kubernetes clusters have logging enabled
Corporate Emails OnlyEnsures that no users are using their Gmail accounts for access to GCP.
Basic Authentication DisabledEnsure basic authentication is set to disabled on Kubernetes clusters.

Managed GCP Security FAQ

GCP Security Compliance FAQ

Q: What are the costs related with the implementation of the GCP Security Compliance Policies?

A: GCP Security Compliance costs are based on the following paid services:

  • Initial deployment and configuration of your custom security policies – This is the effort associated with the initial creation of the security framework that you want to be compliant with: not all the security policies available in GCP by default would make sense for your particular environment as some of them could impede your normal management operations, for example. Creation of all the alerts for policy violations and other health alerts for your critical services. Creating and implementing the remediation plan for any policy violations. Novaquantum provides support for the full development life-cycle of security policies and remediation tasks involved in securing your environment.
  • On-going management – This is the effort required for daily support of the GCP Security Compliance service, monitoring of log sources, policy violations and on-going alerts tune-up and is covered by monthly management fee charged by managed GCP providers like us.  

Q: Can you guarantee 100% compliance with the above mentioned standards?

A: We will enable and remediate (if agreed by the customer) all the security controls available in GCP for the compliance framework(s) that you choose. Most of the security compliance frameworks have not only technical components, but business processes and procedures that need to be compliant as well, for which the customer alone is responsible. One notable exception is the GCP CIS that has only technical controls which we can control 100%.

Each security control is associated with one or more GCP feature/service. These features/services may help you assess compliance with the control; however, there often is not a 1:1 or complete match between a control and one or more platform feature. As such, Compliant in GCP refers only to the policies themselves; this doesn’t ensure you’re fully compliant with all requirements of a control. In addition, the compliance standard includes controls that aren’t addressed by any GCP platform features at this time. Therefore, compliance in GCP is only a partial view of your overall compliance status.

Q: I don’t need or understand what those security standards are, so why should I care about them?

A: Many small and medium businesses don’t need to be compliant with any of the mentioned standards, but the compliance will enable your Azure environment to be very secure and protected. The enablement and continuous monitoring of those security controls will give you confidence that your data is secure in the Cloud! As a best practice, we recommend to anyone having any workloads running in a public cloud like GCP, to use the CIS security standard as a baseline for securing their environment.

Q: I am interested in the initial assessment and enablement of those security controls, but I am not interested in the ongoing maintenance of the compliance: can you offer me only this service?

A: Short answer: Yes, but…without ongoing maintenance of your security compliance, your GCP environment will be very fast exposed to a lot of security risks. Cloud environments are very dynamic with resources and services/features being added, removed and modified quite often, so without keeping pace with all those changes, your initial security controls that we enabled will not be very effective.

Q: Could you perform a security assessment and remediation of any security flaws for the applications that we have running in GCP?

A: Not at this time, but we are always adding new services to our portfolio!

Q: Our environment is a hybrid environment with resources located on-premise and in GCP, would you be able to audit and propose a remediation plan for all the resources?

A: Short answer: No, we cannot. Long answer: enabling non-GCP resources for security auditing using GCP services, requires the installation of local agents on those resources and the use of third party software. We can assist and provide guidance in this situations, but the installation and distribution of the agents is your responsibility entirely.

Q: All the remediation tasks that are required to enable the security controls for any given standard, might disrupt our normal business or operational procedures that we have in place: how can we avoid any downtime and disruption of those procedures?

A: Our experienced security consultants will advise you if any of the changes required will require an outage or not. You will always have the final say as to when or if those changes are acceptable to the business. You can choose as well to perform the changes yourself. Our proposal for remediation of the non-compliant resources will include a priority list and a risk score, so you will always know where you should focus your technical resources.

Q: Could tell me more about the actual security checks that you will perform for my environment?

A: We are focusing our GCP security analysis on the following security domains:

  • Resource Management
    • GCP org hierarchy
    • Environments & resource isolation
    • Project creation
    • Resource provisioning
    • Organization policies
  • Identity, Authentication & Authorization
    • User & group management
    • Administrative roles
    • Authentication
    • Assigning IAM roles
  • Network Security
    • VPC architecture
    • Firewall rules
    • Network logging
    • VPC service controls
    • DDoS and WAF
    • Identity Aware Proxy
  • VM Security
    • VM identities
    • Remote access
  • Data security
    • Encryption key management
    • Cloud Storage security
    • BigQuery security
    • Cloud SQL security
    • Data Loss Prevention
  • Security operations
    • Logging
    • Monitoring
    • Policy scanning
    • Incident Response
  • Kubernetes security
    • GKE cluster provisioning
    • Secure cluster default configurations
    • Cluster IAM/RBAC
    • Container image building
    • Container lifecycle management
    • Container runtime security
    • Workload hardening and isolation
Windows 10 Experience at Multi-session Cost

WVD: Windows 10 Experience at Multi-session Cost

The first economic benefit for infrastructure is you can have Windows 10 experience at multi-session cost. It matters to you because with today’s VDI solutions you’ll have to either go with Windows Server RDS which compromises on user experience or Windows 10 single-session which compromises on cost; but with WVD, you can get both.

Let’s take a look at a customer migration scenario here.

If you are using Windows 10 single-session on-prem today for better user experience (against Windows Server RDS deployment), WVD is the best solution for you going forward because not only it provides local like Windows 10 experience for your end users but also saves you big bucks via multi-session deployment.

Lets see why.

For a single session deployment on the left hand side, you’ll need 1 small VM per user, which usually ends up with low utilization. In comparison, for a multi-session deployment in the middle pane, you can have a larger shared VM to support multiple users so that you have higher utilization. in addition to that, since you’ll have fewer VMs, you can also expect lower operational costs. As a result, you can expect your multi-session cost to be around 1/6 of your single-session cost as seen on the right hand side. This is the key differentiation of WVD as you will find no other solution in the marketplace that supports Windows 10 multi-session.

Windows 10 Experience at Multi-session Cost

Windows 10 Experience at Multi-session Cost