Пост Лукацкого

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

1️⃣ Тщательная проверка источников получения ПО. Используйте средства защиты только из проверенных и хорошо зарекомендовавших себя источников. Изучите их историю, активность сообщества и репутацию разработчиков. Тут все было с Github, но в других кейсах может быть и иначе.

2️⃣ Оценка популярности и поддерживаемости ПО. Чем больше активных пользователей и чем чаще выпускаются обновления, тем выше вероятность оперативного устранения уязвимостей. Хотя давняя история с HeartBleed, когда в популярной библиотеке OpenSSL пару лет не могли найти уязвимость, говорит, что и это не панацея.

3️⃣ Своевременное обновление. Регулярно проверяйте и обновляйте средства защиты до последних стабильных версий, содержащих исправления уязвимостей. Главное, не повторять кейс CrowdStrike и следовать "канареечному" подходу (обновление по частям).

4️⃣ Использование LTS-версий. Для критически важных систем выбирайте версии с долгосрочной поддержкой (LTS), которые получают стабильные обновления безопасности.

5️⃣ Проверка кода на уязвимости. Если возможно, проводите независимую проверку исходного кода open source решений перед их использованием. По крайней мере в отношении критически важного ПО. И не думайте, что ИБ-решения более защищенные, чем обычное прикладное или системное ПО.

6️⃣ Оценка компонентов и зависимостей. Средства защиты могут включать сторонние библиотеки, которые также должны регулярно проверяться на наличие уязвимостей (например, с использованием инструментов для анализа зависимостей или соответствующих фидов).

7️⃣ Сегментация. Разделяйте среды, в которых работают защитные инструменты, чтобы ограничить потенциальный ущерб. Например, запускайте сканеры в изолированных контейнерах или на виртуальных машинах.

8️⃣ Минимизация привилегий. Убедитесь, что защитные средства работают с минимально необходимыми правами доступа, а еще лучше в определенные технологические окна, чтобы иметь возможность видеть отклонения от определенного расписания и другие аномалии.

9️⃣ Логирование и аудит. Настройте запись действий всех средств защиты, чтобы отслеживать потенциально вредоносное поведение. Интеграция DevSecOps в SOC - не самая изученная тема, кстати.

1️⃣0️⃣ Мониторинг активности. Используйте системы мониторинга SIEM/XDR/метапродукты для выявления аномальной активности со стороны самих средств защиты. Кто контролирует контролеров?!

1️⃣1️⃣ Проверка резервных копий. Регулярно тестируйте резервные копии систем, чтобы быть готовыми восстановить работу в случае инцидента.

1️⃣2️⃣ Разработка плана реагирования. Имейте четкий план действий на случай, если обнаружится уязвимость или компрометация средства защиты. У вас, кстати, текущий план реагирования покрывает инфраструктуру ИБ?

1️⃣3️⃣ Пентесты и Red Team. Регулярно проводите проверки используемых средств защиты, включая их роль в инфраструктуре. И не ограничивайтесь только проверкой SOCа.

1️⃣4️⃣ Bug Bounty. Если средство используется в больших масштабах, запустите программу Bug Bounty, чтобы привлекать исследователей для поиска уязвимостей (ну или убедитесь, что используемое вами решение участвует в какой-то программе Bug Bounty).

1️⃣5️⃣ Активное участие в сообществах. Подпишитесь на рассылки и каналы безопасности, связанные с используемыми инструментами, чтобы оперативно узнавать об уязвимостях в них.

1️⃣6️⃣ Поддержка связей с разработчиками. Если вы используете open source решения, участвуйте в обсуждениях и уведомляйте разработчиков об обнаруженных проблемах. Помогайте другим пользователям не наступить на грабли, с которыми столкнулись вы сами.

1️⃣7️⃣ Не полагайтесь на одно решение. Используйте несколько уровней защиты и разнообразие инструментов, чтобы снизить риск единой точки отказа. Тем более, что в сегменте open source сканеров уязвимостей, таких решений полно.

1️⃣8️⃣ Оценка альтернатив. Регулярно пересматривайте используемые решения и сравнивайте их с альтернативами.

#управлениеинцидентами #opensource

Please open Telegram to view this post

VIEW IN TELEGRAM

www.group-telegram.com/kr/alukatsky.com/12042

6.1K viewsJan 8 at 06:48

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

1️⃣ Тщательная проверка источников получения ПО. Используйте средства защиты только из проверенных и хорошо зарекомендовавших себя источников. Изучите их историю, активность сообщества и репутацию разработчиков. Тут все было с Github, но в других кейсах может быть и иначе.

2️⃣ Оценка популярности и поддерживаемости ПО. Чем больше активных пользователей и чем чаще выпускаются обновления, тем выше вероятность оперативного устранения уязвимостей. Хотя давняя история с HeartBleed, когда в популярной библиотеке OpenSSL пару лет не могли найти уязвимость, говорит, что и это не панацея.

3️⃣ Своевременное обновление. Регулярно проверяйте и обновляйте средства защиты до последних стабильных версий, содержащих исправления уязвимостей. Главное, не повторять кейс CrowdStrike и следовать "канареечному" подходу (обновление по частям).

4️⃣ Использование LTS-версий. Для критически важных систем выбирайте версии с долгосрочной поддержкой (LTS), которые получают стабильные обновления безопасности.

5️⃣ Проверка кода на уязвимости. Если возможно, проводите независимую проверку исходного кода open source решений перед их использованием. По крайней мере в отношении критически важного ПО. И не думайте, что ИБ-решения более защищенные, чем обычное прикладное или системное ПО.

6️⃣ Оценка компонентов и зависимостей. Средства защиты могут включать сторонние библиотеки, которые также должны регулярно проверяться на наличие уязвимостей (например, с использованием инструментов для анализа зависимостей или соответствующих фидов).

7️⃣ Сегментация. Разделяйте среды, в которых работают защитные инструменты, чтобы ограничить потенциальный ущерб. Например, запускайте сканеры в изолированных контейнерах или на виртуальных машинах.

8️⃣ Минимизация привилегий. Убедитесь, что защитные средства работают с минимально необходимыми правами доступа, а еще лучше в определенные технологические окна, чтобы иметь возможность видеть отклонения от определенного расписания и другие аномалии.

9️⃣ Логирование и аудит. Настройте запись действий всех средств защиты, чтобы отслеживать потенциально вредоносное поведение. Интеграция DevSecOps в SOC - не самая изученная тема, кстати.

1️⃣0️⃣ Мониторинг активности. Используйте системы мониторинга SIEM/XDR/метапродукты для выявления аномальной активности со стороны самих средств защиты. Кто контролирует контролеров?!

1️⃣1️⃣ Проверка резервных копий. Регулярно тестируйте резервные копии систем, чтобы быть готовыми восстановить работу в случае инцидента.

1️⃣2️⃣ Разработка плана реагирования. Имейте четкий план действий на случай, если обнаружится уязвимость или компрометация средства защиты. У вас, кстати, текущий план реагирования покрывает инфраструктуру ИБ?

1️⃣3️⃣ Пентесты и Red Team. Регулярно проводите проверки используемых средств защиты, включая их роль в инфраструктуре. И не ограничивайтесь только проверкой SOCа.

1️⃣4️⃣ Bug Bounty. Если средство используется в больших масштабах, запустите программу Bug Bounty, чтобы привлекать исследователей для поиска уязвимостей (ну или убедитесь, что используемое вами решение участвует в какой-то программе Bug Bounty).

1️⃣5️⃣ Активное участие в сообществах. Подпишитесь на рассылки и каналы безопасности, связанные с используемыми инструментами, чтобы оперативно узнавать об уязвимостях в них.

1️⃣6️⃣ Поддержка связей с разработчиками. Если вы используете open source решения, участвуйте в обсуждениях и уведомляйте разработчиков об обнаруженных проблемах. Помогайте другим пользователям не наступить на грабли, с которыми столкнулись вы сами.

1️⃣7️⃣ Не полагайтесь на одно решение. Используйте несколько уровней защиты и разнообразие инструментов, чтобы снизить риск единой точки отказа. Тем более, что в сегменте open source сканеров уязвимостей, таких решений полно.

1️⃣8️⃣ Оценка альтернатив. Регулярно пересматривайте используемые решения и сравнивайте их с альтернативами.

#управлениеинцидентами #opensource