Информация из части 3 статьи 1 Федерального закона от 30.11.2024 N 420-ФЗ "О внесении изменений в Кодекс Российской Федерации об административных правонарушениях".
Было такое опасение. Но все же участники игр относились друг к другу с определенным уровнем уважения и оценивали по честному. Бланков с одними единицами не было.
Нам важно понимать как будет реализовываться угроза (через какую уязвимость), потому что один из вариантов снижения риска это влияние на уязвимость, а не на угрозу. Тут речь не про программные уязвимости типа CVE/NVD а про свойства активов, позволяющие угрозе реализоваться. Например:
Заражение ВПО из-за реагирования на фишинговые письмапользователем
Заражение ВПО из-за неработоспособности АВЗ на ОС Windows
Угроза одна, а уязвимости в разных активах, воздействие в каждом случае будет свое. При этом мы можем (если чутка касаться темы с расчетом рисков) смотреть как на атомарные риски так и, например, совокупную величину рисков связанных с угрозой Заражения ВПО.
Условно говоря угрозы - это короткие (и желательно понятные руководству) проблемы, а уязвимости в активах это то, почему эти проблемы могут произойти.
... и мы тут еще не касаемся темы с сценариями (цепочками угроз), это вообще вырви мозг =)
Базу и сервис на которые ссылался мы используем как раз на практике, для построения реестра рисков и расчетов, в том числе оценки влияния защитных мер, постараюсь описать поподробнее в новых статьях, спасибо за интерес.
Согласен с вами, угрозы и уязвимости часто путают. Взять ту же БДУ ФСТЭК, в которой половина угроз это по сути уязвимости. Сюда же можно добавить ментальную ошибку, приучившую нас под уязвимостью понимать какую-нибудь CVE, которую надо устранить сканером уязвимостей и патчами. Хотя в широком смысле уязвимость это, как вы сказали, архитектурная особенность системы, т.е. любое ее свойство.
В статье не идет речь про расчет рисков, это действительно отдельная большая тема, заслуживающая отдельного внимания. Хотел статьей навести резкость именно в формулировании рисков (возможно "плюсы" в формуле ввели в заблуждение).
Как вы предлагаете (включать уязвимость в угрозу) сделано в БДУ ФСТЭК, когда у нас под угрозой скрывается несколько абзацев описывающих как она может быть реализована и к чему привести. Поэтому такой подход не то что имеет место, но в каком то роде "узаконен" нашими регуляторами. Но в нем вижу проблему, ведь угроза может реализовываться множеством способов (через различные уязвимости) и каждая из этих уязвимостей может приводить к разным угрозам, так зачем копипастить уязвимости в карточках различных угроз если можно на техническом уровне разбить понятие риск на 3 составляющие (угроза, уязвимость и актив).
По теме блокировки:
Согласен автором в том, что блокировка может привести к негативным последствиям для сети. Даже если исключить целенаправленные действия нарушителя, веерная блокировка может быть вызвана вирусной активностью (тот же Kido, о котором писал).
Но при этом прошу обратить внимание, что блокировка учетных записей — это базовое требование для ГИС (государственных информационных систем) и ИСПДн — ИАФ.4, УПД.1, УПД.6.
И если ваша система предполагается к аттестации на соответствие 17 или 21 приказам ФСТЭК, надо будет постараться, чтобы обосновать отсутствие автоматической блокировки.
Приятно, что моя статья О защите служебных учетных записей оказалась столь близкой темой для ildarz и помогла ему написать свою первую статью.
Возможно, автор найдет время для того, чтобы систематизировать свой богатый опыт и оформить его не в форме критичной заметки, а систематизированных рекомендаций с примерами и описанием реализации? Такой материал был бы многим полезен.
Не опускаясь до взаимной оценки квалификаций, считаю нужным разъяснить следующий момент, чтобы у читателей не возникло ложного представления о вопросе:
Блокировка учетных записей — это базовое требование для ГИС (государственных информационных систем) и ИСПДн — ИАФ.4, УПД.1, УПД.6.
Если уж задаваться такой целью — не проще ли анализировать журналы на предмет неуспешных попыток?
Можно поступить и так, но в обоих случаях возможность уведомления придется решать либо скриптом, либо дополнительным ПО (например NetWrix).
Зачем?
Если можно так же сделать задание, срабатывающее на не успешную авторизацию,
Согласен, написал в статье о такой возможности, просто пример приводил именно того, как это было реализовано. А накручивать в эту сторону можно далеко.
Информация из части 3 статьи 1 Федерального закона от 30.11.2024 N 420-ФЗ "О внесении изменений в Кодекс Российской Федерации об административных правонарушениях".
В КоАП это внесут позже (когда вступит в силу)
Было такое опасение. Но все же участники игр относились друг к другу с определенным уровнем уважения и оценивали по честному. Бланков с одними единицами не было.
Нам важно понимать как будет реализовываться угроза (через какую уязвимость), потому что один из вариантов снижения риска это влияние на уязвимость, а не на угрозу.
Тут речь не про программные уязвимости типа CVE/NVD а про свойства активов, позволяющие угрозе реализоваться. Например:
Заражение ВПО из-за реагирования на фишинговые письма пользователем
Заражение ВПО из-за неработоспособности АВЗ на ОС Windows
Угроза одна, а уязвимости в разных активах, воздействие в каждом случае будет свое. При этом мы можем (если чутка касаться темы с расчетом рисков) смотреть как на атомарные риски так и, например, совокупную величину рисков связанных с угрозой Заражения ВПО.
Условно говоря угрозы - это короткие (и желательно понятные руководству) проблемы, а уязвимости в активах это то, почему эти проблемы могут произойти.
... и мы тут еще не касаемся темы с сценариями (цепочками угроз), это вообще вырви мозг =)
Базу и сервис на которые ссылался мы используем как раз на практике, для построения реестра рисков и расчетов, в том числе оценки влияния защитных мер, постараюсь описать поподробнее в новых статьях, спасибо за интерес.
Согласен с вами, угрозы и уязвимости часто путают. Взять ту же БДУ ФСТЭК, в которой половина угроз это по сути уязвимости. Сюда же можно добавить ментальную ошибку, приучившую нас под уязвимостью понимать какую-нибудь CVE, которую надо устранить сканером уязвимостей и патчами. Хотя в широком смысле уязвимость это, как вы сказали, архитектурная особенность системы, т.е. любое ее свойство.
В статье не идет речь про расчет рисков, это действительно отдельная большая тема, заслуживающая отдельного внимания. Хотел статьей навести резкость именно в формулировании рисков (возможно "плюсы" в формуле ввели в заблуждение).
Как вы предлагаете (включать уязвимость в угрозу) сделано в БДУ ФСТЭК, когда у нас под угрозой скрывается несколько абзацев описывающих как она может быть реализована и к чему привести. Поэтому такой подход не то что имеет место, но в каком то роде "узаконен" нашими регуляторами. Но в нем вижу проблему, ведь угроза может реализовываться множеством способов (через различные уязвимости) и каждая из этих уязвимостей может приводить к разным угрозам, так зачем копипастить уязвимости в карточках различных угроз если можно на техническом уровне разбить понятие риск на 3 составляющие (угроза, уязвимость и актив).
Согласен автором в том, что блокировка может привести к негативным последствиям для сети. Даже если исключить целенаправленные действия нарушителя, веерная блокировка может быть вызвана вирусной активностью (тот же Kido, о котором писал).
Но при этом прошу обратить внимание, что блокировка учетных записей — это базовое требование для ГИС (государственных информационных систем) и ИСПДн — ИАФ.4, УПД.1, УПД.6.
И если ваша система предполагается к аттестации на соответствие 17 или 21 приказам ФСТЭК, надо будет постараться, чтобы обосновать отсутствие автоматической блокировки.
Возможно, автор найдет время для того, чтобы систематизировать свой богатый опыт и оформить его не в форме критичной заметки, а систематизированных рекомендаций с примерами и описанием реализации? Такой материал был бы многим полезен.
Блокировка учетных записей — это базовое требование для ГИС (государственных информационных систем) и ИСПДн — ИАФ.4, УПД.1, УПД.6.
Можно поступить и так, но в обоих случаях возможность уведомления придется решать либо скриптом, либо дополнительным ПО (например NetWrix).
Согласен, написал в статье о такой возможности, просто пример приводил именно того, как это было реализовано. А накручивать в эту сторону можно далеко.