Download to read offline
Uploaded byAdvanced monitoring
Анализ защищенности ПО и инфраструктур – подходы и результаты
Документ представляет анализ защищенности информационных систем и инфраструктуры, подчеркивая методы выявления уязвимостей и приведя примеры атак. Основное внимание уделено статистике атак и типам уязвимостей, включая ошибки разработчиков и проблемы в инфраструктуре. Также рассмотрены подходы к обеспечению безопасности и способы их улучшения через аудит и мониторинг.
More Related Content
![PulseVPN [RU] .pdf](https://cdn.slidesharecdn.com/ss_thumbnails/pulsevpnru-240623103458-bb7ec315-thumbnail.jpg?width=640&height=640&fit=bounds)
![NSA's panic. JetBrains [RU] .pdf](https://cdn.slidesharecdn.com/ss_thumbnails/nsaspanic-240623103726-5a57272a-thumbnail.jpg?width=640&height=640&fit=bounds)
Анализ защищенности ПО и инфраструктур – подходы и результаты
- 1. Анализ защищенности ПОи инфраструктур – подходы и результаты Михаил Богатырев Руководитель направления по работе с клиентами ЗАО «ПМ»
- 2. О нас Дочерняя компанияИнфоТеКС создана в 2007 г. Анализ защищенности ПО и ИС. Центр мониторинга.
- 3. Основные типы компьютерныхатак Многопрофильная компания Офис в Москве 3 офиса в России ~700 рабочих мест События 2016 Сканирования 480,838 Другие 313,773 Вредоносное ПО 113,239 Попытки вызова отказа в обслуживании 24,380 Попытки перебора паролей 17,059 Попытки эксплуатации известных уязвимостей 3,036 Сканирования 480,838 Другие 313,773 Вредоносное ПО 113,239 Попытки вызова отказа в обслуживании 24,380 Попытки перебора паролей 17,059 Попытки эксплуатации известных уязвимостей 3,036
- 4. Причины возникновения уязвимостей ПОи систем защиты Уязвимости на стадии разработки ПО и СЗИ Ошибки разработчиков кода. Уязвимости сторонних компонентов, системного ПО, платформы. Уязвимости, внесенные в код злоумышленником. Уязвимости на стадии эксплуатации Изменения настроек. Смена режима эксплуатации. Изменения в процессах. Изменения в персонале.
- 5. Примеры выявленных уязвимостейв ПО, сторонних компонентах и платформе Модификация клиентского приложения, в результате которой был получен доступ ко всем записям базы данных серверной части. Уязвимость в web-приложении позволила провести инъекцию исполняемого файла на сервер, с помощью которого был получен доступ к операционной системе. Используя уязвимость драйвера ядра удалось повысить привилегии и проникнуть в локальную сеть.
- 6. Примеры выявленных уязвимостейв ПО, сторонних компонентах и платформе Перехват ключевой информации из оперативной памяти клиентского приложения, который позволил осуществить доступ к данным клиента и организовать несколько фиктивных клиентских рабочих мест. Отправка запросов на аутентификацию от имени разных клиентских приложений, привела к множественным блокировкам клиентских учетных данных.
- 7. Примеры выявленных уязвимостейв инфраструктуре Подключенная к локальной сети wi-fi точка сотрудника позволила получить доступ к инфраструктуре из соседних офисов. Добавленный администратором для своего удобства сетевой адаптер позволил проникнуть из открытого сегмента в защищенный через его рабочее место.
- 8. Примеры выявленных уязвимостейв инфраструктуре Испорченные файлы архивов не позволили провести восстановление после сбоя. «Зомби-аккаунт» позволил уволенному сотруднику несколько лет получать доступ к данным. IDS не обнаруживал сетевые атаки из-за потерь трафика при копировании после подключения новых мощностей.
- 9. Методы выявления уязвимостейв ПО Анализ исходных кодов (статический анализ). Тестирование на проникновение и устойчивость к воздействиям (динамический анализ): декомпиляция; отладка; фаззинг; попытки НСД к данным HDD, RAM, трафик. Анализ настроек вспомогательного и системного ПО.
- 10. Методы выявления уязвимостейв ПО Мониторинг публикаций об уязвимостях сторонних компонентов, системного ПО, платформ. Количество уязвимостей в CVE Аудит инфраструктуры и системы обновлений разработчика. Комплексный аудит защищенности Анализ методов защиты обновлений
- 11. Снижение количества уязвимостейна стадии разработки Аудит требований. Анализ архитектуры. Анализ разработанного кода. Мониторинг публикаций об уязвимостях сторонних компонентов. Анализ безопасности конечного решения. Анализ безопасности системы обновлений. Цикл безопасной разработки ПО
- 12. Цикл безопасной разработки(нотация HP)
- 13. Комплексный аудит ИБ: тестированиена проникновение; анализ конфигураций СЗИ; аудит процессов управления ИБ; тестирование персонала. Методы выявления уязвимостей в инфраструктуре
- 14. Отслеживание изменений настроек Отслеживаниесобытий ИБ Методы выявления уязвимостей в инфраструктуре Центр мониторинга
- 15. Спасибо за внимание? МихаилБогатырев Руководитель направления по работе с клиентами ЗАО «ПМ»
Editor's Notes
- #4 В случае ИБ, как и в медицине системы защиты функционируют во враждебной среде. На слайде показана реальная статистика систем обнаружения вторжений на сети средних размеров компании. Всегда остается надежда, что неприятности случатся с кем-то другим, но не с нами. В ИБ, как и в медицине всем известно, что профилактика требует меньше затрат, чем ликвидация уже случившейся проблемы.
- #5 Даже если ваша информационная система не содержала уязвимостей ПО, СЗИ, была правильно спроектирована и внедрена, то со временем ее защитные функции будут ослабевать. Источники уязвимостей закладываются уже на стадии разработки. Кроме ошибок самих разработчиков, выявляются новые уязвимости вспомогательного, системного ПО, аппаратных платформ. Отдельная область в поверхности атак – использование обновлений прикладного ПО для внедрения в вашу информационную систему. Злоумышленник может модифицировать обновления, получив доступ к сети разработчика. (Такие факты мы фиксировали в реальности). Кроме уязвимостей самого ПО, в ходе эксплуатации изменяются настройки СЗИ и оборудования, меняются режимы эксплуатации СЗИ в связи с развитием информационной системы, меняется состав рабочих групп и отделов, что отражается на эффективности работы системы защиты, процессов обработки инцидентов, и т.п.
- #6 Приведу несколько примеров уязвимостей ПО, выявленных нами в ходе многочисленных тестирований на проникновение. Все примеры относятся к клиент-серверная архитектуре. Первый пример – система оформления заказов. Клиентские приложения распространяются для заказчиков. Серьезная, продуманная система защиты. Одна уязвимость в клиентском приложении позволила сквозь все системы защиты получить прямой доступ к общему хранилищу данных. Следующий пример показывает, как злоумышленник может использовать многоходовые комбинации, используя уязвимости разного типа. Через уязвимость прикладного ПО он загрузил исполняемый файл на сервер, с помощью него получил удаленный доступ. Используя уязвимость драйвера (это уже уровень системного ПО) он повысил свои привилегии, с помощью которых у него появилась возможность скрыть следы взлома и развивать атаку дальше в локальную сеть. Еще один пример показывает, как недостаточная защита данных в оперативной памяти может быть использована. Злоумышленник легально приобрел один экземпляр клиентского ПО. Из оперативной памяти ему удалось добыть ключевую информацию, используя которую он смог клонировать клиента и создать несколько десятков рабочих мест. Следующий пример – атака на всю систему, с использованием уязвимости в логике ее работы. Серверная часть разрывает клиентскую сессию при получении от его имени запроса на аутентификацию с другого адреса. Злоумышленник осуществил «веерное отключение» клиентов, отправляя запросы от их имени со своего клиента. Имена клиентов совпадали с названиями компаний-клиентов. Перечень компаний-клиентов был получен злоумышленником из архива базы данных, обнаруженных в одном из каталогов.
- #7 Еще один пример показывает, как недостаточная защита данных в оперативной памяти может быть использована. Злоумышленник легально приобрел один экземпляр клиентского ПО. Из оперативной памяти ему удалось добыть ключевую информацию, используя которую он смог клонировать клиента и создать несколько десятков рабочих мест. Следующий пример – атака на всю систему, с использованием уязвимости в логике ее работы. Серверная часть разрывает клиентскую сессию при получении от его имени запроса на аутентификацию с другого адреса. Злоумышленник осуществил «веерное отключение» клиентов, отправляя запросы от их имени со своего клиента. Имена клиентов совпадали с названиями компаний-клиентов. Перечень компаний-клиентов был получен злоумышленником из архива базы данных, обнаруженных в одном из каталогов.
- #8 Теперь посмотрим, что вносится в информационную систему в процессе ее эксплуатации: Во время нескольких!!! Пентестов нам удавалось обнаружить беспроводные точки, нелегально подключенные к локальной сети (чтобы подключать свои планшеты и смартфоны). Т.к. настраивались они не системными администраторами компании, то и уровень их защищенности позволял использовать их для проникновения в сеть с улицы, из помещения этажом ниже. Еще один пример из жизни, как человеческий фактор влияет на защищенность. У системного администратора было 2 АРМ: первое рабочее место в открытом офисном сегменте с почтой, интернетом и т.п., второе рабочее место подключено к изолированному защищенному сегменту. Ему показалось неудобным переключаться с одного на другое рабочее место и он добавил себе еще один Ethernet-адаптер. В результате его АРМ оказалось подключенным к двум сегментам одновременно. Теперь дело за малым – получить доступ к его АРМ, а для этого есть множество способов (в нашем случае сработал трюк с перехватом пароля администратора из оперативной памяти, когда он удаленно подключался к АРМ другого пользователя).
- #9 Еще один пример – несоблюдение регламентов: когда грянула беда, вышло из строя хранилище, то восстановить данные из резервных копий не удалость, т.к. одна из копий была испорчена и более поздние архивы без нее были бесполезны. Причина – отсутствие регулярных проверок целостности архивов. Следующий пример – не сработали коммуникации между службами: при увольнении сотрудника положено блокировать все его аккаунты, но одного сотрудника «проморгали», он после увольнения несколько лет подключался удаленно к VPN, использовал данные компании для своей новой работы. В завершение пример изменений в режимах работы: в компании организовывались новые рабочие места, появились резервные каналы связи, началось активное использование видеоконференций, в результате трафик, который копировался для анализа на IDS стал столь объемным, что начались потери пакетов на сетевом оборудовании, и информация о событиях уже не доходила до IDS. Выявить это удалось только во время тестирования.
- #10 Для тщательного выявления уязвимостей необходимо анализировать исходные коды ПО. Но коды не всегда доступны, и кроме того, анализ кодов не позволяет ответить на все вопросы. Для того, чтобы оценить простоту эксплуатации уязвимостей, устойчивость к внешним воздействиям, мы проводим тестирование на проникновение конкретной реализация системы, анализируем настройки систем защиты, инфраструктуры. Мы проверяем, что сможет получить атакующий, если будет использовать отладчик или декомпилятор, проверяем, насколько устойчиво решение в ситуации, когда оно получает на вход заведомо некорректные запросы.
- #11 Чтобы понять возможности злоумышленника вставить свое вредоносное ПО в пакеты обновлений, или использовать для атаки инфраструктуру разработчика и каналы доставки, мы проводим комплексный анализ защищенности обновлений. Иногда проводим анализ защищенности инфраструктуры разработчика ПО. Для управления уязвимостями сторонних компонентов ПО, вспомогательных сервисов и служб, уязвимостями операционных систем, прошивок и аппаратных платформ мы мониторим публикации об обнаруженных уязвимостях как в открытых, так и в закрытых источниках.
- #12 Всем известно, что устранять уязвимости в продукте в 30 раз дороже, чем выявить ее на стадии производства. Для снижения затрат и повышения качества своих продуктов, разработчики ПО внедряют у себя цикл безопасной разработки, который предполагает проверки безопасности на всех этапах производства. Здесь мы можем заметить некоторые уже знакомые нам термины. Отличие заключается в том, что на производстве все проверки максимально автоматизированы для регулярных многократных итераций, и внедрены в производственные процессы.
- #13 На слайде мы видим цикл безопасной разработки в нотации HP. Разработчики прибегают к помощи экспертных организации, таких, как наша, для проведения финальных проверок, разработки инструментария, и тест-кейсов, внедрения процессов и практик, коучинга.
- #14 Для выявления уязвимостей, появляющихся в инфраструктуре и процессах, необходимо проводить внешний комплексный аудит информационной безопасности который должен быть регулярным (это важно!). В процессе аудита проверяется, насколько изменилась защищенность вашей инфраструктуры, какова эффективность процессов и средств управления ИБ, насколько готов персонал противодействовать компьютерным атакам.
- #15 Для поддержания уровня защищенности необходимо обеспечить внедрение нескольких важных процессов: Управление изменениями всего: средств защиты, ОС, сетевых устройств, пользователей и пр. Управление инцидентами ИБ.