Useful Google Cloud Logs (Stackdriver) Query Filters

GKE create cluster

protoPayload.methodName="google.container.v1.ClusterManager.CreateCluster"

All GKE cluster logs

resource.type="gke_cluster"

Access transparency logs

logName="projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2Faccess_transparency"

OR

jsonPayload.@type="type.googleapis.com/google.cloud.audit.TransparencyLog"

Listing TLS cipher suites

Nmap will list the ciphersuites of a server, and do some warning about old ones:

nmap --script ssl-enum-ciphers -p 443 www.example.com

Gatekeeper/policycontroller kubectl cheat sheet

Gatekeeper/policycontroller cheat sheet.

List all the constraint templates

kubectl get constrainttemplates -l="configmanagement.gke.io/configmanagement=config-management"

Get the status of a particular constraint, including logged violations:

kubectl get k8sallowedrepos.constraints.gatekeeper.sh repo-is-gcr

Get the policy controller logs:

kubectl logs -n gatekeeper-system -l gatekeeper.sh/system=yes

Replacements for docker

 With docker changing its license and the general problem of running a super privileged daemon, I've been looking for alternatives. Here's what I've found to work.

Gcrane for interacting with registries:

go install github.com/google/go-containerregistry/cmd/gcrane@latest
export PATH="${HOME}/go/bin:$PATH"

gcrane pull ubuntu ubuntu.tar
gcrane push ubuntu.tar gcr.io/my-project/ubuntu
gcrane cp ubuntu gcr.io/my-project/ubuntu

Podman for building and pushing

sudo apt-get install podman

If you get this warning:

Reading allowed ID mappings: reading subuid mappings for user "${USER}" and subgid mappings for group "${USER}": no subuid ranges found for user "${USER}" in /etc/subuid

You need to add some UIDs:

sudo usermod --add-subuids ${start_uid:=100000}-$(( ${start_uid:=100000} + "65535" )) $(whoami)
sudo usermod --add-subgids ${start_gid:=100000}-$(( ${start_gid:=100000} + "65535" )) $(whoami)

Then you can use it:

podman build -t ${IMG}:${TAG} .

# Auth to an artifact registry repo
gcloud auth print-access-token | podman login -u oauth2accesstoken --password-stdin ${REGION}-docker.pkg.dev
podman push ${REGION}-docker.pkg.dev/${PROJECT}/${REPO}/${IMG}:${TAG}

# Run a container
podman run --rm -it alpine:latest /bin/sh

Unpatchable vulnerabilities detected by scanners

There's quite a lot of vulnerabilities in the NVD that aren't really vulnerabilities but may show up in vulnerability scanners depending on the behavior of the scanner. Here's some examples of open vulnerabilities (pulled from a debian container that's up-to-date at the time of writing) that just aren't vulnerabilities at all:

• We don't ship that vulnerable script in kerberos
• That's how tar works
• The default setting has blocked unknown username logging for more than a decade, you can change it for debugging.
• That's how glob works
• Not actually a vulnerability because URI isn't used
• Dual_EC_DRBG is unused/broken in OpenSSL

As raesene@ points out whether these show up in your container vulnerability scanner depends entirely on the scanner. Empirical testing shows that nessus filters out quite a lot of unactionable vulnerability scan results, whereas free scanners like Trivy, or even other paid scanners, don't. They take the approach of "show everything, but you can filter out the actionable vulns that have patches".

The second approach is the easiest and least controversial for the scanner implementor because they don't have to make any security decisions about what to show or not show. It effectively delegates the problem of filtering out the noise to the user. The first problem is that the default view is very noisy and it's not immediately obvious how to make it better, especially for practitioners coming from scanners that filter the noise up-front. It takes effort to get to a sensible view.

The second problem is that if you just filter vulns by which ones have patches, to eliminate the this-isn't-a-vuln entries from 2005, you may miss something important that isn't patched yet but that you should be mitigating with a workaround or settings change.

I don't think we're doing users any favors by continuing to put 18-year-old "vulnerabilities" that were never vulnerabilities in their scan results. It's harder to do, but I think a line should be drawn by the scanner as nessus does.

Other ancient unactionable vulnerabilities you'll see, in tools that don't filter up-front, are technically vulnerabilities but low enough severity that no-one has gotten around to fixing them for years. Some are incompatible with current software so there's no obvious fix without something like a new kernel syscall.

• Perl symlinks
• Shadow TOCTOU
• chroot with --userspec
• systemd and selinux

Should these be filtered out? From the user's, i.e. the scan consumer's, point of view they are basically useless. It's not like the average practitioner has the skills or time to go fix these, and even if they did the projects may just reject the fixes.

Showing them in tools, "i.e. many eyes", isn't exerting much pressure on getting them fixed because they are all multiple years old or completely abandoned. From a scanner implementor point of view the decision on whether to show them is more difficult, because unlike the first list these are real vulns, just not important ones that are going to be fixed inside of any kind of compliance SLO.

So should a scanner hide a "real" vuln? Or show the user an unpatchable vuln in their dashboard that may, depending on the user's specific compliance requirements, trigger a need to write monthly deviation requests forever? Tough choice.

GNOME desktop: disabling all the annoying stuff

 Sadly GNOME seems to be missing (or has removed) options to disable all of the annoying stuff it's doing.

To disable the stupid workspace switching animation you have to install an entire extension. I installed this one directly from github, the code is tiny, you can read it.

To turn off the hotcorner that I continually accidentally hit there is apparently no longer a UI option, but running:

gsettings set org.gnome.desktop.interface enable-hot-corners false

worked.

Annoyingly the UI control you do have is not anywhere intuitive like with GNOME in the name. It's in "tweaks" and "extensions".  Tweaks is where you can adjust font size, Extensions is where the workspace switching toggle shows up and also where you can disable the applications menu.

Quick summary of the cybersecurity executive order

Exec order is here, fact sheet summary. Good analysis from lawfare blog here.

• Share info on incidents (anything that impacts CIA according to 44 U.S.C. 3552(b)(2), which could be read incredibly broadly) by amending gov contractual language.
• Zero trust all the things. Make a plan to adopt zero trust as defined by NIST. It's basically defense in depth plus least privilege and seems about as likely to make progress as a result of this order as those general ideas have made in the last 15 years.
• Use FedRAMP to set a cloud security strategy and adopt new cloud security principles. FedRAMP will develop "cloud-security technical reference architecture documentation that illustrates recommended approaches to cloud migration and data protection for agency data collection and reporting."
• CISA to develop "a cloud services governance framework" which sounds like it's to help with gov IR: "identify a range of services and protections available to agencies based on incident severity".
• Gov agencies must identify and report sensitive unclass data. I interpret this as the beginning of a process to adjust thinking from "unclass data doesn't matter" to a more sensible data classification that isn't solely focused on impact to national security.
• MFA and "encryption at rest and in transit" within 180 days for all gov agencies. Reports every 60 days after.
• Train gov agencies on FedRAMP and automate fedramp comms/forms with CSPs. Map compliance requirements onto FedRAMP authorization requirements and rely on the compliance certs instead of re-doing work for FedRAMP.
• Publish secure software supply chain guidelines for "critical software" within 180 days, NIST to publish 90 days after that. Preview of requirements around providing purchaser a software bill of materials, proof of provenance, vuln disclosure etc. Format of BOM to be decided and go into contract language within a year. This whole section is very optimistic.
• Consider consumer labelling for IoT re secure supply chain. This isn't my field but if I was buying one of these devices I would love to know what the security patch frequency and EOL is.
• Build a cyber safety review board that looks at big incidents modeled after the NTSB. This is great.
• CISA to write an incident response playbook for all gov agencies. This might be helpful for agencies that have no such playbooks, and may be a hindrance for those that already have good agency-specific ones. A bad, and likely, outcome would be to force sophisticated response private sector companies to do worse security response because they need to follow the letter of the official government playbook.
• EDR initiative: "CISA, to engage in cyber hunt, detection, and response activities". They get access to all data they need to do it, without any pre-authorization. This seems big. The lawfare blog points out that "Congress actually granted CISA expanded (and clarified) centralized threat-hunting authority in Section 1705 of the fiscal 2021 National Defense Authorization Act". Will we see a gov EDR product that has to be able to run on all gov-owned infra, including cloud?
• Gov agencies need logs from CSPs and to be able to provide those logs to DHS for analysis. Logs need to be signed at export time to prove authenticity as they pass through multiple hands.
• Classified systems should do the same or better as this exec order, without upsetting the existing rules/authorities.