Системный подход к проектированию информационной безопасности
Извините, буду использовать аббревиатуру ИБ.
Некоторые (или многие?) утверждают, что ИБ состоит из трех составляющих (триада: конфиденциальность, целостность, доступность), или других (пять, десять..) .
Очевидно, что в реальной жизни все сложнее. Частей мб больше, или меньше, а главное, что они динамичные, то есть изменяются во времени и в зависимости от задачи и ситуации.
Систему ИБ можно создавать, придерживаясь этих трех и/или других правил. Но оптимально ли это? Или ее нужно синтезировать, используя механизмы, заложенные, например, в системном подходе, то есть цели, критерии, ограничения, состояния, взаимодействие с окружающей средой, оптимизацию... Системный подход - это некий общий механизм разработки, философия техники .
Чтобы не было пустословия, возьму для примера задачу создания автоматизированной системы, пусть то отдельный компьютер (АРМ) для писателя, или корпоративный комплекс со множеством рабочих станций, серверов, облачных хранилищ, Интернет-порталов и т.д. Целевая функция такой системы описывает ее функционирование во взаимодейстии с оператором. Для писателя, это удобство плюс скорость составления и корректировки текста в любом месте и в любое время.
Входит ли ИБ в целевую функцию? Нет. А если сделать ИБ целевой функцией, то получим абсолютно черное тело.
Согласно системному подходу ИБ определяет ограничения. Поэтому не может быть постулатов для разработки подсистемы ИБ, будь то триада или гексада. Это только варианты выбора правил. Для писателя ИБ определяет динамический набор правил-запретов: делай копии, не оставляй свой комп без присмотра и пр. Правила могут быть реализованы организационно или автоматически (пароль на вход в комп, шифрование, копирование и т.д.).
Как и любое ограничение, подсистема ИБ может препятствовать выполнению целевой функции системы (конфликтовать с нею). Мы тратим время на вход в запароленный комп, быстродействие падает при шифровании и копировании...
Система описывается набором параметров состояния, которые составляют вектор состояния системы, зависящий от времени. Вектор может быть направлен в сторону от ограничений (писатель находится в защищенном месте), тогда подсистема ИБ должна отключаться, и ограничений в системе нет. Что это значит? Подсистема ИБ зависит от состояния системы, то есть должна адаптивно управляться в зависимости от этого состояния. Поэтому должна быть связанной с вектором состояния, то есть проектироваться в составе системы.
Систему можно проектировать множеством способов: по теориям, на основе опыта, методом тыка.. Согласно системному подходу система синтезируется, то есть создается с оптимальным качеством для заданной целевой функции, ограничений и критериев качества. Тогда все подсистемы, в том числе и ИБ будут соответствовать заданным критериям качества и ограничениям, то есть не будет (недо)ограничений или (пере)ограничений. Если вектор состояния, ограничения, критерии, среда могут быть описаны математически, то задача синтеза решается вычислением. В противном случае, это логическая задача. Но правила синтеза одинаковы.
Проверим это на примере синтеза автоматизированного рабочего места АРМ для писателя. Задача кажется тривиальной, но простота делает ее прозрачной. Я не могу описать ее математически, поэтому синтез логический. Из целевой функции (удобство и скорость написания текстов и добавления иллюстраций) вытекает такая структура АРМ: комп с ОС Windows (имеющей богатый набор редакторов, графики и API), интеллектуальный текстовый редактор и графический редактор. Ограничения: возможности оператора (писателя), обеспечение ИБ и пр. Если при синтезе не затрагивается ИБ, то ее можно было бы разрабатывать отдельно. И тогда моя заметка неверна. Ах нет, учитывая ограничения, накладываемые ИБ, комп и редакторы должны изначально строиться так, чтобы обеспечить защиту данных. Сделав список этих ограничений, получим перечень основных функций ИБ, в том числе, автокопирование данных, защита входа (пароль, антропометрия...), автошифрование данных, физическая защита и т.д. Почему «авто»? А чтобы снизить влияние ограничений, накладываемых на целевую функцию. Ведь это АРМ для писателя, а не сисадмина. Ну а для сисадмина будут другие ограничения, то есть другая подсистема ИБ.
Из той же целевой функции с учетом внешней среды (по отношению к АРМ) возникает необходимость обмена с внешними источниками и необходимость удаленного доступа (например, писателю в дороге пришла мысль, которую он должен сохранить через АРМ). Это добавляет функции ИБ. Таким образом, в результате синтеза ИБ мы получаем перечень функций подсистемы ИБ в различных ситуациях (дома, в дороге…).
Что здесь нового? Во-первых, подсистема ИБ проектировалась вместе с АРМ, накладывая ограничения на функциональность АРМ уже на этапе синтеза. Например, снижение уровня излучения компа. Или использование специальной ОС вместо Windows. Во-вторых, ИБ АРМ оказалась динамичной, то есть ограничения, накладываемые ИБ, менялись в зависимости от применения и внешней среды (адаптивная ИБ). В третьих, благодаря синтезу как оптимизации системы, мы снизили влияние ограничений ИБ, конфликтующих с целевой функцией. Прошу заметить явный конфликт ИБ с целевой функцией, который мы успешно преодолели.
Возможно, что тот же результат можно получить якобы и без системного подхода, используя постулаты ИБ (триада, гексада..). Если конечно проектировать ИБ вместе с ситемой (т.е. АРМ). Но на самом деле это не так, поскольку к постулатам обязательно придется прибавить свой опыт. Я бы назвал это эмпирическим системным подходом.
