Молодогвардейцев 454015 Россия, Челябинская область, город Челябинск 89085842764
MindHalls logo

Статический анализ кода согласно руководящем документу ФСТЭК

Защита от несанкционированного доступа к информации
Часть 1.
Программное обеспечение средств защиты информации Классификация по уровню контроля отсутствия недекларированных возможностей

Полный текст документа

На самом деле статический анализ кода это далеко не только проверка синтаксиса, границ массивов и переполнения буфера. Такой аудит исходных кодов представляет собой лишь малую часть общего, комплексного и документально заверенного ФСТЭК (ранее Государственная техническая комиссия), статического анализа. В этой небольшой статье я попытаюсь кратко описать требования руководящего документа и его «видение» статического анализа, порассуждаю об использовании автоматизированных средств, способных выполнить пункты документа.

Что есть статический анализ на самом деле

Будучи еще Государственной технической комиссией при Президенте Российской Федерации наш горячо любимый ФСТЭК утвердил выше упомянутый руководящий документ, призванный разъяснить разработчикам и комиссии каким именно образом стоить проводить сертификацию программного обеспечения. Зачем нужна эта сертификация? На самом деле это очень полезная штука, говорящая громко и четко «Данное ПО безопасно, не содержит бекдоров и различных закладок и может смело использоваться для обработки конфиденциальной информации, даже на правительственном уровне». Звучит неплохо, правда? Открывает многие недоступные несертифицированным программным продуктам двери. Можно инсталлироваться в школах, больницах, госдуме…

Всего руководящим документом устанавливается четыре уровня контроля отсутствия недекларированных возможностей. Каждый уровень включает в себя минимальный набор требований и несет в себе большие привилегии.

Самый высокий уровень контроля — первый, достаточен для ПО, используемого при защите информации с грифом «ОВ» — особой важности.

Второй уровень контроля достаточен для ПО, используемого при защите информации с грифом «CC» — совершенно секретно.

Третий уровень контроля достаточен для ПО, используемого при защите информации с грифом «C» — секретно.

Самый низкий уровень контроля — четвертый, достаточен для ПО, используемого при защите конфиденциальной информации.

В тексте руководящего документа приводится определение. Статический анализ исходных текстов программ – совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных текстов программ. Таким образом, главная цель анализа это убедиться в достоверности документации и правдивости разработчика, а вовсе не оценить количество некрасивого кода и ошибок.

Итак, настало время обозначить главную суть — перечень требований к каждому уровню контроля.

Требование 4 уровень 3 уровень 2 уровень 1 уровень
1 Контроль полноты и отсутствия избыточности исходных текстов + + + =
2 Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду + = = +
3 Контроль связей функциональных объектов по управлению + = =
4 Контроль связей функциональных объектов по информации + = =
5 Контроль информационных объектов + = =
6 Контроль наличия заданных конструкций в исходных текстах + +
7 Формирование перечня маршрутов выполнения функциональных объектов + + =
8 Анализ критических маршрутов выполнения функциональных объекто + =
9 Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т. п., построенных по исходным текстам контролируемого ПО + =

«-» — нет требований к данному уровню;
«+» — новые или дополнительные требования;
«=» — требования совпадают с требованиями предыдущего уровня.

Средства автоматизации

Таким образом самым главным элементом руководящего документа является эта табличка. На самый низкий уровень достаточно выполнить пукнты 1 и 2, что звучит весьма логично. А если появилось желание писать софт для обработки данных с грифом секретности, то придется постараться.

Естественно, проверять все пункты руками никто не собирается, да и невозможно это. Нужно понимать, что проекты такого уровня содержат много очень много файлов исходного кода с огромным количеством исполняемого кода. Кроме того, нужно понимать, что проекты пишутся на великом множестве языков программирования с сильно отличающимся синтаксисами и парадигмой. Учесть все многообразие кажется невозможным.

Золотой мечтой ФСТЭК наверняка является раздобыть супер инструмент, который нажатием одной кнопки проверить все девять пунктов руководящей таблицы. Но такого, к сожалению, не существуют. Именно по этой причине до сих пор актуальны научные работы в этой области.

Но можно использовать множество различных инструментов и грамотную пост-обработку их результатов, чтобы добиваться ответов на вопросы руководящего документа. Я имел такой опыт для проектов на языке C++ и собираюсь более подробно его раскрыть в других публикациях. Сейчас в двух словах скажу, что есть достойные открытые анализаторы: Jscpd, CoFlo, Joern, RATS и другие. Жаль, что некоторые из них на данный момент заброшены, но что поделать.

Заключение

На самом деле, даже не смотря на то, что документ существует (и действует) с 1999 года, до сих пор вопрос об эффективной и быстрой сертификации стоит. На мой взгляд главная проблема тут это «вилка» с тем, что продукт для сертификации тоже должен быть сертифицированным и надежным, и требования к нему очень велики. Согласитесь, что некоторые требования с наскока кажутся в принципе непригодными к автоматизации. Но тема мне все равно интересна и я буду продолжать ее так или иначе затрагивать. Спасибо за внимание.