Если ты не заметил, мы тут постоянно говорим о том, как писать безопасный код и защищать платформу. Все это полезно и важно, но безопасность — это не какой-то чеклист из действий и правил, это целый процесс. И самое главное тут — люди, которые этот процесс поддерживают. Это профессионалы своего дела, а не жадные интеграторы или хитрые консультанты со стороны.
Цели
В каждом проекте под безопасностью понимаются совершенно разные вещи. Для кого-то ИБ — это бумажки и бесконечные терки с регуляторами. Другим требуется обеспечить внутреннюю безопасность, защититься от недобросовестности своих же сотрудников. А кого-то беспокоит именно защита внешнего периметра, угроза взлома. Для каждого отдельного случая нужно сформулировать свой набор задач и необходимых спецов. Возьмем защиту внешнего периметра, которой я занимаюсь в данный момент.
Какие проблемы есть при защите внешнего периметра? Самое очевидное — дыры, через которые можно получить доступ куда не следует. Но само понятие «дыра» очень абстрактно. Дыры бывают разные — в платформе, в приложениях, в инфраструктуре ЦОДа или облака. Во всех этих сценариях возникают особые задачи. А есть еще и проблемы privacy, важно, где и как мы храним данные, за которые отвечаем. Тут мы должны учитывать и локальное законодательство, и требования регуляторов (скажем, Visa/MasterCard).
Такая куча задач приводит к тому, что нужны процессы, которые будут отвечать заданным целям. Попробуем разобрать некоторые из них.
Процессы
Итак, во внешнем периметре мы имеем некую платформу, некий софт и некие данные. Защищаемым активом здесь являются именно данные пользователей, которые мы обрабатываем, и то, что мы «ограниченно предоставляем» особым клиентам.
Допустим, мы используем AWS как площадку. Надо позаботиться о шифровании данных и их хранении у третьих лиц, к тому же мы должны четко информировать пользователя о том, какая информация нами собирается и что мы с ней делаем или не делаем. Все это уже отдельная проблема и работа.
Кроме того, у нас есть сервисы, по сути — приложения, которые мы разрабатываем и предоставляем, в них могут быть дыры как в коде, так и в логике; плюс есть платформа, которую также нужно поддерживать в «защищенном» состоянии. Для простоты разделим все на процессы и подпроцессы:
- Поддержка privacy:
- местное законодательство. Информация и то, как мы с ней работаем, не должна нарушать законов;
- требования регуляторов. Условия обработки информации могут быть продиктованы не только законами, но и требованиями сторонних сервисов, которые мы используем;
- специфика бизнеса. В компании могут быть свои правила и свое видение работы с той или иной информацией. Например, если мы производим нечто и предоставляем это пользователям (например, платный контент), то это нечто также надо защищать и это тоже становится защищаемым активом.
- Анализ рисков:
- классификация информации;
- анализ возможных проблем. Потенциальный ущерб и прочие «бумажные» темы, которые становятся актуальными в самый неподходящий момент;
- оценка ресурсов и целесообразности тех или иных проектов по ИБ или иных решений.
- Построение архитектуры защиты:
- оценка attack surface;
- принятие решений по технической реализации. Алгоритмы, технологии, логика защиты должны учитывать возможные векторы атаки, риски и многие вещи. Это тот самый момент стыка бумажников и технарей :);
- выработка стандартов для проектов, например HttpOnly, SSL требования к ключам, формат лог-файлов их хранения и так далее.
- Безопасная разработка кода:
- автоматизация. Средства сканирования кода, например статические анализаторы, которые встраиваются в цикл производства;
- обучение персонала. Выработка единого стиля программирования;
- аудит кода. Для критичных кусков кода при определенных условиях (неминорный патч, новая версия…) необходимо проводить в том числе и ручную проверку кода.
- Реагирование на инциденты:
- поддержка систем IDS;
- bug bounty;
- работа с CERT;
- расследование инцидентов;
- работа в режиме hotfix с R&D.
- Поддержка ИБ:
- patch managment;
- vulnerability mangment;
- организация локальных ивентов (например, обучать разработчиков принципам безопасной разработки кода).
Все это — сложные и многогранные процессы, техническая и бумажная работа, которой должны заниматься правильные люди.
Люди
Итак, кто нужен для нашего проекта? Какая она, идеальная команда?
Директор
Куда без босса? Кто будет представлять ИБ в среде топ-менеджмента и быть лицом там, наверху? Неважно, как его называть — CISO или директором по ИБ. Важно, чтобы этот человек представлял цели бизнеса, цели ИБ и делал все это эффективным. Он разбирается в проблемах бизнеса, он понимает риски и принимает сложные решения. Непосредственно директор ответственен за все, что делает его команда, и именно его волю и видение реализуют все остальные. В то же время эта воля базируется на фидбеке и опыте его людей.
Менеджер
Когда бумаг много, процессов тоже становится много и нужен кто-то, кто будет решать задачи на уровне менеджмента всего этого: что в первую очередь, что во вторую, что у нас еще не сделано, а что делается медленно, как переложить ресурсы и где их слишком много. Это абстрактно, конечно, и зависит от конкретной команды, но менеджер — этот тот, кто помогает все держать связанным по времени, срокам и прочим бумажным вопросам. Их может быть несколько в зависимости от размеров работы. Сюда, в принципе, можно внести любого «бумажника», который решает определенные задачи на уровне «надо, чтобы было так», но и который бы понимал, как это сделать на верхнем уровне (задачи 1, 2, 6 — построение процессов, и их планирование весьма тяжелый труд).
Технический персонал
Архитекторы, инженеры ИБ идут последними в списке, но именно это самый ценный ресурс. В нормальной команде все держится на их экспертизе, навыках и заключениях. Ни один менеджер или директор не скажет «давайте внедрять то или это» или «риск тут именно такой» без того, чтобы инженер не ПОДТВЕРДИЛ истинность вышесказанного. Потому что менеджеры мало знают о реальных рисках, атаках, уязвимостях… они берут то, что им говорят инженеры и консультанты (если своих инженеров нет). Именно инженеры ИБ смогут точно оценить тонкие риски, связанные с IT, выявить уязвимости как в логике, так и в коде, проводить работы по анализу логов систем ИДС, и вообще это ниндзя (задачи 1, 2, 3, 4, 5, 6 — да эти люди вовлечены во все процессы, если подумать).
В итоге идеальная команда, где менеджеры помогают техперсоналу — инженерам, архитекторам и прочим хакерам своего отдела — координировать их работу и процессы, ну и ресурсы, а те, в свою очередь, помогают менеджеру быть в теме и достигать цели. Директор же контролирует эффективность и счастье бизнеса в целом и команды ИБ в частности, как свое дитя. Тогда эффективность будет расти, а цели достигаться, причем реальные цели, а не отписки. Конечно, проблемы будут всегда и везде, главным образом — далеко не все могут позволить себе иметь такую команду, и даже далеко не всегда она целесообразна. Но все же иметь технаря ИБ в довесок к грамотному менеджеру ИБ сильно повысит адекватность вашей СУИБ, причем в разы. Можно очень тонко комбинировать аутсорс-услуги с применением собственных сил, в зависимости от задач и поставленных процессов, но нельзя полностью уходить на растерзание консультантов и интеграторов. Это чревато потерей контроля над ситуацией и зависимостью от сторонней компании в важных процессах.
Зачем?
Что же я хотел сказать всем этим? Не скидывайте задачи ИБ в довесок к разработчикам и системным инженерам, если это не часть процесса (например, самоконтроля и правил разработки кода). Но не надо доверять всю техническую часть консультантам со стороны и интеграторам. Если есть менеджер, но ему нечего менеджить, кроме как проекты с интеграторами и аутсорсерами, — это грустно.
Интеграторы и прочие сторонние консультанты заинтересованы в продаже своих услуг. Это не значит, что они не нужны в принципе, — просто надо знать возможности и цену любой работе. Например, проще нанять одного инженера, чтобы он внедрил IDS и настроил правила именно под твою систему, чем нанимать интегратора, который внедрит систему из коробки, а та будет реагировать на кучу false positive, и придется покупать у них еще и мониторинг ивентов как аутсорс.
К тому же часто интеграторы хотят внедрить «несколько» больше дорогих штучек, чем нужно тебе, но так как у тебя нет понимания того, что именно нужно (нет инженеров, архитекторов), то придется верить своему интегратору. Я знаю случаи, когда крупный банк после найма интегратора нанимал стороннего консультанта, чтобы тот оценил адекватность интегратора, и как бы стравливал их. Что ж, главное — платите деньги, а там любые извращения доступны!
Так что посыл мой таков: ИБ — это люди, которые ответственны, профессиональны и инициативны на всех уровнях, будь то бумажная ИБ или IT Security, и комбинация таких людей в вашей команде — залог успеха и счастья :).
