Downloaded 109 times
Uploaded byAleksey Lukatskiy
Информационная безопасность на базе open source: есть ли смысл?
Документ рассматривает использование решений на основе open source в сфере информационной безопасности, выделяя преимущества и недостатки таких подходов. Автор предлагает альтернативы коммерческим продуктам и подчеркивает важность тщательного анализа безопасности и управления уязвимостями в open source ПО. В заключение, приводятся рекомендации по разработке политик и процедур для эффективного использования open source в компаниях.
More Related Content
Similar to Информационная безопасность на базе open source: есть ли смысл?
Информационная безопасность на базе open source: есть ли смысл?
- 1. 1 1 ИБ на базеopen source: есть ли смысл? Алексей Лукацкий Бизнес-консультант по безопасности 26/05/2016
- 2. 2 3 сценария действийв кризис • Занять выжидательную позицию в надежде, что Курс стабилизируется Санкции отменят Ситуация нормализуется • Срочно предпринимать «очевидные» действия Сокращать расходы, в том числе ФОТ Уменьшать штат сотрудников Пересматривать обязательства и договоренности • Провести тщательный анализ ситуации в своей отрасли, разработать и реализовать комплекс последовательных мер, направленных на поддержание конкурентоспособности компании/подразделения в новых условиях
- 3. 3 Курс валюты изменился. Что делать? • Активно использовать то, что уже есть Пора начать пользоваться уже приобретенным на 90%, а не только покупать что-то новое Знаете ли вы, что в маршрутизаторах Cisco есть встроенный межсетевой экран, покрывающий до 80% функций, нужных для МСЭ? Знаете ли вы, что в ОС Windows (всех семейств) существуют встроенные возможности по разграничению доступа к файлам и приложениям? А про MS Security Essentials вы слышали? Насколько эффективно у вас выстроен процесс управления обновлениями (патчами)? • Разработка собственных решений по ИБ • Использование open source Для внутренних задач В качестве основы для своих продуктов для потребителя, например, IDS на базе Snort
- 4. 4 Snort как эталон системы обнаружения атак • Snort создан Мартином Решем в 1998-м году • Является стандартом де-факто для систем обнаружения атак • Язык описания сигнатур атак Snort также является стандартом де-факто • Текущая версия – 3.0 (Snort++) • На базе Snort создаются многие иные системы обнаружения атак, в т.ч. и в России
- 5. 5 Snort vs FirePOWERServices • 6 аппаратных платформ • Технология RNA (профилирование) • Технология RUA (пользователи) • Борьба с вредоносным кодом • NGFW (приложения) • OpenAppID • Фильтрация URL и DLP • Сканер безопасности • Белые/черные списки
- 6. 6 Обратите внимание 78% компаний в мире используют open source в той или иной степени и только 3% не используют и не будут ни при каких условиях! Источник: The 2015 North Bridge & Black Duck Future of Open Source Study
- 7. 7 Чем (временно) заменить коммерческие решения? Средство защиты Аналог в open source Антивирус ClamAV, Immunet Борьба с шпионским ПО Nixory Межсетевой экран / UTM IOS Firewall, iptables, Endian, Untangle, ClearOS, NetCop, IPCop, Devil-Linux, Shorewall, Turtle Firewall, Vuurmuur Прикладной межсетевой экран AppArmor, ModSecurity Антиспам ASSP, SpamAssassin, SpamBayes, MailScanner DLP OpenDLP, MyDLP
- 8. 8 Чем (временно) заменить коммерческие решения? Средство защиты Аналог в open source Фильтрация Web DansGuardian Обнаружение вторжений на ПК OSSEC Обнаружение вторжений на уровне сети Snort, Bro, Suricata Управление паролями PasswordMaker, KeePassX, KeePass Password Safe, Шифрование на ПК AxCrypt, TrueCrypt, Gnu Privacy Guard, NeoCrypt Расследование инцидентов ODESSA, The Sleuth Kit/Autopsy Browser, Cuckoo Sandbox, GRR, Maltego
- 9. 9 Чем (временно) заменить коммерческие решения? Средство защиты Аналог в open source Управление инцидентами MozDef Мониторинг сетевых аномалий Wireshark, tcpdump, Security Onion Многофакторная аутентификация WiKID Сканеры безопасности OpenVAS, Nessus, Nmap, Metasploit, Nikto, Brakeman SIEM OSSIM, OpenSOC
- 10. 10 Обратите внимание ПО бывает популярным и не очень!
- 11. 11 Преимущества open source •Независимость от производителя • Снижение совокупной стоимости владения при разработке решения • Гибкость в кастомизации под свои нужды • Анализ исходных кодов в поисках багов перед внедрением • Принцип »множества глаз» • Привлечение талантливой молодежи Так ли все просто?
- 12. 12 Анализ исходников • А у вас есть квалификация для этого? Часто исходники идут без каких-либо комментариев и документации Считается, что для анализа исходников надо быть как минимум таким же компетентным, что и сам автор • А если квалификации нет, то кто будет анализировать исходники? А внешняя организация имеет квалификацию? А ведь это уже деньги и немалые;; и время • Будет ли более безопасно ПО с исходниками, чем без оных? Наличие исходников еще не делает ПО более безопасным Не все ПО анализируется также как и Linux, Apache и т.п. Часто ПО анализируется не с точки зрения безопасности, а с точки зрения его настройки под свои нужды История с ФСТЭК и OpenSSL
- 13.
- 14. 14 Знаете ли вы что… Проект OpenSSL (до Heartbleed) поддерживался «двумя Стивами», работающих неполный рабочий день за несколько тысяч долларов в год, поступающих в виде добровольных взносов!
- 15. 15 Обратите внимание 67% компаний в мире не анализируют уязвимости в ПО open source! Источник: The 2015 North Bridge & Black Duck Future of Open Source Study
- 16. 16 OpenSOC vs коммерческого SIEM • 2 Network Capture Cards (рекомендуется Napatech NT20E2-CAP) • Apache Flume 1.4.0 + • Apache Kafka 0.8.1+ • Apache Storm 0.9 + • Apache Hadoop 2.x (любой дистрибутив) • Apache Hive 12 + (13 - рекомендуется) • Apache Hbase 0.94+ • Elastic Search 1.1 + • MySQL 5.6+ + написать коннекторы
- 17. 17 Централизованное управление Централизованное управление в open source – это больная тема!
- 18.
- 19.
- 20. 20 Риски использования open source • Нехватка адекватной оценки соответствия требованиям А кто это делал или должен делать? Разработчику часто недосуг этим заниматься Вы можете воспользоваться решениями по анализу исходных кодов, но это требует ресурсов (финансовых и людских) Вы можете воспользоваться RATS или Flawfinder, а может и Appercut или Solar inCode • Внесение в дистрибутив open source вредоносного кода • Нехватка поддержки (патчи, консультации и т.п.) Исключая популярное ПО, например, Snort Особенно если вы берете ПО не у автора, а у посредника, который на его основе создал свою разработку и может даже не знать, как поддерживать используемые библиотеки У поставщика есть SLA?
- 21. 21 Open Source в контексте требований регуляторов • Наличие исходных кодов означает наличие доступа, в т.ч. и у злоумышленников к среде функционирования • Возникает риск использования недокументированных возможностей на прикладном или на системном уровне У проприетарного ПО таких рисков меньше • ПО на базе open source практически не имеет шансов быть сертифицированным Кто будет платить за сертификацию ПО, которое потом сложно продать? Вы можете сделать это самостоятельно на базе «Общих критериев» (ISO 15408). А у вас есть опыт?
- 22. 22 Рекомендации • Взвесьте все «за» и «против» Помните про TCO • Разработайте политику использования open source Не везде и не для всех задач Возможно стоит начать с менее критичных функций Кто несет ответственность за оценку, загрузку, внедрение и обновление? • Разработайте политики выбора и оценки Поищите статистику использования выбранного ПО Есть ли у этого ПО группы поддержки, форумы, сайт? Они обновляются? Не забудьте про анализ защищенности open source • Разработайте политику анализа защищенности Анализ защищенности должен быть проведен перед/после каждого обновления
- 23. 23 Обратите внимание 55% не имеют политик и процедур работы с open source! Источник: The 2015 North Bridge & Black Duck Future of Open Source Study
- 24. 24 Рекомендации • Разработайте политики загрузки из доверенных источников А откуда вы качаете ПО и обновления к нему? У вас список доверенных источников? • Разработайте политику доработки ПО • Если вы загружаете бинарные файлы, то проверяйте их контрольные суммы А лучше загружайте исходники и сами их компилируйте • Конфигурируйте ПО правильно Отключайте ненужные сервисы и меняйте пароли, заданные по умолчанию • Используйте принцип эшелонированной обороны • Периодически проводите аудит ПО и процессов его поддержки
- 25. 25 Что же тогда влияет на качество и защищенность ПО? • Архитектура и дизайн • Обученные и квалифицированные разработчики В том числе и в контексте SDLC • Тип и качество инструментария, используемого при разработке • Глубина и качество тестирования • Эргономика пользовательского интерфейса
- 26.