-
Похожий контент
-
От Timur644
Доброго дня всем.
Антивирус KES последний раз активировал 3 года назад, сейчас забыл как происходит активация.
Нынешней работе стоит KES 12.6, Kaspersky Security for Linux Mail Server 8.0.3.30. для нескольких доменов. (про него прочитал что тоже через Сервер активируется)
Лицензия истекает 13.10.2024, ключ уже есть.
Подскажите пожалуйста как быть с активацией, ближе к дате надо запустить задачу или в тот день?
-
От tav
Всех приветствую !
Поднял пока что тестовый KSC последний на Alt Linux.
Версия KSC Linux PF 15.1.0.12199 и версия KESL PF 12.1.0.1543.
В настройках политики установил распространять ключ через KSC и на самой лицензии галка стоит.
Клиент работает не в режиме легкого агента.
В итоге клиент виндовый подхватывает ключ с сервера KSC, клиент линуксовый при установке автоматом ставит тестовую/пробную лицензию и ни как не хочет цеплять автоматом лицензию.
Если я создаю задачу для линуксовой группы/клиента сменить ключ, то все ок клиенты по задаче меняют ключ тестовый на корпоративный.
Не понимаю почему именно линуксовые клиенты автоматом не тащат ключ. Настройки как я понимаю правильные.
-
От Din
Есть приватный ключ, подскажите как и чем расшифровать?
Сообщение от модератора Mark D. Pearlstone Перемещено из темы. -
От Bercolitt
Разбиваю длинный, сложный мастер-ключ на части и храню их в разных файлах и в бумажной записной книжке. Перед вводом пароля данные из этих файлов собираю в буфере обмена, вставляю в поле ввода KPM, а затем дописываю из записной книжки в нужную позицию с экранной клавиатуры Kaspersky. После разблокировки хранилища приходит сообщение, что буфер обмена очищен. Проверяю использованный буфер обмена и вижу, что никакой очистки не произошло. Нужно чистить вручную .
-
От KL FC Bot
Серьезные ИБ-инциденты порой затрагивают многих участников, зачастую и тех, кто повседневно не занимается вопросами ИТ и ИБ. Понятно, что в первую очередь усилия сосредоточиваются на выявлении, сдерживании и восстановлении, но, когда пыль немного осядет, наступает время для еще одного важного этапа реагирования — извлечения уроков. Чему можно научиться по итогам инцидента? Как улучшить шансы на успешное отражение подобных атак в будущем? На эти вопросы очень полезно ответить, даже если инцидент не принес существенного ущерба из-за эффективного реагирования или просто удачного стечения обстоятельств.
Немного о людях
Разбор инцидента важен для всей организации, поэтому к нему обязательно привлекать не только команды ИТ и ИБ, но также высшее руководство, бизнес-владельцев ИТ-систем, а также подрядчиков, если они были затронуты инцидентом или привлекались к реагированию. На встречах этой рабочей группы нужно создать продуктивную атмосферу: важно донести, что это не поиск виноватых (хотя ошибки будут обсуждаться), поэтому перекладывание ответственности и манипулирование информацией исказят картину, повредят анализу и ухудшат позицию организации в долгосрочной перспективе.
Еще один важный момент: многие компании скрывают детали инцидента в страхе за репутацию или опасаясь повторной кибератаки по тому же сценарию. И хотя это вполне объяснимо и некоторые подробности действительно конфиденциальны, нужно стремиться к максимальной прозрачности в реагировании и делиться подробностями атаки и реагирования если не с широкой публикой, то как минимум с узким кругом коллег из сферы ИБ, которые могут предотвратить похожие атаки на свои организации.
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти