Security updates for Wednesday

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

Security updates have been issued by Debian (h2o, open-vm-tools, pmix, and zookeeper), Gentoo (GitPython), Oracle (firefox, java-11-openjdk, java-17-openjdk, libguestfs-winsupport, nginx:1.22, and thunderbird), Red Hat (samba), SUSE (container-suseconnect, libsndfile, and slurm), and Ubuntu (krb5, linux, linux-aws, linux-aws-5.15, linux-azure, linux-azure-5.15,
linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gcp-5.15,
linux-gkeop, linux-gkeop-5.15, linux-hwe-5.15, linux-ibm, linux-ibm-5.15,
linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia,
linux-oracle, linux-oracle-5.15, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4,
linux-bluefield, linux-gcp, linux-gcp-5.4, linux-gkeop, linux-hwe-5.4,
linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4,
linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp, linux, linux-aws, linux-aws-6.2, linux-azure, linux-azure-6.2,
linux-azure-fde-6.2, linux-gcp, linux-gcp-6.2, linux-hwe-6.2, linux-kvm,
linux-lowlatency, linux-lowlatency-hwe-6.2, linux-oracle, linux-raspi,
linux-starfive, linux-laptop, linux-nvidia-6.2, linux-oem-6.1, linux-raspi, open-vm-tools, and xorg-server).

Урок по финанси – как се оценя общински бюджет, в случая на Община Родопи

Post Syndicated from VassilKendov original https://kendov.com/%D1%83%D1%80%D0%BE%D0%BA-%D0%BF%D0%BE-%D1%84%D0%B8%D0%BD%D0%B0%D0%BD%D1%81%D0%B8-%D0%BA%D0%B0%D0%BA-%D1%81%D0%B5-%D0%BE%D1%86%D0%B5%D0%BD%D1%8F-%D0%BE%D0%B1%D1%89%D0%B8%D0%BD%D1%81%D0%BA%D0%B8/

Сега когато предизборната кампнаия премина и вотът на Хората от Община Родопи беше повече от ясен е време да се отърсим от предизборното говорене и да започнем да мислим трезво.

Първо да честитим на г-н Павел Михайлов новия мандат и наред с това да започнем да обръщаме внимание на злободневните проблеми.

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

Тази година той беше планиран в размер на 55.7 млн лева.

Миналата година беше в размер на 44.8 млн лева.

Миналата година беше в размер на 44.8 млн лева.

Как обаче се прави връзка между двата бюджета? Разбира се чрез изпълнението. Защото ако нямаме изпълнение, единствения начин е да изпълним обещанията чрез теглене на кредит, както го и направихме.

Бюджет 2022 беше изпълнен на 55%. Прилагам някой снимки.

Пимерно в Бюджет 2022, приходите от данък МПС са заложени 2.2 млн, от който сме изпълнили 2.1 млн. Смея да твърдя доста добро изпълнение. Знаете ли защо? Защото не можете да минете преглед, ако не сте си платили данъка. Този данък е доста добре прогнозируем по тази причина. Затова за 2023г. общината е заложила 3.1 млн. приходи.
Преведено на прост език – ще увеличим данъка или очакваме в рамките на една година, автомобилите да се увеличат с 50%. Тоест всяко второ семейство да си купи по още един автомобил, без да спира от движение съществуващия.
Или разбира се да се почви инвеститор, който да регистрира фирмата си с хиляди автомобили в Общиа Родопи. Ще бъде интересно да видим отчета за 2023 на тези приходи.

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

За 2022г са планирани 701 500лв, събрани са 181 900 лева, тоест едва 26%. Пак казвам, тук събираемостта е пряко свързана с дейността на администрацията. Въпреки тази ниска събираемост за 2023 сме заложили приходи от 746 600 лв. Тоест увеличение на приходите с 6% при положение, че предходната година си събрал едва 26% от планираното.

С нетърпение очаквам да ме опровергаят в очакванията ми, че тази година по това перо пак изпълнението ще бъде близко до 26%, че и по-малко.

Ето така се раздува бюджета – със заложени неизпълними приходи. Понеже няма санкция за неизпълнението, а само аз задавам някакви въпроси на обсъжданията, администрацията може да си позволи да не си дава много зор в изпълнението. Все пак кредита в края на мандата винаги е опция. Поне до едно време, когато станем свръхзадлъжнели, но до този момент има още време.
Едно е сигурно – следващата година няма да има много нови улици и LED лампи. Поне не без кредит. Виж ако изтеглим още 7 млн. ще е различно.
А Брестовчани могат да си чакат техните 25 млн за смяна на водопроводната мрежа. При този бюджет и това изпълнение аз не го виждам. Освен ако разбира се държавата не помогне. Но при Централна власт доминирана от ГЕРБ и ПП-ДБ, и при кмет на Родопи от  БСП, това ще е малко вероятно според мен. Още повече, че Брестовица са се засилили да изберат и селски кмет също от БСП.
Както се казва дано да греша и централната власт да не работи на принципа – Отпускам пари само ако мога да си направя PR или ако са гласували за мен. Дано също така да са сменени тръбите под новия площад в Брестовица, че ако трябва после да го копаем… язък ни за барута.

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

Следвайте ме за още финансови уроци, свързани с бюджета на китната Община Родопи

Васил Кендов – патологичен финансист

За  срещa с мен моля използвайте посочената форма.

[contact-form-7]

The post Урок по финанси – как се оценя общински бюджет, в случая на Община Родопи appeared first on Kendov.com.

За джендъра на машините, или за активните мероприятия

Post Syndicated from Светла Енчева original https://www.toest.bg/za-djendura-na-mashinite-i-za-aktivnite-meropriyatiya/

За джендъра на машините, или за активните мероприятия

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

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

Не е случайност

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

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

Може би се питате за какво му е било на зам.-министъра Михаил Стойнов да снима (публичен) код с телефона си, и си задавате въпроси и за други странности, съпровождащи скандала. Но мислите ли, че една акция, при която действат в синхрон ДАНС, 5 от 6 парламентарно представени партии и ЦИК, нямаше да се осъществи, ако Стойнов не беше снимал? Тогава щеше да има нещо друго, независимо колко нелепо. Например бръкнал си е в джоба, където може би крие нещо, заплашващо сигурността на вота, а с това и цялата национална сигурност. Ето, Върховният административен съд видя различен проблем – машините за гласуване не били удостоверени от когото трябва.

История за университет, джоб и инфаркт

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

И така, годината е 2008-ма, мястото е Югозападният университет (ЮЗУ) в Благоевград. Съдът тъкмо е отменил второто уволнение на преподавател на име Петър Дошков. Него все го уволняват, защото е чепат и се бори с корупцията в университета. Особено с вече покойния декан на Правно-историческия факултет Александър Воденичаров, който де факто управлява университета. Между другото, продукт на същия факултет е и Делян Пеевски. Към онзи момент Воденичаров е бивш говорител на Висшия съдебен съвет и виден тимаджия, има свое лоби в парламента и кара незаконен трети мандат.

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

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

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

На третия ден Петър Дошков се връща в родното си село, където в следващите три години продължава битките си с ЮЗУ. Докато един ден просто получава инфаркт и умира на 50-годишна възраст.

Да целиш танк с прашка

Няма смисъл да продължаваме да обсъждаме конкретното активно мероприятие със зам.-министъра Михаил Стойнов. Проблемът не е какво е направил или не е направил той, а защо не можем ефективно да се противопоставяме на активните мероприятия.

Да вземем за пример друго такова мероприятие – кампанията срещу Истанбулската конвенция. Колкото и логични аргументи да се привеждаха и колкото и да се обясняваше абсурдността на превратното тълкуване на термина „джендър“, всички усилия останаха глас в пустиня. Стигна се до три решения на две висши съдилища – две на Конституционния и едно на Върховния касационен съд, които юридически бетонираха целия нонсенс. От това пострадаха не само преживелите домашно насилие и ЛГБТ+ хората, а и неправителственият сектор и академичните изследователи, работещи в до този момент безобидна област, която внезапно беше превърната в скандална и незаконна.

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

Последствията от затварянето на очите

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

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

Също толкова сериозен проблем е безкритичността на голяма част от медиите, особено на най-популярните от тях – националните телевизии. Ретранслирането на опорните точки на силните на деня без контекст, без проверка на фактите, без въпроси не е журналистика. Нито „отразяването“ на една и съща новина от максимален брой репортери, без нито един от тях да се опитва да разбере и покаже нещо повече от това, което официално му се казва. Още по-малко пък демонстративният отказ да се разберат елементарни неща, ако те противоречат на актуалната популистка реторика. Така например вече 15 години преди всеки „София прайд“ активисти трябва да отговарят в едни и същи телевизионни студиа на водещи, които казват: „Не разбирам защо парадирате.“

Ето така, като няма кой да се противопоставя, активните мероприятия се множат и стават все по-безочливи.

Този път е по-различно

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

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

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

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

Поуката

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

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

Единственият начин това да не стане е, ако използваме думите на Стивън Хокинг, да продължаваме да говорим. Нека си припомним изговорените с електронния му глас думи, станали част от песента „Keep Talking“ на Pink Floyd:

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

Имаме остра нужда от яснота и проницателност. Разговор с Галин Стоев

Post Syndicated from Стефан Иванов original https://www.toest.bg/imame-ostra-nuzhda-ot-yasnota-i-pronitsatielnost-razgovor-s-galin-stoev/

Имаме остра нужда от яснота и проницателност. Разговор с Галин Стоев

Преди „Хага“ по-скоро не сте правил политически театър?

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

Защо?

Тогава бяхме тийнейджъри и това е моментът, в който започваш да си задаваш малко по-конкретни въпроси: в какво живееш, в какъв тип общество и политическа среда? По онова време имаше няколко интересни движения, свързани най-вече с „Екогласност“, с дисидентската идея, и на тази възраст на човек му става интересно да се порови малко повече. Имах шанса да бъда част от поколение, което се оказа на площадката, когато една система сменяше друга, и ние бяхме абсолютно неподготвени, нямахме абсолютно никаква политическа култура. Населението масово нямаше такава. Имаше идеологеми, които не се поставяха под въпрос. Сблъскахме се с нов начин, по който трябваше да декодираме света и да се учим да бъдем свободни.

Това незнание даде ли повече свобода?

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

Как протече за Вас този период на учене от 90-те до днес?

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

Този сблъсък със свободния свят – защото прекарах доста време в Англия, Германия, Белгия и Франция – също разтърси едни дълбоки устои и представи, които имах, за това кои сме ние, къде сме, за какво се борим и към какво се стремим.

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

Днес възможно ли е това наваксване, ако погледът е обърнат в по-човешка и морална посока?

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

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

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

В този ред на мисли според Вас към днешна дата България колонизирана, деколонизирана или държава в процес на деколонизация е?

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

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

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

Каква би била разликата между постановки на „Хага“ във Франция и в България?

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

Като урок по човекознание, като антропология?

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

Разказвачът в „Хага“ е дете, тийнейджър може би, но е и нещо повече, нали?

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

Как бихте разказал за какво става въпрос в „Хага“, на български или руски тийнейджър, или на дете?

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

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

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

Има текстове като „Образ и подобие“ на Радичков или „Персифедрон“ на Константин Павлов, но сякаш политическият театър и драматургия в България все още остават периферни?

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

Как тогава може да съществува мир в България?

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

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

Да разбираме, че Вие сте – по някакъв начин – стоически обнадежден?

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

И от честност и искреност може би?

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

Why ACPI?

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

“Why does ACPI exist” – – the greatest thread in the history of forums, locked by a moderator after 12,239 pages of heated debate, wait no let me start again.

Why does ACPI exist? In the beforetimes power management on x86 was done by jumping to an opaque BIOS entry point and hoping it would do the right thing. It frequently didn’t. We called this Advanced Power Management (Advanced because before this power management involved custom drivers for every machine and everyone agreed that this was a bad idea), and it involved the firmware having to save and restore the state of every piece of hardware in the system. This meant that assumptions about hardware configuration were baked into the firmware – failed to program your graphics card exactly the way the BIOS expected? Hurrah! It’s only saved and restored a subset of the state that you configured and now potential data corruption for you. The developers of ACPI made the reasonable decision that, well, maybe since the OS was the one setting state in the first place, the OS should restore it.

So far so good. But some state is fundamentally device specific, at a level that the OS generally ignores. How should this state be managed? One way to do that would be to have the OS know about the device specific details. Unfortunately that means you can’t ship the computer without having OS support for it, which means having OS support for every device (exactly what we’d got away from with APM). This, uh, was not an option the PC industry seriously considered. The alternative is that you ship something that abstracts the details of the specific hardware and makes that abstraction available to the OS. This is what ACPI does, and it’s also what things like Device Tree do. Both provide static information about how the platform is configured, which can then be consumed by the OS and avoid needing device-specific drivers or configuration to be built-in.

The main distinction between Device Tree and ACPI is that Device Tree is purely a description of the hardware that exists, and so still requires the OS to know what’s possible – if you add a new type of power controller, for instance, you need to add a driver for that to the OS before you can express that via Device Tree. ACPI decided to include an interpreted language to allow vendors to expose functionality to the OS without the OS needing to know about the underlying hardware. So, for instance, ACPI allows you to associate a device with a function to power down that device. That function may, when executed, trigger a bunch of register accesses to a piece of hardware otherwise not exposed to the OS, and that hardware may then cut the power rail to the device to power it down entirely. And that can be done without the OS having to know anything about the control hardware.

How is this better than just calling into the firmware to do it? Because the fact that ACPI declares that it’s going to access these registers means the OS can figure out that it shouldn’t, because it might otherwise collide with what the firmware is doing. With APM we had no visibility into that – if the OS tried to touch the hardware at the same time APM did, boom, almost impossible to debug failures (This is why various hardware monitoring drivers refuse to load by default on Linux – the firmware declares that it’s going to touch those registers itself, so Linux decides not to in order to avoid race conditions and potential hardware damage. In many cases the firmware offers a collaborative interface to obtain the same data, and a driver can be written to get that. this bug comment discusses this for a specific board)

Unfortunately ACPI doesn’t entirely remove opaque firmware from the equation – ACPI methods can still trigger System Management Mode, which is basically a fancy way to say “Your computer stops running your OS, does something else for a while, and you have no idea what”. This has all the same issues that APM did, in that if the hardware isn’t in exactly the state the firmware expects, bad things can happen. While historically there were a bunch of ACPI-related issues because the spec didn’t define every single possible scenario and also there was no conformance suite (eg, should the interpreter be multi-threaded? Not defined by spec, but influences whether a specific implementation will work or not!), these days overall compatibility is pretty solid and the vast majority of systems work just fine – but we do still have some issues that are largely associated with System Management Mode.

One example is a recent Lenovo one, where the firmware appears to try to poke the NVME drive on resume. There’s some indication that this is intended to deal with transparently unlocking self-encrypting drives on resume, but it seems to do so without taking IOMMU configuration into account and so things explode. It’s kind of understandable why a vendor would implement something like this, but it’s also kind of understandable that doing so without OS cooperation may end badly.

This isn’t something that ACPI enabled – in the absence of ACPI firmware vendors would just be doing this unilaterally with even less OS involvement and we’d probably have even more of these issues. Ideally we’d “simply” have hardware that didn’t support transitioning back to opaque code, but we don’t (ARM has basically the same issue with TrustZone). In the absence of the ideal world, by and large ACPI has been a net improvement in Linux compatibility on x86 systems. It certainly didn’t remove the “Everything is Windows” mentality that many vendors have, but it meant we largely only needed to ensure that Linux behaved the same way as Windows in a finite number of ways (ie, the behaviour of the ACPI interpreter) rather than in every single hardware driver, and so the chances that a new machine will work out of the box are much greater than they were in the pre-ACPI period.

There’s an alternative universe where we decided to teach the kernel about every piece of hardware it should run on. Fortunately (or, well, unfortunately) we’ve seen that in the ARM world. Most device-specific simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you?

It’s understandable why ACPI has a poor reputation. But it’s also hard to figure out what would work better in the real world. We could have built something similar on top of Open Firmware instead but the distinction wouldn’t be terribly meaningful – we’d just have Forth instead of the ACPI bytecode language. Longing for a non-ACPI world without presenting something that’s better and actually stands a reasonable chance of adoption doesn’t make the world a better place.

comment count unavailable comments

NVIDIA L40S is the NVIDIA H100 AI Alternative with a Big Benefit

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/nvidia-l40s-is-the-nvidia-h100-ai-alternative-with-a-big-benefit-supermicro/

We delve into the NVIDIA L40S versus the NVIDIA H100 PCIe and discuss the differences and why the L40S should be the go-to GPU for many today

The post NVIDIA L40S is the NVIDIA H100 AI Alternative with a Big Benefit appeared first on ServeTheHome.

Announcing Amazon EC2 Capacity Blocks for ML to reserve GPU capacity for your machine learning workloads

Post Syndicated from Channy Yun original https://aws.amazon.com/blogs/aws/announcing-amazon-ec2-capacity-blocks-for-ml-to-reserve-gpu-capacity-for-your-machine-learning-workloads/

Recent advancements in machine learning (ML) have unlocked opportunities for customers across organizations of all sizes and industries to reinvent new products and transform their businesses. However, the growth in demand for GPU capacity to train, fine-tune, experiment, and inference these ML models has outpaced industry-wide supply, making GPUs a scarce resource. Access to GPU capacity is an obstacle for customers whose capacity needs fluctuate depending on the research and development phase they’re in.

Today, we are announcing Amazon Elastic Compute Cloud (Amazon EC2) Capacity Blocks for ML, a new Amazon EC2 usage model that further democratizes ML by making it easy to access GPU instances to train and deploy ML and generative AI models. With EC2 Capacity Blocks, you can reserve hundreds of GPUs collocated in EC2 UltraClusters designed for high-performance ML workloads, using Elastic Fabric Adapter (EFA) networking in a peta-bit scale non-blocking network, to deliver the best network performance available in Amazon EC2.

This is an innovative new way to schedule GPU instances where you can reserve the number of instances you need for a future date for just the amount of time you require. EC2 Capacity Blocks are currently available for Amazon EC2 P5 instances powered by NVIDIA H100 Tensor Core GPUs in the AWS US East (Ohio) Region. With EC2 Capacity Blocks, you can reserve GPU instances in just a few clicks and plan your ML development with confidence. EC2 Capacity Blocks make it easy for anyone to predictably access EC2 P5 instances that offer the highest performance in EC2 for ML training.

EC2 Capacity Block reservations work similarly to hotel room reservations. With a hotel reservation, you specify the date and duration you want your room for and the size of beds you’d like─a queen bed or king bed, for example. Likewise, with EC2 Capacity Block reservations, you select the date and duration you require GPU instances and the size of the reservation (the number of instances). On your reservation start date, you’ll be able to access your reserved EC2 Capacity Block and launch your P5 instances. At the end of the EC2 Capacity Block duration, any instances still running will be terminated.

You can use EC2 Capacity Blocks when you need capacity assurance to train or fine-tune ML models, run experiments, or plan for future surges in demand for ML applications. Alternatively, you can continue using On-Demand Capacity Reservations for all other workload types that require compute capacity assurance, such as business-critical applications, regulatory requirements, or disaster recovery.

Getting started with Amazon EC2 Capacity Blocks for ML
To reserve your Capacity Blocks, choose Capacity Reservations on the Amazon EC2 console in the US East (Ohio) Region. You can see two capacity reservation options. Select Purchase Capacity Blocks for ML and then Get started to start looking for an EC2 Capacity Block.

Choose your total capacity and specify how long you need the EC2 Capacity Block. You can reserve an EC2 Capacity Block in the following sizes: 1, 2, 4, 8, 16, 32, or 64 p5.48xlarge instances. The total number of days that you can reserve EC2 Capacity Blocks is 1– 14 days in 1-day increments. EC2 Capacity Blocks can be purchased up to 8 weeks in advance.

EC2 Capacity Block prices are dynamic and depend on total available supply and demand at the time you purchase the EC2 Capacity Block. You can adjust the size, duration, or date range in your specifications to search for other EC2 Capacity Block options. When you select Find Capacity Blocks, AWS returns the lowest-priced offering available that meets your specifications in the date range you have specified. At this point, you will be shown the price for the EC2 Capacity Block.

After reviewing EC2 Capacity Blocks details, tags, and total price information, choose Purchase. The total price of an EC2 Capacity Block is charged up front, and the price does not change after purchase. The payment will be billed to your account within 12 hours after you purchase the EC2 Capacity Blocks.

All EC2 Capacity Blocks reservations start at 11:30 AM Coordinated Universal Time (UTC). EC2 Capacity Blocks can’t be modified or canceled after purchase.

You can also use AWS Command Line Interface (AWS CLI) and AWS SDKs to purchase EC2 Capacity Blocks. Use the describe-capacity-block-offerings API to provide your cluster requirements and discover an available EC2 Capacity Block for purchase.

$ aws ec2 describe-capacity-block-offerings \
          --instance-type p5.48xlarge \
          --instance-count 4 \
          --start-date-range 2023-10-30T00:00:00Z \
          --end-date-range 2023-11-01T00:00:00Z \
          –-capacity-duration 48

After you find an available EC2 Capacity Block with the CapacityBlockOfferingId and capacity information from the preceding command, you can use purchase-capacity-block-reservation API to purchase it.

$ aws ec2 purchase-capacity-block-reservation \
          --capacity-block-offering-id cbr-0123456789abcdefg \
          –-instance-platform Linux/UNIX

For more information about new EC2 Capacity Blocks APIs, see the Amazon EC2 API documentation.

Your EC2 Capacity Block has now been scheduled successfully. On the scheduled start date, your EC2 Capacity Block will become active. To use an active EC2 Capacity Block on your starting date, choose the capacity reservation ID for your EC2 Capacity Block. You can see a breakdown of the reserved instance capacity, which shows how the capacity is currently being utilized in the Capacity details section.

To launch instances into your active EC2 Capacity Block, choose Launch instances and follow the normal process of launching EC2 instances and running your ML workloads.

In the Advanced details section, choose Capacity Blocks as the purchase option and select the capacity reservation ID of the EC2 Capacity Block you’re trying to target.

As your EC2 Capacity Block end time approaches, Amazon EC2 will emit an event through Amazon EventBridge, letting you know your reservation is ending soon so you can checkpoint your workload. Any instances running in the EC2 Capacity Block go into a shutting-down state 30 minutes before your reservation ends. The amount you were charged for your EC2 Capacity Block does not include this time period. When your EC2 Capacity Block expires, any instances still running will be terminated.

Now available
Amazon EC2 Capacity Blocks are now available for p5.48xlarge instances in the AWS US East (Ohio) Region. You can view the price of an EC2 Capacity Block before you reserve it, and the total price of an EC2 Capacity Block is charged up-front at the time of purchase. For more information, see the EC2 Capacity Blocks pricing page.

To learn more, see the EC2 Capacity Blocks documentation and send feedback to AWS re:Post for EC2 or through your usual AWS Support contacts.

— Channy

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

Post Syndicated from Bozho original https://blog.bozho.net/blog/4162

Във връзка с твърденията, че заедно с Кирил Петков съм притискал или заплашвал министъра на електронното управление за поръчки, искам да кажа няколко неща:

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

2. Ще съдействам максимално на компетентните органи за установяване на истината.

3. Нямам никаква представа каква е причината за такива твърдения. Надявам се всичко това да е нелепо недоразумение, а не част от политически сценарий.

4. 640 милиона са много пари, които няма как да се изхарчат за краткия хоризонт на правителството. Министерството, а по-рано държавната агенция, за цялото си съществуване от 2016 г. досега са похарчили общо около 135 милиона (по данни от СЕБРА).

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

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

Материалът Опровержение на твърдения на натиск от моя страна е публикуван за пръв път на БЛОГодаря.

Transforming transactions: Streamlining PCI compliance using AWS serverless architecture

Post Syndicated from Abdul Javid original https://aws.amazon.com/blogs/security/transforming-transactions-streamlining-pci-compliance-using-aws-serverless-architecture/

Compliance with the Payment Card Industry Data Security Standard (PCI DSS) is critical for organizations that handle cardholder data. Achieving and maintaining PCI DSS compliance can be a complex and challenging endeavor. Serverless technology has transformed application development, offering agility, performance, cost, and security.

In this blog post, we examine the benefits of using AWS serverless services and highlight how you can use them to help align with your PCI DSS compliance responsibilities. You can remove additional undifferentiated compliance heavy lifting by building modern applications with abstracted AWS services. We review an example payment application and workflow that uses AWS serverless services and showcases the potential reduction in effort and responsibility that a serverless architecture could provide to help align with your compliance requirements. We present the review through the lens of a merchant that has an ecommerce website and include key topics such as access control, data encryption, monitoring, and auditing—all within the context of the example payment application. We don’t discuss additional service provider requirements from the PCI DSS in this post.

This example will help you navigate the intricate landscape of PCI DSS compliance. This can help you focus on building robust and secure payment solutions without getting lost in the complexities of compliance. This can also help reduce your compliance burden and empower you to develop your own secure, scalable applications. Join us in this journey as we explore how AWS serverless services can help you meet your PCI DSS compliance objectives.

Disclaimer

This document is provided for the purposes of information only; it is not legal advice, and should not be relied on as legal advice. Customers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.

AWS encourages its customers to obtain appropriate advice on their implementation of privacy and data protection environments, and more generally, applicable laws and other obligations relevant to their business.

PCI DSS v4.0 and serverless

In April 2022, the Payment Card Industry Security Standards Council (PCI SSC) updated the security payment standard to “address emerging threats and technologies and enable innovative methods to combat new threats.” Two of the high-level goals of these updates are enhancing validation methods and procedures and promoting security as a continuous process. Adopting serverless architectures can help meet some of the new and updated requirements in version 4.0, such as enhanced software and encryption inventories. If a customer has access to change a configuration, it’s the customer’s responsibility to verify that the configuration meets PCI DSS requirements. There are more than 20 PCI DSS requirements applicable to Amazon Elastic Compute Cloud (Amazon EC2). To fulfill these requirements, customer organizations must implement controls such as file integrity monitoring, operating system level access management, system logging, and asset inventories. Using AWS abstracted services in this scenario can remove undifferentiated heavy lifting from your environment. With abstracted AWS services, because there is no operating system to manage, AWS becomes responsible for maintaining consistent time settings for an abstracted service to meet Requirement 10.6. This will also shift your compliance focus more towards your application code and data.

This makes more of your PCI DSS responsibility addressable through the AWS PCI DSS Attestation of Compliance (AOC) and Responsibility Summary. This attestation package is available to AWS customers through AWS Artifact.

Reduction in compliance burden

You can use three common architectural patterns within AWS to design payment applications and meet PCI DSS requirements: infrastructure, containerized, and abstracted. We look into EC2 instance-based architecture (infrastructure or containerized patterns) and modernized architectures using serverless services (abstracted patterns). While both approaches can help align with PCI DSS requirements, there are notable differences in how they handle certain elements. EC2 instances provide more control and flexibility over the underlying infrastructure and operating system, assisting you in customizing security measures based on your organization’s operational and security requirements. However, this also means that you bear more responsibility for configuring and maintaining security controls applicable to the operating systems, such as network security controls, patching, file integrity monitoring, and vulnerability scanning.

On the other hand, serverless architectures similar to the preceding example can reduce much of the infrastructure management requirements. This can relieve you, the application owner or cloud service consumer, of the burden of configuring and securing those underlying virtual servers. This can streamline meeting certain PCI requirements, such as file integrity monitoring, patch management, and vulnerability management, because AWS handles these responsibilities.

Using serverless architecture on AWS can significantly reduce the PCI compliance burden. Approximately 43 percent of the overall PCI compliance requirements, encompassing both technical and non-technical tests, are addressed by the AWS PCI DSS Attestation of Compliance.

Customer responsible
52%
AWS responsible
43%
N/A
5%

The following table provides an analysis of each PCI DSS requirement against the serverless architecture in Figure 1, which shows a sample payment application workflow. You must evaluate your own use and secure configuration of AWS workload and architectures for a successful audit.

PCI DSS 4.0 requirements Test cases Customer responsible AWS responsible N/A
Requirement 1: Install and maintain network security controls 35 13 22 0
Requirement 2: Apply secure configurations to all system components 27 16 11 0
Requirement 3: Protect stored account data 55 24 29 2
Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks 12 7 5 0
Requirement 5: Protect all systems and networks from malicious software 25 4 21 0
Requirement 6: Develop and maintain secure systems and software 35 31 4 0
Requirement 7: Restrict access to system components and cardholder data by business need-to-know 22 19 3 0
Requirement 8: Identify users and authenticate access to system components 52 43 6 3
Requirement 9: Restrict physical access to cardholder data 56 3 53 0
Requirement 10: Log and monitor all access to system components and cardholder data 38 17 19 2
Requirement 11: Test security of systems and networks regularly 51 22 23 6
Requirement 12: Support information security with organizational policies 56 44 2 10
Total 464 243 198 23
Percentage 52% 43% 5%

Note: The preceding table is based on the example reference architecture that follows. The actual extent of PCI DSS requirements reduction can vary significantly depending on your cardholder data environment (CDE) scope, implementation, and configurations.

Sample payment application and workflow

This example serverless payment application and workflow in Figure 1 consists of several interconnected steps, each using different AWS services. The steps are listed in the following text and include brief descriptions. They cover two use cases within this example application — consumers making a payment and a business analyst generating a report.

The example outlines a basic serverless payment application workflow using AWS serverless services. However, it’s important to note that the actual implementation and behavior of the workflow may vary based on specific configurations, dependencies, and external factors. The example serves as a general guide and may require adjustments to suit the unique requirements of your application or infrastructure.

Several factors, including but not limited to, AWS service configurations, network settings, security policies, and third-party integrations, can influence the behavior of the system. Before deploying a similar solution in a production environment, we recommend thoroughly reviewing and adapting the example to align with your specific use case and requirements.

Keep in mind that AWS services and features may evolve over time, and new updates or changes may impact the behavior of the components described in this example. Regularly consult the AWS documentation and ensure that your configurations adhere to best practices and compliance standards.

This example is intended to provide a starting point and should be considered as a reference rather than an exhaustive solution. Always conduct thorough testing and validation in your specific environment to ensure the desired functionality and security.

Figure 1: Serverless payment architecture and workflow

Figure 1: Serverless payment architecture and workflow

  • Use case 1: Consumers make a payment
    1. Consumers visit the e-commerce payment page to make a payment.
    2. The request is routed to the payment application’s domain using Amazon Route 53, which acts as a DNS service.
    3. The payment page is protected by AWS WAF to inspect the initial incoming request for any malicious patterns, web-based attacks (such as cross-site scripting (XSS) attacks), and unwanted bots.
    4. An HTTPS GET request (over TLS) is sent to the public target IP. Amazon CloudFront, a content delivery network (CDN), acts as a front-end proxy and caches and fetches static content from an Amazon Simple Storage Service (Amazon S3) bucket.
    5. AWS WAF inspects the incoming request for any malicious patterns, if the request is blocked, the request doesn’t return static content from the S3 bucket.
    6. User authentication and authorization are handled by Amazon Cognito, providing a secure login and scalable customer identity and access management system (CIAM)
    7. AWS WAF processes the request to protect against web exploits, then Amazon API Gateway forwards it to the payment application API endpoint.
    8. API Gateway launches AWS Lambda functions to handle payment requests. AWS Step Functions state machine oversees the entire process, directing the running of multiple Lambda functions to communicate with the payment processor, initiate the payment transaction, and process the response.
    9. The cardholder data (CHD) is temporarily cached in Amazon DynamoDB for troubleshooting and retry attempts in the event of transaction failures.
    10. A Lambda function validates the transaction details and performs necessary checks against the data stored in DynamoDB. A web notification is sent to the consumer for any invalid data.
    11. A Lambda function calculates the transaction fees.
    12. A Lambda function authenticates the transaction and initiates the payment transaction with the third-party payment provider.
    13. A Lambda function is initiated when a payment transaction with the third-party payment provider is completed. It receives the transaction status from the provider and performs multiple actions.
    14. Consumers receive real-time notifications through a web browser and email. The notifications are initiated by a step function, such as order confirmations or payment receipts, and can be integrated with external payment processors through an Amazon Simple Notification Service (Amazon SNS) Amazon Simple Email Service (Amazon SES) web hook.
    15. A separate Lambda function clears the DynamoDB cache.
    16. The Lambda function makes entries into the Amazon Simple Queue Service (Amazon SQS) dead-letter queue for failed transactions to retry at a later time.
  • Use case 2: An admin or analyst generates the report for non-PCI data
    1. An admin accesses the web-based reporting dashboard using their browser to generate a report.
    2. The request is routed to AWS WAF to verify the source that initiated the request.
    3. An HTTPS GET request (over TLS) is sent to the public target IP. CloudFront fetches static content from an S3 bucket.
    4. AWS WAF inspects incoming requests for any malicious patterns, if the request is blocked, the request doesn’t return static content from the S3 bucket. The validated traffic is sent to Amazon S3 to retrieve the reporting page.
    5. The backend requests of the reporting page pass through AWS WAF again to provide protection against common web exploits before being forwarded to the reporting API endpoint through API Gateway.
    6. API Gateway launches a Lambda function for report generation. The Lambda function retrieves data from DynamoDB storage for the reporting mechanism.
    7. The AWS Security Token Service (AWS STS) issues temporary credentials to the Lambda service in the non-PCI serverless account, allowing it to launch the Lambda function in the PCI serverless account. The Lambda function retrieves non-PCI data and writes it into DynamoDB.
    8. The Lambda function fetches the non-PCI data based on the report criteria from the DynamoDB table from the same account.

Additional AWS security and governance services that would be implemented throughout the architecture are shown in Figure 1, Label-25. For example, Amazon CloudWatch monitors and alerts on all the Lambda functions within the environment.

Label-26 demonstrates frameworks that can be used to build the serverless applications.

Scoping and requirements

Now that we’ve established the reference architecture and workflow, lets delve into how it aligns with PCI DSS scope and requirements.

PCI scoping

Serverless services are inherently segmented by AWS, but they can be used within the context of an AWS account hierarchy to provide various levels of isolation as described in the reference architecture example.

Segregating PCI data and non-PCI data into separate AWS accounts can help in de-scoping non-PCI environments and reducing the complexity and audit requirements for components that don’t handle cardholder data.

PCI serverless production account

  • This AWS account is dedicated to handling PCI data and applications that directly process, transmit, or store cardholder data.
  • Services such as Amazon Cognito, DynamoDB, API Gateway, CloudFront, Amazon SNS, Amazon SES, Amazon SQS, and Step Functions are provisioned in this account to support the PCI data workflow.
  • Security controls, logging, monitoring, and access controls in this account are specifically designed to meet PCI DSS requirements.

Non-PCI serverless production account

  • This separate AWS account is used to host applications that don’t handle PCI data.
  • Since this account doesn’t handle cardholder data, the scope of PCI DSS compliance is reduced, simplifying the compliance process.

Note: You can use AWS Organizations to centrally manage multiple AWS accounts.

AWS IAM Identity Center (successor to AWS Single Sign-On) is used to manage user access to each account and is integrated with your existing identify provider. This helps to ensure you’re meeting PCI requirements on identity, access control of card holder data, and environment.

Now, let’s look at the PCI DSS requirements that this architectural pattern can help address.

Requirement 1: Install and maintain network security controls

  • Network security controls are limited to AWS Identity and Access Management (IAM) and application permissions because there is no customer controlled or defined network. VPC-centric requirements aren’t applicable because there is no VPC. The configuration settings for serverless services can be covered under Requirement 6 to for secure configuration standards. This supports compliance with Requirements 1.2 and 1.3.

Requirement 2: Apply secure configurations to all system components

  • AWS services are single function by default and exist with only the necessary functionality enabled for the functioning of that service. This supports compliance with much of Requirement 2.2.
  • Access to AWS services is considered non-console and only accessible through HTTPS through the service API. This supports compliance with Requirement 2.2.7.
  • The wireless requirements under Requirement 2.3 are not applicable, because wireless environments don’t exist in AWS environments.

Requirement 3: Protect stored account data

  • AWS is responsible for destruction of account data configured for deletion based on DynamoDB Time to Live (TTL) values. This supports compliance with Requirement 3.2.
  • DynamoDB and Amazon S3 offer secure storage of account data, encryption by default in transit and at rest, and integration with AWS Key Management Service (AWS KMS). This supports compliance with Requirements 3.5 and 4.2.
  • AWS is responsible for the generation, distribution, storage, rotation, destruction, and overall protection of encryption keys within AWS KMS. This supports compliance with Requirements 3.6 and 3.7.
  • Manual cleartext cryptographic keys aren’t available in this solution, Requirement 3.7.6 is not applicable.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks

  • AWS Certificate Manager (ACM) integrates with API Gateway and enables the use of trusted certificates and HTTPS (TLS) for secure communication between clients and the API. This supports compliance with Requirement 4.2.
  • Requirement 4.2.1.2 is not applicable because there are no wireless technologies in use in this solution. Customers are responsible for ensuring strong cryptography exists for authentication and transmission over other wireless networks they manage outside of AWS.
  • Requirement 4.2.2 is not applicable because no end-user technologies exist in this solution. Customers are responsible for ensuring the use of strong cryptography if primary account numbers (PAN) are sent through end-user messaging technologies in other environments.

Requirement 5: Protect a ll systems and networks from malicious software

  • There are no customer-managed compute resources in this example payment environment, Requirements 5.2 and 5.3 are the responsibility of AWS.

Requirement 6: Develop and maintain secure systems and software

  • Amazon Inspector now supports Lambda functions, adding continual, automated vulnerability assessments for serverless compute. This supports compliance with Requirement 6.2.
  • Amazon Inspector helps identify vulnerabilities and security weaknesses in the payment application’s code, dependencies, and configuration. This supports compliance with Requirement 6.3.
  • AWS WAF is designed to protect applications from common attacks, such as SQL injections, cross-site scripting, and other web exploits. AWS WAF can filter and block malicious traffic before it reaches the application. This supports compliance with Requirement 6.4.2.

Requirement 7: Restrict access to system components and cardholder data by business need to know

  • IAM and Amazon Cognito allow for fine-grained role- and job-based permissions and access control. Customers can use these capabilities to configure access following the principles of least privilege and need-to-know. IAM and Cognito support the use of strong identification, authentication, authorization, and multi-factor authentication (MFA). This supports compliance with much of Requirement 7.

Requirement 8: Identify users and authenticate access to system components

  • IAM and Amazon Cognito also support compliance with much of Requirement 8.
  • Some of the controls in this requirement are usually met by the identity provider for internal access to the cardholder data environment (CDE).

Requirement 9: Restrict physical access to cardholder data

  • AWS is responsible for the destruction of data in DynamoDB based on the customer configuration of content TTL values for Requirement 9.4.7. Customers are responsible for ensuring their database instance is configured for appropriate removal of data by enabling TTL on DDB attributes.
  • Requirement 9 is otherwise not applicable for this serverless example environment because there are no physical media, electronic media not already addressed under Requirement 3.2, or hard-copy materials with cardholder data. AWS is responsible for the physical infrastructure under the Shared Responsibility Model.

Requirement 10: Log and monitor all access to system components and cardholder data

  • AWS CloudTrail provides detailed logs of API activity for auditing and monitoring purposes. This supports compliance with Requirement 10.2 and contains all of the events and data elements listed.
  • CloudWatch can be used for monitoring and alerting on system events and performance metrics. This supports compliance with Requirement 10.4.
  • AWS Security Hub provides a comprehensive view of security alerts and compliance status, consolidating findings from various security services, which helps in ongoing security monitoring and testing. Customers must enable PCI DSS security standard, which supports compliance with Requirement 10.4.2.
  • AWS is responsible for maintaining accurate system time for AWS services. In this example, there are no compute resources for which customers can configure time. Requirement 10.6 is addressable through the AWS Attestation of Compliance and Responsibility Summary available in AWS Artifact.

Requirement 11: Regularly test security systems and processes

  • Testing for rogue wireless activity within the AWS-based CDE is the responsibility of AWS. AWS is responsible for the management of the physical infrastructure under Requirement 11.2. Customers are still responsible for wireless testing for their environments outside of AWS, such as where administrative workstations exist.
  • AWS is responsible for internal vulnerability testing of AWS services, and supports compliance with Requirement 11.3.1.
  • Amazon GuardDuty, a threat detection service that continuously monitors for malicious activity and unauthorized access, providing continuous security monitoring. This supports the IDS requirements under Requirement 11.5.1, and covers the entire AWS-based CDE.
  • AWS Config allows customers to catalog, monitor and manage configuration changes for their AWS resources. This supports compliance with Requirement 11.5.2.
  • Customers can use AWS Config to monitor the configuration of the S3 bucket hosting the static website. This supports compliance with Requirement 11.6.1.

Requirement 12: Support information security with organizational policies and programs

  • Customers can download the AWS AOC and Responsibility Summary package from Artifact to support Requirement 12.8.5 and the identification of which PCI DSS requirements are managed by the third-party service provider (TSPS) and which by the customer.

Conclusion

Using AWS serverless services when developing your payment application can significantly help reduce the number of PCI DSS requirements you need to meet by yourself. By offloading infrastructure management to AWS and using serverless services such as Lambda, API Gateway, DynamoDB, Amazon S3, and others, you can benefit from built-in security features and help align with your PCI DSS compliance requirements.

Contact us to help design an architecture that works for your organization. AWS Security Assurance Services is a Payment Card Industry-Qualified Security Assessor company (PCI-QSAC) and HITRUST External Assessor firm. We are a team of industry-certified assessors who help you to achieve, maintain, and automate compliance in the cloud by tying together applicable audit standards to AWS service-specific features and functionality. We help you build on frameworks such as PCI DSS, HITRUST CSF, NIST, SOC 2, HIPAA, ISO 27001, GDPR, and CCPA.

More information on how to build applications using AWS serverless technologies can be found at Serverless on AWS.

Want more AWS Security news? Follow us on Twitter.

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

Abdul Javid

Abdul Javid

Abdul is a Senior Security Assurance Consultant and PCI DSS Qualified Security Assessor with AWS Security Assurance Services, and has more than 25 years of IT governance, operations, security, risk, and compliance experience. Abdul leverages his experience and knowledge to advise AWS customers with guidance and advice on their compliance journey. Abdul earned an M.S. in Computer Science from IIT, Chicago and holds various industry recognized sought after certifications in security and program and risk management from prominent organizations like AWS, HITRUST, ISACA, PMI, PCI DSS, and ISC2.

Ted Tanner

Ted Tanner

Ted is a Principal Assurance Consultant and PCI DSS Qualified Security Assessor with AWS Security Assurance Services, and has more than 25 years of IT and security experience. He uses this experience to provide AWS customers with guidance on compliance and security, and on building and optimizing their cloud compliance programs. He is co-author of the Payment Card Industry Data Security Standard (PCI DSS) v3.2.1 on AWS Compliance Guide and the soon-to-be-released v4.0 edition.

Tristan Watty

Tristan Watty

Dr. Watty is a Senior Security Consultant within the Professional Services team of Amazon Web Services based in Queens, New York. He is a passionate Tech Enthusiast, Influencer, and Amazonian with 15+ years of professional and educational experience with a specialization in Security, Risk, and Compliance. His zeal lies in empowering customers to develop and put into action secure mechanisms that steer them towards achieving their security goals. Dr. Watty also created and hosts an AWS Security Show named “Security SideQuest!” that airs on the AWS Twitch Channel.

Padmakar Bhosale

Padmakar Bhosale

Padmakar is a Sr. Technical Account Manager with over 25 years of experience in the Financial, Banking, and Cloud Services. He provides AWS customers with guidance and advice on Payment Services, Core Banking Ecosystem, Credit Union Banking Technologies, Resiliency on AWS Cloud, AWS Accounts & Network levels PCI Segmentations, and Optimization of the Customer’s Cloud Journey experience on AWS Cloud.

[$] Rust code review and netdev

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

A fast-moving patch set—seemingly the norm for Linux networking
development—seeks to add some Rust abstractions for physical layer
(PHY) drivers. Lots of
review has been done, and the patch set has been reworked
frequently in response to those comments. Unfortunately, the Rust-for-Linux developers are
having trouble keeping up with that pace. There
is, it would appear, something of a disconnect between the two communities’
development practices.

Things That Used to Be Science Fiction (and Aren’t Anymore)

Post Syndicated from Yev original https://www.backblaze.com/blog/things-that-used-to-be-science-fiction-and-arent-anymore/

A decorative image showing a spaceship beaming up the Backblaze logo.

The year is 2023, and the human race has spread across the globe. Nuclear powered flying cars are everywhere, and the first colonies have landed on Mars! [Radio crackles.] 

Okay, so that isn’t exactly how it’s gone down, but in honor of Halloween, the day celebrates the whimsy of all things being possible, let’s talk about things that used to be science fiction and aren’t anymore.

Artificial Intelligence (AI)

Have we gotten reader fatigue from this topic yet? (As technology people by nature, we’re deep in it.) The rise of generative AI over the past year or so has certainly brought this subject into the spotlight, so in some ways it seems “early” to judge all the ways that AI will change things. On the other hand, there are lots of tools and functions we’ve been using for a while that have been powered by AI algorithms, including AI assistants. 

Shout out to this content creator for a hilarious video.

At the risk of not doing this topic justice in this list, I’ll say that there’s plenty of reporting on—and plenty of potential for—AI now and in the future. 

Aliens

This year, the U.S. House Oversight Committee was conducting an investigation on unidentified flying objects (UFOs). While many UFOs turn out to be things like weather balloons and drones designed for home use, well, some apparently aren’t. Three military veterans, including a former intelligence officer, went on record saying that the government has a secret facility where it’s been reverse engineering highly advanced vehicles, and that the U.S. has recovered “non-human biologics” from these crash sites. (Whatever that means—but we all know what that means, right…) 

Here’s the video, if you want to see for yourself. 

Weirdly, the public response was… not much of one. (The last couple of years have been “a year”.) But, chalk this one up as confirmed. 

Space Stations

The list of sci-fi shows and books set on space stations is definitely too long to list item by item. Depending on your age (and we won’t ask you to tell us), you may think of Isaac Asimov’s Foundation series (the books), Star Wars, Zenon, Girl of the 21st Century (or maybe the Zequel?), Babylon 5, or the Expanse. 

Back in the real world, the International Space Station (ISS) has been in orbit since 1998 and runs all manner of scientific experiments. Notably, these experiments include the Alpha Meter Spectrometer (AMS-02) which is designed to detect things like dark matter and antimatter and solve the fundamental mysteries of the universe. (No big deal.) 

For those of us stuck on Earth (for now), you can keep up with the ISS in lots of ways. Check out this map that lets you track whether you can see it from your current location. (Wave the next time it floats over!) And, of course, there are some fun YouTube channels streaming the ISS. Here’s just one:  

Universal Translators

Okay, universal translators is the cool sci-fi name, but if you want the actual, machine learning (ML) name, folks call that interlingual machine translation. Translation may seem straightforward at first glance, but, as this legendary Star Trek episode demonstrates, things are not always so simple. 

And sure, it’s easy to say that this is an unreasonable standard given that most human languages are known—but are they? Native language reclamation projects like those from the Cherokee and Oneida tribes demonstrate how easy it is to lose the nuance of a language without those who natively speak it. Advanced degrees in poetry translation, like this Masters of Fine Arts from the University of Iowa (go Hawks!), help specialists grapple with and capture the nuance between smell, scent, odor, and stench across different languages. And, add to those challenges that translators also have to contend with the wide array of accents in each language. 

With that in mind, it’s pretty amazing that we now have translation devices that can be as small as earbuds. Most still require an internet connection, and some are more effective than others, but it’s safe to say we live in the future, folks. Case in point: I had a wine tasting in Tuscany a few months ago where we used Google Translate exclusively to speak with the winemaker and proprietor. 

iPads

“What?” you say. “iPads are so normal!” Sure, now you’re used to touch screens. But, let me present you with this image from a show that is definitely considered science fiction:

Shockingly, not an iPad.

Yes, folks, that’s Captain Jean Luc Picard from Star Trek: The Next Generation. And here’s a later one, from Star Trek: Deep Space Nine. 

These are plans for the arboretum, so Keiko is probably dropping some knowledge.

Star Trek wikis describe the details of a Personal Access Display Device, or PADD, including a breakdown of how they changed over time in the series. Uhura even had a “digital clipboard” in the original Star Trek series: 

We’d have to revisit the episode to see what this masterful side-eye is about.

And, just for the record, we’ll always have a soft spot in our heart for Chief O’Brien’s love of backups.

Robot Domestic Laborer

If you were ever a fan of this lovely lady—

Rosie the Robot, of course, longtime employee and friend of The Jetsons.

—then you’ll be happy to know that your robot caretaker(s) have arrived. Just as Rosie was often seen using a separate vacuum cleaner, they’re not all integrated into one charming package—yet. If you’re looking for the full suite of domestic help, you’ll have to get a few different products. 

First up, the increasingly popular (and, as time goes on, increasingly affordable) robot vacuum. There are tons of models, from the simple vacuum to the vacuum/mop. While they’re reportedly prone to some pretty hilarious (horrific?) accidents, having one or several of these disk-shaped appliances saves lots of folks lots of time. Bonus: just add cat, and you have adorable internet content in the comfort of your own home. 

Next up, the Snoo, marketed as a smart bassinet, will track everything baby, then use that data to help said baby sleep. Parents who can afford to buy or rent this item sing its praises, noting that you can swaddle the baby for safety and review the data collected to better care for your child. 

And, don’t forget to round out your household with this charming toilet cleaning robot. 

Robot Bartenders

In this iconic scene from The Fifth Element, Luc Besson’s 1997 masterpiece, a drunken priest waxes poetic about a perfect being (spoiler: she’s a woman) to a robot bartender. “Do you know what I mean?” the priest asks. The robot shakes its head. “Do you want some more?”

Start at about 2:00 minutes.

These days, you can actually visit robot bartenders in Las Vegas or on Royal Caribbean cruise ships. Or, if you’re looking for a robot bartender that does more than serve up a great Sazerac, you can turn to Brillo, a robot bartender powered by AI who can also engage in complex dialogue. 

Please politely ignore that his face is the stuff of nightmares…it’s what’s on the inside (and in the glass) that counts.

And, if leaving your house sounds terrible, don’t worry: you can also get a specialized appliance for your home. 

It’s a Good Time to Be Cloud Storage

One thing that all these current (and future) tech developments have in common: you never see them carting something trailing wires. That means (you guessed it!) that they’re definitely using a central data source delivered via wireless network, a.k.a the cloud.

After you’ve done all the work to, say, study an alien life form or design and program the perfect cocktail, you definitely don’t want to do that work twice. And, do you see folks slowing down to schedule a backup? Definitely not. Easy, online, always updating backups are the way to go.

So, we’re not going to say Backblaze Computer Backup makes the list as a sci-fi idea that we’ve made real; we’re just saying that it’s probably one of those things that people leave off-stage, like characters brushing their teeth on a regular basis. And, past or future, we’re here to remind you that you should always back up your data.

Backup Is Past, Present, and Future 

Things We Still Want (Get On It, Scientists!) 

Everything we just listed is really cool and all, but let’s not forget that we are still waiting for some very important things. Help us out scientists; we really need these: 

  • Flying cars
  • Faster than light space travel
  • Teleportation 
  • Matter replicators (3D printing isn’t quite there)

We feel compelled to add that, despite our jocular tone, the line between science and science fiction has always been something of a thin one. Studies have shown and inventors like Motorola’s Martin Cooper have gone on record pointing to their inspiration in the imaginative works of science fiction. 

So, that leaves us standing by for new developments! Let’s see what 2024 brings. Let us know in the comments section what cool tech in your life fits this brief.

The post Things That Used to Be Science Fiction (and Aren’t Anymore) appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

The collective thoughts of the interwebz