Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог

Взаимодействие с разработчиками

Взаимодействие с разработчиками при использовании результатов анализа защищенности приложений

Для определения защищенности бизнес-систем многие компании используют сканеры уязвимостей, как статические, анализирующие исходный код, так и динамические, исследующие приложение целиком в среде его исполнения. Используются различные технологии и методики – и в результате получается некоторый отчет об уязвимостях различной степени критичности из которого после интерпретации получается change request – запрос разработчику на исправление ошибок.

Вот тут и начинаетсaя самое интересное. Очевидно, что разработчик не спешит признавать свои ошибки. С одной стороны, найденные ошибки – пятно на мундире. С другой – неоплаченные трудозатраты, поскольку большинство контрактов подразумевает исправление ошибок за счет подрядчика. Поэтому все силы разработчика обычно бросаются на доказывание того, что в реальной жизни найденные некорректности кода реализоваться не могут.

Даже при предъявлении эксплойта, демонстрирующего способ эксплуатации уязвимости, разработчик предпочтет убеждать заказчика, что для написания такого эксплойта злоумышленнику понадобятся знания об архитектуре системы, которую ему в реальной жизни просто неоткуда почерпнуть.

При предъявлении другого эксплойта разработчик заявит, что такой эксплойт сработает только при определенных настройках разрабатываемой системы, а такие настройки может установить только больной на голову администратор.

При предъявлении третьего – что это уязвимость в интерфейсе администратора, а последний может получить доступ к данным безо всяких инъекций, поэтому вероятность эксплуатации этой уязвимости мала.

Четвертая уязвимость будет отвергнута, поскольку проэксплуатировать ее можно только получив доступ к личному кабинету клиента сервиса, а на это никто не пойдет, поскольку испугается, что его быстро найдут по авторизации.

Вроде все логично, но ощущение наличия в коде бомбы замедленного действия не покидает заказчика. Информация об архитектуре может утечь с уволившимся сотрудником, настройки могут меняться, в том числе и умышленно, а клиент, «расковырявший» уязвимость в личном кабинете может открыть для атаки отдельный счет на украденный паспорт. А практика многократного использования кода может привести к тому, что инъекция станет возможной уже совсем не в интерфейсе администратора.

Что делать в случае, когда подрядчик не признает результатов внешнего аудита своего приложения? Экономически вроде бы логично не трогать работающий софт: функции работают и падает не так часто, а после перегрузки поднимается. Пусть так и будет – перфекционизм отвлекает подрядчиков от написания новых, нужных бизнесу функций. Если выбирать: потратить ресурсы на исправление непризнанных ошибок или же на написание новых функций, бизнес скорее всего выберет второе. Только не забудьте взять с разработчиков подписку, что риски по эксплуатации обнаруженных уязвимостей их приложения принимают они – они же уверены, что их эксплуатировать невозможно.

При новых же разработках на уровне ТЗ вносите в требования обязательного отсутствия в заказном бизнес-приложений определенных классов уязвимостей - ссылайтесь на OWASP, CERT, рекомендации разработчиков платформ или другие лучшие практики. Тогда найденные некорректные конструкции, даже если они и не стали уязвимости, будут исправляться подрядчиками в рамках контракта. Десяток апдейтов, три пять лет работы независимой оценки защищенности приложений – и все ваши приложения станут безопасными. Если, конечно, не найдутся новые уязвимости и новые способы их обнаружения.

Оцените материал:
Total votes: 248
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.