Notice: file_put_contents(): Write of 10582 bytes failed with errno=28 No space left on device in /var/www/group-telegram/post.php on line 50
Warning: file_put_contents(): Only 8192 of 18774 bytes written, possibly out of free disk space in /var/www/group-telegram/post.php on line 50 Пост Лукацкого | Telegram Webview: alukatsky/12042 -
Но чтобы это была не просто очередная новость, несколько рекомендаций (да, местами очевидных) по снижению риска повтора аналогичной ситуации на стороне пользователей:
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
One thing that Telegram now offers to all users is the ability to “disappear” messages or set remote deletion deadlines. That enables users to have much more control over how long people can access what you’re sending them. Given that Russian law enforcement officials are reportedly (via Insider) stopping people in the street and demanding to read their text messages, this could be vital to protect individuals from reprisals. WhatsApp, a rival messaging platform, introduced some measures to counter disinformation when Covid-19 was first sweeping the world. Recently, Durav wrote on his Telegram channel that users' right to privacy, in light of the war in Ukraine, is "sacred, now more than ever." "For Telegram, accountability has always been a problem, which is why it was so popular even before the full-scale war with far-right extremists and terrorists from all over the world," she told AFP from her safe house outside the Ukrainian capital. The last couple days have exemplified that uncertainty. On Thursday, news emerged that talks in Turkey between the Russia and Ukraine yielded no positive result. But on Friday, Reuters reported that Russian President Vladimir Putin said there had been some “positive shifts” in talks between the two sides.
from cn
