Спроси эксперта. Solar inСode все, что вы хотели узнать про "дыры" в коде, но не у кого было спросить

27.04.2016
Все, что вы хотели узнать
про «дыры» в коде, но
не у кого было спросить

solarsecurity.ru +7 (499) 755-07-70
О чем пойдет речь
Что такое дыры
Как они появляются в коде
Какими инструментами их находить
Что делать с найденными дырами
2

Особенности разработки приложений
с точки зрения ИБ
Дыры в софте:
 Уязвимости
 Недекларированные
возможности (закладки)
3

Откуда берутся уязвимости
4
 Культура разработки – разработчик не уделяет внимания:
 Языковым конструкциям, которые использует
 Коду, который используется как сторонний
 Безопасности связей между компонентами, которые разрабатывает
 Недостаток времени:
 Техническое задание разрабатывается быстро
 Программное обеспечение разработается быстро:
задержка в разработке – потеря денег
 Можно удовлетворить только два из трех желаний: быстро,
качественно и недорого
ОБЫЧНО – ЭТО БЫСТРО И НЕДОРОГО

Статистика за 2015 год
5
 Более 75% успешных кибератак эксплуатируют
«дыры» в ПО, т.к. на сегодняшний день это самое
слабое звено технической защиты
 Уязвимости для платформы Android – 15% из всех
уязвимостей, публично опубликованных за 2015 год
 SQLi – 8,4% из всех атак за прошедший 2015 год

Что делать при выявлении уязвимости
Идеальный вариант – устранить уязвимость, переписав код
Некоторые уязвимости веб-приложений можно закрыть
наложенными средствами защиты
7

Bug bounty
Официальная возможность заработать на найденных дырах
В среднем – несколько сотен долларов за уязвимость
Чрезмерно активное исследование на дыры может завалить
исследуемую систему, к этому надо быть готовым
8

Что делать, если получили информацию
об уязвимостях от внешних лиц
Поблагодарить человека за присланную информацию
Проверить уязвимость
Если она подтвердилась – принять решение
об устранении, исходя из ее критичности
Критичные уязвимости устранять
как можно быстрее
Стараться не отвечать
приславшему в стиле
«да это вообще не уязвимость»
9

Сложности
10
 Получить исходный код у разработчиков
 Убедиться, что код «собирается в проект» и не имеет
«неразрешенных зависимостей»
 Проверить код: корректно запустить скан
 Суметь понять, что написано в отчете
 Донести до разработчиков все найденные уязвимости и
объяснить их понятным языком

Методология безопасного
программирования
SDL – Secure Development Lifecycle
 Официально считается, что SDL был впервые внедрен в Microsoft в
2004 г.
SDL предполагает закладывание требований по ИБ еще на этапе ТЗ
на систему.
Важным элементом является тестирование кода на безопасность с
возможным наложением вето на передачу релиза в production
11

Кто, когда и сколько должен проверять
софт
В идеале тестировать
необходимо после внесения
изменений в код
Если изменений не происходит,
то рекомендуется делать
проверки при обновлении
базы уязвимостей
 Тестировать должно
независимое от разработки
лицо, которое компетентно
в вопросах ИБ
12

Как проверить софт?
13

Откуда брать информацию об
уязвимостях. Некоторые источники
https://www.owasp.org
https://cwe.mitre.org/
https://capec.mitre.org/
https://www.cvedetails.com/
http://csrc.nist.gov/groups/ST/index.html
14

Белый ящик. С исходниками или без
С исходниками нет сложностей с
восстановлением кода
Без исходников можно брат
приложение прямо из production, есть
гарантия, что вы проверяете тот же
самый код, а не зачищенную версию
Без исходников вы также
анализируете дыры в
скомпилированных кусках софта,
взятого из других источников.
15

Проверка на НДВ («закладки»)
Самое глубокое тестирование
на НДВ можно провести только
силами эксперта. У него
обязательно должна быть
документация на систему
Автоматически можно искать
НДВ в коде по шаблонным
признакам:
«Захардкоженный» пароль
Временной триггер
16

Продукты для статического анализа кода
17
IBM Security AppScan Source
APPERCUT
HP Fortify Static Code Analyzer
Checkmarx Static Code Analysis
PT Application Inspector
Solar inCode

Здесь могла бы быть ваша реклама
18

На что обратить внимание при выборе
сканера
Поддержка тех языков программирования, которые Вам нужны
Понятный для Вас отчет: язык отчета, описание «дыр»,
рекомендаций итп
Возможность проверки приложений как по исходникам, так и без
Удобство работы: управление правилами поиска уязвимостей,
кастомизация отчетов, интеграция с репозиториями, Bug Tracking
Systems, IDE
Возможность генерации рекомендаций для наложенных СЗИ
Количество пропусков уязвимостей
Количество ложных срабатываний
19

Cloud vs OnSite
Облачный формат:
как правило не требует вложения
в железо и софт
Но надо внутренне согласиться
с передачей своего кода наружу
Как правило дешевле и выгоднее,
если у Вас небольшие объемы
анализируемого кода
20

Cloud vs OnSite
OnSite
Требует внедрения и
администрирования
Дает больше возможностей по
автоматизации SDL
Анализируемый код не уходит
в облако
Как правило является
предпочтительным вариантом для
клиентов с большим количеством
разрабатываемого/анализируемого
кода
21

Основные языки
22
 ActionScript
 Delphi
 MXML (Flex)
 ASP.NET
 VB.NET,
 C# (.NET)
 C/C++
 Classic ASP (with
VBScript)
 COBOL
 HTML
 JavaScript
 AJAX
 JSP
 Objective-C
 PL/SQL
 Python
 T-SQL
 Visual Basic
 VBScript
 XML
 PHP
 Scala
 Java
 Java for
Android

Что должно быть в отчетах
Executive Summary
Бенчмаркинг
Статистика найденных уязвимостей
Динамика изменения уязвимостей
Описание найденных уязвимостей и возможных атак
Критичность найденных уязвимостей
Рекомендации по корректировке кода
Рекомендации по настройке
наложенных СЗИ (где применимо)
Служебная информация
по анализируемому коду: структура проекта,
объем кода итп.
23

ФСТЭК России про контроль кода
21 приказ:
11. В случае определения в соответствии с Требованиями к защите
персональных при их обработке в информационных системах
персональных данных, утвержденными постановлением Правительства
Российской Федерации от 1 ноября 2012 г. N1119, в качестве актуальных
угроз безопасности персональных данных 1-го и 2-го типов дополнительно
к мерам по обеспечению безопасности персональных данных, указанным в
пункте 8 настоящего документа, могут применяться следующие меры:
• проверка системного и (или) прикладного программного обеспечения,
включая программный код, на отсутствие недекларированных
возможностей с использованием автоматизированных средств и (или)
без использования таковых;
• тестирование информационной системы на проникновения;
• использование в информационной системе системного и (или)
прикладного программного обеспечения, разработанного с
использованием методов защищенного программирования.
24

Реестр отечественного ПО
25

Полезные ссылки
 Анализаторы исходного кода – обзор рынка в России и в мире:
https://www.anti-
malware.ru/reviews/Code_analyzers_market_overview_Russia_and_world
 Базы уязвимостей:
 https://www.owasp.org
 https://cwe.mitre.org/
 https://capec.mitre.org/
 https://www.cvedetails.com/
 http://csrc.nist.gov/groups/ST/index.html
 Microsoft SDL:
https://www.microsoft.com/en-us/sdl/
 http://bdu.fstec.ru/
26

Даниил Чернов
Руководитель направления
Application Security
www.solarsecurity.ru
d.chernov@solarsecurity.ru

Спроси эксперта. Solar inСode все, что вы хотели узнать про "дыры" в коде, но не у кого было спросить

More Related Content

What's hot

Viewers also liked

Similar to Спроси эксперта. Solar inСode все, что вы хотели узнать про "дыры" в коде, но не у кого было спросить

More from Solar Security

Спроси эксперта. Solar inСode все, что вы хотели узнать про "дыры" в коде, но не у кого было спросить

Editor's Notes