Основные понятия и идеи "Общей методологии оценки безопасности информационных технологий"
"Общая методология оценки безопасности информационных технологий" - второй по важности документ (после "Общих критериев"), подготовленный в рамках "Проекта ОК". Основная цель "Общей методологии" - добиться объективности, повторяемости и воспроизводимости результатов оценки.
Следуя принципам структурной декомпозиции, разработчики выделили в процессе оценки три задачи (этапа):
-
входная задача;
-
задача оценки;
-
выходная задача.
Входная задача имеет дело с представленными для оценки свидетельствами (далее для краткости мы будем именовать их свидетельствами оценки). Ее назначение - убедиться, что версии свидетельств корректны и должным образом защищены.
Обычно для оценки представляются стабильные, официально выпущенные версии свидетельств, однако в ситуациях, когда оценка ведется параллельно разработке или доработке ОО, возможно предъявление рабочих версий. Оценщику вместе со спонсором этого процесса необходимо составить каталог и в дальнейшем производить конфигурационный контроль версий. Он обязан обеспечить защиту свидетельств от изменения и утери, а по окончании процесса оценки возвратить их, поместить в архив или уничтожить.
На всех этапах оценки должна обеспечиваться конфиденциальность.
Задача оценки в общем случае разбивается на следующие подзадачи:
- оценка задания по безопасности;
- оценка управления конфигурацией ОО;
- оценка документации по передаче ОО потребителю и эксплуатационной документации;
- оценка документации разработчиков;
- оценка руководств;
- оценка поддержки жизненного цикла ОО;
- оценка тестов;
- тестирование;
- оценка анализа уязвимостей.
Нередко проводятся выборочные проверки, когда вместо всего (относительно однородного) множества свидетельств анализируется представительное подмножество, что позволяет сэкономить ресурсы при сохранении необходимого уровня доверия безопасности. Размер выборки должен быть обоснован математически и экономически, но при анализе реализации объекта оценки он должен составлять не менее 20%.
Ошибки, обнаруженные при выборочной проверке, подразделяются на систематические и случайные.
После исправления систематической ошибки необходимо произвести новую выборку; после случайной этого не требуется.
Допускается выборочная проверка доказательств, тестов, результатов анализа скрытых каналов, выполнения требований к содержанию и представлению свидетельств, выборочное тестирование.
В остальных ситуациях такой способ можно применять только в исключительных случаях, когда полная проверка требует слишком много ресурсов по сравнению с другими действиями в процессе оценки или когда она не существенно увеличивает доверие безопасности. При этом необходимо обосновать допустимость и целесообразность выборочного подхода.
В "Общей методологии" специально подчеркивается, что сами по себе большие размеры и высокая сложность объекта оценки не оправдывают замены полных проверок выборочными, поскольку для оценки безопасности подобных объектов заведомо требуется много сил и средств.
Необходимый элемент оценки - проверка внутренней согласованности каждого из представленных свидетельств, а также внешней взаимной согласованности различных свидетельств.
Внутренняя согласованность проверяется в первую очередь для сущностей, имеющих несколько представлений: для спецификаций и проектов всех уровней, а также для руководств.
Проверка внешней согласованности производится для описаний функций, параметров безопасности, процедур и событий, связанных с безопасностью, поскольку эти описания могут содержаться в разных документах.
Внутренняя несогласованность высокоуровневых сущностей может иметь глобальные последствия для процесса оценки. Например, выявление противоречий в целях заставляет заново проанализировать требования и функции безопасности.
Разные подзадачи в процессе оценки могут выполняться в произвольном порядке или параллельно, однако существуют зависимости, накладывающие некоторые ограничения на очередность выполнения. Наиболее очевидное из них состоит в том, что анализ задания по безопасности должен выполняться до каких бы то ни было проверок объекта оценки.
Задание по безопасности среди других характеристик объекта оценки определяет его границы и спектр рассматриваемых угроз.
Следовательно, процесс и результат оценки одного и того же продукта в сочетании с разными заданиями могут быть разными. Например, если в нем содержатся средства межсетевого экранирования и поддержки виртуальных частных сетей (ВЧС), но в задании по безопасности предусмотрена исключительно защита внутренней сети от внешних угроз, то свойства ВЧС-функций важны лишь в контексте возможности обхода средств экранирования. Даже если ВЧС-функции не обеспечивают конфиденциальности сетевых потоков данных, продукт с таким заданием получит положительную оценку.
(Заметим, что набор проверяемых требований необходим при сертификации не только по "Общим критериям". Нередко производитель в рекламных целях ограничивается кратким "продукт сертифицирован", что, по сути, бессодержательно и может ввести в заблуждение потребителя, так как зачастую означает соответствие каким-либо условиям общего характера, вроде отсутствия недекларированных возможностей.)
Важным моментом, обычно вызывающим много вопросов, является анализ уязвимостей и стойкости функций безопасности.
Цель обоих видов проверки заключается в выявлении степени устойчивости объекта оценки по отношению к атакам, выполняемым нарушителем с определенным (низким, умеренным или высоким) потенциалом нападения.
Анализ уязвимостей применяется ко всем функциям безопасности; при этом не делается каких-либо предположений относительно корректности их реализации, сохранения целостности, возможности обхода и т.п.
Анализу стойкости подвергаются только функции безопасности, реализованные с помощью вероятностных или перестановочных механизмов, у которых и проверяется стойкость - базовая, средняя или высокая (базовая означает защищенность от нарушителя с низким потенциалом нападения). В принципе, все вероятностные функции можно считать уязвимыми, а подобный анализ классифицировать как анализ уязвимостей специального вида.
Для успешного нападения необходимо сначала идентифицировать, а затем использовать некоторую уязвимость. Оба действия оцениваются с точки зрения временных затрат, необходимой квалификации, уровня знаний об ОО, характера и продолжительности доступа к ОО, необходимых аппаратно-программных и иных ресурсов.
Перечисленные составляющие не являются независимыми. Высокая квалификация может сэкономить время, а специальное оборудование - упростить и ускорить доступ к ОО. Следовательно, если оценивать каждый параметр количественно, то результирующую функцию, характеризующую серьезность уязвимости, естественно сделать аддитивной.
В таблицах 2.1 - 2.5 содержатся условные баллы, присваиваемые параметрам уязвимости в зависимости от того, в какой диапазон или на какой уровень они попадают. Для получения общего рейтинга нужно выбрать по одному значению из обоих числовых столбцов всех таблиц и сложить эти десять чисел. При оценке стойкости функций безопасности фаза идентификации не рассматривается (предполагается, что уязвимость известна), поэтому достаточно выбрать и сложить пять чисел из последних столбцов.
| < 0.5 часа | 0 | 0 |
| < суток | 2 | 3 |
| < месяца | 3 | 5 |
| > месяца | 5 | 8 |
| Любитель | 0 | 0 |
| Специалист | 2 | 2 |
| Эксперт | 5 | 4 |
| Отсутствие знаний | 0 | 0 |
| Общедоступные знания | 2 | 2 |
| Конфиденциальные сведения | 5 | 4 |
| < 0.5 часа или доступ незаметен | 0 | 0 |
| < суток | 2 | 4 |
| < месяца | 3 | 6 |
| > месяца | 4 | 9 |
| Отсутствие оборудования | 0 | 0 |
| Стандартное оборудование | 1 | 2 |
| Специальное оборудование | 3 | 4 |
| Заказное оборудование | 5 | 6 |
Если уязвимость можно идентифицировать и/ или использовать несколькими способами, для каждого из них вычисляется рейтинг и из полученных значений выбирается минимальное, то есть уязвимость характеризуется самым простым методом успешного нападения.
В табл. 2.6 приведены диапазоны рейтинга, которые характеризуют стойкость функции безопасности.
| 10 - 17 | Базовая |
| 18 - 24 | Средняя |
| > 24 | Высокая |
В табл. 2.7 приведены диапазоны рейтинга, иллюстрирующие определенный потенциал нападения.
| < 10 | Низкий |
| 10 - 17 | Умеренный |
| 18 - 24 | Высокий |
| > 24 | Нереально высокий |
Отметим, что потенциал предполагаемых нападений на ОО выявляется дважды: при анализе задания по безопасности для выбора надлежащих мер противодействия и при анализе уязвимостей для определения достаточности выбранных мер и качества их реализации.
Рассмотрим пример анализа стойкости функции безопасности. Пусть доступ к информационной системе осуществляется посредством территориально разнесенных терминалов, работа за которыми не контролируется. Авторизованные пользователи проходят аутентификацию путем введения паролей, состоящих из четырех различных цифр. Если пароль введен неверно, терминал блокируется на одну минуту. Требуется оценить стойкость такой парольной защиты для заданного пользователя с известным нападающему входным именем. Для нападения выбран один терминал, временем ввода можно пренебречь.
Очевидно, число возможных парольных последовательностей составляет
10*9*8*7 = 5040
Для успешного подбора пароля методом полного перебора требуется примерно 2520 попыток, которые можно произвести за 42 часа, что больше суток, но меньше месяца. Никакой квалификации, знаний и/или оборудования для этого не нужно. Следовательно, чтобы определить стойкость функции, достаточно сложить два числа: 5 из табл. 2.1 и 6 из табл. 2.4. Сумма 11 позволяет сделать вывод, что данная функция безопасности обладает базовой стойкостью и является устойчивой к нападению с низким потенциалом.
Возвращаясь к трем основным задачам процесса оценки, рассмотрим последнюю, выходную задачу. Ее цель - сформулировать замечания и получить технический отчет оценки.
Текст с замечаниями не является обязательным. Он нужен, если в процессе оценки выявились какие-либо неясности или проблемы.
Технический отчет оценки - это главный выходной документ, от качества которого во многом зависит повторяемость и воспроизводимость результатов оценки, т. е. возможность их многократного использования. "Общая методология" предписывает следующую структуру подобных отчетов:
- введение;
- архитектурное (высокоуровневое) описание объекта оценки с рассмотрением основных компонентов;
- описание процесса оценки, примененных методов, методологий, инструментальных средств и стандартов;
- представление результатов оценки;
- выводы и рекомендации;
- список представленных свидетельств;
- список сокращений, словарь терминов;
- список замечаний.
Изучение "Общей методологии" полезно не только оценщикам, но и разработчикам, так как дает представление о вопросах, которые могут возникать в процессе оценки. К сожалению, более детальное рассмотрение этого документа выходит за рамки настоящего курса.
