Анализ возможности перехода на 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 FirePOWER Services
• 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. 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. 18
Централизованное управление

19. 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. 26
Благодарю
за внимание