Виталий Балашов, руководитель подразделения инженеров по кибербезопасности ЕРАМ Ukraine, рассказывает, как правильно искать специалистов по кибербезопасности в качестве подрядчика.

Кибербезопасность — в приоритете

Пару дней назад я общался с владельцем магазина детских игрушек, который за время карантина оказался на грани банкротства. Когда люди перестали заходить в его магазин, предприниматель решил разместить свой товар на онлайн-маркетплейсе. Ситуация не единичная в современной реальности. Мы наблюдаем всплеск перехода бизнеса из традиционного офлайн-формата в онлайн. 

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

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

Виталий Балашов

Узнайте подрядчика в лицо

За годы работы я сталкивался в компаниях по созданию софта с разным отношением к кибербезопасности. В итоге разделил для себя их поведение на три модели (отмечу, что моя классификация основана сугубо на личном опыте).

Модель 1. Подрядчики, которые перекладывают ответственность

Компании этого типа обычно маленькие. Каждый новый специалист для них — затраты, каждая новая компетенция — вложения. Они не всегда заботятся о своем будущем и могут годами делать дешевые сайты на заказ. Но вот к ним приходит клиент, который хочет знать, как обеспечена кибербезопасность его продукта. Он начинает задавать вопросы и, если подрядчик настроен с ним сотрудничать, обращается к консультантам (и это обычно дороже) или ищет специалиста. Так в штате ІТ-компании появляется человек, который со временем может курировать все вопросы, хотя бы косвенно касающиеся кибербезопасности. Фактически на него перекладывают ответственность. Иногда эта модель успешно работает, но в целом у такого специалиста возникает риск быстро выгореть и все бросить.

Модель 2. Спецподразделение без реального влияния

Предположим, компания поняла, что одного специалиста ей уже не хватает. Менеджеры принимают решение собрать целый отдел. У них появляются эксперты, а с ними и типичная ошибка: в компании нет отлаженных процессов и достаточных полномочий у исполнителей. В таком случае команда превращается в отдел специализированной техподдержки, который делает отчеты, кому-то их отправляет, но ситуация не меняется. Я часто слышу о таких административных проколах на собеседованиях. Развиваться профессионально в такой среде сложно. 

Модель 3. Несколько команд с разными сферами влияния и реальной ответственностью 

Эта модель требует вложений и потому применима к крупным сервисным компаниям типа ЕРАМ. Я считаю ее самой успешной. Она предполагает четкие процессы, понятную оргструктуру и наличие нескольких команд, которые распределены как с точки зрения географии, так и компетенций (одни занимаются безопасностью заказчиков, другие — безопасностью внутри компании). У нас большой спрос на сервисы по кибербезопасности, поэтому мы регулярно берем в команду новых экспертов.

Проверяйте с умом

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

1. Вопрос 1. Как вы обеспечиваете безопасность?

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

1. Вопрос 2. А можете устроить "экскурсию по цеху"?

Попросите показать, как устроен процесс работы, где команда отслеживает прогресс (это могут быть такие инструменты, как Jira, Trello и другие), есть ли отдельный раздел по безопасности. По аналогии с арендой офиса загляните не только в само помещение, но осмотрите также коридор, осведомитесь о соседях, загляните в "служебные помещения". Так вы сможете понять общий уровень предлагаемого решения.  

1. Вопрос 3. У нас ЧП. Что делать будем?

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

1. Вопрос 4. Что с документацией?

Требуйте качественную базовую документацию. Иногда она может быть довольно краткой, со ссылками на официальные источники и стандарты или приложенными файлами. Если вы уверены в компетенции своих подрядчиков и не относитесь к государственному сектору, не бюрократизируйте, ведь усилия инженеров по созданию красивых документов и описаний могут быть излишними и обойдутся вам дороже. 

1. Вопрос 5. Предоставляете ли вы модель угроз?

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

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

1. Вопрос 6. Откуда вы берете требования к безопасности?

Подрядчики обычно опираются на требования заказчика или на различные стандарты типа OWASP ASVS, CIS Benchmarks, GDPR и другие. Уточните во втором случае, почему выбран именно этот стандарт. Если не будет корректного и детального ответа, то это повод задуматься.

А вот этого делать не стоит

Не разгоняйте команду после первой ошибки. Если в первом релизе совсем нет багов, это очень странно. Особенность продуктов IT-отрасли — наличие дефектов на старте. Команда разработки самостоятельно их исправляет, главное — дайте обратную связь. А вот как она это делает, заслуживает вашего внимания. Убедитесь, что инженер по безопасности перепроверяет исправленный дефект и только после того, как он дает добро, условную карточку на Trello-доске закрывают.

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

На финише

Когда разработка продукта завершена, попросите стороннюю команду, не принимавшую участия в разработке, провести оценку безопасности, аудит и пен-тест. Успешного развития в новой реальности!