Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

Post Syndicated from Reid Tatoris original https://blog.cloudflare.com/eliminating-captchas-on-iphones-and-macs-using-new-standard/

Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

Today we’re announcing Private Access Tokens, a completely invisible, private way to validate that real users are visiting your site. Visitors using operating systems that support these tokens, including the upcoming versions of macOS or iOS, can now prove they’re human without completing a CAPTCHA or giving up personal data. This will eliminate nearly 100% of CAPTCHAs served to these users.

What does this mean for you?

If you’re an Internet user:

  • We’re making your mobile web experience more pleasant and more private than other networks at the same time.
  • You won’t see a CAPTCHA on a supported iOS or Mac device (other devices coming soon!) accessing the Cloudflare network.

If you’re a web or application developer:

  • Know your user is coming from an authentic device and signed application, verified by the device vendor directly.
  • Validate users without maintaining a cumbersome SDK.

If you’re a Cloudflare customer:

  • You don’t have to do anything!  Cloudflare will automatically ask for and utilize Private Access Tokens
  • Your visitors won’t see a CAPTCHA and we’ll ask for less data from their devices.

Introducing Private Access Tokens

Over the past year, Cloudflare has collaborated with Apple, Google, and other industry leaders to extend the Privacy Pass protocol with support for a new cryptographic token. These tokens simplify application security for developers and security teams, and obsolete legacy, third-party SDK based approaches to determining if a human is using a device. They work for browsers, APIs called by browsers, and APIs called within apps. We call these new tokens Private Access Tokens (PATs). This morning, Apple announced that PATs will be incorporated into iOS 16, iPad 16, and macOS 13, and we expect additional vendors to announce support in the near future.

Cloudflare has already incorporated PATs into our Managed Challenge platform, so any customer using this feature will automatically take advantage of this new technology to improve the browsing experience for supported devices.

Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

CAPTCHAs don’t work in mobile environments, PATs remove the need for them

We’ve written numerous times about how CAPTCHAs are a terrible user experience. However, we haven’t discussed specifically how much worse the user experience is on a mobile device. CAPTCHA as a technology was built and optimized for a browser-based world. They are deployed via a widget or iframe that is generally one size fits all, leading to rendering issues, or the input window only being partially visible on a device. The smaller real estate on mobile screens inherently makes the technology less accessible and solving any CAPTCHA more difficult, and the need to render JavaScript and image files slows down image loads while consuming excess customer bandwidth.

Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

Usability aside, mobile environments present an additional challenge in that they are increasingly API-driven. CAPTCHAs simply cannot work in an API environment where JavaScript can’t be rendered, or a WebView can’t be called. So, mobile app developers often have no easy option for challenging a user when necessary. They sometimes resort to using a clunky SDK to embed a CAPTCHA directly into an app. This requires work to embed and customize the CAPTCHA, continued maintenance and monitoring, and results in higher abandonment rates. For these reasons, when our customers choose to show a CAPTCHA today, it’s only shown on mobile 20% of the time.

We recently posted about how we used our Managed Challenge platform to reduce our CAPTCHA use by 91%. But because the CAPTCHA experience is so much worse on mobile, we’ve been separately working on ways we can specifically reduce CAPTCHA use on mobile even further.

When sites can’t challenge a visitor, they collect more data

So, you either can’t use CAPTCHA to protect an API, or the UX is too terrible to use on your mobile website. What options are left for confirming whether a visitor is real? A common one is to look at client-specific data, commonly known as fingerprinting.

You could ask for device IMEI and security patch versions, look at screen sizes or fonts, check for the presence of APIs that indicate human behavior, like interactive touch screen events and compare those to expected outcomes for the stated client. However, all of this data collection is expensive and, ultimately, not respectful of the end user. As a company that deeply cares about privacy and helping make the Internet better, we want to use as little data as possible without compromising the security of the services we provide.

Another alternative is to use system-level APIs that offer device validation checks. This includes DeviceCheck on Apple platforms and SafetyNet on Android. Application services can use these client APIs with their own services to assert that the clients they’re communicating with are valid devices. However, adopting these APIs requires both application and server changes, and can be just as difficult to maintain as SDKs.

Private Access Tokens vastly improve privacy by validating without fingerprinting

This is the most powerful aspect of PATs. By partnering with third parties like device manufacturers, who already have the data that would help us validate a device, we are able to abstract portions of the validation process, and confirm data without actually collecting, touching, or storing that data ourselves. Rather than interrogating a device directly, we ask the device vendor to do it for us.

In a traditional website setup, using the most common CAPTCHA provider:

  • The website you visit knows the URL, your IP, and some additional user agent data.
  • The CAPTCHA provider knows what website you visit, your IP, your device information, collects interaction data on the page, AND ties this data back to other sites where Google has seen you. This builds a profile of your browsing activity across both sites and devices, plus how you personally interact with a page.
Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

When PATs are used, device data is isolated and explicitly NOT exchanged between the involved parties (the manufacturer and the Cloudflare)

  • The website knows only your URL and IP, which it has to know to make a connection.
  • The device manufacturer (attester) knows only the device data required to attest your device, but can’t tell what website you visited, and doesn’t know your IP.
  • Cloudflare knows the site you visited, but doesn’t know any of your device or interaction information.
Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

We don’t actually need or want the underlying data that’s being collected for this process, we just want to verify if a visitor is faking their device or user agent. Private Access Tokens allow us to capture that validation state directly, without needing any of the underlying data. They allow us to be more confident in the authenticity of important signals, without having to look at those signals directly ourselves.

How Private Access Tokens compartmentalize data

With Private Access Tokens, four parties agree to work in concert with a common framework to generate and exchange anonymous, unforgeable tokens. Without all four parties in the process, PATs won’t work.

  1. An Origin. A website, application, or API that receives requests from a client. When a website receives a request to their origin, the origin must know to look for and request a token from the client making the request. For Cloudflare customers, Cloudflare acts as the origin (on behalf of customers) and handles the requesting and processing of tokens.
  2. A Client. Whatever tool the visitor is using to attempt to access the Origin. This will usually be a web browser or mobile application. In our example, let’s say the client is a mobile Safari Browser.
  3. An Attester. The Attester is who the client asks to prove something (i.e that a mobile device has a valid IMEI) before a token can be issued. In our example below, the Attester is Apple, the device vendor. An Issuer. The issuer is the only one in the process that actually generates, or issues, a token. The Attester makes an API call to whatever Issuer the Origin has chosen to trust,  instructing the Issuer to produce a token. In our case, Cloudflare will also be the Issuer.
Private Access Tokens: eliminating CAPTCHAs on iPhones and Macs with open standards

In the example above, a visitor opens the Safari browser on their iPhone and tries to visit example.com.

  1. Since Example uses Cloudflare to host their Origin, Cloudflare will ask the browser for a token.
  2. Safari supports PATs, so it will make an API call to Apple’s Attester, asking them to attest.
  3. The Apple attester will check various device components, confirm they are valid, and then make an API call to the Cloudflare Issuer (since Cloudflare acting as an Origin chooses to use the Cloudflare Issuer).
  4. The Cloudflare Issuer generates a token, sends it to the browser, which in turn sends it to the origin.
  5. Cloudflare then receives the token, and uses it to determine that we don’t need to show this user a CAPTCHA.

This probably sounds a bit complicated, but the best part is that the website took no action in this process. Asking for a token, validation, token generation, passing, all takes place behind the scenes by third parties that are invisible to both the user and the website. By working together, Apple and Cloudflare have just made this request more secure, reduced the data passed back and forth, and prevented a user from having to see a CAPTCHA. And we’ve done it by both collecting and exchanging less user data than we would have in the past.

Most customers won’t have to do anything to utilize Private Access Tokens

To take advantage of PATs, all you have to do is choose Managed Challenge rather than Legacy CAPTCHA as a response option in a Firewall rule. More than 65% of Cloudflare customers are already doing this. Our Managed Challenge platform will automatically ask every request for a token, and when the client is compatible with Private Access Tokens, we’ll receive one. Any of your visitors using an iOS or macOS device will automatically start seeing fewer CAPTCHAs once they’ve upgraded their OS.

This is just step one for us. We are actively working to get other clients and device makers utilizing the PAT framework as well. Any time a new client begins utilizing the PAT framework, traffic coming to your site from that client will automatically start asking for tokens, and your visitors will automatically see fewer CAPTCHAs.

We will be incorporating PATs into other security products very soon. Stay tuned for some announcements in the near future.

AWS MGN Update – Configure DR, Convert CentOS Linux to Rocky Linux, and Convert SUSE Linux Subscription

Post Syndicated from Jeff Barr original https://aws.amazon.com/blogs/aws/aws-mgn-update-configure-dr-convert-centos-linux-to-rocky-linux-and-convert-suse-linux-subscription/

Just about a year ago, Channy showed you How to Use the New AWS Application Migration Server for Lift-and-Shift Migrations. In his post, he introduced AWS Application Migration Service (AWS MGN) and said:

With AWS MGN, you can minimize time-intensive, error-prone manual processes by automatically replicating entire servers and converting your source servers from physical, virtual, or cloud infrastructure to run natively on AWS. The service simplifies your migration by enabling you to use the same automated process for a wide range of applications.

Since launch, we have added agentless replication along with support for Windows 10 and multiple versions of Windows Server (2003, 2008, and 2022). We also expanded into additional regions throughout 2021.

New Post-Launch Actions
As the title of Channy’s post stated, AWS MGN initially supported direct, lift-and-shift migrations. In other words, the selected disk volumes on the source servers were directly copied, bit-for-bit to EBS volumes attached to freshly launched Amazon Elastic Compute Cloud (Amazon EC2) instances.

Today we are adding a set of optional post-launch actions that provide additional support for your migration and modernization efforts. The actions are initiated and managed by the AWS Systems Manager agent, which can be automatically installed as the first post-launch action. We are launching with an initial set of four actions, and plan to add more over time:

Install Agent – This action installs the AWS Systems Manager agent, and is a prerequisite to the other actions.

Disaster Recovery – Installs the AWS Elastic Disaster Recovery Service agent on each server and configures replication to a specified target region.

CentOS Conversion – If the source server is running CentOS, the instances can be migrated to Rocky Linux.

SUSE Subscription Conversion – If the source service is running SUSE Linux via a subscription provided by SUSE, the instance is changed to use an AWS-provided SUSE subscription.

Using Post-Launch Actions
My AWS account has a post-launch settings template that serves as a starting point, and provides the default settings each time I add a new source server. I can use the values from the template as-is, or I can customize them as needed. I open the Application Migration Service Console and click Settings to view and edit my template:

I click Post-launch settings template, and review the default values. Then I click Edit to make changes:

As I noted earlier, the Systems Manager agent executes the other post-launch actions, and is a prerequisite, so I enable it:

Next, I choose to run the post-launch actions on both my test and cutover instances, since I want to test against the final migrated configuration:

I can now configure any or all of the post-launch options, starting with disaster recovery. I check Configure disaster recovery on migrated servers and choose a target region:

Next, I check Convert CentOS to Rocky Linux distribution. This action converts a CentOS 8 distribution to a Rocky Linux 8 distribution:

Moving right along, I check Change SUSE Linux Subscription to AWS provided SUSE Linux subscription, and then click Save template:

To learn more about pricing for the SUSE subscriptions, visit the Amazon EC2 On-Demand Pricing page.

After I have set up my template, I can view and edit the settings for each of my source servers. I simply select the server and choose Edit post-launch settings from the Replication menu:

The post-launch actions will be run at the appropriate time on the test or the cutover instances, per my selections. Any errors that arise during the execution of an action are written to the SSM execution log. I can also examine the Migration dashboard for each source server and review the Post-launch actions:

Available Now
The post-launch actions are available now and you can start using them today in all regions where AWS Application Migration Service (AWS MGN) is supported.

Jeff;

Sunsetting Atom

Post Syndicated from GitHub Staff original https://github.blog/2022-06-08-sunsetting-atom/

When we formally introduced Atom in 2014, we set out to give developers a text editor that was deeply customizable but also easy to use—one that made it possible for more people to build software. While that goal of growing the software creator community remains, we’ve decided to retire Atom in order to further our commitment to bringing fast and reliable software development to the cloud via Microsoft Visual Studio Code and GitHub Codespaces.

Today, we’re announcing that we are sunsetting Atom and will archive all projects under the organization on December 15, 2022.

Why are we doing this now?

Atom has not had significant feature development for the past several years, though we’ve conducted maintenance and security updates during this period to ensure we’re being good stewards of the project and product. As new cloud-based tools have emerged and evolved over the years, Atom community involvement has declined significantly. As a result, we’ve decided to sunset Atom so we can focus on enhancing the developer experience in the cloud with GitHub Codespaces.

This is a tough goodbye. It’s worth reflecting that Atom has served as the foundation for the Electron framework, which paved the way for the creation of thousands of apps, including Microsoft Visual Studio Code, Slack, and our very own GitHub Desktop. However, reliability, security, and performance are core to GitHub, and in order to best serve the developer community, we are archiving Atom to prioritize technologies that enable the future of software development.

What happens next?

We recognize that Atom is still used by the community and want to acknowledge that migrating to an alternative solution takes time and energy. We are committed to helping users and contributors plan for their migration.

  • Today, we’re announcing the sunset date six months out.
  • Over the next six months, we’ll continue to inform Atom users of the sunset in the product and on atom.io.
  • On December 15, 2022, we will archive the atom/atom repository and all other repositories remaining in the Atom organization.

Thank you

GitHub and our community have benefited tremendously from those who have filed issues, created extensions, fixed bugs, and built new features on Atom. Atom played an integral part in many developers’ journeys, and we look forward to building and shaping the next chapter of software development together.

[Security Nation] Phillip Maddux on HoneyDB, the Open-Source Honeypot Data Project

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/06/08/security-nation-phillip-maddux-on-honeydb-the-open-source-honeypot-data-project/


[Security Nation] Phillip Maddux on HoneyDB, the Open-Source Honeypot Data Project

In this episode of Security Nation, Jen and Tod chat with Phillip Maddux about his project HoneyDB, a site that pulls data together from honeypots around the world in a handy, open-source format for security pros and researchers. He details how his motivations for creating HoneyDB derived from his time in application security and why he thinks open source is such a great format for this kind of project.

No Rapid Rundown this week, since RSAC 2022 has Tod tied up (and several time zones farther from Jen than usual). If you’re in San Francisco for the conference, stop by the Rapid7 booth and say hi!

Phillip Maddux

[Security Nation] Phillip Maddux on HoneyDB, the Open-Source Honeypot Data Project

Phillip Maddux is a staff engineer on the Detection and Response Engineering team at Compass. He has over 15 years of experience in information security, with the majority of that time focused on application security in the financial services sector. Throughout his career, Phillip has been a honeypot enthusiast and is the creator of HoneyDB.io.

Show notes

Interview links

Like the show? Want to keep Jen and Tod in the podcasting business? Feel free to rate and review with your favorite podcast purveyor, like Apple Podcasts.

Want More Inspiring Stories From the Security Community?

Subscribe to Security Nation Today

[$] ioctl() forever?

Post Syndicated from original https://lwn.net/Articles/897202/

In a combined storage and filesystem session at the
2022 Linux Storage,
Filesystem, Memory-management and BPF Summit
(LSFMM), Luis Chamberlain
and James Bottomley led a discussion about the use of ioctl()
as a mechanism for configuration. There are plenty of downsides to the use
of ioctl() commands, and alternatives exist, but in general kernel
developers have chosen to continue using this multiplexing system
call. While there is interest in changing things, at least in some
quarters, the discussion did not seem to indicate major changes on the horizon.

Security updates for Wednesday

Post Syndicated from original https://lwn.net/Articles/897297/

Security updates have been issued by Debian (avahi), Fedora (firefox), Oracle (grub2, python-twisted-web, shim, shim-signed, and thunderbird), Red Hat (kernel and python-twisted-web), SUSE (gcc48, go1.17, go1.18, and mariadb), and Ubuntu (e2fsprogs, linux, linux-aws, linux-aws-5.13, linux-azure, linux-azure-5.13, linux-gcp, linux-gcp-5.13, linux-hwe-5.13, linux-intel-5.13, linux-kvm, linux-oracle, linux-oracle-5.13, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4, linux-azure-fde, linux-gcp, linux-gke, linux-gke-5.4, linux-gkeop, linux-gkeop-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, linux, linux-aws, linux-aws-hwe, linux-azure, linux-azure-4.15, linux-gcp, linux-hwe, linux-kvm, linux-oracle, linux-raspi2, linux-snapdragon, linux, linux-aws, linux-azure, linux-gcp, linux-gke, linux-ibm, linux-intel-iotg, linux-kvm, linux-lowlatency, linux-oracle, linux-raspi, linux, linux-aws, linux-kvm, linux-lts-xenial, linux-oem-5.14, linux-oem-5.17, and ntfs-3g).

In Ukraine and beyond, what it takes to keep vulnerable groups online

Post Syndicated from Jocelyn Woolbright original https://blog.cloudflare.com/in-ukraine-and-beyond-what-it-takes-to-keep-vulnerable-groups-online/

In Ukraine and beyond, what it takes to keep vulnerable groups online

This post is also available in 日本語, Deutsch, Français, Español, Português.

In Ukraine and beyond, what it takes to keep vulnerable groups online

As we celebrate the eighth anniversary of Project Galileo, we want to provide a view into the type of cyber attacks experienced by organizations protected under the project. In a year full of new challenges for so many, we hope that analysis of attacks against these vulnerable groups provides researchers, civil society, and targeted organizations with insight into how to better protect those working in these spaces.

For this blog, we want to focus on attacks we have seen against organizations in Ukraine, including significant growth in DDoS attack activity after the start of the conflict. Within the related Radar dashboard, we do a deep dive into attack trends against Project Galileo participants in a range of areas including human rights, journalism, and community led non-profits.

To read the whole report, visit the Project Galileo 8th anniversary Radar Dashboard.

Understanding the Data

  • For this dashboard, we analyzed data from July 1, 2021 to May 5, 2022 from 1,900 organizations from around the world that are protected under the project.
  • For DDoS attacks, we classify this as traffic that we have determined is part of a Layer 7 (application layer) DDoS attack. Such attacks are often malicious floods of requests designed to overwhelm a site with the intention of knocking it offline. We block the requests associated with the attack, ensuring that legitimate requests reach the site, and that it stays online.
  • For traffic mitigated by the web application firewall, this is traffic that was determined to be malicious and was blocked by Cloudflare’s firewall. We provide free Business level services under Project Galileo, and our WAF is one of the valuable tools used to mitigate attempts to exploit vulnerabilities intended to gain unauthorized access to an organization’s online application.
  • For graphs that represent changes in traffic or domains under Project Galileo, we are using the average daily traffic (number of requests) of the first two weeks of July 2021 as the baseline.

Highlights of past year

  • We continue to see cyberattack activity increase, with nearly 18 billion attacks between July 2021 and May 2022. This is an average of nearly 57.9 million cyberattacks per day over the last nine months, an increase of nearly 10% over last year.
  • Mitigated DDoS traffic targeting organizations in Ukraine reached as much as 90% of total traffic during one significant attack in April.
  • After the war in Ukraine started, applications to the project increased by 177% in March 2022.
  • Journalism and media organizations in Europe and the Americas saw traffic grow ~150% over the last year.
  • We see a range of unsophisticated cyberattacks against organizations that work in human rights and journalism. Up to 40% of WAF mitigated requests were classified as HTTP Anomalies, the largest of any WAF rule type, a type of attack that can be damaging to unprotected organizations but is automatically blocked by Cloudflare.
  • From July 2021 to May 2022, organizations based in Europe consistently accounted for half to two-thirds of request traffic out of all the regions covered under the project.

Global Coverage of Project Galileo

In Ukraine and beyond, what it takes to keep vulnerable groups online

Protecting organizations in Ukraine

As the war started in Ukraine, we saw an increase in applications for participation in Project Galileo from organizations looking for our assistance. Many came in while under DDoS attack, but we also saw sites subject to large influxes of traffic from people on the ground in Ukraine attempting to access information due to the ongoing Russian invasion. While traffic from organizations in Ukraine was largely flat before the start of the war, since that time, traffic increases primarily have been driven by organizations that work in journalism and media.

In Ukraine and beyond, what it takes to keep vulnerable groups online

Ahead of the war, organizations that work in community building/social welfare, such as those who provide direct assistance to refugees, or provide donation platforms to support those in Ukraine were responsible for what little traffic that was mitigated by the web application firewall (WAF). However, after the war began, journalism organizations saw the most WAF-mitigated traffic, with frequent spikes, including one on March 13 representing 69% of traffic. During this period of increased WAF-mitigated requests that started in late February, the majority of the attacks were classified as SQLi. WAF mitigated traffic for human rights organizations increased in mid-March, growing to between 5-10% of traffic.

In Ukraine and beyond, what it takes to keep vulnerable groups online

Mitigated DDoS traffic for organizations in Ukraine was concentrated in the mid-March to May timeframe, with rapid growth in the percentage of traffic it represents. The first spikes were in the 20% range, but rapidly grew before receding, including an attack on April 19 that accounted for over 90% of traffic that day.

In Ukraine and beyond, what it takes to keep vulnerable groups online

Since the start of the war, growth in traffic from protected organizations has varied across the categories. Traffic among Health organizations increased by 20-30x over baseline between late March and later April. Setting aside attack spikes, traffic from Journalism organizations was generally up 3-4x over baseline. Growth in the other categories was generally below 3x.

In Ukraine and beyond, what it takes to keep vulnerable groups online

For traffic mitigated by the web application firewall (WAF), the most frequently applied rule was HTTP Anomaly, associated with 92% of requests. Requests for Web content (HTTP requests) have an expected structure, set of headers, and related values. Some attackers will send malformed requests, including anomalies like missing headers, unsupported request methods, using non-standard ports, or invalid character encoding. These requests are classified as “HTTP anomalies”. These anomalous requests are frequently associated with unsophisticated attacks, and are automatically blocked by Cloudflare’s WAF.

In Ukraine and beyond, what it takes to keep vulnerable groups online

With the ongoing war, we continue to onboard and provide protection to organizations in Ukraine and neighboring countries to ensure they have access to information. Any Ukrainian organizations that are facing attack can apply for free protection under Project Galileo by visiting www.cloudflare.com/galileo, and we will expedite their review and approval.

Attack methods based on region

Across the Americas, Asia Pacific, Europe, and Africa/Middle East regions, the largest fraction (28%) of mitigated requests were classified as “HTTP Anomaly”, with 20% of mitigated requests tagged as SQL injection attempts and nearly 13% as attempts to exploit specific CVEs. CVEs are publicly disclosed cybersecurity vulnerabilities. Cloudflare monitors new vulnerabilities and quickly determines which require additional rulesets to protect our users. Depending on the vulnerability, they can be sophisticated attacks but depend on the severity, identification and response by security professionals.

In our previous report, we identified similar attack trends with SQLi injection and HTTP anomalies, classified as User agent anomalies, making up a large part of mitigated requests.

In Ukraine and beyond, what it takes to keep vulnerable groups online

Attacks methods by on organization type

We protect a range of organizations under Project Galileo. For this dashboard, we categorized them in 6 groups: community building/social welfare, education, environmental/disaster relief, human rights and journalism. To help understand threats against these groups, we broke down the types of attacks we saw that were mitigated by the web application firewall. A majority of the mitigated traffic is from HTTP anomalies and SQLi (SQL injection).

SQLi is an attack technique designed to modify or retrieve data from SQL databases. By inserting specialized SQL statements into a form field, attackers attempt to execute commands that allow for the retrieval of data from the database, modification of data within the database, the destruction of sensitive data, or other manipulative behaviors.

In Ukraine and beyond, what it takes to keep vulnerable groups online

Learn more on the 8th Anniversary Radar DashboardSee the full report on attack trends we observed against a wide range of organizations protected under Project Galileo.

Дилемата пред Близкия изток. Разговор с Надим Шeхади

Post Syndicated from Мирослав Зафиров original https://toest.bg/nadim-shehadi-interview/

Надим Шехади (р. 1956) е изпълнителен директор на Академичния център на Ливано-американския университет в Ню Йорк и асоцииран сътрудник в Кралския институт за международни отношения („Чатъм Хаус“), където по-рано е ръководил програмата за Близкия изток. Бил е директор на Центъра за източносредиземноморски изследвания „Фарес“ към Факултета по право и дипломация в Университета „Тъфтс“ и дългогодишен директор на „Ливански изследвания“ в колежа „Св. Антоний“ към Оксфордския университет. Той е водещ учен по въпросите на Близкия изток и Северна Африка и е консултант на няколко правителства и международни организации, в т.ч. и на Европейския съюз. Негови статии са публикувани в големи международни новинарски издания, като „Ню Йорк Таймс“, „Гардиън“ и Си Ен Ен. 

По повод наскоро състоялите се парламентарни избори в Ливан, а и цялостната обстановка в Близкия изток в светлината на настоящите глобални кризи, с г-н Шехади разговаря Мирослав Зафиров. 


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

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

Ние вече не се намираме в това положение, днес ще откриете този дебат по-скоро в Лондон, отколкото в Бейрут. Регионът постепенно навлезе в спиралата на непредсказуемостта – процес, започнал още през 50-те години на XX век. Възходът на светските националистически военни режими, който постепенно изтласка традиционната аристокрация и елитите, останали от Османската империя, показа истинското си лице – това на репресивния режим. Този режим бе особено безпощаден спрямо движенията, принадлежащи към политическия ислям. Но не само ислямистите бяха целта, скоро жертви на преследвания станаха левите политически течения и либералите.

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

Какво е мнението Ви за наскоро проведените парламентарни избори в Ливан? След години на нарастващо напрежение, икономическа криза и политическа нестабилност смятате ли, че страната е готова да излекува своите рани? 

Изборите в Ливан наподобяват тези в Ирак от 2021 г., доколкото резултатите демонстрираха намаляване на влиянието на проиранските партии и милиции. И в двете държави имаше сходно по дух обществено настроение. В случая с Ливан „Хизбулла“ се ползваше с абсолютния контрол над шиитските гласове, а коалицията ѝ с другата шиитска партия – „Амал“, ѝ осигури 27 места в парламента, въпреки че партиите загубиха двете места, които не бяха предвидени за шиитите.

Системата в Ливан дава възможност на „Хизбулла“ и нейните съюзници да упражняват правото на вето върху всички назначения: председател на парламента, министър-председател, президент и т.н. Коалицията е в състояние да парализира всеки изборен процес, докато условията, налагани от „Хизбулла“, не бъдат изпълнени. Те направиха това през 2006 г., когато окупираха центъра на Бейрут и парализираха страната за 19 месеца. Кризата приключи едва със Споразумението от Доха от 2008 г., в което ветото на „Хизбулла“ беше на практика институционализирано. По-късно отново шиитската коалиция блокира политическия процес за нови 29 месеца – между 2013 и 2016 г., когато Ливан съществуваше без президент, изборите за парламент бяха забавени, а правителството беше лишено от възможност да функционира. И всичко това – за да може отново „Хизбулла“ да наложи избора си за държавен глава.

На 15 май 2022 г. бяха проведени парламентарни избори в Ливан, на които за първи път след десетилетия на доминация „Хизбулла“ загуби мнозинството си. Коалицията, водена от шиитското движение, разполага с 62 от 128 места в Народното събрание. Противниците на шиитската коалиция – в т.ч. и финансираната от Саудитска Арабия християнска партия „Ливански сили“ – спечелиха мнозинство. Сред големите изненади бе и победата на движението на друзкия лидер Уалид Джумблат над неговия исторически противник и лидер на другата основна друзка фамилия – Талал Арслан. Джумблат е известен с позицията си срещу влиянието на Сирия в Ливан. Заслужава внимание и ниската избирателна активност сред сунитското население, като много от поддръжниците на бившия премиер Саад Харири по този начин изразиха подкрепа за сина на загиналия през 2005 г. Рафик Харири и решението му да не участва в изборите.

Какъв е Вашият анализ на парламентарните резултати? Наистина ли говорим за постепенно отслабване на „Хизбулла“? 

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

Важно е да се отбележи, че общите листи между „Амал“ и „Хизбулла“ са резултат от споразумение, постигнато след тригодишни преговори. Лидерът на „Амал“ Набих Бери беше заявил, че „Хизбулла“ олицетворява Дракула, защото живее за сметка на кръвта, която пролива, и обвини партията, че е отговорна за убийството на повече шиити, отколкото самият Израел. Няколко от водещите фигури в „Амал“ бяха убити, а други напуснаха страната или бяха изолирани, докато най-сетне не беше сключено споразумението за обща листа. По този начин това, което по-късно стана известно като „шиитското дуо“, видя бял свят и не позволи появата на нови независими политически гласове сред шиитите. В шиитските части на Ливан общата листа получи почти пълна подкрепа. Подобно на вота в един авторитарен режим, 97,6 % от гласовете на шиитите бяха за коалицията между „Амал“ и „Хизбулла“.

През 2020 г. в статия за „Ню Йорк Таймс“ Лина Мунзер написа, че въпреки убеждението си, че могат да преживеят всичко, ливанците се оказаха излъгани. Вие съгласен ли сте с нея? И ако е така, кое е онова нещо, което ливанците не успяха да преживеят – последиците от Споразумението от Таиф? Възхода на „Хизбулла“ през годините? Сирийската война, а преди нея – израелската окупация в Южен Ливан? 

Признавам си, че не си спомням тази статия, но дори последните две години в Ливан бяха достатъчно трудни. Мнозина ливанци осъзнаха, че повече не са в състояние да „преживеят всичко“. Ливанците трябваше да избират между няколко дилеми – конфронтация или компромис, сигурност или свобода, война или мир, и т.н. Но в крайна сметка политическата ни система не можа да издържи на постоянния натиск на „Хизбулла“. Това е все едно да играете футбол под прицела на снайперист, по чиято воля във всеки момент всеки от играчите може да бъде елиминиран. Някои ливанци обвиняват системата, но аз лично смятам, че никоя система не е в състояние да понесе подобен партньор и да оцелее под подобен натиск.

Вие сте известен с позицията си спрямо Иран. Предвид санкциите смятате ли, че Иран някак успя да оцелее въпреки всички атаки срещу себе си? Също така успя ли Техеран да намери изход от кризата в Сирия?

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

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

През 2011 и 2012 г., благодарение на Вашата помощ, София успя да стане домакин на първата истинска среща на сирийската опозиция. Мнозина бяха скептични, но срещата произведе първата обща декларация, която, за съжаление, впоследствие беше неглижирана от някои страни. Днес, десет години по-късно, какъв е изходът от продължаващата криза в Сирия, или тя вече е хроничен проблем, подобно на палестинския въпрос – две кризи, които влияят на стабилността в региона? 

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

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

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

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

След 24 февруари т.г. системата на международните отношения, завещана ни след Втората световна война, сякаш престана да съществува. Русия де факто не се ползва от привилегията да е част от клуба на т.нар. големи сили, представени от постоянните членки на Съвета за сигурност на ООН. Струва ли си да се поддадем на изкушението да мислим за свят след модела, заложен от държавите победителки, или по-скоро следва да запазим реда, докато не намерим с какво по-добро да заменим вече съществуващата система? 

Много от държавите в Близкия изток сякаш гледат на войната в Украйна с оптимизъм. Западът игнорираше руските действия в Сирия и сега западните държави осъзнават, че това, което се случва в Украйна, е своеобразно повторение на сирийския сценарий. Ние непрекъснато повтаряхме, че Башар ал Асад следва правилата от Хама и Грозни и че Иран действа по един криминален начин в Сирия чрез своите милиции, извършващи масови убийства. Но Западът избра да сключи сделка с Русия, с Иран и с Ал Асад за сметка на сирийския народ и за сметка на задълбочаваща се криза в Близкия изток.

Мнозина в Близкия изток са някак скептични да последват действията на САЩ и ЕС спрямо Русия. Египет, Ирак и ключови държави от Залива са дори доста внимателни. Какво мислите за това? 

Много малко е доверието в региона спрямо способността на САЩ или ЕС да отстояват своите позиции в Украйна. Видяхме, че и Вашингтон, и Брюксел сякаш признаха своето поражение в тази война, преди дори тя да е започнала. На президента Зеленски беше предложено той и семейството му да напуснат Украйна, докато САЩ и ЕС обсъждаха санкции, които да бъдат наложени едва след войната, а дори и по този въпрос нямаше съгласие. Да обсъждаш последиците от дадено събитие на практика означава да го приемеш за вече случило се. И страните в Залива и Ирак са непосредствено изложени на иранската заплаха и нямат никакво доверие, че САЩ ще ги защити. Египет се намира във фарватера на Залива, а режимът на Абделфатах ал Сиси не е в състояние да оцелее дори седмица без финансовата помощ на ОАЕ и Саудитска Арабия. Така виждам аз събитията.

Заглавна снимка: © Chatham House / Flickr

Източник

За украинските бежанци… и за нас

Post Syndicated from original http://www.gatchev.info/blog/?p=2457

Напоследък чух тонове плювни срещу украинските бежанци:

– че са гадове, понеже имат хубави коли и домове
– че искат да наливат бензин и да ядат в ресторанти, без да плащат
– че ние им даваме по 40 лева на ден от джоба си, а те искат повече
– (въпреки че имат цели куфари с пачки долари и евро, и мезонети по Черноморието)
– че им плащаме от джоба си да живеят в петзвездни хотели, докато българските пенсионери мрат от глад
– че са неблагодарници, понеже не им харесва да ги тъпчем по 6 души в стари ЖП контейнери
– че са неблагодарници, понеже се възмущават, че някой тук им обстрелвал децата с въздушна пушка
– че са неблагодарници, понеже не им харесва български патриоти да ги пребиват на улицата
– че са претенциозни, понеже някои искат да имат достъп до аптека, а някои – даже до лекар
– че са нагли, понеже се учудват, ако към храната няма прибори
– че нямат място тук, след като за по цяла седмица все още не са научили български добре
– че ако ги подслоняваме, Русия ще ни атакува (заслужено – украинците са нацисти!)
– че а пък в Германия умните германци не им дават никакви помощи
– че а пък в Германия тъпите германци им дават по 200 евро помощ на ден, и проклетите мръсници си живеят безгрижно
– накрая и че хич не са бежанци, след като след известен престой тук започват да бягат от България, обратно в Украйна, при войната…

(Съкратил съм списъка няколко пъти, читателю – нищо лошо не си ми направил…)

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

Но има нещо, още по-важно от това.

На какви струни в човешката душа се опитват да свирят тези твърдения?
Какви качества и черти са нужни, за да им вярва човек?
И какви качества и черти са нужни, за да ги разпространява?
Що за човек трябва да е – отвътре, под маската, която носи?

И какви струни в душата докосва другото – че бежанците бягат от зло и имат нужда от помощ?
Какви качества трябва да има човек, за да мисли първо за това, а после дали имат пари?
Какви качества са нужни, за да им помага с каквото може – подслон, дарения, добра дума в Интернет?…
Какъв трябва да е такъв човек отвътре, под маската на ежедневието?

С кой от тези два типа хора искате да сте близки, приятели… свои?
А от кой е добре да се пазите и да стоите по-далече?
На кой от тези два типа хора бихте вярвали, а на кой – не?
Кой от тях ще ви се отплати дори за доброто със зло, а кой – дори за прегрешенията с добро?

Сред кой от тези типове хора искате да живеете и да бъдете?

В момента правите именно този избор.

Нямам какво да добавя.

One developer’s journey bringing Dependabot to GitHub Enterprise Server

Post Syndicated from Landon Grindheim original https://github.blog/2022-06-07-one-developers-journey-bringing-dependabot-to-github-enterprise-server/

If you’re like me, you’re still excited by last week’s news that Dependabot is generally available on GitHub Enterprise Server (GHES). Developers using GHES can now let Dependabot secure their dependencies and keep them up-to-date. You know who would have loved that? Me at my last job.

Before joining GitHub, I spent five years working on teams that relied on GHES to host our code. As a GHES user, I really, really wanted Dependabot. Here’s why.

🤕 Dependencies

One constant pain point for my previous teams was staying on top of dependencies. Creating a Rails project with rails new results in an app with 74 dependencies, Django apps start with 88 dependencies, and a project initialized with Create React App will have 1,432 dependencies!

Unfortunately, security vulnerabilities happen, and they can expose your customers to existential risk, so it’s important they are handled as soon as they’re published.

As I’m most familiar with the Ruby ecosystem, I’ll use Nokogiri, a gem for parsing XML and HTML, to illustrate the process of manually resolving a vulnerability. Nokogiri has been a dependency of every Rails app I’ve maintained. It’s also seen seven vulnerabilities since 2019. To fix these manually, we’ve had to:

  • Clone `my_rails_app`
  • Track down and parse the Nokogiri release notes
  • Patch Nokogiri in `my_rails_app` to a non-vulnerable version
  • Push the changes and open a pull request
  • Wait for CI to pass
  • Get the necessary reviews
  • Deploy, observe, and merge

This is just one of (at least) 74 dependencies in one Rails app. My team maintained 14 Rails apps in our microservices-based architecture, so we needed to repeat the process for each app. A single vulnerability would eat up days of engineering time. That’s just one dependency in one ecosystem. We also worked on apps written in Elixir, Python, JavaScript, and PHP.

If an engineer was patching vulnerabilities, they couldn’t pursue feature work, the thing our customers could actually see. This would, understandably, lead to conversations about which vulnerabilities were most likely to be exploited and which we could tolerate for now.

If we had Dependabot security updates, that process would have started with a pull request. What took an engineer days to complete on their own could have been done before lunch.

We could have invested in keeping all of our dependencies up-to-date. Incremental upgrades are typically easier to perform and pose less risk. They also give bad actors less time to find and exploit vulnerabilities. One of my previous teams was still running Rails 3.2, which was no longer maintained when Rails 6 was released six years later. As support phased out, we had to apply our own security patches to our codebase instead of getting them from the framework. This made upgrading even harder. We spent years trying to get to a supported version, but other product priorities always won out.

If my team had Dependabot version updates, Dependabot would have opened pull requests each time a new version of Rails was released. We’d still need to make changes to ensure our apps were compliant with the new versions, but the changes would be made incrementally, making the lift much lighter. But we didn’t have Dependabot. We had to upgrade manually, and that meant upgrading didn’t happen until it became a P0.

A new home

I joined GitHub in 2021 to work on Dependabot. Being intimately familiar with the challenges Dependabot could help address, I wanted to be part of the solution. Little did I know, the team was just starting the process of bringing Dependabot to GHES. Call it serendipity, a dream come true, or tea leaves arranged just so.

I quickly realized why Dependabot wasn’t already on GHES. GitHub acquired Dependabot in 2019, and it took some time to scale Dependabot to be able to secure GitHub’s millions of repositories. To achieve this, we ported the service’s backend to run on Moda, GitHub’s internal Kubernetes-based platform. The dependency update jobs that result in pull requests were updated to run on lightweight Firecracker VMs, allowing Dependabot to create millions of pull requests in just hours. It was an impressive effort by a small team.

That effort, however, didn’t lend itself to the architecture of GHES, where everything runs on a single server with limited resources. An auto-scaling backend and network of VMs wasn’t an option. Instead, we needed to port Dependabot’s backend to run on Nomad, the container orchestration option on GHES. The jobs running on Firecracker VMs needed to run on our customers’ hardware. Fortunately, organizations can self-host GitHub Actions runners in GHES, so we adapted them to run on GitHub Actions. We also had to adjust our development processes to support continuous delivery in the cloud and less frequent GHES releases.

The result is that developers relying on GHES now have the option to have their dependencies updated for them. Now, my former teammates can update their dependencies by:

  • Viewing the already opened pull request
  • Reviewing the pull request and the included release notes
  • Deploying, observing, and merging

We’re really proud of that. As for me, I get the immense satisfaction of knowing that I built something that will directly benefit my former teammates. It doesn’t get much better than that!

Guess what? GitHub is hiring. What would you like to make better?

If you’re inspired to work at GitHub, we’d love for you to join us. Check out our Careers page to see all of our current job openings.

  • Dedicated remote-first company with flexible hours
  • Building great products used by tens of millions of people and companies around the world
  • Committed to nurturing a diverse and inclusive workplace
  • And so much more!

AWS HITRUST Shared Responsibility Matrix version 1.2 now available

Post Syndicated from Sonali Vaidya original https://aws.amazon.com/blogs/security/aws-hitrust-shared-responsibility-matrix-version-1-2-now-available/

The latest version of the AWS HITRUST Shared Responsibility Matrix is now available to download. Version 1.2 is based on HITRUST MyCSF version 9.4[r2] and was released by HITRUST on April 20, 2022.

AWS worked with HITRUST to update the Shared Responsibility Matrix and to add new controls based on MyCSF v9.4[r2]. You don’t have to assess these additional controls because AWS already has completed HITRUST assessment using version 9.4 in 2021 . You can deploy your environments on AWS and inherit our HITRUST Common Security Framework (CSF) certification, provided that you use only in-scope services and apply the controls detailed on the HITRUST website.

What this means for our customers

The new AWS HITRUST Shared Responsibility Matrix has been tailored to reflect both the Cross Version ID (CVID) and Baseline Unique ID (BUID) in HITRUST so that you can select the correct control for inheritance even if you’re still using an older version of HITRUST MyCSF for your own assessment.

With the new version, you can also inherit some additional controls based on MyCSF v9.4[r2].

At AWS, we’re committed to helping you achieve and maintain the highest standards of security and compliance. We value your feedback and questions. You can contact the AWS HITRUST team at AWS Compliance Contact Us. If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security ‘how-to’ content, news, and feature announcements? Follow us on Twitter.

Author

Sonali Vaidya

Sonali leads multiple AWS global compliance programs, including HITRUST, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 9001, and CSA STAR. Sonali has over 20 years of experience in information security and privacy management and holds multiple certifications such as CISSP, C-GDPR|P, CCSK, CEH, CISA, PCIP, ISO 27001, and ISO 22301 Lead Auditor.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close