Zero-Trust DNS

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/05/zero-trust-dns.html

Microsoft is working on a promising-looking protocol to lock down DNS.

ZTDNS aims to solve this decades-old problem by integrating the Windows DNS engine with the Windows Filtering Platform—the core component of the Windows Firewall—directly into client devices.

Jake Williams, VP of research and development at consultancy Hunter Strategy, said the union of these previously disparate engines would allow updates to be made to the Windows firewall on a per-domain name basis. The result, he said, is a mechanism that allows organizations to, in essence, tell clients “only use our DNS server, that uses TLS, and will only resolve certain domains.” Microsoft calls this DNS server or servers the “protective DNS server.”

By default, the firewall will deny resolutions to all domains except those enumerated in allow lists. A separate allow list will contain IP address subnets that clients need to run authorized software. Key to making this work at scale inside an organization with rapidly changing needs. Networking security expert Royce Williams (no relation to Jake Williams) called this a “sort of a bidirectional API for the firewall layer, so you can both trigger firewall actions (by input *to* the firewall), and trigger external actions based on firewall state (output *from* the firewall). So instead of having to reinvent the firewall wheel if you are an AV vendor or whatever, you just hook into WFP.”

Case Study: Monitoring Railway Infrastructure for Infrabel

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/case-study-monitoring-railway-infrastructure-for-infrabel/28035/

Infrabel is a government-owned public limited company that builds, owns, maintains, and upgrades the Belgian railway network, makes its capacity available to railway operator companies, and handles train traffic control. Headquartered in Brussels, Infrabel employs over 9,000 people and manages 3,602 kilometers of rail lines.

The challenge

Infrabel needed a monitoring solution that was flexible enough to manage not only infrastructure, but also OS level metrics, data centers, service and application states, and the availability of railway infrastructure components.

The solution

To begin with, Zabbix agents are deployed on railway station screens and broadcasting systems. This is possible because under the hood these pieces of hardware they run Debian OS, which means they can be monitored on the OS level by Zabbix agents right out of the box with our official templates.

This can be very easily automated together with low level discovery, autoregistration, or network discovery. Devices can be pinged from Zabbix proxies or Zabbix servers to check if they are available. If they are unavailable, Zabbix sends a notification, after which an engineer either restores the network connectivity or replaces the hardware.

In addition, Infrabel also uses Zabbix to retrieve and monitor data collected from ActiveMQ. This is where a combination of custom bash scripts and Zabbix sender is used, so the required data (also related to the railway infrastructure and data centre, hardware, and software) is retrieved from ActiveMQ via Bash script, then forwarded to Zabbix sender via a wrapper script, sent to the Zabbix server or proxy, stored and analyzed in Zabbix, and acted upon if required.

The results

Infrabel found that they could get the most out of Zabbix by integrating it with a third-party ticketing system they were already using. The integration itself is simple – when Zabbix generates a problem, the Zabbix API is then used to retrieve the problems related to a particular set of triggers that need to be forwarded to this third-party system.

These alerts are then forwarded via API to whatever system Infrabel requires – Zabbix has a variety of integrations available right out-of-the-box using web hooks, including Slack, JIRA, Microsoft Teams, and many others. Messengers can also be used with Zabbix, but Infrabel has opted to use Zabbix API for their custom ticketing solution.

In conclusion

Infrabel is the perfect example of how the flexibility of Zabbix allows it to adapt to any industry or need. The possibility to use Zabbix API, web hooks, or a combination of both was a game-changer for Infrabel – just as it could be for any customer in any industry.

You can learn more about what we can do for customers across a variety of industries by visiting our website or requesting a demo.

The post Case Study: Monitoring Railway Infrastructure for Infrabel appeared first on Zabbix Blog.

Симаф, която иска да учи и да стане лекарка

Post Syndicated from Надежда Цекулова original https://www.toest.bg/simaf-interview/

Симаф, която иска да учи и да стане лекарка

Симаф е на 12, от Сирия. Тя е дете бежанец и от юли миналата година живее в Регистрационно-приемателния център на Държавната агенция за бежанците в Харманли. Пристигнала е в България с леля си Лейля, но според българското законодателство леля ѝ не може да бъде нейна настойничка и за системата Симаф е „непридружено непълнолетно лице“. 

Като всяко дете под 16 години, търсещо закрила в страната ни, Симаф подлежи на задължително обучение в училище и органите на ДАБ подават името ѝ към образователната система. Малцина от непридружените деца обаче наистина тръгват на училище. Властите казват, че децата не са мотивирани, защото плановете им най-често не са да останат в България, а някои никога не са ходили на училище в живота си. 

Разговаряме със Симаф и Лейля за опита им с българското училище, но този разговор е неразделен от разговора за това какво е да си бежанец в България. Срещам се с тях в току-що ремонтираната с помощта на „УНИЦЕФ България“ сграда в бежанския център в Харманли, която ще функционира като „сигурна зона“ – обособен сектор с по-високо ниво на сигурност, в който ще бъдат настанявани децата бежанци, попаднали в страната ни сами. 

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

В какъв момент ви намирам?

Лейля: Добре сме, слава богу. Вече повече от осем месеца сме тук, текат процедури. Настанени сме в семейния сектор. Там е по-спокойно, но тук (в сигурната зона – б.а.) е станало много хубаво, несравнимо е с другите сгради в лагера. 

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

Как стигнахте до България?

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

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

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

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

В кой клас си?

Симаф: В трети.

В Сирия ходила ли си на училище?

Симаф: Не. 

Звучи доста трудно човек да тръгне на училище директно в трети клас, особено като не знае езика. Как учиш български език?

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

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

В лагера идват Иванка и Катя, които ни занимава с различни неща. При тях също учим и много обичам да ходя.

А как учиш в училище? Как се справяте двете с учителката, когато тя трябва да ти обясни някой урок? 

Симаф: Някои неща разбирам, за някои другите деца ми помагат. Имаме в класа деца, които говорят турски. Те ми обясняват каквото не разбирам.

Превеждат ти какво обяснява учителката? 

Симаф: Да.

Освен децата има ли кой да помага на теб и учителката да се разбирате, когато нещо не е ясно?

Симаф: Не.

А как се справяш с другите предмети, в които учите – за миналото, за природата, за различни неща от света?

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

А на какъв език говориш със съучениците си?

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

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

Симаф: И ще им казвам какво трябва и какво не трябва да правят (смее се). 

Имаш ли приятели в клас?

Симаф: Да, имам.

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

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

А случвало ли се е да говорите с тях или с учителката за Сирия?

Симаф: Не много. 

Лейля: В началото я бяха питали къде е семейството ѝ. Когато стана ясно, че е още в Сирия, никой повече нищо не я попита. 

Може би са забелязали, че това я натъжава.

Лейля: На нея ѝ е много трудно… В момента тече процедурата за събиране на семейството. И чакаме, не знаем колко време ще отнеме всичко. За едно дете осем месеца без родители са много време. Опитвам се да я успокоявам, но неяснотата много тежи. Всеки ден казвам: „Не си сама, аз съм тук. Може би утре ще имаме новини.“ Правим планове да се устроим някак, когато пристигнат майка ѝ, баща ѝ, братчето и сестричката ѝ, да потърсим квартира, работа… Иска ни се да останем в България. 

Мислили ли сте дали ще останете в Харманли, дали ще търсите по-голям град, изобщо как си представяте бъдещето? 

Симаф: Аз искам да продължа да ходя на училище, защото искам да стана лекарка.

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

Introducing classroom management to the Code Editor

Post Syndicated from Phil Howell original https://www.raspberrypi.org/blog/code-editor-classroom-management/

I’m excited to announce that we’re developing a new set of Code Editor features to help school teachers run text-based coding lessons with their students.

Secondary school age learners in a computing classroom.

New Code Editor features for teaching

Last year we released our free Code Editor and made it available as an open source project. Right now we’re developing a new set of features to help schools use the Editor to run text-based coding lessons online and in-person.

The new features will enable educators to create coding activities in the Code Editor, share them with their students, and leave feedback directly on each student’s work. In a simple and easy-to-use interface, educators will be able to give students access, group them into classes within a school account, and quickly help with resetting forgotten passwords.

Example Code Editor feedback screen from an early prototype

We’re adding these teaching features to the Code Editor because one of the key problems we’ve seen educators face over the last few months has been the lack of an ideal tool to teach text-based coding in the classroom. There are some options available, but they can be cost-prohibitive for schools and educators. Our mission is to support young people to realise their full potential through the power of computing, and we believe that to tackle educational disadvantage, we need to offer high-quality tools and make them as accessible as possible. This is why we’ll offer the Code Editor and all its features to educators and students for free, forever.

A learner and educator at a laptop.

Alongside the new classroom management features, we’re also working on improved Python library support for the Code Editor, so that you and your students can get more creative and use the Editor for more advanced topics. We continue to support HTML, CSS, and JavaScript in the Editor too, so you can set website development tasks in the classroom.

Two learners at a laptop in a computing classroom.

Educators have already been incredibly generous in their time and feedback to help us design these new Code Editor features, and they’ve told us they’re excited to see the upcoming developments. Pete Dring, Head of Computing at Fulford School, participated in our user research and said on LinkedIn: “The class management and feedback features they’re working on at the moment look really promising.” Lee Willis, Head of ICT and Computing at Newcastle High School for Girls, also commented on the Code Editor: “We have used it and love it, the fact that it is both for HTML/CSS and then Python is great as the students have a one-stop shop for IDEs.”

Our commitment to you

  • Free forever: We will always provide the Code Editor and all of its features to educators and students for free.
  • A safe environment: Accounts for education are designed to be safe for students aged 9 and up, with safeguarding front and centre.
  • Privacy first: Student data collection is minimised and all collected data is handled with the utmost care, in compliance with GDPR and the ICO Children’s Code.
  • Best-practice pedagogy: We’ll always build with education and learning in mind, backed by our leading computing education research.
  • Community-led: We value and seek out feedback from the computing education community so that we can continue working to make the Code Editor even better for teachers and students.

Get started

We’re working to have the Code Editor’s new teaching features ready later this year. We’ll launch the setup journey sooner, so that you can pre-register for your school account as we continue to work on these features.

Before then, you can complete this short form to keep up to date with progress on these new features or to get involved in user testing.

A female computing educator with three female students at laptops in a classroom.

The Code Editor is already being used by thousands of people each month. If you’d like to try it, you can get started writing code right in your browser today, with zero setup.

The post Introducing classroom management to the Code Editor appeared first on Raspberry Pi Foundation.

Минало и бъдеще на електронното управление

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

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

Електронното управление има няколко компонента – „хардуер и мрежи“, „политики и процеси“, “информационни системи, регистри и данни”. В миналото, политиката и процесите са били част от Министерството на държавната администрация и административната реформа, а впоследствие – дирекция в Министерство на транспорта, информационните технологии и съобщенията (МТИТС), мрежите са били последователно в Държавна агенция за информационни технологии и съобщения и в Изпълнителна агенция „Електронни съобщителни мрежи и информационни системи“ към МТИТС, а “информационните системи, регистрите и данните” – разпръснати по отделните министерства, без много обща политика, като изключим неща като оперативна съвместимост и администриране на някои централизирани информационни системи (в МТИТС и ИА ЕСМИС).

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

Реформата от 2016 г.

В този момент започна моето официално участие в процеса, когато през 2015 г. станах съветник на вицепремиера с ресор „административна реформа“ Румяна Бъчварова.

Тогава подготвихме мащабно изменение в Закона за електронното управление и няколко свързани с него закони, като събрахме „парчетата“ в една нова Държавна агенция „Електронно управление“ (ДАЕУ), на която дадохме значителни правомощия (в т.ч. задължителни разпореждания, административни санкции на държавни служители за неспазване на закона, проектен контрол, в т.ч. за информационните системи и регистрите, бюджетен контрол на разходите за информационни и комуникационни технологии (ИКТ), отворени данни и др.)

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

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

Единен системен оператор и преминаване към „системна интеграция“

Другата важна част от измененията през 2016 г. беше и създаването на Държавно предприятие „Единен системен оператор“ (ДП ЕСО), като в закона бяха разписани детайлно услугите, които то ще предоставя на администрациите – всички свързани с подпомагане на развитието на електронното управление и използването на ИКТ. Идеята беше Информационно обслужване АД да бъде трансформирано в такова държавно предприятие (напр. чрез апорт на активи и преназначаване на служители), като така да се реши проблема с директното възлагане по каталог на услуги (чрез вменяване на публични функции) не свързания с това проблем с малкия процент частни акционери в дружеството. До 2019 г. това не се случи и ДП ЕСО не беше създадено. В този период, в рамките на малко повече от година, стана пробивът в НАП и сривът в Търговския регистър, и правителството на ГЕРБ „на пожар“ прокара една поправка в закона, без тя да е минала обществено обсъждане, и малко отвъд ръба на съгласувателните правила на Министерския съвет – цялата глава от закона за ДП ЕСО беше изтрита и беше заменена с един член 7с и един параграф 45, според които Информационно обслужване извършва системна интеграция за администрации, определени с решение на Министерски съвет. Тогава, нарочно или не, бяха изтрити разпоредбите за прозрачност както на държавното предприятие, така и на самата държавна агенция (ДАЕУ). Отпаднала беше и концепцията за публичен каталог на услугите, приет от Министерски съвет, с ясна стойност, както и други гаранции, които бяхме заложили за да предотвратим свръхконцентрацията на неформална власт в ДП ЕСО чрез системите, които оперира.

Така възлагането на Информационно обслужване става не по реда на Закона за обществените поръчки, а е изключение от него. Спорно е дали това изключение е в съответствие с директивата за обществените поръчки (т.е. дали минава за „изключително право“) или е скрито допълнително изключение, но така или иначе, то дава гъвкавост да се възлагат дейности на Информационно обслужване директно, от определен кръг администрации. От една страна, тези администрации са малко на брой (варират през годините, но са около 20), но пък в тях е концентрирана голяма част от ключовите системи (в което има логика) и голяма част от разходите за ИКТ – това са НАП, Митници, Агенция по вписванията, ГРАО, Кадастъра, Министерство на здравеопазването, НЗОК. Възлагането става по реда на едно малко известно решение на Министерския съвет – 481 от 2020 г.

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

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

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

Министерство на електронното управление

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

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

Инфраструктурната част („мрежи и хардуер“) преместихме в изпълнителна агенция към министерството, като след първата стъпка (механично преливане на хора от ДАЕУ) трябваше да последва стора стъпка – кадрова реформа, защото с наличните човешки ресурси там не може да се обслужва ефективно държавния облак, мрежа и другите споделени ресурси. Такава не се случи нито в служебния кабинет, нито след това при министър Йоловски, макар че имаше ясна концепция за нея. Недостатъчният капацитет в изпълнителната агенция създава аргументи за прехвърляне на дейности към Информационно обслужване, но има аргументи и срещу това – че и капацитет на Информационно обслужване не е достатъчен (според техните настоящи възложители), че се създава свръхцентрализация, от която няма нужда, но носи рискове; че се възлагат твърде много основни функции на търговско дружество; че (поне до скоро) нямаше необходимото ниво на достъп до класифицирана информация.

Тук следва да се отбележи, че в периода 2017-2020 г, ДАЕУ изгражда държавната облачна инфраструктура (държавния облак), като решава това да бъде с класифицирани процедури, вероятно защото по исторически причини тези структури са имали и функции свързани с отбраната и националната сигурност, и съответно в тях работят много военни. Това обаче води след себе си доста особености и усложнения за бъдещи проекти и нужда от поетапно декласифициране на елементи от него – нещо, което бях поискал като министър както за облака, така и за държавната мрежа, но след като завършихме първия етап от трансформацията през май 2022 г., нямах време да довърша и тази задача (гласуваха ни оставките през юни 2022 г.).

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

Киберсигурност

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

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

Предстоящите въпроси пред киберсигурността са как тя да бъде структурирана ефективно, дали националният SOC (security operations center) да бъде част от администрацията или да бъде възложен на ИО, как да се намерят достатъчно експерти и да им се създаде достатъчно добра среда за работа, как най-ефективно да взаимодействат различните звена (CERT, НЕРИКС, НКЦ и др.), дали да се създаде агенция за киберсигурност и какви функции да има тя (вкл. за гореспоменатия национален SOC).

Електронна идентификация

Електронната идентификация е средството, с което всеки ще може да заявява електронни услуги. В Естония това започва като „чип в личната карта“, но вече по-популярен носител на идентификацията е мобилният телефон. През 2016 г. това беше друга ключова реформа – приемане на Закон за електронната идентификация и подготовка на техническата спецификация за нея (и в двете имат основно участие). За съжаление, МВР направи почти всички възможни грешки по пътя (писал съм за това), поради което при закон, приет през 2016 г, към май 2024 г все още резултат няма.

В началото на 2022 г. все още работата по проекта на МВР не беше стартирала, защото се чакаше решение на съда в Люксембург дали МВР правилно прилага духа на директивата за обществените поръчки, така че, съобразявайки се с технологичния напредък и повишената сигурност на мобилните устройства, след обществено обсъждане, възложих на Информационно обслужване изграждането на мобилно приложение за електронна идентификация. Защо на Информационно обслужване – по две причини. Бързина на възлагане и изпълнение (имахме огромно забавяне за наваксване) и наличния експертен капацитет (ИО е доставчик на квалифицирани удостоверителни услуги и има нужната експертиза).

За съжаление, с известен саботаж от страна на МВР, и с липсата на активна подкрепа за проекта в служебния кабинет, работата по него спря, като в края на същата година МВР подписа договора за своя проект. Няма тук да влизам в детайли защо двата проекта не си противоречат, а се допълват, но в последната година и половина опитах да убедя МВР да използва разработеното по проекта за мобилно приложение – те отказаха. Тогава споделих публично притесненията си, че със спецификация от 2016 г. може и да не получим адекватен на 2024 г. резултат. МВР вече закъснява както с личните карти, така и със системата за електронна идентификация. Надявам се резултатът да може да адаптиран към настоящите реалности, включително към последните изменения в Закона за електронното управление, с които направихме възможно услуги да се заявяват без квалифициран електронен подпис, а само с електронна идентификация. МВР впоследствие възрази и срещу предложени от мен изменения в закона, с които да даде на МЕУ да оперира националната схема за електронна идентификация.

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

Нов Закона за управление на информационните и комуникационните технологии в обществения сектор

Всичко описано по-горе подчертава основните проблеми – липса на достатъчно капацитет, липса на адекватна структура, неефективност на харченето, бавно и неадекватно възлагане и др. Смятам, че това може да се поправи с нов закон, чиято подготовка стартирах през 2022 г. и вече е в доста напреднал стадий – Закон за управление на информационните и комуникационни технологии в обществения сектор. Целта е с него да се уреди повече ефективност, предвидимост, фокус и прозрачност на възлагането, както на системния интегратор (ИО), така и на свободния пазар, вкл. чрез рамкови споразумения и отчитане на общата стойност на притежаване (т.нар. TCO), както правят много европейски държави; по-висока отчетност и контрол на дейността на системния интегратор; намиране на баланса между ефективност чрез „икономии от мащаба“ и ограничаване на рисковете от свръхцентрализация на управлението на ИКТ; по-добра вътрешна организация на работата в администрацията; използването на споделени услуги по утвърден каталог, вместо „всеки да се оправя поединично“; повече яснота по предоставянето на споделени ресурси (облак, мрежа и др.) от МЕУ; по-малко зависимости от един или друг доставчик; обособяване на отделна агенция за киберсигурност, която освен услуги по мониторинг и отговор на инциденти, да подпомага ГДБОП в разследването на киберпрестъпления; на разкачане на структурата и заплащането на ИТ експертите в двете агенции (инфраструктурата агенция и кибер агенцията) от общата структура в администрацията, за да има по-привлекателни условия за специалистите; организиране на централен орган за покупки на стандартен хардуер и софтуер, така че да се спестят както време, така и средства за най-стандартните неща.

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

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

Заключение

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

В последните парламенти приехме много изменения, с които дигитализираме различни процеси и регистри в администрацията, така че да отпада излишната хартия, а дигитализацията ѝ да стане по правилния начин. Но този подход не е достатъчно бърз и координиран – нужен е институционален “upgrade”.

Законът за електронното управление вече е уредил достатъчно добре „какво“ трябва да се случи, особено след последното му изменение миналата година. Предстои да отговорим на въпроса „как“. Един нов закон няма да реши всичко, но ще постави ясна рамка, в която да се вдигнат и оборотите, и качеството.

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

Mozilla Foundation Welcomes Nabiha Syed as Executive Director

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

The Mozilla Foundation has announced
that its new executive director will be Nabiha Syed.

Syed is known for her mission-driven leadership, focused on
increasing transparency into the most powerful institutions in
society. She comes to Mozilla after leading The Markup, an
award-winning publication that challenges technology to serve the
public good, from its launch through its successful acquisition in
2024.

The Four Pillars of Managing Email Reputation

Post Syndicated from Dustin Taylor original https://aws.amazon.com/blogs/messaging-and-targeting/the-four-pillars-of-email-reputation/

Introduction

A sender’s domain and IP reputation strongly indicate email deliverability success. Maintaining a high reputation ensures optimal recipient inboxing. This blog outlines how Amazon SES protects its network reputation to help customers deliver high-quality email consistently. Understanding sender reputation nuances across diverse mailbox providers can be challenging, making issue identification and root cause analysis difficult. We’ll explore SES’ approach to managing domain and IP reputation.

What are Domain and IP Reputation?

Domain and IP reputation are measured by mailbox providers to indicate how reputable a sender is based primarily on how recipients engage with their email. Mailbox providers have their own way of measuring reputation and typically consider indicators such as:

  • A history of the emails received from the domain/IP
  • The authentication technologies used during delivery (SPF, DKIM, DMARC)
  • The rate of user engagement for the messages
  • The rate of complaints generated by the messages
  • The rate of which the mailbox providers’ spam filter determines mail to be spam from a domain/IP

While not an exhaustive list, these are some of the inputs into the reputation of a sender. Of this list, 4 of the 5 have nothing to do with the body, or viewable content, of the email that is received. This illustrates how important it is to have effective processes in place to set up sending from your domain/IPs and the management of your email sending programs.

How does Amazon SES manage Domain and IP Reputation

Management of reputation requires a multi-faceted approach distilled into four distinct pillars: Prevention, Monitoring, Analysis, and Response. Let’s dive deeper into these four pillars to see how Amazon SES operates to protect sending reputation for our service and our customers.

Prevention

Prevention is arguably the most important of the four pillars of reputation management. Abuse, or misuse, is the leading cause of poor reputation. Abuse, or misuse, can be characterized as sending phishing emails, unsolicited emails, or aggressive sending practices ignoring user feedback or lack of engagement, but this is not an exhaustive list. Prevention of abuse is accomplished through customer education (blogs, public documentation, and customer correspondence), service terms, acceptable use policies, and strict rules on setup. These abuse prevention mechanisms aid in educating customers before they use SES on prohibited sending practices as well as providing guidance on email sending best practices. SES implements several mechanisms to mitigate abuse and misuse, including:

  • Production access reviews – Every customer must request access to send email outbound. This step plays two parts: 1\ giving customers an opportunity to test sending from and to verified identities and 2\ preventing malicious senders from being able to open an account and begin uninhibited sending of low-quality mail. Every customer requesting access to send via SES provides information on their sending practices and volume estimates. This information is used in three ways: first to ensure that a customer is following best practices for sending email, second to provide the appropriate limits needed for their business, and third to determine if a customer’s sending practices are a risk to other senders.
  • Restricted sending from only verified identities/domains – Every customer, must verify ownership of an email address or sending domain to send an email on SES. This can be done for email addresses by clicking a verification link or for domains by placing DNS records that SES is able to verify.
  • Daily volume and sending rate limits – SES applies sending limits to an account for the following reasons: prevention of reputational damage and limiting costs should a bug occur within a customer’s application, and limiting the damage an elusive bad actor may cause.

Monitoring

The second pillar of reputation management is accurately monitoring your sending performance. Amazon SES tracks metrics like bounces, complaints, abuse reports, and mailbox provider status codes. Establishing overall sending baselines is crucial to measure the impact of deliverability and reputation changes. Granular monitoring is equally important, including metrics at the account, domain, IP, and blocklist levels.

Having granular data regarding our customer’s sending performance gives SES, and our customers, the opportunity to identify mechanisms in which a customer’s sending can improve, or indicators of when a bad actor may intend to misuse SES. Some of the mechanisms that we use to reduce the risk of reputation degradation include:

  • Monitoring new customer activity closely – The riskiest time for SES is when a new customer begins using SES and we have no historical precedent for the mail they are attempting to send. While the overwhelming majority of our customers send quality email, it’s important to ensure that a customer that is onboarding exhibits good sending practices. A customer may be inexperienced in their sending practices and SES will notify customers early to aid them in improving their sending. This limits the damage that can be done to both SES reputation and that of our customer.
  • Monitor any customers that trend away from the baseline – SES looks to determine what customers are doing well and where they could improve. Should they be given access to send freely, or should there be restrictions?
  • Monitor high-performing customers as well as low-performing customers – For SES, it’s crucial to prevent events that can degrade our reputation, such as sender compromises, uploading purchased lists, or using unsolicited recipient lists. Thoroughly reviewing all customers is essential to avoid reputational degradation from unnoticed compromises or misused recipient lists.
  • Providing our customers with a way to monitor more than bounce and complaint rates – SES provides a feature called the Virtual Deliverability Manager (VDM) which gives customers the added insight into how their messages are received by mailbox providers. These insights are provided in a dashboard that customers can review and dig into problems at the domain level, and broken down by provider.

Analysis

The third of the pillars of reputation management is analysis. Understanding the history of a sender, normal behavior and trends, mailbox provider feedback patterns, and monitoring reputation from a reputation provider enables SES to build a picture of a sender. Lets speak on some specifics about each of these data points further.

  • Sending Behavior – Is this a new sender, or one with an established reputation? Do they have a history of previous bounce/complaint issues? What historical volume is sent?
    • Tip: Understanding the baseline or history of the sender gives you the ability to know when things have changed for the better or worse.
  • Mailbox provider feedback – Amazon SES reviews mailbox provider feedback patterns to analyze responses when sending mail. If normally all SES mail is received successfully and we begin to see a spike in throttles with a negative response message such as this one from Gmail:

    421-4.7.28 Gmail has detected an unusual rate of unsolicited mail originating from your DKIM domain [example.com 36]. To protect our users from spam, mail sent from your domain has been temporarily rate limited. For more information, go to https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our Bulk Email Senders Guidelines. m25-20020ae9e019000000b0078edf1f4c40si26277545qkk.197 – gsmtp

    this could be the first sign of reputation degradation.

    • Tip: Mailbox provider feedback is a good data point for degradation, however this is a late sign as the damage has already occurred. More proactive measures should be in place to ensure this step doesn’t occur.
  • Using reputation providers – External feedback on Amazon SES reputation is critical to validate our processes and identify potential gaps. Selecting a reputation provider has helped SES close this gap.
    • Tip: As a mail provider, you rely on sending metrics and historical data for monitoring senders. However, you may not know how customers acquired their recipient lists – whether through confirmed opt-ins or purchased lists. Purchased lists risk your domain being blocklisted since recipients didn’t sign up for your mail. Lacking visibility into subscription workflows makes it hard to determine why blocklisting occurred. Refer to our FAQ for more on blocklists.

Response

The fourth of the pillars of reputation management is response. Understanding what to do when your reputation begins to show signs of decline is important. Some signals that show reputation declines are: low inbox rates, mail being throttled, mail being blocked, or external reputation tools showing poor reputation for your domain/IP. For Amazon SES, we take action to do the following:

  • Contact customers where metrics breach alarm thresholds.
  • Respond timely to signs of abuse or reputation degradation.
  • Stop sending based on continued, or high-risk, signals of abuse or reputation degradation.
  • Support customers in resolving sending issues to maintain the overall reputation of SES.

It is important to respond quickly to the signals of reputation degradation. The decision to impact a customer’s ability to send mail is not one that Amazon SES takes lightly. A decision to impact a customer’s ability to send mail is made when the quality of mail is abusive in nature (phishing) or if there are signals that the mail being sent is not well received by mailbox providers at scale. In some cases, a customer may not be aware that their sending patterns, practices, or content may be problematic. This can be due to a gap in monitoring, logging, or an issue with credentials being compromised. If the decision to impact a customer’s sending is made, a communication will be sent to that customer so that we can partner with them to resolve the issue.

Amazon SES doesn’t only make the decision to communicate with our customers when there is a problem. SES also communicates with customers, when appropriate, earlier in the reputation management cycle to warn of a negative trend in sending. This can be seen in the review periods that are triggered when increases in bounces, complaints, or mailbox provider feedback is seen. These review periods give SES customers the ability and time to understand the problem, and to work on fixes to avoid serious reputation impact. Being involved early in the discovery phase of a sending event improves the customer experience without the need to negatively impact sending.

Conclusion

Maintaining a positive sending reputation necessitates a diligent approach to prevent abusive emails. The four pillars outlined serve as guidelines to improve email quality: prevention, monitoring, analysis, and response. This is an iterative process that requires moving fluidly between pillars.

About the author:

Dustin Taylor

Dustin Taylor

Dustin is the Manager of anti-abuse and email deliverability for Amazon SES. His focus is both external and internal in helping improve inbox placement for SES customers and finding new ways to fight email abuse. In his off-time he enjoys going bass fishing and is a hobbyist woodworker.

Phison Pascari X200 is the New Data Center SSD Player to Watch

Post Syndicated from Cliff Robinson original https://www.servethehome.com/phison-pascari-x200-is-the-new-data-center-ssd-player-to-watch/

Phison has a new Pascari X200 SSD. Pascari is the company’s new data center SSD brand and the X200 is a 3M IOPS PCIe Gen5 NVMe SSD

The post Phison Pascari X200 is the New Data Center SSD Player to Watch appeared first on ServeTheHome.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor (ars technica)

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

Ars technica looks
at
a a
recent report
on the Ebury root kit, with a focus on the 2011 compromise of kernel.org, which may have
been more extensive than believed at the time.

In 2014, ESET researchers said the 2011 attack likely infected
kernel.org servers with a second piece of malware they called
Ebury. The malware, the firm said, came in the form of a malicious
code library that, when installed, created a backdoor in OpenSSH
that provided the attackers with a remote root shell on infected
hosts with no valid password required. In a little less than 22
months, starting in August 2011, Ebury spread to 25,000
servers. Besides the four belonging to the Linux Kernel
Organization, the infection also touched one or more servers inside
hosting facilities and an unnamed domain registrar and web hosting
provider.

Analyze Elastic IP usage history using Amazon Athena and AWS CloudTrail

Post Syndicated from Aidin Khosrowshahi original https://aws.amazon.com/blogs/big-data/analyze-elastic-ip-usage-history-using-amazon-athena-and-aws-cloudtrail/

An AWS Elastic IP (EIP) address is a static, public, and unique IPv4 address. Allocated exclusively to your AWS account, the EIP remains under your control until you decide to release it. It can be allocated to your Amazon Elastic Compute Cloud (Amazon EC2) instance or other AWS resources such as load balancers.

EIP addresses are designed for dynamic cloud computing because they can be re-mapped to another instance to mask any disruptions. These EIPs are also used for applications that must make external requests to services that require a consistent address for allow listed inbound connections. As your application usage varies, these EIPs might see sporadic use over weeks or even months, leading to potential accumulation of unused EIPs that may inadvertently inflate your AWS expenditure.

In this post, we show you how to analyze EIP usage history using AWS CloudTrail and Amazon Athena to have a better insight of your EIP usage pattern in your AWS account. You can use this solution regularly as part of your cost-optimization efforts to safely remove unused EIPs to reduce your costs.

Solution overview

This solution uses activity logs from CloudTrail and the power of Athena to conduct a comprehensive analysis of historical EIP attachment activity within your AWS account. CloudTrail, a critical AWS service, meticulously logs API activity within an AWS account.

Athena is an interactive query service that simplifies data analysis in Amazon Simple Storage Service (Amazon S3) using standard SQL. It is a serverless service, eliminating the need for infrastructure management and costing you only for the queries you run.

By extracting detailed information from CloudTrail and querying it using Athena, this solution streamlines the process of data collection, analysis, and reporting of EIP usage within an AWS account.

To gather EIP usage reporting, this solution compares snapshots of the current EIPs, focusing on their most recent attachment within a customizable 3-month period. It then determines the frequency of EIP attachments to resources. An attachment count greater than zero suggests that the EIPs are actively in use. In contrast, an attachment count of zero indicates that these EIPs are idle and can be released, aiding in identifying potential areas for cost reduction.

In the following sections, we show you how to deploy the solution using AWS CloudFormation and then run an analysis.

Prerequisites

Complete the following prerequisite steps:

  1. If your account doesn’t have CloudTrail enabled, create a trail, then capture the S3 bucket name to use later in the implementation steps.
  2. Download the CloudFormation template from the repository. You need this template.yaml file for the implementation steps.

Deploy the solution

In this section, you use AWS CloudFormation to create the required resources. AWS CloudFormation is a service that helps you model and set up your AWS resources so that you can spend less time managing those resources and more time focusing on your applications that run in AWS.

The CloudFormation template creates Athena views and a table to search past AssociateAddress events in CloudTrail, an AWS Lambda function to collect snapshots of existing EIPs, and an S3 bucket to store the analysis results.

Complete the following steps:

  1. On the AWS CloudFormation console, choose on Create stack and choose With new resources (standard).
  2. In the Specify Template section, choose an existing template and upload the template.yaml file downloaded from the prerequisites.
  3. In the Specify stack details section, enter your preferred stack name and the existing CloudTrail S3 location, and maintain the default settings for the other parameters.
  4. At the bottom of the Review and create page, select the acknowledgement check box, then choose Submit.

Wait for the stack to be created. It should take a few minutes to complete. You can open the AWS CloudFormation console to view the stack creation process.

Run an analysis

You have configured the solution to run your EIP attachments analysis. Complete the following steps to analyze your EIP attachment history. If you’re using Athena for the first time in your account, you need to set up a query result location in Amazon S3.

  1. On the Athena console, navigate to the query editor.
  2. For Database, choose default.
  3. Enter the following query and choose Run query:
select 
eip.publicip,
eip.allocationid,
eip.region,
eip.accountid,
eip.associationid, 
eip.PublicIpv4Pool,
max(associate_ip_event.eventtime) as latest_attachment,
count(associate_ip_event.associationid) as attachmentCount
from eip LEFT JOIN associate_ip_event on associate_ip_event.allocationid = eip.allocationid 
group by 1,2,3,4,5,6

All the required tables are created under the default database.

You can now run a query on the CloudTrail logs to look back in time for the EIP attachment. This query provides you with better insight to safely release idle EIPs in order to reduce costs by displaying how frequently each specific EIP was previously attached to any resources.

This report will provide the following information:

  • Public IP
  • Allocation ID (the ID that AWS assigns to represent the allocation of the EIP address for use with instances in a VPC)
  • Region
  • Account ID
  • latest_attachment date (the last time EIP was attached to a resource)
  • attachmentCount (number of attachments)
  • The association ID for the address (if this field is empty, the EIP is idle and not attached to any resources)

The following screenshot shows the query results.

Clean up

To optimize cost, clean up the resources you deployed for this post by completing the following steps:

  1. Delete the contents in your S3 buckets (eip-analyzer-eipsnapshot-* and eip-analyzer-athenaresulteipanalyzer-*).
  2. Delete the S3 buckets.
  3. On the AWS CloudFormation console, delete the stack you created.

Conclusion

This post demonstrated how you can analyze Elastic IP usage history to have a better insight of EIP attachment patterns using Athena and CloudTrail. Check out the GitHub repo to regularly run this analysis as part of your cost-optimization strategy to identify and release inactive EIPs to reduce costs.

You can also use Athena to analyze logs from other AWS services; for more information, see Querying AWS service logs.

Additionally, you can analyze activity logs with AWS CloudTrail Lake and Amazon Athena. AWS CloudTrail Lake is a managed data lake that enables organizations to aggregate, immutably store, and query events recorded by CloudTrail for auditing, security investigation, and operational troubleshooting. AWS CloudTrail Lake supports the collection of events from multiple AWS regions and AWS accounts. For CloudTrail Lake, you pay for data ingestion, retention, and analysis. Refer to AWS CloudTrail Lake pricing page for pricing details.


About the Author

Aidin Khosrowshahi is a Senior Technical Account Manager with Amazon Web Services based out of San Francisco. He focuses on reliability, optimization, and improving operational mechanisms with his customers.

Анализ на политическата криза

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

Ще си позволя един (не толкова) кратък анализ на политическата криза. Тя започна през лятото на 2020 г., когато стана ясно за твърде много хора, че правоохранителните органи работят като бухалки, в „нечий“, а не в обществен интерес – както действията на НСО и след това МВР на Росенец, така и последващото влизане не прокуратурата в президенството. Върху това се насложи и разследването за „Осемте джуджета“.

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

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

Бонус към политическата криза беше неадекватността на “Има такъв народ”, които пропиляха два парламента (и може би за добро, в крайна сметка), за да дойде “Продължаваме Промяната” в третия и да формира четворната коалиция на кабинета “Кирил Петков”..

Тогава закрихме специализираното правосъдие, което беше една от основните бухалки. Но получихме спирачка от президента за реформата в спецслужбите, 4-тото колело (ИТН) постоянно генерираше шум и скандали, а конституционно мнозинство нямаше. Върху вътрешнополитическата сложност се добави и войната, която опъна сериозна геополитическа линия на разделение, и усложни допълнително формирането на мнозинства – докато преди нея разделенията бяха „корупция – антикорупция“, тогава разделенията станаха и по линията „Запад – Русия“, и ако разчертаем тези линии на един лист, в нито един квадрант не се събира мнозинство.

Затова след логичния неуспех на 48-ия парламент да излъчи правителство, в 49-ия единственият начин да се отключи политическата криза беше да се върнем към решаването на нейната първопричина – че за упражняването на власт (за важните неща, с голям риск и големи интереси) няма значение кой е министър и кой има мнозинство в парламента, а има значение кой „държи“ прокуратура и служби. И затова поставихме измененията в Конституцията на първо място, защото действащата ограничаваше всякаква възможност да се излезе от това блато. Преди една година казвахме, че това е „правителство на конституционната реформа“, защото то даде технологичното време за минаване през трите четения на измененията.

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

Но по-важно: измененията в Конституцията направиха възможна съдебната реформа през Закона за съдебната власт. И именно там отновно имаше „спирачка“ и отново се сблъскахме с първопричината за политическата криза.

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

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

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

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

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

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

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

The collective thoughts of the interwebz