Operations | Monitoring | ITSM | DevOps | Cloud

While auditing the Kubernetes source code, I recently discovered an issue (CVE-2020-8566) in Kubernetes that may cause sensitive data leakage. You would be affected by CVE-2020-8566 if you created a Kubernetes cluster using ceph cluster as storage class, with logging level set to four or above in kube-controller-manager. In that case, your ceph user credentials will be leaked in the cloud-controller-manager‘s log.

Threat actors can move pretty fast. There are untold numbers of adversaries operating in the shadows looking for the next vulnerability they can exploit. Sometimes they find a vulnerability that hasn’t been identified by white-hat researchers or the vendors—resulting in a zero-day exploit—but most often they watch for public disclosures and updates from vendors to identify changes that have occurred in code.

Using open source code makes it easier to build applications, but the freely available nature of open source code introduces the risk of pulling potential security vulnerabilities into your environment. Knowing whether or not customers are actually accessing the vulnerable parts of your application is key to triaging security threats without spending hours fixing an issue that doesn’t affect end users.

Common Vulnerability Scoring System (CVSS) scores have been viewed as the de facto measure to prioritize vulnerabilities. Vulnerabilities are assigned CVSS scores ranging from one to 10, with 10 being the most severe. However, they were never intended as a means of risk prioritization. If you’ve relied on CVSS scores alone to safeguard your organization, here’s why you’re probably using them incorrectly.

An Elastic Security Advisory (ESA) is a notice from Elastic to its users of a new Elasticsearch vulnerability. The vendor assigns both a CVE and an ESA identifier to each advisory along with a summary and remediation details. When Elastic receives an issue, they evaluate it and, if the vendor decides it is a vulnerability, work to fix it before releasing a remediation in a timeframe that matches the severity.

While auditing the Kubernetes source code, I recently discovered an issue (CVE-2020-8563) in Kubernetes that may cause sensitive data leakage. You would be affected by CVE-2020-8563 if you created a Kubernetes cluster over vSphere, and enabled vSphere as a cloud provider with logging level set to 4 or above. In that case, your vSphere user credentials will be leaked in the cloud-controller-manager‘s log.

A critical Active Directory vulnerability (CVE-2020-1472) has been making headlines for being the most notorious elevation of privilege bug because it can affect all computers and domain controllers in an organization. This high-risk vulnerability, dubbed Zerologon, gives threat actors easy, instant access to domain controllers without requiring any additional privileges. This attack does not even require a user to be authenticated; the user just needs to be connected to the internal network.

Pop quiz: An employee just submitted a ticket to IT about recurring application crashes. When IT finally gets back to them, what is the first thing they ask? Answer: “When did you last update your device?” If this rings true, there is a reason. Outdated devices and applications can quickly detract from digital employee experience and IT notoriously struggles to detect and resolve these issues at scale.

Every day we discover new vulnerabilities in our systems, cracks in the fence the adversaries take advantage of to get into your organization and wreak havoc. Understanding what you have in your environment (e.g., types of devices, systems equipment, etc.) is very important in order to make sure the controls in place are working and more importantly, keeping up with the threat landscape.