Планируется ли смена политики компании в отношении угроз?
Автор
jra
в Задай вопрос Евгению Касперскому!
-
Похожий контент
-
Автор mamruc
Доброго!
На рабочих станция с установленным KES 11.8.0.384 и 12.3.0.493 накатанаполитика контроля устройств (съемные диски - запрещать) см. скрины.
Все работало прекрасно, но в определенный момент обнаружилось, что съемные диски работают!!! Политика применяется - все хорошо.
Если зайти локально на рабочую станцию через KSC , что в политике вместо запрета стоит в зависимости от шины подключения см. скрин 4. Если ручками поменять - все работает.
Кто сталкивался? И почему это могло произойти...
KSC 14
-
Автор S_S_S
Подскажите.
Немогу понять что делаю не так. Хотя все по вашему мануалу
Допустим хочу ограничть всю сетевую активность Punto Switcher. Предварительно провожу инвентаризацию, что бы kasper собрал экзешники. Потом я их нахожу и добавляю в нужную группу.
Сохраняю, политика распространяется на машину. И ничего не меняется.
На скрине слева настройки каспера на машине, справа соответсвенно настройка политики.
И второй вопрос. На скрине punto.exe я уже переместил в другую группу почему при поиске он кажет что они в trusted группе?
Если запрещать трафик на клиенте в настройках каспера то работает. Но зачем тогда KSC нужен..
KES 12.2.0.462
KSC 14.2.0.26967
-
Автор cringemachine
Добрый день.
Существует ли функциональная возможность ограничить права главного сервера в отношении подчиненного? Например, чтобы администратор безопасности при подключении к подчиненному серверу из консоли главного сервера мог просматривать только вкладку Управляемые устройства и Лицензии Лаборатории Касперского?
Поделитесь знаниями, пожалуйста.
-
Автор KL FC Bot
Даже компании со зрелой ИБ и достаточными инвестициями в это направление не застрахованы от киберинцидентов. Атакующие могут использовать уязвимости нулевого дня или скомпрометировать цепочку поставок, сотрудники могут стать жертвой сложной мошеннической схемы по проникновению в компанию, сама команда ИБ может допустить ошибку в настройках защитных инструментов или процедуре реагирования. Но каждый такой случай — повод улучшать процессы и системы, делать защиту еще эффективнее. И это не просто мотивационный афоризм, а практический подход, который вполне успешно работает в других сферах, например в авиационной безопасности.
В авиации требования по обмену информацией для предотвращения инцидентов предъявляются ко всем участникам — от производителей самолетов до стюардесс. И речь идет не обязательно об авариях или сбоях, в этой отрасли принято сообщать и о потенциальных проблемах. Сообщения постоянно анализируются и на их основе корректируются меры безопасности. Постоянное внедрение новых мер и технологий привело к снижению числа фатальных инцидентов с 40 на миллион вылетов в 1959 году до 0,1 — в 2015-м.
Но главное — в авиации давно поняли, что такая схема не будет работать, если ее участники боятся сообщать о нарушениях процедур, проблемах качества и других причинах инцидентов. Поэтому авиационные стандарты включают требования non-punitive reporting и just culture — то есть сообщения о проблемах и нарушениях не должны приводить к наказанию. Есть подобный принцип и у инженеров DevOps, они обычно называют это blameless culture и используют при разборе масштабных сбоев. Незаменим такой подход и в кибербезопасности.
У каждой ошибки есть фамилия?
Противоположностью blameless culture является принцип «у каждой ошибки есть фамилия», то есть конкретный виновник, который ее совершил. В рамках этой концепции за каждую ошибку применяют дисциплинарные взыскания вплоть до увольнения. Однако в реальности использование этого принципа вредно и не ведет к повышению защищенности.
Сотрудники боятся ответственности и искажают факты при расследовании случившихся инцидентов, а то и уничтожают информацию, пытаясь скрыть улики. Искаженная или частично уничтоженная информация об инциденте усложняет реагирование и ухудшает общий исход, потому что ИБ не может правильно и быстро оценить масштаб инцидента. При разборе инцидентов фокус на конкретном виновнике не позволяет сосредоточиться на том, как надо изменить систему, чтобы подобные инциденты не повторялись впредь. Сотрудники боятся сообщать о нарушениях политик и практик ИТ и ИБ, поэтому компания упускает шанс устранить дефекты защиты ДО ТОГО, как они стали причиной критического инцидента. Сотрудники не мотивированы обсуждать вопросы кибербезопасности, обучать друг друга, корректировать ошибки коллег. Чтобы все в компании могли внести вклад в ее защиту, надо действовать иначе.
View the full article
-
Автор Bercolitt
Как сменить мастер-пароль в Kaspersky Password Manager?
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти