Ключевым вопросом при планировании сроков выпуска программного обеспечения на рынок является точная оценка временных затрат. При этом одним из самых сложно прогнозируемых этапов является этап подтверждения безопасности программы – сертификация. Именно большими и сложно прогнозируемыми временными затратами, а также дороговизной сертификата обусловлено нежелание большинства разработчиков сертифицировать свою продукцию на соответствие стандартам безопасности. В настоящее время большинство программного обеспечения сертифицируется только в условиях, когда заказчик требует наличия сертификата.
Создание общего подхода к оцениванию затрат на сертификацию сделает ее более доступной для широкого круга разработчиков и окажет положительное влияние на проблему безопасности программного обеспечения в целом.
Наименее прогнозируемым этапом при сертификации ПО является этап проведения сертификационных испытаний. Зная требования к предоставляемой информации и общепринятые методики проведения сертификационных испытаний можно достаточно точно спрогнозировать примерные временные и финансовые затраты. В настоящее время испытательные лаборатории при оценке затрат на проведение сертификационных испытаний в первую очередь руководствуются объемом анализируемых данных (количество строк ИТ и их объем в Мб), а так же состоянием производства и документации. Однако следует заметить, что данные характеристики не описывают, в полной мере, весь объем работ, который необходимо будет провести, при проведении сертификационных испытаний ПО. Это может привести к несоответствию объема работ по проведению сертификационных испытаний затраченным средствам (затраченные заказчиком средства либо не покроют стоимость работ по сертификации либо существенно их превысят). Следовательно, для более точной оценки затрат по сертификации ПО, необходимо оценивать не только объем исходных текстов, но и их сложность.
Введение
Программное обеспечение стало неотъемлемой частью современной жизни. Входя в состав автоматизированных систем, оно решает сложнейшие задачи управления и проектирования, обработки информации и другие не менее важные задачи. Разработкой ПО занимается множество организаций, большинство из которых не уделяет должного внимания контролю безопасности создаваемых программных продуктов. Следствием является существенный рост количества уязвимостей, выявляемых в программном обеспечении.
Сертификация программного обеспечения является, пожалуй, основным средством, позволяющим убедится в безопасности ПО. Проведение анализа исходных текстов ПО является базовым (вне зависимости от уровня контроля) требованием при проведении сертификационных испытаний ПО на соответствие требованиям безопасности. В целях обеспечения информационной безопасности ПО существует множество методик, основной задачей которых является выявление уязвимостей в ПО. Для оценки качества работы этих методик можно использовать множество характеристик, но необходимо отметить, что все они характеризуют качество работы. В настоящее время нет методики, позволяющей оценить временные затраты на проведение сертификационных испытаний.
- Система сертификационных испытаний
Организационную структуру системы сертификации программного обеспечения образуют: ФСТЭК России, Орган по сертификации, испытательная лаборатория и заявитель (Рисунок 1).
Рис. 1. Система сертификации программного обеспечения
В компетенции ФСТЭК России создана Система сертификации средств защиты информации по требованиям безопасности информации и установлены правила проведения сертификации средств защиты информации. Также ФСТЭК имеет возможность утверждать нормативные документы, на соответствие требованиям которых проводится сертификация средств защиты информации и программного обеспечения, и методические документы по проведению сертификационных испытаний. Все выданные сертификаты учтены в государственном реестре. Органы по сертификации средств защиты информации и испытательные лаборатории проходят аккредитацию на право проведения работ по сертификации, в ходе которой ФСТЭК России определяет возможности выполнения этими органами и лабораториями работ по сертификации средств защиты информации. Органам по сертификации средств защиты информации ФСТЭК делегирует часть своих полномочий. Они сертифицируют средства защиты информации, выдают сертификаты и лицензии на применение знака соответствия с представлением копий в ФСТЭК России и осуществляют инспекционный контроль за сертифицированными средствами защиты информации и учет. Испытательные лаборатории проводят сертификационные испытания средств защиты информации и по их результатам оформляют заключения и протоколы, которые направляют в соответствующий орган по сертификации средств защиты информации и изготовителям.
В настоящее время существует ряд метрик для определения объема и относительной сложности программ. Прежде всего следует отметить размерно-ориентированную метрику LOC (Lines Of Code), которая, для определения сложности ПО использует количество строк кода. Также следует отметить метрику Холстеда, определяющую объем (1) и сложность (2) программы в зависимости от количества функциональных и информационных объектов.
(1) |
|
(2) |
где Nfo и Nio – количество функциональных и информационных объектов, а Ufo и Uio – количество вызовов функциональных объектов (ФО) и использования информационных объектов (ИО). Однако существующие метрики не учитывают специфики проведения сертификационных испытаний. Например, не учитываются различия в требованиях для разных классов безопасности, а также специфические особенности существующих алгоритмов анализа программного обеспечения. При оценке сложности необходимо учитывать, что основной объем работ по сертификации осуществляется при проведении испытаний программного обеспечения в Испытательной лаборатории.
Исследования, проведенные на базе Испытательной лаборатории Средств защиты информации ПГУПС, показывают, что наиболее трудоемкими этапами процесса испытаний ПО является обработка результатов анализа, а также принятие решения о соответствии программного обеспечения требованиям безопасности. Практика проведения сертификационных испытаний показывает, что до 50% времени, необходимого на всю процедуру сертификации, затрачивается на сертификационные испытания (рисунок 2).
Рис. 2 – Система проведения сертификационных испытаний ПО
Сертификация программного обеспечения по требованиям безопасности предполагает проведение определенного множества испытаний и тестов, набор которых зависит от уровня контроля. Основными инструментами, при проведении испытаний являются статический анализ исходных текстов и динамический анализ исполняемых файлов ПО. Вне зависимости от используемого подхода, все методы анализа имеют примерно одинаковый алгоритм выполнения (рисунок 3).
Рис. 3 – Принципиальная модель анализа ПО
Исходя из методики проведения испытаний можно выделить следующие характеристики исходных данных, оказывающие влияние на время проведения испытаний (Таблица 1).
Таблица 1
Характеристики, влияющие на временные затраты
№ |
Характеристика |
Обозначение |
Исходные данные, к которым относится характеристика |
||
ИТ |
ИФ |
ФП |
|||
1 |
Количество файлов |
Nfl |
+ |
+ |
– |
2 |
Количество строк |
Loc |
+ |
+ |
+ |
3 |
Объем |
Size |
+ |
+ |
+ |
4 |
Количество логических операций |
Nlog |
+ |
– |
+ |
5 |
Количество ФО |
Nfo |
+ |
+ |
– |
6 |
Количество ИО |
Nio |
+ |
– |
– |
7 |
Количество вызовов ФО |
Ufo |
+ |
+ |
– |
8 |
Количество обращений к ИО |
Uio |
+ |
– |
– |
Зная характеристики, влияющие на время проведения испытаний, определим их влияние в зависимости от существующих классов требований к безопасности ПО (Таблица 2).
Таблица 2
Зависимость временных затрат на класс безопасности от характеристик
Характеристика |
Классы безопасности ПО (уровень контроля) |
|||
4 |
3 |
2 |
1 |
|
Fcnt |
+ |
+ |
+ |
+ |
Loc |
– |
+ |
+ |
+ |
Size |
+ |
+ |
+ |
+ |
Flog |
– |
– |
+ |
+ |
Focnt |
– |
+ |
+ |
+ |
Iocnt |
– |
– |
+ |
+ |
Foex |
– |
+ |
+ |
+ |
Ioex |
– |
– |
+ |
+ |
Теперь, зная требования к классу безопасности (уровню контроля отсутствия недекларированных возможностей) можем определить временные затраты на выполнение сертификационных испытаний для каждого класса.
Самые мягкие требования предъявляются к программному обеспечению в рамках четвертого класса безопасности. Основным инструментом является статический анализ, который включает контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов и контроль соответствия исходных текстов ПО его объектному коду. Для оценки временных затрат вполне подойдет оценка, основанная на количестве строк кода.
Третий класс безопасности расширяет требования четвертого класса в области статического анализа исходных текстов программ. В частности, необходимо выполнить контроль полноты и отсутствия избыточности исходных текстов на уровне ФО, контроль связей ФО по управлению и информации, контроль ИО, а также сформировать перечень маршрутов выполнения ФО. Предъявляются новые требования по проведению динамического анализа исходных текстов программ:
контроль выполнения ФО;
сопоставление фактических маршрутов выполнения ФО и маршрутов, построенных в процессе проведения статического анализа.
Следовательно, необходимо добавить зависимость от количества и частоты использования ФО и ИО. Для этого добавим зависимость от сложности программы, предложенную Холстедом, в расчет, основанный на подсчете количества строк кода(3).
(3) |
Для второго класса, помимо аналогичных требований, предъявляемых к третьему классу, необходимо выполнить следующие проверки:
контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне ФО;
синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;
формирование перечня маршрутов выполнения ФО;
анализ критических маршрутов выполнения ФО для заданных экспертом списков ИО;
сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в “Пояснительной записке”.
Для динамического анализа предъявляются следующие требования:
контроль выполнения ФО;
сопоставление фактических маршрутов выполнения ФО и маршрутов, построенных в процессе проведения статического анализа.
Исходя из требований третьего класса, можно рассчитать временные затраты (4).
(4) |
Наиболее полный набор требований безопасности предъявляется к первому классу, в котором добавляются такие требования как контроль соответствия исходных текстов ПО его объектному (загрузочному) коду с использованием сертифицированных компиляторов, а также семантический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных конструкций. Основное отличие данных требований заключается в том, что существенно больше времени тратится на семантический анализ исходных текстов (5).
(5) |
Так же необходимо учесть, что большой объем работ по анализу программного обеспечения выполняет эксперт. Значит необходимо добавить в расчеты корректирующий коэффициент, который отражает объем времени требуемый эксперту на выполнение одной технологической операции. Экспериментально установлено, что это время в среднем равняется 25 с. В ходе выполнения реальных сертификационных испытаний были рассчитаны временные затраты для двух программ (Таблица 3).
Таблица 3
Характеристики сертифицируемого ПО
|
Характеристики |
||||
Loc |
Nfo |
Nio |
Ufo |
Uio |
|
Приложение 1 |
600 |
3 |
9 |
7 |
15 |
Приложение 2 |
900 |
5 |
13 |
9 |
24 |
При этом временные затраты в полной мере отражают реальные затраты в условиях когда сертификационные испытания прошли в установленном режиме и не потребовалась корректировка исходных данных (Таблица 4).
Таблица 4
Распределение временных затрат в зависимости от класса безопасности
|
Временные затраты |
|||
|
O4 |
O3 |
O2 |
O1 |
Приложение 1 |
0:27:38 |
0:41:02 |
2:28:46 |
4:57:32 |
Приложение 2 |
0:39:32 |
1:08:08 |
5:39:28 |
11:18:57 |
Расхождение реальных затрат с рассчитанными составило не более 14%. Следует отметить, что предложенный подход находится в сильной зависимости от индивидуальных свойств эксперта, но аналогичная зависимость существует и в реальных условия проведения сертификационных испытаний.
Еще одним преимуществом предложенного подхода является что, что он позволяется оценить и проконтролировать эффективность работы эксперта.
Заключение
Внедрение единой методики оценивания сложности проведения сертификационных испытаний даст инструмент, позволяющий более точно оценить временные затраты. Это сделает получение сертификата безопасности более доступным для широкого круга разработчиков, а стоимость более обоснованной, что в свою очередь окажет положительное влияние как на качество конечного продукта, так и на его безопасность.
- Литература:
Безопасность программного обеспечения компьютерных систем / Казарин О.В. – Москва, МГУЛ, 2003. – 213с. - ISBN 5-283-01667
Выявление уязвимостей программного обеспечения в процессе сертификации / Марков А.С., Миронов С.В, Цирлов В.Л. и др., Научно-практический журнал «Информационное противодействие угрозам терроризма» №7 – М.: ФГУП НТЦ, 2006. – с. 177-186
Codermetrics: Analytics for Improving Software Teams / Jonathan Alexander - O’Reilly Media, 2011 – 262 с. - ISBN: 978-1-449-30515-4
ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом.
Метрическая оценка качества программ / Изосимов А.В., Рыжко А.Л. - М.: МАИ, 1989.
Начала науки о программах / Холстед М. - М.: Финансы и статистика, 1981.
Анализ методов проверки корректности программ / Еремеев М.А., Глухарев М.Л., Корниенко А.А., Сборник докладов 10 международной научно-практической конференции «Информационные технологии на железнодорожном транспорте «Инфотранс - 2005» – С-Пб.: ПГУПС, 2005. – с.276-280