Кот в мешке: вопросы безопасности при m&a
TRANSCRIPT
Кот в мешке: вопросы безопасности при M&A
Наталья Куканова
Логотип партнераЛоготип Яндекса (Сервиса)
3
Какое-то вступление
4
Какое-то вступление
5
Немного статистики
› 2013 год — 5 сделок, в том числе kinopoisk.ru
› 2014 год — 12 сделок, в том числе avto.ru, AnyVoid, AdFox
6
Мы не будем говорить о…
› соответствии требованиям
› покупке зданий и офисной инфраструктуры
▌ Обычно мы покупаем стартапы и перевозим их в наш офис
▌ и на наше оборудование.
M&A без безопасности
8
Что покупаем?
› Технологии, know-how, базы клиентов/поставщиков/whatever
› Программный код
› Команду
› Бренд
9
Проблемы
› Небезопасные технологии
› Уязвимые архитектура и код
› Немотивированная команда
› Отсутствие внутренних процессов безопасности
10
Процесс
› Сделка совершается без участия Службы ИБ.
› В лучшем случае, Служба ИБ подключается на этапе интеграции и может дать свои рекомендации.
› В худшем случае, Служба ИБ узнаёт о покупке после запуска сервиса под новым брендом.
11
Риски
▌ Может повлиять на:
› безопасность других сервисов
› безопасность внутреннего окружения
› бренд компании
12
Простой ответ
▌ Служба ИБ должна участвовать в процессе покупки новых
▌ компаний!
Пробы пера
14
Общий процесс M&A в Яндексе
› Все сделки проходят через менеджера по слияниям и поглощениям.
› Существуют формальные проверки, которые нужно пройти перед заключением сделки.
› Без получения согласия по всем применимым проверкам сделка не заключается.
15
Вариант 1. Утром деньги, вечером стулья
› Любая сделка — это товарно-денежные отношения
› Небезопасные технологии, уязвимый код — недостатки товара, из-за которых можно получить скидку
› Алгоритм: стоимость устранения уязвимостей вычитается из суммы сделки
▌ Но стоимость устранения уязвимостей пренебрежимо мала
▌ по сравнению с суммой сделки.
16
Вариант 1. Утром деньги, вечером стульяБазовые параметры: 1. Время закрытия (t) одной уязвимости (чел/дней).2. Количество (q) уязвимостей из отчета по аудиту.
Коэффициенты:1. В зависимости от критичности уязвимости используем коэффициент:высоко (h) критичные уязвимости — 1средне (m) критичные уязвимости — 0,5низко критичные уязвимости — 0 2. В зависимости от формата сделки используем коэффициент (f):покупаем весь сервис — 1 покупаем технологию (или контент), когда-то будем переписывать реализацию — 0,8покупаем технологию (или контент), сразу будем переписывать реализацию — 0 3. Если используются персональные или личные данные (d) пользователей — 1,5
Итоговая формула для оценки рисков: I = ((s*t*q(h)*1)+(s*t*q(m)*0,5))*f*d
17
Вариант 2. Оценка рисков
› Уязвимости не только требуют денег на устранение, но и повышают риски.
› Используя уязвимости, злоумышленник может … да много всего он может.
▌ Но оценка рисков подразумевает наличие вероятности реализации
▌ уязвимостей, которую владелец сделки считает практически
▌ нулевой, а Служба ИБ — практически стопроцентной.
Вариант 3. Наш
19
Наши цели при покупке?
› Уязвимый код не попадает в инфраструктуру Яндекса.
› Сервисы под брендом Яндекса защищены от атак злоумышленников.
› Команда понимает и принимает наши требования к безопасной разработке.
20
Процесс
▌ Покупаем только технологию:
› Наше согласование не требуется, но мы включаемся на этапе разработки нового продукта
21
Процесс
▌ Покупаем технологию плюс код:
› Аудит сервиса
› Требование закрыть уязвимости, несовместимые с жизнью, до переезда в нашу инфраструктуру
› При использовании небезопасных технологий переезд осуществляется в выделенное окружение
22
Процесс
▌ К нам присоединяется команда:
› Общий вводный курс про культуру информационной безопасности в Яндексе
› Спецкурс про безопасное использование технологий
› Включение в общую программу повышения осведомленности сотрудников Яндекса
23
Переезд
24
Всё идёт как по маслу?
▌ Конечно, бывают исключения:
› Срочно, срочно, срочно…
› Имиджевая сделка, всё остальное неважно
▌ Но 99% сделок обрабатывается по общему сценарию.
25
Почему это работает?
› Понятные для бизнеса требования и алгоритм принятия решений
› Удобно организованный процесс
26
Работающий процесс — удобный процесс
› Удобная и исчерпывающая заявка на внутренней вики
› Чёткий зафиксированный процесс, SLA
› Подробный отчёт с рекомендациями и экспертное заключение для менеджера сделки
› Помощь в закрытии уязвимостей и интеграции сервиса
27
Заявка на проверку сервиса
│ Главное — мы узнаём о сделке на этапе
│ её планирования и имеем время │ и пространство для манёвра.
29
