Cloudflare’s commitment to CISA Secure-By-Design pledge: delivering new kernels, faster

Post Syndicated from Brandon Harris original https://blog.cloudflare.com/cloudflare-delivers-on-commitment-to-cisa/

As cyber threats continue to exploit systemic vulnerabilities in widely used technologies, the United States Cybersecurity and Infrastructure Agency (CISA) produced best practices for the technology industry with their Secure-by-Design pledge. Cloudflare proudly signed this pledge on May 8, 2024, reinforcing our commitment to creating resilient systems where security is not just a feature, but a foundational principle.

We’re excited to share and provide transparency into how our security patching process meets one of CISA’s goals in the pledge: Demonstrating actions taken to increase installation of security patches for our customers.

Balancing security patching and customer experience 

Managing and deploying Linux kernel updates is one of Cloudflare’s most challenging security processes. In 2024, over 1000 CVEs were logged against the Linux kernel and patched. To keep our systems secure, it is vital to perform critical patch deployment across systems while maintaining the user experience. 

A common technical support phrase is “Have you tried turning it off and then on again?”.  One may be  surprised how often this tactic is used — it is also an essential part of how Cloudflare operates at scale when it comes to applying our most critical patches. Frequently restarting systems exercises the restart process, applies the latest firmware changes, and refreshes the filesystem. Simply put, the Linux kernel requires a restart to take effect.

However, considering that a single Cloudflare server may be processing hundreds of thousands of requests at any point in time, rebooting it would impact user experience. As a result, a calculated approach is required, and traffic must be carefully removed from the server before it can safely reboot. 

First, the server is marked for maintenance. This action alerts our load balancing system, unimog, to stop sending traffic to this server. Next, the server waits for this flow of traffic to terminate, and once public traffic is gone, the server begins to disable internal traffic. Internal traffic has multiple purposes, such as determining optimal routing, service discovery, and system health checks. Once the server is no longer actively serving any traffic, it can safely restart, using the new kernel.

Kernel lifecycle at Cloudflare

This diagram is a high level view of the lifecycle of the Linux kernel at Cloudflare. The list of kernel versions shown is a point in time example snapshot from kernel.org.


First, a new kernel is released by the upstream kernel developers. We follow the longterm stable branch of the kernel. Each new kernel release is pulled into our internal repository automatically, where the kernel is built and tested. Once all testing has successfully passed, several flavors of the kernel are built and readied for a preliminary deployment.

The first stage of deployment is an internal environment that receives no traffic. Once it is confirmed that there are no crashes or unintended behavior, it is promoted to a production environment with traffic generated by Cloudflare employees as eyeballs.

Cloudflare employees are connected via Zero Trust to this environment. This allows our telemetry to collect information regarding CPU utilization, memory usage, and filesystem behavior, which is then analyzed for deviations from the previous kernel. This is the first time that a new kernel is interacting with live traffic and real users in a Cloudflare environment. 

Once we are satisfied with kernel performance and behavior, we begin to deploy this kernel to customer traffic. This progression starts as a small percentage of traffic in multiple datacenters and ends in one large regional datacenter. This is an important qualification phase for a new kernel, as we need to collect data on real world traffic. Once we are satisfied with performance and behavior, we have a candidate release that can go everywhere.

When a new kernel is ready for release, an automated cycle named the Edge Reboot Release is initiated. The Edge Reboot Release begins and completes every 30 days. This guarantees that we are running an up-to-date kernel in our infrastructure every month.

What about patches for the kernel that are needed faster than the standard cycle? We can live patch changes to close those gaps faster, and we have even written about closing one of these CVE’s.

Automating kernel updates in our Control Plane 

The Cloudflare network is 50 ms from 95% of the world’s Internet-connected population. The Control Plane runs different workloads than our network, and is composed of 80 different clustered workloads responsible for persistence of information and decisions that feed the Cloudflare network. Until 2024, the Control Plane kernel maintenance was performed ad-hoc, and this caused the working kernel for Control Plane workloads to fall behind on patches. Under the pledge, this had to change and become just as consistent as the rest of our network.


Consider a relational database as an example workload, as illustrated in the diagram above. One would need a copy available to restart the original in order to provide a seamless end user experience. This copy is called a database replica. That replica should then be promoted to become the primary serving database. Now that a new primary is serving traffic, the old primary is free to restart. If a database replica reboot is needed, an additional replica would be needed to take its place, allowing another safe restart. In this example, we have 2 different ways to restart a member of the clustered workload. Every clustered workload has different safe methodologies to restart one of its members.

Reboau (short for reboot automation) is an internally-built tool to manage custom reboot logic in the Control Plane. Reboau offers additional efficiencies described as “rack aware”, meaning it can operate on a rack of servers vs. a single server at a time. This optimization is helpful for a clustered workload, where it may be more efficient to drain and reboot a rack versus a single server. It also leverages metrics to determine when it is safe to lose a clustered member, execute the reboot, and ensure the system is healthy through the process.

In 2024, Cloudflare migrated Control Plane workloads to leverage Reboau and follow the same kernel upgrade cadence as the network. Now all of our infrastructure benefits from faster patching of the Linux kernel, to improve security and reliability for our customers.

Conclusion 

Irrespective of the industry, if your organization builds software, we encourage you to familiarize yourself with CISA’s ‘Secure by Design’ principles and create a plan to implement them in your company. The CISA Secure by Design pledge is built around seven security goals, prioritizing the security of customers, and challenges organizations to think differently about security. 

By implementing automated security patching through kernel updates, Cloudflare has demonstrated measurable progress in implementing functionality that allows automatic deployment of software patches by default. This process highlights Cloudflare’s commitment to protecting our infrastructure and keeping our customers against emerging vulnerabilities.

For more updates on our CISA progress, you check out our blog. Cloudflare has delivered five of the seven CISA Secure by Design pledge goals, and we aim to complete the entirety of the pledge goals by May 2025.

Pentales: Red Team vs. N-Day (and How We Won)

Post Syndicated from Ed Montgomery original https://blog.rapid7.com/2025/04/04/pentales-red-team-vs-n-day-and-how-we-won/

Pentales: Red Team vs. N-Day (and How We Won)

During a recent Vector Command operation, I had the chance to sit down with one of our red teamers to hear firsthand how they identified and exploited an N-Day vulnerability in a customer’s environment. It’s a clear example of how continuous red teaming can uncover and validate real-world risks before attackers do.

While the organization involved remains anonymous, the events described are real. This story reflects how our always-on testing approach closely mirrors the creativity and persistence of actual threat actors.

Initial Recon: Spotting an N-Day in the Wild

Vector Command engagements begin with one core question: If someone wanted to break in, where would they start? That’s the mindset our red team brings to every operation.

A red team is a group of security professionals who simulate real-world adversaries. Their goal isn’t to check boxes or run automated scans, but to think and act like attackers—uncovering weaknesses that traditional assessments often miss. They combine technical skill with creativity, adapting to the environment they’re targeting and exploring how far a real compromise could go.

In this case, as part of Vector Command’s continuous reconnaissance, the red team identified a subdomain hosting a vulnerable web application. The vulnerability, already publicly disclosed, classified the exposure as an N-Day. While the issue was known in the broader security community, it hadn’t yet been patched in this environment.

Using a publicly available proof-of-concept exploit, the team compromised the application and underlying host. From there, they found credentials stored in the file system, granting access to services deeper within the internal network.

From Exploit to Expansion: Breaching the Perimeter and Moving Laterally

As part of our recon, we zeroed in on a subdomain running a web app that was just begging to be poked. It was tied to a recently disclosed N-Day vulnerability—publicly known, actively discussed, and in this case, still unpatched.

We ran a proof-of-concept exploit and landed a shell. From there, we had access to the underlying host, and it didn’t take long to find something useful: credentials stashed away on the file system. Those creds gave us our next step into the internal network.

With the perimeter breached, we started exploring. There was little in the way of segmentation, which made internal discovery a breeze. We quickly found an internal SMTP server and realized we could send emails that appeared completely legit—from the inside, to the inside.

We used that to spin up a phishing campaign. The bait? A cloned version of the company’s actual login portal, hosted on the compromised subdomain. From the user’s perspective, everything looked familiar. The URL checked out. The branding was perfect. And people clicked.

We captured multiple sets of credentials, including an admin account. From there, we confirmed a misconfiguration on a critical internal system. That allowed us to escalate privileges and prepare for full domain takeover.

Classic attack chain: exploit, phish, pivot, escalate. All real. All tested safely under Vector Command.

From Attack Chain to Action Plan

You may be forgiven for thinking an organization would not be happy with this. However, it is exactly the opposite and our Vector Command customer was delighted we found and exploited this vulnerability. We proved the value of our continuous red teaming, mimicking what a real external threat actor would do to breach a network.

The sub-domain we compromised was prioritized for remediation and now has security controls in place. We then re-tested the customer’s environment to ensure their patches actually worked and this particular security gap was closed.

From PoC’s to Happy SOC’s

In our previous blogs, we’ve explored the human side of continuous red teaming—through opportunistic phishing stories, external network assessments, and a deep dive into the TTPs behind post-compromise simulations.

Security Operations Centers (SOCs) are often relieved—not rattled—when we uncover these risks. It gives them proof, insight, and time to act.

As part of Vector Command, this engagement was fully documented—summarized for executive stakeholders and detailed for security practitioners. Reports live in the Vector Command portal, accessible whenever teams need to revisit findings or track remediation progress.

Customers also have the opportunity to debrief directly with the red teamer behind the operation. Whether it’s to dig deeper into the attack chain or walk through lessons learned, we’re here to help strengthen defenses—because at the end of the day, we’re all working toward the same goal.

If you or your security team want to explore how continuous red teaming can support your program, let’s talk.

Ready for Your Own Red Team Reality Check?

If you’re curious what an attacker might find in your environment, Vector Command can help you find out before someone else does.

Learn More about Rapid7’s Vector Command Service ▶︎

Ready to see how continuous red team managed services can ensure your potential attack pathways are remediated before they can ever be exploited?

Имаш Пеевски – пиеш мляко

Post Syndicated from Емилия Милчева original https://www.toest.bg/imash-peevski-piesh-mlyako/

Имаш Пеевски – пиеш мляко

Градската легенда гласи, че на мафиотския бос Ал Капоне светът дължи сроковете за годност върху кутиите с прясно мляко – направил го от алтруизъм, за да защити хората от развалени продукти. Истината е друга. Идвал краят на Сухия режим (1920–1933) и той видял възможността за нов бизнес предвид контрола върху пивоварни и дистрибуторски маршрути в съчетание с безотговорна регулация на млечната промишленост. „Трябва да имаме продукт, от който всеки да се нуждае всеки ден… Знаете ли, че има по-голяма надценка на прясното мляко, отколкото на алкохола?!“, цитира думите му неговата племенница Диъдри Мари Капоне, последната, която носи тази фамилия, в книгата си „Чичо Ал Капоне. Неразказаната семейна история“.

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

Самата българска политика заприлича на нещо като „Имаш Пеевски – пиеш мляко“, не само за ДПС и производните му. Поне до юни, когато ще излязат конвергентните доклади за по-скоро да, отколкото не на България в еврозоната, всички в парламента ще пият „мляко“. Управляващите – защото ще разчитат на сигурна подкрепа, а разнокалибрената опозиция – ПП–ДБ, МЕЧ, „Величие“ и „Възраждане“ – също, но поради друга причина: възможността да повтарят рефрена за сиамските близнаци Борисов–Пеевски. Никой от тях не бърза за избори, което не пречи да се организират вотове на недоверие.

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

ПП–ДБ не участваха в гласуването и обещаха, че ще поискат вот на недоверие след решението за еврозоната.

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

Надежда Йорданова, съпредседателка на парламентарната група на ПП–ДБ

Нито е моментът, нито е поводът да се иска оставката на правителството сега.

Николай Денков, съпредседател на парламентарната група на ПП–ДБ

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

Рейдването

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

Предстои Пеевски да погълне изцяло ДПС и затова групата около Доган отчаяно се мъчи да събере в едно парчетата. Разпокъсана на отделни зони на влияние между Джевдет Чакъров, Илхан Кючюк, Юджел Атилла (извън парламента) и други, с напускащи и преминаващи в другия лагер знакови лица, като лидера на младежкото ДПС Ибраим Зайденов, ДПС–ДПС отчаяно се стреми да се задържи на борда. Формално е партньор на управляващото мнозинство – мандатоносителя ГЕРБ–СДС плюс БСП – Обединена левица и „Има такъв народ“, но освен запазване на имунитета на депутата Джейхан Ибрямов не е спечелило позиции като заместник-министри, представители в регулатори и областни управи. Единият му кандидат за регулатор – Ремзи Осман за КЕВР, се оттегли от участие, а Ердоан Ахмедов, номиниран за Фискалния съвет, не сполучи с гласуването. 

На 27 март от партията на Ахмед Доган, представена с 19 депутати в 51-вото НС (срещу 30 на Пеевски), обвиниха управляващите, че вместо да демонтират, отново връщат модела „Пеевски“, и заплашиха да преосмислят участието си във властта:

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

Но – също без изненада – ДПС–ДПС ще продължи да подкрепя правителството до юни, когато се очаква конвергентният доклад за eврозоната. Това бе решено на 1 април. Дори и заплахата за оттегляне да се беше осъществила, натрапената от Пеевски и неговото „Ново начало“ подкрепа се запазва, а значи и мнозинството. 

Ще ги оставя да ми се катерят по гърба, докато влезем в еврозоната, след това ще видите каква ще ми е реакцията,

заяви лидерът на ГЕРБ Бойко Борисов. Той поясни, че в името на тази цел приема всякаква подкрепа: 

… и от ПП–ДБ, и от „Ново начало“, и от АПС (ДПС–ДПС, б.а.), и от всеки, който иска бяла, правова, финансово дисциплинирана държава. 

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

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

На пръв поглед парадоксално, но овладяването на ДПС от феномена Пеевски, сътворен от „Доган & съзаклятници“, показа, че етническият мир (лавров венец на Доган) не е застрашен, нито етническите турци са притеснени, че лидерът е българин. Като много български граждани, и те са стигнали до прагматичния извод „Важното е да върши работа!“. А той върши – не само онова, което Доган вършеше толкова години с раздаването на порциите, но и повече. Пеевски отива по-далеч с бруталния контрол върху съдебна система и институции.

Pigs get fat, hogs get slaughtered 

Разумният апетит е важна гаранция за дълголетие в политиката. Но ако някой (политически) играч прекали и стане твърде алчен и ненаситен, привлича нежелано внимание и бива унищожен. Неразкритите убийства в България на хора от високите етажи на властта и бизнеса, като Андрей Луканов, Илия Павлов, Емил Кюлев, Алексей Петров, са потвърждение. Авторитарните политици обаче винаги се размножават бързо и агресивно – както Борисов създаде плеяда себеподобни, така и Пеевски отглежда наследници. Те всички тлъстеят от власт и не подозират края си.

Имаме ли експертиза за тарифите?

Post Syndicated from original https://www.toest.bg/imame-li-ekspertiza-za-tarifite/

Имаме ли експертиза за тарифите?

Човек трябва да знае в коя област е истински професионалист, затова нека признаем очевидното: най-висока експертиза за тарифите притежава сегашният основен обитател на Белия дом. Ние просто можем да сведем глави и да се опитаме да обясним защо нито тарифите са тарифи, нито експертизата е експертиза в този случай, доколкото ни позволяват познанията.

Мито и тарифа

В българския език от време оно се употребява думата мито (стб. мыто), за която се смята, че е заемка от старовисоконемски. Да си припомним, че евангелист Матей е бил митар, тоест събирал е данъци от населението¹. В съвременния български език думата мито отдавна има утвърдено значение – ‘държавен налог, с който се облагат внасяни или изнасяни стоки’, и следва да употребяваме именно нея, а не тарифа, когато говорим за курса, поет от Доналд Тръмп по отношение на вносните автомобили например.

Тук сигурно влизам в капан и финансистите ще ме критикуват, защото, ако сме по-прецизни, би трябвало да кажем, че американският президент увеличава ставката на митата. По същия начин обаче не проявяваме достатъчно прецизност и когато говорим, че правителството или общинската управа вдига данъците, а всъщност повишава данъчната ставка. Да речем, тази година в община Търговище ставката за данък сгради се вдига от 1,65 на 2,5 промила от данъчната оценка на имота. Естествено, това повишение води до увеличаване на самия данък в левово изражение.

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

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

Експертност и експертиза

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

Не е добра идея същата тази дума да се натоварва с ново значение, автоматично пренесено от английския. Спокойно бихме могли да използваме експертност – съществително име, което назовава качество и е образувано от прилагателното експертен и наставката -ост. Моделът е продуктивен и можем да посочим много такива съществителни (около 2300²) в българския език: отговорност, активност, вежливост, грижовност…

Факт е, че думата експертност липсва в академичния тълковен речник и БЕРОН, но това не е причина да не се употребява. Тук е моментът да кажем и дори да подчертаем, че ако не намираме дадена дума в речниците, това не означава забрана да я изричаме.

Може също да използваме синонимен израз, например Елена Иванова е експерт (вместо има експертиза) в областта на маркетинга. Ако пък става въпрос не за отделен човек, подходящ вариант би бил Екипът ни има богат експертен/професионален опит в областта на гражданското право.

Силициев и силиконов

Струва ми се, че ерата на Силиконовата долина вече е зад гърба ни, защото повечето хора разбраха, че това е неправилен превод на Silicon Valley. Районът, където са съсредоточени високотехнологичните компании в САЩ, се нарича Силициевата долина, защото силицият (silicon), а не силиконът (siliconе) се използва за изработването на микрочипове, които на свой ред се използват в електрониката, а без нея съвременната високотехнологична индустрия би била немислима.

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

Бенефициент и бенефициер

Ще представя още два паронима на вашето внимание, но тук, за съжаление, сме далеч от справянето с проблема. А проблемът е, че думата бенефициент, с която би трябвало да се назовава даващият, предоставящият средства, се употребява за диаметрално противоположната страна – получаващия средства. Ще попитате защо така е редно. Причината е, че в латинския език, откъдето сме заели и двете думи, beneficient- е сегашното деятелно причастие на глагола beneficere ‘облагодетелствам’ и съответно означава ‘облагодетелстващ, т.е. предоставящ, даващ’. Професор Огнян Герджиков посочва примери за двойки юридически термини – също заемки от латински, които имат наставки -ент/-ант и -ер/-ар и означават точно двете страни на дадено действие, да речем депонент (лицето, което влага) и депозитар (лицето, което получава, приема за съхранение).

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

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

Ще се отклоня малко от темата, за да посоча случая с Наказателно-процесуалния кодекс и Административнопроцесуалния кодекс³, които трябва да се пишат по един и същ начин, но названието на първия е в противоречие със сегашните правописни правила. Тук нямаме избор и когато посочваме даден нормативен акт в писмен текст, се съобразяваме с названието му в този вид, в който е обнародван.

Да адресираме проблема

Аз лично продължавам борбата си с адресирането, когато редактирам текстове, но признавам, че понякога ми е трудно да намеря точното съответствие. Става въпрос, разбира се, не за надписването на адрес на пощенска пратка, а за онова по-общо значение на английския глагол to address, когато при превод на български се питаме: Сега всъщност само обръщаме внимание на даден проблем, правим опити да го овладеем или го разрешаваме? Или пък нещо четвърто или пето?

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

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

1 Значението на думите мыто (‘подкуп, подарък’) и мытарь (‘събирач на данъци и мита’) в старобългарския език се различава от значението на днешните мито и митничар, но трябва да имаме предвид, че разполагаме с ограничен брой употреби в старобългарските писмени паметници.

2 Обратен речник на съвременния български език. София: Издателство на БАН, 1975, с. 541–562.

3 За да е цветна палитрата в названията, освен тези два кодекса имаме Граждански процесуален кодекс и Данъчно-осигурителен процесуален кодекс, но все пак техният правопис е подчинен на официалните правила.

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

Гражданско участие и взаимопомощ сред политическа апатия

Post Syndicated from Хестър Гартрел original https://www.toest.bg/grazhdansko-uchastie-i-vzaimopomosht-sred-politicheska-apatia/

Гражданско участие и взаимопомощ сред политическа апатия

Политическата апатия и съмненията в демокрацията не са само български проблем, а и европейски, американски и световен. В България изследванията показват, че е по-вероятно младежите да предпочетат силен лидер, който не се занимава с парламент или избори. Въпреки склонността на българите да очакват най-лошото от България, неотдавнашно проучване сочи същата тенденция в Обединеното кралство – 52% от младите хора от 13- до 27-годишна възраст вярват, че би било по-добре, ако в страната на практика се установи тоталитарна система. В същото време наблюдаваме спад в избирателната активност, който несъмнено е по-силно изразен в България поради турбулентната политическа обстановка. Той е показателен за факта, че недоволството от статуквото не е характерно само за младежите, а е широко разпространено в цялото общество.

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

Приоритет върху локалния контекст на фона на слабата политическа ангажираност и общественото разделение?

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

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

Значението на „третите пространства“

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

Не можем обаче просто да следваме принципа „ако го построите, хората ще дойдат“. През 2010 г. Ipsos MORI провежда широкообхватно проучване на тема „Иска ли обществeността наистина да се присъедини към усилията на правителството на Великобритания?“. И установяват, че три четвърти от хората имат желание да се ангажират повече в своите общности, ако има как това да стане част от всекидневния им живот. Въпреки че винаги ще има кой да се заеме с осъществяването на промяна на местно ниво, постигането на широко и устойчиво участие изисква то да бъде преди всичко удобно, колкото и тривиално и комерсиално да звучи това.

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

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

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

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

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

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

Взаимопомощ и взаимоотношения

В кризисни ситуации често виждаме, че общностните инициативи се множат и набират скорост. По време на пандемията от COVID-19 в Обединеното кралство процъфтяха организации за взаимопомощ – местни мрежи от доброволци, предоставящи в неформални организационни структури подкрепа както един на друг, така и на съседи в уязвимо положение. Съседски общности създадоха програми за проверка дали хората, които не могат да излязат по здравословни причини, получават доставки на храна и лекарства. Подобна мобилизация виждаме и при природни бедствия, като например наводнението в Царево. Тя изразява желание за помощ, но и констатацията, че държавните структури и институции може да не са способни да реагират достатъчно бързо или по начина, по който хората наистина имат нужда.

Както пише Дейвид Грейбър в статията си „Никога не е имало Запад“: 

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

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

Въпреки че взаимопомощта работи добре в краткосрочен план, тя трудно се поддържа за дълъг срок от време. Проучване по темата, проведено след кризата с COVID-19, показва, че когато хората започнаха да се връщат към своя „нормален живот“, ангажираността и положителните нагласи намаляха. Реакция при кризи се разгръщаше там, където вече имаше поддържащи политически структури и капацитет чрез местни неправителствени организации. В условия на вкоренена бедност и неравенство хората скоро се изтощават, ако липсват достатъчно ресурси и структури на терен.

Ако искаме да активираме местните мрежи, за да създадем ангажирана и активна общност, не можем да очакваме общностите сами да свършат това.

Гласува ли една активна и просперираща общност?

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

Активизмът на терен е труден, изисква много надежда, борба с „прегарянето“ и „чукане на затворени врати“,

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

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

Гражданско участие и взаимопомощ сред политическа апатия
Гражданско участие и взаимопомощ сред политическа апатия

„Голямата маса“. Снимки: Хестър Гартрел

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

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

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

Гражданско участие и взаимопомощ сред политическа апатия

Facilitating Docs-as-Code implementation for users unfamiliar with Markdown

Post Syndicated from Grab Tech original https://engineering.grab.com/facilitating-docs-as-code-with-markdown

Introduction

Although Grab is a tech company, not everyone is an engineer. Many team members don’t use GitLab daily, and Markdown’s quirks can be challenging for them. This made adopting the Docs-as-Code culture a hurdle, particularly for non-engineering teams responsible for key engineering-facing documents. In this article, we’ll discuss how we’ve streamlined the Docs-as-Code process for technical contributors, specifically non-engineers, who are not very familiar with GitLab and might face challenges with Markdown. For more on the benefits of the Docs-as-Code approach, check out this blog on the subject.

As part of our ongoing efforts to enhance the TechDocs experience, we’ve introduced a rich text editor for those who prefer a WYSIWYG (What You See Is What You Get) interface on top of a Git workflow, helping to simplify authoring. We’ll also cover how we plan to improve the workflow for non-engineering teams contributing to service and standalone documentation.

The need for a rich text editor

Ask any developer today, and they’ll likely tell you that Markdown is the go-to format for documentation. Due to its simplicity, whether it’s GitHub, GitLab, Bitbucket, or other platforms, Markdown has become the default choice, even for issue tracking. It’s also integrated into most text editors, like IntelliJ, VS Code, Vim, and Emacs, with handy plugins for syntax highlighting and previewing.

Engineers are gradually embracing the Docs-as-Code approach and enjoying the benefits of writing the documentation in Markdown format directly in their IDEs and pushing them out as merge requests (MR). However, non-engineers face the nuance of writing in Markdown and going through the Git workflow. This is when the call for a WYSIWYG (What You See Is What You Get) editor aka TechDocs editor came about. This solution brought about several benefits to non-engineers. It provides a familiar, UI-based experience for editing, but it still aligns with the Docs-as-Code model. This tool allows users to edit documentation via a simple UI in the Backstage portal without having to deal with the complexities of MkDocs, entity catalogs, or Markdown syntax. In the context Backstage, “entities” refer to services, platforms, tools, or libraries, and documentation is often tied to these entities to provide context sensitivity. The goal was to make it easy for people to focus on content, not the tools, and enable quick updates without the technical overhead.

We’ve kept GitLab as the central storage system, but now, with the TechDocs editor, non-engineers can contribute with ease. Figure 1 highlights our editor’s features:

  • Reordering
  • Renaming
  • Deleting pages
  • Switching between normal and Markdown views
  • Formatting text with titles, bullets, numbering
Figure 1: TechDocs editor in Helix TechDocs portal

Our goal for our editor is to make it more flexible, performant, and user-friendly. Based on user feedback, key priorities include customisation, extensibility for non-standard Markdown elements, and long-term maintainability.

To achieve this, we selected the Lexical framework. Compared to other Markdown-based tools like Toast UI, Lexical offers greater extensibility, allowing us to implement advanced features such as autocomplete and support for non-standard Markdown elements like Kroki diagrams.

The following flowchart illustrates how Markdown content is imported and exported within the Lexical editor, ensuring seamless integration with TechDocs.

Figure 2: Lexical Markdown transformer flow chart

By continuously iterating based on user needs, we aim to make Docs-as-Code accessible not just for engineers but for anyone contributing to documentation at Grab.

User journeys

We explored various workflows to streamline the documentation lifecycle, focusing on both creation and editing processes. By integrating these workflows into the developer portal, we ensured that users can easily create and edit documentation, enhancing overall efficiency and collaboration.

Here are the three key user journeys we focused on addressing:

Journey 1: Edit existing TechDocs

High level workflow definition:

  1. Toggle to ‘edit’ mode: The user switches to the edit mode to start making changes to the TechDocs.
  2. User starts editing TechDocs: The user begins the process of editing the documentation and clicks save.
  3. User gets redirected to GitLab: If not authenticated, they are redirected to GitLab for authentication. Once authenticated, a merge request is created to update the entity YAML file and add the new TechDocs.
  4. Access check: The system checks if the user has access to the TechDocs file repository. If not, they are prompted to request access.
Figure 3: User journey 1

Journey 2: Create stand-alone TechDocs from “Documentation” page

High level workflow definition:

  1. User authentication:
    • If the user is not authenticated, they are redirected to GitLab for authentication.
    • If the user is already authenticated, the process skips to the next step.
  2. Registering merge requests:
    • The MR is registered to a scheduler job to automatically register a new entity catalog when it detects that the MR has been merged.

This workflow ensures that users are authenticated via GitLab before proceeding and that new entity catalogs are automatically registered upon the merging of MRs.

Figure 4: User journey 2

Journey 3: Create TechDocs from “Docs” tab on entity page

High level workflow definition:

  1. Start creating TechDocs:
    • User selects ‘create TechDocs’ on the ‘Docs’ tab in the Helix TechDocs portal UI.
  2. Save and redirect:
    • User clicks ‘save’ and is redirected to GitLab with a merge request (MR) created to update the entity YAML file and add new TechDocs.
  3. Access check and MR registration:
    • If the user has access to the entity YAML file repository, proceed with the MR. If not, prompt the user to get access.
    • Register the MR to a scheduler job to automatically refresh the entity catalog when it detects the MR as merged.
Figure 5: User journey 3

Phased rollout

We phased the rollout of our Markdown editor to ensure a smooth transition, allowing users to gradually adapt while we gathered feedback and iterated on features. This approach helped us address challenges early, refine usability, and deliver meaningful improvements with each phase.

Phase 1: Initial Markdown editor for developer portal

In Phase 1, we built a basic editor aligned with our documentation standards. Users can create and edit TechDocs for different entity catalogs, with support for basic Markdown and image previews for both absolute and relative paths. The editor tracks concurrent editing sessions and shows pending merge requests. It also includes Markdown configuration options to add, rename, reorganise, or delete pages. Additionally, our GitLab integration consolidates changes into a single commit and opens a merge request.

Phase 2: Independent documentation creation

Phase 2 includes expanded functionality to support independent documentation creation and related features, such as:

  • HTML preview and image uploads (relative paths).
  • Save drafts locally in the browser.
  • Pending MRs listed in the editor.
  • Draw.io and Excalidraw integration for diagrams.
  • MkDocs updates: change site name.
  • Auto-registeration of new entity catalogs when MRs are merged.

Phase 3: Advanced editor capabilities

Phase 3 introduced additional features, such as:

  • Support for Kroki / Mermaid diagrams.
  • Display concurrent edit sessions for better collaboration.

Each phase improved the editor, enhancing TechDocs at Grab with seamless GitLab integration and user-friendly features.

Integrating the ability to do a live preview

While syntax highlighting in the TechDocs editor is helpful, it can’t fully predict how the final Markdown document will appear once rendered due to Markdown flavour inconsistencies. This is especially true for elements like images, tables, and diagrams, where visual verification is crucial. To minimise these risks, the TechDocs editor includes a live preview feature, allowing users to see the fully rendered document alongside the editor in a split-screen view. This lets users verify their work as they go, preventing the need to switch back and forth between the editor and the final document, saving time and reducing potential formatting errors.

However, like most live preview features, performance challenges can arise. For larger documents, the process of continuously converting Markdown to HTML can slow down editing. External resources such as images that need to be re-rendered, can cause visual glitches or delays in the preview. Running scripts or using plugins with extended grammar also adds to the performance load, requiring frequent re-execution and potentially slowing down the experience.

To mitigate these issues, the TechDocs editor uses an inbuilt preview feature that shows users exactly how their changes are going to appear on the portal once their changes are merged. This ensures that users can confidently make adjustments and understand the final presentation before committing their updates. Additionally, the live preview feature enables more efficient collaboration by providing real-time feedback on content and formatting, further enhancing the overall documentation workflow.

GitLab integration strategy

The TechDocs editor integrates seamlessly with GitLab, allowing users to make changes effortlessly through OAuth2 authentication. When users log into the editor, they simply click the “Connect with GitLab” button, which provides access via the OAuth 2.0 protocol. Once connected, all modifications made within the editor are executed using the user’s GitLab credentials, streamlining the documentation process and ensuring a smooth experience for users as they update their documentation directly within the TechDocs framework.

To minimise Git conflicts, we considered and implemented some of these approaches:

  • Display pending merge requests at the top of the editor to alert users of existing changes.
  • Show who else is editing the same TechDocs to help users coordinate and avoid conflicts.
  • Include tools to automatically or semi-automatically resolve Git conflicts.

Conclusion

Bringing Docs-as-Code to a broader audience at Grab meant addressing the challenges faced by non-engineering contributors. With the introduction of a WYSIWYG editor, seamless GitLab integration, and a live preview feature, we’ve made it easier for everyone to contribute without needing deep Markdown expertise.

As we continue to improve the TechDocs editor, our focus remains on removing barriers to documentation, enhancing collaboration, and ensuring that our docs evolve alongside our fast-moving engineering teams.

Docs-as-Code isn’t just about engineers writing documentation—it’s about making documentation a natural and frictionless part of the development process for everyone.

Join us

Grab is a leading superapp in Southeast Asia, operating across the deliveries, mobility and digital financial services sectors. Serving over 800 cities in eight Southeast Asian countries, Grab enables millions of people everyday to order food or groceries, send packages, hail a ride or taxi, pay for online purchases or access services such as lending and insurance, all through a single app. Grab was founded in 2012 with the mission to drive Southeast Asia forward by creating economic empowerment for everyone. Grab strives to serve a triple bottom line – we aim to simultaneously deliver financial performance for our shareholders and have a positive social impact, which includes economic empowerment for millions of people in the region, while mitigating our environmental footprint.

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

Running the Deepseek-R1 671B Model at FP16 Fidelity Alongside Virtualized Workloads

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/running-the-deepseek-r1-671b-model-at-fp16-fidelity-alongside-amd-virtualized-workloads/

We show you how you can run the 1.27TB Deepseek-R1 671B model at FP16, and even look at running it alongside VMs in your clusters

The post Running the Deepseek-R1 671B Model at FP16 Fidelity Alongside Virtualized Workloads appeared first on ServeTheHome.

Announcing the Well-Architected Data Residency with Hybrid Cloud Services Lens

Post Syndicated from Enrico Liguori original https://aws.amazon.com/blogs/architecture/announcing-the-well-architected-data-residency-with-hybrid-cloud-services-lens/

As organizations increasingly take advantage of the benefits of hybrid cloud architectures, they are often faced with the challenge of balancing data residency requirements with the flexibility of the cloud. To help you navigate this complex landscape, we are excited to introduce the AWS Well-Architected Data Residency with Hybrid Cloud Services (DRHC) Lens paper.

The AWS Well-Architected Framework provides a consistent approach for evaluating architectures and applying best practices to build reliable, secure, efficient, and cost-effective systems in the cloud. The framework is based on six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability.

What’s in the Well-Architected Data Residency with Hybrid Cloud Services Lens?

The DRHC Lens identifies a set of key design principles to help you in the development and deployment of Well-Architected hybrid cloud workloads:

  • Classify data and workloads – Determine which data sources and workloads must remain on premises or in a specific geography to comply with data residency requirements, and which can be moved to an AWS Region.
  • Establish operational practices for data sovereignty – Develop and implement distinct processes and procedures for data and workloads that are subject to data residency or data sovereignty regulations.
  • Use in-Region services whenever possible – Data residency and data sovereignty regulations often apply only to specific elements of an application, or to specific data. For those elements that aren’t in scope for these regulations, use the broad set of services available in Regions, such as identity, automation, and monitoring services.
  • Automate infrastructure – Build orchestration and automation frameworks that adapt to data residency or data sovereignty classifications to deploy compliant, repeatable, and verifiable application stacks. Automation is critical for eliminating manual processes that might introduce mistakes that can lead to compliance failures.
  • Implement robust security measures – The protection and integrity of data is critical to complying with corporate, data-residency, and data-sovereignty regulations. Use all of the tools and services available across AWS Regions, AWS Local Zones, and on AWS Outposts, including specific preventative controls to meet data residency regualations, when developing and deploying your applications.

In addition to these design principles, the lens provides detailed guidance across the six pillars of the Well-Architected Framework:

  • Operational Excellence – Achieve effective system operations, gain operational insights, and implement continuous process improvement for hybrid cloud workloads.
  • Security – Establish control objectives, implement access controls and governance, and configure detection mechanisms to protect data across on-premises and cloud environments.
  • Reliability – Deploy multiple Outposts or Local Zones for high availability, plan for disaster recovery, and maintain operations during on-premises maintenance.
  • Performance Efficiency – Carefully select services, Regions, and configurations that align with latency, bandwidth, and data residency requirements.
  • Cost Optimization – Implement a tagging strategy, monitor and manage Outposts capacity, and optimize network configurations to reduce costs.
  • Sustainability – Anchor Outposts and Local Zones to sustainable Regions, scale infrastructure to match demand, and optimize storage to reduce energy consumption.

Who should use the DRHC Lens?

All AWS customers with data residency requirements, including government agencies, healthcare providers, financial institutions, and public sector industries who are looking for guidance on these architectural patterns, can use the DRHC Lens. When designing and maintaining your architecture with data residency in mind, the following roles can benefit from this lens:

  • Business and technology leaders — For strategic decision-making around data sovereignty requirements
  • Chief technology officers — For aligning technology choices with data residency compliance needs
  • Solutions architects and data residency specialists — For designing compliant hybrid architectures following Well-Architected principles
  • Security and compliance teams — For making sure data handling meets regulatory requirements across Regions
  • Operations teams — For maintaining daily compliance with data residency controls
  • Data engineers and edge computing specialists — For implementing technical controls that enforce data locality requirements

Conclusion

The new Well-Architected Data Residency with Hybrid Cloud Services Lens is available now. Use the lens whitepaper to adopt your hybrid cloud workloads according to the tenants of the Well-Architected Framework while maintaining data sovereignty requirements.

Applying the Data Residency with Hybrid Cloud Services Lens to your architecture helps validate your data handling practices and provides actionable recommendations to address gaps. AWS will continue to update the whitepaper as new services and features are released. Using the lens can help you consistently apply the latest patterns to meet your requirements. This allows you to deploy applications to meet your business objectives and requirements.

About the Authors

Ivanti Connect Secure CVE-2025-22457 exploited in the wild

Post Syndicated from Ryan Emmons original https://blog.rapid7.com/2025/04/03/etr-ivanti-connect-secure-cve-2025-22457-exploited-in-the-wild/

Ivanti Connect Secure CVE-2025-22457 exploited in the wild

On Thursday, April 3, 2025, Ivanti disclosed a critical severity vulnerability affecting Ivanti Connect Secure, Pulse Connect Secure, Policy Secure, and ZTA Gateways. CVE-2025-22457 is a stack-based buffer overflow vulnerability that allows remote, unauthenticated attackers to execute code on the target device. Ivanti’s advisory indicates that CVE-2025-22457 is known to be exploited in the wild; Google’s Mandiant division attributes this activity to suspected China-nexus actors.

Ivanti’s advisory indicates that the vulnerability was “initially identified as a product bug” and patched in Ivanti Connect Secure version 22.7R2.6 (released February 11, 2025). Per Mandiant, CVE-2025-22457 is “a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability.” However, on April 3, Ivanti publicly acknowledged known exploitation in the wild of supported Ivanti Connect Secure and End-of-Support Pulse Connect Secure appliances for remote code execution in some customer environments.

Mitigation guidance

The following products and versions are vulnerable to CVE-2025-22457:

  • Ivanti Connect Secure 22.7R2.5 and prior
  • Pulse Connect Secure (End-of-Support) 9.1R18.9 and prior
  • Ivanti Policy Secure 22.7R1.3 and prior
  • ZTA Gateways 22.8R2 and prior

Ivanti has a full table of affected versions and corresponding solution estimates in their advisory.

A patch is available (initially released on February 11, 2025) for CVE-2025-22457 in Ivanti Connect Secure. However, the advisory states that patches for Ivanti Policy Secure and ZTA Gateways will not be available until April 21, 2025 and April 19, 2025, respectively. Pulse Connect Secure 9.1x reached End-of-Support on December 31, 2024 and won’t be patched. For the latest information, please refer to the Ivanti advisory.

Customers should apply the available Ivanti Connect Secure patch immediately, without waiting for a typical patch cycle to occur. Ivanti’s advisory notes that “Customers should monitor their external ICT and look for web server crashes. If your ICT result shows signs of compromise, you should perform a factory reset on the appliance and then put the appliance back into production using version 22.7R2.6.” Notably, ICT results may vary; a factory reset should be performed if exploitation is suspected, regardless of ICT results.

For the latest information, please refer to the vendor advisory.

Rapid7 customers

InsightVM and Nexpose customers will be able to assess their exposure to CVE-2025-22457 in Ivanti Connect Secure with a vulnerability check expected to be available in today’s (April 3, 2025) content release.

Correlate telemetry data with Amazon OpenSearch Service and Amazon Managed Grafana

Post Syndicated from Balaji Mohan original https://aws.amazon.com/blogs/big-data/correlate-telemetry-data-with-amazon-opensearch-service-and-amazon-managed-grafana/

Troubleshooting a large, complex, distributed enterprise application involves challenges like tracing requests across multiple services, identifying performance bottlenecks across the stack, and understanding cascading failures between dependent services. Customers often need to work with isolated data to identify the underlying cause of the problem. By correlating different signals like logs, traces, metrics, and other performance indicators, you can get valuable insight into what caused the problem, where, and why.

Amazon OpenSearch Service is a managed service to deploy, operate, and search data at scale within AWS. Amazon Managed Grafana is a secure data visualization service to query operational data from multiple sources, including OpenSearch Service.

In this post, we show you how to use these services to correlate the various observability signals that improve root cause analysis, thereby resulting in reduced Mean Time to Resolution (MTTR). We also provide a reference solution that can be used at scale for proactive monitoring of enterprise applications to avoid a problem before they occur.

Solution overview

The following diagram shows the solution architecture for collecting and correlating various enterprise telemetry signals at scale.

At the core of this architecture are applications composed of microservices (represented by orange boxes) running on Amazon Elastic Kubernetes Service (Amazon EKS). These microservices contain instrumentation that emit telemetry data in the form of metrics, logs, and traces. This data is exported into the OpenTelemetry Collector, which serves as a central vendor agnostic gateway to collect this data uniformly.

In this post, we use an OpenTelemetry demo application as a sample enterprise application. Large enterprise customers typically separate their observability signal data into various stores for scalability, fault isolation, access control, and ease of operation. To aid in these functions, we recommend and use Amazon OpenSearch Ingestion for a serverless, scalable, and fully managed data pipeline. We separate log and trace data and send them to distinct OpenSearch Service domains. The solution also sends the metrics data to Amazon Managed Service for Prometheus.

We use Amazon Managed Grafana as a data visualization and analytics platform to query and visualize this data. We also show how to employ correlations as a valuable tool to gain insights from these signals spread across various data stores.

The following sections outline building this architecture at scale.

Prerequisites

Complete the following prerequisite steps:

  1. Provision and configure the Amazon Managed Prometheus workspace to receive metrics from the OpenTelemetry Collector.
  2. Create two dedicated OpenSearch Service domains (or use existing ones) to ingest logs and traces from the OpenTelemetry Collector.
  3. Create an Amazon Managed Grafana workspace and configure data sources to connect to Amazon Managed Prometheus and OpenSearch Service.
  4. Set up an EKS cluster to deploy applications and the OpenTelemetry Collector.

Create log and trace OpenSearch Ingestion pipelines

Before setting up the ingestion pipelines, you need to create the necessary AWS Identity and Access Management (IAM) policies and roles. This process involves creating two policies for domain and OSIS access, followed by creating a pipeline role that uses these policies.

Create a policy for ingestion

Complete the following steps to create an IAM policy:

  1. Open the IAM console.
  2. Choose Policies in the navigation pane, then choose Create policy.
  3. On the JSON tab, enter the following policy into the editor:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "es:DescribeDomain",
            "Resource": "arn:aws:es:*:{accountId}:domain/*"
        },
        {
            "Effect": "Allow",
            "Action": [ "es:ESHttpGet", "es:HttpHead", "es:HttpDelete", "es:HttpPatch", "es:HttpPost", "es:HttpPut" ],
            "Resource": "arn:aws:es:us-east-1:{accountId}:domain/otel-traces"
        },
        {
            "Effect": "Allow",
            "Action": [ "es:ESHttpGet", "es:HttpHead", "es:HttpDelete", "es:HttpPatch", "es:HttpPost", "es:HttpPut" ],
            "Resource": "arn:aws:es:us-east-1:{accountId}:domain/otel-logs"
        }
        }
    ]
}

// Replace {accountId} with your own values
  1. Choose Next, choose Next again, and name your policy domain-policy.
  2. Choose Create policy.
  3. Create another policy with the name osis-policy and use the following JSON:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "osis:Ingest",
            "Resource": "arn:aws:osis:us-east-1:{accountId}:pipeline/osi-pipeline-otellogs"
        },
        {
            "Effect": "Allow",
            "Action": "osis:Ingest",
            "Resource": "arn:aws:osis:us-east-1:{accountId}:pipeline/osi-pipeline-oteltraces"
        }
    ]
}
// Replace {accountId} with your own values

Create a pipeline role

Complete the following steps to create a pipeline role:

  1. On the IAM console, choose Roles in the navigation pane, then choose Create role.
  2. Select Custom trust policy and enter the following policy into the editor:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "eks.amazonaws.com",
                    "osis-pipelines.amazonaws.com"
                ],
                "AWS": "{nodegroup_arn}"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

// Replace {nodegroup_arn} with your own values
  1. Choose Next, then search for and select the policies osis-policy and domain-policy you just created.
  2. Choose Next and name the role PipelineRole.
  3. Choose Create role.

Allow access for the pipeline role in OpenSearch Service domains

To enable access for the pipeline role in OpenSearch Service domains, complete the following steps:

  1. Open the OpenSearch Service console.
  2. Choose your domain (either logs or traces).
  3. Choose the OpenSearch Dashboards URL
  4. Sign in with your credentials.

Then, complete the following steps for each OpenSearch Service domain (logs and traces domains).

  1. In OpenSearch Dashboards, go to the Security
  2. Choose Roles and then all_access.

This procedure uses the all_access role for demonstration purposes only. This grants full administrative privileges to the pipeline role, which violates the principle of least privilege and could pose security risks. For production environments, you should create a custom role with minimal permissions required for data ingestion, limit permissions to specific indexes and operations, consider implementing index patterns and time-based access controls, and regularly audit role mappings and permissions. For detailed guidance on creating custom roles with appropriate permissions, refer to Security in Amazon OpenSearch Service.

  1. Choose Mapped users and then Managed mapping.
  2. On the Map user page, under Backend roles, update the backend role with the Amazon Resource Name (ARN) for the role PiplelineRole.
  3. Choose Map.

Create a pipeline for logs

Complete the following steps to create a pipeline for logs:

  1. Open the OpenSearch Service console.
  2. Choose Ingestion pipelines.
  3. Choose Create pipeline.
  4. Define the pipeline configuration by entering the following:
version: "2"
otel-logs-pipeline:
  source:
    otel_logs_source:
      path: "/v1/logs"
  sink:
    - opensearch:
        hosts: ["{OpenSearch_domain_endpoint}"]
        aws:
          sts_role_arn: "arn:aws:iam::{accountId}:role/osi-pipeline-role"
          region: "us-east-1"
          serverless: false
        index: "observability-otel-logs%{yyyy-MM-dd}"
       
 # To get the values for the placeholders:
 # 1. {OpenSearch_domain_endpoint}: You can find the domain endpoint by navigating to the Amazon Managed Opensearch managed clusters in the AWS Management Console, and then clicking on the domain.
 # After obtaining the necessary values, replace the placeholders in the configuration with the actual values.           

Create a pipeline for traces

Complete the following steps to create a pipeline for traces:

  1. Open the OpenSearch Service console.
  2. Choose Ingestion pipelines.
  3. Choose Create pipeline.
  4. Define the pipeline configuration by entering the following:
version: "2"
entry-pipeline:
  source:
    otel_trace_source:
      path: "/v1/traces"
  processor:
    - trace_peer_forwarder:
  sink:
    - pipeline:
        name: "span-pipeline"
    - pipeline:
        name: "service-map-pipeline"
span-pipeline:
  source:
    pipeline:
      name: "entry-pipeline"
  processor:
    - otel_traces:
  sink:
    - opensearch:
        index_type: "trace-analytics-raw"
        hosts: ["{OpenSearch_domain_endpoint}"]
        aws:                 
          sts_role_arn: "arn:aws:iam::{accountId}:role/osi-pipeline-role"
          region: "us-east-1"
service-map-pipeline:
  source:
    pipeline:
      name: "entry-pipeline"
  processor:
    - service_map:
  sink:
    - opensearch:
        index_type: "trace-analytics-service-map"
        hosts: ["{OpenSearch_domain_endpoint}"]
        aws:                 
          sts_role_arn: "arn:aws:iam::{accountId}:role/osi-pipeline-role"
          region: "us-east-1"
         
 # To get the values for the placeholders:
 # 1. {OpenSearch_domain_endpoint}: You can find the domain endpoint by navigating to the Amazon Managed Opensearch managed clusters in the AWS Management Console, and then clicking on the domain.  # 2. {accountId}: This is your AWS account ID. You can find your account ID by clicking on your username in the top-right corner of the AWS Management Console and selecting "My Account" from the dropdown menu.
 # After obtaining the necessary values, replace the placeholders in the configuration with the actual values.     

Install the OpenTelemetry demo application in Amazon EKS

Use the EKS cluster you set up earlier along with AWS CloudShell or another tool to complete these steps:

  1. Open the AWS Management Console.
  2. Choose the CloudShell icon in the top navigation bar, or go directly to the CloudShell console.
  3. Wait for the shell environment to initialize—it comes preinstalled with common AWS Command Line Interface (AWS CLI) tools.

Now you can complete the following steps to install the application.

  1. Clone the OpenTelemetry Demo repository:
git clone https://github.com/aws-samples/sample-correlation-opensearch-repository
  1. Navigate to the Kubernetes directory:
cd deployment_files
  1. Deploy the demo application using kubectl apply:
kubectl apply -f .
  1. Use a load balancer to expose the frontend service so you can reach the source application web URL:
kubectl expose deployment opentelemetry-demo-frontendproxy --type=LoadBalancer --name=frontendproxy
  1. After you have deployed the application, access the frontend application using the load balancer on port 8080. Use your browser to visit http://<LoadBalancerIP>:8080/ to open the source application for OpenTelemetry.

By following these steps, you can successfully install and access demo applications on your EKS cluster.

Configure the OpenTelemetry Collector exporter for logs, traces, and metrics

The OpenTelemetry Collector is a tool that manages the receiving, processing, and exporting of telemetry data from your application to a target repository.

In this step, we send logs and traces to OpenSearch Service and metrics to Amazon Managed Prometheus. The OpenTelemetry Collector also works with popular data repositories like Jaeger and a variety of other open source and commercial platforms. In this section, we include steps to configure the OpenTelemetry Collector in an EKS environment. Then we deploy the demo application and explore the OpenTelemetry exporters using AWS Managed Solutions instead of the open source versions.

Complete the following steps:

  1. Open the otel-collector-config ConfigMap in your preferred editor:
kubectl edit configmap opentelemetry-demo-otelcol -n otel-demo
  1. Update the exporters section with the following configuration (provide the appropriate Amazon Managed Service for Prometheus endpoint and OpenSearch Service log ingestion URLs):
exporters:
     logging: {}
     otlphttp/logs:
       logs_endpoint: "<AWS_OPENSEARCH_LOG_INGESTION_URL>/v1/logs"
       auth:
         authenticator: sigv4auth
       compression: none
     otlphttp/traces:
       traces_endpoint: "<AWS_OPENSEARCH_TRACE_INGESTION_URL>/v1/traces"
       auth:
         authenticator: sigv4auth
       compression: none
     prometheusremotewrite:
        endpoint: "<AWS_MANAGED_PROMETHEUS_ENDPOINT>"
        auth:
          authenticator: sigv4auth 
  1. Locate the extensions section and update the IAM role ARN in the sigv4auth configuration:
sigv4auth:
        assume_role:
            arn: "arn:aws:iam::{accountId}:role/osi-pipeline-role"
            sts_region: "us-east-1"
        region: "us-east-1"
        service: "osis"
 #  {accountId}: replace accountID with your account id
  1. After updating the ConfigMap, restart the OpenTelemetry Collector deployment:
kubectl rollout restart deployment opentelemetry-demo-otelcol -n otel-demo

With these changes, the OpenTelemetry Collector will send trace data to the OpenSearch Service domain, metrics data to the AWS Managed Service for Prometheus endpoint, and log data to the OpenSearch Service domain.

Configure Amazon Managed Grafana

Before you can visualize your logs and traces, you need to configure OpenSearch Service as a data source in your Amazon Managed Grafana workspace. This configuration is done through the Amazon Managed Grafana console.

Configure the OpenSearch Service data source

Complete the following steps to configure the OpenSearch Service data source:

  1. Open the Amazon Managed Grafana console.
  2. Select your workspace and choose the workspace URL to access your Grafana instance.
  3. Log in to your Amazon Managed Grafana instance.
  4. From the side menu, choose the configuration (gear) icon.
  5. On the Configuration menu, choose Data Sources.
  6. Choose Add data source.
  7. On the Add data source page, select OpenSearch Service from the list of available data sources.
  8. In the Name field, enter a descriptive name for the data source.
  9. In the URL field, enter the URL (OpenSearch Service domain endpoint) of your OpenSearch Service domain, including the protocol and port number.
  10. If your OpenSearch cluster is configured with authentication, provide the required credentials in the User and Password
  11. If you want to use a specific index pattern for the data source, you can specify it in the Index name field (For example, logstash-*).
  12. Adjust any other settings as needed, such as the Time field name and Time interval.
  13. Choose Save & Test to verify the connection to your OpenSearch cluster.

If the test is successful, you should see a green notification with the message “Data source is working.”

  1. Choose Save to save the data source configuration.
  2. Repeat the same steps for the OpenSearch logs and traces domains.

Configure the Prometheus data source

Complete the following steps to configure the Prometheus data source:

  1. Open the Amazon Managed Grafana console.
  2. Select your workspace and choose the workspace URL to access your Grafana instance.
  3. Log in to your Amazon Managed Grafana instance.
  4. From the side menu, choose the configuration (gear) icon.
  5. On the Configuration menu, choose Data Sources.
  6. Choose Add data source.
  7. On the Add data source page, select Amazon Managed Prometheus from the list of available data sources.
  8. In the Name field, enter a descriptive name for the data source.
  9. The AWS Auth Provider and Default Region fields should be automatically populated based on your Amazon Managed Grafana workspace configuration.
  10. In the Workspace field, enter the ID or alias of your Amazon Managed Prometheus workspace.
  11. Choose Save & Test to verify the connection to your Amazon Managed Prometheus workspace.

If the test is successful, you should see a green notification with the message “Data source is working.”

  1. Choose Save to save the data source configuration.

Create correlations in Amazon Managed Grafana

To establish connections between your logs and traces data, you need to set up data correlations in Amazon Managed Grafana. This allows you to navigate seamlessly between related logs and traces. Follow these steps in your Amazon Managed Grafana workspace:

  1. Open the Amazon Managed Grafana console.
  2. Select your workspace and choose the workspace URL to access your Grafana instance.
  3. In the Amazon Managed Grafana portal, on the Administration menu, choose Plugins and Data, and choose Correlation.

  1. On the Set up the target for the correlation page, under Target, choose your traces data source (OpenSearch Service, for example, otel-traces) from the dropdown list and define the query that will execute when the link is followed. You can use variables to query specific field values. For example, traceId: ${__value.raw}.

  1. On the Set up the target for the correlation page, choose the log data source from the dropdown list, and enter the field name to be linked or correlated with the traces data source in the OpenSearch Service data source. For example, traceID.

  1. Choose Save to complete the correlation configuration.

  1. Repeat the steps to create a correlation between metrics on Prometheus to logs in OpenSearch Service.

Validate results

In Amazon Managed Grafana, using the Prometheus data source, locate the desired instance for correlation. The instance ID will be displayed as a link. Follow the link to open the corresponding log details in a panel on the right side of the page.

With the logs to traces correlation configured, you can access trace information directly from the logs page. Choose traces on the log details panel to view the corresponding trace data.

The following screenshot demonstrates the node graph visualization showing the correlation flow: instance metrics to logs to traces.

Clean up

Remove the infrastructure for this solution when not in use to avoid incurring unnecessary costs.

Conclusion

In this post, we showed how to use correlation as a helpful tool to gain insight into observability data stored in various stores.

Separating logs and traces into dedicated domains provides the following benefits:

  • Better resource allocation and scaling based on different workload patterns
  • Independent performance optimization for each data type
  • Simplified cost tracking and management
  • Enhanced security control with separate access policies

You can use this solution as a reference to build a scalable observability solution for your enterprise to detect, investigate, and remediate problems faster. This ability, when used along next-generation artificial intelligence and machine learning (AI/ML), helps to not only proactively react but predict and prevent problems before they occur. You can learn more about AI/ML with AWS.

About the Authors

Balaji Mohan is a Senior Delivery Consultant specializing in application and data modernization to the cloud. His business-first approach provides seamless transitions, aligning technology with organizational goals. Using cloud-centered architectures, he delivers scalable, agile, and cost-effective solutions, driving innovation and growth.

Senthil Ramasamy is a Senior Database Consultant at Amazon Web Services. He works with AWS customers to provide guidance and technical assistance on database services, helping them with database migrations to the AWS Cloud and improving the value of their solutions when using AWS.

Muthu Pitchaimani is a Search Specialist with Amazon OpenSearch Service. He builds large-scale search applications and solutions. Muthu is interested in the topics of networking and security, and is based out of Austin, Texas.

[$] Page allocation for address-space isolation

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

Address-space isolation may well be, as Brendan Jackman said at the
beginning of his memory-management-track session at the 2025 Linux Storage,
Filesystem, Memory-Management, and BPF Summit, “some security
bullshit“. But it also holds the potential to protect the kernel from
a wide range of vulnerabilities, both known and unknown, while reducing the
impact of existing mitigations. Implementing address-space isolation with
reasonable performance, though, is going to require some significant
changes. Jackman was there to get feedback from the memory-management
community on how those changes should be implemented.

[$] Better hugetlb page-table walking

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

The kernel must often step through the page tables of one or more processes
to carry out various operations. This “page-table walking” tends to be
performed by ad-hoc (duplicated) code all over the kernel. Oscar Salvador
used a memory-management-track session at the 2025 Linux Storage,
Filesystem, Memory-Management, and BPF Summit to talk about strategies to
unify the kernel’s page-table walking code just a little bit by making
hugetlb pages look more like ordinary pages.

The collective thoughts of the interwebz