N
Тогда почему в предлагаемом плане из одноименной заметки мы тратим столько сил на реакцию на КИ ? Если незначимые ОКИИ защищать не нужно...
Size: a a a
2021 April 02
N
При наличии незначимого ОКИИ это не снимает обязанность с владельца обеспечивать его защиту исходя из его принадлежности в рамках приказов ФСТЭК 17 и 21 и иных НПА.
V
N S M
При наличии незначимого ОКИИ это не снимает обязанность с владельца обеспечивать его защиту исходя из его принадлежности в рамках приказов ФСТЭК 17 и 21 и иных НПА.
вы так и не поняли, что по 17 и 21 приказу вы будете защищать информацию, обрабатываему НОКИИ,а не сам НОКИИ
A
ну если ФСТЭК вам подтвердил результат категорирования, то не вижу повода сомневаться в вашем утверждении
Не подтвердил им, просто у нас такая же ситуация. Сейчас мы кии т.к. сегмент у нас. Скоро уйдем в облако и у нас будет только арм и я хочу стать незначимым. С коллегами и специалистами в области безопасности идут жаркие споры по этому поводу
V
Alex
Не подтвердил им, просто у нас такая же ситуация. Сейчас мы кии т.к. сегмент у нас. Скоро уйдем в облако и у нас будет только арм и я хочу стать незначимым. С коллегами и специалистами в области безопасности идут жаркие споры по этому поводу
как обоснуете показатели, так и будет
N
вы так и не поняли, что по 17 и 21 приказу вы будете защищать информацию, обрабатываему НОКИИ,а не сам НОКИИ
По моему это вытекает одно из другого ибо в рамках 187 это просто более глобальнее
A
как обоснуете показатели, так и будет
Нам не ответили на наше письмо по акту категооирования
V
N S M
По моему это вытекает одно из другого ибо в рамках 187 это просто более глобальнее
Нет. Именно по этому появилась отдельная статья УК РФ и вводится новый коап
AK
он может вообще собственными мерами защищаться при желании
Ну оговорка была - чтобы не прозвучало - а вот сказали, что не нужно, следовательно ФСТЭК говорит - нельзя, следовательно деньги тратить не буду и тд., и тп. и вообще отстаньте.
V
Фстэк ответит, что законом требования не установлены
2021 April 04
NP
Всем здравствуйте. Приказ 235 ФСТЭК 2 глава: читая ее складывается впечатление, что иб кии нельзя отдавать на аутсорс за исключением функций в п.10 и только п.10..... верно трактовал ?
AP
Всем здравствуйте. Приказ 235 ФСТЭК 2 глава: читая ее складывается впечатление, что иб кии нельзя отдавать на аутсорс за исключением функций в п.10 и только п.10..... верно трактовал ?
Нет, не верно. В п.11 звучит, для обеспечения функций п.10 (а не п.10.2!!! - это важно) субъект кии может "отдавать на аутсорсинг".
NP
Нет, не верно. В п.11 звучит, для обеспечения функций п.10 (а не п.10.2!!! - это важно) субъект кии может "отдавать на аутсорсинг".
Благодарю
2021 April 05
D
Коллеги, поделитесь опытом составления Плана действий по установлению уровня опасности проведения целевых компьютерных атак на информационную инфраструктуру. Хотя бы общими штрихами.
DK
Denis
Коллеги, поделитесь опытом составления Плана действий по установлению уровня опасности проведения целевых компьютерных атак на информационную инфраструктуру. Хотя бы общими штрихами.
План действий все-таки про реагирование.
Уровень опасности - про моделирование угроз.
Вам сто из этого требуется?
Уровень опасности - про моделирование угроз.
Вам сто из этого требуется?
D
План действий все-таки про реагирование.
Уровень опасности - про моделирование угроз.
Вам сто из этого требуется?
Уровень опасности - про моделирование угроз.
Вам сто из этого требуется?
План действий
DK
Denis
План действий
План действий по реагированию пишется на конкретные типы инцидентов. Если в общих чертах для каждого типа инцидентов план реагирования - это 4 раздела.
1. Что собой представляет система - на уровне сведений о категооировании (из чего состоит, где размещены компоненты, кто администрирует хотя бы на уровне названий структурных подразделений)
2. Как вы определяете, что произошел инцидент данного типа. Как минимум, тут вы определяете негативные последствия ("пользователи нажаловались на шифровальщик", "вот такие сервисы вдруг стали недоступны" и т. п.), но в идеале к ним рано или поздно должны добавиться признаки "раннего оповещения" на основе моделирования угроз ("сработала вот такая корреляция SIEM")
3. Что делаете, если инцидент наступил. Эти действия специфичны именно для данного объекта и для данного типа инцидентов. Для начала действия можно описывать верхнеуровнево, ограничиваясь чисто организационными вещами:
- оповешаем вот таких людей;
- готовим к запуску вот такой холодный резерв и т. п.
Со временем в идеале в план должны добавиться практические вещи:
- меняем настройки вот таких МСЭ, чтобы локализовать распространение заразы;
- сохраняем вот такие логи для дальнейшего разбора;
- пишем трафик вот с таких интерфейсов для дальнейшего разбора;
- переводим вот такие операции в ручной режим;
- оповешаем вот таких контрагентов, чтобы не пытались прислать нам данные через упавший сервис, а несли их на флешках вот сюда;
- дальше разбираемся по обстоятельствам
Подробно расписывать никто не требует, достаточно честно написать только то, что можно предусмотреть заранее до момента "что дальше делать - пока не знаем, соберем рабочую группу и будем решать на месте".
4. Кто за что отвечает. Например:
- руководитель группы реагирования вводит план в действие и собирает рабочую группу в составе...;
- вот такие специалисты предлагают решения по вот таким вопросам;
- предлагаемые решения группы согласовываются вот таким человеком, который в случае звиздеца может принимать любые решения по остановке системы, изменению режимов её работы и т. п.
- структурные подразделения вот такое-то, получив согласованное решение, бегут его исполнять
1. Что собой представляет система - на уровне сведений о категооировании (из чего состоит, где размещены компоненты, кто администрирует хотя бы на уровне названий структурных подразделений)
2. Как вы определяете, что произошел инцидент данного типа. Как минимум, тут вы определяете негативные последствия ("пользователи нажаловались на шифровальщик", "вот такие сервисы вдруг стали недоступны" и т. п.), но в идеале к ним рано или поздно должны добавиться признаки "раннего оповещения" на основе моделирования угроз ("сработала вот такая корреляция SIEM")
3. Что делаете, если инцидент наступил. Эти действия специфичны именно для данного объекта и для данного типа инцидентов. Для начала действия можно описывать верхнеуровнево, ограничиваясь чисто организационными вещами:
- оповешаем вот таких людей;
- готовим к запуску вот такой холодный резерв и т. п.
Со временем в идеале в план должны добавиться практические вещи:
- меняем настройки вот таких МСЭ, чтобы локализовать распространение заразы;
- сохраняем вот такие логи для дальнейшего разбора;
- пишем трафик вот с таких интерфейсов для дальнейшего разбора;
- переводим вот такие операции в ручной режим;
- оповешаем вот таких контрагентов, чтобы не пытались прислать нам данные через упавший сервис, а несли их на флешках вот сюда;
- дальше разбираемся по обстоятельствам
Подробно расписывать никто не требует, достаточно честно написать только то, что можно предусмотреть заранее до момента "что дальше делать - пока не знаем, соберем рабочую группу и будем решать на месте".
4. Кто за что отвечает. Например:
- руководитель группы реагирования вводит план в действие и собирает рабочую группу в составе...;
- вот такие специалисты предлагают решения по вот таким вопросам;
- предлагаемые решения группы согласовываются вот таким человеком, который в случае звиздеца может принимать любые решения по остановке системы, изменению режимов её работы и т. п.
- структурные подразделения вот такое-то, получив согласованное решение, бегут его исполнять
D
План действий по реагированию пишется на конкретные типы инцидентов. Если в общих чертах для каждого типа инцидентов план реагирования - это 4 раздела.
1. Что собой представляет система - на уровне сведений о категооировании (из чего состоит, где размещены компоненты, кто администрирует хотя бы на уровне названий структурных подразделений)
2. Как вы определяете, что произошел инцидент данного типа. Как минимум, тут вы определяете негативные последствия ("пользователи нажаловались на шифровальщик", "вот такие сервисы вдруг стали недоступны" и т. п.), но в идеале к ним рано или поздно должны добавиться признаки "раннего оповещения" на основе моделирования угроз ("сработала вот такая корреляция SIEM")
3. Что делаете, если инцидент наступил. Эти действия специфичны именно для данного объекта и для данного типа инцидентов. Для начала действия можно описывать верхнеуровнево, ограничиваясь чисто организационными вещами:
- оповешаем вот таких людей;
- готовим к запуску вот такой холодный резерв и т. п.
Со временем в идеале в план должны добавиться практические вещи:
- меняем настройки вот таких МСЭ, чтобы локализовать распространение заразы;
- сохраняем вот такие логи для дальнейшего разбора;
- пишем трафик вот с таких интерфейсов для дальнейшего разбора;
- переводим вот такие операции в ручной режим;
- оповешаем вот таких контрагентов, чтобы не пытались прислать нам данные через упавший сервис, а несли их на флешках вот сюда;
- дальше разбираемся по обстоятельствам
Подробно расписывать никто не требует, достаточно честно написать только то, что можно предусмотреть заранее до момента "что дальше делать - пока не знаем, соберем рабочую группу и будем решать на месте".
4. Кто за что отвечает. Например:
- руководитель группы реагирования вводит план в действие и собирает рабочую группу в составе...;
- вот такие специалисты предлагают решения по вот таким вопросам;
- предлагаемые решения группы согласовываются вот таким человеком, который в случае звиздеца может принимать любые решения по остановке системы, изменению режимов её работы и т. п.
- структурные подразделения вот такое-то, получив согласованное решение, бегут его исполнять
1. Что собой представляет система - на уровне сведений о категооировании (из чего состоит, где размещены компоненты, кто администрирует хотя бы на уровне названий структурных подразделений)
2. Как вы определяете, что произошел инцидент данного типа. Как минимум, тут вы определяете негативные последствия ("пользователи нажаловались на шифровальщик", "вот такие сервисы вдруг стали недоступны" и т. п.), но в идеале к ним рано или поздно должны добавиться признаки "раннего оповещения" на основе моделирования угроз ("сработала вот такая корреляция SIEM")
3. Что делаете, если инцидент наступил. Эти действия специфичны именно для данного объекта и для данного типа инцидентов. Для начала действия можно описывать верхнеуровнево, ограничиваясь чисто организационными вещами:
- оповешаем вот таких людей;
- готовим к запуску вот такой холодный резерв и т. п.
Со временем в идеале в план должны добавиться практические вещи:
- меняем настройки вот таких МСЭ, чтобы локализовать распространение заразы;
- сохраняем вот такие логи для дальнейшего разбора;
- пишем трафик вот с таких интерфейсов для дальнейшего разбора;
- переводим вот такие операции в ручной режим;
- оповешаем вот таких контрагентов, чтобы не пытались прислать нам данные через упавший сервис, а несли их на флешках вот сюда;
- дальше разбираемся по обстоятельствам
Подробно расписывать никто не требует, достаточно честно написать только то, что можно предусмотреть заранее до момента "что дальше делать - пока не знаем, соберем рабочую группу и будем решать на месте".
4. Кто за что отвечает. Например:
- руководитель группы реагирования вводит план в действие и собирает рабочую группу в составе...;
- вот такие специалисты предлагают решения по вот таким вопросам;
- предлагаемые решения группы согласовываются вот таким человеком, который в случае звиздеца может принимать любые решения по остановке системы, изменению режимов её работы и т. п.
- структурные подразделения вот такое-то, получив согласованное решение, бегут его исполнять
Спасибо. Монументально!
DK
Есть еще проект ГОСТ по реагированию на компьютерные инциденты, но он ушёл на доработку - там план ещё сильнее был детализирован :)
2021 April 06
В
Добрый день
Есть план реагирования на комп.инциденты готовый уже, чтобы посмотреть образец?
Есть план реагирования на комп.инциденты готовый уже, чтобы посмотреть образец?