Что такое объекты кии
Руслан Рахметов, Security Vision
Какие же меры следует предпринимать для защиты значимых объектов критической информационной инфраструктуры (ЗОКИИ)? Приказ №239 говорит, что разработка мер защиты информации значимого объекта КИИ должна включать в себя анализ угроз безопасности и разработку модели угроз безопасности КИИ:
1. Анализ угроз включает в себя выявление источников угроз, оценку возможностей нарушителей (т.е. создание модели нарушителя), анализ уязвимостей используемых систем, определение возможных способов реализации угроз и их последствий. Модель нарушителя строится на основе предположений о потенциале атакующих, т.е. о мере усилий, затрачиваемых нарушителем при реализации угроз безопасности информации в информационной системе (при этом потенциалы нарушителей можно условно разделить на высокий, средний и низкий).
определение возможных негативных последствий от реализации угроз по результатам оценки рисков нарушения законодательства, бизнес-процессов и/или нарушения защищенности информации, что может привести к таким негативным последствиям, как нарушение законодательства, экономический или репутационный ущерб;
определение условий для реализации угроз безопасности информации, т.е. выявление уязвимостей, недекларированных возможностей, доступов к ИТ-системам, которые могут быть использованы злоумышленниками;
определение сценариев реализации угроз с помощью таблицы тактик и техник атакующих, приведенной в Методике;
оценка уровня опасности угроз безопасности информации путем анализа типа доступа, необходимого для реализации атаки, сложности сценария атаки и уровня важности атакуемых активов.
Вернемся к Приказу №239. После анализа и моделирования угроз следует переходить к внедрению контрмер. При этом следует иметь в виду, что внедряемые меры защиты не должны оказывать негативного влияния на функционирование самого объекта КИИ – этим подчеркивается, что приоритетом является непрерывность технологических процессов, остановка которых может сама по себе привести к инциденту на КИИ, например, к выходу оборудования из строя или даже аварии.
В списке организационных и технических мер, предусмотренных положениями данного приказа в зависимости от категории значимости объекта КИИ и угроз безопасности информации, указаны следующие пункты:
идентификация и аутентификация;
ограничение программной среды;
защита машинных носителей информации;
предотвращение вторжений (компьютерных атак);
защита технических средств и систем;
защита информационной (автоматизированной) системы и ее компонентов;
планирование мероприятий по обеспечению безопасности;
управление обновлениями программного обеспечения;
реагирование на инциденты информационной безопасности;
обеспечение действий в нештатных ситуациях;
информирование и обучение персонала.
Кроме этого, в Приказе №239 особо оговорено, что при использовании СЗИ для защиты КИИ приоритет отдается штатному защитному функционалу, а при реагировании на компьютерные инциденты в критической информационной инфраструктуре требуется отправлять информацию о них в систему ГосСОПКА. Указывается также на важность использования СЗИ, которые обеспечиваются гарантийной и/или технической поддержкой, а также на возможные ограничения по использованию программного/аппаратного обеспечения или СЗИ (видимо, имеются ввиду санкционные риски). Также указано, что на значимом объекте КИИ требуется запретить удаленный и локальный бесконтрольный доступ для обновления или управления лицами, не являющимися работниками субъекта КИИ, а также запретить бесконтрольную передачу информации из объекта КИИ производителю или иным лицам. Кроме этого, все программные и аппаратные средства объекта КИИ первой категории значимости должны располагаться на территории РФ (за исключением оговоренных законодательством случаев).
Категорирование объектов критической информационной инфраструктуры (КИИ). Практические примеры
Автор статьи:
Царев Евгений Олегович
Прежде чем приступить к категорированию объектов КИИ, нужно определиться с основными понятиями, которые разъясняются в Федеральном законе от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»:
Критическая информационная инфраструктура — объекты критической информационной инфраструктуры, а также сети электросвязи, используемые для организации взаимодействия таких объектов.
Объекты критической информационной инфраструктуры — информационные системы, информационно-телекоммуникационные сети, автоматизированные системы управления субъектов критической информационной инфраструктуры.
Субъекты критической информационной инфраструктуры — государственные органы, государственные учреждения, российские юридические лица и (или) индивидуальные предприниматели, которым на праве собственности, аренды или на ином законном основании принадлежат информационные системы (ИС), информационно-телекоммуникационные сети (ИТС), автоматизированные системы управления (АСУ), функционирующие в сфере здравоохранения, науки, транспорта, связи, энергетики, банковской сфере и иных сферах финансового рынка, топливно-энергетического комплекса, в области атомной энергии, оборонной, ракетно-космической, горнодобывающей, металлургической и химической промышленности, российские юридические лица и (или) индивидуальные предприниматели, которые обеспечивают взаимодействие указанных систем или сетей.
Значимый объект критической информационной инфраструктуры — объект критической информационной инфраструктуры, которому присвоена одна из категорий значимости и который включен в реестр значимых объектов критической информационной инфраструктуры.
Компьютерный инцидент — факт нарушения и (или) прекращения функционирования объекта критической информационной инфраструктуры, сети электросвязи, используемой для организации взаимодействия таких объектов, и (или) нарушения безопасности обрабатываемой таким объектом информации, в том числе произошедший в результате компьютерной атаки.
Исходя из этих определений, появляется ясность, что такое КИИ, что является «объектом КИИ», а что «субъектом», и в каких именно отраслях функционируют объекты и субъекты КИИ.
Все ИС, ИТС и АСУ субъекта КИИ — это объекты КИИ.
ИС – совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств.
ИТС – технологическая система, предназначенная для передачи по линиям связи информации, доступ к которой осуществляется с использованием средств вычислительной техники.
АСУ – комплекс программных и программно-аппаратных средств, предназначенных для контроля за технологическим и (или) производственным оборудованием (исполнительными устройствами) и производимыми ими процессами, а также для управления такими оборудованием и процессами.
Какие же объекты КИИ подлежат категорированию? На этот вопрос есть ответ в Постановлении Правительства РФ от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений» (ПП №127). В данном постановлении четко определено:
«Категорированию подлежат объекты критической информационной инфраструктуры, которые обеспечивают управленческие, технологические, производственные, финансово-экономические и (или) иные процессы в рамках выполнения функций (полномочий) или осуществления видов деятельности субъектов критической информационной инфраструктуры».
Прежде чем перейти непосредственно к детальному разбору методики категорирования объектов КИИ (согласно ПП №127) советуем Вам внимательно изучить наши предыдущие статьи по данной теме:
КАТЕГОРИРОВАНИЕ ОБЪЕКТОВ КИИ: РАБОЧИЙ АЛГОРИТМ
Если вы не специалист в области ИБ и комплаенса (compliance), то просто прочитав ПП №127, вам будет непросто самостоятельно выполнить работы в области категорирования объектов КИИ, поэтому лучше обратиться за консультацией к профессионалам, а также желательно изучить практические рекомендации по этому вопросу.
Первое, что нужно сделать – это составить для себя алгоритм категорирования объектов КИИ:
ПЕРЕЧЕНЬ ПОКАЗАТЕЛЕЙ КРИТЕРИЕВ ЗНАЧИМОСТИ
В таблице ПП №127 детально расписаны эти показатели. Например, по «социальному критерию» идет подразделение на «причинение ущерба жизни и здоровью людей», «прекращение или нарушение функционирования объектов обеспечения жизнедеятельности населения» и т.д. Потенциальный ущерб учитывается по охваченной территории и по количеству пострадавших людей, детальную информацию по всем показателям можно найти в данной таблице. Устанавливаются 3 категории значимости. Самая высокая категория — первая, самая низкая – третья, а также объекту КИИ может быть вообще не присвоена категория (т.е. «без категории»).
Исходя из нормативных документов, организации (субъекты КИИ) будут сами составлять перечень процессов (управленческие, технологические, финансово-экономические, производственные и др. процессы) и сами оценивать их критичность. Таким образом, количество объектов КИИ, которые войдут в перечень, зависит от решения самих организаций.
Важное примечание: может получиться так, что у субъекта КИИ вообще не будет объектов КИИ, подлежащих категорированию (т.е. они будут обозначены, как «без категории»). Однако надо учитывать, что «Перечень объектов КИИ» согласовывается с отраслевым регулятором (например, с Министерством энергетики, Банком России и пр.) и перечень объектов КИИ отправляется во ФСТЭК.
По вопросам оформления перечня объектов КИИ советуем ознакомиться с «Информационным сообщением» ФСТЭК от 24 августа 2018 г. N 240/25/3752
Какие именно исходные данные понадобятся для категорирования объектов КИИ, можно посмотреть здесь: Этап 5. Сбор исходных данных для категорирования объектов КИИ.
КАКАЯ ИНФОРМАЦИЯ ПОНАДОБИТСЯ ДЛЯ ПОДАЧИ ВО ФСТЭК?
КАК ОПРЕДЕЛИТЬСЯ ПО СРОКАМ?
ПРАКТИЧЕСКИЕ ПРИМЕРЫ ПО КОНКРЕТНЫМ ОТРАСЛЯМ И ОРГАНИЗАЦИЯМ
Изучив НПА и алгоритм категорирования объектов КИИ (см. выше) можно непосредственно приступить к практике. Здесь хотелось бы дать ряд советов и показать практические кейсы для организаций финансовой и банковской сферы.
Это говорит о том, что не каждый банк или финансовая структура вообще подпадает под законодательство о КИИ. Надо помнить, что категорируем мы не субъект, а объект КИИ, для каждого объекта КИИ будет присвоена своя категория, оценку последствий инцидента надо делать для каждого объекта.
Формирование комиссии:
На начальном этапе нужно сформировать комиссию. Подробнее об этом можно прочитать по ссылке: Этап 1. Создание комиссии по категорированию объектов КИИ (там же и образец «Приказа о создании комиссии по категорированию КИИ»).
Определение процессов:
Затем необходимо определиться с процессами, которые есть в организации, составить их полный перечень. На этом этапе нам не обойтись без помощи специалистов и руководителей различных подразделений. Рассмотрим, как действовать, на примере банка. Как правило, основные виды деятельности организации уже задокументированы, специалисту ИБ надо внимательно изучить учредительные и др. документы (лицензии, сертификаты), для банков опираемся на Федеральный закон от 02.12.1990 N 395-1 «О банках и банковской деятельности» и нормативные документы Центрального Банка РФ.
Виды деятельности банка по Код ОКВЭД 64: «Деятельность по предоставлению финансовых услуг, кроме услуг по страхованию и пенсионному обеспечению». Затем, исходя из видов деятельности, необходимо прописать бизнес-процессы в финансовой организации. Есть различные классификации бизнес-процессов в банковской сфере (в конкретном банке они, как правило, уже задокументированы).
Рассмотрим типовой пример (источник):
Основные бизнес-процессы банка:
Обеспечивающие бизнес-процессы банка:
Управляющие бизнес-процессы банка:
Рис.1. Бизнес-процессы банка (типовой пример)
Переходим от процессов к критическим процессам:
Для начала ответим на важный вопрос: нарушение (или остановка) каких процессов в банке приведет негативным экономическим последствиям, согласно ПП №127? Т.е. другими словами, в ходе категорирования мы попытаемся решить, попадают ли возможные последствия от компьютерных инцидентов на объекте КИИ (ИС, ИТС, АСУ) в категории значимости (ПП 127).
Как выделить из всех процессов именно критические и связать с ними объекты КИИ видно на рис 2. Например, Процесс 2 не критический.
Рис 2. Выявление критических процессов
Далее переходим от процессов к объектам КИИ:
Выделяем объекты КИИ, которые обрабатывают информацию, необходимую для обеспечения выполнения критических процессов, т.е. осуществляют управление, контроль, мониторинг критических процессов.
Для соответствия процессов и объектов можно составить такую простую таблицу:
Таблица 1. Объекты КИИ и процессы
Например, в качестве объектов КИИ в банке есть:
На этом этапе уже можно занести объекты КИИ в «Перечень объектов КИИ».
Принимаем решение о значимости объекта КИИ: перечень объектов у нас есть, также построена взаимосвязь объектов с процессами (Таблица 1).
Далее оцениваем:
Для этой работы нам потребуется: «Модель угроз», «Модель нарушителя», а также статистика по компьютерным инцидентам. Как правило, в банках есть свои службы ИБ, у которых имеются политики безопасности и др. документы по ИБ, поэтому, думаем, что проблем с такими данными не должно быть. В помощь службам ИБ: методические документы ФСТЭК России и «Основные положения базовой модели угроз и нарушителей безопасности информации» прил. А ГОСТ Р 57580.1-2017.
Как оценивать?
Для более точной оценки при категорировании объектов КИИ, мы составили небольшой опросник. На вопросы желательно отвечать точно: «да» или «нет».
Таким образом, процесс принятия решения о категорировании объектов КИИ проходит на основании «моделирования угроз». Для финансовых расчетов возможных потерь и убытков согласно табл. ПП 127 п. 8,9,10. желательно привлечь специалистов из экономических подразделений банка.
После проведения категорирования объектов КИИ составляется «Акт категорирования объектов КИИ», который отправляется во ФСТЭК в установленные законом сроки.
Обеспечение безопасности значимых объектов критической информационной инфраструктуры в рамках 187-ФЗ. Приказы ФСТЭК России №235 и 239
Руслан Рахметов, Security Vision
Обеспечение безопасности КИИ
Приказ ФСТЭК о безопасности КИИ
В прошлой публикации мы рассмотрели основные этапы процедуры категорирования объектов критической информационной инфраструктуры (далее ОКИИ), по результатам которой субъект критической информационной инфраструктуры (далее субъект КИИ) выявляет ОКИИ и присваивает им категории значимости. В данной статье мы подробно рассмотрим нормативные требования, регламентирующие обеспечение безопасности значимых объектов критической информационной инфраструктуры (далее ЗОКИИ), которые содержатся в Приказах ФСТЭК России № 235 и № 239.
Подход к обеспечению безопасности ЗОКИИ следует начинать с Приказа ФСТЭК России № 235, который предписывает субъекту КИИ создание системы безопасности ЗОКИИ. Под системой здесь понимается совокупность правовых, организационных, технических и прочих мер, которые должны быть направлены на обеспечение безопасности и устойчивого функционирования ЗОКИИ при проведении в отношении них компьютерных атак.
Обеспечение безопасности критической информационной инфраструктуры в рамках системы безопасности ЗОКИИ должна решать задачи по предотвращению неправомерного доступа к информации, недопущению воздействия на технические средства обработки информации, восстановлению функционирования ЗОКИИ и осуществлять непрерывное взаимодействие с государственной системой обнаружения, предупреждение и ликвидация последствий компьютерных атак (ГосСОПКА).
Создаваемая субъектом КИИ система обеспечения безопасности ЗОКИИ должна соответствовать ряду требований.
1. Требования к силам
К силам обеспечения безопасности ЗОКИИ в первую очередь относятся подразделения (работники), которые непосредственно являются ответственными обеспечение безопасности. Кроме того, к силам относятся структурные подразделения субъекта КИИ, которые эксплуатируют или обеспечивают функционирование ЗОКИИ.
На подразделения или работников, которые являются ответственными за безопасность критической информационной инфраструктуры в части защиты ЗОКИИ, в обязательном порядке возлагаются следующие основные функции:
— разработка предложений по совершенствованию организационно-распорядительной документации (ОРД) по безопасности ЗОКИИ;
— проведение анализа угроз и выявления уязвимостей;
— обеспечение реализации требований по обеспечению безопасности ЗОКИИ;
— реализация организационных мер, применение СЗИ и их эксплуатация;
— осуществление реагирования на компьютерные инциденты,
— организация периодических оценок соответствия ЗОКИИ требованиям по безопасности,
— подготовка предложений по совершенствованию системы и повышению уровня безопасности.
Здесь важно отметить, что Приказом не допускается возложение на структурное подразделение по безопасности, специалистов по безопасности функций, не связанных с обеспечением безопасности ЗОКИИ или обеспечением информационной безопасности субъекта КИИ в целом.
2. Требования к средствам
Данные требования касаются применяемых для обеспечения безопасности ЗОКИИ программных и программно-аппаратных средств защиты информации. К таким средствам относятся: средства защиты от несанкционированного доступа, межсетевые экраны, средства обнаружения вторжений, средства предотвращения вторжений, средства антивирусной защиты, средства контроля и анализа защищенности, средства управления событиями безопасности, средства каналов передачи данных.
Документ предписывает использовать для защиты ЗОКИИ сертифицированные средства или средства, прошедшие оценку соответствия в форме испытаний (приемки). Кроме того, все применяемые средства защиты должны быть обеспечены гарантийной, технической поддержкой со стороны разработчиков.
3. Требования к организационно-распорядительным документам
Состав и формы организационно-распорядительной документации разрабатываются субъектом КИИ самостоятельно с учетом сферы и особенностей его деятельности. При этом ОРД должна в обязательном порядке определять следующие аспекты:
— Цели и задачи обеспечения безопасности ЗОКИИ;
— Основные угрозы и категории нарушителей;
— Основные организационные и технические мероприятия;
— Состав, структуру и функции системы безопасности;
— Порядок применения, формы оценки соответствия ЗОКИИ и средств защиты информации требованиям по безопасности;
— Планы мероприятий по обеспечению безопасности ЗОКИИ;
— Модели угроз в отношении ЗОКИИ;
— Порядок реализации мер и проведения испытаний (приемки) средств защиты информации;
— Порядок реагирования на компьютерные инциденты;
— Порядок информирования и обучения работников;
— Порядок взаимодействия между подразделениями субъекта КИИ при решении задач обеспечения безопасности ЗОКИИ;
— Порядок взаимодействия с ГосСОПКА;
— Правила безопасной работы сотрудников субъекта КИИ на ЗОКИИ и действия при возникновении компьютерных инцидентов.
4. Требования к функционированию
Здесь Приказ ФСТЭК России №235 предписывает, что внутри субъекта КИИ должны быть внедрены и выстроены следующие процессы по обеспечению безопасности ЗОКИИ:
— Планирование и разработка мероприятий (ежегодных или более длительных);
— Реализация (внедрение) мероприятий (организационные и (или) технические);
— Контроль текущего состояния безопасности ЗОКИИ (не реже чем раз в 3 года);
— Совершенствование безопасности ЗОКИИ (предложения в план).
Важно отметить, что все эти процессы должны сопровождаться и подтверждаться различной документацией (отчетами, актами, протоколами, приказами), так как впоследствии эти документы могут являться предметом проверки со стороны регулятора.
Перейдем к следующему, не менее важному Приказу ФСТЭК России № 239. Данный Приказ ФСТЭК достаточно подробно описывает требования к обеспечению безопасности на всех стадиях жизненного цикла ЗОКИИ.
1. Создание или модернизация
При создании или модернизации подсистемы безопасности ЗОКИИ требования устанавливаются в техническом задании. Их содержание должно быть следующим:
— цель и задачи обеспечения безопасности ЗОКИИ;
— категория значимости ЗОКИИ;
— перечень нормативных правовых актов, методических документов и стандартов, которым должен соответствовать ЗОКИИ;
— перечень типов объектов защиты ЗОКИИ;
— требования к организационным и техническим мерам;
— этапы работ по созданию подсистемы безопасности ЗОКИИ;
— требования к применяемым программным и программно-аппаратным средствам;
— требования к защите средств и систем, обеспечивающих функционирование ЗОКИИ;
— требования к информационному взаимодействию ЗОКИИ с другими ОКИИ или ИС, АСУ ИТКС;
— требования к составу и содержанию разрабатываемой документации.
При разработке организационных и технических мер по обеспечению безопасности ЗОКИИ в обязательном порядке должны быть осуществлены:
— анализ угроз и разработка модели угроз безопасности информации;
— проектирование подсистемы безопасности ЗОКИИ;
— разработка рабочей документации в части обеспечения безопасности ЗОКИИ.
Требования к организационным и техническим мерам принимаются в зависимости от ранее присвоенной категории значимости ЗОКИИ и актуальных угроз безопасности, реализация которых может привести к прекращению или нарушению функционирования ЗОКИИ. Общий перечень организационных и технических мер, которые необходимо применять, представлен ниже:
— идентификация и аутентификация (ИАФ);
— управление доступом (УПД);
— ограничение программной среды (ОПС);
— защита машинных носителей информации (ЗНИ);
— аудит безопасности (АУД);
— антивирусная защита (АВЗ);
— предотвращение вторжений (компьютерных атак) (СОВ);
— обеспечение целостности (ОЦЛ);
— обеспечение доступности (ОДТ);
— защита технических средств и систем (ЗТС);
— защита информационной (автоматизированной) системы и ее компонентов (ЗИС);
— планирование мероприятий по обеспечению безопасности (ПЛН);
— управление конфигурацией (УКФ);
— управление обновлениями программного обеспечения (ОПО);
— реагирование на инциденты информационной безопасности (ИНЦ);
— обеспечение действий в нештатных ситуациях (ДНС);
— информирование и обучение персонала (ИПО).
Более подробный состав мер по обеспечению безопасности ЗОКИИ, которые необходимо применять в зависимости от присвоенной категории значимости, представлен в табличной форме Приложения к Приказу ФСТЭК России № 239.
По итогам ранее разработанных документов и на их основании осуществляется внедрение организационных и технических мер по обеспечению безопасности ЗОКИИ. Внедрение предусматривает следующие работы:
— установку и настройка средств защиты информации;
— разработку ОРД, правил и процедур;
— внедрение организационных мер;
— проведение предварительных испытаний;
— проведение опытной эксплуатации;
— анализ уязвимостей и принятие мер по их устранению;
— приемочные испытания.
Конечным результатом первого этапа является ввод в эксплуатацию ЗОКИИ и его подсистемы безопасности при положительном заключении, который оформляется актом приемки.
В ходе эксплуатации ЗОКИИ Приказ ФСТЭК России № 239 предписывает реализацию следующих мероприятий:
— планирование мероприятий по обеспечению безопасности ЗОКИИ;
— проведения анализа угроз и последствий от их реализации;
— администрирование подсистемы безопасности ЗОКИИ;
— управление конфигурацией ЗОКИИ и подсистемы безопасности;
— реагирование на компьютерные инциденты;
— обеспечение действий в нештатных ситуациях;
— информирование и обучение персонала ЗОКИИ;
— осуществление контроля за обеспечением безопасности ЗОКИИ.
3. Вывод из эксплуатации
При принятии решения об окончании жизненного цикла ЗОКИИ субъекту КИИ необходимо осуществить ряд процедур, которые предусматривает нормативный документ:
— архивирование информации ЗОКИИ;
— уничтожение данных и остаточной информации из ЗОКИИ;
— уничтожение или архивирование данных об архитектуре и конфигурации ЗОКИИ;
— архивирование или уничтожение эксплуатационной документации на ЗОКИИ.
Важно отметить, что процедуры уничтожения должны быть задокументированы субъектом КИИ с указанием наименования, состава документов, способов и даты их уничтожения.
Как мы видим, документы регулятора предписывают осуществлять достаточно большой объем обязательных процедур, не считая непосредственной операционной деятельности по отражению компьютерных атак. Необходимо учитывать, что значимые критические ИС, АСУ или ИТКС не являются статическими сущностями, они очень часто подвергаются модернизации, а это в свою очередь влечет необходимость пересмотра всех ранее разработанных документов ЗОКИИ, вплоть до пересмотра категории значимости объекта. Поэтому субъектам КИИ важно понимать, что обеспечение безопасности ЗОКИИ – это непрерывный процесс на протяжении всего существования критических ИС, АСУ или ИТКС. Собственно, именно по этой причине регулятор предписывает выделять специалистов, ответственных за безопасность ЗОКИИ, в отдельное структурное подразделение и не допускать возложения на них косвенных функций и задач.