Изтичането на лични данни от НАП

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

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

• Използвана е уязвимост в приложение, чрез което са достъпни данни от други приложения (недобре обмислен дизайн); 
• Използваната уязвимост е известна от 2012 година (липса на регулярни процеси за одитиране на софтуера). 

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

От техническа гледна точка има доста автоматизирани решения, които помагат за прилагането на такива процеси – анализиране на слаби места в IT инфраструктура, анализиране на софтуерен код спрямо известни атаки, penetration тестове. По отношение на процесите са важни следните неща:

• Ясно разписани критерии за одобряване/внедряване на софтуер, които са еднакви както за вътрешни, така и за външни разработчици (включително за out of the box решения), с които всички разработчици са запознати 
• Контролна функция в организацията, която проверява изпълнението на дефинираните критерии на регулярна база.
• Одитираща функция в организацията, която се грижи критериите да са актуални. 

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

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

• Да ограничи анализа само до данните, до които има нужда. Честно казано експорт на данни за над 1 милион души, не ми се струва добра практика. Ако анализът предполага обобщаване на такъв обем от данни, най-вероятно могат да се ползват BI инструменти в самата информационна система, вместо да се наливат в инструменти извън нея. 
• Ако се налага експортиране на данни от информационната система, да ограничи достъпа до тях само до хората, които са ангажирани със задачата. Фактът, че странично приложение е имало достъп до тях, води до допускането, че и голяма част от служителите на НАП също са имали достъп до тях.
• Да използва експортираните данни само за нуждите на анализа и да ги премахне след приключване на задачата. В медиите се появи информация, че част от данните са за периоди от преди повече от 10 години. За моите разбирания, това е повече от оперативния интерес на НАП, така че е вероятно съответните експорти са направени доста отдавна. 

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

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

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

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

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

Електронно банкиране с Firefox 34+

След upgrade на Firefox започнах да имам проблем с електроннота банкиране при ПИБ. Оказа се, че от Firefox версия 34 нататък, са премахнали window.crypto.signText функцията в резултат, на което не могат да се подписват платежни нареждания. Детайли за мотивите около премахването могат да се прочетат тук, а решение на проблемът е, чрез инсталиране на signTextJS плъгина от тук.

Честита национализация

След промените в пенсионното осигуряване, гласувани вчера, може спокойно да се приеме, че вторият стълб за осигуряване е зачеркнат. Твърденията, че това се прави заради хората и им се дава право на избор, са меко казано смешни и само наивници биха им се вързали. На практика, това което е прието, че парите отиват в НОИ, но имаш право да си ги запазиш във фонда. Само че предвид кратките срокове за упражняване на това „право“, то има цена и то доста висока. В моя случай, разходите, които ще трябва да направя биха ми излезнали колкото годишната доходност. За хората, които се намират в чужбина по една или друга причина през това време, упражняването на това право, ще стане икономически неизгодно. За мен тази поправка и на това разчита, че доста от хората или няма да са заинтересовани или няма да могат да упражнят „правото“ си на избор. За сметка на това, прехвърлянето на голяма сума пари от фондовете към НОИ, доста ще натисне цените на активите, определено ще прецака хората, които остават във втория стълб. Разбира се, то ще даде възможност на хора с доста финансов ресурс, да направят добри пари. Мисля, че това обяснява и защо се бърза толкова с тази поправка и се прави в нарушение на всякакви административни и морални правила. Ясно е КОЙ покрай далаверата с КТБ гушна едни пари и сега иска да ги мултиплицира, а пък на ГЕРБ им трябва финансов ресурс в бюджета, чрез който пък да могат да се похвалят какво са направили, както и да облажат някои обръчи.

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

ГЕРБ срещу майките 2

Предложението на Бойко Борисов към майките, осветено с малко повече детайли в тази статия на Дневник, е добра илюстрация за това, че демографията не е сред приоритетите на ГЕРБ. Ако трябва да говорим с цифри, офертата е всички майки да получават по-малко пари за майчинство, без да има нищо в замяна (детските градини не се строят с пари на НОИ, а вноските към НОИ не се променят). Най-малко засегнати са майките, които почти не са работили или си осигуряват на минимума. За целият период на майчинството ще получат грубо 1000 лева по-малко. Най-силно засегнати са майките осигуряващи се на максималния осигурителен доход. За тях офертата е да получат с около 6000 лева по-малко. Всички останали са между тези две граници. Майките, взимащи около средната за страната заплата, ще получат около 3000 лева по-малко.

Ако ГЕРБ смятат да намаляват периода на майчинските, то трябва да го правят за сметка на увеличаване на периода за изплащане на обезщетения близки до заплатата, както и да намалят периода, който се използва за пресмятане на размера на обезщетението. Последното е особено важно, ако искат да стимулират раждането на повече от едно дете. В момента има казуси, как майчинските за второто дете за 2-3 пъти по-ниски от майчинските за първото дете, без майката да си е сменяла работата или да има сериозни промени в заплатата.

Проблеми със сигурността на Microinvest Warehouse Open

Във Microinvest Warehouse Open има проблем със сигурността, който на няколко пъти съм повдигал. За мое съжаление, хората от Microinvest го неглижират. С настоящия си постинг бих искал да дам публичност на проблема, така че от една страна хората, които ползват продукта да преценят до колко той отговаря на техните разбирания за сигурност, а от друга да стимулирам хората от Microinvest да го отстранят.

Microinvest Warehouse Open, както и повечето складово счетоводни програми, принадлежат към класа програми, предоставящи интерфейс върху някаква база данни. С други думи казано съхранението, манипулирането и управлението на данните се извършва от някаква СУБД (в случая на Warehouse Open това е MySQL), а приложният софтуер ни предоставя по-удобен начин да се случва това (не ни се налага да пишем директно сложни SQL команди). Когато се налага да  се реализират някакви правила за достъп и промяна на данните сме изправени пред следната дилема – дали да ползваме функционалностите предоставени от СУБД или да направим нещо върху нея (ако е възможно), което да е реализирано в приложния софтуер.

Всяка себе уважаваща се СУБД предлага доста гъвкавост при управление на достъпа до данните. В повечето случаи не е трудно да се ограничи достъпа на потребителя до конкретна база данни, таблица, колони или редове в таблица, както и операциите, които може да прави върху дадени данни (да ги изтрива, променя по специфичен начин и т.н.). Имайки това в предвид, някак си съвсем естествено идва потребителите на приложния софтуер, да са потребители на СУБД. Разбира се, това може да наложи да се направят множество специфични изгледи на таблици или използването на stored procedures. Съответно, това усложнява структурата на базата данни и може би коства повече усилия да се реализира.

Другата възможност е сигурността да е реализирано в самия приложен софтуер. Най-често това става, като се съхранява таблица с потребители, информация за правата им за достъп и хешове на паролите им. Съответно, когато някой потребител се идентифицира в приложението, то проверява предоставената информация от съответната таблица. Ако всичко е успешно, то променя интерфейса си, съгласно зададените права за достъп. Предимството на този подход е че не се налага да се прави по сложна структура на базата данни и съответно времето за програмиране на приложението би било по-малко. Разбира се, това става на цената на редица недостатъци. За да може приложението да се закачи да СУБД, то трябва да използва потребител от СУБД. Този потребител, в термините на СУБД, трябва да има достъп за четене/промяна (поне) до данните, които управлява приложението. В частност и до таблицата с потребители на приложението. Основните рисковете, които крие тази реализация, са три:

• Данните за идентифициране пред СУБД трябва да се пазят в тайна. Разбиването на паролата на този единствен потребител, компрометира най-малко данните на използваното приложение. В същото време тази информация трябва да съхранява някъде, така че когато някой потребител иска да влезе в приложението, то да може да се закачи до СУБД.
• Ефективно всеки потребител на приложението има повече права, от колкото биха му били нужни за да си върши работата. Това от своя страна означава, че много по-лесно може да се използват грешки на самото приложение (sql injections, грешки в модела/интерфейса направата за достъп и т.н.).
• При злонамерени опити за прихващане на комуникациите между приложението и СУБД, чисто статистически най-вероятно е да има успех при потребителите, които най-често ползват приложението. Обикновено тези потребители (от бизнес гледна точка) не би трябвало да имат значителни права за работа върху данните. Така че компрометирането на техните account-и, не би трябвало да нанесе сериозни щети, ако управлението на сигурността на данните на приложението се извършва от СУБД. Когато самото приложение има грижата да управлява правата за достъп, то рискът от компрометиране на системата е значително по-висок.

Подходът за реализиране на системата за сигурност в приложния софтуер се ползва най-често в web базираните приложения. Като цяло крайният потребител има достъп единствено до интерфейса на приложението, така че възможностите му да прочете файла, в който приложението съхранява информацията за достъп до СУБД или да предприеме атаки върху комуникацията между СУБД и приложението са значително ограничени. Съответно негативните ефекти от реализирането на този подход са силно смекчени.

За съжаление това не е така при stand-alone приложенията. Ако чрез инструментите на операционната система би могло да се ограничат възможностите за атака (от компютъра на който работи приложението) на комуникацията между приложния софтуер и СУБД, то не е толкова лесно да се ограничи достъпа до файла, който съхранява информацията за достъп до СУБД. Като цяло затвореният софтуер разчита на security through obscurity подхода. Информацията се пази криптирана и се разчита, че само приложението знае алгоритъма и ключа който се използва за декриптирането и. Разбира се, този подход не работи при приложенията с отворен код, тъй като всеки би могъл до види използвания алгоритъм и ключ. За мое най-голямо учудване Microinvest Warehouse Open използва именно този подход.

Лесно може да видите информацията касаеща връзката до СУБД чрез:

cat ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep Db

Криптираната парола за достъп до MySQL се съхранява във value полето на DbPassword реда. Бърз поглед върху изходния код на Warehouse Open ни дава информация за използвания алгоритъм и ключ. Имайки тази информация, лесно може да видим паролата чрез тази команда:

cat  ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep DbPassword | cut -f4 -d'"' | openssl enc -des-cbc -a -d -K 4d6963726f696e76 -iv 1234567890abcdef; echo

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

Като цяло докато този проблем не бъде разрешен, не може да се разчита на правата за достъп на Warehouse Open. Съвсем тривиално е всеки да се сдобие с каквито права за достъп иска. Разбира се, това не добавя кой знае какъв допълнителен риск, ако всичко (приложен софтуер и СУБД) се върти на една машина, до която злонамерения потребител има физически достъп. В такава ситуация, макар и една идея по-трудно, могат да се случат доста неприятни неща. За съжаление, този проблем компрометира ситуации, в които машината, на която е разположена СУБД е добре физически и мрежово защитена.