The Veeam Community Weekly Recap is available with incredible content and relevant information! Congratulations to Nico Losschaert, Brad Linch, Christian Eromosele, and Philippe Dupuis for the posts and articles.
Thanks so much to Madalina Cristil, Mark Boothman, and Safiya Mohamed for the opportunity to participate! I am honored.
The first version of Magic Quadrant for Container Management is around! If we compare the companies named leaders by Gartner with those that contributed most to the Kubernetes project last year, we will realize that they are practically the same. Coincidence? I don’t think so.
These solutions deliver many Cloud Native Computing Foundation (CNCF) projects alongside Kubernetes distributions, like service mesh, security, observability, etc. Container management is a foundation for cloud-native infrastructure and helps enterprises automate container image provisioning, operation, and life cycle management at scale.
Protect these platforms with app and data protection solutions like Veeam Kasten!
As announced in VeeamON 2023, Veeam is working to improve the ransomware detection capabilities in two ways:
Comparing guest file system indexes and looking for typical traces of malware
AI/ML to perform an in-line entropy analysis of the data stream on backup proxies to detect previously unencrypted data becoming encrypted.
Some Ransomware detection techniques exist, but many have a poor detection rate. They also suffer from having high false positive rates, where they flag benign programs as malicious, and false-negative rates, and thus fail to identify malicious programs.
The same applies to files where obfuscation techniques have been used by ransomware in an attempt to avoid signature detection. One of the most common techniques used is a CRC, which involves analysis of the value and position of a data group.
On the other hand, detection techniques like Behavioral and Dynamic analysis must collect significant amounts of information. At the same time, monitoring has the disadvantage that it can consume a large amount of system resources.
Example of Entropy analysis associated with Machine Learning and AI
With the advance of Machine Learning and Artificial Intelligence technologies, new ransomware detection/protection techniques are being built, associating these techniques with entropy.
Entropy is a concept that emerged with Thermodynamics and was established by Rudolf Clausius in 1854. Clausius was an American mathematician, electrical engineer, computer scientist, and cryptographer known as the “father of information theory.”
In technology, entropy can be described as a measure of randomness within a data set.
The file entropy analysis was useful because ransomware-encrypted files have a characteristic of increasing entropy.
There are several methods to calculate entropy, and as a reference, NIST published NIST 800-90b and provided methods and tools that can be used for this purpose.
However, just measuring file entropy is no longer enough. New ransomware attacks use encoding algorithms, such as base-64, which allow the entropy index not to increase even if the files are encrypted.
At this point, techniques complementary to entropy come into play.
For example, we have an exciting paper published in IEEE Xplore entitled “Machine Learning Based File Entropy Analysis for Ransomware Detection in Backup Systems.”
In this document, the authors propose a method to detect ransomware-infected files synchronized to the backup system. I will not go into the details of the article, as it can be read and accessed at the link below.
The study uses the following machine learning models: K-Nearest Neighbors (KNN), linear model, decision tree, decision tree ensemble, kernel trick, and deep learning.
In addition, model evaluation is deployed. The evaluation models include cross-validation, cross-validation splitter, Leave-One-Out (LOOCV), and shuffle split cross-validation.
Here is a brief description of how this proposed method works:
“The backup system uses machine learning models to identify files infected by ransomware and to derive the entropy reference value. The machine learning models used in this paper are KNN, linear model, decision tree, decision tree ensemble, kernel trick, and deep learning.
Based on these models, the proposed system first extracts the optimal entropy reference value for each file format by performing learning and classification for each user, and it also has an artificial intelligence element as it continuously extracts and updates the reference value. Next, the extracted entropy reference value is passed to the user’s client software.
The ransomware detection module embedded in the client software measures the entropy of files synchronized to the backup system. The detection module detects infected files by comparing the measured entropy of the synchronized files with the reference value of the file format received from the backup system.
Moreover, it is also a good idea to determine the entropy reference value as the average of many files. Nevertheless, different characteristics of the entropy of user files may be derived for each user.
Therefore, the backup system learns and measures the entropy of the files stored in the backup system for each user, thereby deriving an optimal reference value specific to the user files, which leads to more accurate detection of the files infected by ransomware.”
The performance metrics of this method, such as accuracy, precision, recall, F1-score, precision-recall curve, ROC (Receiver Operating Characteristics) curve, and AUC (Area Under the Curve), were evaluated highly.
This is just one example I chose to demonstrate the potential of combining Machine Learning and AI techniques with entropy analysis.
I also do not mean in any way that Veeam will use this method in its solution. We have to wait for more details. This can undoubtedly be another powerful tool in the battle against ransomware.
Let’s wait for the release of the following editions of the Veeam Data Platform, as announced in the last VeeamON 2023.
As announced in VeeamON 2023, the release 12a (or 12.1) of the Veeam Data Platform is coming soon. In addition to bringing new cybersecurity features, one of the focuses is improving the ability to protect data stored in Object Storage. It is a critical demand for organizations to store data related to modern applications or any unstructured data related to the business. It will be possible to take data from object storage and store it in backup repositories of any type: block, file, object storage, or even tape. There will be flexible recoveries in restoring the entire buckets, including permissions, attributes, and tags. You will perform granular recoveries on individual objects and restore specific object versions. Of course, the immutability, the ability to define object version, object archive, and Backup Copy will be supported. This is all based on the NAS backup technology of Veeam Backup & Replication. Let’s wait for this new version!
A new version of Veeam Backup for Nutanix AHV (5.0) was released last week. One of the biggest drivers for this release has been a focus on scalability.
Nutanix Cloud Clusters (NC2) is supported now, so you can protect your Nutanix hybrid cloud end-to-end. Improvements in backup speed are also implemented with the CBT read-ahead mechanism. Workers have been introduced in the architecture.
Dedicated workers are responsible for data processing tasks in large deployments are Linux-based VMs distributed among the cluster hosts (nodes) and are automatically launched for the duration of a backup or restore process.
The new support for BitLocker on Windows VMs can result in significant space savings and reduce the time required to perform a backup. Nutanix and Veeam are better together.
To prevent the loss of backup files due to ransomware, malware, or even unplanned actions, it is recommended to use immutable backup repositories and the 3-2-1-1-0 data protection architectural rule.
One of the options available since release 11 of Veeam Backup & Replication is using a Linux server, taking advantage of the native file protection capabilities of this operating system as a backup repository.
The Veeam Hardened Linux Repository supports the following features:
File immutability: we can specify the period, and backup files will remain immutable. During this time, they cannot be modified or deleted.
Single-use credentials: this is one of the most critical security points. Linux user credentials are only used during the initial Veeam Data Mover deployment. This operation only happens when adding the Linux server to the backup infrastructure. These credentials are not stored in the backup infrastructure. Even if the Veeam Backup & Replication server is compromised, the attacker cannot obtain the credentials and connect to the protected repository.
Two Veeam services are used to implement and control immutability in this solution:
Transport service.
Immutability service.
After installation, the transport service runs as a non-root user. In our example here, we create the user “veeamadmin”. The transport service is responsible for communicating with the backup server, obtaining information about the immutability period, and forwarding it to the immutability service for processing.
The immutability service runs with root permissions and is a child transport service process. It checks the file’s immutability attributes every twenty minutes, calculates the time until a file must be immutable according to the backup job settings configured in the VBR console, and sets or removes the immutable attribute for backup files.
It is an intelligent mechanism because it prevents backup files from being deleted or modified even if they somehow exploit the transport service.
Using the command “ps aux | grep -i veeam” in the hardened repository, we can see the list of the Veeam processes:
We can see, as stated before, that the “veeamimmureposvc” service has the root attribute:
This service controls the “i” (immutability) attribute of the backup files, as shown in the figure below. After the immutability period, it removes that “i” attribute, allowing the file to be deleted from the backup chain.
Although Veeam’s “veeamimmureposvc” service has root access to set the “i” attribute, it is 100% local, has no network or port access, and cannot be compromised remotely.
When we start a new backup job, we can see the transport service in action:
Analyzing the immutability period for these backup files, we can see that the immutability expiration time is the same as configured in the VBR for this backup repository: 07 days.
Conclusion
Since Veeam works with the incremental forever backup chain concept, and a file or object can be part of different backup chains, VBR must be able to control the granular removal of each file or object from an immutable repository.
If Veeam Data Platform needs to discard old restore points in which a file or incremental backup object is no longer included but is still part of a restore point that cannot yet be discarded, it needs to control the enabling and disabling of the immutability of this file or object precisely.
This is why some object storage solutions do not allow immutability with Veeam: they only implement immutability at the level of the bucket and not on the object level.
In this video, I show how to install Veeam Backup for Google Cloud and integrate it with Google Cloud Plug-In for Veeam Backup & Replication.
Veeam Backup for Google Cloud is a solution developed for protection and disaster recovery tasks for Google Cloud environments. With Veeam Backup for Google Cloud, you can perform the following operations:
Create image-level backups and cloud-native snapshots of VM instances.
Create image-level backups and cloud-native snapshots of Cloud SQL instances.
Keep the backed-up data in cost-effective, long-term Google Cloud storage buckets.
Restore entire Cloud SQL instances, specific Cloud SQL databases, entire VM instances, individual persistent disks, and guest OS files and folders.
Google Cloud Plug-in for Veeam Backup & Replication is a solution developed for data protection and disaster recovery tasks for Google Cloud environments.
Google Cloud Plug-in for Veeam Backup & Replication extends the Veeam Backup & Replication functionality and provides access to Veeam Backup for Google Cloud in the Veeam Backup & Replication console.
The CNCF (Cloud Native Computing Foundation) was created in 2015 by Google and the Linux Foundation to encourage the development and collaboration of Kubernetes and other cloud-native solutions.
The foundation can be defined as an open-source and neutral center to make cloud-native computing universal and sustainable.
Currently, 172 projects are categorized as Graduated, Incubating, Sandbox, and Archived. Categorization criteria include adoption rate, governance, longevity, and whether the project is mature enough that a product can be built around it.
Graduated and Incubating projects are considered stable and are already successfully used in production environments. On the other hand, Sandbox projects are at an early stage and require more community involvement.
Through the CNCF Landscape tool, it is possible to view the current status and category of all projects:
In the figure below, I present the top 15 projects ranked by the amount of “commits” in the last year (January 2022 to January 2023). This was the metric chosen by CNCF to identify the speed of evolution of projects:
In collaborative and open-source projects, a “commit” is an operation performed by a contributor/developer that commits code changes to a shared repository. These changes are performed on files that are part of the source code.
The Kubernetes project continues to be responsible for the most significant number of contributions and commits. In the last year, some of the companies that most participated in the project, in order of number of contributions, were Google, Red Hat, Microsoft, VMware, IBM, Suse, Amazon, Huawei, Intel, Cisco, and Apple.
Analyzing the projects positioned just below Kubernetes, which had more than 10,000 “commits” in the last year, it is interesting to highlight the position of KubeVirt, a project classified as Incubating.
The growth of this project confirms the need to provide developers with an environment that combines virtual server-based and container-based applications, working side by side. It enables lifecycle management and migration of application architectures (monolithic to microservices) in a unified and scalable way. By the way, some market solutions already deliver this capacity.
The positioning of the Open Telemetry project, with the second highest number of “commits”, demonstrates the demand for a unified framework for “multi-environments” and “multi-clouds” observability aimed at SRE (Site Reliability Engineering) teams.
Red Hat announced on June 21, 2023, that it would no longer make the source code for Red Hat Enterprise Linux (RHEL) available to the general public. From now on, the code will only be available to customers who can’t legally share it.
Here is the link to the statement from a blog post:
CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.
It means that downstream projects that rebuild RHEL source code to produce compatible distributions such as AlmaLinux, Rocky Linux, and Oracle Linux will no longer have access to it.
So I am sharing the new big picture of upstream and downstream projects related to RHEL.
Fedora and CentOS Stream are the upstream community projects of RHEL. The software developed and tested in Fedora flows into CentOS Stream, whence it flows into RHEL.
Fedora is developed by the Fedora Project and sponsored by Red Hat. It follows its release schedule, with a new version approximately every six months; on the other side, a new version of Red Hat Enterprise Linux comes out every few years and is supported for up to 10 years.
Fedora supplies CentOS Stream and EPEL (Extra Packages for Enterprise Linux). EPEL is a particular interest group (SIG) from the Fedora Project that creates, maintains, and manages a high-quality set of additional packages for Enterprise Linux, like RHEL, Scientific Linux, Alma Linux, Rocky Linux, and Oracle Linux.
CentOS Stream is a community project that paces the development of RHEL; it will become the next point release of RHEL and is an intermediary distribution between Fedora and RHEL.
CentOS Stream is periodically resynchronized with RHEL when a new major release occurs.
From RHEL, there are Red Hat consumers like RHEL CoreOS and Red Hat Universal Base Image (UBI). RHEL CoreOS is released, upgraded, and managed as part of OpenShift; UIB is essentially a redistributable derivative of RHEL specifically designed for development and production use cases with containers.
From now, external downstream consumers, like Alam Linux, Rocky Linux, and Oracle Linux, will no longer have access to the RHEL source code.
Hope you got some helpful information from this post!
It is essential to understand and communicate to customers the differences between FPGA and ASIC microchip technologies.
The “Field-Programmable Gate Array” (FPGA) technology allows an integrated circuit, or chipset, to be logically reprogrammed at any time, if necessary. Therefore, FPGA technology allows corrections in logical functions related to bugs, security breaches or even the implementation and availability of new functionalities and capabilities in hardware already produced.
The “Application-Specific Integrated Circuit” (ASIC) technology is related to dedicated-use chipsets that cannot be reprogrammed after production. Logic circuits are definitely “written” into silicon. The correction of a bug or a security breach related to the logical design of the chipset cannot be performed after it is produced (like a field correction or upgrade). Therefore, the financial risk is greater if the solution is not correctly validated and mature.
The manufacturers choose to use ASICs in their equipment due to the low cost of producing chipsets on a large scale, which is much lower than the cost of producing FPGA technology in large quantities. On the other hand, in ASIC technology, the design costs called Non-Recurring Engineering (NRE costs) are high.
FPGA technology is generally used in the product development, prototyping, testing, and initial release phases, allowing corrections and adjustments to the solution, if necessary.
Once the solution is sufficiently mature and validated, the products use ASICs on a large scale from the final logic programs of FPGAs. The costs of converting an FPGA design to ASIC chipsets are relatively less than the NRE costs.
At the beginning of my career, the programming of FPGAs was carried out through logic drawings. Currently, programming is performed using a language called “Hardware Description Language” (HDL).
Thus, it is not correct to say that the logical structure of an ASIC can be reprogrammed. We have even seen recent cases of the need for complete replacement of appliances due to security breaches related to hardware/ASICs, which cannot be corrected in the field.
Some of the leading manufacturers of FPGAs are Intel (former Altera), AMD (Xilinx), Achronix, Altium, Lattice, and Microchip.
In this figure, there is a comparative summary of the technologies.
Hope you got some helpful information from this post!
Hey! These are the top 15 CNCF (Cloud Native Computing Foundation) projects ranked by the amount of “commits” in the past year (Jan 2022 to Jan 2023). It was the metric the CNCF chose to identify the speed of evolution of its projects.
In open-source and collaborative projects, a “commit” is an operation performed by a contributor/developer that commits code changes to a shared repository. These changes are performed on files that are part of the source code.
The Kubernetes project continues to account for the highest amount of overall contributions and “commits”. In the last year, some of the companies that most participated in this project, in order of amount of contributions, were: Google, Red Hat, Microsoft, VMware, IBM, Suse, Amazon, Huawei, Intel, Cisco, and Apple.
Analyzing the projects just below Kubernetes and which had more than 10,000 “commits” in the last year, it is interesting to observe the position of KubeVirt, a project identified as “incubating” within the CNCF maturity classification.
It confirms the need to provide developers with an environment that combines applications based on virtual servers and applications based on containers, working side by side. It allows for both lifecycle management and migration of application architectures (monolithics to microservices) in a unified and scalable manner.
Citing two market solutions that deliver an integrated K8s/VMs environment, we have the Red Hat OpenShift Virtualization and the VMware Tanzu Kubernetes Grid (TKG).
The positioning of the OpenTelemetry project with the second highest number of “commits” demonstrates the great need to adopt a unified framework for “multi-environments” and “multi-cloud” observability for SRE teams.
The positioning of the Backstage project, an open platform for building developer portals, shows the strong movement around the Developer Experience (DevX – Developer eXperience).
For more information about Backstage and the context of DevX, follow a post I wrote on the subject: