The CloudCasa elves has been busy in their workshop for the past few months, and in December we delivered a stocking full of brand-new Kubernetes data protection goodies just in time for the holidays!
As 2022 begins, it’s a great time to set resolutions for the coming year. Don’t worry, we don’t expect you to become a CrossFit guru or break world records on your Peloton. Instead, how about you set goals to improve your abilities as a secure developer? All too often, we choose resolutions that set ourselves up for failure. A better approach is to set realistic goals.
If you attended SnykCon 2021, you may remember our inaugural CTF: Fetch the Flag. In this CTF, TopLang was a web challenge of medium difficulty that we received a lot of positive feedback about. So for those of you that loved it, this write-up explains how our team internally approached tackling and solving this challenge. This challenge was a pretty typical example of what is known as an “oracle attack” using blind SQL injection.
Strictly following security best practices is the first step to cybersecurity. Although SSH is the industry standard for both security and efficacy for remote server access, as with any software, SSH is only as secure as configurations applied to the server and client configurations. In this article, we’ll explore five SSH best practices you should observe to boost the security of your infrastructure.
Audit logging for SSH is essential for system security, and it’s often an important part of compliance regulations. Developers and administrators should only be granted access to the resources they need, and a continuous monitoring system should be in place to ensure that they aren’t abusing that access.
Development teams are frequently under the gun to deliver software quickly, which is difficult to do without modern tools to build, test, and deploy applications efficiently. That’s why Atlassian’s Bitbucket Cloud — a Git-based source code repository service in the cloud that streamlines software development for collaborative teams — was built for both speed and efficiency. The challenge nearly all organizations face is ensuring development speed and security at the same time.
No matter your role in tech, you’ve probably already heard about, or dealt with, the ubiquitous Log4Shell vulnerability impacting a large number of Java applications. To help spread the latest info on this critical, zero-day vulnerability, we recently hosted a webinar to get everyone up to speed.
Since December 10, in a span of just 20 days, there have been four different vulnerabilities published against Log4j. Engineers who worked long hours to update their Log4j versions to 2.15.0 on December 11th, were told three days later that they needed to do it all over again and upgrade to version 2.16.0. This is not sustainable. And yet the risks are high. Looking backward, we see that Log4j has been vulnerable since 2013 to the kinds of attacks described in CVE-2021-44228.
I talk to a lot of engineers every day. SREs. Systems Architects. Security Engineers. What I am hearing from them is that they are moving away from passwords — both in their personal lives, opting for more secure forms of authentication like biometrics and second factors, and at work. It just doesn’t make sense anymore to protect your personal bank with a second factor, but to share around an SSH key to access critical server infrastructure.
