В рубрику "Управление" | К списку рубрик | К списку авторов | К списку публикаций
Часть 2
Алексей Марков, к. т.н., старший научный сотрудник, CISSP, эксперт по информационной безопасности
Валентин Цирлов, CISSP, эксперт по информационной безопасности
Планирование аудита безопасности программного кода
Провести полномаршрутное тестирование сложных программ с учетом всевозможных входных данных и условий среды в сколь угодно обозримое для человечества время невозможно. Технология security code reviews оптимизирует процесс аудита путем выделения фрагментов повышенного риска, которые затем анализируются ручным или полуавтоматизированным способом.
Для идентификации потенциально опасных фрагментов и их ранжирования могут быть использованы различные подходы, например: использование опросных листов (checklist), оценка метрической сложности ПО, предварительный анализ потенциально опасных операций (сигнатур). Технологии security code reviews опираются на определение подпрограмм и фрагментов кода, непосредственно связанных с безопасностью системы, например:
Кроме того, могут быть приняты во внимание экспертные оценки по ранжированию областей повышенного риска. В качестве исходных данных может служить информация о степени модификации кода по сравнению с предыдущими версиями, о выполнении кода по умолчанию, наличии ассемблерных вставок, возможности выполнения кода с повышенными привилегиями, частоте повторно используемого кода, возможности межсетевого обмена и т.п. В простейшем случае ранжирование областей повышенного риска можно осуществить на основе статистики о потенциально опасных операциях, полученной на этапе предварительного анализа программного продукта.
Сокращение проверок может идти по пути выделения точек входа и входных данных потенциально опасного фрагмента. Это позволяет исключить ненужный анализ и исправление уязвимостей, которые затруднительно реализовать злоумышленнику.
Конечно, в идеале аудит безопасности программного кода начинается с анализа проекта ПО, формирования моделей угроз ПО и идентификации классов уязвимостей, свойственных конкретному языку программирования.
Сертификация или аудит кода?
В заключение рассмотрения технологии аудита безопасности кода следует сказать о возможности ее развития в нашей стране. Дело в том, что в России повышение доверия к ПО регулируется путем его сертификации на отсутствие недеклариро-ванных возможностей в соответствии с руководящим документом Гостехкомиссии России. Требования руководящего документа и процедуры аудита безопасности кода в ряде случаев совпадают (табл. 1). Оба подхода предполагают наличие исходных текстов, спецификаций и соответствующей компиля-ционной среды. Российская нормативная база ориентирована на контроль целостности и полномаршрутное тестирование всего программного продукта (что на практике нереально) с целью выявления ошибок вообще, в то время как процедуры security code reviews направлены на скорейшее выявление реализуемых уязвимостей программного кода. Здесь приходится констатировать факт, что продукты, сертифицированные по 3-му и 4-му уровню контроля отсутствия недекларированных возможностей, не обладают достаточным уровнем доверия, так как неочевидно, подвергались ли они проверкам по безопасности кода или нет.
Слабым местом аудита, как, впрочем, и сертификации, является отсутствие механизма достоверной оценки полноты и достаточности проверок по безопасности. Сертификация и аудит безопасности программ в явном виде не касаются обнаружения скрытых каналов, но очевидно, что технология аудита не накладывает никаких ограничений по использованию статических и динамических процедур поиска и отслеживания любых дефектов, ошибок или нарушений безопасности.
Проведение аудита безопасности программного кода является актуальным практическим направлением повышения уровня ИБ систем, направленное на исключение первоисточников угроз безопасности программных ресурсов. Аудит безопасности кода как процедура нормоконтроля должен стать неотъемлемой частью современных систем менеджмента качества, СУИБ и аттестованных производств средств защиты информации.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #3, 2008