We are excited to announce CloudCasa can now be deployed via a recipe to protect Kubernetes clusters managed via Rafay’s Kubernetes Operations Platform for Enterprises and MSPs.
As part of Teleport 8 we’ve made significant improvements to our routing, so much so the improvements have become a feature. Teleport 8 has new TLS routing that greatly reducing the port requirements needed for Teleport to run. Reducing the open network footprint down to a single port for your entire infrastructure and minimizing the attack surface. Want to know how we did it? Read on!
Due to the recently discovered Log4Shell vulnerability, and to support the tremendous effort being mounted by the community to address it, we are happy to announce that we are increasing the free test limit in Snyk Open Source! This means that any developer, no matter the company or project, can now use Snyk Open Source to find and fix Log4Shell with double the number of free tests, whether it’s within your IDE, your Git repositories, CI environments, or using the Snyk CLI.
During my time as a penetration tester, I’ve seen many IT teams storing server catalogs with respective IP addresses and passwords in a sharable Excel sheet. This is more so true in windows server infrastructure as many organizations resort to password-based auth for local and remote access. Of course, security-conscious organizations would use a password vault. But in any case, password storage in any form is often an Achilles heel in infrastructure security.
Last week, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.
At Snyk we have some general points of principle that we use to help guide our security thinking and decision making. Firstly, it is always important to understand from whom we are protecting, as it has implications for how we need to act. As an example of this, if our artefact is a web server, then we need to protect it against untrusted users. Whilst if our artefact is encryption software, then we clearly need to protect it even from users with physical access to the system.
