Yazov_ITKS

2.2. Понятие защищенной информационнотелекоммуникационной системы

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

Дело в том, что, во-первых, понятие защищенности связывается с определенным нормативным документом, выполнение требований которого является основанием считать, что ИТКС защищена в смысле выполнения этих требований. При этом указанные требования могут быть направлены:

на защиту в целом информации в ИТКС или в ее подсистемах и компонентах (в разных документах они представляются как «требования по защите», «требования к защите», «требования о защите» и др.);

на выбор технологии и разработку способов ЗИ в ИТКС, если приемлемые технологии и способы отсутствуют;

на построение СЗИ («требования к системе защиты») и могут касаться состава, структуры и характеристик системы защиты информации в ИТКС;

на выбор мер и средств защиты информации в ИТКС или разработку новых средств защиты, если существующие средства по своим характеристикам оказываются неприемлемыми.

151

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

В-третьих, сегодня не все нормативные документы «привязаны» к содержанию парируемых угроз безопасности информации, что приводит к необходимости дополнительного анализа возможностей такого парирования при реализации тех или иных требований по ЗИ, при этом без такого анализа зачастую весьма сложно утверждать, достаточен ли набор требований, взятых из выбранных нормативных документов, для парирования актуальных угроз в конкретной ИТКС, и, следовательно, считать ИТКС защищенной.

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

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

152

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

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

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

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

153

2.3. Общие подходы к проектированию информационно-телекоммуникационных систем в защищенном исполнении

Проектирование ИТКС в защищенном исполнении

– это процесс синтеза некоторого набора мер и средств защиты, обеспечивающего выполнение установленных требований по защиты информации. Как правило, такой набор мер и средств защиты реализуется в виде СЗИ в составе ИТКС (более подробно о СЗИ в 6 разделе).

Сегодня известно (применяются или только прорабатываются) несколько подходов к проектирования ИТКС в защищенном исполнении.

Первый подход – это синтез «снизу-вверх» (вариант «восходящего проектирования»), когда меры и средства начинают выбираться относительно каждого блока информации или каждого хоста, содержащего защищаемую информацию пользователя, с переходом к средствам защиты узла, совокупности узлов в составе сегмента ИТКС и т.д. Этот подход целесообразен для небольших компьютерных сетей, состоящих из одного-двух сегментов с несколькими хостами в каждом. При наличии сотен компьютеров, объединенных в большое количество сегментов с разными доменами безопасности (например, разными правилами разграничения доступа к информации в разных сегментах), предусмотреть возможные меры защиты при переходе от нижестоящего уровня проектирования к вышестоящему крайне сложно. Учитывая, что гарантировать полную защиту блоков информации на каждом уровне невозможно, приходится распределять усилия по защите на разных уровнях, что неизбежно приводит к итеративной процедуре проектирования и отходе от «чистого» синтеза «снизу-вверх».

154

Второй подход – это синтез «сверху – вниз» (вариант «нисходящего проектирования»), когда сначала выбираются меры и средства ЗИ, пригодные для всей ИТКС в целом, а затем уже подбирают при необходимости меры и средства ЗИ для сегментов и отдельных хостов. Следует отметить, что в научной литературе рассматривается несколько вариантов такого подхода, основанных:

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

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

155

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

3) на формировании так называемых функций безопасности информации (например, идентификации пользователей и процессов, аутентификации, межсетевого экранирования и т.д., см. раздел 5) и затем выбора минимального набора мер и средств защиты, реализующих все необходимые функции безопасности в ИТКС. Этот вариант нисходящего проектирования по сравнению с предыдущим более гибок, позволяет первоначально абстрагироваться от характеристик конкретных мер и средств защиты, однако, во-первых, связан с необходимостью формирования функций безопасности, которые в ряде отечественных нормативных документов даже не упоминаются, вовторых, основан на предположении, что функции безопасности реализуются абсолютно эффективно (при том, что методическое обеспечение оценки такой эффективности отсутствует), в-третьих, связан с необходимостью анализа реализуемости в средствах защиты выбранного набора функций безопасности.

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

156

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

– реализация остаточного принципа выбора мер и средств защиты, что может привести к недостаточной эффективности ЗИ в целом в ИТКС. Вариантом этого подхода является проектирование (выбор мер и средств защиты) по направлениям защиты ИТКС.

Четвертый подход – это комбинированный подход, при котором выбор мер и средств защиты осуществляется по направлениям ЗИ (см. раздел 2.2), то есть по подсистемам с реализацией нисходящего (второй вариант), восходящего или смешанного варианта проектирования ИТКС в защищенном исполнении. Этот подход позволяет разделить проектирование СЗИ по подсистемам, в нем, как правило, реализуется итеративная процедура выбора, когда осуществляется проверка соответствия выбранного варианта решения на том или ином уровне процесса проектирования решениям на других уровнях.

В отечественной практике не регламентируется ни один из описанных вариантов проектирования, а их выбор является прерогативой проектировщика. Чаще всего применяется четвертый вариант, что обусловлено рядом об-

157

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

2.4. Основные стадии и технологическая схема

проектирования информационнотелекоммуникационной системы в защищенном исполнении

Проектирование ИТКС в защищенном исполнении – это создание комплекта конструкторской, программной и эксплуатационной документации, необходимой для производства (построения и развертывания) и эксплуатации данной ИТКС и СЗИ в ее составе.

На практике, как правило, имеет место два варианта условий проектирования ИТКС в защищенном исполнении:

первый вариант - для новой ИТКС, когда СЗИ проектируется одновременно с проектированием этой ИТКС;

второй вариант – для модернизируемой ИТКС, когда в ходе модернизации проектируется новая СЗИ.

Рассмотрим порядок проектирования, регламентируемый национальными стандартами ГОСТ Р 51583-2014 «Порядок создания автоматизированных систем в защищенном исполнении» [12] и ГОСТ 34.601—90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» [13].

158

Для обоих из указанных вариантов проектирование включает в себя три стадии (рис. 2.1): предпроектную стадию, стадию разработки проекта и стадию ввода в действие ИТКС в защищенном исполнении или СЗИ в составе модернизированной ИТКС.

Рассмотрим первый из указанных вариантов, когда СЗИ создается для новой ИТКС. В этом случае проводится так называемое параллельное проектирование СЗИ и ИТКС, то есть уже с момента выработки общего замысла построения ИТКС предусматриваются должные роль и место мер и средств защиты информации. Проектирование СЗИ охватывает все этапы создания ИТКС: обоснование требований; разработку технических предложений, эскизное и техническое проектирование; выпуск рабочей документации, изготовление, испытания и сдачу системы заказчику [12]. Пояснения по некоторым этапам проектирования даны в табл. 2.1 [13].

Разработка и ввод в эксплуатацию вновь создаваемой ИТКС проводится в соответствии с техническим заданием (ТЗ). ТЗ на работы по созданию ИТКС является основным документом, определяющим требования, предъявляемые к ИТКС, порядок ее создания и приемку при вводе в действие. Для вновь создаваемых ИТКС ТЗ разрабатывают на систему в целом. Дополнительно могут быть разработаны ТЗ на составные части ИТКС, то есть на подсистемы ИТКС. Поэтому требования по ЗИ при создании ИТКС в защищенном исполнении должны включаться разделом в общее ТЗ на создание ИТКС или могут быть изложены в виде ТЗ на составную часть или дополнения к основному ТЗ на ИТКС.

159

Рис. 2.1. Стадии создания защищенной ИТКС (СЗИ в составе ИТКС)

Таблица 2.1 Типовое содержание работ по этапам создания ИТКС в защищенном исполнении

160