Добрый день, конечно, определение SOC было дано в первой части данной серии постов:
В публикации также дается определение SOC (англ. Security Operations Center, Центр мониторинга кибербезопасности) как команды, состоящей преимущественно из специалистов в области кибербезопасности, сформированной для предотвращения, выявления, анализа, реагирования на инциденты кибербезопасности и предоставления соответствующей отчетности.
Да, время не стоит на месте) И даже "классические" SIEM-системы постепенно эволюционируют в облачные NextGen-SIEM с машинным обучением для парсинга логов, искусственным интеллектом в ядре корреляции, предиктивным обнаружением угроз...
Спасибо за комментарий и ссылку. Действительно, в статье отражены далеко не все способы получения полезной инвентаризационной информации из реестра, а даны лишь примеры использования.
Спасибо за комментарий. Цель данной статьи — продемонстрировать использование исключительно штатного функционала Windows с минимальными привилегиями на удаленной системе.
Благодарю за обратную связь!
1. Группу Distributed COM Users (Пользователи DCOM) использовать можно, но она дает сканирующей УЗ избыточные привилегии, в частности, локальный доступ и запуск DCOM-объектов.
2. Не все WMI-подпространства наследуют DACL от пространств default и cimv2, например Security\MicrosoftVolumeEncryption, как указано в статье.
3. Локализация иллюстраций соответствует локализации статьи.
Добрый день, спасибо за обратную связь.
Действительно, в законодательстве по защите КИИ множество нововведений, при этом процессный подход при построении системы управления ИБ, в том числе с применением PDCA-цикла Деминга, достаточно распространен и продвигается регуляторами не первый год. Исходя из лучших практик, наилучший результат в контексте минимизации рисков ИБ дает выстраивание именно процессов, а не функций ЗИ.
Всегда пожалуйста!
По поводу успешных атак на организации, которые получили статус сертифицированных по ISO 27001, можно сказать, что, во-первых, любая процедура сертификации формализована и зачастую подразумевает скорее документальное подтверждение выполнения требований, а техническую реализацию всех тонкостей практически нереально проверить. А во-вторых, никакая сертификация не отменяет необходимости поддерживать состояние системы управления ИБ на должном уровне даже после получения статуса, поскольку угрозы постоянно эволюционируют и для противостояния им нужны действенные контрмеры, актуальные именно на момент атаки, а не на (прошедшую) дату получения статуса.
Спасибо за комментарий. По срокам – в нашем решении изначально реализован конструктор аудитов и контроль соответствия. При этом глубокую настройку и определение метрик можно сделать только в тесном взаимодействии с заказчиком в рамках проекта. А интерес у заказчиков возник в этом году, когда появились обязывающие документы (регистрация в Минюсте 672-П 21.03.2019, 683-П — 16.05.2019 и т.д.) Кстати, одно из последних оживлений от заказчиков в виде запросов произошло после публикации проекта нового 382-П (под требования попадут операторы услуг информационного обмена, поставщики платежных приложений и прочие субъекты НПС).
В статье рассказал именно о тенденциях и об управлении соответствием (compliance control) ГОСТу. Насчет эффективности (конкретно в контексте реализации управления соответствием) – всё в конечном итоге выражается в деньгах, а комплаенс становится весьма актуальным (и выражается повышением заинтересованности заказчиков), т.к. несоблюдение требований ИБ будет грозить штрафными санкциями и доначислением резервов организации в соответствии с рисками (по прозрачной схеме с явной методикой расчетов), а это живые деньги.
То, о чем Вы написали (с примерами) — согласен, только комплаенсом (даже автокомпаленсом) не решается. Эффективный инструмент – это автоматизация по многим направлениям, обнаружение и работа с инцидентами, реагирование на них и т.д., такой инструментарий также предоставляем.
Применительно к примерам с последствиями и эффективностью руководства — рекомендую ознакомиться с проектом Положения Банка России «О требованиях к системе управления операционным риском в кредитной организации и банковской группе», где анонсированы наборы показателей системы управления риском ИБ и способы расчета капитала, необходимого на покрытие потерь от реализации операционного риска (с четким выделением риска ИБ). Насчет сокрытия статистики – там же предусмотрены механизмы контроля и воздействия (см. ответ на комментарий ert112).
С Наступающим Новым Годом!)
Про сценарий – речь именно про автоматизацию соответствия требованиям, возможность вовремя узнать о проблемах в данном направлении и качественно оценить соответствующие compliance риски (расставить приоритеты).
А насчет подделки и сокрытия информации – могут, но с соответствующим наказанием в последующем. Предполагается (см. проект Положения Банка России «О требованиях к системе управления операционным риском в кредитной организации и банковской группе» cbr.ru/StaticHtml/File/41186/180918-41_1.pdf) многоуровневая система контроля: внутренний контроль (независимой службой внутреннего аудита), внешняя независимая оценка (внешним экспертом) и, в конце концов, контроль мегарегулятора, который осуществляет надзор.
Если говорить конкретно про инциденты – как минимум, показатель доли репортинга в ФинЦЕРТ по событиям риска ИБ явно обозначается и идет как количественный показатель (см. последний абзац п.2.1.1 приложения 4 вышеупомянутого проекта). И плохой показатель всё равно скажется на увеличении резервов.
А если расхождения будут серьезные, то это будет уже повод говорить о неэффективной системе управления операционным риском всей организации с соответствующими последствиями (присмотрятся ко всей отчетности организации с пристрастием и т.д., начнут применять меры по 86-ФЗ).
Описанные в статье нормативные документы действительно рассматривают защиту IT и OT систем и сетей. Если же брать «аналоговые» системы, то в них модель угроз и нарушителя, а также риски будут иными. Для их защиты логичнее всего будет применять организационные меры: инструкции и прочие локальные нормативные акты, визуальный контроль работы, проверки кандидатов и сотрудников.
В Приказе №31 как раз подчеркивается, что важно использовать штатный защитный функционал используемых в АСУТП систем. Таким образом, следует корректно/безопасно настраивать и само оборудование, а не только средства защиты и ИТ-инфраструктуру «вокруг» объекта.
К слову, в пункте 42 Декларативной части GDPR прямо говорится, что согласие на обработку ПДн не может считаться данным добровольно, если у субъекта ПДн нет выбора или если он не может отказаться или отозвать своё согласие без ущерба для себя.
Вам и следующему комментатору:
Безусловно, законодательство и «классические» подходы могут отставать от вызовов времени и актуальных угроз, однако нам самим, как наиболее заинтересованным в безопасности своих персональных данных, также следует принимать определенные меры. Например, не следует забывать об элементарной цифровой гигиене, которая должна войти в обиход современного человека. Перефразировав фразу классика, «береги данные смолоду»: не сообщай избыточную личную информацию сайтам и сервисам, не выкладывай сканы документов в сеть, читай лицензионные соглашения, наконец. Только осознанное и бережное обращение с персональными данными поможет нам самостоятельно хотя бы минимизировать возможность утечки и/или некорректного использования. Кстати, как раз сегодня ФинЦЕРТ Банка России опубликовал отчет, в котором ясно прослеживается нарастающая тенденция использования злоумышленниками методов социальной инженерии, при этом ими зачастую используются общедоступные персональные данные (из соцсетей, сервисов по покупке/продаже, и т.д.). О методах социальной инженерии и способах противостояния психологическим манипуляциям злоумышленников дополнительно можно почитать, например, тут.
Полностью согласен. Однако, взяв за ролевую модель лучшие практики и международные стандарты, можно постараться выстроить качественные процессы ИБ даже при наличии «тяжелого» инфраструктурного бэкграунда.
Добрый день, конечно, определение SOC было дано в первой части данной серии постов:
В публикации также дается определение SOC (англ. Security Operations Center, Центр мониторинга кибербезопасности) как команды, состоящей преимущественно из специалистов в области кибербезопасности, сформированной для предотвращения, выявления, анализа, реагирования на инциденты кибербезопасности и предоставления соответствующей отчетности.
Да, время не стоит на месте) И даже "классические" SIEM-системы постепенно эволюционируют в облачные NextGen-SIEM с машинным обучением для парсинга логов, искусственным интеллектом в ядре корреляции, предиктивным обнаружением угроз...
Спасибо за обратную связь!
1. Группу Distributed COM Users (Пользователи DCOM) использовать можно, но она дает сканирующей УЗ избыточные привилегии, в частности, локальный доступ и запуск DCOM-объектов.
2. Не все WMI-подпространства наследуют DACL от пространств default и cimv2, например Security\MicrosoftVolumeEncryption, как указано в статье.
3. Локализация иллюстраций соответствует локализации статьи.
Добрый день, спасибо за обратную связь.
Действительно, в законодательстве по защите КИИ множество нововведений, при этом процессный подход при построении системы управления ИБ, в том числе с применением PDCA-цикла Деминга, достаточно распространен и продвигается регуляторами не первый год. Исходя из лучших практик, наилучший результат в контексте минимизации рисков ИБ дает выстраивание именно процессов, а не функций ЗИ.
По поводу успешных атак на организации, которые получили статус сертифицированных по ISO 27001, можно сказать, что, во-первых, любая процедура сертификации формализована и зачастую подразумевает скорее документальное подтверждение выполнения требований, а техническую реализацию всех тонкостей практически нереально проверить. А во-вторых, никакая сертификация не отменяет необходимости поддерживать состояние системы управления ИБ на должном уровне даже после получения статуса, поскольку угрозы постоянно эволюционируют и для противостояния им нужны действенные контрмеры, актуальные именно на момент атаки, а не на (прошедшую) дату получения статуса.
Российское и международное законодательство в области защиты персональных данных
Обзор российского законодательства по защите критической информационной инфраструктуры
Как говорится, Welcome!
В статье рассказал именно о тенденциях и об управлении соответствием (compliance control) ГОСТу. Насчет эффективности (конкретно в контексте реализации управления соответствием) – всё в конечном итоге выражается в деньгах, а комплаенс становится весьма актуальным (и выражается повышением заинтересованности заказчиков), т.к. несоблюдение требований ИБ будет грозить штрафными санкциями и доначислением резервов организации в соответствии с рисками (по прозрачной схеме с явной методикой расчетов), а это живые деньги.
То, о чем Вы написали (с примерами) — согласен, только комплаенсом (даже автокомпаленсом) не решается. Эффективный инструмент – это автоматизация по многим направлениям, обнаружение и работа с инцидентами, реагирование на них и т.д., такой инструментарий также предоставляем.
Применительно к примерам с последствиями и эффективностью руководства — рекомендую ознакомиться с проектом Положения Банка России «О требованиях к системе управления операционным риском в кредитной организации и банковской группе», где анонсированы наборы показателей системы управления риском ИБ и способы расчета капитала, необходимого на покрытие потерь от реализации операционного риска (с четким выделением риска ИБ). Насчет сокрытия статистики – там же предусмотрены механизмы контроля и воздействия (см. ответ на комментарий ert112).
С Наступающим Новым Годом!)
А насчет подделки и сокрытия информации – могут, но с соответствующим наказанием в последующем. Предполагается (см. проект Положения Банка России «О требованиях к системе управления операционным риском в кредитной организации и банковской группе» cbr.ru/StaticHtml/File/41186/180918-41_1.pdf) многоуровневая система контроля: внутренний контроль (независимой службой внутреннего аудита), внешняя независимая оценка (внешним экспертом) и, в конце концов, контроль мегарегулятора, который осуществляет надзор.
Если говорить конкретно про инциденты – как минимум, показатель доли репортинга в ФинЦЕРТ по событиям риска ИБ явно обозначается и идет как количественный показатель (см. последний абзац п.2.1.1 приложения 4 вышеупомянутого проекта). И плохой показатель всё равно скажется на увеличении резервов.
А если расхождения будут серьезные, то это будет уже повод говорить о неэффективной системе управления операционным риском всей организации с соответствующими последствиями (присмотрятся ко всей отчетности организации с пристрастием и т.д., начнут применять меры по 86-ФЗ).
Безусловно, законодательство и «классические» подходы могут отставать от вызовов времени и актуальных угроз, однако нам самим, как наиболее заинтересованным в безопасности своих персональных данных, также следует принимать определенные меры. Например, не следует забывать об элементарной цифровой гигиене, которая должна войти в обиход современного человека. Перефразировав фразу классика, «береги данные смолоду»: не сообщай избыточную личную информацию сайтам и сервисам, не выкладывай сканы документов в сеть, читай лицензионные соглашения, наконец. Только осознанное и бережное обращение с персональными данными поможет нам самостоятельно хотя бы минимизировать возможность утечки и/или некорректного использования. Кстати, как раз сегодня ФинЦЕРТ Банка России опубликовал отчет, в котором ясно прослеживается нарастающая тенденция использования злоумышленниками методов социальной инженерии, при этом ими зачастую используются общедоступные персональные данные (из соцсетей, сервисов по покупке/продаже, и т.д.). О методах социальной инженерии и способах противостояния психологическим манипуляциям злоумышленников дополнительно можно почитать, например, тут.