Защита КИИ - Форум по вопросам информационной безопасности

to Гость
<Благодарю за приятную для меня сравнительную оценку> - ох, японский ж бог...

<Уж чего-чего, а приказы регулятор писать умеет. Не то, что методички...> - не в бровь, а в глаз. Но сути дела это не меняет...

<...Заказчику нужно определить требования по защите информации в АСУ по 17-му приказу...> - зачем к АСУ ТП приплетать требования ГИС? Это государственный станок с ЧПУ (эта фраза не оставляла мне выбора, ага)? Или технологическая информация, обрабатываемая в данной системе, имеет отношение к ИОД-ОГВ/МУ? От этого надо плясать (goto Metka)...

<Заказчиком определено, что "степень возможного ущерба может быть:
высокой...> - молодец, заказчик (надеюсь, имеется в виду "владелец ИС"/"владелец ИОД". В целом, имеет полное право. Только есть один нюанс (goto Metka)...

<Как аудитору подтвердить, перепроверить правильность субъективной оценки Заказчика о "существенных негативных последствиях"?> - логикой, мать ее. А если не выходит логикой, то есть такая классная штука, как тестовые испытания. Желательно, на стенде, конечно. А масштаб и тип деятельности Заказчик должен был указать для своей ИС (конкретно, без размытых фраз), по которым аудитор осуществляет проверку. В чем проблема-то?

<красиво-волшебные показатели типа "более или равно 1, но менее или равно 50". А если не 50, а 51?> - это вы откуда взяли? Ежели из моих сообщений на форуме, то, primo, это пример, и secundo, см. контекст...

<по каким методикам определить например цифровой показатель "причинения ущерба жизни и здоровью людей (человек)"?> - а по каким методикам в соответствии с ст. 111 УК РФ оцениваются "тяжкие телесные", а? Или на этом моменте начнется классическое "вот поэтому у нас суды/эксперты/полиция/правительство/дворники/etc. так и работают - разворовали всю страну, ко-ко-ко..."?

to Гость
METKA:
Еще раз для тех, кто в танке, либо прикидывается...
1) В любой ИС или АС мы защищаем ИОД, на ней фокусируемся. При этом к ИОД могут относиться как конечные сведения по перечням (на уровне ФЗ, на уровне частных решений и проч.), так и доп. информация, касающаяся данной ИС (АС) или ее организации-владельца.
2) В ИСПДн мы защищаем ИОД = ПДн в э/в представления. Своих ли сотрудников, чужих ли - ФЗ и проч. Важно: ИС может предоставлять услуги внешним пользователям (т.е. не сотрудникам оператора, а, например, физ.лицам). Последствия - для юзеров ИС и для организации-владельца (оператора) ИС. Масштаб - по охвату юзеров, ага...
3) В ГИС мы защищаем ИОД = гос-не-ГТ в э/в представления. Важно: ИС может предоставлять услуги внешним пользователям (т.е. не сотрудникам оператора, а, например, физ.лицам), но тогда такая ИОД может лишиться параметра "К", и, следовательно, защита должна сосредоточиться на параметрах "Ц" и "Д". Последствия - для юзеров ИС и для государства (его "представителей"). Масштаб - по охвату юзеров, ага...
4) АСУ ТП уже не ИС! В АСУ ТП мы защищаем сам техпроцесс, т.е. информационные потоки производственного характера на уровне "ТС-ТС" и "ТС-управляющаяИС". В первую голову по параметрам "Д" и "Ц", "К" уже вторично (третично). Последствия - для организации-владельца, для эксплуатантов и заказчиков. Масштаб - по масштабам производства, ага...
5) КИИ уже не ИС! В КИИ мы защищаем уже не ИОД (ее там, в целом, нет), а более низкий уровень - уровень информационных связей, уровень предоставления "транспорта" для обмена информацией. И в масштабах РФ, а не отдельно взятой организации. И почему об этом все забывают? По последствиям, думаю, понятно от чего плясать...
6) ГТ/КТ - no comments, уже давно все разжевано...

ЗЫ Разумеется, на правах imho. Разумеется, меня тоже не радует, что ФЗ и проч. акты не смогли по такому же принципу доходчивое все это описать. Разумеется, нужен свой велосипед, поскольку ездить хочется. Но, как говорил один мой знакомый покойник - ты специалист? вот и разбирайся, и решай, а время покажет, кто, зачем и куда...

to Гость

Последнее...
Если вы считаете, что в вашем ведении имеется ИСПДн-которая ГИС-которая АСУ ТП-которая КИИ, то отойдите от стола, протрите глаза, проспитесь и посчитайте еще раз...
Если у вас все-таки имеется ОИ, в котором ИСПДн, ГИС, АСУ ТП и КИИ перемешаны в одну кучу, то поздравляю - вы завод по линии ГС ПВДНП, не иначе. Тогда вам к "другому регулятору", ага...
Для всего остального есть способ разделения контуров. Как по факту, так и на бумаге. Ключевые меры ЗИ выбираются по-максимуму, чтобы никому обидно не было. А меры ЗИ применительно к каждому контуру уже по факту ценности защищаемого ресурса (все в полном соответствии с методиками/приказами, ага)...

ЗЫ Если вы ничего из вышесказанного не понимаете или принципиально не желаете принять, то могу одолжить табельное и 1 патрон, ага...

oko | 100612
<...Заказчику нужно определить требования по защите информации в АСУ по 17-му приказу...> - зачем к АСУ ТП приплетать требования ГИС?

«Дык эта тово этова», заказчику нужно определить требования к защите информации в ГИС по 17-му приказу, а не по 31-му. Однако за «наводку» благодарствуйте.

Ссылка в 31-м приказе что-то понемногу начинает прояснять:
«степень возможного ущерба определяется заказчиком или оператором экспертным или иным методом и может быть:
высокой, если в результате нарушения одного из свойств безопасности информации (целостности, доступности, конфиденциальности), повлекшего нарушение штатного режима функционирования автоматизированной системы управления, возможно возникновение чрезвычайной ситуации федерального или межрегионального характера <*> или иные существенные негативные последствия в социальной, политической, экономической, военной или иных областях деятельности;
<*> Устанавливается в соответствии с постановлением Правительства Российской Федерации от 21 мая 2007 г. N 304 "О классификации чрезвычайных ситуаций природного и техногенного характера" (Собрание законодательства Российской Федерации, 2007, N 22, ст. 2640; 2011, N 21, ст. 2971)».

oko | 100613
>5) КИИ уже не ИС!

«Шедеврально».
Согласно статьи 2 ФЗ от 26.07.2017 №187:
6) критическая информационная инфраструктура - объекты критической информационной инфраструктуры, а также сети электросвязи, используемые для организации взаимодействия таких объектов;
7) объекты критической информационной инфраструктуры - информационные системы, информационно-телекоммуникационные сети, автоматизированные системы управления субъектов критической информационной инфраструктуры.

>В КИИ мы защищаем уже не ИОД (ее там, в целом, нет)
Если объектом КИИ является АСУ ТП, то согласно 31-му приказу:
«В автоматизированной системе управления объектами защиты являются:
информация (данные) о параметрах (состоянии) управляемого (контролируемого) объекта или процесса (входная (выходная) информация, управляющая (командная) информация, контрольно-измерительная информация, иная критически важная (технологическая) информация)»;

Если «аудитор включит логику», то поймет, что это и будет ИОД, и если такая информация ИОД не будет, то за каким шутом её нужно защищать и применять требования 31-го приказа?

oko | 100614
>Если у вас все-таки имеется ОИ, в котором ИСПДн, ГИС, АСУ ТП и КИИ перемешаны в одну кучу, то поздравляю - ……… Тогда вам к "другому регулятору»

А давайте пошлем к «другому регулятору» мастеров нормотворческого жанра, заваривших эту неперевариваемую желудком кашу из методичек?

to Гость
Еще раз помедитируйте над разницей ИС в контексте защиты чистой ИОД по факту ключевого параметра "К", и над ИС, в которых ключевыми являются параметры "Д" и "Ц". Поймете и мои слова, и смысловую разницу в документах регулятора. Как минимум:
<иная критически важная (технологическая) информация> - это не ИОД в прямом смысле слова. Ее основными характеристиками являются "Д" и "Ц". Кому в голову придет, условно, секретить"протоколы обмена" аппаратуры (ну, кроме конторы-разработчика, только это уже в другую степь), отвечающей за обеспечение ядерного реактора? Security through obscurity не жизнеспособная позиция. Вот обеспечить их штатное использование и отсутствие посторонних "вкраплений" в режиме реального времени - главная задача. Как и в любой АСУ ТП. Как, в целом, в любой КИИ...
<...неперевариваемую желудком кашу из методичек...> + <Ссылка в 31-м приказе что-то понемногу начинает прояснять...> = судя по всему, любезнейший, вы эти методички и приказы сейчас впервые читать и начали. Рекомендую либо потратить время с пользой и изучить мат.базу, а потом уже лезть на форум со своим самоваром. Либо наконец проср*ся, раз уж желудок слабоват и не выдерживает. Только учтите, что полихеция - дело сугубо интимное, личное. И тут не общественный сортир (официальной вывески не наблюдал во всяком случае)...

После очередного рассмотрения 239 приказа , заметил (внезапно ), что контроль целостности требуется для всех категорий.
В порядке дискусси, опуская спец СЗИ (SN, DL), которые могут просто не взлететь на ОКИИ, или доставить больше проблем чем пользы . Какие будут предложения у коллег, по части интегрированных решений , контроля соответствия, а может даже компенсирующих мер.

to Dfg
Разрешено же юзать несертиф. СЗИ с проведением испытаний и доказательством их валидности. А дописать или "налепить поверх" для любого софта механизм КЦ на базе того же CRC32 не такая уж и сложна задача...

Вообще представляю, если систем сотни и тысячи, какой поток пойдёт изменений хэшей после очередного обновления. Самое интересное, что вот изменилась контрольная сумма у вот этой dll (одной из тысяч) , где взять столько человеко часов , чтобы анализировать какой вред несёт это изменение. Требование выпоним, а практическая польза где.

to Dfg
Не сгущайте краски. Акт: "бла-бла-бла необходимость обновления -> экспертная группа установила корректность обновления -> экспертная группа решила, что последствий по части защищенности объекта обновления не несут -> КС "источника" обновлений (для софта в целом, а не каждого файла, если вы не извращенец, конечно), рассчитанная таким-то способом, приведена ниже"...
<...где взять столько человеко часов , чтобы анализировать какой вред несёт это изменение...> - меж тем, самый главный вопрос. Достаточно 1 вредоносного/багнутого файла из сотни тысяч, чтобы "свалить" не только весь программный комплекс, но и, теоретически, всю систему защиты и/или операционную среду. Как быть? Думать, решать, моделировать, тестировать, оценивать необходимость (вложенные силы к возможным последствиям, ага) подобных действий изначально вообще и т.д. Т.е. заниматься обеспечением безопасности, а не ругаться на требования, ага...

Oko
"Достаточно 1 вредоносного/багнутого файла из сотни тысяч, чтобы "свалить" не только весь программный комплекс, но и, теоретически, всю систему защиты и/или операционную среду. Как быть? "
Явно не решать такие вещи контролем целостности, который просто забьет siem алертами и распылит силы аналитиков. Вредоносность сейчас определяется поведенческими моделями (mitre att&ck и прочими ).
Практический контроль целостности был бы полезен, если бы система была неизменяемая. Ну или как предлагают некоторые решения - готовые пополняемые базы хэшей легитимного ПО, врукопашную это не разгребешь.

"Акт: "бла-бла-бла необходимость обновления -> экспертная группа установила корректность обновления -> экспертная группа решила, что последствий по части защищенности объекта обновления не несут -> КС "источника" обновлений (для софта в целом, а не каждого файла, если вы не извращенец, конечно), рассчитанная таким-то способом, приведена ниже"...

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