Обобщение на теча на данни в НАП

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

Инцидентът

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

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

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

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

Как?

Няма официална информация как е станал пробивът, но на няколко места излезе слух, че е т.нар. SQL инжекция. Това звучи правдоподобно, така че ще коментирам него. SQL инжекциите са сред най-простите уязвимости – хакерът вкарва специално подготвен текст в дадено поле и получава контрол над базата данни, защото разработчикът не е „почистил“ входните данни (и не използва т.нар. prepared statements). Ако например искаме да използваме формата за вход в системата, то можем да допуснем, че проверката на потребителското име и паролата би изглеждало така: SELECT * FROM users WHERE username={params.username} AND password={transform(params.password)}. (transform, защото паролите никога не трябва да се пазят в явен вид).

Това е псевдо-код, с който виждаме, че параметрите, подадени от потребителя се „залепят“ за заявка, която се изпълнява към базата. Е, ако хакерът вместо потребителско име попълни друга валидна заявка в полето, тя ще се изпълни. Напр. след въвеждане, заявката би изглеждала така: SELECT * FROM users WHERE username=1;CREATE PROCEDURE exfiltrate …;–AND password=…. Създадената процедура може да бъде с произволен код, който да обхожда всички бази данни и техните таблици и да ги изпраща към определен IP адрес.

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

Защо?

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

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

Паралелно това, с измененията в Закона за електронното управление направихме две неща. По-маловажното беше, че създадохме опция Държавна агенция „Електронно управление“ да създаде програма за привличане на експерти от частния сектор, които краткосрочно да помагат за ИТ услугите на държавата. Нещо, което и аз правех тогава, но в мащаб. Нещо подобно на американските 18F/USDS. Това, излишно е да казвам, не се случва вече 3-та година.

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

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

Информационна сигурност

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

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

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

Течът, обаче, не значи, че всички системи в НАП са толкова „пробити“. Хакерите винаги атакуват най-слабото звено в системата. Именно затова информационната сигурност е трудно нещо (говорил съм неведнъж за това), и не е еднократно усилие. Нужни са редица от мерки и постоянно внимание към множество детайли. Рискът никога не е елиминиран на 100%, което е видно и от ежедневните пробиви в уважавани частни компании. Но една държавна институция няма право да допуска толкова прости за изпълнение (и за предотвратяване) пробиви.

GDPR

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

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

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

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

Мерките?

Какви мерки могат да се вземат на този етап. Краткосрочните: спиране на уязвимата услуга (вече направено), пълен одит на сигурността на всички системи не само в системата на Министерство на финансите, ами в цялата държава. Проверка дали всички информационни системи са включени в одита на Държавна агенция „Електронно управление“ и последователната им автоматизирана проверка за уязвимости.

Средносрочните са провеждане на обучения на всички служител в ИТ дирекциите за информационна сигурност и защита на данните и запознаване с приложимата нормативна уредба, ама не само като членове и алинеи, а и какво стои зад нея. Евентуално сертифициране на всички първостепенни и второстепенни разпоредители по ISO 27001 (стандарт за информационна сигурност), макар че те вече имат това задължение според наредбата за за общите изисквания за мрежова и информационна сигурност. Друга средносрочна мярка е насърчаване на т.нар. отговорно докладване (reposnisble disclosure). Хора, които откриват уязвимости и го докладват на органа, без да има риск да бъдат наказани (и дори срещу финансово възнаграждение). Такъв текст бяхме добавили в Закона за електронното управление, но при приемането не Закона за киберсигурност се е загубил.

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

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

Комуникацията

Комуникацията на официалните лица може да се раздели на две части – от една страна тази на експертите в НАП, начело с пиара Росен Бъчваров, и от друга страна всички останали.

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

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

Хакерът

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

Дали заловеният наистiна е извършител ще реши съдът. ГДБОП трябва да събере доказателства и от тях да следва еднозначно, че той е извършителят. Дали намереният файл, в който се съдържа името му е истински или не – не можем да кажем. Има много варианти, в които е истински. И такива, в които не е.

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

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

Какви биха били мотивите му – има много варианти. Просто адреналинът от това до пробиеш система на държавен орган е един мотив. Ако мога да цитирам любим филм (The Dark Knight) – „Някои хора просто искат да гледат как света гори“. Ако приемем хипотезата, че не е един самотен хакер, а група хакери, потенциално свързани с друга държава, тогава мотивите приемат съвсем друг характер. А тази хипотеза не можем да я изключим изцяло на този етап.

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

Заключение

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

За такива инциденти трябва да се носи политическа отговорност. Дали чрез оставки или на избори, не знам. Но всеки инцидент е следствие от нечие действие или бездействие.

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

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

19 коментара

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

  2. Също е забавно, че за регистрация в тази система като цяло човек има нужда само от ЕГН + 3 имена. Които са вече публична информация.

  3. Да, това с паролата в plain/text в Имотния регистър е безумие. Друго, което прави впечатление е, че по никакъв начин не можеш да валидираш, че правилно си си въвел телефона и, че системата успешно изпраща sms. Мисля, че трябва да им се обърне внимание на това.

  4. Това е си е местна инициатива и един етап от предизборната кампания . Все някой клател държавата, особено преди избори. Със сигурност няма да има наказани за пробива или уволнени. За мен няма съмнение откъде идва организацията. Участниците само се променят – загрижени полицаи с флашки, независими журналисти, вълшебници с sqlmap. Има си и причина да се ползват български и руски пощи. Някой ден като проникне наистина чужд обект ще се види каква е разликата в нещата.

  5. В един перфектен свят, в какъвто не живеем, но все пак – сега би бил момента (след теча от НАП) IT „боговете“ и сие да запромотират block-chain. Ако финансите, имотния, търговския и всякакви други регистри се пазеха в blockchain (за по-голяма сигурност с multisig портфейли), всички граждани щяха да спят спокойно за притежанията си. Сега е достатъчно нечестен нотариус (+ може би още 2-3 невнимателни), за да стане измама с изтеклите данни.

  6. Видно и явно е – магистралите са по!важни… жалко! 🙁

  7. Не знам защо наричат тоя пич „хакер“, като той си е просто скрипт киди… който не знае какво означава скрипт киди – да потърси във уикипедия.
    Той сам си казва в един свой пост:

    „Аз главно използвам SQLMap, Uniscan, Aircrack-ng, SET, Owasp-ZAP, Nikto, Fluxion, Nmap, ZED и не на последно място Metasploit.
    Hashcat ми е един от най-приятните за ползване софтуери, тъй като изучавам криптография и стенография като съм айляк…“

    (https://www.xakep.bg/forum/topic/497-какви-програми-използвате-за-pentesting/?tab=comments#comment-1416)

    Т.е. с тези софтуери, и прочитането на help-a им, и след изглеждането на няколко клипа в ютуб – всеки, ама наистина ВСЕКИ с малко повече от елементарни познания би могъл да хакне дори ЦРУ, ако имат „дупка“ в сайт, зад който са им базите данни. Поради просата причина, че сканираш на воля, и ако има „дупка“ – софтуерът ти казва точно къде е дупката. Никакъв хакер не е, а просто едно непорастнало дете, което си е повярвало, че е недосегаемо.

    Отделно, на много места го изкарват едва ли не герой, и че е бил натопен… щото видите ли – той бил ползвал Линукс… е, ползвал е линукс, ползвал е и Виндовс.
    Възможен сценарий:

    От виртуалка с Виндовс разглежда файлът, в същото време – пропуска тази подробност, и прави .zip архив под Линукс (т.е. от невиртуалката)…. и ето, .lock файлът е вътре. Елементарно недоглеждане. А може би просто не знае, че Libre Office прави .lock файл? (аз признавам, до момента – не знаех).

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

  8. Уважаеми господин Божанов,

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

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

    Колко от тези ЕГН-та (понеже у нас все още ЕГН-то е лични данни) биха излезли в разни pdf файлове при просто търсете в Google с нещо като „EГН filtype:pdf“?

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

  9. ГДПР важи за частни лица 🙂
    Не и за фирми. Учредителен акт, документи на фирми и т..н – ГДПР не ги лови!
    И да, получава се парадокс – но лицето Х, чиито данни са посочени в документите не е частно лице, а собственик/съсобственик/съдружник във фирма.

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

  11. – Gmail е по-сигурен от почти всички останали пощи
    – SQL инжекция си е, мисля, че няма различни мнения по темата
    – GDPR има изключения – ако национален закон урежда друго. ЗТР (ЗТРЮЛНЦ от скоро) отрежда кои данни са публични, така че GDPR в частта кое е публично и кое не, не се прилага.

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

  13. @Димитър – папките са схеми, файловете са таблици. Стандартна функционалност на базите данни е да дъмпят точно в CSV по този начин

  14. Хм… не можеш да ме убедиш, че в НАП имат схема QNEQNEV и подобни 🙂
    Нямам идея как дъмпи Oracle…. може и така да е. Но ако беше дъмп – щеше поне да е актуален. Според мен е свален стар бекъп. Не, че го няма варианта наистина това да е само част от нещата, все пак ГДБОП казаха, че имало общо 106 бази в компютъра на скрипт кидито….

  15. По последна информация, като са показали history-то на комадите, въведени от „хакера“ прави впечатление, че е брутално неграмотен, и си няма никакво понятие какво е Линукс, и ползва конзолата само за да се прави на интересен.
    Скрипт кидито вместо да напише:

    find . -exec touch -a -m -t 198911100130.09 * {} ;

    и да смени датата на файловете на веднъж, той… прави:
    cd imenapapka
    touch ….
    cd ..
    cd imenadrugapapka
    touch …
    cd imenatretapapka

    и так… чудно, ако папките бяха няколко милиона – какво щеше да направи? 🙂

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

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

    А машинното гласуване се провали заради необучени комисии основно.

  18. Здравейте Bozho,

    Позволете ми да не се съглася с Вас и по двата пункта.
    Причината за това са лични (подчертавам „лични“) наблюдения над случващото се, както и куп документи и официални справки.
    Нека започна с НАП.
    От години, сървърите на българската държавна администрация имат сериозен проблем. Информацията масово изтича през портове 3055, 3051, но най-вече през 1521. Ако сте запознати с това какво е Firedac и как функционира (това е втория любим елемент на професионалните киберпрестъпници и специализираните агенции след Indy) няма как да не знаете, че достъп до СУБД може да се реализира и на ФИЗИЧЕСКО ниво, заобикаляйки бизнес слоя. Лично аз ползвам подобен подход и на практика почти не ми се налага да използвам SQL. Не ми е нужно да се достига до HTTP/HTTPS (реално HTTP, който е доста високо в OSI йерархията) а се работи директно на ниво TCP/IP или IPX (защото има един два забравени от Бога и администрацията сървъри на Novell, които тихо си функционират от времето на Йордан Христосков). Но като се замисля на практика към момента Indy позволява директен достъп до над 280 мрежови протокола. Може да поставяте „защитни стени“, да изграждате VPN канал и пр. и пр. , но … има едни хора, които учат от други учебници и знаят, че RAD Studio (и в частност Delphi) не са „отживяла времето си антика“, а нещо изключително динамично развиващо се, което в други държави (Германия, Австрия, Япония, Австралия, република Корея, Китай, Русия, Бразилия, САЩ и др.) е въпрос на държавна политика. Тези хора правят разлика между „виртуални“ и „динамични“ методи, знаят какво е „критична секция“, но най-вече познават OSI-модела до най-малкия детайл и са в състояние да изградят за около 15 минути (стандартно тестово задание), мощен REST-сървър, пред който web-сървър на Apach изглежда като детска играчка. За тези хора няма значение дали някой ползва UNIX, Linux, Windows, iOS, Android, Xenix, P.A.L.D. или някакъв друг вид ОС, за която не сме и чували. Тези хора имат друго мислене и познават други езици за програмиране (за справка „Наръчник на кибертерориста“, доста весело четиво).
    Има термин „държавни комуникационни структури“. Има и конкретни лица, агенции и държавни фирми, които носят юридическа и наказателна отговорност за това, което извършват. Нека бъдем честни: Освен данни от НАП са изтекли и огромен обем данни от НЗОК, в т.ч. и т.н. „здравни досиета“. Извинете ме, но не ми казвайте, че това вече е в резултат на неправилна „вътрешна разработка“. Тук нещата са много по сериозни, а аз определено не съм журналист.

    Сега за „машинното гласуване“ и ролята на Информационно обслужване (нали знаете, че точно те са структурата, която обработва изборните резултати) в провала на машинното гласуване.
    Тук става още по забавно. Официално бе обявено, че за доставка кандидатстват три фирми, но РЕАЛНО фирмите бяха две. Едната предлагаше машините да се ИЗРАБОТЯТ, а другата ДА СЕ НАЕМАТ ПОД НАЕМ.
    Забавното бе когато се достигна до въпроса за сертифицирането. Тук бях посетен от представителите и на двете фирми, защото … Да сте чували какво е CC сертификат и други подобни?
    Всички оторизирани структури в България КАТЕГОРИЧНО отказаха да проведат сертификационна процедура и повярвайте, напълно подкрепям колегите.
    Но забавното идва на един по късен етап и тук вече опираме до много интересни документи.
    Na 11.04.2019 година лично съм изпратил писмено становище, относно цитирам: „Някои текстове в документацията за участие в състезателна процедура с договаряне за възлагане на обществена поръчка с предмет: „Наемане на 3 000 специализирани устройства с инсталиран софтуер за електронно машинно гласуване, както и логистично осигуряване и обслужване на специализираните устройства до секционните избирателни комисии в страната, обучение на персонал за работа с устройствата за произвеждане на избори за членове на Европейския парламент от Република България на 26.05.2019 г.“.
    В този документ изрично съм упоменал, цитирам: “ … Всички проблемни текстове са в т.5 от техническата спецификация за специализирани устройства за електронно машинно гласуване – Приложение към Решение № 14-ЕП от 27.03.2019 г.“.
    В заключението изрично съм записал следното:
    „… В изискванията има пропуски, които биха могли да доведат до дискредитиране на процеса на машинно гласуване.“
    Сега следва да се зададе въпросът: От кого и как са били изготвени двете концепции на общите изисквания за провеждане на търга? Кои специалисти са участвали в това? Има ли опит за укриване на документи, които би следвало да бъдат публично достъпни и пр. и пр. и пр.
    Но нещата не свършват до тук.
    На 17.07.2019 година лично съм информирал в писмен вид КОМИСИЯТА ЗА ЗАЩИТА НА ЛИЧНИ ДАННИ, за цитирам: „Относно заплаха за възможни нарушения на Регламент (ЕС) 2016/679“.
    В този ми сигнал, както и в редица други писмено подадени сигнали към оторизираните звена се цитира и името на Информационно обслужване, във връзка с федерално разследване на изключително тежки нарушения на киберсигурността на САЩ (за справка са посочени куп документи в т.ч. и такива уличаващи една от фирмите, чиито услуги ползва Информационно обслужване със забранената организация ИДИЛ).
    Извинете ме, но аз лично се доверявам на официалните документи, резултатите от влезли в сила наказателни постановления (в САЩ, не в България), както и на анализите на специализираните звена (отново САЩ и Централна Европа), а не на българските медии.
    За мен сме изправени пред много сериозен проблем и нещата трябва да бъдат детайлно проучени преди да се дават крайни оценки.
    Самият аз се въздържам от такива. Има достатъчно документи, които не са класифицирани и всеки може сам за себе си да проведе частно разследване. Това, което обаче няма да Ви хареса са изводите, до които неминуемо ще достигнете.
    Лично аз съм ужасен от случващото се и мащабите.

    Моля да ме извините, ако съм бил остър в излагането на доводите си.

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *