Третата вълна, или как да пием по-добро кафе

Post Syndicated from Йовко Ламбрев original https://www.toest.bg/tretata-vulna-ili-kak-da-piem-po-dobro-kafe/

Третата вълна, или как да пием по-добро кафе

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

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

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

Втората вълна – от втората половина на ХХ век, се свързва с възхода на различни марки кафе и на специализираните кафетерии. Смята се, че двигатели на тази вълна са САЩ и Великобритания. С брандове като Starbucks и Costa те променят начина, по който и до днес се консумира кафе по целия свят. Но истината е, че в основата на промяната стои един нов прочит на начина, по който италианците консумират вездесъщото си капучино.

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

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

Преди това обаче нека уточним основните понятия и фактология.

Какво

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

Най-разпространените видове кафе са арабика и робуста, които заемат съответно около 65 и 35% от световното производство.

Най-рано култивираната и най-широко отглеждана разновидност на кафето е арабиката. Тя е спечелила предпочитанието на публиката със своята по-широка палитра от вкусове и аромати, по-изразена сладка и плодова киселинност и по-фино тяло. Съдържанието на захари в арабиката е около 6–9%, докато при робустата е между 3 и 7%. Арабиката, от друга страна, е с почти двойно по-ниско съдържание на кофеин – едва 1,5% спрямо 2,7% при робустата.

Растенията арабика са капризни и предпочитат по-висока надморска височина, като в същото време никак не понасят мразовито време.

Робуста се е наложило като общо название за сортовете на вида Coffea canephora, от които само единият наистина се нарича robusta, но вече май трябва да сме свикнали, че в света на кафето не бива да сме твърде придирчиви за правилната употреба на названията.

Напитките от робуста се отличават с плътно тяло, ниска киселинност и доста изразена горчивина. Вкусът най-често се определя като дървесен или ядков, а съдържанието на кофеин при робустата е най-високо.

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

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

Либерика, най-редкият вид Coffea, заема едва 1,5% от световното производство. Тя е с по-ниско съдържание на кофеин дори от арабиката – около 1%, при сходно съдържание на захари. Но тъй като човешкото небце възприема кофеина като силно горчив, това създава усещането, че кафето от либерика е по-сладко. Същевременно либериката е по-близка вкусово до робустата – с плътно, опушено ядково тяло, но пък с отличим флорален и плодов аромат, по-характерен за арабиката.

Къде

Кафе се отглежда в повече от 70 страни по света с преобладаващ тропически климат, дори в две европейски локации – на Азорските острови, които са част от Португалия, и на Канарските острови, разположени съвсем близо до крайбрежието на Мароко, но принадлежащи на Испания. Трите най-големи производители обаче са Бразилия, Виетнам и Колумбия. Заедно те осигуряват над 60% от световната продукция, като само Бразилия отглежда над една трета от кафето, което човечеството консумира всяка година.

Виетнам е най-големият производител на робуста (около 40% от световното производство), но тя се отглежда също в значителен мащаб и в Бразилия, Индонезия, Индия, Уганда и други страни. Най-големите производители на кафе арабика са Бразилия, Колумбия и Етиопия.

Колко и как

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

Средногодишната консумация във Финландия достига до 12 кг на човек, което означава приблизително по 4 чаши дневно. Там кратките почивки за кафе са регламентирани в трудовото законодателство на страната. Често в първата петица попадат и исландците, които даже имат интересно свое название за късо кафе – tíu dropar, което буквално означава десет капки. Следващите позиции обикновено се заемат от Швеция, Швейцария и Белгия. А много често в класацията влизат също Естония и Люксембург – едни от най-малките страни на света, но с много развита мрежа от кафенета и годишна консумация от около 6,5 кг кафе на глава от населението.

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

Известният ресторант Noma в Копенхаген има своя авангардна рецепта, в която са комбинирани три класически техники за тяхното т.нар. Nomaricano. То се приготвя първоначално като много дълго (180 мл) еспресо от скандинавско изпечени зърна арабика, допълнително филтрирано през V60, към което накрая се добавят 120 мл гореща вода, за да се получи балансирано американо с плътен букет от флорални вкусове. Популярното вече по цял свят flat white кафе (макар и продукт на втората вълна) е родено в Австралия. А набиращото популярност през последните няколко години dirty coffee („мръсно кафе“) е с японски произход.

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

На гребена на третата вълна

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

А качеството на едно кафе е свързано в огромна степен с две неща – неговия произход и подходящото му изпичане. 

Третата вълна обединява фермерите, пекарите и консуматорите в симбиоза, чиято обща цел е максимално добрият вкус на напитката. Когато произходът на дадено кафе може да бъде проследен до конкретната географска точка, където е отгледано, то се нарича single origin – или single estate, ако е посочена и конкретната ферма производител. Това е важно за ценителите на качествено кафе, защото съдържа информация за вкусовите характеристики и как с различни комбинации от печене и приготвяне на напитките тези вкусове и аромати да изпъкнат възможно най-силно.

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

Част от single origin кафетата с много високо качество се наричат специални.

След като кафеените плодове са събрани (специалните кафета най-често се берат ръчно), зърната трябва да бъдат извадени и изсушени. Има няколко различни метода за това. След тази обработка се получава т.нар. зелено кафе, което напуска фермата, опаковано в чували. В този си вид кафето е доста твърдо и с изразен тревист вкус и аромат. След изпичането зърната стават крехки и развиват естествените си вкусове и аромати. 

Именно печенето е процесът, който отключва и влияе пряко на вкусовете, ароматите и дори върху кофеиновото съдържание на едно кафе.

Така печенето и пекарите стават следващият най-важен фактор за добрия вкус в чашите ни.

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

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

След три-четири месеца от печенето вече почти няма да има значение дали и колко специално е било едно кафе. 

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

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

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

А по-важно от това дали пиете скъпо екзотично специално кафе, е дали то е прясно изпечено.

Прието е, че едно добро еспресо трябва да бъде извлечено за около 25–30 секунди. Много важна е и постоянната температура на водата, при това съобразена със степента на изпичане на зърната. По-светло изпечените кафета обикновено се приготвят с по-гореща вода (92–96°C) от средно изпечените (88–93°C) или тъмните (85–91°C). Смилането на зърната също се отразява на вкуса в чашата, като конкретно за еспресото е много важно смляното кафе да е еднородно (тоест да няма едновременно фини и по-едри частици), за което е нужна качествена мелачка. 

Прекалената горчивост на напитката обикновено е в резултат на твърде дълго извличане, а киселият вкус е симптом за недостатъчна екстракция. За да променим вкуса на кафето от по-кисел към неутрален или по-горчив, има няколко начина: да увеличим температурата, да мелим по-фино, да ползваме по-тъмно изпечено кафе или да увеличим времето за екстракция. Вече споменахме, че робустата придава горчивост, а арабиката – киселинност. Робустата също осигурява повече от т.нар. каймак в еспресото, особено когато зърната са прясно и тъмно изпечени. Средно и по-светло изпечените зърна запазват повече от палитрата от вкусове, които кафето носи със себе си. Тези нюанси се усещат по-лесно чрез филтърни техники за приготвяне на кафе, като V60 или Chemex.

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

Не просто бизнес, а призвание

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

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

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

Преди около десетина години Ангел влага всичките си спестявания в първата си машина за печене на кафе, мотивиран от философията на третата вълна и от мечтата да може да нарече един продукт моето кафе. „На изток казват: „Не е важна целта, а пътят“, споделя той с мен.

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

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

Според Ангел „което не е трудно, не е интересно“. Той добавя:

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

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

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

Димо споделя сходни мисли:

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

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

Не мога да не попитам за конкуренцията, особено в съседните ни Румъния и Гърция, където третата вълна се надига с голяма сила. През 2019 г. Богдан Джорджеску, румънски ИТ специалист, който едва пет години по-рано започва да пече кафе вкъщи за себе си, спечели второ място на Световния шампионат по печене на кафе, а днес неговото прясно печено кафе Mabó се предлага в над 30 заведения в Букурещ и в още толкова в други румънски градове. Миналата година друг румънец зае петото място в същия шампионат.

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

Генезисът на третата вълна е такъв, че се съсредоточава в местната общност и се търсят локални предпочитания. Тази ограниченост не позволява „избухване“ на международно ниво и спечелване на по-голяма популярност. Защото всички ползваме една и съща техника, в повечето случаи едни и същи сортове и като цяло правим каквото можем с наличния ресурс.

Димо също признава, че конкуренцията в кафе индустрията сред нашите най-близки съседи е доста интензивна. И допълва: 

В Румъния през последните години се наблюдава значителен ръст на интереса към специалното кафе. В големите градове и особено в Букурещ има много кафетерии и специализирани магазини, които предлагат висококачествено прясно изпечено кафе. Румънските потребители стават все по-взискателни и образовани относно различните видове кафе и методи на приготвяне.

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

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

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

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

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

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

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

How AI Will Change Democracy

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/05/how-ai-will-change-democracy.html

I don’t think it’s an exaggeration to predict that artificial intelligence will affect every aspect of our society. Not by doing new things. But mostly by doing things that are already being done by humans, perfectly competently.

Replacing humans with AIs isn’t necessarily interesting. But when an AI takes over a human task, the task changes.

In particular, there are potential changes over four dimensions: Speed, scale, scope and sophistication. The problem with AIs trading stocks isn’t that they’re better than humans—it’s that they’re faster. But computers are better at chess and Go because they use more sophisticated strategies than humans. We’re worried about AI-controlled social media accounts because they operate on a superhuman scale.

It gets interesting when changes in degree can become changes in kind. High-speed trading is fundamentally different than regular human trading. AIs have invented fundamentally new strategies in the game of Go. Millions of AI-controlled social media accounts could fundamentally change the nature of propaganda.

It’s these sorts of changes and how AI will affect democracy that I want to talk about.

To start, I want to list some of AI’s core competences. First, it is really good as a summarizer. Second, AI is good at explaining things, teaching with infinite patience. Third, and related, AI can persuade. Propaganda is an offshoot of this. Fourth, AI is fundamentally a prediction technology. Predictions about whether turning left or right will get you to your destination faster. Predictions about whether a tumor is cancerous might improve medical diagnoses. Predictions about which word is likely to come next can help compose an email. Fifth, AI can assess. Assessing requires outside context and criteria. AI is less good at assessing, but it’s getting better. Sixth, AI can decide. A decision is a prediction plus an assessment. We are already using AI to make all sorts of decisions.

How these competences translate to actual useful AI systems depends a lot on the details. We don’t know how far AI will go in replicating or replacing human cognitive functions. Or how soon that will happen. In constrained environments it can be easy. AIs already play chess and Go better than humans. Unconstrained environments are harder. There are still significant challenges to fully AI-piloted automobiles. The technologist Jaron Lanier has a nice quote, that AI does best when “human activities have been done many times before, but not in exactly the same way.”

In this talk, I am going to be largely optimistic about the technology. I’m not going to dwell on the details of how the AI systems might work. Much of what I am talking about is still in the future. Science fiction, but not unrealistic science fiction.

Where I am going to be less optimistic—and more realistic—is about the social implications of the technology. Again, I am less interested in how AI will substitute for humans. I’m looking more at the second-order effects of those substitutions: How the underlying systems will change because of changes in speed, scale, scope and sophistication. My goal is to imagine the possibilities. So that we might be prepared for their eventuality.

And as I go through the possibilities, keep in mind a few questions: Will the change distribute or consolidate power? Will it make people more or less personally involved in democracy? What needs to happen before people will trust AI in this context? What could go wrong if a bad actor subverted the AI in this context? And what can we do, as security technologists, to help?

I am thinking about democracy very broadly. Not just representations, or elections. Democracy as a system for distributing decisions evenly across a population. It’s a way of converting individual preferences into group decisions. And that includes bureaucratic decisions.

To that end, I want to discuss five different areas where AI will affect democracy: Politics, lawmaking, administration, the legal system and, finally, citizens themselves.

I: AI-assisted politicians

I’ve already said that AIs are good at persuasion. Politicians will make use of that. Pretty much everyone talks about AI propaganda. Politicians will make use of that, too. But let’s talk about how this might go well.

In the past, candidates would write books and give speeches to connect with voters. In the future, candidates will also use personalized chatbots to directly engage with voters on a variety of issues. AI can also help fundraise. I don’t have to explain the persuasive power of individually crafted appeals. AI can conduct polls. There’s some really interesting work into having large language models assume different personas and answer questions from their points of view. Unlike people, AIs are always available, will answer thousands of questions without getting tired or bored and are more reliable. This won’t replace polls, but it can augment them. AI can assist human campaign managers by coordinating campaign workers, creating talking points, doing media outreach and assisting get-out-the-vote efforts. These are all things that humans already do. So there’s no real news there.

The changes are largely in scale. AIs can engage with voters, conduct polls and fundraise at a scale that humans cannot—for all sizes of elections. They can also assist in lobbying strategies. AIs could also potentially develop more sophisticated campaign and political strategies than humans can. I expect an arms race as politicians start using these sorts of tools. And we don’t know if the tools will favor one political ideology over another.

More interestingly, future politicians will largely be AI-driven. I don’t mean that AI will replace humans as politicians. Absent a major cultural shift—and some serious changes in the law—that won’t happen. But as AI starts to look and feel more human, our human politicians will start to look and feel more like AI. I think we will be OK with it, because it’s a path we’ve been walking down for a long time. Any major politician today is just the public face of a complex socio-technical system. When the president makes a speech, we all know that they didn’t write it. When a legislator sends out a campaign email, we know that they didn’t write that either—even if they signed it. And when we get a holiday card from any of these people, we know that it was signed by an autopen. Those things are so much a part of politics today that we don’t even think about it. In the future, we’ll accept that almost all communications from our leaders will be written by AI. We’ll accept that they use AI tools for making political and policy decisions. And for planning their campaigns. And for everything else they do. None of this is necessarily bad. But it does change the nature of politics and politicians—just like television and the internet did.

II: AI-assisted legislators

AIs are already good at summarization. This can be applied to listening to constituents:  summarizing letters, comments and making sense of constituent inputs. Public meetings might be summarized. Here the scale of the problem is already overwhelming, and AI can make a big difference. Beyond summarizing, AI can highlight interesting arguments or detect bulk letter-writing campaigns. They can aid in political negotiating.

AIs can also write laws. In November 2023, Porto Alegre, Brazil became the first city to enact a law that was entirely written by AI. It had to do with water meters. One of the councilmen prompted ChatGPT, and it produced a complete bill. He submitted it to the legislature without telling anyone who wrote it. And the humans passed it without any changes.

A law is just a piece of generated text that a government agrees to adopt. And as with every other profession, policymakers will turn to AI to help them draft and revise text. Also, AI can take human-written laws and figure out what they actually mean. Lots of laws are recursive, referencing paragraphs and words of other laws. AIs are already good at making sense of all that.

This means that AI will be good at finding legal loopholes—or at creating legal loopholes. I wrote about this in my latest book, A Hacker’s Mind. Finding loopholes is similar to finding vulnerabilities in software. There’s also a concept called “micro-legislation.” That’s the smallest unit of law that makes a difference to someone. It could be a word or a punctuation mark. AIs will be good at inserting micro-legislation into larger bills. More positively, AI can help figure out unintended consequences of a policy change—by simulating how the change interacts with all the other laws and with human behavior.

AI can also write more complex law than humans can. Right now, laws tend to be general. With details to be worked out by a government agency. AI can allow legislators to propose, and then vote on, all of those details. That will change the balance of power between the legislative and the executive branches of government. This is less of an issue when the same party controls the executive and the legislative branches. It is a big deal when those branches of government are in the hands of different parties. The worry is that AI will give the most powerful groups more tools for propagating their interests.

AI can write laws that are impossible for humans to understand. There are two kinds of laws: specific laws, like speed limits, and laws that require judgment, like those that address reckless driving. Imagine that we train an AI on lots of street camera footage to recognize reckless driving and that it gets better than humans at identifying the sort of behavior that tends to result in accidents. And because it has real-time access to cameras everywhere, it can spot it … everywhere. The AI won’t be able to explain its criteria: It would be a black-box neural net. But we could pass a law defining reckless driving by what that AI says. It would be a law that no human could ever understand. This could happen in all sorts of areas where judgment is part of defining what is illegal. We could delegate many things to the AI because of speed and scale. Market manipulation. Medical malpractice. False advertising. I don’t know if humans will accept this.

III: AI-assisted bureaucracy

Generative AI is already good at a whole lot of administrative paperwork tasks. It will only get better. I want to focus on a few places where it will make a big difference. It could aid in benefits administration—figuring out who is eligible for what. Humans do this today, but there is often a backlog because there aren’t enough humans. It could audit contracts. It could operate at scale, auditing all human-negotiated government contracts. It could aid in contracts negotiation. The government buys a lot of things and has all sorts of complicated rules. AI could help government contractors navigate those rules.

More generally, it could aid in negotiations of all kinds. Think of it as a strategic adviser. This is no different than a human but could result in more complex negotiations. Human negotiations generally center around only a few issues. Mostly because that’s what humans can keep in mind. AI versus AI negotiations could potentially involve thousands of variables simultaneously. Imagine we are using an AI to aid in some international trade negotiation and it suggests a complex strategy that is beyond human understanding. Will we blindly follow the AI? Will we be more willing to do so once we have some history with its accuracy?

And one last bureaucratic possibility: Could AI come up with better institutional designs than we have today? And would we implement them?

IV: AI-assisted legal system

When referring to an AI-assisted legal system, I mean this very broadly—both lawyering and judging and all the things surrounding those activities.

AIs can be lawyers. Early attempts at having AIs write legal briefs didn’t go well. But this is already changing as the systems get more accurate. Chatbots are now able to properly cite their sources and minimize errors. Future AIs will be much better at writing legalese, drastically reducing the cost of legal counsel. And there’s every indication that it will be able to do much of the routine work that lawyers do. So let’s talk about what this means.

Most obviously, it reduces the cost of legal advice and representation, giving it to people who currently can’t afford it. An AI public defender is going to be a lot better than an overworked not very good human public defender. But if we assume that human-plus-AI beats AI-only, then the rich get the combination, and the poor are stuck with just the AI.

It also will result in more sophisticated legal arguments. AI’s ability to search all of the law for precedents to bolster a case will be transformative.

AI will also change the meaning of a lawsuit. Right now, suing someone acts as a strong social signal because of the cost. If the cost drops to free, that signal will be lost. And orders of magnitude more lawsuits will be filed, which will overwhelm the court system.

Another effect could be gutting the profession. Lawyering is based on apprenticeship. But if most of the apprentice slots are filled by AIs, where do newly minted attorneys go to get training? And then where do the top human lawyers come from? This might not happen. AI-assisted lawyers might result in more human lawyering. We don’t know yet.

AI can help enforce the law. In a sense, this is nothing new. Automated systems already act as law enforcement—think speed trap cameras and Breathalyzers. But AI can take this kind of thing much further, like automatically identifying people who cheat on tax returns, identifying fraud on government service applications and watching all of the traffic cameras and issuing citations.

Again, the AI is performing a task for which we don’t have enough humans. And doing it faster, and at scale. This has the obvious problem of false positives. Which could be hard to contest if the courts believe that the computer is always right. This is a thing today: If a Breathalyzer says you’re drunk, it can be hard to contest the software in court. And also the problem of bias, of course: AI law enforcers may be more and less equitable than their human predecessors.

But most importantly, AI changes our relationship with the law. Everyone commits driving violations all the time. If we had a system of automatic enforcement, the way we all drive would change—significantly. Not everyone wants this future. Lots of people don’t want to fund the IRS, even though catching tax cheats is incredibly profitable for the government. And there are legitimate concerns as to whether this would be applied equitably.

AI can help enforce regulations. We have no shortage of rules and regulations. What we have is a shortage of time, resources and willpower to enforce them, which means that lots of companies know that they can ignore regulations with impunity. AI can change this by decoupling the ability to enforce rules from the resources necessary to do it. This makes enforcement more scalable and efficient. Imagine putting cameras in every slaughterhouse in the country looking for animal welfare violations or fielding an AI in every warehouse camera looking for labor violations. That could create an enormous shift in the balance of power between government and corporations—which means that it will be strongly resisted by corporate power.

AIs can provide expert opinions in court. Imagine an AI trained on millions of traffic accidents, including video footage, telemetry from cars and previous court cases. The AI could provide the court with a reconstruction of the accident along with an assignment of fault. AI could do this in a lot of cases where there aren’t enough human experts to analyze the data—and would do it better, because it would have more experience.

AIs can also perform judging tasks, weighing evidence and making decisions, probably not in actual courtrooms, at least not anytime soon, but in other contexts. There are many areas of government where we don’t have enough adjudicators. Automated adjudication has the potential to offer everyone immediate justice. Maybe the AI does the first level of adjudication and humans handle appeals. Probably the first place we’ll see this is in contracts. Instead of the parties agreeing to binding arbitration to resolve disputes, they’ll agree to binding arbitration by AI. This would significantly decrease cost of arbitration. Which would probably significantly increase the number of disputes.

So, let’s imagine a world where dispute resolution is both cheap and fast. If you and I are business partners, and we have a disagreement, we can get a ruling in minutes. And we can do it as many times as we want—multiple times a day, even. Will we lose the ability to disagree and then resolve our disagreements on our own? Or will this make it easier for us to be in a partnership and trust each other?

V: AI-assisted citizens

AI can help people understand political issues by explaining them. We can imagine both partisan and nonpartisan chatbots. AI can also provide political analysis and commentary. And it can do this at every scale. Including for local elections that simply aren’t important enough to attract human journalists. There is a lot of research going on right now on AI as moderator, facilitator, and consensus builder. Human moderators are still better, but we don’t have enough human moderators. And AI will improve over time. AI can moderate at scale, giving the capability to every decision-making group—or chatroom—or local government meeting.

AI can act as a government watchdog. Right now, much local government effectively happens in secret because there are no local journalists covering public meetings. AI can change that, providing summaries and flagging changes in position.

AIs can help people navigate bureaucracies by filling out forms, applying for services and contesting bureaucratic actions. This would help people get the services they deserve, especially disadvantaged people who have difficulty navigating these systems. Again, this is a task that we don’t have enough qualified humans to perform. It sounds good, but not everyone wants this. Administrative burdens can be deliberate.

Finally, AI can eliminate the need for politicians. This one is further out there, but bear with me. Already there is research showing AI can extrapolate our political preferences. An AI personal assistant trained on and continuously attuned to your political preferences could advise you, including what to support and who to vote for. It could possibly even vote on your behalf or, more interestingly, act as your personal representative.

This is where it gets interesting. Our system of representative democracy empowers elected officials to stand in for our collective preferences. But that has obvious problems. Representatives are necessary because people don’t pay attention to politics. And even if they did, there isn’t enough room in the debate hall for everyone to fit. So we need to pick one of us to pass laws in our name. But that selection process is incredibly inefficient. We have complex policy wants and beliefs and can make complex trade-offs. The space of possible policy outcomes is equally complex. But we can’t directly debate the policies. We can only choose one of two—or maybe a few more—candidates to do that for us. This has been called democracy’s “lossy bottleneck.” AI can change this. We can imagine a personal AI directly participating in policy debates on our behalf along with millions of other personal AIs and coming to a consensus on policy.

More near term, AIs can result in more ballot initiatives. Instead of five or six, there might be five or six hundred, as long as the AI can reliably advise people on how to vote. It’s hard to know whether this is a good thing. I don’t think we want people to become politically passive because the AI is taking care of it. But it could result in more legislation that the majority actually wants.

Where will AI take us?

That’s my list. Again, watch where changes of degree result in changes in kind. The sophistication of AI lawmaking will mean more detailed laws, which will change the balance of power between the executive and the legislative branches. The scale of AI lawyering means that litigation becomes affordable to everyone, which will mean an explosion in the amount of litigation. The speed of AI adjudication means that contract disputes will get resolved much faster, which will change the nature of settlements. The scope of AI enforcement means that some laws will become impossible to evade, which will change how the rich and powerful think about them.

I think this is all coming. The time frame is hazy, but the technology is moving in these directions.

All of these applications need security of one form or another. Can we provide confidentiality, integrity and availability where it is needed? AIs are just computers. As such, they have all the security problems regular computers have—plus the new security risks stemming from AI and the way it is trained, deployed and used. Like everything else in security, it depends on the details.

First, the incentives matter. In some cases, the user of the AI wants it to be both secure and accurate. In some cases, the user of the AI wants to subvert the system. Think about prompt injection attacks. In most cases, the owners of the AIs aren’t the users of the AI. As happened with search engines and social media, surveillance and advertising are likely to become the AI’s business model. And in some cases, what the user of the AI wants is at odds with what society wants.

Second, the risks matter. The cost of getting things wrong depends a lot on the application. If a candidate’s chatbot suggests a ridiculous policy, that’s easily corrected. If an AI is helping someone fill out their immigration paperwork, a mistake can get them deported. We need to understand the rate of AI mistakes versus the rate of human mistakes—and also realize that AI mistakes are viewed differently than human mistakes. There are also different types of mistakes: false positives versus false negatives. But also, AI systems can make different kinds of mistakes than humans do—and that’s important. In every case, the systems need to be able to correct mistakes, especially in the context of democracy.

Many of the applications are in adversarial environments. If two countries are using AI to assist in trade negotiations, they are both going to try to hack each other’s AIs. This will include attacks against the AI models but also conventional attacks against the computers and networks that are running the AIs. They’re going to want to subvert, eavesdrop on or disrupt the other’s AI.

Some AI applications will need to run in secure environments. Large language models work best when they have access to everything, in order to train. That goes against traditional classification rules about compartmentalization.

Fourth, power matters. AI is a technology that fundamentally magnifies power of the humans who use it, but not equally across users or applications. Can we build systems that reduce power imbalances rather than increase them? Think of the privacy versus surveillance debate in the context of AI.

And similarly, equity matters. Human agency matters.

And finally, trust matters. Whether or not to trust an AI is less about the AI and more about the application. Some of these AI applications are individual. Some of these applications are societal. Whether something like “fairness” matters depends on this. And there are many competing definitions of fairness that depend on the details of the system and the application. It’s the same with transparency. The need for it depends on the application and the incentives. Democratic applications are likely to require more transparency than corporate ones and probably AI models that are not owned and run by global tech monopolies.

All of these security issues are bigger than AI or democracy. Like all of our security experience, applying it to these new systems will require some new thinking.

AI will be one of humanity’s most important inventions. That’s probably true. What we don’t know is if this is the moment we are inventing it. Or if today’s systems are yet more over-hyped technologies. But these are security conversations we are going to need to have eventually.

AI is fundamentally a power-enhancing technology. We need to ensure that it distributes power and doesn’t further concentrate it.

AI is coming for democracy. Whether the changes are a net positive or negative depends on us. Let’s help tilt things to the positive.

This essay is adapted from a keynote speech delivered at the RSA Conference in San Francisco on May 7, 2024. It originally appeared in Cyberscoop.

 

На второ четене: „Красноречието на сардината“

Post Syndicated from Стефан Иванов original https://www.toest.bg/na-vtoro-chetene-krasnorechieto-na-sardinata/

„Красноречието на сардината“ от Бил Франсоа

На второ четене: „Красноречието на сардината“

превод от френски Наташа Колевска-Куртева, изд. „Жанет 45“, 2022

Когато за пръв път мернах прекрасния сборник с есета „Красноречието на сардината“, моментално се сетих за „Елегантността на таралежа“ на Мюриел Барбери и двете книги наистина имат общи неща – освен подобието в заглавията. Франсоа смесва изискан и хуманен хумор с личния си морски опит, ерудицията и научното си познание – с любовта към пословичните дълбини под вълнитe.

Едва ли в много други страни саундтракът към „Аризонска мечта“ – наистина невероятна среща между Брегович и Иги Поп, е имал толкова радушен или даже култов прием, колкото в България. В една от песните Иги Поп казва в речитатива си, че

рибата не мисли / рибата е безмълвна, без изражение / рибата не мисли, защото тя знае всичко.

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

Рибата говори, просто ние не владеем нейния език.

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

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

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

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

На второ четене: „Красноречието на сардината“

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

Описанията на Франсоа могат да влюбят читателя в подводните жители и да разширят неимоверно представите му. Той разказва как зеленушки и морски каракуди се носят над пяната и скалите. Как

атлантическата сьомга е в състояние да различи във водите на Гренландия мириса на бретонския поток, където е родена, да тръгне да плува по следите на този мирис, докато открие извора му.

Как

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

Или как

лангустите пък се мислят за по-музикални и свирят на цигулка със своите антени,

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

Историята, която ме покърти, е за най-самотния кит на света.

Песента му приличала на тази при финвалите и имала честота 52 херца, която е еквивалентна на най-ниската нота, произвеждана от туба. Това е прекалено висок, пронизителен звук за финвалите, които се свързват на звукова честота от 10 до 35 херца. Затова от десетилетия този кит пее, говори и зове себеподобните си, без да получава отговор. Той се скита самотен в необятната водна шир и само океанографските хидрофони чуват всяка година неговия зов. Никой не знае защо той има толкова странен глас. […] също така никой не знае дали някога е срещал други китове, нито какво може да е почувствал при такава среща, като е виждал другите, без да може да разговаря с тях. Никой не е успял да го види, въпреки че всяка година самотната му миграция може да бъде проследена по звука. За хората самотният кит съществува само чрез своята песен, същата тази, която го изолира от събратята му, тази песен, която той изпраща неуморно с надежда в пустотата на Тихия океан.

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

Такива книги (като „Черноморски упанишад“ на Николай Грозни или като излязлата наскоро „Кратка философия на морето“ на Лоранс Дьовилер) са усилия по посока на усъмняване в превъзходството и нарцисизма на човешкия род и в превръщането му в един по-добър представител на екосистемата на планетата ни. Преди да я досъсипе с ентусиазъм и задоволство от постигнатите резултати.

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

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


Активните дарители на „Тоест“ получават постоянна отстъпка в размер на 20% от коричната цена на всички заглавия от каталога на издателство „Жанет 45“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.

Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. Рубриката е част от партньорската програма Читателски клуб „Тоест“. Изборът на заглавия обаче е единствено на авторите – Стефан Иванов и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как веднъж на две седмици да се разходите с тях в книжарницата.

Тайланд под кожата (първа част)

Post Syndicated from Емине Садкъ original https://www.toest.bg/tayland-pod-kozhata-purva-chast/

Тайланд под кожата (първа част)

Преди няколко години на битака в Исперих си намерих Хун – традиционна тайландска кукла за театър, управлявана от трима души. След цял ден разнасяне из града, с куклата пристигнахме на парти, предизвиквайки страшна еуфория.

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

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

На популярни места като Чианг Май, Патая, Пукет или островите Фи Пи ще се убедите, че

голяма част от туристите идват в Тайланд да видят онова, което холивудските филми и социалните мрежи ни предлагат,

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

Ако обаче не си падате по шоу с вагини, пушещи цигари или изстрелващи топчета за пинг-понг към вас, крокодили на чеверме, скорпиони на клечка и некачествени наркотици, има вероятност улици като „Косан Роад“ и нощните пазари в Бангкок да ви се сторят агресивни и шумни. И все пак – заслужава си да се пуснете по тях, защото само там може да видите как срещу баба, готвеща pad thai (нудъли на тиган със зеленчуци, тофу или месо) танцуват полуголи лейдибойс.

Транссексуалността в Тайланд е толерирана заради будизма –

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

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

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

Това беше и първата страна в Югоизточна Азия, легализирала марихуаната. В началото на пролетта на 2022 г. с публикация в социалните мрежи министърът на здравеопазването Анутин Чарнвиракул обяви, че от 9 юни същата година марихуаната ще бъде достъпна за всички. Мотивите на правителството гласяха, че с това престъпността ще намалее, а земеделските региони в провинцията ще имат възможност да се развиват. Друга причина за легализацията на марихуаната беше, че пандемията нанесе огромни щети върху икономиката на страната и обръщането в тази посока би поощрило по-бързото завръщане на туристите. И привличането на нови.

По данни на Световната банка туризмът съставлява 20% от БВП на страната.

В същия линк може да разгледате основните особености на туризма в Тайланд. А за да си представите ужасяващия удар върху икономиката, който пандемията е нанесла, ще цитирам данните за 2019 г., през която посетителите достигат 39,8 милиона души, а през 2020 г. числото пада под 7 милиона и много от туристическите бизнеси фалират.

След края на пандемията и закрепването на туристическия сектор, както и със смяната на правителството, се говори, че марихуаната в Тайланд отново ще бъде криминализирана, което ще доведе до затварянето на безброй частни магазини за марихуана и кофишопове, както и до закриването на международни компании, инвестирали милиони – например Royal Queen Seeds, най-голямата банка за семена в света.

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

Когато поздравяват или благодарят, тайландците използват т.нар. wai – поклон напред със събрани ръце, подобно на намасте. Намирам за очарователна комуникацията, която включва и тялото. Поздравът Sawasdee (sah-waah-dee) и благодарностите Khwaap khun се превръщат в танц между двама души, водещ до кратко съвместно смирение.

Тайланд под кожата (първа част)

И ако искате хората да разберат, че сте били в Тайланд, без да казвате, че сте били в Тайланд, може да продължите да отговаряте с khaap khun след всяко изречение, когато се приберете. Или да си направите свещена татуировка с бамбукова пръчка. Традиционната татуировка – Sak Yant, се смята за свещена, а татуистите – Sak Yant Ajarns, са с ранг на духовни учители. По време на ритуала на татуиране се освещава всяка капка мастило, която носи късмет, любов, закрила и други благоденствия за татуирания. Но и без да преминете през мастиления ритуал,

Тайланд ще остане под кожата ви и една от причините за това, разбира се, е храната.

Въпреки че навсякъде може да се видят по една пасяща кравичка с големи уши и малки кози, завързани за дърво, къща, кола, мотор, крак на спящ човек, жегата и влагата са твърде агресивни, за да се произвеждат и съхраняват млечни продукти. А един от малкото брандове кисели млека, които се продават в популярните вериги магазини 7-Eleven, носи името Bulgaria.

Вместо краве мляко в традиционната тайска кухня се използва кокосово като един от основните компоненти, както и кафява захар, соев или стриден сос, лимонена трева и люто. Много люто. Още по-люто. Смърт. Често в менютата на ресторантите има две скàли за лютивост – Western spicy или Thai spicy. Ако изберете втората, възможно е сервитьорите тайно да ви наблюдават, докато ядете, и да се любуват на последвалите гримаси.

Сладостта в тайското къри и някои други ястия не е по моя вкус, но

да си вегетарианец в Тайланд е много по-лесно дори в сравнение с най-хипстърския град на нашия континент.

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

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

Друго, което тайландците продават навсякъде, е бензин в бутилки от ром. Така по всяко време може да заредиш японския си (като марка) скутер, произведен в Тайланд и нает за 150 бата на ден (около 7,50 лв.). Както в повечето азиатски страни, и тук скутерите масово се използват за придвижване дори в големите градове, в които разстоянията са изтощителни.

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

Тайланд под кожата (първа част)

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

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

Всички снимки в статията са собственост на авторката.

[$] Standardizing the BPF ISA

Post Syndicated from daroc original https://lwn.net/Articles/975830/

While BPF may be most famous for its use in the Linux kernel, there is actually
a growing effort to standardize BPF for use on other systems. These include

eBPF for Windows
, but also

uBPF
,

rBPF
,

hBPF
,

bpftime
, and
others. Some hardware manufacturers are even
considering integrating BPF directly into networking hardware. Dave Thaler
led two sessions about all of the problems that cross-platform use inevitably
brings and the current status of the standardization work at the 2024
Linux Storage,
Filesystem, Memory Management, and BPF Summit
.

Migrate a petabyte-scale data warehouse from Actian Vectorwise to Amazon Redshift

Post Syndicated from Krishna Gogineni original https://aws.amazon.com/blogs/big-data/migrate-a-petabyte-scale-data-warehouse-from-actian-vectorwise-to-amazon-redshift/

Amazon Redshift is a fast, scalable, and fully managed cloud data warehouse that allows you to process and run your complex SQL analytics workloads on structured and semi-structured data. It also helps you securely access your data in operational databases, data lakes, or third-party datasets with minimal movement or copying of data. Tens of thousands of customers use Amazon Redshift to process large amounts of data, modernize their data analytics workloads, and provide insights for their business users.

In this post, we discuss how a financial services industry customer achieved scalability, resiliency, and availability by migrating from an on-premises Actian Vectorwise data warehouse to Amazon Redshift.

Challenges

The customer’s use case required a high-performing, highly available, and scalable data warehouse to process queries against large datasets in a low-latency environment. Their Actian Vectorwise system was designed to replace Excel plugins and stock screeners but eventually evolved into a much larger and ambitious portfolio analysis solution running multiple API clusters on premises, serving some of the largest financial services firms worldwide. The customer saw growing demand that needed high performance and scalability due to 30% year-over-year increase in usage from the success of their products. The customer needed to keep up with increased volume of read requests, but they couldn’t do this without deploying additional hardware in the data center. There was also a customer mandate that business-critical products must have their hardware updated to cloud-based solutions or be deemed on the path to obsolescence. In addition, the business started moving customers onto a new commercial model, and therefore new projects would need to provision a new cluster, which meant that they needed improved performance, scalability, and availability.

They faced the following challenges:

  • Scalability – The customer understood that infrastructure maintenance was a growing issue and, although operations were a consideration, the existing implementation didn’t have a scalable and efficient solution to meet the advanced sharding requirements needed for query, reporting, and analysis. Over-provisioning of data warehouse capacity to meet unpredictable workloads resulted in underutilized capacity during normal operations by 30%.
  • Availability and resiliency – Because the customer was running business-critical analytical workloads, it required the highest levels of availability and resiliency, which was a concern with the on-premises data warehouse solution.
  • Performance – Some of their queries needed to be processed in priority, and users were starting to experience performance degradation with longer-running query times as their solution started getting used more and more. The need for a scalable and efficient solution to manage customer demand, address infrastructure maintenance concerns, replace legacy tooling, and tackle availability led to them choosing Amazon Redshift as the future state solution. If these concerns were not addressed, the customer would be prevented from growing their user base.

Legacy architecture

The customer’s platform was the main source for one-time, batch, and content processing. It served many enterprise use cases across API feeds, content mastering, and analytics interfaces. It was also the single strategic platform within the company for entity screening, on-the-fly aggregation, and other one-time, complex request workflows.

The following diagram illustrates the legacy architecture.

The architecture consists of many layers:

  • Rules engine – The rules engine was responsible for intercepting every incoming request. Based on the nature of the request, it routed the request to the API cluster that could optimally process that specific request based on the response time requirement.
  • API – Scalability was one of the primary challenges with the existing on-premises system. It wasn’t possible to quickly scale up and down API service capacity to meet growing business demand. Both the API and data store had to support a highly volatile workload pattern. This included simple data retrieval requests that had to be processed within a few milliseconds vs. power user-style batch requests with complex analytics-based workloads that could take several seconds and significant compute resources to process. To separate these different workload patterns, the API and data store infrastructure was split into multiple isolated physical clusters. This made sure each workload group was provisioned with sufficient reserved capacity to meet the respective response time expectations. However, this model of reserving capacity for each workload type resulted in suboptimal usage of compute resources because each cluster would only process a specific workload type.
  • Data store – The data store used a custom data model that had been highly optimized to meet low-latency query response requirements. The current on-premises data store wasn’t horizontally scalable, and there was no built-in replication or data sharding capability. Due to this limitation, multiple database instances were created to meet concurrent scalability and availability requirements because the schema wasn’t generic per dataset. This model caused operational maintenance overhead and wasn’t easily expandable.
  • Data ingestion – Pentaho was used to ingest data sourced from multiple data publishers into the data store. The ingestion framework itself didn’t have any major challenges. However, the primary bottleneck was due to scalability issues associated with the data store. Because the data store didn’t support sharding or replication, data ingestion had to explicitly ingest the same data concurrently across multiple database nodes within a single transaction to provide data consistency. This significantly impacted overall ingestion speed.

Overall, the current architecture didn’t support workload prioritization, therefore a physical model of resources was reserved for this reason. The downside here is over-provisioning. The system had an integration with legacy backend services that were all hosted on premises.

Solution overview

Amazon Redshift is an industry-leading cloud data warehouse. Amazon Redshift uses SQL to analyze structured and semi-structured data across data warehouses, operational databases, and data lakes using AWS-designed hardware and machine learning (ML) to deliver the best price-performance at any scale.

Amazon Redshift is designed for high-performance data warehousing, which provides fast query processing and scalable storage to handle large volumes of data efficiently. Its columnar storage format minimizes I/O and improves query performance by reading only the relevant data needed for each query, resulting in faster data retrieval. Lastly, you can integrate Amazon Redshift with data lakes like Amazon Simple Storage Service (Amazon S3), combining structured and semi-structured data for comprehensive analytics.

The following diagram illustrates the architecture of the new solution.

In the following sections, we discuss the features of this solution and how it addresses the challenges of the legacy architecture.

Rules engine and API

Amazon API Gateway is a fully managed service that help developers deliver secure, robust, API-driven application backends at any scale. To address scalability and availability requirements of the rules and routing layer, we introduced API Gateway to do the routing of the client requests to different integration paths using routes and parameter mappings. Having API Gateway as the entry point allowed the customer to move away from the design, testing, and maintenance of their rules engine development workload. In their legacy environment, handling fluctuating amounts of traffic posed a significant challenge. However, API Gateway seamlessly addressed this issue by acting as a proxy and automatically scaling to accommodate varying traffic demands, providing optimal performance and reliability.

Data storage and processing

Amazon Redshift allowed the customer to meet their scalability and performance requirements. Amazon Redshift features such as workload management (WLM), massively parallel processing (MPP) architecture, concurrency scaling, and parameter groups helped address the requirements:

  • WLM provided the ability for query prioritization and managing resources effectively
  • The MPP architecture model provided horizontal scalability
  • Concurrency scaling added additional cluster capacity to handle unpredictable and spiky workloads
  • Parameter groups defined configuration parameters that control database behavior

Together, these capabilities allowed them to meet their scalability and performance requirements in a managed fashion.

Data distribution

The legacy data center architecture was unable to partition the data without deploying additional hardware in the data center, and it couldn’t handle read workloads efficiently.

The MPP architecture of Amazon Redshift offers efficient data distribution across all the compute nodes, which helped run heavy workloads in parallel and subsequently lowered response times. With the data distributed across all the compute nodes, it allows data to be processed in parallel. Its MPP engine and architecture separates compute and storage for efficient scaling and performance.

Operational efficiency and hygiene

Infrastructure maintenance and operational efficiency was a concern for the customer in their current state architecture. Amazon Redshift is a fully managed service that takes care of data warehouse management tasks such as hardware provisioning, software patching, setup, configuration, and monitoring nodes and drives to recover from failures or backups. Amazon Redshift periodically performs maintenance to apply fixes, enhancements, and new features to your Redshift data warehouse. As a result, the customer’s operational costs reduced by 500%, and they are now able to spend more time innovating and building mission-critical applications.

Workload management

Amazon Redshift WLM was able to resolve issues with the legacy architecture where longer-running queries were consuming all the resources, causing other queries to run slower, impacting performance SLAs. With automatic WLM, the customer was able to create separate WLM queues with different priorities, which allowed them to manage the priorities for the critical SLA-bound workloads and other non-critical workloads. With short query acceleration (SQA) enabled, it prioritized selected short-running queries ahead of longer-running queries. Furthermore, the customer benefited by using query monitoring rules in WLM to apply performance boundaries to control poorly designed queries and take action when a query goes beyond those boundaries. To learn more about WLM, refer to Implementing workload management.

Workload isolation

In the legacy architecture, all the workloads—extract, transform, and load (ETL); business intelligence (BI); and one-time workloads—were running on the same on-premises data warehouse, leading to the noisy neighbor problem and performance issues with the increase in users and workloads.

With the new solution architecture, this issue is remediated using data sharing in Amazon Redshift. With data sharing, the customer is able to share live data with security and ease across Redshift clusters, AWS accounts, or AWS Regions for read purposes, without the need to copy any data.

Data sharing improved the agility of the customer’s organization. It does this by giving them instant, granular, and high-performance access to data across Redshift clusters without the need to copy or move it manually. With data sharing, customers have live access to data, so their users can see the most up-to-date and consistent information as it’s updated in Redshift clusters. Data sharing provides workload isolation by running ETL workloads in its own Redshift cluster and sharing data with other BI and analytical workloads in their respective Redshift clusters.

Scalability

With the legacy architecture, the customer was facing scalability challenges during large events to handle unpredictable spiky workloads and over-provisioning of the database capacity. Using concurrency scaling and elastic resize allowed the customer to meet their scalability requirements and handle unpredictable and spiky workloads.

Data migration to Amazon Redshift

The customer used a home-grown process to extract the data from Actian Vectorwise and store it in Amazon S3 and CSV files. The data from Amazon S3 was then ingested into Amazon Redshift.

The loading process used a COPY command and ingested the data from Amazon S3 in a fast and efficient way. A best practice for loading data into Amazon Redshift is to use the COPY command. The COPY command is the most efficient way to load a table because it uses the Amazon Redshift MPP architecture to read and load data in parallel from a file or multiple files in an S3 bucket.

To learn about the best practices for source data files to load using the COPY command, see Loading data files.

After the data is ingested into Redshift staging tables from Amazon S3, transformation jobs are run from Pentaho to apply the incremental changes to the final reporting tables.

The following diagram illustrates this workflow.

Key considerations for the migration

There are three ways of migrating an on-premises data warehouse to Amazon Redshift: one-step, two-step, and wave-based migration. To minimize the risk of migrating over 20 databases that vary in complexity, we decided on the wave-based approach. The fundamental concept behind wave-based migration involves dividing the migration program into projects based on factors such as complexity and business outcomes. The implementation then migrates each project individually or by combining certain projects into a wave. Subsequent waves follow, which may or may not be dependent on the results of the preceding wave.

This strategy requires both the legacy data warehouse and Amazon Redshift to operate concurrently until the migration and validation of all workloads are successfully complete. This provides a smooth transition while making sure the on-premises infrastructure can be retired only after thorough migration and validation have taken place.

In addition, within each wave, we followed a set of phases to make sure that each wave was successful:

  • Assess and plan
  • Design the Amazon Redshift environment
  • Migrate the data
  • Test and validate
  • Perform cutover and optimizations

In the process, we didn’t want to rewrite the legacy code for each migration. With minimal code changes, we migrated the data to Amazon Redshift because SQL compatibility was very important in the process due to existing knowledge within the organization and downstream application consumption. After the data was ingested into the Redshift cluster, we adjusted the tables for best performance.

One of the main benefits we realized as part of the migration was the option to integrate data in Amazon Redshift with other business groups in the future that use AWS Data Exchange, without significant effort.

We performed blue/green deployments to make sure that the end-users didn’t encounter any latency degradation while retrieving the data. We migrated the end-users in a phased manner to measure the impact and adjust the cluster configuration as needed.

Results

The customer’s decision to use Amazon Redshift for their solution was further reinforced by the platform’s ability to handle both structured and semi-structured data seamlessly. Amazon Redshift allows the customer to efficiently analyze and derive valuable insights from their diverse range of datasets, including equities and institutional data, all while using standard SQL commands that teams are already comfortable with.

Through rigorous testing, Amazon Redshift consistently demonstrated remarkable performance, meeting the customer’s stringent SLAs and delivering exceptional subsecond query response times with an impressive latency. With the AWS migration, the customer achieved a 5% improvement in query performance. Scalability of the clusters was done in minutes compared to 6 months in the data center. Operational cost reduced by 500% due to the simplicity of the Redshift cluster operations in AWS. Stability of the clusters improved by 100%. Upgrades and patching cycle time improved by 200%. Overall, improvement in operational posture and total savings for the footprint has resulted in significant savings for the team and platform in general. In addition, the ability to scale the overall architecture based on market data trends in a resilient and highly available way not only met the customer demand in terms of time to market, but also significantly reduced the operational costs and total cost of ownership.

Conclusion

In this post, we covered how a large financial services customer improved performance and scalability, and reduced their operational costs by migrating to Amazon Redshift. This enabled the customer to grow and onboard new workloads into Amazon Redshift for their business-critical applications.

To learn about other migration use cases, refer to the following:


About the Authors

Krishna Gogineni is a Principal Solutions Architect at AWS helping financial services customers. Krishna is Cloud-Native Architecture evangelist helping customers transform the way they build software. Krishna works with customers to learn their unique business goals, and then super-charge their ability to meet these goals through software delivery that leverages industry best practices/tools such as DevOps, Data Lakes, Data Analytics, Microservices, Containers, and Continuous Integration/Continuous Delivery.

Dayananda Shenoy is a Senior Solution Architect with over 20 years of experience designing and architecting backend services for financial services products. Currently, he leads the design and architecture of distributed, high-performance, low latency analytics services for a data provider. He is passionate about solving scalability and performance challenges in distributed systems leveraging emerging technology which improve existing tech stacks and add value to the business to enhance customer experience.

Vishal Balani is a Sr. Customer Solutions Manager based out of New York. He works closely with Financial Services customers to help them leverage cloud for businesses agility, innovation and resiliency. He has extensive experience leading large-scale cloud migration programs. Outside of work he enjoys spending time with family, tinkering with a new project or riding his bike.

Ranjan Burman is a Sr. PostgreSQL Database Specialist SA. He specializes in RDS & Aurora PostgreSQL. He has more than 18 years of experience in different database and data warehousing technologies. He is passionate about automating and solving customer problems with the use of cloud solutions.

Muthuvelan Swaminathan is an Enterprise Solutions Architect based out of New York. He works with enterprise customers providing architectural guidance in building resilient, cost-effective and innovative solutions that address business needs.

Quickly adopt new AWS features with the Terraform AWS Cloud Control provider

Post Syndicated from Welly Siauw original https://aws.amazon.com/blogs/devops/quickly-adopt-new-aws-features-with-the-terraform-aws-cloud-control-provider/

Introduction

Today, we are pleased to announce the general availability of the Terraform AWS Cloud Control (AWS CC) Provider, enabling our customers to take advantage of AWS innovations faster. AWS has been continually expanding its services to support virtually any cloud workload; supporting over 200 fully featured services and delighting customers through its rapid pace of innovation with over 3,400 significant new features in 2023. Our customers use Infrastructure as Code (IaC) tools such as HashiCorp Terraform among others as a best-practice to provision and manage these AWS features and services as part of their cloud infrastructure at scale. With the Terraform AWS CC Provider launch, AWS customers using Terraform as their IaC tool can now benefit from faster time-to-market by building cloud infrastructure with the latest AWS innovations that are typically available on the Terraform AWS CC Provider on the day of launch. For example, AWS customer Meta’s Oculus Studios was able to quickly leverage Amazon GameLift to support their game development. “AWS and Hashicorp have been great partners in helping Oculus Studios standardize how we deploy our GameLift infrastructure using industry best practices.” said Mick Afaneh, Meta’s Oculus Studios Central Technology.

The Terraform AWS CC Provider leverages AWS Cloud Control API to automatically generate support for hundreds of AWS resource types, such as Amazon EC2 instances and Amazon S3 buckets. Since the AWS CC provider is automatically generated, new features and services on AWS can be supported as soon as they are available on AWS Cloud Control API, addressing any coverage gaps in the existing Terraform AWS standard provider. This automated process allows the AWS CC provider to deliver new resources faster because it does not have to wait for the community to author schema and resource implementations for each new service. Today, the AWS CC provider supports 950+ AWS resources and data sources, with more support being added as AWS service teams continue to adopt the Cloud Control API standard.

As a Terraform practitioner, using the AWS CC Provider would feel familiar to the existing workflow. You can employ the configuration blocks shown below, while specifying your preferred region.

terraform {
  required_providers {
    awscc = {
      source  = "hashicorp/awscc"
      version = "~> 1.0"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "awscc" {
  region = "us-east-1"
}

provider "aws" {
  region = "us-east-1"
}

During Terraform plan or apply, the AWS CC Terraform provider interacts with AWS Cloud Control API to provision the resources by calling its consistent Create, Read, Update, Delete, or List (CRUD-L) APIs.

AWS Cloud Control API

AWS service teams own, publish, and maintain resources on the AWS CloudFormation Registry using a standardized resource model. This resource model uses uniform JSON schemas and provisioning logic that codifies the expected behavior and error handling associated with CRUD-L operations. This resource model enables AWS service teams to expose their service features in an easily discoverable, intuitive, and uniform format with standardized behavior. Launched in September 2021, AWS Cloud Control API exposes these resources through a set of five consistent CRUD-L operations without any additional work from service teams. Using Cloud Control API, developers can manage the lifecycle of hundreds of AWS and third-party resources with consistent resource-oriented API instead of using distinct service-specific APIs. Furthermore, Cloud Control API is up-to-date with the latest AWS resources as soon as they are available on the CloudFormation Registry, typically on the day of launch. You can read more on launch day requirement for Cloud Control API in this blog post. This enables AWS Partners such as HashiCorp to take advantage of consistent CRUD-L API operations and integrate Terraform with Cloud Control API just once, and then automatically access new AWS resources without additional integration work.

History and Evolution of the Terraform AWS CC Provider

The general availability of Terraform AWS CC Provider project is a culmination of 4+ years of collaboration between AWS and HashiCorp. Our teams partnered across the Product, Engineering, Partner, and Customer Support functions in influencing, shaping, and defining the customer experience leading up to the the technical preview announcement of the AWS CC provider in September 2021. At technical preview, the provider supported more than 300 resources. Since then, we have added an additional 600+ resources to the provider, bringing the total to 950+ supported resources at general availability.

Beyond just increasing resource coverage, we gathered additional signals from customer feedback during the technical preview and rolled out several improvements since September 2021. Customers care deeply about the user experience on the providers available on the Terraform registry. Customers sought practical examples in the form of sample HCL configurations for each resource that they could use to immediately test in order to confidently start using the provider. This prompted us to enrich the AWS CC provider with hundreds of practical examples for popular AWS CC provider resources in the Terraform registry. This was made possible by contributions of hundreds of Amazonians who became early adopters of the AWS CC provider. We also published a how-to guide for anyone interested in contributing to AWS CC provider examples. Furthermore, customers also wanted to minimize context switching by moving between Terraform and AWS service documentation on what each attribute of a resource signified and the type of values it needed as part of configuration. This empowered us to prioritize augmenting the provider with rich resource attribute description with information taken from AWS documentation. The documentation provides detailed information of how to use the attributes, enumerations of the accepted attribute values and other relevant information for dozens of popularly used AWS resources.

We also worked with HashiCorp on various bug fixes and feature enhancements for the AWS CC provider, as well as the upstream Cloud Control API dependencies. We improved handling for resources with complex nested attribute schemas, implemented various bug fixes to resolve unintended resource replacement, and refined provider behavior under various conditions to support the idempotency expected by Terraform practitioners. While this are not an exhaustive list of improvements, we continue to listen to customer feedback and iterate on improving the experience. We encourage you to try out the provider and share feedback on the AWS CC provider’s GitHub page.

Using the AWS CC Provider

Let’s take an example of a recently introduced service, Amazon Q Business, a fully managed, generative AI-powered assistant that you can configure to answer questions, provide summaries, generate content, and complete tasks based on your enterprise data. Amazon Q Business resources were available in AWS CC provider shortly after the April 30th 2024 launch announcement. In the following example, we’ll create a demo Amazon Q Business application and deploy the web experience.

data "aws_caller_identity" "current" {}

data "aws_ssoadmin_instances" "example" {}

resource "awscc_qbusiness_application" "example" {
  description                  = "Example QBusiness Application"
  display_name                 = "Demo_QBusiness_App"
  attachments_configuration    = {
    attachments_control_mode = "ENABLED"
  }
  identity_center_instance_arn = data.aws_ssoadmin_instances.example.arns[0]
}

resource "awscc_qbusiness_web_experience" "example" {
  application_id              = awscc_qbusiness_application.example.id
  role_arn                    = awscc_iam_role.example.arn
  subtitle                    = "Drop a file and ask questions"
  title                       = "Demo Amazon Q Business"
  welcome_message             = "Welcome, please enter your questions"
}

resource "awscc_iam_role" "example" {
  role_name   = "Amazon-QBusiness-WebExperience-Role"
  description = "Grants permissions to AWS Services and Resources used or managed by Amazon Q Business"
  assume_role_policy_document = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "QBusinessTrustPolicy"
        Effect = "Allow"
        Principal = {
          Service = "application.qbusiness.amazonaws.com"
        }
        Action = [
          "sts:AssumeRole",
          "sts:SetContext"
        ]
        Condition = {
          StringEquals = {
            "aws:SourceAccount" = data.aws_caller_identity.current.account_id
          }
          ArnEquals = {
            "aws:SourceArn" = awscc_qbusiness_application.example.application_arn
          }
        }
      }
    ]
  })
  policies = [{
    policy_name = "qbusiness_policy"
    policy_document = jsonencode({
      Version = "2012-10-17"
      Statement = [
        {
          Sid = "QBusinessConversationPermission"
          Effect = "Allow"
          Action = [
            "qbusiness:Chat",
            "qbusiness:ChatSync",
            "qbusiness:ListMessages",
            "qbusiness:ListConversations",
            "qbusiness:DeleteConversation",
            "qbusiness:PutFeedback",
            "qbusiness:GetWebExperience",
            "qbusiness:GetApplication",
            "qbusiness:ListPlugins",
            "qbusiness:GetChatControlsConfiguration"
          ]
          Resource = awscc_qbusiness_application.example.application_arn
        }
      ]
    })
  }]
}

As you see in this example, you can use both the AWS and AWS CC providers in the same configuration file. This allows you to easily incorporate new resources available in the AWS CC provider into your existing configuration with minimal changes. The AWS CC provider also accepts the same authentication method and provider-level features available in the AWS provider. This means you don’t have to add additional configuration in your CI/CD pipeline to start using the AWS CC provider. In addition, you can also add custom agent information inside the provider block as described in this documentation.

Things to know

The AWS CC provider is unique due to how it was developed and its dependencies with Cloud Control API and AWS resource model in the CloudFormation registry. As such, there are things that you should know before you start using the AWS CC provider.

  • The AWS CC provider is generated from the latest CloudFormation schemas, and will release weekly containing all new AWS services and enhancements added to Cloud Control API.
  • Certain resources available in the CloudFormation schema are not compatible with the AWS CC provider due to nuances in the schema implementation. You can find them on the GitHub issue list here. We are actively working to add these resources to the AWS CC provider.
  • The AWS CC provider requires Terraform CLI version 1.0.7 or higher.
  • Every AWS CC provider resource includes a top-level attribute `id` that acts as the resource identifier. If the CloudFormation resource schema also has a similarly named top-level attribute `id`, then that property is mapped to a new attribute named `<type>_id`. For example `web_experience_id` for `awscc_qbusiness_web_experience` resource.
  • If a resource attribute is not defined in the Terraform configuration, the AWS CC provider will honor the default values specified in the CloudFormation resource schema. If the resource schema does not include a default value, AWS CC provider will use attribute value stored in the Terraform state (taken from Cloud Control API GetResponse after resource was created).
  • In correlation to the default value behavior as stated above, when an attribute value is removed from the Terraform configuration (e.g. by commenting the attribute), the AWS CC provider will use the previous attribute value stored in the Terraform state. As such, no drift will be detected on the resource configuration when you run Terraform plan / apply.
  • The AWS CC provider data sources are either plural or singular with filters based on `id` attribute. Currently there is no native support for metadata sources such as `aws_region` or `aws_caller_identity`. You can continue to leverage the AWS provider data sources to complement your Terraform configuration.

If you want to dive deeper into AWS CC provider resource behavior, we encourage you to check the documentation here.

Conclusion

The AWS CC provider is now generally available and will be the fastest way for customers to access newly launched AWS features and services using Terraform. We will continue to add support for more resources, additional examples and enriching the schema descriptions. You can start using the AWS CC provider alongside your existing AWS standard provider. To learn more about the AWS CC provider, please check the HashiCorp announcement blog post. You can also follow the workshop on how to get started with AWS CC provider. If you are interested in contributing with practical examples for AWS CC provider resources, check out the how-to guide. For more questions or if you run into any issues with the new provider, don’t hesitate to submit your issue in the AWS CC provider GitHub repository.

Authors

Manu Chandrasekhar

Manu is an AWS DevOps consultant with close to 19 years of industry experience wearing QA/DevOps/Software engineering and management hats. He looks to enable teams he works with to be self-sufficient in
modelling/provisioning Infrastructure in cloud and guides them in cloud adoption. He believes that by improving the developer experience and reducing the barrier of entry to any technology with the advancements in automation and AI, software deployment and delivery can be a non-event.

Rahul Sharma

Rahul is a Principal Product Manager-Technical at Amazon Web Services with over three and a half years of cumulative product management experience spanning Infrastructure as Code (IaC) and Customer Identity and Access Management (CIAM) space.

Welly Siauw

As a Principal Partner Solution Architect, Welly led the co-build and co-innovation strategy with AWS ISV partners. He is passionate about Terraform, Developer Experience and Cloud Governance. Welly joined AWS in 2018 and carried with him almost 2 decades of experience in IT operations, application development, cyber security, and oil exploration. In between work, he spent time tinkering with espresso machines and outdoor hiking.

CVE-2024-24919: Check Point Security Gateway Information Disclosure

Post Syndicated from Rapid7 original https://blog.rapid7.com/2024/05/30/etr-cve-2024-24919-check-point-security-gateway-information-disclosure/

CVE-2024-24919: Check Point Security Gateway Information Disclosure

On May 28, 2024, Check Point published an advisory for CVE-2024-24919, a high-severity information disclosure vulnerability affecting Check Point Security Gateway devices configured with either the “IPSec VPN” or “Mobile Access” software blade.

On May 29, 2024, security firm mnemonic published a blog reporting that they have observed in-the-wild exploitation of CVE-2024-24919 since April 30, 2024, with threat actors leveraging the vulnerability to enumerate and extract password hashes for all local accounts, including accounts used to connect to Active Directory. They’ve also observed adversaries moving laterally and extracting the “ntds.dit” file from compromised customers’ Active Directory servers, within hours of an initial attack against a vulnerable Check Point Gateway.

On May 30, 2024, watchTowr published technical details of CVE-2024-24919 including a PoC.

The vulnerability allows an unauthenticated remote attacker to read the contents of an arbitrary file located on the affected appliance. For example, this allows an attacker to read the appliances /etc/shadow file, disclosing the password hashes for local accounts. The attacker is not limited to reading this file and may read other files that contain sensitive information. An attacker may be able to crack the password hashes for these local accounts, and if the Security Gateway allows password only authentication, the attacker may use the cracked passwords to authenticate.

Mitigation Guidance

According to the vendor advisory, the following products are vulnerable to CVE-2024-24919:

  • CloudGuard Network
  • Quantum Maestro
  • Quantum Scalable Chassis
  • Quantum Security Gateways
  • Quantum Spark Appliances

Check Point has advised that a Security Gateway is vulnerable if one of the following configuration is applied:

  • If the “IPSec VPN” blade has been enabled and the Security Gateway device is part of the “Remote Access” VPN community.
  • If the “Mobile Access” blade has been enabled.

Check Point has released hotfixes for Quantum Security Gateway, Quantum Maestro, Quantum Scalable Chassis, and Quantum Spark Appliances. We advise customers to refer to the Check Point advisory for the most current information on affected versions and hotfixes.

The vendor supplied hotfixes should be applied immediately. Rapid7 strongly recommends that Check Point Security Gateway customers examine their environments for signs of compromise and reset local account credentials in addition to applying vendor-provided fixes.

Check Point notes that exploit attempts their team has observed “focus on remote access scenarios with old local accounts with unrecommended password-only authentication.” The company recommends that customers check for local account usage, disable any unused local accounts, and add certificate-based authentication rather than password-only authentication. More information and recommendations on user and client authentication for remote access is available here.

Rapid7 Customers

A vulnerability check is in development for InsightVM and Nexpose customers to assess exposure to CVE-2024-24919. This blog will be updated with the latest information as and when it is available

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on post-exploitation behavior related to this vulnerability:

  • Suspicious Web Server Request – Successful Path Traversal Attack
  • Suspicious Web Request – Possible Check Point VPN (CVE-2024-24919) Exploitation

Let’s Architect! Learn About Machine Learning on AWS

Post Syndicated from Luca Mezzalira original https://aws.amazon.com/blogs/architecture/lets-architect-learn-about-machine-learning-on-aws/

A data-driven approach empowers businesses to make informed decisions based on accurate predictions and forecasts, leading to improved operational efficiency and resource optimization. Machine learning (ML) systems have the remarkable ability to continuously learn and adapt, improving their performance over time as they are exposed to more data. This self-learning capability ensures that organizations can stay ahead of the curve, responding dynamically to changing market conditions and customer preferences, ultimately driving innovation and enhancing competitiveness.

By leveraging the power of machine learning on AWS, businesses can unlock benefits that enhance efficiency, improve decision-making, and foster growth.

AWS re:Invent 2023 – Zero to machine learning: Jump-start your data-driven journey

In this session, see how organizations with constrained resources (budgets, skill gaps, time) can jump start their data-driven journey with advanced analytics and ML capabilities. Learn AWS Working Backwards best practices to drive forward data-related projects that address tangible business value. Then dive into AWS analytics and AI/ML capabilities that simplify and expedite data pipeline delivery and business value from ML workloads. Hear about low-code no-code (LCNC) AWS services within the context of a complete data pipeline architecture.

Take me to this video

See an architecture to analyze customer churn using AWS services

Figure 1. See an architecture to analyze customer churn using AWS services

Introduction to MLOps engineering on AWS

As artificial intelligence (AI) continues to revolutionize industries, the ability to operationalize and scale ML models has become a critical challenge. This session introduces the concept of MLOps, a discipline that builds upon and extends the widely adopted DevOps practices prevalent in software development. By applying MLOps principles, organizations can streamline the process of building, training, and deploying ML models, ensuring efficient and reliable model lifecycle management. By mastering MLOps, organizations can bridge the gap between AI development and operations, enabling them to unlock the full potential of their ML initiatives.

Take me to this video

MLOps maturity level will help to assess your organization and understand how to reach the next level.

Figure 2. MLOps maturity level will help to assess your organization and understand how to reach the next level.

Behind-the-scenes look at generative AI infrastructure at Amazon

To power generative AI applications while keeping costs under control, AWS designs and builds machine learning accelerators like AWS Trainium and AWS Inferentia. This session introduces purpose-built ML hardware for model training and inference, and shows how Amazon and AWS customers take advantage of those solutions to optimize costs and reduce latency.

You can learn from practical examples showing the impact of those solutions and explanations about how these chips work. ML accelerators are not only beneficial for generative AI workloads; they can also be applied to other use cases, including representation learning, recommender systems, or any scenario with deep neural network models.

Take me to this video

Discover the technology that powers our AI services

Figure 3. Discover the technology that powers our AI services

How our customers are implementing machine learning on AWS

The following resources drill down into the ML infrastructure that’s used to train large models at Pinterest and the experimentation framework built by Booking.com.

The Pinterest video discusses the strategy to create an ML development environment, orchestrate training jobs, ingest data into the training loop, and accelerate the training speed. You can also learn about the advantages derived from containers in the context of ML and how Pinterest decided to set up the entire ML lifecycle, including distributed model training.

The second resource covers how Booking.com accelerated the experimentation process by leveraging Amazon SageMaker for data analysis, model training, and online experimentation. This resulted in shorter development times for their ranking models and increased speed for the data science teams.

Take me to Pinterest video

Take me to Booking.com blog post

Let’s discover how Pinterest is using AWS services for machine learning workloads

Figure 4. Let’s discover how Pinterest is using AWS services for machine learning workloads

SageMaker Immersion Day

Amazon SageMaker Immersion Day helps customers and partners provide end-to-end understanding of building ML use cases. From feature engineering to understanding various built-in algorithms, with a focus on training, tuning, and deploying the ML model in a production-like scenario, this workshop guides you to bring your own model to perform lift-and-shift from on-premises to the Amazon SageMaker platform. It further demonstrates more advanced concepts like model debugging, model monitoring, and AutoML.

Take me to the workshop

Train, tune and deploy your workload using Amazon SageMaker

Figure 5. Train, tune and deploy your workload using Amazon SageMaker

See you next time!

Thanks for reading! With this post, introduced you to the art of possibility on using AWS machine learning services. In the next blog, we will talk about cloud migrations.

To revisit any of our previous posts or explore the entire series, visit the Let’s Architect! page.

UALink will be the NVLink Standard Backed by AMD Intel Broadcom Cisco and More

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/ualink-will-be-the-nvlink-standard-backed-by-amd-intel-broadcom-cisco-and-more/

AMD, Intel, Broadcom, Cisco, Meta, Goole, Microsoft and more are backing the UALink standard as an industry alternative to NVIDIA NVLink

The post UALink will be the NVLink Standard Backed by AMD Intel Broadcom Cisco and More appeared first on ServeTheHome.

How to issue use-case bound certificates with AWS Private CA

Post Syndicated from Chris Morris original https://aws.amazon.com/blogs/security/how-to-issue-use-case-bound-certificates-with-aws-private-ca/

In this post, we’ll show how you can use AWS Private Certificate Authority (AWS Private CA) to issue a wide range of X.509 certificates that are tailored for specific use cases. These use-case bound certificates have their intended purpose defined within the certificate components, such as the Key Usage and Extended Key usage extensions. We will guide you on how you can define your usage by applying your required Key Usage and Extended Key usage values with the IssueCertificate API operation.

Background

With the AWS Private CA service, you can build your own public key infrastructure (PKI) in the AWS Cloud and issue certificates to use within your organization. Certificates issued by AWS Private CA support both the Key Usage and Extended Key Usage extensions. By using these extensions with specific values, you can bind the usage of a given certificate to a particular use case during creation. Binding certificates to their intended use case, such as SSL/TLS server authentication or code signing, provides distinct security benefits such as accountability and least privilege.

When you define certificate usage with specific Key Usage and Extended Key Usage values, this helps your organization understand what purpose a given certificate serves and the use case for which it is bound. During audits, organizations can inspect their certificate’s Key Usage and Extended Key Usage values to determine the certificate’s purpose and scope. This not only provides accountability regarding a certificate’s usage, but also a level of transparency for auditors and stakeholders. Furthermore, by using these extensions with specific values, you will follow the principle of least privilege. You can grant least privilege by defining only the required Key Usage and Extended Key Usage values for your use case. For example, if a given certificate is going to be used only for email protection (S/MIME), you can assign only that extended key usage value to the certificate.

Certificate templates and use cases

In AWS Private CA, the Key Usage and Extended Key Usage extensions and values are specified by using a configuration template, which is passed with the IssueCertificate API operation. The base template provided by AWS handles the most common certificate use cases, such as SSL/TLS server authentication or code signing. However, there are additional use cases for certificates that are not defined in base templates. To issue certificates for these use cases, you can pass blank certificate templates in your IssueCertificate requests, along with your required Key Usage and Extended Key usage values.

Such use cases include, but are not limited to the following:

  • Certificates for SSL/TLS
    • Issue certificates with an Extended Key Usage value of Server Authentication, Client Authentication, or both.
  • Certificates for email protection (S/MIME)
    • Issue certificates with an Extended Key Usage value of E-mail Protection
  • Certificates for smart card authentication (Microsoft Smart Card Login)
    • Issue certificates with an Extended Key Usage value of Smart Card Logon
  • Certificates for document signing
    • Issue certificates with an Extended Key Usage value of Document Signing
  • Certificates for code signing
    • Issue certificates with an Extended Key Usage value of Code Signing
  • Certificates that conform to the Matter connectivity standard

If your certificates require less-common extended key usage values not defined in the AWS documentation, you can also pass object identifiers (OIDs) to define values in Extended Key Usage. OIDs are dotted-string identifiers that are mapped to objects and attributes. OIDs can be defined and passed with custom extensions using API passthrough. You can also define OIDs in a CSR (certificate signing request) with a CSR passthrough template. Such uses include:

  • Certificates that require IPSec or virtual private network (VPN) related extensions
    • Issue certificates with Extended Key Usage values:
      • OID: 1.3.6.1.5.5.7.3.5 (IPSEC_END_SYSTEM)
      • OID: 1.3.6.1.5.5.7.3.6 (IPSEC_TUNNEL)
      • OID: 1.3.6.1.5.5.7.3.7 (IPSEC_USER)
  • Certificates that conform to the ISO/IEC standard for mobile driving license (mDL)
    • Pass the ISO/IEC 18013-5 OID reserved for mDL DS: 1.0.18013.5.1.2 by using custom extensions.

It’s important to note that blank certificate templates aren’t limited to just end-entity certificates. For example, the BlankSubordinateCACertificate_PathLen0_APICSRPassthrough template sets the Basic constraints parameter to CA:TRUE, allowing you to issue a subordinate CA certificate with your own Key Usage and Extended Key Usage values.

Using blank certificate templates

When you browse through the AWS Private CA certificate templates, you may see that base templates don’t allow you to define your own Key Usage or Extended Key Usage extensions and values. They are preset to the extensions and values used for the most common certificate types in order to simplify issuing those types of certificates. For example, when using EndEntityCertificate/V1, you will always get a Key Usage value of Critical, digital signature, key encipherment and an Extended Key Usage value of TLS web server authentication, TLS web client authentication. The following table shows all of the values for this base template.

EndEntityCertificate/V1
X509v3 parameter Value
Subject alternative name [Passthrough from certificate signing request (CSR)]
Subject [Passthrough from CSR]
Basic constraints CA:FALSE
Authority key identifier [Subject key identifier from CA certificate]
Subject key identifier [Derived from CSR]
Key usage Critical, digital signature, key encipherment
Extended key usage TLS web server authentication, TLS web client authentication
CRL distribution points [Passthrough from CA configuration]

When you look at blank certificate templates, you will see that there is more flexibility. For one example of a blank certificate template, BlankEndEntityCertificate_APICSRPassthrough/V1, you can see that there are fewer predefined values compared to EndEntityCertificate/V1. You can pass your own values for Extended Key Usage and Key Usage.

BlankEndEntityCertificate_APICSRPassthrough/V1
X509v3 parameter Value
Subject alternative name [Passthrough from API or CSR]
Subject [Passthrough from API or CSR]
Basic constraints CA:FALSE
Authority key identifier [Subject key identifier from CA certificate]
Subject key identifier [Derived from CSR]
CRL distribution points

Note: CRL distribution points are included in the template only if the CA is configured with CRL generation enabled.

[Passthrough from CA configuration or CSR]

To specify your desired extension and value, you must pass them in the IssueCertificate API call. There are two ways of doing so: the API Passthrough and CSR Passthrough templates.

  • API Passthrough – Extensions and their values defined in the IssueCertificate parameter APIPassthrough are copied over to the issued certificate.
  • CSR Passthrough – Extensions and their values defined in the CSR are copied over to the issued certificate.

To accommodate the different ways of passing these values, there are three varieties of blank certificate templates. If you would like to pass extensions defined only in your CSR file to the issued certificate, you can use the BlankEndEntityCertificate_CSRPassthrough/V1 template. Similarly, if you would like to pass extensions defined only in the APIPassthrough parameter, you can use the BlankEndEntityCertificate_APIPassthrough/V1 template. Finally, if you would like to use a combination of extensions defined in both the CSR and APIPassthrough, you can use the BlankEndEntityCertificate_APICSRPassthrough/V1 template. It’s important to remember these points when choosing your template:

  • The template definition will always have the higher priority over the values specified in the CSR, regardless of what template variety you use. For example, if the template contains a Key Usage value of digital signature and your CSR file contains key encipherment, the certificate will choose the template definition digital signature.
  • API passthrough values are only respected when you use an API passthrough or APICSR passthrough template. CSR passthrough is only respected when you use a CSR passthrough or APICSR passthrough template. When these sources of information are in conflict (the CSR contains the same extension or value as what’s passed in API passthrough), a general rule usually applies: For each extension value, the template definition has highest priority, followed by API passthrough values, followed by CSR passthrough extensions. Read more about the template order of operations in the AWS documentation.

How to issue use-case bound certificates in the AWS CLI

To get started issuing certificates, you must have appropriate AWS Identity and Access Management (IAM) permissions as well as an AWS Private CA in an “Active” status. You can verify if your private CA is active by running the aws acm-pca list-certificate-authorities command from the AWS Command Line Interface (CLI). You should see the following:

"Status": "ACTIVE"

After verifying the status, make note of your private CA Amazon Resource Name (ARN).

To issue use-case bound certificates, you must use the Private CA API operation IssueCertificate.

In the AWS CLI, you can call this API by using the command issue-certificate. There are several parameters you must pass with this command:

  • (--certificate-authority-arn) – The ARN of your private CA.
  • (--csr) – The CSR in PEM format. It must be passed as a blob , like fileb://.
  • (--validity) – Sets the “Not After” date (expiration date) for the certificate.
  • (--signing-algorithm) – The signing algorithm to be used to sign the certificate. The value you choose must match the algorithm family of the private CA’s algorithm (RSA or ECDSA). For example, if the private CA uses RSA_2048, the signing algorithm must be an RSA variant, like SHA256WITHRSA.

    You can check your private CA’s algorithm family by referring to its key algorithm. The command aws acm-pca describe-certificate-authority will show the corresponding KeyAlgorithm value.

  • (--template-arn) – This is where the blank certificate template is defined. The template should be an AWS Private CA template ARN. The full list of AWS Private CA template ARNs are shown in the AWS documentation.

We’ll now demonstrate how to issue use-case bound end-entity certificates by using blank end-entity certificate templates. We will issue two different certificates. One will be bound for email protection, and one will be bound for smart card authentication. Email protection and smart card authentication certificates have specific Extended Key Usage values which are not defined by any base template. We’ll use CSR passthrough to issue the smart card authentication certificate and use API passthrough to issue the email protection certificate.

The certificate templates that we will use are:

  • For CSR passthrough: BlankEndEntityCertificate_CSRPassthrough/V1
  • For API Passthrough: BlankEndEntityCertificate_APIPassthrough/V1

Important notes about this demo:

  • These commands are for demo purposes only. Depending on your specific use case, email protection certificates and smart card authentication certificates may require different extensions than what’s shown in this demo.
  • You will be generating RSA 2048 private keys. Private keys need to be protected and stored properly and securely. For example, encrypting private keys or storing private keys in a hardware security module (HSM) are some methods of protection that you can use.
  • We will be using the OpenSSL command line tool, which is installed by default on many operating systems such as Amazon Linux 2023. If you don’t have this tool installed, you can obtain it by using the software distribution facilities of your organization or your operating system, as appropriate.

Use API passthrough

We will now demonstrate how to issue a certificate that is bound for email protection. We’ll specify Key Usage and Extended Key Usage values, and also a subject alternative name through API passthrough. The goal is to have these extensions and values in the email protection certificate.

Extensions:

	X509v3 Key Usage: critical
	Digital Signature, Key Encipherment
	X509v3 Extended Key Usage:
	E-mail Protection
	X509v3 Subject Alternative Name:
	email:[email protected]

To issue a certificate bound for email protection

  1. Use the following command to create your keypair and CSR with OpenSSL. Define your distinguished name in the OpenSSL prompt.
    openssl req -out csr-demo-1.csr -new -newkey rsa:2048 -nodes -keyout private-key-demo-1.pem

  2. Use the following command to issue an end-entity certificate specifying the EMAIL_PROTECTION extended key usage value, the Digital Signature and Key Encipherment Key Usage values, and the subject alternative name [email protected]. We will use the Rfc822Name subject alternative name type, because the value is an email address.

    Make sure to replace the data in arn:aws:acm-pca:<region>:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 with your private CA ARN, and adjust the signing algorithm according to your private CA’s algorithm. Assuming my PCA is type RSA, I am using SHA256WITHRSA.

    aws acm-pca issue-certificate --certificate-authority-arn arn:aws:acm-pca:<region>:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 --csr fileb://csr-demo-1.csr --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_APIPassthrough/V1 --signing-algorithm "SHA256WITHRSA" --validity Value=365,Type="DAYS" --api-passthrough "Extensions={ExtendedKeyUsage=[{ExtendedKeyUsageType="EMAIL_PROTECTION"}],KeyUsage={"DigitalSignature"=true,"KeyEncipherment"=true},SubjectAlternativeNames=[{Rfc822Name="[email protected]"}]}"

     If the command is successful, then the ARN of the issued certificate is shown as the result:

    {
        "CertificateArn": "arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789"
    }

  3. Proceed to the Retrieve the Certificate section of this post to retrieve the certificate and certificate chain PEM from the CertificateArn.

Use CSR passthrough

We’ll now demonstrate how to issue a certificate that is bound for smart card authentication. We will specify Key Usage, Extended Key Usage, and subject alternative name extensions and values through CSR passthrough. The goal is to have these values in the smart card authentication certificate.

Extensions:

	X509v3 Key Usage: critical
	Digital Signature
	X509v3 Extended Key Usage:
	TLS Web Client Authentication, Microsoft Smartcard Login
	X509v3 Subject Alternative Name:
	othername: UPN::[email protected]

We’ll generate our CSR by requesting these specific extensions and values with OpenSSL. When we call IssueCertificate, the CSR passthrough template will acknowledge the requested extensions and copy them over to the issued certificate.

To issue a certificate bound for smart card authentication

  1. Use the following command to create the private key.
    openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private-key-demo-2.pem

  2. Create a file called openssl_csr.conf to define the distinguished name and the requested CSR extensions.

    Following is an example of OpenSSL configuration file content. You can copy this configuration to the openssl_csr.conf file and adjust the values to your requirements. You can find further reference on the configuration in the OpenSSL documentation.

    [ req ]
    default_bits = 2048
    prompt = no
    default_md = sha256
    req_extensions = my_req_ext
    distinguished_name = dn
    
    #Specify the Distinguished Name
    [ dn ]
    countryName                     = US
    stateOrProvinceName             = VA 
    localityName                    = Test City
    organizationName                = Test Organization Inc
    organizationalUnitName          = Test Organization Unit
    commonName                      = john_doe
    
    
    #Specify the Extensions
    [ my_req_ext ]
    keyUsage = critical, digitalSignature
    extendedKeyUsage = clientAuth, msSmartcardLogin 
    
    #UPN OtherName OID: "1.3.6.1.4.1.311.20.2.3". Value is ASN1-encoded UTF8 string
    subjectAltName = otherName:msUPN;UTF8:[email protected] 

    In this example, you can specify your Key Usage and Extended Key Usage values in the [ my_req_ext ] section of the configuration. In the extendedKeyUsage line, you may also define extended key usage OIDs, like 1.3.6.1.4.1.311.20.2.2. Possible values are defined in the OpenSSL documentation.

  3. Create the CSR, defining the configuration file.
    openssl req -new -key private-key-demo-2.pem -out csr-demo-2.csr -config openssl_csr.conf

  4. (Optional) You can use the following command to decode the CSR to make sure it contains the information you require.
    openssl req -in csr-demo-2.csr -noout  -text

    The output should show the requested extensions and their values, as follows.

    	X509v3 Key Usage: critical
    	Digital Signature
    	X509v3 Extended Key Usage:
    	TLS Web Client Authentication, Microsoft Smartcard Login
    	X509v3 Subject Alternative Name:
    	othername: UPN:: <your_user_here>

  5. Issue the certificate by using the issue-certificate command. We will use a CSR passthrough template so that the requested extensions and values in the CSR file are copied over to the issued certificate.

    Make sure to replace the data in arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 with your private CA ARN and adjust the signing algorithm and validity to for your use case. Assuming my PCA is type RSA, I am using SHA256WITHRSA.

    aws acm-pca issue-certificate --certificate-authority-arn arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 --csr fileb://csr-demo-2.csr --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 --signing-algorithm "SHA256WITHRSA" --validity Value=365,Type="DAYS"

    If the command is successful, then the ARN of the issued certificate is shown as the result:

    {
        "CertificateArn": "arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789"
    }

Retrieve the certificate

After using issue-certificate with API passthrough or CSR passthrough, you can retrieve the certificate material in PEM format. Use the get-certificate command and specify the ARN of the private CA that issued the certificate, as well as the ARN of the certificate that was issued:

aws acm-pca get-certificate --certificate-arn arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 --certificate-authority-arn arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 --output text

You can use the --query command with the AWS CLI to get the certificate and certificate chain in separate files.

Certificate

aws acm-pca get-certificate --certificate-authority-arn  arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 --certificate-arn arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 --output text --query Certificate > certfile.pem

Certificate chain

aws acm-pca get-certificate --certificate-authority-arn  arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111 --certificate-arn arn:aws:acm-pca:us-east-1:<accountID>:certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 --output text --query CertificateChain > certchain.pem

After you retrieve the certificate, you can decode it with the openssl x509 command. This will allow you to view the details of the certificate, including the extensions and values that you defined.

openssl x509 -in certfile.pem -noout -text

Conclusion

In AWS Private CA, you can implement the security benefits of accountability and least privilege by defining the usage of your certificates. The Key Usage and Extended Key Usage values define the usage of your certificates. Many certificate use cases require a combination of Key Usage and Extended Key Usage values, which cannot be defined with base certificate templates. Some examples include document signing, smart card authentication, and mobile driving license (mDL) certificates. To issue certificates for these specific use cases, you can use blank certificate templates with the IssueCertificate API call. In addition to the blank certificate template, you must also define the specific combination of Key Usage and Extended Key Usage values through CSR passthrough, API passthrough, or both.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Chris Morris

Chris Morris

Chris is a Cloud Support Engineer at AWS. He specializes in a variety of security topics, including cryptography and data protection. He focuses on helping AWS customers effectively use AWS security services to strengthen their security posture in the cloud. Public key infrastructure and key management are some of his favorite security topics.

Vishal Jakharia

Vishal Jakharia

Vishal is a Cloud Support Engineer based in New Jersey, USA. Having expertise in security services and he loves to work with customer to troubleshoot the complex issues. He helps customers migrate and build secure scalable architecture on the AWS Cloud.

[$] New APIs for filesystems

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

A discussion of extensions to the statx()
system call comes up frequently at the Linux Storage,
Filesystem, Memory Management, and BPF Summit
; this year’s edition was
no exception. Kent Overstreet led the first filesystem-only session at the
summit on querying information about filesystems that have subvolumes and
snapshots. While it was billed as a discussion on statx()
additions, it ranged more widely over new APIs needed for modern filesystems.

Disrupting FlyingYeti’s campaign targeting Ukraine

Post Syndicated from Cloudforce One original https://blog.cloudflare.com/disrupting-flyingyeti-campaign-targeting-ukraine


Cloudforce One is publishing the results of our investigation and real-time effort to detect, deny, degrade, disrupt, and delay threat activity by the Russia-aligned threat actor FlyingYeti during their latest phishing campaign targeting Ukraine. At the onset of Russia’s invasion of Ukraine on February 24, 2022, Ukraine introduced a moratorium on evictions and termination of utility services for unpaid debt. The moratorium ended in January 2024, resulting in significant debt liability and increased financial stress for Ukrainian citizens. The FlyingYeti campaign capitalized on anxiety over the potential loss of access to housing and utilities by enticing targets to open malicious files via debt-themed lures. If opened, the files would result in infection with the PowerShell malware known as COOKBOX, allowing FlyingYeti to support follow-on objectives, such as installation of additional payloads and control over the victim’s system.

Since April 26, 2024, Cloudforce One has taken measures to prevent FlyingYeti from launching their phishing campaign – a campaign involving the use of Cloudflare Workers and GitHub, as well as exploitation of the WinRAR vulnerability CVE-2023-38831. Our countermeasures included internal actions, such as detections and code takedowns, as well as external collaboration with third parties to remove the actor’s cloud-hosted malware. Our effectiveness against this actor prolonged their operational timeline from days to weeks. For example, in a single instance, FlyingYeti spent almost eight hours debugging their code as a result of our mitigations. By employing proactive defense measures, we successfully stopped this determined threat actor from achieving their objectives.

Executive Summary

  • On April 18, 2024, Cloudforce One detected the Russia-aligned threat actor FlyingYeti preparing to launch a phishing espionage campaign targeting individuals in Ukraine.
  • We discovered the actor used similar tactics, techniques, and procedures (TTPs) as those detailed in Ukranian CERT’s article on UAC-0149, a threat group that has primarily targeted Ukrainian defense entities with COOKBOX malware since at least the fall of 2023.
  • From mid-April to mid-May, we observed FlyingYeti conduct reconnaissance activity, create lure content for use in their phishing campaign, and develop various iterations of their malware. We assessed that the threat actor intended to launch their campaign in early May, likely following Orthodox Easter.
  • After several weeks of monitoring actor reconnaissance and weaponization activity (Cyber Kill Chain Stages 1 and 2), we successfully disrupted FlyingYeti’s operation moments after the final COOKBOX payload was built.
  • The payload included an exploit for the WinRAR vulnerability CVE-2023-38831, which FlyingYeti will likely continue to use in their phishing campaigns to infect targets with malware.
  • We offer steps users can take to defend themselves against FlyingYeti phishing operations, and also provide recommendations, detections, and indicators of compromise.

Who is FlyingYeti?

FlyingYeti is the cryptonym given by Cloudforce One to the threat group behind this phishing campaign, which overlaps with UAC-0149 activity tracked by CERT-UA in February and April 2024. The threat actor uses dynamic DNS (DDNS) for their infrastructure and leverages cloud-based platforms for hosting malicious content and for malware command and control (C2). Our investigation of FlyingYeti TTPs suggests this is likely a Russia-aligned threat group. The actor appears to primarily focus on targeting Ukrainian military entities. Additionally, we observed Russian-language comments in FlyingYeti’s code, and the actor’s operational hours falling within the UTC+3 time zone.

Campaign background

In the days leading up to the start of the campaign, Cloudforce One observed FlyingYeti conducting reconnaissance on payment processes for Ukrainian communal housing and utility services:

  • April 22, 2024 – research into changes made in 2016 that introduced the use of QR codes in payment notices
  • April 22, 2024 – research on current developments concerning housing and utility debt in Ukraine
  • April 25, 2024 – research on the legal basis for restructuring housing debt in Ukraine as well as debt involving utilities, such as gas and electricity

Cloudforce One judges that the observed reconnaissance is likely due to the Ukrainian government’s payment moratorium introduced at the start of the full-fledged invasion in February 2022. Under this moratorium, outstanding debt would not lead to evictions or termination of provision of utility services. However, on January 9, 2024, the government lifted this ban, resulting in increased pressure on Ukrainian citizens with outstanding debt. FlyingYeti sought to capitalize on that pressure, leveraging debt restructuring and payment-related lures in an attempt to increase their chances of successfully targeting Ukrainian individuals.

Analysis of the Komunalka-themed phishing site

The disrupted phishing campaign would have directed FlyingYeti targets to an actor-controlled GitHub page at hxxps[:]//komunalka[.]github[.]io, which is a spoofed version of the Kyiv Komunalka communal housing site https://www.komunalka.ua. Komunalka functions as a payment processor for residents in the Kyiv region and allows for payment of utilities, such as gas, electricity, telephone, and Internet. Additionally, users can pay other fees and fines, and even donate to Ukraine’s defense forces.

Based on past FlyingYeti operations, targets may be directed to the actor’s Github page via a link in a phishing email or an encrypted Signal message. If a target accesses the spoofed Komunalka platform at hxxps[:]//komunalka[.]github[.]io, the page displays a large green button with a prompt to download the document “Рахунок.docx” (“Invoice.docx”), as shown in Figure 1. This button masquerades as a link to an overdue payment invoice but actually results in the download of the malicious archive “Заборгованість по ЖКП.rar” (“Debt for housing and utility services.rar”).

Figure 1: Prompt to download malicious archive “Заборгованість по ЖКП.rar”

A series of steps must take place for the download to successfully occur:

  • The target clicks the green button on the actor’s GitHub page hxxps[:]//komunalka.github[.]io
  • The target’s device sends an HTTP POST request to the Cloudflare Worker worker-polished-union-f396[.]vqu89698[.]workers[.]dev with the HTTP request body set to “user=Iahhdr”
  • The Cloudflare Worker processes the request and evaluates the HTTP request body
  • If the request conditions are met, the Worker fetches the RAR file from hxxps[:]//raw[.]githubusercontent[.]com/kudoc8989/project/main/Заборгованість по ЖКП.rar, which is then downloaded on the target’s device

Cloudforce One identified the infrastructure responsible for facilitating the download of the malicious RAR file and remediated the actor-associated Worker, preventing FlyingYeti from delivering its malicious tooling. In an effort to circumvent Cloudforce One’s mitigation measures, FlyingYeti later changed their malware delivery method. Instead of the Workers domain fetching the malicious RAR file, it was loaded directly from GitHub.

Analysis of the malicious RAR file

During remediation, Cloudforce One recovered the RAR file “Заборгованість по ЖКП.rar” and performed analysis of the malicious payload. The downloaded RAR archive contains multiple files, including a file with a name that contains the unicode character “U+201F”. This character appears as whitespace on Windows devices and can be used to “hide” file extensions by adding excessive whitespace between the filename and the file extension. As highlighted in blue in Figure 2, this cleverly named file within the RAR archive appears to be a PDF document but is actually a malicious CMD file (“Рахунок на оплату.pdf[unicode character U+201F].cmd”).

Figure 2: Files contained in the malicious RAR archive “Заборгованість по ЖКП.rar” (“Housing Debt.rar”)

FlyingYeti included a benign PDF in the archive with the same name as the CMD file but without the unicode character, “Рахунок на оплату.pdf” (“Invoice for payment.pdf”). Additionally, the directory name for the archive once decompressed also contained the name “Рахунок на оплату.pdf”. This overlap in names of the benign PDF and the directory allows the actor to exploit the WinRAR vulnerability CVE-2023-38831. More specifically, when an archive includes a benign file with the same name as the directory, the entire contents of the directory are opened by the WinRAR application, resulting in the execution of the malicious CMD. In other words, when the target believes they are opening the benign PDF “Рахунок на оплату.pdf”, the malicious CMD file is executed.

The CMD file contains the FlyingYeti PowerShell malware known as COOKBOX. The malware is designed to persist on a host, serving as a foothold in the infected device. Once installed, this variant of COOKBOX will make requests to the DDNS domain postdock[.]serveftp[.]com for C2, awaiting PowerShell cmdlets that the malware will subsequently run.

Alongside COOKBOX, several decoy documents are opened, which contain hidden tracking links using the Canary Tokens service. The first document, shown in Figure 3 below, poses as an agreement under which debt for housing and utility services will be restructured.

Figure 3: Decoy document Реструктуризація боргу за житлово комунальні послуги.docx

The second document (Figure 4) is a user agreement outlining the terms and conditions for the usage of the payment platform komunalka[.]ua.

Figure 4: Decoy document Угода користувача.docx (User Agreement.docx)

The use of relevant decoy documents as part of the phishing and delivery activity are likely an effort by FlyingYeti operators to increase the appearance of legitimacy of their activities.

The phishing theme we identified in this campaign is likely one of many themes leveraged by this actor in a larger operation to target Ukrainian entities, in particular their defense forces. In fact, the threat activity we detailed in this blog uses many of the same techniques outlined in a recent FlyingYeti campaign disclosed by CERT-UA in mid-April 2024, where the actor leveraged United Nations-themed lures involving Peace Support Operations to target Ukraine’s military. Due to Cloudforce One’s defensive actions covered in the next section, this latest FlyingYeti campaign was prevented as of the time of publication.

Mitigating FlyingYeti activity

Cloudforce One mitigated FlyingYeti’s campaign through a series of actions. Each action was taken to increase the actor’s cost of continuing their operations. When assessing which action to take and why, we carefully weighed the pros and cons in order to provide an effective active defense strategy against this actor. Our general goal was to increase the amount of time the threat actor spent trying to develop and weaponize their campaign.

We were able to successfully extend the timeline of the threat actor’s operations from hours to weeks. At each interdiction point, we assessed the impact of our mitigation to ensure the actor would spend more time attempting to launch their campaign. Our mitigation measures disrupted the actor’s activity, in one instance resulting in eight additional hours spent on debugging code.

Due to our proactive defense efforts, FlyingYeti operators adapted their tactics multiple times in their attempts to launch the campaign. The actor originally intended to have the Cloudflare Worker fetch the malicious RAR file from GitHub. After Cloudforce One interdiction of the Worker, the actor attempted to create additional Workers via a new account. In response, we disabled all Workers, leading the actor to load the RAR file directly from GitHub. Cloudforce One notified GitHub, resulting in the takedown of the RAR file, the GitHub project, and suspension of the account used to host the RAR file. In return, FlyingYeti began testing the option to host the RAR file on the file sharing sites pixeldrain and Filemail, where we observed the actor alternating the link on the Komunalka phishing site between the following:

  • hxxps://pixeldrain[.]com/api/file/ZAJxwFFX?download=one
  • hxxps://1014.filemail[.]com/api/file/get?filekey=e_8S1HEnM5Rzhy_jpN6nL-GF4UAP533VrXzgXjxH1GzbVQZvmpFzrFA&pk_vid=a3d82455433c8ad11715865826cf18f6

We notified GitHub of the actor’s evolving tactics, and in response GitHub removed the Komunalka phishing site. After analyzing the files hosted on pixeldrain and Filemail, we determined the actor uploaded dummy payloads, likely to monitor access to their phishing infrastructure (FileMail logs IP addresses, and both file hosting sites provide view and download counts). At the time of publication, we did not observe FlyingYeti upload the malicious RAR file to either file hosting site, nor did we identify the use of alternative phishing or malware delivery methods.

A timeline of FlyingYeti’s activity and our corresponding mitigations can be found below.

Event timeline

Date Event Description
2024-04-18 12:18 Threat Actor (TA) creates a Worker to handle requests from a phishing site
2024-04-18 14:16 TA creates phishing site komunalka[.]github[.]io on GitHub
2024-04-25 12:25 TA creates a GitHub repo to host a RAR file
2024-04-26 07:46 TA updates the first Worker to handle requests from users visiting komunalka[.]github[.]io
2024-04-26 08:24 TA uploads a benign test RAR to the GitHub repo
2024-04-26 13:38 Cloudforce One identifies a Worker receiving requests from users visiting komunalka[.]github[.]io, observes its use as a phishing page
2024-04-26 13:46 Cloudforce One identifies that the Worker fetches a RAR file from GitHub (the malicious RAR payload is not yet hosted on the site)
2024-04-26 19:22 Cloudforce One creates a detection to identify the Worker that fetches the RAR
2024-04-26 21:13 Cloudforce One deploys real-time monitoring of the RAR file on GitHub
2024-05-02 06:35 TA deploys a weaponized RAR (CVE-2023-38831) to GitHub with their COOKBOX malware packaged in the archive
2024-05-06 10:03 TA attempts to update the Worker with link to weaponized RAR, the Worker is immediately blocked
2024-05-06 10:38 TA creates a new Worker, the Worker is immediately blocked
2024-05-06 11:04 TA creates a new account (#2) on Cloudflare
2024-05-06 11:06 TA creates a new Worker on account #2 (blocked)
2024-05-06 11:50 TA creates a new Worker on account #2 (blocked)
2024-05-06 12:22 TA creates a new modified Worker on account #2
2024-05-06 16:05 Cloudforce One disables the running Worker on account #2
2024-05-07 22:16 TA notices the Worker is blocked, ceases all operations
2024-05-07 22:18 TA deletes original Worker first created to fetch the RAR file from the GitHub phishing page
2024-05-09 19:28 Cloudforce One adds phishing page komunalka[.]github[.]io to real-time monitoring
2024-05-13 07:36 TA updates the github.io phishing site to point directly to the GitHub RAR link
2024-05-13 17:47 Cloudforce One adds COOKBOX C2 postdock[.]serveftp[.]com to real-time monitoring for DNS resolution
2024-05-14 00:04 Cloudforce One notifies GitHub to take down the RAR file
2024-05-15 09:00 GitHub user, project, and link for RAR are no longer accessible
2024-05-21 08:23 TA updates Komunalka phishing site on github.io to link to pixeldrain URL for dummy payload (pixeldrain only tracks view and download counts)
2024-05-21 08:25 TA updates Komunalka phishing site to link to FileMail URL for dummy payload (FileMail tracks not only view and download counts, but also IP addresses)
2024-05-21 12:21 Cloudforce One downloads PixelDrain document to evaluate payload
2024-05-21 12:47 Cloudforce One downloads FileMail document to evaluate payload
2024-05-29 23:59 GitHub takes down Komunalka phishing site
2024-05-30 13:00 Cloudforce One publishes the results of this investigation

Coordinating our FlyingYeti response

Cloudforce One leveraged industry relationships to provide advanced warning and to mitigate the actor’s activity. To further protect the intended targets from this phishing threat, Cloudforce One notified and collaborated closely with GitHub’s Threat Intelligence and Trust and Safety Teams. We also notified CERT-UA and Cloudflare industry partners such as CrowdStrike, Mandiant/Google Threat Intelligence, and Microsoft Threat Intelligence.

Hunting FlyingYeti operations

There are several ways to hunt FlyingYeti in your environment. These include using PowerShell to hunt for WinRAR files, deploying Microsoft Sentinel analytics rules, and running Splunk scripts as detailed below. Note that these detections may identify activity related to this threat, but may also trigger unrelated threat activity.

PowerShell hunting

Consider running a PowerShell script such as this one in your environment to identify exploitation of CVE-2023-38831. This script will interrogate WinRAR files for evidence of the exploit.

CVE-2023-38831
Description:winrar exploit detection 
open suspios (.tar / .zip / .rar) and run this script to check it 

function winrar-exploit-detect(){
$targetExtensions = @(".cmd" , ".ps1" , ".bat")
$tempDir = [System.Environment]::GetEnvironmentVariable("TEMP")
$dirsToCheck = Get-ChildItem -Path $tempDir -Directory -Filter "Rar*"
foreach ($dir in $dirsToCheck) {
    $files = Get-ChildItem -Path $dir.FullName -File
    foreach ($file in $files) {
        $fileName = $file.Name
        $fileExtension = [System.IO.Path]::GetExtension($fileName)
        if ($targetExtensions -contains $fileExtension) {
            $fileWithoutExtension = [System.IO.Path]::GetFileNameWithoutExtension($fileName); $filename.TrimEnd() -replace '\.$'
            $cmdFileName = "$fileWithoutExtension"
            $secondFile = Join-Path -Path $dir.FullName -ChildPath $cmdFileName
            
            if (Test-Path $secondFile -PathType Leaf) {
                Write-Host "[!] Suspicious pair detected "
                Write-Host "[*]  Original File:$($secondFile)" -ForegroundColor Green 
                Write-Host "[*] Suspicious File:$($file.FullName)" -ForegroundColor Red

                # Read and display the content of the command file
                $cmdFileContent = Get-Content -Path $($file.FullName)
                Write-Host "[+] Command File Content:$cmdFileContent"
            }
        }
    }
}
}
winrar-exploit-detect

Microsoft Sentinel

In Microsoft Sentinel, consider deploying the rule provided below, which identifies WinRAR execution via cmd.exe. Results generated by this rule may be indicative of attack activity on the endpoint and should be analyzed.

DeviceProcessEvents
| where InitiatingProcessParentFileName has @"winrar.exe"
| where InitiatingProcessFileName has @"cmd.exe"
| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, AccountName
| sort by Timestamp desc

Splunk

Consider using this script in your Splunk environment to look for WinRAR CVE-2023-38831 execution on your Microsoft endpoints. Results generated by this script may be indicative of attack activity on the endpoint and should be analyzed.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name=winrar.exe `windows_shells` OR Processes.process_name IN ("certutil.exe","mshta.exe","bitsadmin.exe") by Processes.dest Processes.user Processes.parent_process_name Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id 
| `drop_dm_object_name(Processes)` 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `winrar_spawning_shell_application_filter`

Cloudflare product detections

Cloudflare Email Security

Cloudflare Email Security (CES) customers can identify FlyingYeti threat activity with the following detections.

  • CVE-2023-38831
  • FLYINGYETI.COOKBOX
  • FLYINGYETI.COOKBOX.Launcher
  • FLYINGYETI.Rar

Recommendations

Cloudflare recommends taking the following steps to mitigate this type of activity:

  • Implement Zero Trust architecture foundations:    
  • Deploy Cloud Email Security to ensure that email services are protected against phishing, BEC and other threats
  • Leverage browser isolation to separate messaging applications like LinkedIn, email, and Signal from your main network
  • Scan, monitor and/or enforce controls on specific or sensitive data moving through your network environment with data loss prevention policies
  • Ensure your systems have the latest WinRAR and Microsoft security updates installed
  • Consider preventing WinRAR files from entering your environment, both at your Cloud Email Security solution and your Internet Traffic Gateway
  • Run an Endpoint Detection and Response (EDR) tool such as CrowdStrike or Microsoft Defender for Endpoint to get visibility into binary execution on hosts
  • Search your environment for the FlyingYeti indicators of compromise (IOCs) shown below to identify potential actor activity within your network.

If you’re looking to uncover additional Threat Intelligence insights for your organization or need bespoke Threat Intelligence information for an incident, consider engaging with Cloudforce One by contacting your Customer Success manager or filling out this form.

Indicators of Compromise

Filename SHA256 Hash Description
Заборгованість по ЖКП.rar a0a294f85c8a19be048ffcc05ede6fd5a7ac5e2f0032a3ca0050dc1ae960c314 RAR archive
Рахунок на оплату.pdf
                                                                                 .cmd
0cca8f795c7a81d33d36d5204fcd9bc73bdc2af7de315c1449cbc3551ef4fb59 COOKBOX Sample (contained in RAR archive)
Реструктуризація боргу за житлово комунальні послуги.docx 915721b94e3dffa6cef3664532b586be6cf989fec923b26c62fdaf201ee81d2c Benign Word Document with Tracking Link (contained in RAR archive)
Угода користувача.docx 79a9740f5e5ea4aa2157d9d96df34ee49a32e2d386fe55fedfd1aa33e151c06d Benign Word Document with Tracking Link (contained in RAR archive)
Рахунок на оплату.pdf 19e25456c2996ded3e29577b609de54a2bef90dad8f868cdad795c18df05a79b Random Binary Data (contained in RAR archive)
Заборгованість по ЖКП станом на 26.04.24.docx e0d65e2d36afd3db1b603f10e0488cee3f58ade24d8abc6bee240314d8696708 Random Binary Data (contained in RAR archive)
Domain / URL Description
komunalka[.]github[.]io Phishing page
hxxps[:]//github[.]com/komunalka/komunalka[.]github[.]io Phishing page
hxxps[:]//worker-polished-union-f396[.]vqu89698[.]workers[.]dev Worker that fetches malicious RAR file
hxxps[:]//raw[.]githubusercontent[.]com/kudoc8989/project/main/Заборгованість по ЖКП.rar Delivery of malicious RAR file
hxxps[:]//1014[.]filemail[.]com/api/file/get?filekey=e_8S1HEnM5Rzhy_jpN6nL-GF4UAP533VrXzgXjxH1GzbVQZvmpFzrFA&pk_vid=a3d82455433c8ad11715865826cf18f6 Dummy payload
hxxps[:]//pixeldrain[.]com/api/file/ZAJxwFFX?download= Dummy payload
hxxp[:]//canarytokens[.]com/stuff/tags/ni1cknk2yq3xfcw2al3efs37m/payments.js Tracking link
hxxp[:]//canarytokens[.]com/stuff/terms/images/k22r2dnjrvjsme8680ojf5ccs/index.html Tracking link
postdock[.]serveftp[.]com COOKBOX C2

Celebrating Excellence: Joanne Guarglia and Kelly Hiscoe Recognized as CRN’s 2024 Women of the Channel

Post Syndicated from Rapid7 original https://blog.rapid7.com/2024/05/30/celebrating-excellence-joanne-guarglia-and-kelly-hiscoe-recognized-as-crns-2024-women-of-the-channel/

Celebrating Excellence: Joanne Guarglia and Kelly Hiscoe Recognized as CRN's 2024 Women of the Channel

We are thrilled to announce that two of our exceptional team members, Joanne Guarglia and Kelly Hiscoe, have been recognized as CRN’s 2024 Women of the Channel. This recognition celebrates the achievements and leadership of women within the channel community, and we are incredibly proud to see Joanne and Kelly honored for their contributions.

Kelly Hiscoe: Driving innovation in partner programs

Kelly Hiscoe and her team are at the forefront of designing and launching partner programs, optimizing our operations to support Rapid7’s global channel ecosystem. Their commitment to creating highly effective and streamlined partner experiences ensures seamless execution within our channel. Engaging continuously with partners, Kelly’s team drives simplified, scalable, and predictable experiences that benefit all stakeholders.

Kelly’s dedication to improving our operational infrastructure and incentive programs is unwavering. Kelly said: “We will never be done focusing on creating improved programs and processes. We will continue to be laser focused on enhancing our operational infrastructure and incentive programs because we care deeply about the partner experience with Rapid7.”

Her leadership and vision are integral to our ongoing success and the satisfaction of our partners.

Celebrating Excellence: Joanne Guarglia and Kelly Hiscoe Recognized as CRN's 2024 Women of the Channel
Kelly Hiscoe

Joanne Guarglia: Building lasting relationships

Joanne Guarglia has demonstrated exceptional skill in building and nurturing lasting relationships with our partners, an area in which Rapid7 are investing heavily –  making strides with the channel community more than ever.

“What I enjoy most is being able to build lasting relationships with our partners. Partners want to work with trusted brands who are leaders in the space, and we have that here at Rapid7. Being that trusted voice and growing the relationship, while educating them about our offerings, enables me to have a positive impact,” Joanne said.

Her dedication to partner success and her ability to educate and inform are key components of her impactful work.

Celebrating Excellence: Joanne Guarglia and Kelly Hiscoe Recognized as CRN's 2024 Women of the Channel
Joanne Guariglia

Commitment to excellence

At Rapid7, we are committed to fostering an environment where talented individuals like Joanne and Kelly can thrive. Their recognition as CRN’s 2024 Women of the Channel underscores our dedication to excellence and our focus on building a strong, supportive channel ecosystem. We look forward to their continued contributions and to the ongoing success of our partners.

Please join us in celebrating Joanne and Kelly for their outstanding achievements and their unwavering commitment to excellence in the channel community.

Learn more about Rapid7 global partnerships here.