Но чтобы это была не просто очередная новость, несколько рекомендаций (да, местами очевидных) по снижению риска повтора аналогичной ситуации на стороне пользователей:
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️⃣Оценка альтернатив. Регулярно пересматривайте используемые решения и сравнивайте их с альтернативами.
Но чтобы это была не просто очередная новость, несколько рекомендаций (да, местами очевидных) по снижению риска повтора аналогичной ситуации на стороне пользователей:
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
BY Пост Лукацкого
Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260
In this regard, Sebi collaborated with the Telecom Regulatory Authority of India (TRAI) to reduce the vulnerability of the securities market to manipulation through misuse of mass communication medium like bulk SMS. Now safely in France with his spouse and three of his children, Kliuchnikov scrolls through Telegram to learn about the devastation happening in his home country. Stocks dropped on Friday afternoon, as gains made earlier in the day on hopes for diplomatic progress between Russia and Ukraine turned to losses. Technology stocks were hit particularly hard by higher bond yields. Telegram was founded in 2013 by two Russian brothers, Nikolai and Pavel Durov. The Russian invasion of Ukraine has been a driving force in markets for the past few weeks.
from us
