Разработка модели КСЗИ

Определение условий функционирования КСЗИ

Разработка модели КСЗИ

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

• дифференцированный подход к защите различных АРМ и подсистем (уровень защищенности должен определяться с позиций разумной достаточности с учетом важности обрабатываемой информации и решаемых задач);

• унификацию вариантов применения средств защиты информации на АРМ с одинаковыми требованиями к защите;

• реализацию разрешительной системы доступа к ресурсам АС;

• минимизацию, формализацию (в идеале автоматизацию), реальную выполнимость рутинных операций и согласованность действий различных подразделений по реализации требований разработанных положений и инструкций, не создавая больших неудобств при решении сотрудниками своих основных задач;

• учет динамики развития автоматизированной системы, регламентацию не только стационарного процесса эксплуатации защищенных подсистем, но и процессов их модернизации, связанных с многочисленными изменениями аппаратно-программной конфигурации АРМ;

• минимизацию необходимого числа специалистов отдела защиты информации.

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

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

В таком случае, разрабатываемая система может быть небезопасной в силу одной из двух причин :

· есть ошибки в реализации механизмов защиты или механизмов управления ими;

· ошибочно, недостаточно полно, или неверно понято само определение того, что значит в отношении системы выражение "быть безопасной".

Для устранения первой причины необходимо применение современных технологий создания программного обеспечения в сочетании с принципами разработки, специфичными для выполнения требований безопасности.

Для устранения второй причины необходимо как можно точнее сформулировать понятие "быть безопасной" в отношении разрабатываемой системы.

Известно, что при разработке современных автоматизированных систем используется один из двух методов:

1. Нисходящий метод (метод "сверху-вниз"): сначала составляется общее описание системы; выделяются объекты системы; поэтапно увеличивается степень детализации объектов системы (выделение объектов в объектах и т.д.) - до момента окончания разработки.

2. Восходящий метод (метод "снизу-вверх"): сначала формулируются задачи системы; затем разрабатывается некоторый набор элементарных функций; на базе элементарных функций разрабатываются более крупные объектов системы - и так поэтапно разработка ведется до момента объединения отдельных объектов в единую систему.

Наибольшее распространение получил компромиссный вариант, при котором разработка системы в целом ведется нисходящим методом, а разработка отдельных объектов системы (в основном элементарных) - восходящим.

Наибольший интерес представляет нисходящий метод создания систем, так как этот метод позволяет задавать требования безопасности ко всей системе в целом и затем их детализировать применительно к каждой подсистеме.

Нисходящий метод разработки системы обеспечения безопасности может быть неформальным или формальным (Рис.1).

Неформальная разработка Формальная разработка

	Требования безопасности		Требования безопасности

(демонстрация)

(доказательство)

(тестирование) (тестирование)

Рис.1

Метод неформальной разработки применяется при создании относительно простых систем с небольшим числом объектов и очевидными алгоритмами их взаимодействия.

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

Основную роль в методе формальной разработки системы играет так называемая модель управления доступом. В англоязычной литературе для обозначения сходного понятия используются термины "security model" (модель безопасности) и "security policy model" (модель политики безопасности).

Эта модель определяет правила управления доступом к информации, потоки информации, разрешенные в системе таким образом, чтобы система всегда была безопасной.

Целью модели управления доступом является выражение сути требований по безопасности к данной системе. Для этого модель должна обладать несколькими свойствами:

· быть адекватной моделируемой системе и неизбыточной;

· быть простой и абстрактной, и поэтому несложной для понимания.

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

Моделирование требует значительных усилий и дает хорошие результаты только при наличии времени и ресурсов. Если система уже создана и имеется возможность сделать лишь отдельные изменения в отдельных местах существующей системы ("залатать дыры"), в любом случае маловероятно значительное улучшение состояния безопасности системы и моделирование поэтому будет непродуктивным занятием.

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