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

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

Теперь можно будет попробовать заговорить на одном языке с теми заказчиками, которые, помимо того, что хотят выстроить у себя ИБ‑процессы, являются еще и полноценными разработчиками собственного ПО. Поехали!

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

Какие эти игры, для чего их внедряют в работу?

Как помочь растормошить команду SOCа и заставить их бороться против настоящего, а не вымышленного злоумышленника? С чем чаще всего связана некоторая халатность в отношении процесса постинцидента и как это влияет на процесс расследования в целом?

От чего в наибольшей степени будeт зависеть этап подготовки к расследованию и само расследование? Сегодня мы рассмотрим взаимосвязь пентеста для компании и процессов Lessons Learned.

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

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

Представьте, что вы заходите в оснастку какого-то продукта и у вас нет quickstart guide, обучения, ничего. Как вы в нем будете разбираться? А как настраивать? Как может выглядеть продукт для того, чтобы им могли и сразу пользоваться, и сразу разрабатывать?

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

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

Эта история будет несколько личной - с одной из предыдущих команд, в которой я когда-то была просто инженером, много лет назад мы начинали строить SOC для заказчиков, не сильно-то и понимая, как это делать правильно.
В ход шло все - международные стандарты, здравый смысл и желание «сделать хорошо». В итоге, оглядываясь назад, мы видим, что то, какими стали центры сейчас и какими они были тогда - очевидно, очень разные вещи. Но и то, каким стал SOC, собранный нами за 1-2 года, поразительно отличалось от всего, что было в самом начале - от идеологии до непосредственно исполнения.
В какой-то момент результат был признан конечным, но на самом деле все только начиналось.

Это вторая статья из цикла «Взаимодействие ИТ и ИБ». Первую статью можно прочитать здесь.

Зачем ИБ-шникам ИТ-системы?

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

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

Многие процессы, статьи и корпоративные легенды апеллируют к понятию «security champion», иногда утверждая, что человек с такой ролью способен сделать невозможное (как говорили и мы в статье о противостоянии разработки и безопасности). Но кто же на самом деле скрывается за этим понятием, какие задачи решает и каков в целом смысл его существования?

При расследовании инцидентов есть несколько ключевых моментов этого процесса для аналитиков, на которые в данной статье мы обратим внимание – это корректность самого расследования, верная категоризация произошедшего, а также приоритет. Грамотно расставленные приоритеты, а именно, правильно рассчитанная критичность инцидента, в значительной степени влияет на скорость принятия решений аналитиком и на эффективность его работы в целом.

SOC представляет собой набор людей и процессов, который, подобно живому существу, постоянно развивается и эволюционирует. Без этого сложно представить себе команду расследования. И понятная категоризация, в данном случае – понятная система метрик и понятий – помогает выстроить еще и те процессы, которые начинаются тогда, когда расследование завершено. Речь пойдет о подготовке к процессу lessons learned, или о пост-инциденте: в правках и тюнинге могут нуждаться плейбук, регламент, а зачастую и автоматизация – к примеру, может потребоваться донастройка источника или SIEM. И как раз чтобы знать, куда смотреть, на что обращать внимание, аналитик, проводящий подобную работу, руководствуется результатами предыдущих этапов – категоризацией инцидента в разрезе было или не было, выявлено правильно или неправильно.
От флага, полученного на этапе реагирования и расследования, может зависеть многое – как время аналитика, так и область поиска ошибки с дальнейшим ее исправлением.
Понимание, в какой области находится проблема, как с ней разбираться и как к ней подступиться, даже то, в какой системе эта проблема находится – ко всему этому можно прийти, разбирая случаи подтвержденных/не подтвержденных инцидентов и false positive сработок.

Иллюстратор: Ольга Фурман специально для Security Vision

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

Нередко в потоке рабочей рутины и при постоянном погружении в процесс опытный руководитель может сразу подметить первые признаки усталости и выгорания среди аналитиков и операторов SOC. С еще большей частотой команды, непрерывно, замотивированно и с энтузиазмом работающие над сложными или однообразными задачами, замечают свое «нерабочее» состояние уже по факту.

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