Кот в мешке: вопросы безопасности при M&A

Кот в мешке: вопросы безопасности при 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

Попробуйте, и всё получится!

sterh@yandex-team.ru

Наталья Куканова