Skip to content
Untitled design-Aug-24-2022-05-38-14-77-PM
Dominik RichterApril 11, 202324 min read

ICYMI: Mondoo Release Highlights for March 2023

Mondoo_graphics_ICYMI release march 23-01

Get started today!

Welcome to March 2023 release highlight of Mondoo.

We are excited to share with you the release of our SSPM solution, BigQuery Integration, along with several other significant improvements for this month:

Chapters

 

Mondoo Launches SaaS Security Posture Management (SSPM) Solution

We are thrilled to unveil our SaaS security posture management (SSPM) solution combined with xSPM capabilities and an open public registry of policies for SaaS. Our SSPM solution provides organizations with the assurance that their SaaS applications are secure and up-to-date. 
Mondoo’s open SSPM is based on a trusted open source foundation and helps continuous monitoring for misconfigurations of cloud-based SaaS applications.

Find out more in our blog post.

SSPM Blog Body Screenshot

 
Mondoo Agentless Integrations for Google Workspace and Okta

After agentless integrations for GCP, Azure, and MS365,  we're excited to announce that Mondoo now offers agentless continuous scanning for Google Workspace and Okta SaaS environments. With no downloads or installations required, you can easily set up integrations with service accounts or tokens to securely scan your SaaS services every 8 hours.

 

Mondoo Launches Google BigQuery Data Exports

Mondoo is excited to announce our integration with Google BigQuery, a game-changer for your security intelligence and insights! By combining Mondoo with Google BigQuery, we're creating a powerful team to enrich security data lakes and customize the security with full assessment. This means your security operations can quickly detect and respond to potential security incidents.

Exports are configured just like other integrations in Mondoo and run daily without the need to install anything into your infrastructure.

Once the data is exported it can be combined with other data in BigQuery and analyzed with BigQuery's machine learning and BI features.

Find out more in our blog post.

BigQuery Blog 2

 

UI Experience Enhancements

 

New vulnerabilities views

We've reworked our Vulnerabilities page to make it quicker to find vulnerabilities in your environment, identify the worst offending assets, and investigate newly released CVEs. A new Vulnerabilities menu now includes individual options for Advisories, CVEs, Affected Assets, and Mondoo Vulnerability Database (VMD).

The Advisories and CVEs pages allow you to dive into specific vendor security advisories and CVEs that impact your environment. You can see when these issues were first discovered, progress towards patching them, and get more details on the advisory/CVEs, including impacted assets.

The new Affected Assets page lets you quickly dive into assets with unpatched CVEs or vendor advisories in your space.

The completely reworked Mondoo Vulnerability Database (MVD) gives you a single UI to research new vendor CVEs and advisories even if they don't apply to your assets. Curious about that new CVE you read about online? Look it up to learn more, including details on the CVSSv3 score and any impacted assets in your environment.

Microsoft 365 assets grouped in the console

We improved the Fleet page so that Microsoft 365 assets are now grouped together, making it easier and faster to find them.

 

Find spaces more easily in large organizations

Finding a specific asset has been made easier with our new links to open individual organizations and alphabetical sorting of all spaces. This simplifies the process of locating an asset when you have a large number of organizations or spaces.

Login with a splash

With a splash of Mondoo purple and orange, we have redesigned our old login page to give you a more enhanced login experience.

Policy Updates

New and updated Kubernetes policies

Kubernetes moves fast, so ensuring your security policy matches the latest and greatest security recommendations is essential. Mondoo now includes the latest CIS benchmarks for Kubernetes distributions with updated auditing and remediation steps as well as new checks for the control plane in cloud distributions:

  • New: CIS Kubernetes V1.24 Benchmark 1.0

  • Updated: CIS Amazon Elastic Kubernetes Service (EKS) Benchmark 1.2

  • Updated: CIS Google Kubernetes Engine (GKE) Benchmark 1.3

  • Updated: CIS Azure Kubernetes Service (AKS) Benchmark 1.2

  • Updated: CIS RedHat OpenShift Container Platform v4 Benchmark 1.1

The CIS Google Kubernetes Engine (GKE) Benchmark policy has been enhanced with the following new checks and is now fully certified by CIS:

  • 5.1.1 Ensure Image Vulnerability Scanning using GCR Container Analysis or a third-party provider

  • 5.6.4 Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled

New Microsoft Workstation Security policy

Our all-new Microsoft Workstation Security policy provides security guidance for workstations running Windows 10 and 11.

New Linux and Windows Workstation Policies

We've updated the Linux and Microsoft Azure Security by Mondoo policy environment secure out of the box:

  • Updated Linux Workstation Security
    We expanded boot loader security to include permissions on /boot/loader/loader.conf so you can rest assured your boot sequence hasn't been tampered with.

  • Updated Linux Security Policy
    We improved the reliability of auditd package checks on some SUSE releases.

  • Ensure that App services can authenticate with Active Directory
  • Ensure that the Web App takes advantage of the latest version of TLS encryption
  • Ensure that the expiration date is set for all keys and secrets in key vaults
  • Ensure it is possible to recover key vaults
  • Ensure all operations on the key vault are logged
  • Ensure that activity log alerts exist for the commands Create, Update, and Delete Network Security Group
  • Ensure that "Notify about alerts with high severity" is enabled
  • Ensure SSL connection is enabled for PostgreSQL Database Server
  • Ensure SSL connection is enabled for MariaDB Database Server with the latest version
  • Ensure Public Network access for MariaDB is disabled
  • Ensure SSL connection is enabled for MySQL Database Server with the latest version
  • Ensure Public Network access for SQL Server is disabled or only possible through firewall rules
  • Ensure default Public Network access for Key Vault is disabled
  • Ensure that all activities on SQL Server are audited
  • Ensure that transparent data encryption is enabled on SQL Server
  • Ensure that diagnostic settings exist for the subscription
  • Ensure that Diagnostic Setting collects essential security categories
  • Ensure that direct UDP access to Azure Virtual Machines from the Internet is restricted

The CIS Microsoft Azure Foundations Benchmark policy has been updated from 1.5 to 2.0. This new release includes reworked audit and remediation steps that match Azure's latest UI and CLI experiences.

Expanded Google Workspace policy

We've updated our Google Workspace Security by Mondoo policy with three new checks:

  • Ensure more than one user has Super Admin permissions
  • Users should not be allowed less secure app access
  • Super users should use hardware-based security keys

Slack Team Security by Mondoo policy

Mondoo now includes a new Slack Team Security policy with seven checks to secure your Slack Team (Workspace):

  • Ensure that between 2 and 4 users have admin permissions
  • Ensure that admins use the most secure 2FA method
  • Ensure all users use 2FA
  • Use clear naming for external channels
  • Ensure there is at least one internal channel per workspace
  • Ensure there is at least one internal channel in the workspace and there are no external members
  • Ensure domain whitelisting is enforced on internal channels

New Okta Security policy enhancements

We have shipped continuous Okta scanning integration in the Mondoo Console. Now we have a new Mondoo security policy and improvements to Okta MQL resources so you can secure your Okta environment in just minutes.

Our new Okta Security Policy by Mondoo includes 11 checks to keep your Okta environment secure out of the box:

  • Ensure MFA is active for everybody accessing the Okta platform

  • Ensure a limited session lifetime has been enforced

  • Ensure OpenID or SAML authentication is used for app access

  • Ensure normal users cannot unlock themselves

  • Ensure Secure Web Authentication (SWA) is disabled for critical apps

  • Ensure the option "at every sign-in" is enabled for MFA

  • Ensure "Persist session cookies across browser sessions" is disabled

  • Ensure the users with Super Admin rights are limited to 3

  • Ensure the strong factor is used for MFA

  • Ensure that MFA is configured to use password/IdP plus another authentication factor

  • Ensure the "Password/IdP plus Another" factor is chosen for MFA

VMware vCenter Incident Response Pack

  • New VMware vCenter Incident Response Pack
    Gather critical information on your vSphere and ESXi systems in the event of a security incident with this new incident response pack.

CLI Improvements

 

Scan GCP orgs, projects, and folders

Mondoo has you covered for inspecting any of your GCP infrastructure, from your entire organization to a single folder:

cnquery scan gcp org 342423 # <-- scan GCP organization
cnquery scan gcp project mondoo-dev # <-- scan GCP project
cnquery scan gcp folder 3421423 # <-- scan GCP folder

 

Support for connecting to IPv6 hosts

We've updated both cnquery and cnspec to connect to IPv6 hosts directly over SSH or using Ansible inventory files.

cnquery shell ssh chris@fd00::20c:30ff:fe8a:9da0 --ask-pass
Enter password:
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1
___ _ __ __ _ _ _ ___ _ __ _ _
/ __| '_ \ / _` | | | |/ _ \ '__| | | |
| (__| | | | (_| | |_| | __/ | | |_| |
\___|_| |_|\__, |\__,_|\___|_| \__, |
mondoo™ |_| |___/ interactive shell

cnquery>

Specify GCP and Google Workspace credential path

You can now specify the path to your GCP or Google Workspace credentials using a new --credentials-path flag. Shell environmental variables will continue to take precedence when defining the path, but this is a great method of setting the path if you don't have shell ENV vars set.

With env var:

GOOGLE_APPLICATION_CREDENTIALS=~/mondoo-dev-1111111.json cnquery shell gcp 

With --credentials-path:

cnquery shell gcp --credentials-path ~/mondoo-dev-1111111.json

Improved scan error output

Gone are cryptic asset connection error messages when scanning multiple assets! In their place you now see better formatted and parsed error messages that make it easier to track down exactly why assets can't be scanned.

 

Homebrew now installs cnspec/cnquery along with Mondoo

The Mondoo Homebrew tap now installs both cnquery and cnspec as dependencies, giving you the complete power of Mondoo in one installation.

 

MQL and Resources Updates

Secure your GKE Control Plane

Cloud Kubernetes security extends beyond the kubelet and cluster workloads, so we've added new data-gathering capabilities for the GKE control plan. Use this new data to take inventory of your GKE configuration or to write custom security policies for your organization.

  • addonsConfig

  • nodePools management

  • Cluster networkConfig

  • Cluster workloadIdentityConfig

  • ipAllocationPolicy

  • binaryAuthorization

  • legacyAbac

  • masterAuth

Cluster addonsConfig
cnquery> gcp.project.gke.clusters{ addonsConfig{*} }
gcp.project.gke.clusters: [
  0: {
    addonsConfig: {
      horizontalPodAutoscaling: {
        disabled: false
      }
      id: "gcp.project.gkeService.cluster/12345/addonsConfig"
      gkeBackupAgentConfig: {}
      gcePersistentDiskCsiDriverConfig: {
        enabled: true
      }
      networkPolicyConfig: {
        disabled: false
      }
      gcpFilestoreCsiDriverConfig: {
        enabled: false
      }
      dnsCacheConfig: {
        enabled: false
      }
      httpLoadBalancing: {
        disabled: false
      }
      kubernetesDashboard: {
        disabled: true
      }
      configConnectorConfig: {}
      cloudRunConfig: {}
    }
  }
]
Cluster nodePools management
cnquery> gcp.project.gke.clusters{ nodePools{ management } }
gcp.project.gke.clusters: [
  0: {
    nodePools: [
      0: {
        management: {
          autoRepair: true
          autoUpgrade: true
          upgradeOptions: {}
        }
      }
      1: {
        management: {
          autoRepair: true
          autoUpgrade: true
          upgradeOptions: {}
        }
      }
    ]
  }
]
Cluster networkConfig
cnquery> gcp.project.gke.clusters{ networkConfig{*} }
gcp.project.gke.clusters: [
  0: {
    networkConfig: {
      enableL4IlbSubsetting: false
      id: "gcp.project.gkeService.cluster/12345/networkConfig"
      dnsConfig: {}
      serviceExternalIpsConfig: {
        enabled: false
      }
      subnetworkPath: "projects/project-1/regions/us-central1/subnetworks/mondoo-gke-cluster-2-subnet"
      privateIpv6GoogleAccess: "PRIVATE_IPV6_GOOGLE_ACCESS_UNSPECIFIED"
      datapathProvider: "DATAPATH_PROVIDER_UNSPECIFIED"
      networkPath: "projects/project-1/global/networks/mondoo-gke-cluster-2"
      subnetwork: gcp.project.computeService.subnetwork name="mondoo-gke-cluster-2-subnet"
      enableIntraNodeVisibility: false
      defaultSnatStatus: {
        disabled: false
      }
      network: gcp.project.computeService.network name="mondoo-gke-cluster-2"
    }
  }
]
Cluster workloadIdentityConfig
cnquery> gcp.project.gke.clusters{ workloadIdentityConfig }
gcp.project.gke.clusters: [
  0: {
    workloadIdentityConfig: {
      workloadPool: "mondoo-edge.svc.id.goog"
    }
  }
]
Cluster ipAllocationPolicy
cnquery> gcp.project.gke.clusters{ ipAllocationPolicy{*} }
gcp.project.gke.clusters: [
  0: {
    ipAllocationPolicy: {
      id: "gcp.project.gkeService.cluster/12345/ipAllocationPolicy"
      stackType: "IPV4"
      tpuIpv4CidrBlock: ""
      useRoutes: false
      createSubnetwork: false
      nodeIpv4CidrBlock: ""
      subnetworkName: ""
      servicesSecondaryRangeName: "cluster-2-ip-range-svc"
      useIpAliases: true
      clusterSecondaryRangeName: "cluster-ip-range-pods"
      clusterIpv4CidrBlock: "10.20.0.0/16"
      ipv6AccessType: "IPV6_ACCESS_TYPE_UNSPECIFIED"
      servicesIpv4CidrBlock: "10.30.0.0/16"
    }
  }
]
Cluster binaryAuthorization
cnquery> gcp.project.gke.clusters{ binaryAuthorization }
gcp.project.gke.clusters: [
  0: {
    binaryAuthorization: {
      enabled: false
      evaluationMode: "EVALUATION_MODE_UNSPECIFIED"
    }
  }
]
Cluster legacyAbac
cnquery> gcp.project.gke.clusters{ legacyAbac }
gcp.project.gke.clusters: [
  0: {
    legacyAbac: {
      enabled: false
    }
  }
]
Cluster masterAuth
cnquery> gcp.project.gke.clusters{ masterAuth }
gcp.project.gke.clusters: [
  0: {
    masterAuth: {
      clientCertificate: ""
      clientCertificateConfig: {}
      clientKey: ""
      clusterCaCertificate: "***"
      password: ""
      username: ""
    }
  }
]

 

Identify public IPs in Azure

Identifying publicly exposed assets is critical to securing your cloud infrastructure. 

Use the new publicIpAddresses data available in the azure.subscription.computeservice.vm and azure.subscription.networkservice to quickly identify assets that may be incorrectly publicly exposed.

Identify all public IP addresses in a subscription:

cnquery> azure.subscription.network.publicIpAddresses{*}
azure.subscription.network.publicIpAddresses: [
  0: {
    name: "super-cool-public-ip"
    id: "/subscriptions//resourceGroups//providers/Microsoft.Network/publicIPAddresses/"
    location: "uksouth"
    tags: {}
    ipAddress: "255.255.255.255"
  }
]

Identify public IP addresses on specific VMs:

cnquery> azure.subscription.compute.vms{publicIpAddresses{*}}
azure.subscription.compute.vms: [
  0: {
    publicIpAddresses: [
      0: {
        name: "super-cool-public-ip"
        id: "/subscriptions//resourceGroups//providers/Microsoft.Network/publicIPAddresses/"
        location: "uksouth"
        tags: {}
        ipAddress: "255.255.255.255"
      }
    ]
    name: "vm-name"
  }
]

 

New Azure resources

cnspec and cnquery now ship with additional Azure resources so you can inventory and secure all aspects of your Azure infrastructure:

Azure.subscription.monitor.applicationinsights​

This new Azure resource lets you query each instance of Application Insights.

cnquery> azure.subscription.monitor.applicationInsights
azure.subscription.monitor.applicationInsights: [
  0: azure.subscription.monitorService.applicationinsight id = /subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/microsoft.insights/components/app-insight-test
]
cnquery> azure.subscription.monitor.applicationInsights {name kind location}
azure.subscription.monitor.applicationInsights: [
  0: {
    name: "app-insight-test"
    location: "centralus"
    kind: "web"
  }
]
 
azure.subscription.network.bastionHost​

This new Azure resource lets you query all bastion hosts, including their names, locations, and product SKUs.

cnquery> azure.subscription.network.bastionHosts
azure.subscription.network.bastionHosts: [
  0: azure.subscription.networkService.bastionHost id="/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/Microsoft.Network/bastionHosts/test-bastion-host" name="test-bastion-host" location="uksouth"
]
cnquery> azure.subscription.network.bastionHosts{name location sku}
azure.subscription.network.bastionHosts: [
  0: {
    name: "test-bastion-host"
    sku: {
      name: "Standard"
    }
    location: "uksouth"
  }
]
 
azure.subscription.sql.virtualNetworkRule​

This new Azure resource lets you query the virtual network rules on an SQL server and is similar to firewall rules resources.

cnquery> azure.sql.servers[1].virtualNetworkRules{*}
azure.sql.servers[1].virtualNetworkRules: [
  0: {
    id: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/Microsoft.Sql/servers/sql-server-mondoo-test/virtualNetworkRules/newVnetRule1"
    properties: {
      id: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/cloud-shell-storage-westeurope/providers/Microsoft.Sql/servers/sql-server-mondoo-test/virtualNetworkRules/newVnetRule1"
      name: "newVnetRule1"
      properties: {
        ignoreMissingVnetServiceEndpoint: false
        state: "Ready"
        virtualNetworkSubnetId: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/DefaultResourceGroup-CUS/providers/Microsoft.Network/virtualNetworks/prelav-test-VN/subnets/default"
      }
      type: "Microsoft.Sql/servers/virtualNetworkRules"
    }
    virtualNetworkSubnetId: "/subscriptions/f1a2873a-6b27-4097-aa7c-3df51f103e96/resourceGroups/DefaultResourceGroup-CUS/providers/Microsoft.Network/virtualNetworks/prelav-test-VN/subnets/default"
    type: "Microsoft.Sql/servers/virtualNetworkRules"
    name: "newVnetRule1"
  }
]
 
Azure.subscription.cosmosdb​

This new Azure resource lets you query the Azure Cosmos DB service.

Query databases:

cnquery> azure.subscription.cosmosDb.accounts
azure.subscription.cosmosDb.accounts: [
  0: azure.subscription.cosmosdbService.account name="test-cosmosdb-mondoo" location="West US"
  1: azure.subscription.cosmosdbService.account name="test-mondoo-cassandra" location="West US"
]

Write assertions to secure configuration:

cnquery> azure.cosmosDb.accounts{properties['isVirtualNetworkFilterEnabled'] name}
azure.cosmosDb.accounts: [
  0: {
    properties[isVirtualNetworkFilterEnabled]: true
    name: "test-cosmosdb-mondoo"
  }
  1: {
    properties[isVirtualNetworkFilterEnabled]: true
    name: "test-mondoo-cassandra"
  }
]

 

Query Google Workspace connected apps

You can now fetch Google Workspace connected apps with a new googleworkspace.connectedApps MQL resource:

googleworkspace.connectedApps { name clientid }
googleworkspace.connectedApps: [
  0: {
    clientId: "11234434534-abcdefg.apps.googleusercontent.com"
    name: "Slack"
  }
  ...
]

You can also filter this data to return specific connected apps:

googleworkspace.connectedApps.where( name == /Slack/) { * }
googleworkspace.connectedApps.where: [
  0: {
    users: [
  0: googleworkspace.user primaryEmail="user1@example.com"
    ]
    tokens: [
  0: googleworkspace.token displayText="Slack"
    ]
    scopes: [
      0: "https://www.googleapis.com/auth/activity"
      1: "https://www.googleapis.com/auth/drive.activity"
      2: "https://www.googleapis.com/auth/userinfo.profile"
      3: "https://www.googleapis.com/auth/userinfo.email"
      4: "openid"
      5: "https://www.googleapis.com/auth/calendar.readonly"
      6: "https://www.googleapis.com/auth/drive"
      7: "https://www.googleapis.com/auth/calendar.events"
    ]
    name: "Slack"
    clientId: "11234434534-abcdefg.apps.googleusercontent.com"
  }
  1: {
    users: [
  0: googleworkspace.user primaryEmail="user1@example.com"
  1: googleworkspace.user primaryEmail="user2@example.com"
  2: googleworkspace.user primaryEmail="user3@example.com"
  3: googleworkspace.user primaryEmail="user4@example.com"
    ]
    tokens: [
  0: googleworkspace.token displayText="Slack"
  1: googleworkspace.token displayText="Slack"
  2: googleworkspace.token displayText="Slack"
  3: googleworkspace.token displayText="Slack"
    ]
    scopes: [
      0: "https://www.googleapis.com/auth/userinfo.profile"
      1: "https://www.googleapis.com/auth/userinfo.email"
      2: "openid"
    ]
    name: "Slack"
    clientId: "3321342421-abcdefg.apps.googleusercontent.com"
  }
  2: {
    users: [
  0: googleworkspace.user primaryEmail="user1@example.com"
  1: googleworkspace.user primaryEmail="user2@example.com"
  2: googleworkspace.user primaryEmail="user3@example.com"
  3: googleworkspace.user primaryEmail="user4@example.com"
    ]
    tokens: [
  0: googleworkspace.token displayText="Slack"
  1: googleworkspace.token displayText="Slack"
  2: googleworkspace.token displayText="Slack"
  3: googleworkspace.token displayText="Slack"
    ]
    scopes: [
      0: "https://www.googleapis.com/auth/userinfo.profile"
      1: "https://www.googleapis.com/auth/userinfo.email"
      2: "openid"
    ]
    name: "Slack"
    clientId: "6060606090-abcdefg.apps.googleusercontent.com"
  }
]

 

Python packages inspection

Outdated packages don't end at the operating system, so we've introduced our first application package resource with the python.packages MQL resource. This new resource discovers packages automatically on macOS, Windows, and Linux in the following locations:

  • /usr/local/lib/python/*

  • /usr/local/lib64/python/*

  • /usr/lib/python/*

  • /usr/lib64/python/*

  • /opt/homebrew/lib/python/*

  • C:/Python/*

  • /System/Library/Frameworks/Python.framework/Versions

  • /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions

Each package returns data similar to this pytz package:

cnquery> python.packages[0]{ * }
python.packages[0]: {
  author: "Armin Ronacher"
  name: "Babel"
  dependencies: [
  0: python.package name="pytz" version="2022.7.1"
  ]
  summary: "Internationalization utilities"
  id: "/usr/lib/python3.11/site-packages/Babel-2.10.3-py3.11.egg-info/PKG-INFO"
  file: file path="/usr/lib/python3.11/site-packages/Babel-2.10.3-py3.11.egg-info/PKG-INFO" size=1283 permissions.string="-rw-r--r--"
  license: "BSD"
  version: "2.10.3"
}

To query a specific package on disk you can provide the path to the METADATA file:

cnquery> python.package("/home/jdiaz/.local/lib/python3.11/site-packages/python_ftp_server-1.3.17.dist-info/METADATA"){ * }
python.package: {
  version: "1.3.17"
  summary: "Command line FTP server tool designed for performance and ease of use."
  file: file path="/home/jdiaz/.local/lib/python3.11/site-packages/python_ftp_server-1.3.17.dist-info/METADATA" size=1186 permissions.string="-rw-r--r--"
  author: "Vadym Stupakov"
  dependencies: data is not a map to auto-expand
  id: "/home/jdiaz/.local/lib/python3.11/site-packages/python_ftp_server-1.3.17.dist-info/METADATA"
  license: "MIT"
  name: "python-ftp-server"
}

This is the first of many new application package resources we plan to introduce, allowing you to audit and secure your application dependencies. If you have particular application packaging systems you want to see in cnquery and cnspec, be sure to let us know on our GitHub Discussions page.

Expanded support for AWS ECS in MQL

In this release we've greatly expanded MQL's AWS ECS support with new data and resources:

  • aws.ecs.task now includes platformVersion data.

  • aws.ecs.container now includes platformVersion, runtimeId, and containerName data.

  • aws.ecs.cluster now includes containerInstances data.

  • aws.ecs.image now includes uri data exposing the URI of the image repository.

  • New aws.ecs.instance resource.

More AWS ElasticCache data in MQL

We've deprecated aws.elasticache.clusters in favor of a new aws.elasticache.cacheClusters resource that presents cluster data in an easier to consume format.

cnquery> aws.elasticache.cacheClusters { * }
aws.elasticache.cacheClusters: [
  0: {
    arn: "arn:aws:elasticache:us-east-1:ID:cluster:vjtest-001"
    notificationConfiguration: ""
    cacheSubnetGroupName: "vjtest"
    atRestEncryptionEnabled: false
    logDeliveryConfigurations: []
    ipDiscovery: "ipv4"
    authTokenLastModifiedDate: null
    numCacheNodes: 1
    engine: "redis"
    networkType: "ipv4"
    region: "us-east-1"
    securityGroups: []
    transitEncryptionMode: ""
    cacheNodeType: "cache.t3.medium"
    engineVersion: "7.0.7"
    preferredAvailabilityZone: "us-east-1c"
    transitEncryptionEnabled: false
    cacheClusterId: "vjtest-001"
    authTokenEnabled: false
    snapshotRetentionLimit: 0

 

Policy variants

Sometimes queries differ slightly when executed in different environments. This can happen with:

  • Highly related queries, like OS checks that run differently on physical servers than they do on containers
  • Queries that test for similar things on entirely different targets

Let's take a look at the latter example:

queries:
  - uid: no-public-ip
    title: No public IPs are allowed on internal instances
    variants:
      - uid: no-public-ip-aws
      - uid: no-public-ip-terraform-aws
  - uid: no-public-ip-aws
    mql: |
      aws.ec2.instances.all( publicIp == "" )
    filters: |
      asset.platform == "aws"
  - uid: no-public-ip-terraform-aws
    mql: |
      terraform.resources.
        where( nameLabel == "aws_instance" ).
        all( arguments['associate_public_ip_address'] != true )
    filters: |
      asset.platform == "terraform-hcl"

This query ensures that “No public IPs are allowed on internal instances.” This query is implemented in two different ways: one for the AWS API (no-public-ip-aws) and one for Terraform (no-public-ip-terraform-aws). You can run this check against both AWS accounts and Terraform files and get consistent reporting.

Additionally, this addresses a common use case where there's a split between things that happen in development and things that run in production. If you have separate tools in different environments, or even separate policies, you previously had to manage exceptions to certain checks across both ends of the lifecycle. Now with variants, you can instead define exceptions on the combined check, making sure that they are treated consistently between development and production.

New Okta MQL enhancements

If you want to define your own business policies for Okta, you're in luck. We've improved our Okta MQL policies, giving your access to more information on your environment:

  • Gather okta.role and user.roles, allowing you to query which roles are assigned to a user
  • Gather access policy rules

  • Fix okta.trustedOrigin.scopes parsing

Kubernetes namespace scoped scanning

You can now scan a single namespace in a Kubernetes cluster even if you don't have access to resources outside that namespace. This allows you to scan all workloads in your namespace and browse asset relationships under the namespace in the Mondoo Console.

Example cnquery query against a single namespace:

./cnquery run k8s --namespaces default -c "k8s.pods" --discover namespaces
→ loaded configuration from /Users/ivanmilchev/.config/mondoo/mondoo.yml using source default
→ discover related assets for 1 asset(s)
→ resolved assets resolved-assets=1
k8s.pods: [
  0: k8s.pod namespace="default" name="nginx" created=2023-03-14 16:59:07 +0100 CET
]

 

etcd database encryption state in gcp.project.gke.cluster resource

The gcp.project.gke.cluster resource now includes information on encryption of the etcd database.

cnquery> gcp.project.gke.clusters[0]{databaseEncryption}
gcp.project.gke.clusters[0]: {
  databaseEncryption: {
    keyName: "projects/***/locations/us-central1/keyRings/***/cryptoKeys/***"
    state: "ENCRYPTED"
  }

 

2FA type in slack.users resource

The slack.users resource now includes the type of two-factor authentication (2FA) used by users. This lets you query which users are configured for insecure SMS vs. more secure app-based 2FA.

cnquery> slack.users.where( has2FA == true ){ has2FA twoFactorType }
slack.users.where.list: [
  0: {
    twoFactorType: "app"
    has2FA: true
  }
]

 

Other New Features

Red Hat Universal Base Image cnspec containers on Docker Hub

We are now publishing Red Hat Universal Base Image-based cnspec and cnquery containers to Docker Hub. These containers are perfect for running cnspec and cnquery in OpenShift clusters. You can find these images along with our standard Alpine-based images at https://hub.docker.com/r/mondoo/cnspec and https://hub.docker.com/r/mondoo/cnquery.

Smaller installation size

The Mondoo package has been optimized to reduce the space on disk consumed by Mondoo, cnquery, and cnspec commands. The legacy Mondoo CLI is now 200MB smaller on all platforms. Additionally, the cnquery and cnspec CLIs are each ~150MB smaller on Windows systems.

All macOS binaries are now signed and notarized

We now sign and notarize all binaries for macOS, not just those installed with the Mondoo .pkg file. This means no matter where you consume Mondoo packages, you will always have a fully secured binary that passes all of Apple's security requirements.

Set a proxy server for all Mondoo Platform communication

Problem There was no way to isolate cnspec-to-Mondoo-Platform and cnquery-to-Mondoo-Platform communication from non-Mondoo traffic.

Solution A new --api-proxy config flag allows you to specify the proxy server for Mondoo Platform API calls when you register an asset with the cnspec login command. You can also manually add the api_proxy configuration option in your mondoo.yml config.

Fewer API calls in the AWS Lambda integration

We've optimized our Lambda-based AWS integration to reduce the number of API calls made by the integration to reduce Lambda costs. Don't worry; you'll still get the same great AWS resource scans, but now with added efficiency.

 

🐛 Other Improvements


  • We now correctly detect services on Kali Linux.
  • Mondoo EOL policy now executes on FreeBSD hosts.

  • cnquery run and cnspec run now properly load Mondoo Platform config to support EOL and package vulnerability queries.

  • Fix parsing of timestamps in Google Workspace.

  • Fix setup instructions for Windows on the Integrations page to copy/paste correctly.

  • Add missing breadcrumbs to the Vulnerabilities page.

  • Add form validation to the GCP and Okta Integration setup pages.

  • Don't report successful vulnerability scanning on an asset when zero packages were discovered.

  • Fix incorrect quoting in the GitLab Docker scanning example

  • Don't show the hour when reporting an EOL date for an asset.

  • Fix incorrect GCP project ID validation in the GCP integration setup page.

  • If an integration has never scanned, then display Never instead of Jan 01, 0001.

  • Update links on integration pages to go to specific documentation.

  • Use the latest Microsoft 365 logo on the integrations page.

  • Improve performance of container image scanning in the Mondoo Kubernetes Operator.

  • Update tabs on asset pages to match the new navigation UX.

  • Add the missing Okta token field to the Okta integration setup page.

  • Link to new CloudShell documentation in the AWS integration setup wizard.

  • Fix GCP console links in the GCP integration setup page to load properly when logged out of GCP.

  • Specify UDP or TCP in the ports.listening resource so specific protocols can be queried instead of just ipv4/ipv6.

  • Resolve failures scanning container registries.

  • Label container image assets with all discovered tags when scanning container registries.

  • Don't fail an entire AWS account scan when a single service has a region restriction set.

  • Fail better when a Kubernetes namespace cannot be scanned due to permissions failures.

  • Fix cnspec bundle format failure introduced in 8.0.

  • Update the scanning progress bar to make it more clear when an asset was not scored.

  • Fix console login page text field text color to be black.

  • Fix console login page links to user agreement and privacy policy to load in new windows.

  • Don't display 0 Others for Azure assets in the fleet page.

  • Fix off-center spinner loaders on the integration pages.

  • Rename "Latest Advisories" on the overview page to be "Top Advisories" to better match what the widget shows.

  • Show accurate billing plan data in the console.

  • Improve rendering on the welcome page on small displays.

  • Fix failure if the ps command column has no data and warn if data otherwise can't be parsed correctly.

  • Fix failures setting the AWS integration.

  • Fix parsing of policies with arrays of remediations instead of simple strings.

  • Improve the audit/remediation steps in Mondoo security policies.

  • Update cnspec bundle lint and cnspec bundle fmt commands to support the Mondoo version 8.0+ policy structure.

  • Update the Ensure events that modify the system's Mandatory Access Controls are collected query in the Linux Security by Mondoo policy to support either SELinux or AppArmor. Thanks @micheelengronne!

  • Improve reliability of queries in the Okta Organization Security by Mondoo policy.

  • Replace mondoo shell with cnspec shell in some policy audit instructions.

  • Improve remediation steps in Mondoo Azure, Google, and AWS policies.

  • Fix cnspec bundle fmt removing scoring_system from policies when converting between 7.x and 8.x formats.

  • Fix cnspec bundle fmt not properly parsing typed docs.

  • When scanning Kubernetes manifests containing resources without a namespace, don't create an unnamed namespace asset as the parent.

  • Fix failures querying Azure Cloud Defender security contacts when none exist.

  • Fix failure running github.organization {*} query.

  • Fix CVSS aggregated score calculation in the platform.advisories resource.

  • Fix some CIS Kubernetes policies not displaying in the Policy Hub.

  • Improve ad-hoc scan instructions in AWS/Azure/GCP policies.

  • Update CIS Azure AKS v.1.2 Pod Security Policy checks to only execute on Kubernetes < 1.25.

  • Update Linux Security by Mondoo policy's Ensure events that modify the system's Mandatory Access Controls are collected check to expect a trailing slash in directories. Thanks @micheelengronne!

  • Remove the running and unknown states shown in asset names in the console, which did not consistently or correctly show asset scan status.

  • Add missing impact scores to Windows Security by Mondoo policy.

  • Fix the Kubernetes Operator not immediately scanning newly deployed workloads in a cluster.

  • Update wording on the Azure and MS365 integration pages to make it more clear that the .pem file needs to include both the certificate and the private key.

Get started today!

avatar

Dominik Richter

Dom is a founder, coder, and hacker and one of the creators of Mondoo. He helped shape the DevOps and security space with projects like InSpec and Dev-Sec.io. Dom worked in security and automation at companies like Google, Chef, and Deutsche Telekom. Beyond his work, he loves to dive deep into hacker and nerd culture, science and the mind, and making colorful pasta from scratch.

RELATED ARTICLES

view raw