Combating Ransomware: Building a Strategy to Prevent and Detect Attacks

Forms of ransomware have been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

In this webinar, two experienced cybersecurity professionals—Associate Director of Development Bob Erdman and Principal Security Consultant Sandi Moore—go in-depth on the ransomware attack cycle, the need to protect every endpoint, and how to spot signs of infection before data is encrypted by malicious actors.

This webinar also reveals the current state of ransomware with 2021 Malware Survey results and provide effective security strategies for prevention, including:

Regular review of your security posture and processes
Segregation of backups to ensure data is secure
Prevention and deterrence programs to avoid infection
Detection methods to find threats that break through

Detect and neutralize threats to your IBM i, AIX, and Linux servers with a free virus scan: https://www.helpsystems.com/cta/scan-your-system

Top IBM i Security Vulnerabilities and How to Address Them

IT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i.

In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you’ll want to check out this session.

Download the State of IBM i Security Study here: https://www.helpsystems.com/cta/download-state-ibm-i-security-study-guide

Projects and the advantages of Git branching

It took me a while to start to understand the power that Red Hat OpenShift brings to the Kubernetes world. As someone who is supposed to advocate for OpenShift, I first need to know why I would use the technology before I can advocate. This post explains one of the value adds that got me. OK, let’s get started!

If you are someone who is encouraged or even required to move to the cloud-native ecosystem, running an application on Kubernetes (or OpenShift) can be overwhelming. If you visit the CNCF Cloud Native Interactive Landscape map and look at all the options you can plug into a vanilla Kubernetes, it’s safe to say that it’s intimidating. I am every time I look at it.

One of the first advantages of OpenShift is that it’s an opinionated deployment of Kubernetes. Red Hat spent the time and effort to create a proper production-grade installation of a cloud-native platform and gave you the power to just “use it”. You no longer need to sift through all of the different options; OpenShift just gives you the choices to focus on the business value add and to hopefully get your features out faster than your competition.

So what does this have to do with Git branching and projects? Let’s put ourselves in the mind of someone making those business value adds and see how just one feature (projects) enables them.

If you live in the development world, you probably collaborate on some code to help drive your business. You probably have something such as JIRA to track your tasks and hopefully work on an agile-style team. You probably adopted Git as your distributed version control systems (DVCS) and you are comfortable creating feature branches to merge back into your main branch when the feature is complete and ready to be deployed. You do this day in and day out and your development environment is probably something cut down to mimic as close as you can get to your production environment, but not 100% the same.

Projects are just “souped-up” namespaces in vanilla Kubernetes. They give you many benefits, including role-based access control (RBAC) that ties into other external access controls, quotas assigned to specific resources, and more substantial isolation with some tweaks to the setup. The one thing that moved me over the edge into understanding the power of this feature is the built-in, “ephemeral” nature of projects.

Let’s pretend that you have a ticket called BILLING-1234 and you need to put this feature into your application. There are a couple of projects in your OpenShift cluster called BILLING-PROD, BILLING-STAGING, and BILLING-DEV. BILLING-PROD is the production environment and you know that it’s there, but you can’t access it. BILLING-STAGING deploys a nightly build via continuous integration from your main branch and runs integration tests on it. Finally, BILLING-DEV is a shared DEVELOP environment in case your team needs to collaborate.

The first thing you must do is create a new feature branch, such as git checkout -b BILLING-1234. Now you must deploy it to your OpenShift cluster just to ensure that you have everything safely. Assuming that you have the correct permissions, you could quickly just type out oc new-project BILLING-1234-2021-06-15 and then deploy your app to it.

When you’re done with the feature add, you can make your pull request, deploy it to something such as BILLING-DEV to get more eyes on it, and then, if it’s merged into the main branch, maybe it can be deployed to BILLING-STAGING. Then, when you’re done with your work, you can quickly delete your project by using oc delete project BILLING-1234-2021-06-15 and start the process all over again.

Hopefully, this explanation highlighted the workflow and the natural compliment of using git feature branching and OpenShift projects. You could do some of this with vanilla Kubernetes, but that would require more extended setup and effort. Whereas, for a developer, if all of this is available on day one, you can focus on your value add to the business and grow your competitive edge.

Verified by MonsterInsights