Пашков Юрий, Пашков Кузьма ^[1] — Lead InfoSec ^[2], EMC ^[3], VMWare ^[4] trainer @ training.muk.ua ^[5]

Утрачиваемое искусство доказательства защищенности. Часть 1 из 2. ^[6]

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

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

На интуитивном уровне логика рассуждений следующая: если формальная политика для модели является безопасной, то адекватная ей реальная политика в условиях реальной автоматизированной обработки также будет безопасной.

Последовательность действий при применении доказательного подхода следующая:
— для предметной области с известным алгоритмом обработки ценной информации формулируется несколько высказываний на естественном языке, определяющих «правильный» с точки зрения владельца порядок обработки информационных ценностей; иначе говоря, формулируется политика безопасности, которая в случае ее выполнения является безопасной (не причиняющей ущерба владельцу информационной ценности);
— полученная на предыдущем этапе политика формализуется в терминах одной из хорошо изученных моделей безопасности;
— выполняется формальное доказательство выполнимости утверждений политики безопасности. При этом выявляются необходимые и достаточные условия выполнения политики в терминах используемой политики безопасности; в результате доказательства выявляются условия обработки ценной информации, при которых требования политики безопасности оказываются выполнимыми;
— эти условия выполнения политики интерпретируются для реальной автоматизированной системы и реализуются в виде настроек встроенных механизмов и средств защиты.

Таким образом, при применении доказательного подхода интерпретация выполняется дважды — сначала в терминах формальной модели защиты выражается политика безопасности, затем в терминах механизмов и служб автоматизированной системы описываются условия безопасности политики, полученные в ходе доказательства защищенности.

5. Интерпретация предположений и условии безопасности

Функциональным назначением большинства современных автоматизированных систем является многопользовательский доступ с рабочих мест к большим объемам информации (базам данных). Как правило, взаимодействие между компонентами в таких АС осуществляется по принципам архитектуры «клиент – сервер». Для АС типа «клиент – сервер» характерна следующая логическая структура:
1) ОС рабочей станции, за которой работает пользователь АС;
2) клиентское приложение СУБД, запущенное на рабочей станции, и взаимодействующее с серверной частью СУБД;
3) ОС сервера АС, на котором хранятся база данных и (или) совместно используемые файлы;
4) серверная часть СУБД, являющаяся приложением, запущенным на сервере. Она производит централизованную обработку базы данных в соответствии с запросами с рабочих станций;
5) коммуникационная компонента, осуществляющая передачу информации между клиентской и серверной частями СУБД. Она в свою очередь состоит из трех частей: коммуникационной сети, осуществляющей передачу информации между рабочей станцией и сервером баз данных; коммуникационных драйверов ОС рабочей станции; коммуникационных драйверов сервера баз данных.

В то же время для АС этого типа можно выделить следующие аппаратные компоненты:
1) группа ПЭВМ, являющихся рабочими станциями;
2) группа ЭВМ, являющихся серверами БД и (или) файловыми серверами;
3) коммуникационная сеть, соединяющая серверы и рабочие станции, состоящая из оборудования следующих типов: каналов связи, неуправляемого сетевого оборудования, управляемого сетевого оборудования;
4) хранилище информационных носителей: резервных копий баз данных и программного обеспечения. В нем должен храниться эталонный экземпляр средства защиты информации (далее – СЗИ), системы управления базой данных (далее – СУБД), ОС сервера, ОС рабочей станции, а также утилиты для проверки целостности и рассчитываемые с их помощью контрольные суммы. В нем также должны храниться журналы регистрации СЗИ.

Интерпретация предположений и условий безопасности предполагает подкрепление на практике с помощью организационных мер, оборудования и программных средств предположений 1-5 и условий 1-3, сделанных в предыдущем пункте. Однако прежде чем устанавливать оборудование и конфигурировать программные средства, необходимо уяснить, как соотносятся параметры модели и особенности системы автоматизированной обработки.

Предположение 1. Предположение о том, что у каждого субъекта есть только один родитель, реализуется в большинстве операционных систем в виде механизма порождения процесса. При этом ОС должна поддерживать понятие субъекта как процесса.

Предположение 2. Предположение о том, что возможно моделирование функционирования системы последовательностью доступов активизированных субъектов системы к объектам системы означает, что операционная система поддерживает, начиная с определенного уровня интерфейсов, понятия объектов, субъектов и доступов. Понятно, что эти интерфейсы возникают в процессе загрузки ОС и из рассмотрения выпадают процессы, происходящие в реальных системах в ходе начальной загрузки до запуска механизмов защиты.

Предположение 3. Предположение о наличии единственного администратора и об отказе от передачи им прав другим пользователям может быть преобразовано в организационные меры, которые требуется включить в обязанности администратора.

Предположение 4. Отсутствие канала утечки ценной информации посредством объектов общего доступа. Это предположение может быть реализовано средствами операционной системы под контролем администратора.

Предположение 5. Предположение о порядке работы системы при попытке обращения субъекта, активизированного от имени некоторого пользователя, к объекту системы может быть реализовано оборудованием процессора и ядром безопасности операционной системы с помощью так называемого монитора ссылок.

Итак, если предположения верны и соблюдается политика безопасности, то несанкционированный доступ невозможен. Рассмотрим, при каких условиях может быть соблюдена политика безопасности. Оказывается, она может быть выполнена при соблюдении следующих условий:
■ условие 1 — идентификация и аутентификация;
■ условие 2 —разрешительная подсистема;
■ условие 3 — отсутствие обходных путей.
Интерпретируем теперь требования по защищенности, полученные нами при моделировании, применительно к автоматизированной системе, построенной по принципам архитектуры “клиент — сервер”.

1. Идентификация и аутентификация пользователей. Операционные системы сервера АС и рабочих станций должны обеспечивать идентификацию пользователей по уникальному пользовательскому идентификатору длиной не менее 6 символов. Для аутентификации пользователей должен использоваться пароль условно-постоянного действия длиной не менее 6 символов. Пароль должен устанавливаться администратором сервера АС таким образом, чтобы было исключено его легкое угадывание.

При установлении сеанса пользователя с ОС рабочей станции должны запрашиваться идентификатор и пароль пользователя. При установлении сеанса пользователя с сервером АС должны запрашиваться идентификатор и пароль пользователя. При установлении сеанса пользователя с сервером баз данных должны запрашиваться идентификатор и пароль пользователя. Пароль пользователя не должен храниться в файле на рабочей станции. Он должен быть защищен от раскрытия при передаче по сети.

2. Разрешительная подсистема. Серверы, сетевое оборудование и рабочие станции системы должны иметь включенную систему разграничения доступа к информации, не допускающую возможность НСД к информации, к которой данный пользователь не имеет права доступа, и разрешающую доступ к информации, к которой пользователь должен иметь доступ.

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

Операционная система сервера АС должна осуществлять регистрацию установления и окончания сеанса пользователя с сервером АС. Серверная часть СУБД должна осуществлять регистрацию установления и окончания сеанса пользователя с базой данных в файлах, доступных только администратору сервера. В параметрах регистрации указываются: время и дата входа/выхода субъекта доступа в систему (из системы) или загрузки останова системы; результат попытки входа: успешный или неуспешный — несанкционированный; идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа.

Должен проводиться учет всех защищаемых носителей информации с помощью любой их маркировки. Учет защищаемых носителей должен проводиться в журнале(картотеке) с регистрацией их выдачи/приема. В системе должна отсутствовать возможность получения доступа обычного пользователя к средствам модификации программного кода компонент системы. Должно осуществляться разграничение доступа в помещения, где размещены средства системы.

6. Реализация политики безопасности средствами защиты информации ОС

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

7. Выводы

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

Настоящая статья продемонстрировала возможности доказательного подхода для создания защищенных автоматизированных систем. Недостатком доказательного подхода является необходимость моделирования конкретной АС и политики защиты информации, принятой в организации. Однако свойства модели таковы, что при более детальном, чем приведено выше, моделировании операционной системы окажется, что условия выполнимости политики безопасности для разных организаций будут одни и те же.

Иначе говоря, условия теорем, доказывающих поддержку политики безопасности (включая соответствующую политику), можно формулировать без доказательства в виде стандарта. Такой подход впервые применили американцы в 1983 г., опубликовав проект стандарта по защите информации в ЭСОД (“Оранжевая книга”), где сформулированы требования гарантированной поддержки двух классов политик — дискреционной и политики MLS. Затем этот метод они применили в 1987 г. для описания гарантированно защищенных распределенных сетей, поддерживающих те же политики, и в 1991 г. для описания требований гарантированно защищенных баз данных. На основе этого метода был создан нормативный подход к построению систем защиты информации.

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

---

Продолжение следует. Ждем вопросы по обучению и сертификациям CISSP/CISM/CISA/Security+ по адресу PashkovK@muk.com.ua

---

Учебные курсы по информационной безопасности, которые ведет автор статьи (УЦ МУК — Киев) ^[2]
Ближайшие курсы по инфобезопасности в УЦ МУК ^[5] (Киев)
18 — 22 января 2016 MUK-S0101 SecurityPlus ^[7]
1 — 5 февраля 2016 MUK-S0102 CISA ^[8]
22-26 февраля 2016 MUK-S0105 CISSP/CISM 2015 ^[9]

Автор: МУК

Источник ^[10]