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

1. Антикорупционен софтуер
Божидар Божанов

2. За мен
● Софтуерен инженер и архитект
● Министър на електронното управление (2021-2022)
● Народен представител в 47-мото, 48-мото и 49-тото Народно събрание
● https://techblog.bozho.net
● Twitter: @bozhobg

3. Електронно управление
се постига с (много) софтуер

4. Какво зависи от софтуера в държавата?
● Разходване на средства
● Кокректност на данни
● Ограничаване на достъпа до чувствителни данни
● Разпределение на преписки
● Проследимост на процеси
● …

5. Две важни свойства
1. Софтуерът да спира “хартиената корупция”
2. Софтуерът да не генерира нови начини за “електронна корупция”

6. Основни антикорупционни принципи
● Одитируемост
● Проследимост
● Интегритет (защита срещу манипулация)
● Правно-значимо използване на криптография
● Адекватен IAM (идентичност и контрол на достъпа)
● Защита на данните от изтичане и загуба
● Прозрачност
● Случайно разпределени
● Валидация на данните
● Автоматизиран анализ на риска

7. Одитируемост
● Ако не можеш да одитираш една система, тя със сигурност генерира
корупция
● Актуален изходен код
○ Code-available за комерсиални системи
○ Пример: Тол системата
● Документация
● Достъп до базата данни от страна на институцията
● Мрежова архитектура и мерки за сигурност

8. Проследимост
● Одитна следа на всяко действие и събитие
○ Приложение, база данни, операционна система
○ Други - Firewall, SIEM, софтуер за виртуализация, софтуер за бекъп и т.н.
● Пример: тол системата
○ “Одит лога в базата данни е спрян, защото заема много място”
○ Кой може да добавя и изтрива автомобили от ignore-списъка?
○ Кой може да търси в историята на преминаванията?
○ Кой може да изтрива глоби директно в базата?
● Пример: ВетИС
○ “Как са се появили тези животни тук?”
○ Последен лог на сървъра - от преди няколко години
● Добър пример: ЦАИС ЕОП

9. Проследимост
● Одитна следа на всяко действие и събитие
○ Приложение, база данни, операционна система
○ Други - Firewall, SIEM, софтуер за виртуализация, софтуер за бекъп и т.н.
● Пример: тол системата
○ “Одит лога в базата данни е спрян, защото заема много място”
○ Кой може да добавя и изтрива автомобили от ignore-списъка?
○ Кой може да търси в историята на преминаванията?
○ Кой може да изтрива глоби директно в базата?
● Пример: ВетИС
○ “Как са се появили тези животни тук?”
○ Последен лог на сървъра - от преди няколко години

10. Проследимост
● Одитна следа на всяко действие и събитие
○ Приложение, база данни, операционна система
○ Други - Firewall, SIEM, софтуер за виртуализация, софтуер за бекъп и т.н.
● История на промените (напр. Търговския регистър)
● Пример: тол системата
○ “Одит лога в базата данни е спрян, защото заема много място”
○ Кой може да добавя и изтрива автомобили от ignore-списъка?
○ Кой може да търси в историята на преминаванията?
○ Кой може да изтрива глоби директно в базата?
● Пример: ВетИС
○ “Как са се появили тези животни тук?”
○ Последен лог на сървъра - от преди няколко години

11. Интегритет и правно-значима криптография
● Интегритет = истинска проследимост
● Tamper-evidence (merkle trees, hash chains, trusted timestamps)
● Гарантиране на интегритета на документи
○ В МЕУ включихме tamper-evidence в деловодството преди година и половина
● Публикуване на хешове (!!! :) )
● Електронни времеви печати (trusted timestamps) на всяко значимо
действие
○ Гаранции срещу антидатиране
● Електронно подписване на документи
○ Non-repudiation
● Публичност на печатите и подписите с цел проверка
● Частни ключове - в HSM или смарткарти

12. Identity and access management
● Проследимост, но на кого точно?
● Управление на акаунти, роли
● Интеграция с HR система за отразяване на напуснали служители и
отпуски
○ Пример: АМС
● Двуфакторна автентикация
● FIDO
● Privileged access management (PAM) за администратори
○ “Кой какво и защо е пипал”
○ Вътрешен саботаж на PAM
○ Добър пример: ЦАИС ЕОП

13. ● Криптиране
○ На ниво запис, с отделни ключове, за много чувствителни данни
● Анонимизиране/токенизиране/псевдонимизиране (напр. здравни данни в
НЗИС)
● Database activity monitoring (DAM)
● Управление на резервни копия и архиви
○ Криптиране, управление на ключове
● Защо?
○ Данни могат да се продават “на черно” - данни на ГРАО, ИАЛ, НЗОК, НСИ, НАП и др.
○ Изтичането на чувствителни данни може да създаде сериозни кризи
Защита на данните

14. ● Колкото повече данни са публични, толкова по-малко може да се
злоупотребява
● Когато нещо вече е публично, не може да се “почисти”
● Видимост върху системни проблеми
● В колкото по-реално време, толкова по-дборе
● Пример: СЕБРА, обществени поръчки
● Предложения по ЗДвП: отворени данни за актове и електронни фишове
Прозрачност

15. ● На дела, проверки, преписки
● Публично-проверимо случайно разпределение
● Сигурен източник на “случайност” (напр. Decentralized Randomness
Beacons)
● Централизирана система за случайно разпределение в съдебната власт
○ Отчитане на натоварване и специализация
● Примери: съд, прокуратура, контролни органи, Агенция по вписванията,
МВР…
Случайно разпределение

16. ● Ама това не е ли очевидно?
● “Корупционна кирилица”
● Валидиране на входа, а не ръчно пост-фактум (напр. НЗОК)
● Проверка на представителна власт
● Проверка на статус на лице (напр. починали лица)
Валидация на данни

17. ● Всяка система трябва да анализира корупционния риск и рискът от
измами
● Пример: онлайн регистрация на автомобили
● Пример: здравеопазване
○ анализ на шаблони на продажба на скъпоструващи лекарства
○ анализ на поведението на търговци при намаляване на количествата
● Конфигурируеми параметри, а не част от кода (знам, че е очевидно…)
Автоматизиран анализ на риска

18. Как?
● Закони
● Наредби
● Технически спецификации
● Договори
● Системни проекти
● Текущ и последващ контрол

19. В законодателните ми инициативи винаги
залагам някои от горните компоненти

20. Защо не са оправени?
● “Няма го кода”
● “Няма действащ договор”
● “Няма я фирмата”
● “Да, добре, ще го направим”
● “Няма нормативно основание”
● “Не е предвиден бюджет”

21. Правилните неща отнемат много усилия.
Грешните неща се случват “от само себе
си”.

22. Софтуерът може да ограничи значително
корупционния риск.

23. Благодаря!

24. Въпроси?