Так вышло, что я послушал подряд несколько подкастов, посвященных теме той или иной безопасности. Пора отходить от этой темы и сейчас предлагаю вашему вниманию третий выпуск про безопасность.
На этот раз объектом конспекта будет 164 выпуск подлодки про продуктовую безопасность.
В гостях Сергей Белов - руководитель продуктовой безопасности в MailRu.
Продуктовая безопасность?
Я ранее не сильно сталкивался именно с термином "Продуктовая безопасность" и до конца не понимал в чем её отличие от безопасность в целом:)
Техническая безопасность, как я понял, заключается как раз в механизме хранения данных, инвалидации токенов, защите от инъекций и все то, что направленно на конкретные технические действия с целью сохранения данных пользователей в безопасности.
А вот про продуктовую безопасность посложнее . Если пытаться гуглить, то мы находим только продовольственную безопасность, которая связана с едой, а не с программированием. Как понял я, продуктовая безопасность - ряд действий, направленных на повышение безопасности продукта. Это может быть выполнено с разных углов: добавить капчу на вход, добавить лишнее подтверждение по SMS и тд.
Чем занимается безопасники?
Есть такой стереотип, что безопасники - те, кто усложняют нашу жизнь и те, кого нужно бояться. На самом деле эти люди выстраивают процессы защиты данных и могут, так или иначе, быть полезными на любых уровнях продукта. То есть это необязательно разработчик - например это может быть Product Owner, который решил, что на входе обязательно надо будет делать двухэтапную аутентификацию (код подтверждения).
Есть еще понятие "корповые безопасники" - это как раз те люди, которые контролируют, чтобы вы приходили на работу и не выносили никакие данные наружу.
Вспоминаю как я ехал на встречу в офис Роснефти и мне пришлось заранее описывать что за ноутбук я буду проносить с собой в офис, который был нужен для презентации - коллега взял свой ноутбук не декларировал и пришлось его оставить на первом этаже, вызывать для этого специально обученного человека, который сидел в фое с ноутбуком коллеги пока мы были на встрече, потому что оставить ноутбук внизу было по-просту негде.
В состоявшихся командах безопасники часто участвуют во всех процессах: они приходят на встречи, тихо сидят и краем уха слушают - в общем всегда на чеку). Так же в чатах с клиентами можно видеть что то подобное: "Всем добрый день, добавили нашего сотрудника СБ в чат".
А что разработчики?
"Я разработчик - я хочу писать логику, а не эти ваши эксплоиты, иньекции и тд. Пусть безопасники этим занимаются"
Пример грустной истории общения с разработчиками
Вопрос безопасности, конечно же, не должен ложиться только на плечи безопасников. О безопасности нужно думать всегда. Гораздо эффективнее и выгоднее инвестировать ресурсы команды в обучения азам и детялам безопасности разработчиков и максимально шарить эти знания, что приведет к значительному уменьшению дыр в безопасности вашего продукта. Один из классных способов мотивации - геймификация. Ввести оплату бонусами, отгулами, деньгами за поиск и устранение дыры в безопасности сервиса.
Где искать дыры и откуда они берутся?
Самый простой способ создать новую дыру в безопасности - создать какой-нибудь новый функционал:) Мы живем в реальном мире и наши проекты всегда живут, что приводит к новому функционалу, и нам необходимо отслеживать наличие новых дыр:)
Открытые источники знаний про эксплоиты и др
У хакеров есть своя инфраструктура: свои соц. сети, форумы, гуглы и тд. Есть закрытые от обычного мира (тот самый "даркнет"), а есть открытые - например, гугл для хакеров vulners.com. Заходим, вбиваем название сервиса или библиотеки и получаем список известных уязвимостей. Разумеется, не стоит быть уверенным, что на сайте будут все уязвимости, но полезной эта информация будет в любом случае.
Если мы говорим про опенсорс, то можно посмотреть Issue со словами security, exploit и др. В мире опенсорса есть компании, которые активно поддерживают общую безопасность мира свободного ПО. По поводу поддержки и финансирования обсудим далее.
Интересный момент - если вбить в этом поисковике ffmpeg или imagemagick, то можно увидеть огромное количество проблем. И бывают, конечно же, ситуации, которые решить нормальным путем невозможно, - в мире работы с файлами как-то фильтровать ввод - достаточно трудоемкий процесс. Приходится придумывать какие-то другие меры защиты. Например можно запускать файловый сервер внутри docker контейнера или на отдельном сервере с урезанными правами.
Вознаграждение за поиск уязвимостей
Гость подкаста говорит такую фразу - "Поставь себя в позицию проигравшего и будешь выигравшим". Hacker One - один из примеров принятия позиции проигравшего. hackerone.com - Авито для безопасников. Регистрируете свой сервис, указываете вознаграждение за найденные дыры и хакеры их находят и получают за это деньги. То есть хакеры (вроде бы темные ребята) могут совершенно легально зарабатывать, взламывая ваш сервис, чтобы на этих уязвимостях не начали зарабатывать нелегальные хакеры. Такой процесс называется Bug bounty.
Но, если вы имеете свою команду разработчиков, то, казалось бы, зачем выставлять это на отдельный сервис, если можно просто сделать форму обратной связи, куда будут писать желающие заработать?
Ответ прост - расширяемость. На призыв найти баги могут сбежаться хакеры не только не из вашей страны, но и с другого континента и из мест, куда отправить деньги может вообще стать проблемой. Поиск дыр - специфичный бизнес и в нем участвуют специфичные люди:) Простой перевод на карту сбербанка тут уже не сработает. Плюс еще найти баг может человек из Индии. Как ему переводить деньги? Поэтому площадки-посредники оказываются достаточно удобным способом находить исполнителей.
Спрос на эти услуги достаточно велик и, если ваш сервис не будет представлен на какой-нибудь известной площадке, то про акцию "получи деньги за взлом" достойные "дыроискатели" могут и не узнать:) В общем тут все, как я понял, схоже с миром простых объявлений - проще продать телефон на авито, чем городить свой сайт для этой цели.
Но, конечно же, лучше сделать мало, чем ничего, и начать с простой формы на сайте, куда будут приходить информация от багхантеров.
Сколько тратить на поиск дыр?
Интересно было услышать, что MailRU потратил на Bug Bounty более 1млн. долларов. Не нужно платить за все уязвимости. Нормально начинать с минимальных цен. Например, с 3-5 тыс. долларов. В качестве рекомендации указывается месячный бюджет от $3000 в месяц.
Некоторые компания платят не деньгами, а мерчем, письмами благодарности, что тоже имеет свою ценность. В общем, в любом случае за найденную уязвимость можно и нужно платить хоть чем-то:) Если же пойти к какой-нибудь специализированной компании, которая занимается поиском уязвимостей, то нужно готовиться тратить внушительную сумму и не факт, что результат будет сразу и покроет все дыры.
Багхантинг как работа
Багхантеры - люди, которые как раз ищут дыры за деньги
В целом в багхантинг может пойти любой желающий разработчик. Конечно, наличие опыта разработки не является достаточным условием, но начинать без опыта в разработке проблематично. Очень часто багхантеры находятся в поиске простых задач и теряют навык.
Например, находят дыры в JS коде в форме - можно через запрос к DOM получить список все заявок - легкие, пусть и не большие, деньги. Некоторые багхантеры пишут сканеры на автоматический поиск подобных уязвимостей. Этот бизнес тоже автоматизируется на ура.
По словам гостя, в среднем, на багхантинге можно зарабывать 3-10 тыс. долларов в спокойной загрузке, если набить руку. Я так думаю речь идет про тех, кто обзавелся сканерами или разработал их и работает в полуавтоматическом режиме.
Общие моменты по безопасности
В процессе прослушивания я отмечал для себя разные интересные моменты про продуктовую безопасность.
- Приходится балансировать между удобством сервиса и его безопасностью. Например, пароль: можно забить на сложность пароля, а можно сделать его супер сложным и тут уже выбирать, что вам важнее.
- Двухэтапная аутентификация покрывает большое количество дыр в безопасности
- Делая новый функционал всегда быть готовым к тому, что мы делаем и новые дырки
- Нельзя забывать про GDPR
Вместо заключения
Если вам понравился дайджест, то подписывайтесь на мой канал в Telegram (@amorev94), а если вдруг есть какой-то интересный выпуск, которым стоит поделиться в дайджесте или нашли ошибку или неточность, то, пожалуйста, пишите моему боту (@amorevbot).
