How to implement client certificate revocation list checks at scale with API Gateway

Post Syndicated from Arthur Mnev original https://aws.amazon.com/blogs/security/how-to-implement-client-certificate-revocation-list-checks-at-scale-with-api-gateway/

ityAs you design your Amazon API Gateway applications to rely on mutual certificate authentication (mTLS), you need to consider how your application will verify the revocation status of a client certificate. In your design, you should account for the performance and availability of your verification mechanism to make sure that your application endpoints perform reliably.

In this blog post, I demonstrate an architecture that will help you on your journey to implement custom revocation checks against your certificate revocation list (CRL) for API Gateway. You will also learn advanced Amazon Simple Storage Service (Amazon S3) and AWS Lambda techniques to achieve higher performance and scalability.

Choosing the right certificate verification method

One of your first considerations is whether to use a CRL or the Online Certificate Status Protocol (OCSP), if your certificate authority (CA) offers this option. For an in-depth analysis of these two options, see my earlier blog post, Choosing the right certificate revocation method in ACM Private CA. In that post, I demonstrated that OCSP is a good choice when your application can tolerate high latency or a failure for certificate verification due to TLS service-to-OCSP connectivity. When you rely on mutual TLS authentication in a high-rate transactional environment, increased latency or OCSP reachability failures may affect your application. We strongly recommend that you validate the revocation status of your mutual TLS certificates. Verifying your client certificate status against the CRL is the correct approach for certificate verification if you require reliability and lower, predictable latency. A potential exception to this approach is the use case of AWS Certificate Manager Private Certificate Authority (AWS Private CA) with an OCSP responder hosted on AWS CloudFront.

With an AWS Private CA OCSP responder hosted on CloudFront, you can reduce the risks of network and latency challenges by relying on communication between AWS native services. While this post focuses on the solution that targets CRLs originating from any CA, if you use AWS Private CA with an OCSP responder, you should consider generating an OCSP request in your Lambda authorizer.

Mutual authentication with API Gateway

API Gateway mutual TLS authentication (mTLS) requires you to define a root of trust that will contain your certificate authority public key. During the mutual TLS authentication process, API Gateway performs the undifferentiated heavy lifting by offloading the certificate authentication and negotiation process. During the authentication process, API Gateway validates that your certificate is trusted, has valid dates, and uses a supported algorithm. Additionally, you can refer to the API Gateway documentation and related blog post for details about the mutual TLS authentication process on API Gateway.

Implementing mTLS certificate verification for API Gateway

In the remainder of this blog post, I’ll describe the architecture for a scalable implementation of a client certificate verification mechanism against a CRL on your API Gateway.

The certificate CRL verification process presented here relies on a custom Lambda authorizer that validates the certificate revocation status against the CRL. The Lambda authorizer caches CRL data to optimize the query time for subsequent requests and allows you to define custom business logic that could go beyond CRL verification. For example, you could include other, just-in-time authorization decisions as a part of your evaluation logic.

Implementation mechanisms

This section describes the implementation mechanisms that help you create a high-performing extension to the API Gateway mutual TLS authentication process.

Data repository for your certificate revocation list

API Gateway mutual TLS configuration uses Amazon S3 as a repository for your root of trust. The design for this sample implementation extends the use of S3 buckets to store your CRL and the public key for the certificate authority that signed the CRL.

We strongly recommend that you maintain an updated CRL and verify its signature before data processing. This process is automatic if you use AWS Private CA, because AWS Private CA will update your CRL automatically on revocation. AWS Private CA also allows you to retrieve the CA’s public key by using an API call.

Certificate validation

My sample implementation architecture uses the API Gateway Lambda authorizer to validate the serial number of the client certificate used in the mutual TLS authentication session against the list of serial numbers present in the CRL you publish to the S3 bucket. In the process, the API Gateway custom authorizer will read the client certificate serial number, read and validate the CRL’s digital signature, search for the client’s certificate serial number within the CRL, and return the authorization policy based on the findings.

Optimizing for performance

The mechanisms that enable a predictable, low-latency performance are CRL preprocessing and caching. Your CRL is an ASN.1 data structure that requires a relatively high computing time for processing. Preprocessing your CRL into a simple-to-parse data structure reduces the computational cost you would otherwise incur for every validation; caching the CRL will help you reduce the validation latency and improve predictability further.

Performance optimizations

The process of parsing and validating CRLs is computationally expensive. In the case of large CRL files, parsing the CRL in the Lambda authorizer on every request can result in high latency and timeouts. To improve latency and reduce compute costs, this solution optimizes for performance by preprocessing the CRL and implementing function-level caching.

Preprocessing and generation of a cached CRL file

The first optimization happens when S3 receives a new CRL object. As shown in Figure 1, the S3 PutObject event invokes a preprocessing Lambda that validates the signature of your uploaded CRL and decodes its ASN.1 format. The output of the preprocessing Lambda function is the list of the revoked certificate serial numbers from the CRL, in a data structure that is simpler to read by your programming language of choice, and that won’t require extensive parsing by your Lambda authorizer. The asynchronous approach mitigates the impact of CRL processing on your API Gateway workload.

Figure 1: Sample implementation flow of the pre-processing component

Figure 1: Sample implementation flow of the pre-processing component

Client certificate lookup in a CRL

The optimization happens as part of your Lambda authorizer that retrieves the preprocessed CRL data generated from the first step and searches through the data structure for your client certificate serial number. If the Lambda authorizer finds your client’s certificate serial number in the CRL, the authorization request fails, and the Lambda authorizer generates a “Deny” policy. Searching through a read-optimized data structure prepared by your preprocessing step is the second optimization that reduces the lookup time and the compute requirements.

Function-level caching

Because of the preprocessing, the Lambda authorizer code no longer needs to perform the expensive operation of decoding the ASN.1 data structures of the original CRL; however, network transfer latency will remain and may impact your application.

To improve performance, and as a third optimization, the Lambda service retains the runtime environment for a recently-run function for a non-deterministic period of time. If the function is invoked again during this time period, the Lambda function doesn’t have to initialize and can start running immediately. This is called a warm start. Function-level caching takes advantage of this warm start to hold the CRL data structure in memory persistently between function invocations so the Lambda function doesn’t have to download the preprocessed CRL data structure from S3 on every request.

The duration of the Lambda container’s warm state depends on multiple factors, such as usage patterns and parallel requests processed by your function. If, in your case, API use is infrequent or its usage pattern is spiky, pre-provisioned concurrency is another technique that can further reduce your Lambda startup times and the duration of your warm cache. Although provisioned concurrency does have additional costs, I recommend you evaluate its benefits for your specific environment. You can also check out the blog dedicated to this topic, Scheduling AWS Lambda Provisioned Concurrency for recurring peak usage.

To validate that the Lambda authorizer has the latest copy of the CRL data structure, the S3 ETag value is used to determine if the object has changed. The preprocessed CRL object’s ETag value is stored as a Lambda global variable, so its value is retained between invocations in the same runtime environment. When API Gateway invokes the Lambda authorizer, the function checks for existing global preprocessed CRL data structure and ETag variables. The process will only retrieve a read-optimized CRL when the ETag is absent, or its value differs from the ETag of the preprocessed CRL object in S3.

Figure 2 demonstrates this process flow.

Figure 2: Sample implementation flow for the Lambda authorizer component

Figure 2: Sample implementation flow for the Lambda authorizer component

In summary, you will have a Lambda container with a persistent in-memory lookup data structure for your CRL by doing the following:

  • Asynchronously start your preprocessing workflow by using the S3 PutObject event so you can generate and store your preprocessed CRL data structure in a separate S3 object.
  • Read the preprocessed CRL from S3 and its ETag value and store both values in global variables.
  • Compare the value of the ETag stored in your global variables to the current ETag value of the preprocessed CRL S3 object, to reduce unnecessary downloads if the current ETag value of your S3 object is the same as the previous value.
  • We recommend that you avoid using built-in API Gateway Lambda authorizer result caching, because the status of your certificate might change, and your authorization decision would rest on out-of-date verification results.
  • Consider setting a reserved concurrency for your CRL verification function so that API Gateway can invoke your function even if the overall capacity for your account in your AWS Region is exhausted.

The sample implementation flow diagram in Figure 3 demonstrates the overall architecture of the solution.

Figure 3: Sample implementation flow for the overall CRL verification architecture

Figure 3: Sample implementation flow for the overall CRL verification architecture

The workflow for the solution overall is as follows:

  1. An administrator publishes a CRL and its signing CA’s certificate to their non-public S3 bucket, which is accessible by the Lambda authorizer and preprocessor roles.
  2. An S3 event invokes the Lambda preprocessor to run upon CRL upload. The function retrieves the CRL from S3, validates its signature against the issuing certificate, and parses the CRL.
  3. The preprocessor Lambda stores the results in an S3 bucket with a name in the form <crlname>.cache.json.
  4. A TLS client requests an mTLS connection and supplies its certificate.
  5. API Gateway completes mTLS negotiation and invokes the Lambda authorizer.
  6. The Lambda authorizer function parses the client’s mTLS certificate, retrieves the cached CRL object, and searches the object for the serial number of the client’s certificate.
  7. The authorizer function returns a deny policy if the certificate is revoked or in error.
  8. API Gateway, if authorized, proceeds with the integrated function or denies the client’s request.

Conclusion

In this post, I presented a design for validating your API Gateway mutual TLS client certificates against a CRL, with support for extra-large certificate revocation files. This approach will help you align with the best security practices for validating client certificates and use advanced S3 access and Lambda caching techniques to minimize time and latency for validation.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Security, Identity, and Compliance re:Post or contact AWS Support.

Arthur Mnev

Arthur is a Senior Specialist Security Architect for AWS Industries. He spends his day working with customers and designing innovative approaches to help customers move forward with their initiatives, improve their security posture, and reduce security risks in their cloud journeys. Outside of work, Arthur enjoys being a father, skiing, scuba diving, and Krav Maga.

Rafael Cassolato de Meneses

Rafael Cassolato de Meneses

Rafael Cassolato is a Solutions Architect with 20+ years in IT, holding bachelor’s and master’s degrees in Computer Science and 10 AWS certifications. Specializing in migration and modernization, Rafael helps strategic AWS customers achieve their business goals and solve technical challenges by leveraging AWS’s cloud platform.

Security updates for Thursday

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

Security updates have been issued by Debian (firefox-esr), Fedora (kernel), Mageia (bluez), Oracle (fence-agents, gstreamer1-plugins-bad-free, opensc, openssl, postgresql:10, and postgresql:12), Red Hat (postgresql:15 and tigervnc), Slackware (proftpd), and SUSE (docker, rootlesskit, firefox, go1.20-openssl, go1.21-openssl, gstreamer-plugins-bad, libreoffice, libssh2_org, poppler, putty, rabbitmq-server, wireshark, xen, xorg-x11-server, and xwayland).

Cyberattack on Ukraine’s Kyivstar Seems to Be Russian Hacktivists

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/12/cyberattack-on-ukraines-kyivstar-seems-to-be-russian-hacktivists.html

The Solntsepek group has taken credit for the attack. They’re linked to the Russian military, so it’s unclear whether the attack was government directed or freelance.

This is one of the most significant cyberattacks since Russia invaded in February 2022.

Celebrating young Coolest Projects creators at a London museum

Post Syndicated from Sophie Ashford original https://www.raspberrypi.org/blog/coolest-projects-creators-young-v-a-london/

Each year, young people all over the world share and celebrate their amazing tech creations by taking part in Coolest Projects, our digital technology showcase. Our global online showcase and local in-person events give kids a wonderful opportunity to celebrate their creativity with their communities, explore other young creators’ tech projects, and gain inspiration and encouragement for their future projects.

Coolest Projects exhibit at the Young V&A in London.
The Coolest Projects exhibit at the Young V&A in London.

Now, visitors to the Young V&A museum in London can also be inspired by some of the incredible creations showcased at Coolest Projects. The museum has recently reopened after a large reimagining, and some of the inspiring projects by Coolest Projects 2022 participants are now on display in the Design Gallery, ready to spark digital creativity among more young people.

Projects to solve problems

Many Coolest Projects participants showcase projects that they created to make an impact and solve a real-world problem that’s important to them, for example to help members of their local community, or to protect the environment.

A Coolest Projects entry at the Young V&A in London.
At Coolest Projects, Donal (age 9) showcased his creation to send notifications about coronavirus test results via email.

One example on display in the Young V&A gallery is EleVoc, by 15-year-old Chinmayi from India. Chinmayi was inspired to create her project after she and her family faced a frightening encounter:

“My family and I are involved in wildlife conservation. One time we were charged by elephants even though we were only passing by in a Jeep. This was my first introduction to human–animal conflict, and I wanted to find a way to solve it!” – Chinmayi

The experience prompted Chinmayi to create EleVoc, an early-warning device designed to reduce human–elephant conflict by detecting and classifying different elephant sounds and alerting nearby villages to the elephants’ proximity and behaviour.

Also exhibited at the Young V&A is the hardware project Gas Leak Detector by Sashrika, aged 11, from the USA. Gas Leak Detector is a device that detects if a fuel tank for a diesel-powered heating system is leaking and notifies householders through an app in a matter of second.

Sashrika knew this invention could really make a difference to people’s lives. She explained, “Typically, diesel gas tanks for heating are in the basement where people don’t visit every day. Leakage may be unnoticed and lead to fire or major repair cost.”

Projects to have fun

As well as projects designed to solve problems, Coolest Projects also welcomes young people who create things to entertain or have fun. 

A Coolest Projects entry at the Young V&A.
Harshit’s game for Coolest Projects, now exhibited in the Young V&A

At the Young V&A, visitors can enjoy the fun, fast-paced game project Runaway Nose, by 10-year-old Harshit from Ireland. Runaway Nose uses facial recognition, and players have to use their nose to interact with the prompts on the screen. 

Harshit shared the motivation behind his project:

“I wanted to make a fun game to get you thinking fast and that would get you active, even on a rainy day.” – Harshit

We can confirm Runaway Nose is a lot of fun, and a must-do activity for people of all ages on a visit to the museum.

Join in the celebration!

If you are in London, make sure to head to the Young V&A to see Chinmayi’s, Sashrika’s, and Harshit’s projects, and many more. We love seeing the ingenuity of the global community of young tech creators celebrated, and hope it inspires you and your young people.

With that in mind, we are excited that Coolest Projects will be back in 2024. Registrations for the global Coolest Projects online showcase will be open from 14 February to 22 May 2024, and any young creator up to age 18 anywhere in the world can get involved. We’ll also be holding in-person Coolest Projects events for young people in Ireland and the UK. Head to the Coolest Projects website to find out more.

The exhibition hall at Coolest Projects Ireland 2023.
Coolest Projects Ireland 2023.

Coolest Projects is for all young people, no matter their level of coding experience. Kids who are just getting started and would like to take part can check out the free project guides on our projects site. These offer step-by-step guidance to help everyone make a tech project they feel proud of.

To always get the latest news about all things Coolest Projects, from event updates to the fun swag coming for 2024, sign up for the Coolest Projects newsletter.

The post Celebrating young Coolest Projects creators at a London museum appeared first on Raspberry Pi Foundation.

DNS over HTTPS is now available in Amazon Route 53 Resolver

Post Syndicated from Danilo Poccia original https://aws.amazon.com/blogs/aws/dns-over-https-is-now-available-in-amazon-route-53-resolver/

Starting today, Amazon Route 53 Resolver supports using the DNS over HTTPS (DoH) protocol for both inbound and outbound Resolver endpoints. As the name suggests, DoH supports HTTP or HTTP/2 over TLS to encrypt the data exchanged for Domain Name System (DNS) resolutions.

Using TLS encryption, DoH increases privacy and security by preventing eavesdropping and manipulation of DNS data as it is exchanged between a DoH client and the DoH-based DNS resolver.

This helps you implement a zero-trust architecture where no actor, system, network, or service operating outside or within your security perimeter is trusted and all network traffic is encrypted. Using DoH also helps follow recommendations such as those described in this memorandum of the US Office of Management and Budget (OMB).

DNS over HTTPS support in Amazon Route 53 Resolver
You can use Amazon Route 53 Resolver to resolve DNS queries in hybrid cloud environments. For example, it allows AWS services access for DNS requests from anywhere within your hybrid network. To do so, you can set up inbound and outbound Resolver endpoints:

  • Inbound Resolver endpoints allow DNS queries to your VPC from your on-premises network or another VPC.Amazon Route 53 Resolver inbound endpoint architecture.
  • Outbound Resolver endpoints allow DNS queries from your VPC to your on-premises network or another VPC.Amazon Route 53 Resolver outbound endpoint architecture.

After you configure the Resolver endpoints, you can set up rules that specify the name of the domains for which you want to forward DNS queries from your VPC to an on-premises DNS resolver (outbound) and from on-premises to your VPC (inbound).

Now, when you create or update an inbound or outbound Resolver endpoint, you can specify which protocols to use:

  • DNS over port 53 (Do53), which is using either UDP or TCP to send the packets.
  • DNS over HTTPS (DoH), which is using TLS to encrypt the data.
  • Both, depending on which one is used by the DNS client.
  • For FIPS compliance, there is a specific implementation (DoH-FIPS) for inbound endpoints.

Let’s see how this works in practice.

Using DNS over HTTPS with Amazon Route 53 Resolver
In the Route 53 console, I choose Inbound endpoints from the Resolver section of the navigation pane. There, I choose Create inbound endpoint.

I enter a name for the endpoint, select the VPC, the security group, and the endpoint type (IPv4, IPv6, or dual-stack). To allow using both encrypted and unencrypted DNS resolutions, I select Do53, DoH, and DoH-FIPS in the Protocols for this endpoint option.

Console screenshot.

After that, I configure the IP addresses for DNS queries. I select two Availability Zones and, for each, a subnet. For this setup, I use the option to have the IP addresses automatically selected from those available in the subnet.

After I complete the creation of the inbound endpoint, I configure the DNS server in my network to forward requests for the amazonaws.com domain (used by AWS service endpoints) to the inbound endpoint IP addresses.

Similarly, I create an outbound Resolver endpoint and and select both Do53 and DoH as protocols. Then, I create forwarding rules that tell for which domains the outbound Resolver endpoint should forward requests to the DNS servers in my network.

Now, when the DNS clients in my hybrid environment use DNS over HTTPS in their requests, DNS resolutions are encrypted. Optionally, I can enforce encryption and select only DoH in the configuration of inbound and outbound endpoints.

Things to know
DNS over HTTPS support for Amazon Route 53 Resolver is available today in all AWS Regions where Route 53 Resolver is offered, including GovCloud Regions and Regions based in China.

DNS over port 53 continues to be the default for inbound or outbound Resolver endpoints. In this way, you don’t need to update your existing automation tooling unless you want to adopt DNS over HTTPS.

There is no additional cost for using DNS over HTTPS with Resolver endpoints. For more information, see Route 53 pricing.

Start using DNS over HTTPS with Amazon Route 53 Resolver to increase privacy and security for your hybrid cloud environments.

— Danilo

New Amazon CloudWatch log class to cost-effectively scale your AWS Glue workloads

Post Syndicated from Noritaka Sekiyama original https://aws.amazon.com/blogs/big-data/new-amazon-cloudwatch-log-class-to-cost-effectively-scale-your-aws-glue-workloads/

AWS Glue is a serverless data integration service that makes it easier to discover, prepare, and combine data for analytics, machine learning (ML), and application development. You can use AWS Glue to create, run, and monitor data integration and ETL (extract, transform, and load) pipelines and catalog your assets across multiple data stores.

One of the most common questions we get from customers is how to effectively optimize costs on AWS Glue. Over the years, we have built multiple features and tools to help customers manage their AWS Glue costs. For example, AWS Glue Auto Scaling and AWS Glue Flex can help you reduce the compute cost associated with processing your data. AWS Glue interactive sessions and notebooks can help you reduce the cost of developing your ETL jobs. For more information about cost-saving best practices, refer to Monitor and optimize cost on AWS Glue for Apache Spark. Additionally, to understand data transfer costs, refer to the Cost Optimization Pillar defined in AWS Well-Architected Framework. For data storage, you can apply general best practices defined for each data source. For a cost optimization strategy using Amazon Simple Storage Service (Amazon S3), refer to Optimizing storage costs using Amazon S3.

In this post, we tackle the remaining piece—the cost of logs written by AWS Glue.

Before we get into the cost analysis of logs, let’s understand the reasons to enable logging for your AWS Glue job and the current options available. When you start an AWS Glue job, it sends the real-time logging information to Amazon CloudWatch (every 5 seconds and before each executor stops) during the Spark application starts running. You can view the logs on the AWS Glue console or the CloudWatch console dashboard. These logs provide you with insights into your job runs and help you optimize and troubleshoot your AWS Glue jobs. AWS Glue offers a variety of filters and settings to reduce the verbosity of your logs. As the number of job runs increases, so does the volume of logs generated.

To optimize CloudWatch Logs costs, AWS recently announced a new log class for infrequently accessed logs called Amazon CloudWatch Logs Infrequent Access (Logs IA). This new log class offers a tailored set of capabilities at a lower cost for infrequently accessed logs, enabling you to consolidate all your logs in one place in a cost-effective manner. This class provides a more cost-effective option for ingesting logs that only need to be accessed occasionally for auditing or debugging purposes.

In this post, we explain what the Logs IA class is, how it can help reduce costs compared to the standard log class, and how to configure your AWS Glue resources to use this new log class. By routing logs to Logs IA, you can achieve significant savings in your CloudWatch Logs spend without sacrificing access to important debugging information when you need it.

CloudWatch log groups used by AWS Glue job continuous logging

When continuous logging is enabled, AWS Glue for Apache Spark writes Spark driver/executor logs and progress bar information into the following log group:

/aws-glue/jobs/logs-v2

If a security configuration is enabled for CloudWatch logs, AWS Glue for Apache Spark will create a log group named as follows for continuous logs:

<Log-Group-Name>-<Security-Configuration-Name>

The default and custom log groups will be as follows:

  • The default continuous log group will be /aws-glue/jobs/logs-v2-<Security-Configuration-Name>
  • The custom continuous log group will be <custom-log-group-name>-<Security-Configuration-Name>

You can provide a custom log group name through the job parameter –continuous-log-logGroup.

Getting started with the new Infrequent Access log class for AWS Glue workload

To gain the benefits from Logs IA for your AWS Glue workloads, you need to complete the following two steps:

  1. Create a new log group using the new Log IA class.
  2. Configure your AWS Glue job to point to the new log group

Complete the following steps to create a new log group using the new Infrequent Access log class:

  1. On the CloudWatch console, choose Log groups under Logs in the navigation pane.
  2. Choose Create log group.
  3. For Log group name, enter /aws-glue/jobs/logs-v2-infrequent-access.
  4. For Log class, choose Infrequent Access.
  5. Choose Create.

Complete the following steps to configure your AWS Glue job to point to the new log group:

  1. On the AWS Glue console, choose ETL jobs in the navigation pane.
  2. Choose your job.
  3. On the Job details tab, choose Add new parameter under Job parameters.
  4. For Key, enter --continuous-log-logGroup.
  5. For Value, enter /aws-glue/jobs/logs-v2-infrequent-access.
  6. Choose Save.
  7. Choose Run to trigger the job.

New log events are written into the new log group.

View the logs with the Infrequent Access log class

Now you’re ready to view the logs with the Infrequent Access log class. Open the log group /aws-glue/jobs/logs-v2-infrequent-access on the CloudWatch console.

When you choose one of the log streams, you will notice that it redirects you to the CloudWatch console Logs Insight page with a pre-configured default command and your log stream selected by default. By choosing Run query, you can view the actual log events on the Logs Insights page.

Considerations

Keep in mind the following considerations:

  • You cannot change the log class of a log group after it’s created. You need to create a new log group to configure the Infrequent Access class.
  • The Logs IA class offers a subset of CloudWatch Logs capabilities, including managed ingestion, storage, cross-account log analytics, and encryption with a lower ingestion price per GB. For example, you can’t view log events through the standard CloudWatch Logs console. To learn more about the features offered across both log classes, refer to Log Classes.

Conclusion

This post provided step-by-step instructions to guide you through enabling Logs IA for your AWS Glue job logs. If your AWS Glue ETL jobs generate large volumes of log data that makes it a challenge as you scale your applications, the best practices demonstrated in this post can help you cost-effectively scale while centralizing all your logs in CloudWatch Logs. Start using the Infrequent Access class with your AWS Glue workloads today and enjoy the cost benefits.


About the Authors

Noritaka Sekiyama is a Principal Big Data Architect on the AWS Glue team. He works based in Tokyo, Japan. He is responsible for building software artifacts to help customers. In his spare time, he enjoys cycling on his road bike.

Abeetha Bala is a Senior Product Manager for Amazon CloudWatch, primarily focused on logs. Being customer obsessed, she solves observability challenges through innovative and cost-effective ways.

Kinshuk Pahare is a leader in AWS Glue’s product management team. He drives efforts on the platform, developer experience, and big data processing frameworks like Apache Spark, Ray, and Python Shell.

LSFMM+BPF 2024 call for proposals

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

The 2024 Linux Storage, Filesystem, Memory-Management, and BPF Summit will
be held May 13 to 15 in Salt Lake City, Utah, USA. The call
for proposals
has already gone out, with a deadline of March 1.
“LSF/MM/BPF is an invitation-only technical workshop to map out
improvements to the Linux storage, filesystem, BPF, and memory management
subsystems that will make their way into the mainline kernel within the
coming years.
”

Seven stable kernels

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

The
6.6.8,
6.1.69,
5.15.144,
5.10.205,
5.4.265,
4.19.303, and
4.14.334
stable kernel updates have all been released; each contains another set of
important fixes.

Note that 5.15.145
is already in the review process, with a due date of December 22. It
consists almost exclusively of ksmbd patches in a flurry of backporting
that was seemingly inspired by the recent marking
of ksmbd as broken in 5.15
.

Expanded Coverage and AWS Compliance Pack Updates in InsightCloudSec Coming Out of AWS Re:Invent 2023

Post Syndicated from Lara Sunday original https://blog.rapid7.com/2023/12/20/expanded-coverage-and-aws-compliance-pack-updates-in-insightcloudsec-coming-out-of-aws-re-invent-2023/

Expanded Coverage and AWS Compliance Pack Updates in InsightCloudSec Coming Out of AWS Re:Invent 2023

It seems like it was just yesterday that we were in Las Vegas for AWS Re:Invent, but it’s already been almost two weeks since the conference wrapped up. As is always the case, AWS unveiled a host of new services throughout the week, including advancements around serverless, artificial intelligence (AI) and Machine Learning (ML), security and more.

There were a ton of really exciting announcements, but a few stood out to me. Before we dive into the new and updated services we now support in InsightCloudSec, let’s take a second to highlight a few of them and why they’re of note.

Highlights from AWS’ New Service Announcements during Re:Invent

Amazon Bedrock general availability was announced back in October, re:Invent brought with it announcements of new capabilities including customized models, GenAI applications to execute multi-step tasks, and Guardrails announced in preview. New Security Hub functionalities were introduced, including centralized governance, custom controls and a refresh of the dashboard.

Serverless innovations include updates to Amazon Aurora Limitless Database, Amazon ElasticCache Serverless, and AI-driven Amazon Redshift Serverless adding greater scaling and efficiency to their database and analytics offerings. Serverless architectures bring scalability and flexibility, however security and risk considerations shift away from traditional network traffic inspection and access control lists, towards IAM hygiene, system identity behavioral analysis along with code integrity and validation.

Amazon Datazone general availability, like Bedrock, was originally announced in October and got some new innovations showcased during Re:Invent including business driven domains and data catalog, projects and environments, and the ability for data workers to publish and data consumers to subscribe to workflows. Available in open preview for Datazone are automated, AI-driven recommendations for metadata-driven business descriptions and specific columns and analytical applications based on business units.

One of the most exciting announcements from Re:Invent this year was Amazon Q, Amazon’s new GenAI-powered Virtual Assistant. Q was also integrated into Amazon’s Business Intelligence (BI) service, QuickSight, which has been supported in InsightCloudSec for some time now.

Having released our support for Amazon OpenSearch last year, this year’s re:Invent brought some exciting updates that are worth mentioning here. Now generally available is Vector Engine for OpenSearch Serverless, which enables users to store and quickly search vector embeddings for GenAI applications. AWS also announced the OR1 Instance family, which is compute optimized specifically for OpenSearch and also a new zero-ETL integration with S3.

Expanded Resource Coverage in InsightCloudSec

It’s very important to us here at Rapid7 that we provide our customers with the peace of mind to know when their teams leave these events and begin implementing new innovations from AWS that they’re doing so securely. To that end, the days and weeks following Re:Invent is always a bit of a sprint, and this year was no exception.

The Coverage and Analysis team loves a challenge though, and in my totally unbiased opinion — we’ve delivered something special. Our latest release featured new support for a variety of the new services announced during Re:Invent, as well as, a number of existing services we’ve expanded support for in relation to updates announced by AWS. We’ve added support for 6 new services that were either announced or updated during the show. We’ve also added 25 new Insights, all of which have been applied to our existing AWS Foundational Security Best Practices pack, AWS Center for Internet Security (CIS) 2.0 compliance pack, as well as new AWS relevant updates to NIST SP800-53 (Rev 5).

The newly supported services are:

  • Bedrock, a fully managed service that allows users to build generative AI applications in the cloud by providing a set of foundational models both from AWS and 3rd party vendors.
  • Clean Rooms, which enables customers to collaborate and analyze data securely in ‘clean rooms’ in minutes with any other company on joint initiatives without sharing real raw data.
  • AWS Control Tower (January 2024 Release), a management service that can be used to create and orchestrate a multi-account AWS environment in accordance with AWS best practices including the Well-Architected Framework.

Along with support for newly-added services, we’ve also expanded our coverage around the host of existing services as well. We’ve added or expanded support for the following security and serverless solutions:

  • Network Firewall, which provides fine-grained control over network traffic.
  • Security Hub, an AWS’ native service that provides CSPM functionality, aggregating security and compliance checks.
  • Glue, a serverless data integration service that makes it easy for analytics users to discover, prepare, move, and integrate data from multiple sources, empowering your analytics and ML projects.

Helping Teams Securely Build AI/ML Applications in the Cloud

One of the most exciting elements to come out of the past few weeks with the addition of AWS Bedrock, is our extended coverage for AI and ML solutions that we are now able to provide across cloud providers for our customers. Supporting AWS Bedrock, along with GCP Vertex and Azure OpenAI Service has enabled us to build a very exciting new feature as part of our Compliance Packs.

Machine learning, artificial intelligence, and analytics were driving themes of this year’s conference, so it makes me very happy to announce that we now offer a dedicated Rapid7 AI/ML Security Best Practices compliance pack. If interested, I highly recommend you keep an eye out in the coming days for my colleague Kathryn Lynas-Blunt’s blog discussing how Rapid7 enables teams to securely build AI applications in the cloud.

As a cloud enthusiast, AWS re:Invent never fails to deliver on innovation, excitement and shared learning experiences. As we continue our partnership with AWS, I’m very excited for all that 2024 holds in store. Until next year!

Security updates for Wednesday

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

Security updates have been issued by Fedora (ansible and ansible-core), Gentoo (Minecraft Server and thunderbird), Mageia (fusiondirectory), Red Hat (gstreamer1-plugins-bad-free, opensc, and openssl), Slackware (libssh and mozilla), SUSE (avahi, firefox, ghostscript, gstreamer-plugins-bad, mariadb, openssh, openssl-1_1-livepatches, python-aiohttp, python-cryptography, xorg-x11-server, and xwayland), and Ubuntu (libssh and openssh).

Don’t Let the Cyber Grinch Ruin your Winter Break: Project Cybersafe Schools protects small school districts in the US

Post Syndicated from Zaid Zaid http://blog.cloudflare.com/author/zaid-zaid/ original https://blog.cloudflare.com/project-cybersafe-schools-update


As the last school bell rings before winter break, one thing school districts should keep in mind is that during the winter break, schools can become particularly vulnerable to cyberattacks as the reduced staff presence and extended downtime create an environment conducive to security lapses. Criminal actors make their move when organizations are most vulnerable: on weekends and holiday breaks. With fewer personnel on-site, routine monitoring and response to potential threats may be delayed, providing cybercriminals with a window of opportunity. Schools store sensitive student and staff data, including personally identifiable information, financial records, and confidential academic information, and therefore consequences of a successful cyberattack can be severe. It is imperative that educational institutions implement robust cybersecurity measures to safeguard their digital infrastructure.

If you are a small public school district in the United States, Project Cybersafe Schools is here to help. Don’t let the Cyber Grinch ruin your winter break.

The impact of Project Cybersafe Schools thus far

In August of this year, as part of the White House Back to School Safely: K-12 Cybersecurity Summit, Cloudflare announced Project Cybersafe Schools to help support eligible K-12 public school districts with a package of Zero Trust cybersecurity solutions — for free, and with no time limit.

The response from school districts across the United States exceeded our expectations. We have had inquiries from over 200 school districts in over 30 states and Guam. Over the past few months, we have onboarded dozens of qualifying school districts into the program. As a result, over 60,000 students, teachers, and staff are protected by Cloudflare’s cloud email security to protect against a broad spectrum of threats including Business Email Compromise, multichannel phishing, credential harvesting, and other targeted attacks. These school districts are also receiving protection against Internet threats with DNS filtering by preventing users from reaching unwanted or harmful online content like ransomware or phishing sites. There are more than 9,000 small public school districts across the United States with fewer than 2,500 students. All of those school districts are eligible for Project Cybersafe Schools (for free, and with no time limit — see below for all the details), and we want to help as many as possible.

Since we launched the program, the White House has continued to amplify awareness around the risks for schools as well as the opportunities school districts have to protect themselves. Cloudflare hosted a series of live onboarding sessions at the start of the program and also created a Cybersafe School Resource Hub for school districts to learn more about the program and submit an inquiry.

What our participants are saying about the program

Here’s what a few Project Cybersafe Schools have to say about the impact of the program on small school districts.

“Project Cybersafe Schools has been incredibly helpful, especially for school districts with smaller enrollments, to provide resources, tools and information that otherwise might be out of grasp. Often, these smaller districts have individuals with many responsibilities and cybersecurity may not always be at the forefront. The tools Cloudflare offers as part of the White House focus to strengthen Cybersecurity across the K-12 spectrum allow us greater visibility into the threats experienced through E-Mail as well as protect our devices by layering DNS-based filtering on top of our existing environment to protect against threats that may come through via ransomware or phishing sites. Being able to leverage multiple layers of security helps us be more robust in protecting our student and teacher devices and ensure our learning environment is successful, safe and productive in the current digital landscape.”  
– Randy Saeks, Network Manager, Glencoe School District 35, Glencoe, Illinois

“Quitman School District was excited to add another layer of security for our staff and students with Cloudflare Project Cybersafe Schools. Living in a low income, rural community, we were grateful for the opportunity to add a world-class free service to our school’s network architecture. Partnering with Cloudflare allowed us to continue to modernize and strengthen our security measures and protect our staff and students from a wide variety of threats. This implementation was quick and easy, and we were ecstatic that there was no expiration date for this service.  We were amazed to see that Cloudflare caught nearly 4,000 malicious emails in the first month of implementation!  We are confident that Cloudflare will continue to keep our district and infrastructure safe from harmful threats.”
– Matt Champion, Technology Coordinator, Quitman School District, Quitman, Mississippi

What Zero Trust services are available?

Eligible K-12 public school districts in the United States will have access to a package of enterprise-level Zero Trust cybersecurity services for free and with no time limit – there is no catch and no underlying obligations. Eligible organizations will benefit from:

  • Email Protection: Safeguards inboxes with cloud email security by protecting against a broad spectrum of threats including malware-less Business Email Compromise, multichannel phishing, credential harvesting, and other targeted attacks.
  • DNS Filtering: Protects against Internet threats with DNS filtering by preventing users from reaching unwanted or harmful online content like ransomware or phishing sites and can be deployed to comply with the Children’s Internet Protection Act (CIPA).

Who can apply?

To be eligible, Project Cybersafe Schools participants must be:

  • K-12 public school districts located in the United States
  • Up to 2,500 students in the district

If you think your school district may be eligible, we welcome you to contact us to learn more.  Please visit our Project Cybersafe Schools Resource Hub.

For schools or school districts that do not qualify for Project Cybersafe Schools, Cloudflare has other packages available with educational pricing. If you do not qualify for Project Cybersafe Schools, but are interested in our educational services, please contact us at [email protected].

Да изтеглиш късата клечка, или за (не)възможната смяна на юридическия пол в България

Post Syndicated from Светла Енчева original https://www.toest.bg/da-izteglish-kusata-klechka-ili-za-nevuzmozhnata-smyana-na-yuridicheskiya-pol-v-bulgaria/

Да изтеглиш късата клечка, или за (не)възможната смяна на юридическия пол в България

Кампанията срещу Конвенцията на Съвета на Европа за превенция и борба с насилието над жени и домашното насилие, по-известна като Истанбулската конвенция, в България има последствия, отиващи далеч. Потърпевши са не само транс хората, а цялото общество. Този извод може да се направи от прочита на една книга, чиято премиера беше миналата седмица: „Юридическото признаване на пола в България. Настояще и перспективи“. Тя е издание на Фондация „Ресурсен център Билитис“, разпространява се безплатно, а в скоро време ще е налична и в електронен формат.

За книгата

Да изтеглиш късата клечка, или за (не)възможната смяна на юридическия пол в България

Идеята за правен анализ на юридическата смяна на пола възниква поради разнопосочните практики на българските съдилища в това отношение (за тях ще стане дума по-долу). Тези практики допълнително се усложниха от решенията на Конституционния съд (КС) от 2018 г. и 2021 г. С първото решение Истанбулската конвенция беше обявена за противоконституционна, а с второто КС постанови, че полът е единствено биологичен.

Първоначалната идея е за доклад. Понеже темата се оказва твърде обширна, от един доклад стават четири. Когато те са почти готови, Върховният касационен съд (ВКС) излиза с решение, с което на практика отменя юридическата смяна на пола. Именно това събитие дава импулса докладите да се доразвият и да се обединят в книга. Резултатът е книжно тяло от 233 страници, дело на четирима юристи – правозащитника Радослав Стоянов (отговорен и за общата редакция), адвокатките Силвия Петкова и Галина Чеширова, както и доц. Велина Тодорова.

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

Кой има нужда от юридическо признаване на пола?

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

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

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

Как е решен въпросът със смяната на юридическия пол в други страни?

Разбира се, има държави, в които транс хората се преследват от закона. В книгата обаче се обръща внимание на добрите практики и се дава пример с Малта, Исландия, Норвегия, Швейцария и Аржентина.

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

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

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

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

Смяната на юридическия пол в България до неотдавна – възможна, но неуредена

Смяната на пола по документи в България е възможна в продължение на повече от 30 години – до 20 февруари 2023 г., когато ВКС постанови, че „такова животно няма“. Според Закона за гражданската регистрация и в Правилника за издаване на български лични документи към Закона за българските лични документи се допуска, че човек може да смени юридическия си пол, но нямаше ясни правила как да става това, което беше предпоставка за хаос. Според съдебната практика имаше две минимални условия, но не всички съдилища се съобразяват с тях:

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

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

Три съдилища, три различни решения

В книгата се прави анализ на всички дела за смяна на пола в България, до които авторките на съответната глава са получили достъп (някои съдилища, включително в София, са отказали да им предоставят такъв). И са стигнали до извода, че има три основни типове решения по тези дела. Ще ги представим чрез три измислени персонажа, разказите за които обобщават много истински истории.

Вариант 1: „Имате грешка!“

Диян е транс мъж, който се е подложил на хормонална терапия и операция за смяна на пола. Преди решението на ВКС неговият вариант се случва статистически най-рядко, но това не му помага – той „изтегля късата клечка“. Съдът постановява, че полът в документите му може да бъде сменен само ако първоначално е бил вписан грешно в акта за раждане. Щом Диян е роден с женско тяло, няма никакво значение, че вече си е направил операция за смяна на пола – по документи трябва да бъде жена, защото полът е само биологичен. Точка по въпроса.

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

Вариант 2: „Първо си направете операция за смяна на пола!“

Лора е транс жена, която въпреки професионалната си квалификация все е без работа, защото външният ѝ вид не съответства на личните ѝ документи и никой не иска да я наеме. Съдът настоява тя първо да премине през хормонална терапия и оперативна промяна на пола, за да бъде и според външните си полови белези жена. Лора обаче има здравословни проблеми, поради които тези процедури са опасни за живота ѝ, затова не иска да рискува. За нея решението също е „къса клечка“ – тя си остава с мъжко име в личната карта.

За разлика от Диян, за Лора емиграцията не е вариант. Тя трябва да се грижи за болните си родители, а докато го прави, годините минават и Лора става все по-неконкурентоспособна.

Вариант 3: „Няма проблем!“

Мариета е транс жена, която се подлага на хормонална терапия, но не си е направила операция за смяна на пола. Сгодена е за Мишо. Тя има късмета да попадне на варианта, който се случва най-често. След като се запознава със съдебнопсихиатричната ѝ експертиза и получава уверения от нея и близките ѝ, че е взела „сериозно и непоколебимо решение“ за биологична смяна на пола, съдът смята, че той самият би извършил престъпление, ако накара Мариета да промени пола си хирургически. Наказателният кодекс предвижда затвор от 3 до 10 години за причиняване на телесна повреда, водеща до безплодие. Затова ѝ разрешава юридическата промяна и без да си е направила операция.

С женско име в личната карта Мариета най-сетне може съвсем законно да се омъжи за Мишо в България. Двамата спретват голяма сватба и както се казва в приказките, три дни всички ядат, пият и се веселят.

Ролята на КС и ВКС

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

КС нямаше отношение към темите, свързани с пола, до кампанията срещу Истанбулската конвенция (ИК). В резултат на тази кампания думата „джендър“ беше демонизирана и се надигна мощна трансфобска вълна, въпреки че транс хората изобщо не са централна тема в ИК.

Решението на КС от 2018 г.

През 2018 г. 75 депутати от всички парламентарни групи се обърнаха към КС с искане да направи анализ доколко Конвенцията съответства на Конституцията. В Решението си от 27 юли 2018 г. КС отсъди, че ИК противоречи на Конституцията, с което затвори пътя към ратификацията ѝ в България.

Какви бяха аргументите на КС за това решение? Според него понятието „джендър идентичност“ не съответства на бинарната представа за пол (според която половете са два) в Основния закон. Нищо че нито Конституцията, нито ИК дефинират какво е пол. Нещо повече – съдът свежда социалните роли на пола до биологичните с твърдението, че социалната роля на жената е да бъде майка, което впрочем се подкрепя от всички жени в КС. Използват се религиозни аргументи, въпреки че според Основния закон религията е отделена от държавата.

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

Така съдът стига до извода, че с понятието „социален пол“ се въвежда „трети пол“, което няма нищо общо с оригиналния смисъл. И изобщо не го е грижа, че Конвенцията се отнася предимно към насилието над жени и домашното насилие.

Решението от 2021 г.

Решението на КС от 2018 г. променя практиката на ВКС, който е най-висшата инстанция за обжалване на дела. До този момент ВКС е допускал промяната на юридическия пол на транс хората, като се е позовавал на Европейската конвенция за правата на човека (ЕКПЧ) и практиката на Европейския съд за правата на човека в Страсбург (ЕСПЧ). В чл. 8 на ЕКПЧ всеки има право на неприкосновеност на личния и семейния живот, а според ЕСПЧ това включва и сексуалната ориентация и половата идентичност.

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

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

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

Решението на ВКС от 2023 г.

В решението си от февруари 2023 г. ВКС постановява, че българското материално право не допуска промяната на юридическия пол на транс лицата, макар това да е ставало десетилетия наред. Съдът впрочем е силно разделен по тази тема – решението се взема от 28 съдии, докато 21 гласуват против, защото според тях така се нарушава балансът между обществените и личните интереси.

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

ВКС допълнително усилва религиозните и традиционалистки аргументи в решенията на КС. Накрая се стига до абсурда, че самата същност на човека произтича от понятието за брака в Конституцията. Защото КС говори за „бинарно понятие за брака“ в Основния закон (тоест че бракът е само между мъж и жена), а ВКС – за „бинарно съществуване на човешкия вид“.

Размерът на последствията

С решенията си КС и ВКС са в противоречие с международното право, което България е ратифицирала, и с европейските съдилища. Най-малкото ще последват глоби за страната ни, които ще се извадят от джоба на данъкоплатците. Но анализът в книгата стига до далеч по-тревожно заключение – че тези решения предизвикват цели пет кризи.

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

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

Тогава защо постъпват така?

На този въпрос книгата не дава пряк отговор, но изводът, който може да се направи от прочита ѝ, е: поддали са се на политически натиск, изпълнили са политическа поръчка.

Как да се излезе от цялата бъркотия?

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

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

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

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

И двете приличат на сизифовски труд, но докато не са забранени, има надежда.


Тази статия е публикувана с финансовата подкрепа на Фондация „Ресурсен център Билитис“.

The collective thoughts of the interwebz