InfoSec Game

Про культуру

Почти на каждой конференции слышу тезисы про культуру ИБ. Контекст — мы можем накручивать любую защиту техническими средствами, но пока не будет культуры цифровой грамотности — всё это бессмысленно, потому что человек — самое уязвимое звено системы.

И вот вопрос: а что мы сделали, чтобы эта культура появилась?

Минутка занудства:

Культура — сложившиеся у людей ценности, нормы, обычаи, верования и обряды, знания и умения, техника и технологии, способы мышления, деятельности, взаимодействия и коммуникации.
— Большая российская энциклопедия

Исключим, что иногда ИБ действительно похожа на обряды, верования и обычаи. Вернемся в ту часть определения, где ценности, нормы и взаимодействие.


Ценности

Несколько лет слышу про "продажу ценности ИБ руководству". Но большая масса все ещё торгует страхами:
- придет регулятор и накажет;
- придет хакер и всё сломает;
- придет аудитор и всё перечеркнет.

И с одной стороны, история понимаема: зачем заморачиваться и менять способ получить бюджеты, если и старый способ работает? Особенно в условиях оборотных штрафов.

С другой же — пока остается такая позиция с нашей стороны, бизнес не начнет воспринимать нас иначе, чем налог на деятельность.


Нормы

Всем поставить на рабочие компы антивирус. Никаких доступов не из офиса. Но генеральному директору можно — он же генеральный. И ещё админу. Потому что кто ему действительно запретит (а не на бумаге)? А то, что работа сотрудников в командировках встанет — это мелочи, зато безопасно.

Наша паранойя — это известная болезнь. И её наличие не означает, что за нами не следят.

Но цель бизнеса — зарабатывать деньги. И нам, как функции, которая помогает бизнесу, действительно важно понимать, что, зачем и от кого мы защищаем. И адекватно оценивать потребности бизнеса, когда мы вводим ограничения.


Взаимодействие

Банальная история: продакт-менеджер заводит договор об интеграции на согласование. Договор посмотрел юрист, руководитель менеджера и финансы. Вопрос: кто должен вспомнить, что к согласованию нужно подключить ИБшника? И знают ли они вообще о том, что это нужно?

Бумага — это скучно и нудно, чем меньше бумаги — тем нам же проще. И особенно приятно потом ругаться, что коллеги глупые и неосмотрительные.

И из-за этого в итоге пострадают все:
- IT, когда будет это подключать и поймет, что схема какая то странная и требуется внезапно доп оборудование,
- продакт, когда к нему возникнут вопросы у ИБшника,
- все участвующие, потому что не подключили вовремя,
- а в случае инцидента в рамках интеграции — ещё и сам ИБшник, потому что не отследил и т.д.

Культура начинается с нас. Она не сформируется за день, неделю или месяц. Это долгая, кропотливая работа. Это выстраивание совместных процессов, которые учитывают интересы всех сторон. Это системы by design, построенные совместно с IT. Это работа с внутрикомом, который поможет вам объяснить просто сложные вещи. Это постоянная видимость для коллег, когда они уверены, что получат от вас помощь даже в глупых ситуациях, а не осуждение и насмешки.

Культура ИБ начинается с нас. С наших контактов с коллегами. С наших действий. И с наших историй.

PS Навеяно коллегами-девопсами, которые действительно захотели сделать правильно, а не бумажки для.

#reflection@infosec_game

Про проекты и процессы

Читаю книгу Павла Алфёрова по проектному управлению. С первых же страниц зацепило объяснение про проекты и процессы на примере системы Киневин. Это весьма наглядная интерпретация. Хочу опустить классические определения и показать саму модель.

Здесь под ”задачами" я подразумеваю что-то, что нужно сделать. Вне зависимости от формы постановки задачи, инициатора, описания и т.д. Просто какой-то кейс, который нужно решить.

Суть в том, что все задачи можно разделить на 4 домена:

1. Хаотические (chaotic)
Есть абстрактная идея, что нужно что то сделать. Это всё, что известно о задаче.

2. Запутанные (complex)
Есть сложная задача, которую в теории можно сделать, но как — это ещё надо поизучать. Скорее всего, участвовать будут несколько отделов, потребуется глубокая экспертиза, много времени и несколько итераций.

3. Упорядоченные сложные (complicated)
Есть понятная задача. Всё ещё могут участвовать несколько отделов, всё ещё нужен опыт участников, но что делать и каким образом — вопросов не вызывает.

4. Упорядоченные простые (simple)
Есть типовая задача, которая многократно повторялась. Есть чёткие инструкции, как её решать, понятны сроки.

И пятый - начальный - домен: неопределенный (когда нет понимания, куда отнести задачу).

По мере движения от хаоса у упорядочиванию уменьшается степень нашего непонимания, что делать. В первом домене обычно сложно управлять чем бы то ни было — это история про антикризис и быстрое принятие решений. Во втором (и часто третьем) доменах применяем проектный подход к управлению. Четвертый (и иногда 3) — выстраиваем процесс.

И в этом же, на мой взгляд, прекрасный ответ на вопрос "Когда в SMB должны появиться процессы?".
Примерно тогда, когда у вас появляются типовые задачи, которые вы решаете в рамках рабочей рутины. Если для вас каждый кейс — это что-то новое и не поддающееся стандартному решению, или кейс единичный и не повторится, можно смело забыть про выстраивание процесса. Но когда задача становится периодической и требует какого-то обязательного набора пунктов — процесс будет оптимальнее на долгой дистанции.

При этом стоит держать в голове 2 важных тезиса:
1. Не нужно усложнять то, что можно сделать просто.
2. Выбор домена всегда субъективен для каждой компании.

#processes@infosec_game
#systematization@infosec_game

Про аудиты

Ничего на работе не предвещало беды, но тут пришли они. Аудиты. Поэтому следующая заметка будет посвящена именно им. Взгляд с проверяемой стороны.

Минутка занудства

В наших законах сейчас не прописано определение аудита ИБ. Есть определение для банковской системы (СТО БР ИББС-1.1-2007):

систематический, независимый и документируемый процесс получения свидетельств аудита деятельности организации БС РФ по обеспечению ИБ и установления степени выполнения в организации БС РФ установленных критериев аудита ИБ, проводимый внешней по отношению к проверяемой независимой проверяющей организацией

То есть, "правильный аудит" — это:
- независимая проверяющая организация,
- для проверяемой компании устанавливаются критерии аудита,
- весь процесс документируется.

С независимостью проверяющих все очевидно, критерии устанавливаются законодательством, а аномальное количество сопутствующих бумажных упражнений — это не прихоть проверяющих, а обязательная часть процесса. И конечно, это систематическое действо, а не разовая акция.

Я хочу выделить здесь ключевую фразу: "оценка соответствия требованиям". Затем, чтобы в последствии ожидания от аудита формировались правильно. Это в первую очередь сравнение с "эталоном", который устанавливает нормативка. А дальше сильно зависит от того, насколько вам (не) повезло.

Насколько это действительно полезно?

Теперь вернемся к вопросу полезности. Что хорошего нам может принести оценка соответствия требованиям?

Во-первых, мы получаем для себя не только головную боль от заполнения бумажек, но и понимание, про какие из этих бумажек мы забыли, что не отследили в изменениях законодательства, а какие ВНД было бы неплохо обновить. Для компании это полезно, потому что:
- актуализируется понимание, за что ещё может прилететь и под какие ещё требования вы попадаете,
- бизнес более четко представляет, в какие места стратегии какие косты нужно будет заложить на следующих проектах,
- снижается вероятность совсем внезапных штрафов (например, за невовремя или не поданное уведомление об обработке ПД).

Во-вторых, есть шанс на появление той самой схемы сети или того самого флоу обработки данных, которые вы все никак не могли собраться нарисовать. С какой стороны не посмотри, а систематизация того, что есть только в головах -- это важно. Вдруг случится магия, и полезность этих схем внутри команд будет так велика, что они станут обязательным правилом запуска продукта?

В-третьих, после аудита следуют рекомендации (или замечания, зависит). И это означает возможность более весомых обоснований бюджетов, расширения штата, а кроме того — уточнение целевой системы (TO BE). Более того, часто требования озвучиваются заранее (от 6 месяцев до 2-3 лет), и до вступления их в силу у вас есть шанс ощутимо сэкономить денег: строить системы, учитывающие требования ИБ by design, сильно дешевле, чем потом переделывать.

Подводные камни

Качество аудита всегда зависит от проверяющего.
Кто-то смотрит исключительно в бумагу, кто-то закапывается в технику. Кто-то требует регламенты, утвержденные приказом ГД, кто-то считает, что инструкции в базе знаний достаточно. Кто-то пишет понятные запросы на человеческом языке, а кто-то закидывает 7 строчек формулировок, в которых даже юристы теряются. И это сильно зависит от конкретного аудитора.

Психика ИБшника (и некоторых ИТшников) может пострадать.
На моменте, когда приходит осознание, что цикл совершенствований бесконечен, и к моменту, когда вы выполните текущие требования, появятся новые. Обычно острую аллергическую реакцию вызывают тонны документации — на процесс, на систему, регламенты etc. Увы. С чем-то помогут ИТшники (не стоит писать для них правила без учёта их мнения), с чем-то — юристы (особенно по ПД), с чем-то — внутренний контроль.

Завышенные ожидания.
Аудит — это не красная таблетка, после которой все станет хорошо, а безопасность станет безопасной. Это скорее дорожная карта из AS IS в прекрасное жестокое далёкое TO BE. Но путь этот предстоит проделать вам, а не проверяющим.

#process@infosec_game

Про системность

В текущей итерации нашей истории модно говорить про успешный успех, достижение целей, эффективность, продуктивность и т.д. А у меня который день в голове крутится цитата из книги Джэймса Клира:
"focusing on creating systems rather than setting goals"
Он говорит об этом в контексте привычек, но я хочу пропустить это через призму ИБ.

Система не исключает постановку цели (-ей), но немного смещает фокус. И в работе специалиста ниже уровня C-level мне это видится более релевантным: выстроить систему. Постановка цели, особенно смартированной — это измеримый результат и четкие вехи. Система же дает более полный контекст.

Опять же, я не противопоставляю одно другому. В моем понимании это взаимодополняемые подходы. Но предлагаю обратить внимание на следующий пример.

Допустим, есть глобальная цель, которую в SMB руководители часто формируют как "построй ИБ". Пропустим стадии отрицания, торга и депрессии и перейдем к принятию, где ИБшник садится и пытается понять, что значит это мифическое "построй ИБ". Он проверил, что уже есть, придумал, что должно быть, принес руководителю план на 5 пунктов, что нужно сделать, чтобы была та самая "построенная ИБ". Руководителя всё устроило (ну а вдруг?), и специалист начинает действовать. У него есть 5 целей, и он последовательно приступает к их достижению.

Берёт пункт 1) Делать бэкапы базы пользователей. Через какое-то количество итераций стычек с ИТ, бэкапы всё-таки появляются в компании, делаются автоматически и на регулярной основе. Считать цель выполненной?

С точки зрения реализации строчки — да. С моей точки зрения — нет, цель не достигнута. Потому что "Делать бэкапы" — это итеративное действие, которое совершается с прицелом на то, что в нужный момент эти бэкапы помогут восстановить работу бизнеса. Значит, точно также должен быть налажен процесс развертывания из бэкапов, люди должны уметь это делать в ручном режиме, если автоматика засбоит. Должны быть ресурсы, на которые бэкапы развернутся (не те же, что пострадали, иначе расследование инцидента будет сильно затруднено). Должна быть документация, если вдруг разворачивать придется джуну. Должен быть предусмотрены права на развертывание. Должно быть реализовано переключение всех сервисов на резерв в случае падения основной базы. Ну и в конце концов, сами бэкапы нужно проверять, не только наличие файла, но и содержимое. И это -- системный процесс.

Система здесь не только в том, чтобы выстроить полный процесс. В моем понимании, таким же образом должно быть отработаны все, что специалист делает или меняет. В данном примере -- по всем 5 пунктам.

Могу набросить сверху ситуаций, где это точно также работает:
1) аудит (для галочки формальным выполнением требований, или чтобы действительно защита работала?)
2) личные планы (бесконечный чек-лист или second brain?)
3) здоровье (идти к врачу, когда совсем все плохо, или регулярно проходить чекапы, чтобы до "совсем всё плохо" не дошло?)


Ну и статья Клира на тему:
https://jamesclear.com/goals-systems

#baseline@infosec_game

Про карьеру и “войти в ИБ”

Молодые студенты периодически приходят с вопросом "А где получать много денег, но чтоб без ответственности?". Если пропустить сарказм и язвительность, то мой ответ прост: там, где у вас будут гореть глаза.

Кто-то говорит, что ИБ — это комплаенс, бумажки и нормативка. Принимается.
Вдруг вам нравится
- разбираться в хитросплетениях формулировок, придуманных нашими регуляторами,
- педантично и последовательно составлять систему документов,
- вести аккуратные реестры,
- искать пересечения в нормативке, стандартах, практиках и гайдлайнах...
Добро пожаловать. Без вас будет сложно понять глобальные тренды отрасли, требования регуляторов, рекомендации и советы в стандартах...

Для кого-то ИБ — это EDR, SIEM, ID/PS, DLP, SAST... Тоже принимается.
Может быть, вам ближе
- закапываться в низкоуровневые настройки,
- оптимизировать конфигурации,
- контролировать IT системы,
- исследовать технологии...
Добро пожаловать. Без вас вряд ли ИТ-системы будут комплексно защищены, ИТ-специалисты вряд ли поймут, почему удобно != безопасно, а реагирование на инциденты может даже не начаться, если нарушитель останется незамеченным.

Кто-то ассоциирует ИБ с процессами — управлением комплексными системами, верхнеуровневым пониманием всей системы защиты, выстраиванием взаимодействий. И это тоже принимается.
На случай, если
- ваше стратегическое мышление способно учитывать детали из не связанных на первый взгляд систем,
- вы просчитываете последствия на несколько шагов вперед,
- вам нравится составлять модели и адаптировать их к реальности,
- выступать медиатором между разными функциями...
Добро пожаловать. Без вас профильным специалистам из разных направлений будет очень сложно найти общий язык, ИТ-системы придется переделывать, как только до них доберутся нарушители, а системы безопасности без единой оркестрации будут приносить больше вреда, чем пользы.

И так можно написать про любое из направлений: аудит, пентест, реверс, аварнес...
По отдельности ничего из этого не заработает.

Не важно, по какому из направлений вы пойдете. Важно, чтобы вы горели тем, что делаете. Тогда будут и хорошие зарплаты, и интересные предложения, и такие же горящие люди вокруг.

Наверно, это применимо не только к ИБ.
И вообще, получился пост мотивации.
Гори, чтобы светить.

#motivation@infosec_game

Про вопросы и ожидания

В книге Джона Миллера "Проактивное мышление" приведён метод QBQ — Question by Question. Он описан как способ в том числе наладить коммуникацию, снять стресс от общения. В основе концепции лежит идея, что мы несем ответственность за свой выбор и принятые решения. А правильные вопросы служат отправной точкой для информации, на основе которой мы решения принимаем. И в самом введении поднимается насущная, на мой взгляд, проблема: позиция жертвы.

Она выражается во фразах "я не виноват", "это не моя обязанность", "это не наша проблема" и подобных. Вопросы, которые за этим следуют — "почему это случилось со мной?", "почему они не могут нормально работать?"... Дальше следуют логичные "а кто виноват?". И на этом моменте у меня возникают очень чёткие ассоциации со сферой ИБ. В частности, в диалоге между бизнесом и регуляторами.

Регулятор сказал — мы должны делать.

Очень часто встречаю эту позицию в самом деревянном её исполнении. Трактовать написанное в лоб любят и специалисты по комплаенсу, и аудиторы. И так мало людей, которые задали вопрос "а зачем это требование ввели?". Так мало людей готовы разобраться в том, как устроены системы, и "что автор имел ввиду". Гораздо проще принять позицию "так написано в законе". У меня это вызывает чёткую ассоциацию с той самой позицией жертвы.

Мало кто спрашивает, зачем это нужно.
Мало кто думает, какие интересы затронуты.
Мало кто пытается понять, как можно выполнить требования, если чуть чуть отойти в сторону от очевидного решения.

Да, есть и глубинные проблемы, которые исторически сложились. Высокий порог входа для осознания нормативки. Бешеные информационные потоки, в которых сложно ориентироваться. Противоречия или дублирования между требованиями регуляторов.

Но, кажется, вопросы могут быть полезны. На Инфобереге подняли вопрос о создании единой системы тестирования для прикладного ПО, которая бы проверяла в том числе вопросы интеграций между системами, стабильность работы и остальные жизненно-важные функции. Представитель МинЦифры прямо ответил, что они ждут такую инициативу от бизнеса. В тот момент у меня честно возник вопрос: а бизнес в курсе, что от него этого ждут? Я работаю в сегменте SMB и допускаю, что у enterprise есть информация об этом ожидании. Но для меня это было внезапным.

И сколько ещё таких моментов, когда каждая сторона друг от друга чего то просто ждёт? Не описав ожидания, надеясь, что собеседник сам догадается?

Что стоит дороже:
- страх разговора с регулятором vs затраты компании, которые последуют за исполнение законов "в лоб"?
- страх показаться глупым vs понимание реальных ожиданий руководства?
- страх выглядеть некомпетентным vs понимание работы системы?

Мы перестали задавать правильные вопросы, зациклившись на своей экспертности. Мы разучились признавать ошибки в погоне за успешным успехом. Мы иногда даже не можем найти приемлемый формат работы с коллегами. Может, уже пора?

Я ещё вернусь к этой теме. Возможно, более системно. Когда для себя смогу сложить кубики QBQ в правильную башенку.

#communication@infosec_game

Ценность презентаций

Опять по следам Cyber in Privacy. У студентов курса прошла защита проектов. И в полной мере раскрылась необходимость смежного навыка: проведения презентаций.

Защиту оценивали с 3 позиций: ИБ, DPO и бизнес. Мне "повезло" оказаться в роли представителя бизнеса. Больших трудов стоило отсечь, что представитель бизнеса знает и понимает о технической части. В стартапе — наверно, понимание и осознание используемых технологий глубже, чем в СМБ. В СМБ — больше фокуса на стратегии и процессах, чем на конкретных вариантах реализациях. Но это только мое предположение, потому что запуска бизнеса у меня ещё не случалось и рассуждать я могу только с позиции того, кто точно также с бизнесом разговаривает.

Задание звучало как "нужно в течение года привести дела в порядок (в контексте ИБ) и оставить человека на почасовке для контроля"

Одна из групп представила "продуктовый подход". Со схемами, большими таблицами, ссылками... И абсолютно было непонятно, что со всем этим делать с позиции бизнеса.

Было понятно, что:
1. проделана огромная работа,
2. коллеги умеют в Миро, таблицы и странные аббревиатуры,
3. коллеги ИБшники не хотят нести ответственность за процессы ИБ, оставляя всё на контроль CEO,
4. чтобы применить их спроектированную модель защиты, нужно либо $24k, либо $32k.

Что бы хотелось понимать:
1. Какое состояние сейчас?
2. Зачем нам что-то менять?
3. Куда мы должны прийти?
4. Каких ресурсов это потребует?

Справедливости ради, по условиям кейса коллеги разбирали случай стартапа. Поэтому возможно, что СЕО действительно понимает, что такое ассеты и что скрывается за аббревиатурами. Но пока что у меня не было в практике стартапов, когда при штате в 10 человек компания действительно думала про безопасность. Также возможно, что я сильно утрирую позицию, и представители бизнеса со мной не согласятся.

Но что ещё важно для принятия решения?

#softskills@infosec_game
#reflection@infosec_game

Security Awareness с другого ракурса

Сегодня будет немного рефлексии по следам курса Cyber in Privacy. Это такое короткое знакомство непрофильных специалистов с миром ИБ.

Курс в некотором роде стал для меня откровением. Ценно, что взрослые люди готовы учиться чему-то новому. Ценно, что и инициаторами, и основной аудиторией выступили юристы. Ценно, что с большим трудом, но они разбирают на понятные для себя понятия привычные нам системы.

В каком-то роде это тоже можно назвать Security Awareness, хотя обычно в этот процесс вкладывают немного другое значение. Под SA мы обычно понимаем навыки распознать социальную инженерию, или правила работы с информационными системами, или навыки реагирования на нештатные ситуации... Но почему-то упускаем, что базовая грамотность — это тоже осведомленность, причём более фундаментальная, чем умение распознать звонок мошенников.

И, что ещё более странно, это также должно работать и в обратную сторону. Мы все — граждане правового государства. Но большинство немного знает свои права, изредка — чуть-чуть обязанностей (типа соблюдения ПДД). Но мы — простые смертные не-юристы — вряд ли разберемся в законах без помощи переводчика с юридического на человеческий. И вряд ли захотим, несмотря на то, что это более реальный мир, чем привычный нам цифровой.


Собственно, выводы и наблюдения.

1. Коллеги-преподаватели (в основном ИБшники) часто забывают, что многое из их привычных выражений — сленг, и требует явной расшифровки.
Пример: "подключиться к розетке". Мне интересно, как долго юристы осознавали, что розетка — это про локальную сеть, а не про 220В?

2. Готовиться к лекциям вместе — это весело.
Один из преподавателей попросил помощи в том, чтобы адаптировать свое понимание рисков под ИБшную специфику. Мы проговорили примерно час, со смехом, шутками, кейсами и формулами. Организаторы решили выложить эту запись со словами "лучше уже не будет". По крайней мере, веселее — точно.

3. Иногда мы забываем, что не у всех есть технический бэкграунд.
И это выливается в вопросы типа "а есть ли у облачной инфраструктуры какое-то физическое воплощение?". И дело зачастую не столько в понимании технологий, сколько в структуре мышления. Она действительно отличается.

4. Преподаватель учится у своих студентов так же, как они у него.
Самый главный вывод, подтвержденный в очередной раз. На некоторые вопросы не получается ответить сходу. Некоторые кейсы стоит отмечать просто потому, что коллеги на работе могут думать также, и было бы неплохо эти моменты прояснить. И не нужно стесняться задавать вопросы. В обе стороны.

#reflection@infosec_game

IS Processes: Base-line

Хочу предложить своё видение того, какие процессы ИБ должны появиться в компании в первую очередь. Подразумеваю, что уже в каком-то виде есть понимание инфраструктуры. Сознательно сейчас не говорю про комплаенс, фрэймворки и внедрение процессов.

1. Управление доступом
В широком смысле Identity&Access Management. Если компания начинает развиваться, появляются новые сотрудники, появляются новые направления -- всё это должно тянуть за собой минимизацию и разграничение прав доступа.

2. Управление сетями
Логика та же: Network Management становится необходим, когда появляются отделы с разными функциями, приложения и сервисы, которые между собой общаются, данные с разными "целями" и т.д.

3. Бэкапирование
На случае, если все станет совсем плохо, у вас должна быть возможность быстро восстановить инфраструктуру. Как сервера, так и БД. И люди, которые эту будут делать. И ресурсы, на которые вы будете это делать.

4. Реагирование на инциденты
Что считать инцидентом -- решает бизнес. Есть правила, прописанные регуляторами, но про них позже. Важнее, что именно для компании будет являться инцидентом, и чего это событие будет стоить. Нужно понимать, как вы будете реагировать, когда неприятности случатся.

5. Security Awareness
Когда нет ресурсов -- всегда есть люди. И они -- все равно самый слабый фактор в системе защиты. Люди точно должны знать, что им нельзя делать и почему (второе не менее важно, чем первое). У них должна быть возможность прийти к ИБ, задать глупые вопросы и получить помощь.

————————————
To be continued:
- define base-line

#baseline@infosec_game

Зачем мне SOC?

Начну с заметки по следам Softline Security Summit. Была дискуссия про SOC глазами заказчика. Из зала был задан прекрасный вопрос: "Зачем мне SOC?".

Ответ на вопрос "зачем?" буквально формирует и требования, с которыми вы выходите на рынок, и канву, которая будут заложены в процессы мониторинга и реагирования.

Предлагаю для начала ответить на 2 дополнительных вопроса:
1. Что изменилось, если вы раньше не задумывались о SOC'е, а теперь решили идти в эту историю?
2. Какие ресурсы на реализацию этого проекта у вас действительно есть?

Внедрение процессов — это всегда небыстро и через сопротивление изменениям. SOC — это слаженная работа людей, процессов и систем. Небольшие компании часто в первую очередь при выборе смотрят на аутсорс, потому что своей команды не хватает. Это логично, но есть нюанс: полностью отдать на аутсорс мониторинг можно, но реагировать с определённого уровня придется своими силами.

Возвращаемся к вопросам.

1. Что изменилось?

Произошли изменения в инфраструктуре? Вы закончили срез по рискам и посчитали, что митигация через SOC существенно снизит вероятность инцидентов? Изменилась нормативка, и теперь вам необходимо следовать требованиям комплаенса? Откуда вообще появилась необходимость?
Если причина в том, что "у всех есть, а у меня нет" — оно того не стоит. Я крамольно считаю, что в базисе SOC не является обязательной мерой. Это очень ресурсоемкий процесс, и часть функционала можно закрыть существенно меньшими затратами сил, времени и денег. В SOC есть смысл идти в 2 случаях:
— бизнес дорос до момента, когда затраты на реализацию будут меньше, чем стоимость пропущенного инцидента,
— это обязательное условие продолжение деятельности (из требований комплаенса, например).
В остальных случаях стоит проверить настройку base-line, моделирование рисков, соответствие целей ИБ целям бизнеса и ещё много всего.

2. Какие действительно есть ресурсы?

Я сейчас не про дорогие системы и аутсорс. Я про людей.
Часто предложение отдать систему, связанную с защитой, под IT, у ИБшников вызывает непонимание и негодование. Между "отдать систему защиты в другой отдел" и "не внедрить SOC" я выбираю первый вариант.
Скорее всего у вас уже есть большая часть системы мониторинга — IT отделы обычно весьма внимательно относятся к инфрастуктре, которую они сопровождают. Да, это IT мониторинг, не ИБ. Но в контексте — это не важно. У вас уже есть команда, которая умеет настраивать сбор логов, их читать, выводить на какие-то метрики и сопровождать. Просто они могут не знать про аспект безопасности. Им нужны понятные плэйбуки, понятные граничные значения, после которых они будут обращаться к ИБшникам.
Разумеется, с ростом IT Sec отдела эти процессы нужно разводить, и снимать нагрузку ИБ с IT отдела. Но в условиях отсутствия людей, автоматизация и помощь соседних отделов ценны как никогда.

—————————
To be continued:
- IS Processes: base-line
- IS goals & strategy

Привет.

Меня зовут Phoenix.
Я занимаюсь информационной безопасностью в IT компании. Основная специализация -- выстраивать процессы защиты. Иногда я выступаю на конференциях. Иногда читаю лекции. И за это время накопилось немало заметок, которые мне помогали разобраться с новыми темами, взглянуть на уже известное под другим углом или просто сохранили мои впечатления от каких-то событий.

Я хочу поделиться ими. Возможно, вы подскажете мне контекст, который я не учитываю, или совершенно другое видение. Может, просто заберете себе какую-то заметку, и тогда я порадуюсь, что кому-то она тоже оказалась полезна.

В моей жизни не случалось блогов до этого момента, поэтому начну с не очень амбициозной цели: пусть это будет 4 заметки в месяц. Будут записи и про ИБ, и про смежный контекст: софт-навыки, систематизацию, математику и разное близкое.

Спасибо моему другу и наставнику.
Пинок под хвост иногда действительно работает лучше, чем доброе слово.

Channel created