Време е да променим подходите за неутрализиране на заплахата от NDV

Наскоро писах за недекларирани функции. Бележката беше свързана с трудността да се оцени липсата на недекларирани способности за продукти с американски произход. Преди това имаше още записи (тук, тук и тук). Според мен сега има нужда от преразглеждане на този остарял подход към търсенето на недокументирани функции, като единствен метод за проверка не само на функционалността на защитния инструмент, но и на самата му сигурност. Отчасти тази стъпка вече е предприета от FSTEC в 21-ви ред, който за текущите заплахи от 1-ви и 2-ри тип (NDV съответно на системно и приложно ниво) предоставя не само оценка на липсата на NDV, като един от начините за неутрализиране на заплахи от 1-ви и 2-ри тип, но също така:

внедряване от разработчици на практики за защитено програмиране (SDLC)
прилагане на тестове за проникване.

Тук веднага възниква въпросът – как да докажем изпълнението на една от тези мерки? Е, повече или по-малко е ясно с pentest - мога да покажа или споразумение с външна компания за предоставяне на съответните услуги, или мои собствени правила за провеждане на pentest с дневник за тяхното изпълнение. А какво да кажем за SDLC? Декларация от производителя. Но в крайна сметка търсенето на NDV е предназначено да предпазва от случайни уязвимости или умишлени отметки. Как тогава да се доверим на декларацията на производителя? Нуждаете се от независима оценка? Засега няма отговори, но самият факт на разширяване на такъв списък и излизане извън рамките само на НДВ е впечатляващ.

Засега у нас остава "само NDV" за областта на държавните тайни и средствата за защита на информацията с определени класове и нива на сигурност съгласно 21-ви и 17-и заповеди на FSTEC. Да, и според ФСБ това е задължително нещо. Но както беше показано по-рано, предоставянето на източници, без коитода се удостовери липсата на NDV дори за 4 клас е нереалистична задача за много разработчици. Задънен край? Засега да.

От друга страна, търсенето на недекларирани характеристики не е необходимо навсякъде. Е, тайната е наред. Какво ще кажете за PD? Какво ще кажете за поверителността на правителството? Защо да харчите огромни суми пари за проверка на софтуерни или хардуерни източници, ако заплахата е очевидно неуместна или несравнима с разходите за търсене на NDV?

Може би е време да преосмислите подхода си? Бих Ви предложил първо да очертаете ясно кръга от организации, които подлежат на изискването за търсене на NDV и по-специално да премахнете темата за личните данни изобщо от там. Е, търсенето на NDV (дори в средствата за защита) не е реална мярка за неутрализиране на заплахи за този тип информация с ограничен достъп. И за банковата тайна също. И за данъци, одит и шест дузини други тайни също. Има по-евтини и не по-малко ефективни варианти за тази задача. И тук бих припомнил документите на американското министерство на отбраната и NIST, за които вече писах. Те заявяват, че за да се подобри качеството на кода (по отношение на неговата сигурност, надеждност, устойчивост и т.н.), е необходимо да се използват различни (по избор на клиента) механизми:

Инструменти за анализ на код (не само сорс, но и изпълним). Тук се намесват различни SAST/DAST/fuzzers и други подобни.
Анализ на уязвимости и заплахи. Тук всичко е ясно - скенерите за сигурност работят в режим черна кутия, сива кутия или бяла кутия.
"Ръчен" анализ на кода.
Пентести.
Моделиране на заплахи. Ето един пример може да бъде такъв. С разработчиците се извършва собствена развойна и организационна работа, намалявайки вероятността от въвеждане на NDV в софтуерния код. Или софтуерът е написан на толкова стар език, че никой не помни как се използва.и как да маркирате (помислете за историята на криптографите на Навахо по време на Втората световна война).
Проверка на обхвата на тестване/анализ.
Симулация / емулация.

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