Accelerate Amazon Redshift secure data use with Satori – Part 2

Post Syndicated from Rohit Vashishtha original https://aws.amazon.com/blogs/big-data/accelerate-amazon-redshift-secure-data-use-with-satori-part-2/

This post is co-written by Adam Gaulding, Solution Architect at Satori.

In this post, we continue from Accelerate Amazon Redshift secure data use with Satori – Part 1, and explain how Satori, an Amazon Redshift Ready partner, simplifies both the user experience of gaining access to data and the admin practice of granting and revoking access to data in Amazon Redshift. Satori enables both just-in-time and self-service access to data.

Solution overview

Satori creates a transparent layer providing visibility and control capabilities that is deployed in front of your existing Redshift data warehouse. When adding a new data store to Satori, a new, Satori-provided URL is generated for the data store, which data consumers use instead of connecting directly.

The following diagram illustrates the solution architecture.

Data consumers don’t have to change how they work with data, such as installing different database drivers, changing their queries, or compromising on features or functionality. Satori is not a data virtualization or database federation solution that abstracts your existing data stores.

Self-service access to data is fully automated. The admin is responsible for setting up the access rules. User access privileges can be preconfigured for automated dataset access. The user can see the datasets that are available to them in their personalized data portal. The user then selects the dataset they want to use and Satori automatically applies the appropriate security, privacy, and compliance requirements.

Just-in-time access to data is also flexible but requires approval from an admin. From the user’s personalized data portal, they can see the available datasets—the only datasets they have self-service access to are already included in their My Data folder. If they see a dataset that they need but don’t have access to, they can request access to this data on-demand. The request is sent to the admin and, based on the user’s credentials, the admin can choose to approve or deny access.

The ability to facilitate and automate access to data provides the following benefits:

  • Satori improves the user experience by providing quick access to data. This increases the time-to-value of data and drives innovative decision-making.
  • Admins benefit from automating the process, significantly reducing the amount of time spent on granting and revoking access to data.

Prerequisites

Follow the steps outlined in Accelerate Amazon Redshift secure data use with Satori – Part 1 to complete the following prerequisite steps:

  1. Prepare the data.
  2. Connect to Amazon Redshift.
  3. Create a dataset and give Satori control over access to the dataset.
  4. Optionally, create security policies and revisit the concepts related to secure data access and masking policies.

After you complete the prerequisites, you’re ready to explore self-service and just-in-time access to data.

Self-service access

The following steps explain how to create self-service rules from admin and user perspectives.

Create access request and self-service rules (admin perspective)

After the admin gives Satori control over access to the dataset, they need to first preconfigure the user access rules. Complete the following steps:

  1. Navigate to the Datasets page and choose User Access Requests.
  2. In the Self-Service Access section, choose Self-Service Rule.

  1. Specify the required level of access.

The admin has several options when configuring the access rules. You can set the level of access by user or group, define when it expires, and set revocation rules.

The following screenshot shows the configuration rule for data access requests we created. In this example, the self-service user group has read-only access during the next 30 days that is set to revoke within 7 days if it’s not used.

The following figure shows an example configuration rule to add a user.

The newly created access rule and details are displayed in the list of self-service rules.

The next steps outline the data user view and steps to gain self-service access to data.

Create access request and self-service rules (user perspective)

As a user, complete the following steps:

  1. Enter the Satori personalized data portal using the Data Portal option on the options menu (three vertical dots).

The data portal will display all available datasets. Any datasets that the user already has self-service access to will appear under My Data, as shown in the following screenshot. All other datasets appear under Available Datasets.

  1. Choose the desired dataset (in this case, CustomerDataset) and request immediate access to this dataset by choosing Ask for Access to Dataset.

  1. For Access Request, choose Self Service.
  2. For Request Message, enter a reason for the request.
  3. Choose Request.

Based on the user’s identity, preconfigured access rules match the user to their respective qualifications and authorizations. In this case, the user is automatically granted access to CustomerDataset using the preconfigured self-service rules. The requested dataset appears with Status – Access Granted under My Data.

The preconfigured access rules are applied so that when this user runs their queries, certain sensitive data is redacted.

Now that access is granted, query the data using a SQL editor of your choice. In this post, we use DBeaver to connect to a Redshift cluster using the Satori hostname on the data stores tab.

When you query the data, you will see the security policies applied to the result set at runtime. In the following example, the customer table is displayed with redacted field values based on security policies.

In the following example, the credit_cards table is displayed with masking policies applied to the result values.

Just-in-time access

Just-in-time access is similar to self-service access; the only difference is that it includes an additional step of requesting access from the admin.

Create access request and self-service rules (user perspective)

The user enters the Satori personalized data portal with the same view as shown in the self-service access to data.

If the data that you need isn’t included under My Data but shows under Available Datasets, you can request access to this dataset. For this example, we consider a new user John Doe trying to access CustomerDataset from the available datasets. The process consists of the following steps:

  1. User John Doe logs in to the Satori portal and finds the Available Datasets section in their data portal.
  2. The user submits a request for CustomerDataset.

The request from user John Doe for CustomerDataset stays in Pending Approval status until approved from the admin.

  1. The admin receives the request from user John Doe through email and portal notifications for dataset requests.

The admin can approve or deny the request and might also designate the level of access and when that access expires.

The following screenshot shows an example email notification.

  1. The admin can choose View Request in the email and then approve or deny the request on the Satori portal.

  1. The admin can choose the pencil icon to edit the request before approval and modify the approval conditions.

In this example, the admin modifies a couple of criteria as shown and then approves the request.

Create access request rules (admin perspective)

Users can request access to datasets and the admin can approve or reject those requests, but the admin can also preconfigure the user access rules. Complete the following steps as the admin:

  1. On the Datasets page, choose User Access Requests.
  2. Fill out the access request rule.
  3. Choose Add.

The access request rule creation will be treated as an approval workflow when dataset requests are placed from the data portal.

Dataset requests from users will follow the course of action configured by the admin during access request rules creation. The preconfigured access rules specific to that user are applied so that when this user runs their queries, security policies and masking conditions are applied, and sensitive data is redacted or masked as applicable. The access control is maintained according to the admin settings for both just-in-time access and self-service access.

Clean up

To avoid unintended costs, clean up the resources provisioned as part of Accelerate Amazon Redshift secure data use with Satori – Part 1 or provisioned for this post. Make sure to delete the following resources:

  • Redshift cluster or serverless endpoint
  • Security group to allow inbound traffic from Satori
  • Configurations within your Satori account

Summary

In this post, we described how Satori can help automate secure data access for both data users and admins. The ability to automate this process increases the time-to-value of data for users and reduces the time and resources admins need to allocate for granting and revoking data access.

Satori is available on the AWS Marketplace. To learn more, start a free trial or request a demo meeting.

Amazon Redshift provides comprehensive security and governance features to protect your data, and continues to expand its out-of-the-box capabilities. For the latest features and updates, explore Amazon Redshift What’s New.

About the Authors

Rohit Vashishtha is a Senior Analytics Specialist Solutions Architect at AWS based in Dallas, Texas. He has over 17 years of experience architecting, building, leading, and maintaining big data platforms. Rohit helps customers modernize their analytic workloads using the breadth of AWS services and ensures that customers get the best price/performance with utmost security and data governance.

Jagadish Kumar (Jag) is a Senior Specialist Solutions Architect at AWS focused on Amazon OpenSearch Service. He is deeply passionate about Data Architecture and helps customers build analytics solutions at scale on AWS.

 Adam Gaulding is a Solution Architect at Satori. At Satori, Adam is helping customers implement data security controls on databases, data lakes and data warehouses. Adam has been in and around the data space throughout his 20+ year career. He’s worked with companies large and small and prides himself in building creative solutions for technical problems.

Implementing backup for workloads running on AWS Outposts servers

Post Syndicated from aostan original https://aws.amazon.com/blogs/compute/implementing-backup-for-workloads-running-on-aws-outposts-servers/

This post is written by Leonardo Queirolo, Senior Cloud Support Engineer and Tareq Rajabi, Senior Solutions Architect, Hybrid Cloud

AWS Outposts servers provide fully managed AWS infrastructure, services, APIs, and tools to on-premises and edge locations with limited space or small capacity requirements, such as retail stores, branch offices, healthcare provider locations, or factory floors. Outposts servers provide local compute and networking services.

Outposts servers come with internal NVMe SSD instance storage, supporting local storage used for data access and processing on premises, and for launching Amazon Elastic Block Store (Amazon EBS)-backed Amazon Machine Images (AMIs). The data on these volumes persists after an instance reboot but does not persist after an instance termination. In order for data to persist beyond the lifetime of the instance, it is important to back up your data to a persistent AWS storage, such as an Amazon Simple Storage Service (Amazon S3) bucket or an Amazon Elastic Block Store (Amazon EBS) volume.

In this post, we explore several approaches to back up the data stored in the instance storage volumes of your EC2 instances running on an Outposts server to a persistent storage solution from AWS, and explore their benefits and use cases.

Planning for failure

When evaluating a backup strategy, it’s important to understand the failure modes you are looking to recover from. Some examples are ransomware attacks, accidental data deletion, hardware failure, or a wide scale issue impacting the whole facility where your Outposts servers and on-premises devices (such as network switches, storage appliances) reside. These failures come in many forms and are often unplanned and unexpected events. Next, understand what is considered acceptable recovery for your business. For example, what are the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for your workload running on Outposts servers? These two values, defined by your organization, profile how long a service can be down during recovery and quantify the acceptable amount of data loss, helping you define the appropriate backup strategy.

Scenario 1: Backup to AWS storage in an AWS Region

Backup to an AWS Region enables data redundancy outside of the data center or facility where your Outpost resides, taking advantage of the durability, high availability, and scalability provided natively by the storage in the Region. This approach offers flexibility for restoration to the Region or to an Outposts server in a different edge location if the original data center/facility is impacted by an irrecoverable incident. However, when restoring the data back to an Outposts server, this approach could result in relatively high RTO, depending on the throughput of the service link and the amount of data to restore. In the following sections, we will cover using the AWS Elastic Disaster Recovery (AWS DRS) and an open source solution based on operating system tools and AWS Systems Manager (AWS SSM).

Option 1: AWS Elastic Disaster Recovery (AWS DRS)

You can use AWS DRS to perform a continuous replication of workloads that reside on the Outposts C6id server powered by Intel processors (C6gd are not supported, since only 64-bit operating systems built for the x86 system architecture are supported by AWS DRS) to a staging area subnet in the Region. AWS DRS provides nearly continuous, block-level replication in the Region and creates periodic EBS Snapshots according to the Point in Time (PIT) state schedule for AWS DRS.

The following diagram shows the continuous replication of the data in the instance store volumes through AWS DRS. The PIT EBS Snapshots are used to create Amazon EBS-backed AMIs as a backup of the EC2 instances running on the Outposts server.

Figure 1 - Continuous replication of the Instance Store Volumes data from the instances running Outpost Server to a staging area in the parent region through DRS

Figure 1 – Continuous replication of the Instance Store Volumes data from the instances running Outpost Server to a staging area in the parent region through DRS

Despite AWS DRS not supporting the failback from the Region to Outposts servers, you can use the EBS snapshots taken by AWS DRS to restore the data back to the Outposts server at the desired PIT following the steps described in this post.

Prerequisites

The following prerequisites are required to complete the walkthrough:

  1. The EC2 instance to restore running on the Outposts server has been added as a source server to AWS DRS by installing the AWS Replication Agent.
  2. The initial sync has been completed and the data replication status is showing as healthy.

Restore the entire EC2 instance on the same or a different Outposts server

  1. Use the describe-recovery-snapshots command to list the PIT Snapshots taken by AWS DRS for the source server to restore.$ aws drs describe-recovery-snapshots --source-server <source-server-id>

2. Based on the time in which you want to restore your data, retrieve the corresponding EBS Snapshots in the output of the command. The following is an example of the output:

{
    "items": [
       {
            "ebsSnapshots": [
                "snap-07bf348d58151a432"
            ],
            "expectedTimestamp": "2024-06-13T16:40:00+00:00",
            "snapshotID": "pit-a4877ff6fa68561bf",
            "sourceServerID": "s-a080ceb10af7275a7",
            "timestamp": "2024-06-13T16:46:56.645979+00:00"
        },
        {
            "ebsSnapshots": [
                "snap-0496020ff7f83486d"
            ],
            "expectedTimestamp": "2024-06-13T16:30:00+00:00",
            "snapshotID": "pit-aece827519e1b0fbb",
            "sourceServerID": "s-a080ceb10af7275a7",
            "timestamp": "2024-06-13T16:37:06.600323+00:00"
        },
        {
            "ebsSnapshots": [
                "snap-0d7ebd23e56346cea"
            ],
            "expectedTimestamp": "2024-06-13T16:20:00+00:00",
            "snapshotID": "pit-a56960f89ff12579e",
            "sourceServerID": "s-a080ceb10af7275a7",
            "timestamp": "2024-06-13T16:27:01.595791+00:00"
        },
…
…

3. Open the Amazon EC2 console. In the navigation pane, choose Snapshots and filter by the Snapshot ID chosen in the previous step: snap-07bf348d58151a432.

4. Choose Actions, Create image from snapshot, and specify the Image name. You can leave the other information as default or customize as desired.

5. To perform the restore, launch a new EC2 instance on the same or a different Outposts server from the Amazon EBS-backed AMI created in the previous step.

Note that since AMIs are downloaded from the Region with every instance launch on Outposts servers, this approach could result in an RTO spanning hours, depending on the throughput of the service link and the size of the local instance storage from which the Snapshot and AMI were taken by AWS DRS. Alternatively, if you need to restore only some files and directories, you can do so by launching the EC2 instance in the Region from the AMI taken in Step 4 and then transferring the desired data from that instance to the source server running on Outposts.

Option 2: Backup to the Region using an open source solution

In addition to AWS DRS, you can use open source solutions and/or operating system (OS) functions to back up data from local instance storage to a Region. Consider this approach when you want a highly-customizable solution for workloads where lack of commercial support is acceptable. The open source solution uses AWS Systems Manager Automation and OS functions to take an Amazon EBS-backed AMI in the Region from a Linux EC2 instance running on your Outposts server. The following diagram provides a high-level overview of the solution.

Figure 2 – Wokflow of the open source solution

Figure 2 – Workflow of the open source solution

  1. The Automation creates a helper instance and a baseline EBS volume attached to it in the Region, using an AWS CloudFormation
  2. The Automation executes commands on the OS of the EC2 instance running on the Outposts server to perform preliminary checks and start syncing data from the local instance store volume to the baseline EBS volume in the Region.
  3. The sync continues until the data has been transferred successfully.
  4. When the sync completes, the Automation takes an EBS Snapshot of the baseline EBS volume and then creates an Amazon EBS-backed AMI from it.

Create the Automation document

  1. Open the github page of the open source solution backup-outposts-servers-linux-instance.
  2. Follow the Installation Instructions to create the Systems Manager Automation document.

Back up an EC2 instance running on Outposts server

  1. After creating the Automation document, follow the Usage Instructions to execute the Automation and initiate the backup.
  2. Monitor the Execution status in the System Manager Automation console.

Restore the entire EC2 instance on the same or a different Outposts server

  1. Open the Amazon EC2 console. In the navigation pane, choose AMIs and filter by the AMI names that contain the InstanceId to restore.

2. Select the desired AMI to restore and note its AMI ID.

3. To perform the restore, launch a new EC2 instance on the same or a different Outposts server from the Amazon EBS-backed AMI identified in the previous step.

Considerations for data residency and service link bandwidth

Data residency is a critical consideration for organizations that need to collect and store data in their own data centers for regulatory or compliance reasons. In this case, users cannot back up their data to the Region and need to consider backing up to another on-premises system.

Another consideration is the impact on the service link connectivity when performing backup and restore operations between the Outposts and the Region. When implementing the solutions described in the “Backup to AWS storage in an AWS Region” scenario, both your backup/restore and management/monitoring operations for your Outpost rely on the service link connectivity. Although AWS DRS provides block-level replication, the open source solution we discuss in this post only replicates data, resulting in smaller snapshot sizes for users with lower service link bandwidth requirement.

If you foresee bandwidth constraints for your service link, consider backing up to another on-premises system that is reachable through the local network interface (LNI) of your Outposts server.

Scenario 2: Backup to AWS storage in your on-premises environment

For the preceding reasons, you may need to back up your workload running on Outposts server to a persistent AWS storage system within the same geo political boundary. To do so, you can use an AWS Outposts rack that resides in the same or a different physical location and is reachable through the LNI of your Outposts server.

Outposts rack with Amazon S3 on Outposts allows you to run AWS infrastructure, services, and object storage to your on-premises to meet local data processing and data residency needs while offering the AWS durable storage that can be used to store your backup.

Thanks to this, you can use the same approaches described in the “Backup to AWS storage in an AWS Region” section at a high level to back up your data, while the storage is hosted on the Outposts rack. When evaluating this approach, keep in mind these important considerations for local snapshots.

With this approach, you can store your backup on premises to meet your data residency requirements. This also keeps the network traffic for your backup and restore within your on-premises network, without impacting the service link.

Conclusion

In this post, we showed different approaches to design backup and restore strategies for your workloads running on Outposts servers. Implementing the right approach can help protect your organization’s data against loss or corruption while meeting your performance, RTO, RPO, and data residency needs, with backup destinations ranging from AWS storage in the Region, locally on Outposts rack, or in a hybrid architecture.

Supply-chain attack analysis: Ultralytics (PyPI Blog)

Post Syndicated from jzb original https://lwn.net/Articles/1001909/

The Python Package Index (PyPI) Blog has an analysis
of the compromise of
the ultralytics
project, and what PyPI has learned from this event:

PyPI staff and volunteers do their best to remove malware, but
because the service is open to anyone looking to publish software
there is an unfortunately high amount of abuse. Thankfully most of
this abuse does not have the same widespread impact as a targeted
attack on an already widely-used project.

Mike Fiedler, the PyPI Safety and Security Engineer is working on
new systems for reducing the time that malware is available to be
installed on PyPI, through APIs
that security researchers can automatically send reports to and
new “quarantine”
release status to prevent harm while a human investigates the
situation. Expect more in this space in 2025!

When should we require that firmware be free?

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/70895.html

The distinction between hardware and software has historically been relatively easy to understand – hardware is the physical object that software runs on. This is made more complicated by the existence of programmable logic like FPGAs, but by and large things tend to fall into fairly neat categories if we’re drawing that distinction.

Conversations usually become more complicated when we introduce firmware, but should they? According to Wikipedia, Firmware is software that provides low-level control of computing device hardware, and basically anything that’s generally described as firmware certainly fits into the “software” side of the above hardware/software binary. From a software freedom perspective, this seems like something where the obvious answer to “Should this be free” is “yes”, but it’s worth thinking about why the answer is yes – the goal of free software isn’t freedom for freedom’s sake, but because the freedoms embodied in the Free Software Definition (and by proxy the DFSG) are grounded in real world practicalities.

How do these line up for firmware? Firmware can fit into two main classes – it can be something that’s responsible for initialisation of the hardware (such as, historically, BIOS, which is involved in initialisation and boot and then largely irrelevant for runtime[1]) or it can be something that makes the hardware work at runtime (wifi card firmware being an obvious example). The role of free software in the latter case feels fairly intuitive, since the interface and functionality the hardware offers to the operating system is frequently largely defined by the firmware running on it. Your wifi chipset is, these days, largely a software defined radio, and what you can do with it is determined by what the firmware it’s running allows you to do. Sometimes those restrictions may be required by law, but other times they’re simply because the people writing the firmware aren’t interested in supporting a feature – they may see no reason to allow raw radio packets to be provided to the OS, for instance. We also shouldn’t ignore the fact that sufficiently complicated firmware exposed to untrusted input (as is the case in most wifi scenarios) may contain exploitable vulnerabilities allowing attackers to gain arbitrary code execution on the wifi chipset – and potentially use that as a way to gain control of the host OS (see this writeup for an example). Vendors being in a unique position to update that firmware means users may never receive security updates, leaving them with a choice between discarding hardware that otherwise works perfectly or leaving themselves vulnerable to known security issues.

But even the cases where firmware does nothing other than initialise the hardware cause problems. A lot of hardware has functionality controlled by registers that can be locked during the boot process. Vendor firmware may choose to disable (or, rather, never to enable) functionality that may be beneficial to a user, and then lock out the ability to reconfigure the hardware later. Without any ability to modify that firmware, the user lacks the freedom to choose what functionality their hardware makes available to them. Again, the ability to inspect this firmware and modify it has a distinct benefit to the user.

So, from a practical perspective, I think there’s a strong argument that users would benefit from most (if not all) firmware being free software, and I don’t think that’s an especially controversial argument. So I think this is less of a philosophical discussion, and more of a strategic one – is spending time focused on ensuring firmware is free worthwhile, and if so what’s an appropriate way of achieving this?

I think there’s two consistent ways to view this. One is to view free firmware as desirable but not necessary. This approach basically argues that code that’s running on hardware that isn’t the main CPU would benefit from being free, in the same way that code running on a remote network service would benefit from being free, but that this is much less important than ensuring that all the code running in the context of the OS on the primary CPU is free. The maximalist position is not to compromise at all – all software on a system, whether it’s running at boot or during runtime, and whether it’s running on the primary CPU or any other component on the board, should be free.

Personally, I lean towards the former and think there’s a reasonably coherent argument here. I think users would benefit from the ability to modify the code running on hardware that their OS talks to, in the same way that I think users would benefit from the ability to modify the code running on hardware the other side of a network link that their browser talks to. I also think that there’s enough that remains to be done in terms of what’s running on the host CPU that it’s not worth having that fight yet. But I think the latter is absolutely intellectually consistent, and while I don’t agree with it from a pragmatic perspective I think things would undeniably be better if we lived in that world.

This feels like a thing you’d expect the Free Software Foundation to have opinions on, and it does! There are two primarily relevant things – the Respects your Freedoms campaign focused on ensuring that certified hardware meets certain requirements (including around firmware), and the Free System Distribution Guidelines, which define a baseline for an OS to be considered free by the FSF (including requirements around firmware).

RYF requires that all software on a piece of hardware be free other than under one specific set of circumstances. If software runs on (a) a secondary processor and (b) within which software installation is not intended after the user obtains the product, then the software does not need to be free. (b) effectively means that the firmware has to be in ROM, since any runtime interface that allows the firmware to be loaded or updated is intended to allow software installation after the user obtains the product.

The Free System Distribution Guidelines require that all non-free firmware be removed from the OS before it can be considered free. The recommended mechanism to achieve this is via linux-libre, a project that produces tooling to remove anything that looks plausibly like a non-free firmware blob from the Linux source code, along with any incitement to the user to load firmware – including even removing suggestions to update CPU microcode in order to mitigate CPU vulnerabilities.

For hardware that requires non-free firmware to be loaded at runtime in order to work, linux-libre doesn’t do anything to work around this – the hardware will simply not work. In this respect, linux-libre reduces the amount of non-free firmware running on a system in the same way that removing the hardware would. This presumably encourages users to purchase RYF compliant hardware.

But does that actually improve things? RYF doesn’t require that a piece of hardware have no non-free firmware, it simply requires that any non-free firmware be hidden from the user. CPU microcode is an instructive example here. At the time of writing, every laptop listed here has an Intel CPU. Every Intel CPU has microcode in ROM, typically an early revision that is known to have many bugs. The expectation is that this microcode is updated in the field by either the firmware or the OS at boot time – the updated version is loaded into RAM on the CPU, and vanishes if power is cut. The combination of RYF and linux-libre doesn’t reduce the amount of non-free code running inside the CPU, it just means that the user (a) is more likely to hit since-fixed bugs (including security ones!), and (b) has less guidance on how to avoid them.

As long as RYF permits hardware that makes use of non-free firmware I think it hurts more than it helps. In many cases users aren’t guided away from non-free firmware – instead it’s hidden away from them, leaving them less aware that their freedom is constrained. Linux-libre goes further, refusing to even inform the user that the non-free firmware that their hardware depends on can be upgraded to improve their security.

Out of sight shouldn’t mean out of mind. If non-free firmware is a threat to user freedom then allowing it to exist in ROM doesn’t do anything to solve that problem. And if it isn’t a threat to user freedom, then what’s the point of requiring linux-libre for a Linux distribution to be considered free by the FSF? We seem to have ended up in the worst case scenario, where nothing is being done to actually replace any of the non-free firmware running on people’s systems and where users may even end up with a reduced awareness that the non-free firmware even exists.

[1] Yes yes SMM

comment count unavailable comments

[$] A last look at the 4.19 stable series

Post Syndicated from corbet original https://lwn.net/Articles/1000933/

The release of the 4.19.325 stable
kernel update on December 5 marked the end of an era of sorts.
This kernel had been supported for just over six years since its initial
release in October 2018; over that time, 325 updates were released,
adding 30,109 fixes. Few Linux kernels receive public support for so long;
it is worth taking a look at this kernel’s history to see how it played
out.

Navigating Choppy Waters: Top Security Predictions from Rapid7’s 2025 Webinar

Post Syndicated from Rapid7 original https://blog.rapid7.com/2024/12/12/navigating-choppy-waters-top-security-predictions-from-rapid7s-2025-webinar/

Navigating Choppy Waters: Top Security Predictions from Rapid7's 2025 Webinar

It’s that time of year again — one year is ending and another is set to begin.. And what a year it’s been for the security community! The sheer scale of incidents has left SecOps teams breathless, so thinking about what could be in store next year can be overwhelming.

But there’s no need to panic; despite the disruption, the community has rallied together and risen to the challenge, demonstrating adaptability, collaboration, and resilience. And, most of all, why this industry isn’t for the faint of heart!

Over the last few years, we’ve seen significant interest in our annual Security Predictions webinar. Security teams use the session to take stock of the current year and use the predictions to get a head start on planning for the next.

This year, the webinar was shot in person from Rapid7’s office in Belfast, a city that has emerged as a modern tech innovation hub. From its origins as the shipyards that birthed the Titanic, Belfast’s history is a testament to both ambition and resilience, so it is fitting that this city served as the stage for Rapid7’s annual Security Predictions webinar.

Hosted by industry heavy hitter Brian Honan, CEO of BH Consulting, the webinar brought together Rapid7 security and policy experts Raj Samani, Chief Scientist, and Sabeen Malik, VP of Global Government Affairs and Public Policy.

Looking Back: 2024’s Predictions in Review

Before diving into the future, the panel revisited their predictions for 2024, which focused on three core areas:

1. Increasing risks and regulations will intensify pressure on businesses to navigate evolving demands across a complex global landscape.

Sabeen Malik highlighted that the forecasted rise in cyber regulations materialized, with frameworks like NIS2 and the SEC’s cybersecurity mandates intensifying global compliance demands.

2. Expect a surge in the growth of real-time information sharing within global public-private cyber partnerships.

While strides were made, Raj Samani noted that much of the shared data lacks actionable context, calling for enriched, actionable intelligence that organizations can immediately act upon.

3. The continued use of zero-day vulnerabilities exploited by ransomware groups will compel SOCs to focus on exposure management and validation strategies.

As predicted, ransomware groups continued to exploit zero-day vulnerabilities, a trend exacerbated by their increasing sophistication and access to novel attack vectors.

“2024 was pretty much on the button,” said Brian Honan. “The predictions were accurate, but the challenges they highlighted are far from over.”

2025 could be Iceberg Alley/Visibility as a Life Preserver

Prediction 1: Greater visibility will act as a life preserver for security teams treading water across an increasingly complex attack surface.

Visibility isn’t just a cybersecurity buzzword—it’s the foundation of effective defense. Raj Samani summarized this challenge succinctly: “You can’t protect what you don’t know about.”

In today’s environment, where assets span on-premise systems, cloud services, and third-party integrations, organizations often need help to map their full attack surface. Raj explained how conflicting data from multiple tools complicates this task: “Your endpoint provider says one thing, your VPN provider says another — how do you normalize this information?”

After further discussion, the panellists provided a short, medium and long-term action plan to help defenders strengthen their visibility.

Prediction 2: To thrive in a world where regulatory change is an ongoing concern, SecOps should prepare for both the predictable and the unpredictable.

In cybersecurity, the only constant is change. The panel emphasized the need for agile Security Operations Centers (SOCs) to respond effectively to both expected and unexpected threats.

“This is about moving beyond checkbox exercises,” said Sabeen. “SOC teams must adopt continuous processes and infrastructure to manage a rapidly changing landscape.” She pointed to regulatory frameworks like DORA and NIS2, which mandate real-time monitoring and frequent vulnerability assessments, as drivers of this shift.

The panelists also provided an action plan that prioritizes incident response, real-time threat detection, and continuous vulnerability management to meet evolving compliance and security needs.

Prediction 3: Cybercriminals will increasingly exploit zero-day vulnerabilities, expanding potential entry points and bypassing traditional security measures to deliver more ransomware attacks.

Ransomware remains a dominant threat, evolving as attackers adopt zero-day vulnerabilities to bypass traditional defenses. Raj explained how this shift is lowering the technical barriers for cybercriminals: “Access to zero-days allows even unsophisticated actors to execute devastating attacks.”

The professionalization of ransomware groups further exacerbates the threat. As Sabeen noted, “This is no longer a scattered effort. It’s a highly organized, professional ecosystem, and it’s growing at an unsustainable rate.”

The team outlined an action plan to combat ransomware, including the critical action step of engaging organizational leadership to prioritize cybersecurity investments and ensure board-level awareness of the risks.

“Use this as an opportunity to have meaningful discussions with your board,” Raj advised. “Ransomware is a top concern, and preparation is key.”

Final Thoughts: Staying Resilient in Choppy Waters

While the challenges of 2025 may seem daunting, the panel concluded on a hopeful note. Raj highlighted Rapid7’s commitment to empowering the industry through open-source tools and resources like AttackerKB, Metasploit, and Velociraptor.

“Don’t be overwhelmed,” Raj said. “We’re all in this together, and Rapid7 is here to help with actionable insights and tools that protect what matters most.”

As Brian wrapped up, he reflected on Belfast’s legacy and the lessons it offers. “The Titanic reminds us of both the heights of ambition and the importance of preparation. In cybersecurity, as in life, visibility, adaptability, and resilience are the keys to navigating choppy waters.”

To get a full understanding of what 2025 could bring, watch the Top Cybersecurity Predictions webinar on-demand.

Защо младите ни лекари да се обучават и в чужбина? Разговор с д-р Неда Бакалова

Post Syndicated from Надежда Цекулова original https://www.toest.bg/zashto-mladite-ni-lekari-da-se-obuchavat-i-v-chujbina/

Защо младите ни лекари да се обучават и в чужбина? Разговор с д-р Неда Бакалова

Неда Бакалова е лекарка, специалистка по анестезиология, реанимация и интензивно лечение. Учила е и е специализирала в България, но в последните години работи в болницата в Саутхемптън в Обединеното кралство. Затова в интервюто ще прочетете колко много пъти казва „тук“. Нейното „тук“ е нашето „там“, където има едно по-качествено организирано детско здравеопазване, даващо по-добри резултати.

Защо младите ни лекари да се обучават и в чужбина? Разговор с д-р Неда Бакалова
Д-р Неда Бакалова. Снимка: личен архив

Неда е един от инициаторите на кампанията „Лекари на бъдещето“, която се организира от Фондация BCause и медийната платформа „Майко Мила“. Това е програма за повишаване на нивото на педиатричната помощ в България, ориентирана към лекари специализанти в различни педиатрични специалности. Целта ѝ е да им помогне да натрупат професионален опит в лечебни заведения в чужбина, който да пренесат на местна почва в името на толкова дълго чаканата качествена промяна на българското детско здравеопазване. 

Програмните цели са през 2025 г. да бъдат изпратени петима млади лекари на клинично наблюдение в болници в Европа. Необходимата сума е приблизително 50 000 лв.

Може да дарите на:
Платформата.бг
През benevity – ако сте регистриран служител на компания с профил там.
На номер 17 777 с текст DMS LEKARI.

Вие сте млада лекарка, която вече се е установила в чужбина. Защо се интересувате от обучението на колегите си, които практикуват в България? 

Да, аз съм анестезиолог по специалност. От три години работя в кардиореанимацията и кардиохирургията в болницата в Саутхемптън. Преди това в България съм била основно в болница „Света Екатерина“. След пристигането си тук за първи път започнах да се занимавам с детска кардиохирургия. Екипът доста ме подкрепи и продължава да ме подкрепя и обучава. Вече давам упойки на деца в детската кардиохирургия, докато паралелно работя в реанимацията за възрастни и наблюдавам работата на колегите в детската реанимация.

Самата програма „Лекари на бъдещето“ започна с една лична история. Може би не е моя работа да я разказвам, но в общи линии, детенцето на инициаторката, което, за съжаление, миналата година почина, прекара последните си 5–6 месеца в Педиатрията [СБАЛ по детски болести „Проф. Иван Митев“ – б.р.]. Чувахме се често и се налагаше да обяснявам неща, които не ѝ бяха обяснени. И оттам се зароди идеята, че би било хубаво специализантите по педиатрия да придобият някакъв опит извън България, да видят, че медицината може да се прави и по друг начин. 

Аз съм била специализант в България и е много тежко.

И всъщност основната идея на тази програма е да се покаже на младите лекари, че не всичко опира до това колко пари или колко ресурси има в системата. Голяма част е организация, мислене.

Нас не ни учат как да говорим с пациентите, как да им осигурим психологическото пространство да минат през преживяването си. И би било полезно да видят как това се прави от лекарите тук. 

Кое е различното освен количеството ресурси? Малко е трудно, но може ли да опитате да обясните какво означава „друг начин на мислене“ например?

Няма да е лесно, защото това не засяга само лекарите и тяхното отношение към пациентите, то е двустранно и като че ли по-всеобхватно. Аз също си давам сметка, че съм се променила тук. И обществото е друго, и отношенията между хората са по-различни. За съжаление, ние, българите, не се държим много добре един с друг, което се пренася на всички нива – от медик към пациент, от близки към медици.

Освен това в Англия хората са изключително горди със своята обществена здравна система, тъй като е изцяло финансирана и създадена от данъците им. И въпреки че има доста кусури и доста чакане, цялостното отношение към работещите в здравеопазването е позитивно, има доверие, което много улеснява работата. 

В България липсва доверие между пациенти и лекари. Също така няма достатъчно хора в системата, натоварването е огромно. В резултат е много вероятно, като отидеш да говориш с близки и пациенти, да си изнервен, защото си преуморен, а те от своя страна да са подозрителни и да не ти вярват. Как да се срещнете в тези условия? 

Тук разговорът, срещата между лекари и пациенти са стимулирани по всякакъв начин. Има стая за близки, където аз мога да седна и да говорим нормално с хората в дискретна среда колкото време е нужно. В България най-често сте изправени в коридор или пред някаква полуотворена врата, често без да можете да изолирате разговора от външни хора. 

Затова споменах „начин на мислене“, защото не става само с лични усилия от самата мен. Просто системата вижда и третира отношенията лекар–пациент по друг начин. 

В България, освен комуникацията, неглижирани са и дефинирането, и контролът на качеството на медицинската помощ. Обединеното кралство има традиции в създаването на професионални стандарти в медицината. Какво може да научи един млад български лекар за това в една болница като тази в Саутхемптън? 

Тук всичко е доста по-прозрачно, за всичко се води статистика и се правят одити. Тази прозрачност е необходима, за да се видят грешките в системата и да се коригират. Ако ти не проследяваш какво всъщност правиш, не водиш никаква статистика или поне не я показваш, ако никой никога не търси отговорност, то качеството със сигурност е по-лошо. В България като цяло нямаме система за това. Тук, примерно, ако си специализант, трябва всяка година да направиш някакъв малък одит на данни в болницата, в която работиш, по някаква тема, която ти избереш. Хората тук имат традиция да проследяват качеството на собствената си работа. Аз лично не съм виждала да се прави в България. 

Може ли да дадете пример за читателите, които не се занимават с медицина?

Аз се занимавам с кардиохирургия. Ако отидете на сайта на Дружеството на кардиохирурзите [в Обединеното кралство – б.р.], ще откриете данни болница по болница какви пациенти се оперират, каква е смъртността им, какви са усложненията им. В България такова нещо няма. 

Освен това дружествата тук изработват и насоки за клинично поведение. В България би било практично да ползваме европейските, но те също трябва да се преведат и адаптират, което не мисля, че се прави от всички дружества по специалности. 

Крайният резултат от всичко е, че тук е трудно да се види някой, който практикува медицината по много по-различен начин от друг. Тоест има някакво общо ниво и общо разбиране какво е добра практика и какво не е.

Колко време ще прекарат лекарите от програмата в болницата в Саутхемптън и до каква степен ще могат да се запознаят с тези процеси, които описвате?

Ще прекарат между 4 и 6 седмици. Първите специалисти ще видят как се вършат нещата в детската реанимация в болницата в Саутхемптън. Там се работи по съвременни протоколи, и то не само от лекарите, но и от сестрите. Например като предаваш пациент, има чеклист какво се прави – определени стъпки, за да се предотвратят човешки грешки. Човешките грешки са част от това, че сме хора, и съществуват винаги, но те могат да бъдат сведени до минимум, когато нещата са стандартизирани и има някакъв ред. 

Друг полезен според мен опит за колегите ще бъде да видят взаимоотношенията в отделението. Моят опит с отношенията между специалисти и специализанти от България не е особено позитивен. Тук взаимоотношенията са много по-професионални. Няма обвинения, няма повишаване на тон. Като цяло това води до по-безопасна практика, тъй като, ако някъде стане грешка или трябва да се каже нещо притеснително, не се страхуваш да го кажеш. 

От чисто медицинска гледна точка болницата има една интересна дейност – тъй като е регионална болница в Южна Англия, покрива доста голяма зона за транспорт на тежко болни деца в сътрудничество с оксфордската реанимация.

Тук организацията на болниците е горе-долу като в България – съществуват големи многопрофилни болници и малки болници, които са общински. Ако има дете, което е в тежко състояние в по-малък център, това звено се заема със задачата да го премести в големия център. Това всъщност е доста, доста трудна работа. И колегите ще могат да видят как се прави и как се организира. 

Ще могат да участват и в курсове за спешна животоспасяваща помощ* на деца. И не на последно място – ще видят на практика как протича комуникацията в реанимацията както с родители, така и с деца. 

Кога очаквате първите специализанти от България?

Очакваме през февруари да дойде един човек, а по-късно през годината още двама да минат през тази болница. Междувременно аз работя за връзки и с други реанимации. Желанието ни е да могат да се обучават поне по петима души годишно.

Има ли възможност по някакъв начин да се надгради този опит впоследствие? 

Това зависи в голяма степен и от самите лекари, които минават през обучението. В Англия постоянно има обяви за обучения, тук се наричат fellowship. Това е вече работа. Доста чужденци идват по този начин, за да се обучават. Колегите, които са преминали през първоначалния етап като клинични наблюдатели – observership, се ползват с предимство при кандидатстването за позиции за по-сериозни обучения. Освен това, докато са тук, могат да създадат контакти, които да улеснят последващо развитие. Аз лично съм се ангажирала да помагам на колегите в опознаването на стъпките и дори в подготовката на документи при нужда. 

Няколко пъти споменахте „детска реанимация“. Само за реаниматори ли е отворено това обучение, или и за лекари, обучаващи се в други тесни детски специалности?

За момента се опитваме да започнем с това. Партнираме си със Специализираната болница по детски болести в София и знаем със сигурност, че ръководството ѝ е готово да подкрепи лекари, работещи в тяхното интензивно отделение, да се включат в обученията. Извън това със сигурност има нужди, а тук има възможности, но ще ни е необходимо време, за да ги развием.

Може би е важно да обясня, че когато един млад лекар е клиничен наблюдател, той не просто се разхожда из болницата и наблюдава. Тук на тези обучения се гледа много сериозно и екипът се ангажира с обучението на младия лекар, затова няма възможност например в реанимацията по едно и също време да има много колеги със статут на клинични наблюдатели. Отделно в болницата в Саутхемптън често идват наблюдатели от други по-малки лечебни заведения от региона. 

Как ще се финансират „лекарите на бъдещето“? 

Фондация BCause ни подкрепи с организацията на кампанията, вече имаме профили в Платформата.бг и DMS. Необходимо е да се плати такса на болницата, която е над 1000 паунда. Отделно бихме искали да можем да покрием разходите на лекарите за път и престой. 

Просто в България има много малко възможности да видиш, че е добре нещата да се правят системно. Дори някой да прави нещо добре, системата ни има много недомислици и не ни позволява да сме консистентни: един път можем да предоставим добра помощ, следващия път – не. И не зависи само от нас. Затова е хубаво да се види цялостната организация на една система, която дава по-добри резултати. 

* Emergency life support (англ.) – това понятие обикновено се използва за процедури или мерки, предприемани в критични ситуации за поддържане на жизнените функции на пациента, например реанимация, изкуствена вентилация или сърдечен масаж.

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/1001863/

Security updates have been issued by Debian (libsoup2.4, python-aiohttp, and upx-ucl), Fedora (iaito, python3.11, python3.9, and radare2), Red Hat (ruby, ruby:2.5, and ruby:3.1), Slackware (mozilla-thunderbird), SUSE (govulncheck-vulndb, nodejs18, nodejs20, and socat), and Ubuntu (ofono and python-tornado).

Акаунтите на GovAlertEu са вече основно в Mastodon и Bluesky

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2024/govalerteu-mastodon-bluesky/

Светлината е най-добрият дезинфектант.

Преди малко повече от десет години се замислих, че ми е трудно да следя какво се случва из родните институции и мога да подобря процеса. Затова създадох система, която да изчита по няколко пъти на ден новини, документи, събития и други и да ги публикува в акаунт в Twitter. С времето източниците на информация се увеличиха на 140 от над 31 различни институции, а акаунтите станаха осем.

Проектът се нарича GovAlertEu и до скоро публикуваше съобщения в неофициални акаунти на няколко институции, включително тези на МВР и Министерски съвет. Акаунтът на МВР стана официален на два пъти – за последно при един от редовните кабинети. След това си върнах контрола над него. Този на Министерски съвет все още е официален и имат достъп до него като автоматизацията за публикуване на новини си остава.

Няколко неща се промениха в последната година. Първо, значително увеличеното количество информация, която публикувам за градоустройството в София, Пловдив и Благоевград, както и интереса към данните и визуализациите създаде натоварване на ресурсите, които използвам. Второ, промени в моделът на работа на Twitter/X като мрежа направи почти невъзможна работата на автоматизирани акаунти като моя без да се плаща значителни суми на месец. Суми, които биха били оправдани единствено за големи компании и astroturf бот мрежи, каквито сякаш са единствените останали там.

Още при първите крачки към затваряне на API достъпа до Twitter започнах да гледам мрежи като Mastodon. Тези дни довърших интеграцията и вече е достъпна за използване. Благодаря на @mapto, че ме насочи към подходящ код, който да използвам.

Акаунтите достъпни на новия портал

На адреса m.govalert.eu ще откриете всички акаунти свързани с тази мрежа. Там се публикуват в реално време без ограничения всички новини идващи от институциите. Тази страница е паралелно и портал за ActivityPub протокола, което значи, че може да ги следвате в която и да е Fedi мрежа искате, включително Mastodon. Свързал съм акаунтите пред Fedi Bridge с Bluesky, където съобщенията ще се появяват със забавяне от една до 15 мин.

Линковете към отделните мрежи, включително все още Twitter, ще намерите на самата страница като бутони. В Twitter от началото на годината заради ограниченията ще публикувам единствено препратки към Mastodon с ежедневна статистика колко съобщения са пропуснали следящите там. Като начало това ще се случи за основния акаунт на GovAlertEu, този на МВР и този за градоустройството в София. Този на правителството няма толкова много новини, така че ще остане последен.

Ще забележите, че липсват стари съобщения. В следващата седмица ще генерирам новините поне 4-5 години назад във времето. Искам да развия тази страница като основна за услугата заедно със статистика, индикация кои страници на администрацията са изтрити, изчезнали или променени, както и архивиране на някои от тях. В такива случаи линковете от социалните мрежи ще сочат към архивираната версия.

Също, вижда се, че акаунтът на парламента няма съобщения от известно време. Всъщност, източниците на информация не са 140, а 218 от 47 институции, но една немалка част от тях или са променили сайтовете си значително, или не публикуват вече нужната информация. Предвид смяна на фокуса към градоустройството не съм поддържал тези източници, но с този нов портал ще го направя – един по един ще ги обновя започвайки от страницата на парламента. Тази промяна отваря възможността да разширя значително информацията, която искам да публикувам като до сега въвеждах ограничения заради комуникацията с Twitter.

Моите акаунти в Mastodon и Bluesky ще намерите в линковете под блога ми. Приветствам всякаква обратна връзка и идеи.

The post Акаунтите на GovAlertEu са вече основно в Mastodon и Bluesky first appeared on Блогът на Юруков.

Android privacy improvements break key attestation

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/70630.html

Sometimes you want to restrict access to something to a specific set of devices – for instance, you might want your corporate VPN to only be reachable from devices owned by your company. You can’t really trust a device that self attests to its identity, for instance by reporting its MAC address or serial number, for a couple of reasons:

  • These aren’t fixed – MAC addresses are trivially reprogrammable, and serial numbers are typically stored in reprogrammable flash at their most protected
  • A malicious device could simply lie about them

If we want a high degree of confidence that the device we’re talking to really is the device it claims to be, we need something that’s much harder to spoof. For devices with a TPM this is the TPM itself. Every TPM has an Endorsement Key (EK) that’s associated with a certificate that chains back to the TPM manufacturer. By verifying that certificate path and having the TPM prove that it’s in posession of the private half of the EK, we know that we’re communicating with a genuine TPM[1].

Android has a broadly equivalent thing called ID Attestation. Android devices can generate a signed attestation that they have certain characteristics and identifiers, and this can be chained back to the manufacturer. Obviously providing signed proof of the device identifier is kind of problematic from a privacy perspective, so the short version[2] is that only apps installed using a corporate account rather than a normal user account are able to do this.

But that’s still not ideal – the device identifiers involved included the IMEI and serial number of the device, and those could potentially be used to correlate devices across privacy boundaries since they’re static[3] identifiers that are the same both inside a corporate work profile and in the normal user profile, and also remains static if you move between different employers and use the same phone[4]. So, since Android 12, ID Attestation includes an “Enterprise Specific ID” or ESID. The ESID is based on a hash of device-specific data plus the enterprise that the corporate work profile is associated with. If a device is enrolled with the same enterprise then this ID will remain static, if it’s enrolled with a different enterprise it’ll change, and it just doesn’t exist outside the work profile at all. The other device identifiers are no longer exposed.

But device ID verification isn’t enough to solve the underlying problem here. When we receive a device ID attestation we know that someone at the far end has posession of a device with that ID, but we don’t know that that device is where the packets are originating. If our VPN simply has an API that asks for an attestation from a trusted device before routing packets, we could pass that on to said trusted device and then simply forward the attestation to the VPN server[5]. We need some way to prove that the the device trying to authenticate is actually that device.

The answer to this is key provenance attestation. If we can prove that an encryption key was generated on a trusted device, and that the private half of that key is stored in hardware and can’t be exported, then using that key to establish a connection proves that we’re actually communicating with a trusted device. TPMs are able to do this using the attestation keys generated in the Credential Activation process, giving us proof that a specific keypair was generated on a TPM that we’ve previously established is trusted.

Android again has an equivalent called Key Attestation. This doesn’t quite work the same way as the TPM process – rather than being tied back to the same unique cryptographic identity, Android key attestation chains back through a separate cryptographic certificate chain but contains a statement about the device identity – including the IMEI and serial number. By comparing those to the values in the device ID attestation we know that the key is associated with a trusted device and we can now establish trust in that key.

“But Matthew”, those of you who’ve been paying close attention may be saying, “Didn’t Android 12 remove the IMEI and serial number from the device ID attestation?” And, well, congratulations, you were apparently paying more attention than Google. The key attestation no longer contains enough information to tie back to the device ID attestation, making it impossible to prove that a hardware-backed key is associated with a specific device ID attestation and its enterprise enrollment.

I don’t think this was any sort of deliberate breakage, and it’s probably more an example of shipping the org chart – my understanding is that device ID attestation and key attestation are implemented by different parts of the Android organisation and the impact of the ESID change (something that appears to be a legitimate improvement in privacy!) on key attestation was probably just not realised. But it’s still a pain.

[1] Those of you paying attention may realise that what we’re doing here is proving the identity of the TPM, not the identity of device it’s associated with. Typically the TPM identity won’t vary over the lifetime of the device, so having a one-time binding of those two identities (such as when a device is initially being provisioned) is sufficient. There’s actually a spec for distributing Platform Certificates that allows device manufacturers to bind these together during manufacturing, but I last worked on those a few years back and don’t know what the current state of the art there is

[2] Android has a bewildering array of different profile mechanisms, some of which are apparently deprecated, and I can never remember how any of this works, so you’re not getting the long version

[3] Nominally, anyway. Cough.

[4] I wholeheartedly encourage people not to put work accounts on their personal phones, but I am a filthy hypocrite here

[5] Obviously if we have the ability to ask for attestation from a trusted device, we have access to a trusted device. Why not simply use the trusted device? The answer there may be that we’ve compromised one and want to do as little as possible on it in order to reduce the probability of triggering any sort of endpoint detection agent, or it may be because we want to run on a device with different security properties than those enforced on the trusted device.

comment count unavailable comments

Защо в България вече няма масови протести?

Post Syndicated from Светла Енчева original https://www.toest.bg/zashto-v-bulgaria-veche-nyama-masovi-protesti/

Защо в България вече няма масови протести?

Ако човек не знае нищо за политиката в България и се поразходи вечер по улиците в центъра на София или големите градове, ще си каже, че всичко ни е наред. Заведенията – пълни, площадите – празни (поне откъм протестиращи), хората – видимо доволни, както се пееше в една песен.

А основания за масови протести има. България е в ситуация на институционален полуразпад. Вече три години и половина няма редовно правителство, което да изкара дори една година, да не говорим за пълен мандат. Повечето от т.нар. регулатори (включително Висшият съдебен съвет) са с изтекли мандати, а институции като омбудсмана са без ръководство. Делян Пеевски е завладял не само ДПС, а и върховете на правосъдната система, както и редица общини в страната. Същевременно не спират хибридните атаки от Русия, чиято цел е промяна на геополитическата ориентация на България.

А какви протести бяха…

След разпадането на тоталитарния режим в края на 1989 г. в България на няколко пъти се провеждаха масови протести. И то без да броим многолюдните митинги от декември 1989 г. до началото на 90-те. Ето няколко примера:

Виденовата зима

От 1995 до февруари 1997 г. управляваше правителство на БСП, а премиер беше Жан Виденов. През този период фалираха петнайсетина банки, а инфлацията, особено от 1996 г. нататък, излезе от контрол. Спестяванията на хората се стопиха. 

Личен спомен: през лятото на тази година бях студентка. Заради обезценяването на парите реших да закрия детския влог, открит навремето от баба ми. Парите, методично внасяни през цялото ми детство, стигнаха да купя сватбен подарък – един дезодорант и една самобръсначка.

В края на 1996 г. и началото на 1997 г. инфлацията прерасна в хиперинфлация. Ако сутринта забравех да купя макарони, привечер те вече струваха двойно. Заплатите станаха по 5–6 щатски долара. Не за ден, а за месец. В самия край на годината Виденов подаде оставка, но правителството му продължи да действа.

Насред тази ситуация започнаха протести, в които се включиха представители на всякакви групи – от студенти до пенсионери. Въпреки студа уличните шествия продължиха през целия януари и в началото на февруари.

Междувременно на 22 януари встъпи в длъжност президентът Петър Стоянов. По протокол той беше длъжен да връчи мандат за съставяне на правителство отново на БСП, които въпреки протестите напираха да съставят нов кабинет. Вместо направо да приеме папката с имената на новите министри, на 4 февруари Стоянов свика Консултативния съвет за национална сигурност, на който убеди вносителите да оттеглят предложението си.

Така протестът спечели. Въведе се валутен борд, който действа и до ден днешен. Проведоха се избори, спечелени с мнозинство от Обединените демократични сили, и в продължение на четири години управляваше кабинетът на Иван Костов.

#ДАНСwithme

През юни 2013 г. беше сложено началото на масовите протести против правителството на Пламен Орешарски. За да се стигне дотам обаче, роля изиграха едни други протести, заради които първият кабинет на Бойко Борисов падна. Това са т.нар. протести срещу монополите, насочени основно срещу високите цени на тока и срещу електроразпределителните дружества. Демонстрациите в десетки български градове прераснаха в политически. В този период варненецът Пламен Горанов се самоуби, като се запали пред сградата на Общината във Варна.

В резултат Борисов подаде оставка. На предсрочните избори ГЕРБ отново спечели, но Борисов отказа да състави правителство. Така мандатът отиде у БСП, която направи коалиционен кабинет с ДПС, подкрепян от „златния пръст“ на „Атака“.

Едно от първите неща, които новоизбраният премиер Пламен Орешарски направи, беше да предложи от парламентарната трибуна Делян Пеевски за ръководител на Държавната агенция за национална сигурност (ДАНС). Парламентът прие предложението и същата вечер – на 14 юни – започнаха протести, които продължиха повече от година, въпреки че Пеевски подаде оставка още на следващия ден. В тях се включиха и представители на ГЕРБ.

Освен с многохилядните шествия и със случаите на полицейско насилие, протестите срещу Орешарски се запомниха и с някои арт пърформанси (например възстановка на картината на Йожен Дьолакроа „Свободата води народа“). Както и с хаштаговете #ДАНСwithme – заигравка с ДАНС и английската дума за танц, и #КОЙ – защото никой не искаше да даде информация кой първоначално е предложил Пеевски за шеф на ДАНС. Заради този хаштаг и досега думата „кой“ се използва като синоним на Делян Пеевски.

С времето протестните шествия оредяха, но така и не изчезнаха. Пламен Орешарски подаде оставка през август 2014 г.

Протестите от 2020 г.

През 2020 г. на власт беше третото правителство на Борисов. Макар ГЕРБ да участваха в протестите от 2013 г., по време на следващите две управления, в които бяха водеща политическа сила, допуснаха ДПС (включително Пеевски) да дърпа конците както на правителството, така и на правосъдната система.

През юни бяха разпространени компромати, свързани с Бойко Борисов – снимки от спалнята му, на които се виждат пачки с пари, златни кюлчета и пистолет, както и запис, в който глас, приличащ на неговия, отправя заплахи. В края на месеца Антикорупционният фонд публикува първата част от журналистическото разследване „Осемте джуджета“.

За да илюстрират размерите на задкулисната власт и да покажат нагледно необходимостта от правосъдна реформа, през юли 2020 г. представители на партия „Да, България“, предвождани от председателя ѝ Христо Иванов, щурмуваха с лодка т.нар. сараи на почетния председател на ДПС Ахмед Доган в Росенец. Акцията извади наяве факта, че плажът около резиденцията на Доган, макар и държавна собственост, се охранява от служители на Националната служба за охрана и е на практика частен.

Комбинацията от тези събития даде тласък на протести, които също не се разминаха без полицейско насилие. Поради пандемията от COVID-19 те не бяха толкова масови, колкото през 2013 г. Но пак поради нея в тях успяха да се включат много български студенти, учещи в чужбина, които се бяха прибрали в родината заради временната отмяна на присъственото обучение.

Важна роля в протестите изигра и държавният глава Румен Радев, особено след като тежковъоръжени представители на прокуратурата демонстративно нахлуха в Президентството. В протестите, наред с „Демократична България“, се включи и проруската „Възраждане“, както и представители на левицата. Третото правителство на Борисов просъществува до април 2021 г.

Кой с кого и срещу кого?

От 2021 г. до днес последваха седем (досега) парламентарни избори и осем правителства, шест от които служебни. Тежко̀ им на бъдещите ученици, които ще четат за тези времена в учебниците по история!

В началото ситуацията изглеждаше ясна: всички срещу ГЕРБ и ДПС. Под „всички“ се разбираха президентът Румен Радев, новосъздадената пропрезидентска партия на Слави Трифонов „Има такъв народ“ (ИТН), БСП, Демократична България и коалицията „Изправи се! Мутри вън!“ (по-късно „Изправи се БГ! Ние идваме!“), предвождана от Мая Манолова. Въпреки че през 2013 г. Манолова, тогава от БСП, беше заявила, че тя е предложила Пеевски за шеф на ДАНС. После се отрече от думите си.

ИТН спечели изборите по-късно същата година, но абсурдните ѝ предложения за кабинет и не по-малко абсурдното поведение на членовете ѝ наведоха на идеята, че партията на Трифонов всъщност не иска да управлява. Междувременно в първото служебно правителство на Стефан Янев бяха изгрели звездите на Кирил Петков и Асен Василев. Те основаха собствен политически проект – „Продължаваме промяната“ (ПП), и спечелиха следващите избори. Петков стана премиер в коалиционно правителство на ПП, ДБ, БСП и ИТН.

В този период Радев беше на върха на популярността си и бе избран за втори мандат с подкрепата и на ПП. Не след дълго обаче президентът се обърна срещу Петков и Василев. Конфликтът между него и ПП се задълбочи, след като избухна войната на Русия срещу Украйна, защото ПП застанаха на страната на Украйна, а Радев е с проруски позиции.

Правителството на Петков падна през август 2022 г., след като ИТН се обърнаха срещу ПП. Последваха два служебни (и проруски) кабинета на Гълъб Донев. Народното събрание се сдоби с три проруски партии – „Възраждане“, „Български възход“ на бившия служебен премиер Стефан Янев и БСП.

Така вече основната опозиция не беше всички срещу ГЕРБ и ДПС, а Европа срещу Русия.

В тази ситуация ГЕРБ отново започнаха да изглеждат „от добрите“ и логично спечелиха следващите избори. И по-следващите. Тогава ПП, вече в коалиция с ДБ, се видяха принудени да участват в общо правителство с ГЕРБ, обявено като ротационно, за да престане Румен Радев да прокарва собствената си политика чрез служебни кабинети. Затова парламентът гласува и промени в Конституцията, важна част от които беше ограничаване на правомощията на президента.

Съвместното управление на ПП–ДБ и ГЕРБ, наречено „сглобка“ от Лена Бориславова от ПП, си имаше висока цена – легитимирането на ДПС. И в частност на Делян Пеевски. Първоначално това стана уж заради необходимото мнозинство за промените в Конституцията. Скоро обаче Пеевски се лепна за „сглобката“ и се изживяваше като официален неин говорител. А за всички проблеми ГЕРБ и ДПС изкарваха виновни ПП–ДБ. Накрая отказаха на мястото на Николай Денков премиер да стане Мария Габриел, за да се извърши ротацията на правителството. И то падна.

Последваха две служебни правителства на Димитър Главчев, чрез които – заради ограничените правомощия на президента – на практика управляват ГЕРБ и ДПС. Тоест най-вече ДПС, което междувременно се разцепи на лагер на Пеевски и лагер на Доган, а Пеевски използва властта си върху правосъдната система, за да овладее партията. Това доведе до силно манипулирани избори и разнообразни форми на натиск да се гласува за Пеевски.

Покрай всички тези събития Румен Радев отново изглежда „от добрите“. И започнаха да се множат проруски партии като „Величие“ (която за 21 гласа не влезе в последния парламент) и МЕЧ на бившия депутат от ИТН Радостин Василев.

Смисъл, заместен от паралелни реалности

Да обобщим. За няколко години вече почти всеки политически субект в България е бил в различни конфигурации както с останалите, така и срещу тях. Това подкопава доверието не само в съществуващите партии и коалиции, но и във функционирането на парламентарната демокрация.

Съответно изглежда, че масовите протести губят смисъл. За какво да се протестира и в какво би се изразило политическото представителство на един протест? Ако се протестира против корупцията и за правосъдна реформа, е много лесно гражданската енергия да бъде присвоена от проруски сили, както вече се е случвало. Ако се протестира в името на европейската ориентация на България, това може да изглежда като легитимация на „най-големите евроатлантици“ ГЕРБ и ДПС.

Междувременно хората непрекъснато биват облъчвани с послания, които изместват общественото внимание от важните проблеми. Дали ще става дума за компроматни войни, дали полиция, съд и прокуратура ще се използват като бухалки за разправа с „непослушните“ (един от последните такива случаи беше искането на имунитета на Кирил Петков), дали ще са популистки промени в законите като тази за забраната на ЛГБТИ „пропагандата“ в училище – все ще се намери какво.

На всичко отгоре, въпреки че в действията му няма нищо демократично, Делян Пеевски се държи като говорител на демократичната общност в България. Обяснявайки например, че „болната демокрация се лекува само с повече демокрация“, а „най-мощният лек за демокрацията“ са изборите. Спорно е дали подобни твърдения могат да легитимират Пеевски като демократ. По-вероятно е да легитимират в очите на избирателите парламентарната демокрация като нещо „пеевско“.

Какво се задава на хоризонта

Докато парламентарната демокрация буксува, животът някак си върви. Вярно, за пореден път се обсъжда държавен бюджет, без някой да поема ясна политическа отговорност за него. Има риск България да загуби много пари от Плана за възстановяване и устойчивост. Но пък доходите растат, страната дори влезе в Шенген и има шансове да се дореди и до еврозоната. Логично е много хора да си мислят: значи може и без парламентарна демокрация.

Слез малко повече от година изтича вторият мандат на Румен Радев, а той е публичната личност с най-висок рейтинг в България. Ако създаде свой политически проект, много вероятно е той да е печеливш. Особено ако проектът се представи като алтернатива на настоящата неработеща политическа система. Така до установяването на някаква форма на авторитарно управление от путински тип има само една крачка.

Неотдавна Конституционният съд на Румъния отмени президентските избори заради данни за намеса на Русия в тях. Оказва се впрочем, че хибридните атаки в Румъния имат връзка с фирми, регистрирани в България. И че тези фирми сеят пропаганда и тук. За разлика от румънските институции обаче, българските не изглежда да забелязват някакъв проблем.

По същия начин службите за сигурност, прокуратурата и останалите отговорни институции не изглежда да проявяват интерес към темата за българите във Великобритания, разкрити като руски агенти. Дори след информацията, че те са планирали да убият журналиста Христо Грозев, който беше разкрил кой стои зад опита за убийство на руския опозиционер Алексей Навални.

Държавата си направи оглушки и след журналистическо разследване на „Свободна Европа“, разкриващо, че Русия има нелегално консулство в офиса на БСП във Варна.

Не само на държавата – и на обществото не изглежда да му пука

Като стана дума за БСП, след близо месец блокаж за председател на настоящото 51-во Народно събрание беше избрана конституционалистката Наталия Киселова, депутатка от гражданската квота на листата на партията. Тя е била на специализация в Москва в годината, в която Русия анексира Крим. Преди изборите БСП имаше билбордове с послание „Русия е наш приятел“ – въпреки че самата Русия е обявила България за неприятелска държава.

Избирането на Киселова стана с подкрепата на ПП–ДБ. След известни драми коалицията гласува по този начин, за да изолира проруската „Възраждане“. Никой от ПП–ДБ обаче не попита Киселова каква според нея е причината за войната в Украйна. Или чий е Крим. Като председателка на НС тя е един от хората, които Румен Радев би могъл да избере за служебен премиер, ако отново не се стигне до редовен кабинет.

За разлика от българите, грузинците протестират. Причината за гнева им е решението на проруската партия, спечелила изборите, за отлагане на преговорите за присъединяване към ЕС до 2028 г. Също така протестиращите смятат, че изборите са манипулирани, и оспорват резултатите от тях. До тази ситуация се стига след систематични опити на Русия да придърпа Грузия в своята сфера на влияние.

За разлика от Грузия, България вече е в ЕС. Вероятността обаче в страната да се установи недемократичен проруски режим по подобие на този на Виктор Орбан в Унгария изобщо не е за пренебрегване. Притеснително много знаци сочат към подобен сценарий. Ако той се осъществи, тогава вече може да е късно да протестираме.

How can we teach students about AI and data science? Join our 2025 seminar series to learn more about the topic

Post Syndicated from Jane Waite original https://www.raspberrypi.org/blog/how-can-we-teach-students-about-ai-and-data-science-2025-seminar-series/

AI, machine learning (ML), and data science infuse our daily lives, from the recommendation functionality on music apps to technologies that influence our healthcare, transport, education, defence, and more.

What jobs will be affected by AL, ML, and data science remains to be seen, but it is increasingly clear that students will need to learn something about these topics. There will be new concepts to be taught, new instructional approaches and assessment techniques to be used, new learning activities to be delivered, and we must not neglect the professional development required to help educators master all of this. 

An educator is helping a young learner with a coding task.

As AI and data science are incorporated into school curricula and teaching and learning materials worldwide, we ask: What’s the research basis for these curricula, pedagogy, and resource choices?

In 2024, we showcased researchers who are investigating how AI can be leveraged to support the teaching and learning of programming. But in 2025, we look at what should be taught about AI, ML, and data science in schools and how we should teach this. 

Our 2025 seminar speakers — so far!

We are very excited that we have already secured several key researchers in the field. 

On 21 January, Shuchi Grover will kick off the seminar series by giving an important overview of AI in the K–12 landscape, including developing both AI literacy and AI ethics. Shuchi will provide concrete examples and recently developed frameworks to give educators practical insights on the topic.

Our second session will focus on a teacher professional development (PD) programme to support the introduction of AI in Upper Bavarian schools. Franz Jetzinger from the Technical University of Munich will summarise the PD programme and share how teachers implemented the topic in their classroom, including the difficulties they encountered.

Again from Germany, Lukas Höper from Paderborn University, with Carsten Schulte will describe important research on data awareness and introduce a framework that is likely to be key for learning about data-driven technology. The pair will talk about the Data Awareness Framework and how it has been used to help learners explore, evaluate, and be empowered in looking at the role of data in everyday applications.  

Our April seminar will see David Weintrop from the University of Maryland introduce, with his colleagues, a data science curriculum called API Can Code, aimed at high-school students. The group will highlight the strategies needed for integrating data science learning within students’ lived experiences and fostering authentic engagement.

Later in the year, Jesús Moreno-Leon from the University of Seville will help us consider the  thorny but essential question of how we measure AI literacy. Jesús will present an assessment instrument that has been successfully implemented in several research studies involving thousands of primary and secondary education students across Spain, discussing both its strengths and limitations.

What to expect from the seminars

Our seminars are designed to be accessible to anyone interested in the latest research about AI education — whether you’re a teacher, educator, researcher, or simply curious. Each session begins with a presentation from our guest speaker about their latest research findings. We then move into small groups for a short discussion and exchange of ideas before coming back together for a Q&A session with the presenter. 

An educator is helping two young learners with a coding task.

Attendees of our 2024 series told us that they valued that the talks “explore a relevant topic in an informative way“, the “enthusiasm and inspiration”, and particularly the small-group discussions because they “are always filled with interesting and varied ideas and help to spark my own thoughts”. 

The seminars usually take place on Zoom on the first Tuesday of each month at 17:00–18:30 GMT / 12:00–13:30 ET / 9:00–10:30 PT / 18:00–19:30 CET. 

You can find out more about each seminar and the speakers on our upcoming seminar page. And if you are unable to attend one of our talks, you can watch them from our previous seminar page, where you will also find an archive of all of our previous seminars dating back to 2020.

How to sign up

To attend the seminars, please register here. You will receive an email with the link to join our next Zoom call. Once signed up, you will automatically be notified of upcoming seminars. You can unsubscribe from our seminar notifications at any time.

We hope to see you at a seminar soon!

The post How can we teach students about AI and data science? Join our 2025 seminar series to learn more about the topic appeared first on Raspberry Pi Foundation.

File Integrity Monitoring with Zabbix

Post Syndicated from Paulo R. Deolindo Jr. original https://blog.zabbix.com/file-integrity-monitoring-with-zabbix/29460/

We have often seen Zabbix used as a simple tool for monitoring network assets as well as Information and Communication Technology (ICT) infrastructure. While this concept is not incorrect, it is equally important to understand that with the advancement of Zabbix versions, more and more functionalities have been made available for other types of monitoring, enabling advanced data analysis and stunning visualizations through new and modern widgets in the frontend layer.

In this short blog post, we will explore some of the existing yet under-discussed features of Zabbix that contribute to the maturity of the cybersecurity discipline within organizations — a topic that is becoming increasingly critical in the corporate environment.

FIM – File Integrity Monitoring

FIM is a very common concept among information security tools, specifically in tools like SIEM/XDR (Security Information Event Management/Extended Detection and Response). The name is quite suggestive of its usability, but while some tools highlight this feature as one of their main functionalities, it is also available for those who use Zabbix – just not explicitly labeled under this name.
Here, we will approach FIM as a concept rather than just a functionality. This is because we aim to achieve a result, not merely have a menu with a name to claim compliance while using our tool. In fact, the outcome needs to be more important than mere “marketing.”

What should we expect from FIM?

Imagine that your servers have certain directories and/or files so critical that you cannot afford to neglect monitoring them for changes, insertions, or deletions. Additionally, these files may have owners and properties that must not be altered – otherwise, the systems that depend on them might lose the ability to read or execute their functions. This, at a minimum, is what we expect from FIM as a functionality.
To illustrate this a bit further, consider a database service like MariaDB:

# ls -lR /etc/mysql/
/etc/mysql/:
total 24
drwxr-xr-x 2 root root 4096 Jun 25 18:40 conf.d
-rwxr-xr-x 1 root root 1740 Nov 30 2023 debian-start
-rw------- 1 root root 544 Jun 25 18:43 debian.cnf
-rw-r--r-- 1 root root 1126 Nov 30 2023 mariadb.cnf
drwxr-xr-x 2 root root 4096 Sep 30 16:36 mariadb.conf.d
lrwxrwxrwx 1 root root 24 Oct 20 2020 my.cnf -> /etc/alternatives/my.cnf
-rw-r--r-- 1 root root 839 Oct 20 2020 my.cnf.fallback

/etc/mysql/conf.d:
total 8
-rw-r--r-- 1 root root 8 Oct 20 2020 mysql.cnf
-rw-r--r-- 1 root root 55 Oct 20 2020 mysqldump.cnf

/etc/mysql/mariadb.conf.d:
total 40
-rw-r--r-- 1 root root 575 Nov 30 2023 50-client.cnf
-rw-r--r-- 1 root root 231 Nov 30 2023 50-mysql-clients.cnf
-rw-r--r-- 1 root root 927 Nov 30 2023 50-mysqld_safe.cnf
-rw-r--r-- 1 root root 3795 Sep 30 16:36 50-server.cnf
-rw-r--r-- 1 root root 570 Nov 30 2023 60-galera.cnf
-rw-r--r-- 1 root root 76 Nov 8 2023 provider_bzip2.cnf
-rw-r--r-- 1 root root 72 Nov 8 2023 provider_lz4.cnf
-rw-r--r-- 1 root root 74 Nov 8 2023 provider_lzma.cnf
-rw-r--r-- 1 root root 72 Nov 8 2023 provider_lzo.cnf
-rw-r--r-- 1 root root 78 Nov 8 2023 provider_snappy.cnf

All the files, directories, and subdirectories listed above have already been configured, and the system (whatever it may be) is functioning perfectly. However, if someone suddenly decides to alter a configuration in the file /etc/mysql/mariadb.conf.d/50-server.cnf, this could be disastrous for the service. Regardless, the important thing to do is to monitor this scope and notify the relevant stakeholders so that an appropriate analysis can be conducted.

Zabbix can help with that. Let’s see how.

Zabbix and File Integrity Monitoring functions

Consider that the Zabbix agent is installed on the server to be monitored:

vfs.dir.count[/etc/mysql]

With this key, we can count the objects present within the /etc/mysql directory. Subsequently, we can create a trigger to be activated if there is any change related to the initial collection count, such as someone deleting or adding a file or directory in this location.

 

 

 

 

 

vfs.dir.size[/etc/mysql]

With this key, we can determine the total size in bytes used by the directories and configuration files. In the future, we can create a trigger that activates when this size changes, indicating the deletion or addition of a file.

vfs.file.exists[/etc/mysql/mariadb.conf.d/50-server.cnf]

Among several important files, we may have a greater interest in some configuration files, and we can validate their existence by creating a trigger that activates when such a file ceases to exist. This will clearly indicate that something important has disappeared.

In this case, the value “1” represents “OK” for the existence of the file.

vfs.file.cksum[/etc/mysql/mariadb.conf.d/50-server.cnf,sha256]

In addition to verifying the existence of the configuration file we consider important, we need to be informed if anything in it changes. This key handles that by generating a hash in a variety of possible formats, allowing a trigger to be activated in case of a hash change, which would reflect a file modification (unfortunately, we won’t know what exactly was altered).

vfs.file.regmatch[/etc/mysql/mariadb.conf.d/50-server.cnf,^max_connections\s+=\s+(\d+)]

We might have a specific parameter of interest – for example, the maximum number of connections allowed to the database. Monitoring this is important because if the configuration is set to the default value, it means that no “tuning” has been applied to the database. Alternatively, it could mean that someone simply deleted or commented out this line, causing it to be ignored by the system. Therefore, verifying whether the parameter exists and is properly configured is crucial.

In this case, the value “1” indicates that the regular expression was successfully found, meaning that the configuration or parameter we need to exist is indeed present.

vfs.file.regexp[/etc/mysql/mariadb.conf.d/50-server.cnf,^max_connections\s+=\s+(\d+),,,,\1]

Beyond verifying the existence and integrity of the file, it is also possible to determine what was changed within it. However, we would need to specify the configuration of interest using a regular expression. For example, considering that the maximum number of connections allowed by the database system is “x,” we can be alerted by a trigger if it changes to “y,” “z,” or any other value different from “x.” This setup allows us to monitor the parameter of interest with precision. This logic can be applied to any other parameter you consider important. Of course, there is another way to automate this process, but we will not cover that automation here.

In this case, the parameter defining the maximum number of connections is not only present, but we also know the exact number of connections. This way, we will have a history of the applied parameterization in case it is changed at any point.

vfs.file.owner[/etc/mysql/mariadb.conf.d/50-server.cnf]

vfs.file.owner[/etc/mysql/mariadb.conf.d/50-server.cnf,group]

The two keys above allow us to determine the owner of a file and (in the case of a Linux system) the owning group. We can also choose to monitor the user’s name or their UID in the system. Naturally, a trigger can be activated to alert us in case of an ownership change, indicating that someone might be “taking over” an important file in the system.

vfs.file.permissions[/etc/mysql/mariadb.conf.d/50-server.cnf]

The key above allows us to determine a file’s permissions—read, write, read and write, execution, or a special permission bit. Naturally, a trigger can be activated to alert us if there is any permission change in the file.

vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf]

The key above does not exist by default. It was created with a UserParameter, which is a customization for verifying a command that, in this case, checks the attributes of a specific file. Consider the following command executed directly in your system’s terminal:

# lsattr /etc/mysql/mariadb.conf.d/50-server.cnf
--------------e------- /etc/mysql/mariadb.conf.d/50-server.cnf

What interests us are the attributes:

--------------e-------

If someone who invades the system modifies the attribute of a file (for example) using this command…

# chattr +A /etc/mysql/mariadb.conf.d/50-server.cnf
# lsattr /etc/mysql/mariadb.conf.d/50-server.cnf
-------A------e------- /etc/mysql/mariadb.conf.d/50-server.cnf

…it could mean that someone does not want the system to log when this file was accessed (refer to the chattr command manual). Additionally, any other attribute can be added or removed, which poses a risk to the system because these attributes can alter how files are accessed, stored on disk, and later read. Therefore, we can create a UserParameter as follows:

# cd /etc/zabbix/zabbix_agent2.d/
# echo "UserParameter=vfs.file.attr[*],lsattr \$1 | cut -d\" \" -f1" > attr.conf
# zabbix_agent2 -R userparameter_reload

Finally, we can test the reading of attributes directly from the terminal:

# zabbix_agent2 -t vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf]
vfs.file.attr[/etc/mysql/mariadb.conf.d/50-server.cnf][s|-------A------e-------]

You can also try this now through the frontend.

When creating the item, don’t forget to create the trigger that should be activated in case there is a change in the attribute of a file, whatever it may be.

Paying attention to file access and modification times

To delve a bit deeper into the concept of FIM, we should ask ourselves if we are monitoring file access and modifications concerning their timestamps. In a way, if we have implemented everything proposed above, the answer is yes.

That said, there is an easier way to keep track of all the things we’ve discussed. It involves using this key:

vfs.dir.get[/etc/mysql]

When creating an item with this key, we will recursively obtain all its objects, such as subdirectories and files. The output format will be a JSON, which allows us to create LLD (Low-level Discovery) rules to automate FIM. Below is a small snippet of the monitoring output:

{
"basename": "mariadb.cnf",
"pathname": "/etc/mysql/mariadb.cnf",
"dirname": "/etc/mysql",
"type": "file",
"user": "root",
"group": "root",
"permissions": "0644",
"uid": 0,
"gid": 0,
"size": 1126,
"time": {
"access": "2024-11-30T23:01:01-0300",
"modify": "2023-11-30T01:42:37-0300",
"change": "2024-06-25T18:41:01-0300"
},
"timestamp": {
"access": 1733018461,
"modify": 1701319357,
"change": 1719351661
}
...

Considering that the output includes all objects from the main directory, this would be the most sensible approach to configure our FIM. However, it is necessary to create the LLD and prototypes. We will not cover this in detail in this article, but this is the path I recommend you follow.

Below is a “blueprint” for an LLD to create automated File Integrity Monitoring:

The “Master item”:

The “Dependent rule”:

The LLD Macro:

The item prototypes:

Below are the components of a trigger prototype (I created just one to symbolize a type of alert for file modification):

Name: Object: {#BASENAME} just changed

Event name: Object: {#BASENAME} just changed. Last hash: {ITEM.VALUE} The previous one: {?last(/MySQLDB/vfs.file.cksum["{#PATHNAME}",sha256],#2)} Object: {#BASENAME} just changed. Last hash: {ITEM.VALUE} The previous one: {?last(/MySQLDB/vfs.file.cksum["{#PATHNAME}",sha256],#2)}

Severity: Warning

Expression: last(/MySQLDB/vfs.file.cksum["{#PATHNAME}",sha256],#1)<>last(/MySQLDB/vfs.file.cksum["{#PATHNAME}",sha256],#2)

And then, some results:

Conclusion

The implementation of a robust File Integrity Monitoring system helps to ensure the security of IT infrastructure. Detecting unauthorized changes in critical files helps prevent attacks, identify security breaches, and ensure the integrity and availability of systems. With Zabbix, we have an effective solution to implement FIM, enabling process automation and the real-time visualization of changes. This monitoring not only reinforces protection against intrusions but also facilitates auditing and compliance with regulatory standards.

The main benefits of integrating File Integrity Monitoring with Zabbix include:

1. Early detection of changes in critical files, enabling quick responses.
2. Enhanced compliance with security regulations and internal policies.
3. Protection against malware and ransomware by identifying changes in essential files.
4. Ease of auditing with automated reports and modification histories.
5. Greater visibility and control over the integrity of data and systems in real time.
6. Operational efficiency through the automation of alerts and reports.
7. Improved proactive security, helping prevent attacks before they become critical.

By using Zabbix, organizations can strengthen their security posture and optimize risk management, ensuring that any unauthorized changes are detected and promptly corrected.

 

 

The post File Integrity Monitoring with Zabbix appeared first on Zabbix Blog.

Turbocharging GrabUnlimited with Temporal

Post Syndicated from Grab Tech original https://engineering.grab.com/turbocharging-grabunlimited-with-temporal

Welcome to the behind-the-scenes story of GrabUnlimited, Grab’s flagship membership program. We undertook the mammoth task of migrating from our legacy system to a Temporal1 workflow-based system, enhancing our ability to handle millions of subscribers with increased efficiency and resilience. The result? A whopping 80% reduction in open production incidents, and most importantly – an improved membership experience for our users. In this first part of the series, you will learn how to design a robust and scalable membership system as we delve into our own experience building one.

What is GrabUnlimited?

The idea behind GrabUnlimited, is pretty simple: you pay a monthly fee, you get monthly benefits as a member (e.g discounted food delivery fee). A membership system plays a key role in enhancing user experience by giving them more value for money, but also by building loyalty, making Grab their go-to app for everyday needs. However, as this program grew and evolved, it brought along unique challenges and opportunities.

With the initial triumph and significant surge in subscriber count by over 1000% from January 2022 to June 2023 – which we were super proud of! – the architecture that supported GrabUnlimited was starting to show signs of strain. Common subscriber concerns such as not receiving their membership benefits, along with developer issues marked by an increase in service outages highlighted the system’s low resiliency. The culprit? A backend service that, while functional, was not built to efficiently manage the complexities of a rapidly scaling membership model.

Deep dive into our previous system design

As engineers, we know that deciding to migrate any system to a new one is like changing the engine of a running car. It requires meticulous evaluation of the existing systems, a deep dive into the issues and their root causes, and a thorough analysis of potential solutions and their trade-offs.

How was GrabUnlimited designed?

Initially, GrabUnlimited systems were designed for an experiment and not a full-fledged regional product. The idea was to try it out as a minimum viable product over a restricted segment of a few hundred thousand users. Let’s first have a look at how the membership program works.

Figure 1. GrabUnlimited life of a membership flowchart.

Under the hood, our membership system relies on two main flows

  • Membership purchase: The user enrols for a certain duration (e.g 3 months), completes the payment through our Payment service, and receives benefits via our Reward service.
  • Membership renewal: A daily cron job2 checks which memberships need renewal, processes the payment, and delivers the benefits.

We employed a state machine3 approach to break down the membership process into smaller chunks called state handlers. For instance, a membership might transition through ‘Init’, ‘Charged’, ‘Rewarded’, and ‘Active’ states. To operate these states, we used Amazon’s Simple Queue Service (SQS). SQS acts as a manager, delegating state handlers to workers (our service) and monitoring the status of the state handler. If a worker fails to complete a task, SQS reassigns the task to another worker, ensuring no task is lost. The load is also spread across multiple workers, helping with scalability.

To safeguard our system against duplicate tasks such as charging the user twice, when a worker takes up a task, it would use a Redis lock4 mechanism with a time-to-live (TTL) of five minutes preventing any other worker from picking up the same task. If a worker fails or crashes, the lock expires and another worker can pick up the job.

So far, so good.

Figure 2. GrabUnlimited previous system design overview.

With our success came many challenges

As our subscriber base grew, we experienced an increase in system outages. To address this, we scrutinised metrics like the number of support tickets and gauged the toll on our engineering team. This included the time spent patching up issues and the opportunity cost of not developing new features or improvements.

From our subscribers’ point of view, we saw a steady increase in reported incidents.

  • Users were blocked because their membership status was corrupted in our database.
  • Memberships were not automatically renewed, or users were not able to resubscribe.
  • Users were not receiving their benefits after renewing their membership.

From the engineering team’s perspective, we were dedicating one engineer every week to battle these incidents full time. The on-call engineers were not only tasked with manually fixing all customer reports but were also swamped with frequent system alerts. This situation had three detrimental impacts on our team:

  • We were constantly putting out fires instead of addressing the root causes.
  • We were spending resources that could have been used to enhance our customers’ experience.
  • Our team’s motivation and confidence was taking a big hit.

Finding the architectural culprit

The first step was to clearly identify and understand the issues within our systems. We looked at the frequency of failures and their root cause. From there, we were able to detect recurring patterns, which led us to four major issues in our architecture.

Scalability

Our system’s cron job, which retrieves all daily memberships due for renewal from our database, becomes slower and more resource-intensive as the number of members increases. Despite our attempt to alleviate high database usage by dividing the process into multiple batches and running several cron jobs, we were still experiencing significant surges each time a cron job runs. So our only viable solution was vertical scaling5 of the database. In other words, we had a serious bottleneck in our system.

Figure 3. Database queries per second during membership renewals at night.

Concurrency6

Picture this – A user tries to cancel their membership in the middle of the auto-renewal process, and voila, we have what we call a “zombie” state where the membership is both cancelled and renewed. This situation happens due to the limitations of our 5-minute Redis lock. If the renewal process holding the lock doesn’t complete within the timeout, the lock is released, enabling the cancel process to obtain the lock and run concurrently.

Resiliency7

What happens when the Rewards service faces an outage? The user buys a membership but doesn’t receive the rewards. It’s like throwing a party but the guests never arrive. We had three issues here:

  • In the event where upstream services had an outage, we relied on SQS’s maximum number of retries without exponential backoff8, causing potential overloads on recovering services.
  • Our cron job being housed within the service itself was susceptible to interruptions during outages or service restarts.
  • Over time, the logic to transition between states in our state machine became complex and multi-responsibility as more states were added. This made our retry mechanism unreliable due to potential risks of double charging or double awarding users. Which leads us to our fourth culprit.

Idempotency9

Even when some steps could be retried, our system lacked idempotency guarantees – a safety net to ensure that a step could be repeated without unintended side effects. Although our critical upstream systems like Payments and Rewards support idempotency via idempotency keys, our service wasn’t originally designed with this in mind.

  • Users could be stuck in a state where the payment succeeded but they didn’t receive their benefits or received them twice, requiring manual intervention from engineers.
  • We were not able to auto-retry membership renewals if the cron job, database, or any service had an outage.
Figure 4. Example of Idempotency issue in our old system design. If a single task fails in a state handler, the whole step would be retried which could lead to a double awarding.

For example, consider a state handler “BenefitsAwarding” that follows these steps:

  1. Generate an idempotency key.
  2. Calls Reward service to award the first set of benefits to the subscriber using the key.
  3. Calls Reward service to award the second set of benefits to the subscriber using the key.

If step 3 fails due to an outage, and the step is retried and re-queued in SQS, it would restart from step 1. This generates a new idempotency key, meaning the Reward system wouldn’t recognize the retry and will award Benefits1 twice. One way to fix this with our current design is to substantially increase the number of states in our SQS state machine, to isolate tasks further rather than handling too much logic in a state handler. However, that would mean having hundreds of states making the whole process difficult to maintain.

Ultimately, most incidents traced back to one fundamental issue: Our systems were relying on a sequential process that couldn’t be easily replayed if any incident or disturbance happened during execution. We were placing all our bets on the happy path, a risky gamble indeed.

The Solution: Migrating our system to Temporal

Armed with a clear understanding of the problems and their impacts, we set out to explore potential solutions. This journey led us to consider refactoring our existing system or migrating to a new architecture that another team introduced to us: Temporal.

Enter Temporal

Temporal is an open-source workflow orchestration engine. Think of it as a more robust and battle-tested implementation of our previous SQS architecture. It’s designed to run millions of workflows concurrently and can recover/resume the state of a workflow execution at the exact point of failure even in the event of an outage. It has features like infinite retries, exponential backoff, rate limiting, and observability out of the box. This sounded exactly like what we needed! By using Temporal, we could offload the complexity of managing state transitions, retries, and task concurrency, allowing us to focus on our core business logic.

In order to make the right decision, we meticulously assessed our options over the following criteria: scalability10, reliability11, resiliency12, performance, development effort, cost, security, flexibility13, and testability14. We realised that most of what we needed to build to compensate for our system design gaps was already built into Temporal. Let’s have a sneak peek on how the architecture looks and how it solves all four major culprits we discussed.

Figure 5. GrabUnlimited new system design architecture.

Fixing our architecture culprits

Scalability

Let’s start with the easiest fix, remember our old cron job for membership renewals? We replaced it with Timer which allows a workflow to sleep and automatically wake up. Instead of renewing membership by batches, they are now renewed throughout the entire day based on the hour and minute when the user subscribed. What does this mean for us? We no longer need to fetch memberships from our database to trigger renewals. The workflow will resume at the due date to process the renewal, eliminating the database as a bottleneck.

Figure 6. Total queries per second (QPS) on database before and after the migration to Temporal.

Concurrency

Our legacy Redis lock mechanism was clearly not enough. However, with Temporal, we have alternative solutions to avoid race conditions. What happens if a user tries to cancel while the membership renewal workflow is being triggered? Temporal allows us to assign the same workflow ID to multiple workflows running mutually exclusive operations, ensuring only one operation runs at a time. Basically, we assigned the same workflow ID to both cancellation and renewal workflows, either cancellation happens first, removing the need to renew the consumer membership, or renewal takes the lead, and cancellation only happens after.

Figure 7. Total corrupted membership states (zombies) manually handled by engineers significantly decreased during our migration which started in February.

Resiliency

Out of the box, Temporal allowed us to put in place a few key resilience mechanisms like exponential backoff and infinite retry which was a key gap in our previous SQS architecture. That was great because we didn’t have to implement these mechanisms on our own and it meant that when calling key upstream services like Payment, we were able to precisely set our retry policies without overwhelming the service in case of an outage on their end.

Idempotency

Remember our fourth culprit from above? Our state handlers with SQS were performing too many tasks simultaneously, which made it risky to trust the retry process. This multi-responsibility nature introduced significant risks, including potential database corruption, double charging, and double awarding of benefits. Further breaking down these steps would result in hundreds of intermediary steps, each requiring careful maintenance and correct sequencing. With Temporal, you can imagine a membership as an ever-running workflow consisting of a sequence of steps that are automatically managed and retried in case of failures.

While this approach didn’t directly resolve idempotency issues, it made the system and the code more readable and allowed us to design steps with single responsibilities. This, in turn, made it simpler for us to develop and ensure these steps were idempotent.

Let’s take a look at our previous example with Temporal.

Figure 8. Temporal workflow: If a single task fails, only that task is retried.

Let’s consider the same use case where a member needs to receive their benefits. The tasks remain the same except we don’t need to persist the idempotency key as it will be in the Temporal workflow state instead.

  1. Generate idempotency keys.
  2. Calls Reward service to award the first set of benefits to the subscriber using the key abc1.
  3. Calls Reward service to award the second set of benefits to the subscriber using the second key xyz1.

If the “AssignBenefits2” step fails, and the process is retried by Temporal, it will restart directly from that step, thus preventing the double awarding we were experiencing with SQS. Thanks to this approach, we largely improved idempotency and resiliency in our system, which also led to great results in decreasing user reported incidents.

Figure 9. Total open production incidents reported by users related to membership issues from January to October 2024.

Embracing Temporal: Challenges and mindset shift

Transitioning to Temporal was quite a paradigm shift for our team. Rather than managing SQS state transitions, we could now focus on our core business logic while Temporal handled the complexities of state management, error handling, and retries. This change allowed us to streamline development, making our processes more intuitive.

However, this shift wasn’t without its challenges. Temporal features such as Workflow and Activity design, deterministic execution, and built-in retry mechanisms required a steep learning curve. We had to quickly adapt to Temporal’s new way of thinking, and while it took some time to master these tools, they ultimately led to a more robust and scalable system. The transition to Temporal brought not only technical improvements but also a new mindset for solving problems efficiently.

Key takeaways and conclusion

After a thorough analysis, we decided to transition our architecture to Temporal, as it outperformed on nearly every evaluation criteria. Here are the key takeaways from our experience:

  • Understand the problem, fix it for the future: Migrating legacy systems requires more than just patching up issues; it demands a deep dive into the root causes. For us, that meant addressing challenges in scalability, resiliency, and concurrency head-on to prevent future headaches.
  • Focusing on what matters: By adopting Temporal workflow orchestration, we could shift our focus to what really counts, core business logic. The result? An 80% reduction in production incidents and a much smoother post-migration experience.
  • Resilience and flexibility at scale: Temporal provided the infrastructure we needed to handle millions of subscribers with more robust processes for retries, idempotency, and state management. These features played a key role in ensuring the system remained stable and flexible as our user base grew.
  • The learning curve pays off: Every system migration has its challenges, but the payoff was transformative. Despite the initial hiccups, moving to Temporal allowed us to scale GrabUnlimited seamlessly while significantly improving both our development processes and the overall user experience.

Stay tuned for Part 2, where we dive into the challenges of the migration and the lessons learned along the way. How did we seamlessly migrate millions of users to this new architecture without disrupting their memberships? How did we implement Temporal without pausing development for months? And what roadblocks did we encounter as we scaled this solution to all our users? We’ll answer these questions and more in the next post.

Nothing would have been possible without the unwavering support of Abegail Nato Alcantara, Andrys Silalahi, Pavel Sidlo, and Renu Yadav.

Join us

Grab is the leading superapp platform in Southeast Asia, providing everyday services that matter to consumers. More than just a ride-hailing and food delivery app, Grab offers a wide range of on-demand services in the region, including mobility, food, package and grocery delivery services, mobile payments, and financial services across 700 cities in eight countries.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Definition of terms

  1. Temporal: Temporal is an open-source workflow orchestration platform. It allows developers to build scalable and reliable applications using familiar development patterns and easy-to-use tools. ↩

  2. Cron job: A cron job is a time-based job scheduler in Unix-like operating systems. Users can schedule jobs (commands or scripts) to run periodically at fixed times, dates, or intervals. ↩

  3. State machine: A state machine is a behavioural model used in computer science. It represents a system in terms of states and transitions between those states. ↩

  4. Redis lock mechanism: Redis is an in-memory data structure store that can be used as a database, cache, and message broker. A Redis lock mechanism is a way to ensure that only one computer in a distributed network can process a certain piece of code at a time. ↩

  5. Vertical scaling: also known as “scaling up”, is the process of adding more resources (such as memory, CPUs, or storage) to an existing server or database to enhance its performance and capacity. Which is different from Horizontal scaling, also known as “scaling out”, the process of adding more servers or nodes to a system to handle increased load. ↩

  6. Concurrency: In computing, concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome. ↩

  7. Resiliency: refers to the ability of a system or application to quickly recover from failures and continue its intended operation without significant interruption. ↩

  8. Exponential backoff: Exponential backoff is an algorithm that uses feedback to multiplicatively decrease the rate of some process, in order to gradually find an acceptable rate. In the context of the article, it refers to a strategy for retrying failed tasks with increasing wait times between retries. ↩

  9. Idempotency: An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions. ↩

  10. Scalability: The ability of a system to handle increased workload or demand by adding resources. ↩

  11. Reliability: The capacity of a system to consistently perform its intended functions without failure. ↩

  12. Resiliency: The ability of a system to recover quickly and effectively from failures or disruptions, ensuring continuity of service. ↩

  13. Flexibility: The architecture should be flexible enough to accommodate future changes in requirements. ↩

  14. Testability: The architecture should allow for effective testing to ensure the system works as expected. ↩

The collective thoughts of the interwebz