Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Today, we are facing an unprecedented situation. The COVID-19 pandemic is affecting everything we know -- our families, our businesses, our communities, and our way of life. In these tough times, many organizations have resorted to mandatory remote working for employees so they can still be productive and safe. Saas productivity tools like Zoom, Slack, G-Suite and Office 365 became seemingly mandatory in this new distributed workplace.

According to a recent Forrester report, the application security market will exceed $7 billion by 2023, with security scanning tools leading. Clearly, organizations increasingly understand that securing their application layer is important, and they are prepared to invest substantial resources in protecting it.

March 2020, the Coronavirus is pretty much everywhere. As I am writing these lines, the number of cases worldwide is 341,334 and 192 different countries have experienced infections.The world is fighting this epidemic and travel limitations are widely used in order to control the spread of the disease. While some say these restrictions are critical, others claim it to be ineffective and redundant. I am not an epidemiologist and will leave that analysis to the experts.

The first means to collect security-relevant information at Cloud SIEM Enterprise (CSE) was our Network Sensor. It was built to analyze network traffic and provide visibility beyond traditional SIEM's down to the network-level. Beyond organizing packets into flows, the sensor supports more advanced features such as decoding of common protocols, file carving, SSL certificate validation, OS fingerprinting, clustered deployment and more.

The Zero Trust approach to security is based not on where you are, but who you are. This model shifts the focus from network and perimeter-based security to identity-based access. In simple terms, this means: Zero Trust security provides a powerful approach to keeping an organization’s resources secure and usage auditable.

For the impatient, in this blog post, we’ll look into the problem of preparing a Kubernetes application to be deployed into a large number of Kubernetes clusters, even if you, the developer, do not have direct access to them all. The tutorial parts of this post will utilize Gravity 7.0, which you can download here. This version is in beta at the time of publication, so be sure to select pre-releases in the dropdown on the download page to access it.

Today, we are excited to announce the release of Gravity 7.0! Gravity is a tool for developers to package multiple Kubernetes applications into an easily distributable .tar file called a “cluster image”. A cluster image contains everything an application needs and it can be used for quickly creating Kubernetes clusters pre-loaded with applications from scratch or loading applications contained within an image into an existing Kubernetes cluster like OpenShift or GKE.

It has been slightly more than a month since Catalogic released KubeDR. Since then, we have been busy adding features and making improvements to the project inspired by all the feedback we’ve received from the community. We are very excited to share all the changes that went into KubeDR since its release on January 15. In the first release, we only supported a disaster recovery scenario restore by using a separate Python utility.