Solar 4RAYS подготовили рекомендации на каникулы

Solar 4RAYS подготовили рекомендации на каникулы

Solar 4RAYS подготовили рекомендации на каникулы

Эксперты центра Solar 4RAYS подготовили рекомендации для киберзащитников компаний, которые помогут наладить инфраструктуру так, чтобы можно было беззаботно встретить новый год.

Как напоминают эксперты, новогодние праздники редко обходятся без инцидентов. Злоумышленники пользуются тем, что ИБ-подразделения уходят на каникулы или переходят на удаленный режим работы.

В результате ИБ-специалисты не всегда могут оперативно распознать признаки инцидента и вовремя отреагировать на него, а злоумышленники почти беспрепятственно проникают в инфраструктуры компаний.

Начать эксперты Solar 4RAYS рекомендуют с инвентаризации. Необходимо убедиться, что известны все сегменты сети и активы, которые там находятся. Очень часто злоумышленники атакуют через уязвимые узлы, которые не контролируют ИТ и ИБ-службы, и их обслуживанием занимаются какие-то другие подразделения.

Полезно также будет просканировать пул публичных адресов компании. Это позволит понять и оценить, как ИТ-инфраструктура выглядит с точки зрения потенциальных злоумышленников и определить потенциально уязвимые компоненты. Часть сервисов и приложений на период каникул лучше вообще сделать недоступными из публичного интернета.

Другой важной мерой является создание резервных копий наиболее важных систем. Это позволит восстановить их работоспособность, если ситуация будет развиваться по самому неблагоприятному сценарию.

При этом хранить резервные копии нужно таким образом, чтобы до них не добрались злоумышленники. Для доступа к ним лучше использовать отдельные учетные записи с минимально необходимым набором привилегий, а лучше хранить резервные копии в том сегменте сети, который изолирован от основного.

Необходимо также установить патчи для всех ключевых приложений, прежде всего для публично доступных сервисов. Причем эту задачу надо решать заранее, не откладывая ее на последний рабочий день перед каникулами.

Другой важной мерой является ревизия и смена паролей. Необходимо найти и удалить неиспользуемые учетные записи, сменить пароли администраторов и удаленных пользователей, установить многофакторную аутентификацию для них. Учетные записи подрядчиков нужно отключить на время каникул.

Полезным будет также аудит парольных политик, что позволит исключить «слабые» пароли, которые очень часто используют злоумышленники для атак. Также нужно убедиться в том, что никакие критичные пароли не хранятся в открытом виде на различных ресурсах. 

Полезной мерой будет проверка компрометации инфраструктуры, хотя бы на базовом уровне. Сюда входят срабатывания средств защиты, появление подозрительных файлов, запуск системных служб, появление новых пользователей, установка нового ПО. Также необходима проверка системных журналов на предмет сомнительных аутентификаций, сетевых соединений и всплесков объемов передачи трафика. Эти меры нужно повторить и сразу после каникул, чтобы убедиться в том, что в инфраструктуру компании никто не проник.

В компании также должны быть назначены ответственные за реагирование на инциденты. Необходимы пошаговые инструкции для каждого из участников команды, которые бы описывали первоочередные меры реагирования. Причем ответственные лица должны быть доступны в режиме 24/7. Данную функцию можно делегировать внешнему поставщику услуг.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

Основная сессия запустила субагента, который решил очистить собственные временные файлы, но сформировал лишнюю команду рекурсивного удаления.

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

Проверка тоже оказалась поверхностной: агент посмотрел на названия папок верхнего уровня, которые могли сохраняться, пока их содержимое исчезало.

Пользователь сообщил о потере проектов за несколько месяцев, инструментов разработки, SSH-ключей и учетных данных. В корзине удаленные файлы не оказались. Обращение помечено как ошибка высокого приоритета с потерей данных.

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

RSS: Новости на портале Anti-Malware.ru