Notice: file_put_contents(): Write of 10583 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 18775 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
The War on Fakes channel has repeatedly attempted to push conspiracies that footage from Ukraine is somehow being falsified. One post on the channel from February 24 claimed without evidence that a widely viewed photo of a Ukrainian woman injured in an airstrike in the city of Chuhuiv was doctored and that the woman was seen in a different photo days later without injuries. The post, which has over 600,000 views, also baselessly claimed that the woman's blood was actually makeup or grape juice. In view of this, the regulator has cautioned investors not to rely on such investment tips / advice received through social media platforms. It has also said investors should exercise utmost caution while taking investment decisions while dealing in the securities market. For example, WhatsApp restricted the number of times a user could forward something, and developed automated systems that detect and flag objectionable content. NEWS At this point, however, Durov had already been working on Telegram with his brother, and further planned a mobile-first social network with an explicit focus on anti-censorship. Later in April, he told TechCrunch that he had left Russia and had “no plans to go back,” saying that the nation was currently “incompatible with internet business at the moment.” He added later that he was looking for a country that matched his libertarian ideals to base his next startup.
from fr
