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
Such instructions could actually endanger people — citizens receive air strike warnings via smartphone alerts. If you initiate a Secret Chat, however, then these communications are end-to-end encrypted and are tied to the device you are using. That means it’s less convenient to access them across multiple platforms, but you are at far less risk of snooping. Back in the day, Secret Chats received some praise from the EFF, but the fact that its standard system isn’t as secure earned it some criticism. If you’re looking for something that is considered more reliable by privacy advocates, then Signal is the EFF’s preferred platform, although that too is not without some caveats. Meanwhile, a completely redesigned attachment menu appears when sending multiple photos or vides. Users can tap "X selected" (X being the number of items) at the top of the panel to preview how the album will look in the chat when it's sent, as well as rearrange or remove selected media. Stocks closed in the red Friday as investors weighed upbeat remarks from Russian President Vladimir Putin about diplomatic discussions with Ukraine against a weaker-than-expected print on U.S. consumer sentiment. Asked about its stance on disinformation, Telegram spokesperson Remi Vaughn told AFP: "As noted by our CEO, the sheer volume of information being shared on channels makes it extremely difficult to verify, so it's important that users double-check what they read."
from jp
