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

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

Инцидентът

Към медиите, през имейл в безплатна руска имейл услуга, беше изпратен линк към архив с 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) – „Някои хора просто искат да гледат как света гори“. Ако приемем хипотезата, че не е един самотен хакер, а група хакери, потенциално свързани с друга държава, тогава мотивите приемат съвсем друг характер. А тази хипотеза не можем да я изключим изцяло на този етап.

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

Заключение

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

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

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

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