Правильно подметили, что забыл упомянуть в статье довольно важные темы по поводу точек распространения и как следствие шлюзов соединения (но нюансов в их работе тоже не мало, в целом хватило бы на отдельную статью), они тоже играют роль в нивелировании сетевой нагрузки.
К сожалению в официальной документации не нашёл прямого подтверждения уменьшения нагрузки на сеть при использовании шлюзов соединения именно в описанном в статье сценарии, видимо уточню этот вопрос уже на обучающем курсе.
Очень удобный инструмент, позволяющий и проанализировать действующие security-бэйзлайны microsoft для доменных узлов и объектов в виде отчётов html, а так же их импортировать в действующий домен организации.
Всем советую, но используйте с умом, и предварительным анализом того, что вы включаете)
Вспоминается поговорка: "Плохому танцору и яйца мешают"
Если у ответственного ИТ/ИБ специалиста организации имеется достаточная квалификация и опыт - он сможет, не прибегая к дорогим для организации решениям, по типу физической изоляции сегментов сети - построить киберустойчивую сетевую инфраструктуру (даже не берём в расчеты отдельные случаи, когда организация имеет инфраструктуру уровня матёрого дата-центра, на всех стыках которой такого рода защиту выстроить практически невозможно без серьёзной потери управляемости, масштабируемости и гибкости управления, что тоже весьма важно).
Ровно как и не самый лучший специалист, даже прибегая к "лучшим" архитектурным решениям, может запороть киберустойчивость сетевой инфраструктуры её незнанием, или кривой реализацией.
Про субъекты КИИ - понятное дело, что защита такого уровня должна присутствовать "по умолчанию", в добавок к различным наложенным средствам защиты информации.
Зачем когда есть менеджеры паролей, причем некоторые из них с аатозаполнением и гибким генератором паролей? (Бесплатный - KeePassXC, Платный - Roboform, про корп.сегмент даже говорить нет смысла, поскольку имеется несколько десятков продуктов со схожим и даже большим функционалом, на любой вкус, цвет и потребности);
Использовать на двух и более сайтов один и тот же пароль, хеш или иные производные - априори не безопасная идея;
Коллеги, благодарю за познавательную статью! Подскажите, а был ли в рамках данного проекта, или иного другого, кейсы интеграции SIEM с DR (Detection and Response) решениями? (с KATA, TDR, MXDR и т.д.) Особенно была бы интересна часть про подводные камни реализации..)
Information
Rating
1,169-th
Registered
Activity
Specialization
Security Engineer, Information Security Specialist
Добрый день!
Правильно подметили, что забыл упомянуть в статье довольно важные темы по поводу точек распространения и как следствие шлюзов соединения (но нюансов в их работе тоже не мало, в целом хватило бы на отдельную статью), они тоже играют роль в нивелировании сетевой нагрузки.
К сожалению в официальной документации не нашёл прямого подтверждения уменьшения нагрузки на сеть при использовании шлюзов соединения именно в описанном в статье сценарии, видимо уточню этот вопрос уже на обучающем курсе.
Как раз в процессе выбора УЦ и согласования обучения, благодарю за совет)
Жалко не упомянули про Microsoft Security Compliance ToolKit:
https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/security-compliance-toolkit-10
Очень удобный инструмент, позволяющий и проанализировать действующие security-бэйзлайны microsoft для доменных узлов и объектов в виде отчётов html, а так же их импортировать в действующий домен организации.
Всем советую, но используйте с умом, и предварительным анализом того, что вы включаете)
Вспоминается поговорка: "Плохому танцору и яйца мешают"
Если у ответственного ИТ/ИБ специалиста организации имеется достаточная квалификация и опыт - он сможет, не прибегая к дорогим для организации решениям, по типу физической изоляции сегментов сети - построить киберустойчивую сетевую инфраструктуру (даже не берём в расчеты отдельные случаи, когда организация имеет инфраструктуру уровня матёрого дата-центра, на всех стыках которой такого рода защиту выстроить практически невозможно без серьёзной потери управляемости, масштабируемости и гибкости управления, что тоже весьма важно).
Ровно как и не самый лучший специалист, даже прибегая к "лучшим" архитектурным решениям, может запороть киберустойчивость сетевой инфраструктуры её незнанием, или кривой реализацией.
Про субъекты КИИ - понятное дело, что защита такого уровня должна присутствовать "по умолчанию", в добавок к различным наложенным средствам защиты информации.
Интересное решение, но:
Зачем когда есть менеджеры паролей, причем некоторые из них с аатозаполнением и гибким генератором паролей? (Бесплатный - KeePassXC, Платный - Roboform, про корп.сегмент даже говорить нет смысла, поскольку имеется несколько десятков продуктов со схожим и даже большим функционалом, на любой вкус, цвет и потребности);
Использовать на двух и более сайтов один и тот же пароль, хеш или иные производные - априори не безопасная идея;
Коллеги, благодарю за познавательную статью!
Подскажите, а был ли в рамках данного проекта, или иного другого, кейсы интеграции SIEM с DR (Detection and Response) решениями? (с KATA, TDR, MXDR и т.д.)
Особенно была бы интересна часть про подводные камни реализации..)