3. fff
GOVERNANCE
(давайте сделаем вид, что это
всем интересно)
СТРАТЕГИЯ
(список благоглупостей ни о чем)
МОДЕЛЬ НАРУШИТЕЛЯ
(в воздухе отчетливо пахнет
кирзовыми сапогами)
БУЛШИТ-БИНГО
УПРАВЛЕНИЕ РИСКАМИ
(кажется, нам пытаются продать
что-то очень дорогое)
АУДИТ
(слово из финансового
лексикона, сейчас будут
приставать с какой-то ерундой, а
потом кого-то накажут)
ПОЛИТИКИ
(да-да, я обещал прочитать этот
талмуд, на следующей неделе
точно!)
COMPLIANCE
(о б-же, не было у бабы заботы,
опять что-то придумали)
ПОВЫШЕНИЕ
ОСВЕДОМЛЕННОСТИ
(не надо запускать ничего из
почты, понятненько?)
ИНТЕГРАЛЬНЫЙ ПОДХОД
(раньше у нас все было в
двадцати разных системах, а
теперь будет еще одна)
6. Политрук лжет!
Любая компания начинает с
управления бизнес-рисками.
Не существует никаких
“уровней зрелости”, бывают
процессные недостатки. А
комплаенс вообще от этой
картины сбоку.
#CODEIB
7. fff
Не человек для Субботы, а
Суббота для человека: не
анализ рисков требуется для
комплаенса, но существуют
риски комплаенса и они
ничем не отличаются от
любых других.
8. ПОЧЕМУ COMPLIANCE —
ОЧЕНЬ ПЛОХОЙ ДРАЙВЕР
ДАЖЕ ДЛЯ БАЗОВОГО УРОВНЯ
1 2 3
”ЭТО НУЖНО НЕ НАМ”
• инвесторам
• партнерам
• регуляторам
“НАМ ЭТО НЕ НУЖНО (НЕ
ПО КАРМАНУ)”
Где-то есть богатые
компании, которые могут
себе позволить все сделать,
как там написано, но это не
мы. У нас лишних денег нет.
“НАМ НУЖНО НЕ ЭТО”
Мы боремся за рынок и
наши ad hoc процессы
оптимальнее, чем
рекомендуемые.
9. COMPLIANCE без чеклистов?
• S/Ox
Один абзац текста, суть которого “вы должны правильно
считать свои деньги”
Несколько тысяч страниц комментариев
В итоге все равно интеграторы и консультанты “продают
решения”, в которых, сюрприз, все те же самые
чеклисты.
• ISO27K (еще когда он был BS7799)
Чеклисты добавлены “по просьбам трудящихся” и стали
основой для сертификации.
• GDPR
Ну, вы поняли.
10. Что нам еще продают: пентест как драйвер ИБ
• 5000 “критических уязвимостей”, но нас никто не
ломает?! Что-то тут не так. Покажите нам взлом!
У внутренней ИБ отсутствуют ресурсы на красивые
демонстрации, поэтому критичным считается только то,
что показали пентестеры — это и чинится. До следующего
пентеста.
14. 14
Наверное, ИБ это действительно
сложно ?
• Нет. Просто это не то, к чему все привыкли
• Наши традиционные метафоры запутывают,
а не объясняют.
15. Попытка метафоры #1:
в ИБ есть правила,
аналогичные СНИПам в
строительстве. Если делать
согласно рекомендациям,
риски автоматически будут
удерживаться в рамках
допустимого
#CODEIB
17. Если сохранить аналогию со
строительством, каждый
сарай, который мы строим,
должен выдерживать
ракетную атаку.
Причем ракет у атакующего
сколько угодно и каждый
месяц он придумывает пару
штук специально против
таких сараев, как у тебя.
#CODEIB
19. • Большинство из нас не служило в
армии.
• Те, кто служил, скорее всего, не
были на настоящей войне.
• Те, кто был, вряд ли могут
рассказать так, чтобы мы поняли.
• Какая война, если никого не
убивают?
• Военная дисциплина не работает с
гражданским персоналом.
МЫ НЕ СОЛДАТЫ
20. Но может быть, все-таки так
сойдет? Или еще немного
про так называемые
“лучшие практики” и
попытки им следовать.
#CODEIB
21. NYET
• “Лучшие практики” не лучшие
В них, как правило, полно устаревшей и просто вредной
ерунды вроде “парольных политик”.
• непрактичные
Полное следование заградительно дорого для бизнеса.
Частичное лишено смысла.
22. NYET (еще о “лучших
практиках”)
• Служба ИБ при активном содействии продавцов
будет “искать под фонарем” и “покупать решения”
• Бюджет, бизнес-смысл которого непонятен, будет
неизбежно урезан.
24. Если нет общей модели
рисков, люди используют
персональную
(если есть — тоже, но об
этом отдельно)
#CODEIB
25. Интерлюдия: персональная
иерархия рисков
• Увезут в лес и закопают
• Будет стоить мне карьеры
• Будет стоить мне работы
• Будет стоить мне бонуса
• Чьи-то еще проблемы
Цивилизованный мир отменил первые два пункта и скоро
отменит третий.
26. Интерлюдия: персональная
матрица рисков
Низкая вероятность Средняя вероятность Высокая вероятность
Потеря работы Авось, прокатит
Слабоумие
и отвага
Ну его на #$@
Потеря бонуса Все так делают Авось, прокатит
Слабоумие
и отвага
Чужие проблемы Все так делают Все так делают Все так делают
27. Интерлюдия: кейс продавца
“— Антивирус не дает мне открыть документы, которые вы
мне прислали!
— Какой антивирус?
— Касперский
— Я сейчас пришлю новый архив, попробуйте его”.
28. Интерлюдия: кейс продавца
Анализ рисков для продавца:
• Пренебречь требованиями безопасности: я могу получить
бонус 500,000р за эту сделку. С вероятностью 10% это
фишинг и меня уволят, я потеряю миллион на поиске
новой работы. Если еще узнают, что это был я.
• Сделать все правильно: no pain — no gain.
29. Интерлюдия: кейс продавца
Анализ рисков для CISO:
• Вероятность фишинга была не 10%, а 50%. И мне
наплевать, поймают продавца или нет, компания
потеряет деньги, а я — бонус.
• Вероятность того, что важная сделка сорвется из-за
технической детали завышена продавцом.
32. Не быть троечником
• Да, все компании делятся на тех, кого уже взломали, и
тех, кто еще об этом не знает.
• А еще мы все когда-нибудь умрем
• Это не повод вместо лучших возможных результатов
демонстрировать общественно приемлемый уровень
усердия.
33. Кейс: StuxNet: оправдания
• Это был черный лебедь! Атаку такого уровня нельзя
было предсказать: 0days, поддельные сертификаты,
огромные ресурсы на подготовку!
• Не было никакого смысла тратить миллионы на защиту:
атакующие все равно добились бы своего!
34. Кейс: StuxNet: трезвый взгляд
• Модель нарушителя для завода ядерного топлива в
неблагоприятной политической обстановке ДОЛЖНА
включать атаки такого уровня, в том числе 0day,
поддельные сертификаты и преодоление воздушного
зазора.
• Адекватный бюджет на информационную безопасность в
таких условиях ДОЛЖЕН быть на несколько порядков
больше.
• Набор базовых (для такой модели нарушителя и рисков)
мер позволил бы если не предотвратить, то помочь
обнаружить атаку до наступления серьезных
последствий
35. Кейс: StuxNet: выводы
Мы ничего не можем знать о том, была ли бы успешной
атака, если бы необходимые меры были приняты. Но мы
можем быть уверены, что ее и без того значительная
стоимость увеличилась в разы, вероятность успеха в разы
же бы уменьшилась, и наиболее вероятно, понадобились
дополнительные рискованные методы, например,
злонамеренные инсайдеры, для ее осуществления.
36. Что мы защищаем?
• Инфраструктура
• Данные
• Процессы
• Люди
Есть соблазн представить это как эволюцию, но нет.
38. Коммуникация с топами
• Больше слушать: топы знают, что важно для компании и
могут про это рассказать.
• Находить общий контекст.
• Не стесняться задавать вопросы.
• Не грузить ненужными техническими деталями, когда не
спрашивают, давать общую картину без жаргона.
• Понимать специфические риски и обсуждать их, включая
“неудобные” темы.
39. Коммуникация с менеджерами
• Больше слушать: среднее звено управления знает, как
работают критические процессы и могут про это
рассказать.
• Вникать в персональные модели рисков и находить
взаимовыгодные перспективы (вы здесь для того, чтобы
помогать, а не мешать)
• Убедиться в наличии консенсуса по поводу важности
соблюдения политик и процедур
• Обсуждать программы повышения осведомленности.
40. Коммуникация с сотрудниками
• Больше слушать: если безопасность кому-то “мешает”,
всегда найдется способ ее обойти в ущерб компании.
• Донести мысль, что политики и процедуры — не бумажки
для прикрытия задницы.
44. Немного интересной статистики
• Из регулярно сканируемых
систем за полтора месяца было
исправлено менее трети
• Примерно 50% систем были
отсканированы после
публикации эксплоита
• Практически все они
оставались уязвимыми до тех
пор, пока не начались
панические публикации о
массовых потерях
45. Некоторые мысли по поводу
хайпа
ИБ-хайп это хорошо, когда он закончился, потому что
“модные и дорогие” решения, эффективность которых
доказана практикой, переходят в разряд общедоступных.
ИБ-хайп это плохо, пока он продолжается, потому что
фактор моды и новизны позволяет продавцам снимать с
рынка сливки, несмотря на завышенную цену и
сомнительное качество.
46. Некоторые мысли по поводу
“крутизны” технологий
Самое важное и эффективное по результатам вложений
(управление уязвимостями и конфигурацией) — самое
скучное. Одинаково скучное и со стороны эксплуатации и
со стороны разработчика.
48. Количественное или
качественное измерение?
Во-первых, нужно признать, что оценки рисков, как
правило, берутся совершенно с потолка. Количество
релевантных данных крайне низко. Отсюда соблазн
перейти исключительно на качественную оценку.
Перейти от количественной оценки к качественной (и
соответствующим выводам) можно. Обратно — нельзя.
Неточные данные лучше их отсутствия.
49. Метод FAIR
Три оценки вместо одной: минимальная, максимальная,
наиболее вероятная (не путать со средней между
минимальной и максимальной)
51. Фрагментарные и
нерелевантные метрики — путь
к погибели
Если KPI (хотя бы и неформальные) не ориентированы на
общую бизнес-эффективность, неизбежно перетягивание
одеяла.
Нет критериев эффективности — ИБ либо бездельничает,
либо занимается вахтерством
52. Кейс: гостевой wifi
Юридический отдел сообщает, что возможны риски,
связанные с требованием идентификации пользователей
wifi.
ИБ говорит — не вопрос, сделаем по телефону, как в
метро!
53. Кейс: гостевой wifi
Что сразу пошло не так: регуляторный риск
• не был верифицирован (распространяются ли вообще
эти требования на непубличную сеть, это не кафе и не
бензоколонка)
• не был оценен количественно (во что нам обойдется,
если мы не будем делать вообще ничего)
• не рассмотрены разумные способы снижения с
использованием имеющихся организационно-
технических мер (посетители и так все учтены в журнале
регистрации)
54. Кейс: гостевой wifi
Цена бездумного “вахтерства”
1. Непосредственные затраты на внедрение и
обслуживание системы
2. Потери рабочего времени
3. Раздражение гостей и партнеров — не способствует
бизнесу!
4. Дополнительные потери за счет нестабильной работы
системы с иностранными номерами
5. Дополнительные угрозы ИБ (“а к чорту это глюкалово,
давай я тебя к офисной сети подключу”)
55. Кейс: гостевой wifi
Но нам не с чем сравнивать! Мы не знаем цену того риска,
с которым боролись!
Атомарные KPI юридического отдела в порядке
Атомарные KPI службы ИБ в порядке, “были небольшие
проблемы, но мы их решаем”
“все хорошо поработали”
Что это значит для бизнеса — никто не спрашивает.
59. Некоторые животные равнее
< “Специальные проекты”
< Значительные внутренние ресурсы (Google, FB,
Amazon ..) — могут строить все, что нужно
< Значительные финансовые ресурсы (Fortune 1000,
топовый финтек и банкинг) — могут покупать все,
что нужно
< Процветающий бизнес
< Бедность
< Нищета
60. Некоторые животные равнее
• Индустрия ИБ работает на
снятие сливок, остальным
достается пролетарский жмых и
объедки с барского стола.
• Практики “как мы это сделали у
нас в FB/Cisco/Yandex” плохо
переносятся на “обычный”
бизнес.
• Даже “процветающему” бизнесу
крайне критична простота
внедрения. Бедным и нищим —
только managed service, и
дешево.
• Людей из компаний ниже уровня
бедности мы просто не видим,
они не ездят на конференции.
61. Что нужно, чтобы запустить
обновленную программу ИБ
в организации
#CODEIB
62. Всего три вещи
1. Спонсор (топ-менеджер, который коммуницирует
риски и стратегии с остальными руководителями)
2. Лидер (стратег, ответственный за реализацию
программы, обычно CISO)
3. Экспертиза (понимание специфических деталей или
направления аутсорсинга)
63. Почему CISO это не спонсор
Google: “securityweek no seat for you”
CISO де факто несмотря на букву C воспринимается как
техник без права голоса и права узнавать новости бизнеса
своевременно.
Изменить в одночасье эту ситуацию в большинстве
компаний малореально, а работать нужно уже сейчас.
Человек, к которому относятся иначе, обычно называется
VP of Information Security или как-то так.
64. Как это делается?
(список благоглупостей)
1. Стратегия
2. Коммуникация
3. Измерение эффективности
4. Корпоративная культура безопасности
5. Не бояться узнать что-то плохое
6. Не бояться отдавать на аутсорс то, чего не умеешь
65. Стратегия
Стратегия информационной безопасности — это не
дурацкий кирпич на триста страниц, содержащий
копипасту консультанта из Big4. Читать такое никто не
будет.
Стратегия — короткий документ, в котором перечислены
основные риски, актуальные сценарии атак и способы
снижения рисков в ближайший год. Не больше 20-25 минут
на чтение.
Раз в год или чаще его пересматривают. Документ должен
быть понятен всему топ-менеджменту.
66. Стратегия
Для совсем далеких от IT должно быть executive summary
на ОДНУ страницу, без технического жаргона и
канцелярита, абстрактных лозунгов и так далее. Строго по
делу.
Можно на две, если придумалась хорошая инфографика.
67. Коммуникация
Раз в год или чаще лидер берет спонсора за пуговицу и
обсуждает с ним текущие результаты и проект новой
стратегии. Дальнейшее зависит от корпоративной
структуры управления. В хорошем случае удается создать
“совет информационной безопасности компании”, в
который входит весь заинтересованный топ-менеджмент и
получить какую-то обратную связь. При создании стратегии
в первую очередь нужно понимать, как с ней будет
работать управленцы среднего звена. Если никак, то и
стратегия работать не будет.
68. Измерение эффективности
Как уже говорилось — атомарные KPI создают конфликт
интересов. Эффективность любых мер безопасности
должна оцениваться интегрально.
Некоторые вещи очень трудно измерить, например, если
ИБ портит обстановку в компании “вахтерством” и слежкой
за сотрудниками, пересчитать косвенные потери в деньги
не всегда просто, а они есть. Но мы должны попытаться.
Поговорить с HR, например, они должны быть в курсе.
69. Корпоративная культура
безопасности
Корпоративная культура безопасности — это просто
способ тратить меньше и действовать более эффективно.
Не нужно ее недооценивать: приходилось видеть
компании, которые сумели сократить расходы на
безопасность в разы исключительно за счет того, что там
не нужно за каждой спиной стоять с палкой.
70. Не бояться узнать что-то плохое
Важный момент, к которому нужно быть психологически
готовым. Репрессии и массовые расстрелы — не наш
метод.
71. Не бояться аутсорса
Аутсорс — это не страшно, если уметь его готовить.
Закрывать себе возможности из-за недостатка внутренней
экспертизы — вот это страшно.