Скрытая угроза в заказной разработкеНа Cyber and Digital Security после пленарной сессии «Безопасность данных и информационных систем» поймали одного из спикеров —
Амира Акимбаева, Chief Products, Processes, People Officer в AST Cyber Lab. Он рассказал, какие риски стоит учитывать МСБ при выборе аутсорс-разработчиков.
«Сначала о плюсах. Заказная разработка обходится дешевле, чем содержание инхаус-команды. Для МСБ — это прямо мегаважно. Теперь о минусах. Точнее, о рисках.
☑️
Утечка конфиденциальных данных. В процессе разработки информация о бизнес-процессах компании может быть раскрыта третьим лицам.
☑️
Низкое качество кода — высокая уязвимость отдельных компонентов. Разработчики часто используют устаревшие библиотеки. Потому что в ТЗ редко прописывают, что они должны быть безопасными и новыми. Например, вам могут разработать ПО на базе технологий десятилетней давности.
☑️
Закладки в коде и скрытые функции для контроля системы или данных. Это так называемые бэкдоры или лазейки в разработанном ПО, которые позволяют вносить в него правки после сдачи проекта. Бывает и такое. Отследить их помогает своевременный IT-аудит ПО.
☑️
Уязвимости из-за слабого тестирования. Пропущенный или нерешенный баг может стать серьезной проблемой.
Как бизнесу себя обезопаситьВыбор исполнителя. Не надо искать «по объявлению» спецов, которые обещают быстро и дешево. Нужно выбирать проверенных разработчиков — обратиться за рекомендацией к знакомым, читать отзывы о подрядчиках и смотреть их предыдущие проекты.
Составление ТЗ. Мало составить грамотное техническое задание, надо отработать все возникшие вопросы, прежде чем его утверждать. А еще заранее учесть, что даже на утвержденном ТЗ в процессе выполнения возникнут правки. Всегда. Здесь надо заранее обговорить, в какие сроки и каким образом разработчики будут по ним вносить исправления.
Принимаем ПО. На этом этапе заказчику нужно провести функциональное тестирование. Оно проверяет, насколько написанный код выполняет поставленные задачи.
Далее — проверка на уязвимости. В идеале подрядчик должен провести его до сдачи проекта. Оценивать уязвимости также нужно с точки зрения бизнеса. Например, если нас взломают и все данные сольют, какие быть репутационные и финансовые риски? Об этом должны думать люди, принимающие ключевые решения в компании.
Держим в уме, что даже инхаус-разработка не дает стопроцентной гарантии безопасности. Но там знаешь, с кого спросить, в случае чего. Поэтому, подписываясь на аутсорс, нужно заранее подумать о юридической защите.
Бывает, что уязвимость в ПО обнаруживается после истечения срока контракта с подрядчиком. Такие риски нужно закладывать в ТЗ, допуская отказ от ПО, если оно не соответствует нормам безопасности.
❗️
Важно: при эксплуатации ПО нужно регулярно проводить код-ревью и технический аудит. Как можно протестировать ПО
Этим занимается отдельное направление Application Security (AppSec). Существуют различные Open Source приложения, которые позволяют изучать какие-либо уязвимости в конкретном секторе. Например, SAST — технология статистического анализа безопасности приложения. Сервис анализирует кодовую базу с точки зрение семантики и синтаксиса на наличие уязвимостей. Есть и другие доступные анализаторы.
Минус таких решений в том, что за их обновление отвечает независимое сообщество разработчиков. Крупный бизнес обычно использует решения проверенных вендоров.
Еще нужно провести анализ компонентов, библиотек и зависимостей. Сегодня разработчики используют готовые конструкции. Тем не менее их нужно проверять на уязвимости, баги и лицензирование.
Некоторые библиотеки можно использовать только для определенного типа ПО, другие — с указанием автора, в некоммерческих целях и т.д. В Казахстане судебных прецедентов пока не было, чего нельзя сказать про другие регионы».
#мнениеэксперта #ИБ
@sandyq_orda – цифровизация Казахстана в деталях
