Всем привет! Сегодня расскажу вам о способе определения ложноположительных алертов, который был выработан совместно с коллегой по цеху и другом Николаем (@1Last) за время работы в SOC. К сожалению PhD в этом году перенесли, поэтому было принято решение поделится данным способом тут.

Кому он будет полезен и для какой, собственно, цели:

1. Для руководителей SOC и руководителей дежурной L1 - L2 — как способ оптимизировать ресурсы SOC (потому что мы изначально идём по более вероятному пути): структурировано и обоснованно отсеивать значительный объем шума — по нашему опыту, до 60-80% алертов на этапе роста SOC или в плохо настроенных средах.

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

3. Для аналитиков — использовать в повседневной деятельности подход, положительно зарекомендовавший себя на практике, и снизить ментальную нагрузку на принятие решения о вердикте алерта.

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

По следам ключевых трендов последних лет ИИ-модели добрались и до OSINT: так, LLM’ки успешно заменили специализированные инструменты вроде Maltego и Palantir. Crystal Lite для анализа блокчейна вновь доступен для работы, а Google SpreadSheets и Архивариус 3000 из года в год остаются актуальными инструментами осинтера. Подробнее со ссылками на софт и обзорные статьи читайте под катом!

В настоящее время одним из главных вызовов в кибербезопасности является дефицит кадров, который во многом сдерживает развитие отрасли. Энтузиасты-самоучки и профессионалы, переходящие в ИБ из смежных профессий (например, из ИТ), зачастую ощущают необходимость подтянуть свои теоретические знания по ИБ. Непрерывно совершенствуемые учебные курсы в ВУЗах, программы профессиональной переподготовки, тренинги и курсы от вендоров и учебных центров предоставляют прекрасную возможность получить структурированные знания по ИБ, однако в большинстве своём они подразумевают либо длительное обучение (во многих случаях - очное), либо дают информацию только по определенному направлению профессии. Состоявшимся специалистам, студентам и энтузиастам, интересующимся темой ИБ, возможно, было бы интересно получить некий справочник-учебник с актуальной информацией по большинству современных направлений ИБ. В рамках образовательных инициатив Security Vision мы начинаем серию публикаций, посвященную своду знаний по кибербезопасности - Cybersecurity Body of Knowledge (CyBOK).

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

В этой статье разберём, зачем нужно маскирование, какие данные требуют защиты, и представим opensource-инструмент, который поможет решить эти задачи гибко и эффективно.

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

Все вы уже наверняка наслышаны о том, что рекрутеры тратят на отсмотр одного резюме порядка 0,0000003 миллисекунды, но понимаете ли вы, что с этой информацией делать? А знаете ли вы, какой путь проходит ваше резюме с того момента, как вы его публикуете/отправляете до его преобразования с заветный оффер? Существует ли накрутка опыта в ИБ? Почему даже гениальный безопасник может остаться без внимания из-за плохого резюме? Кто и как смотрит ваше резюме, на что обращает внимание, и как вам с этим всем вообще жить? Вопросов можно наплодить еще очень много, так что погнали разбираться, как сделать из вашего резюме не просто красивый PDF, а полноценный инструмент продажи вашего опыта.

Всем привет! Зовут меня Владимир, я работаю специалистом информационной безопасности в бизнес‑юните Mail.ru компании VK. Запустить сканер внешнего периметра было одной из моих важных задач. Сделать это можно было двумя способами разобрать и использовать то, что было сделано раньше или создать что‑то новое. Я пошел по второму пути и... мы развернули инструмент на всю компанию.

Привет! Меня зовут Екатерина Пухарева, работаю в Авито руководителем продуктовой безопасности. Эта статья будет полезна тем, кто размышляет, стоит ли внедрять роль бизнес-партнёра по безопасности. В ней мы разберём, какую ценность эта роль приносит компании и чем она отличается от security champions.

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

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

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

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

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

За время своей работы в e-commerce-компаниях я собрала некоторый перечень подходов и инструментов защиты, которые реализую в своём направлении. Сегодня я хочу рассказать о маскировании вам, моим коллегам, которые так же, как и я, стремятся сделать данные безопасными, а жизнь пользователей — спокойной.

Как объяснить руководству, что AppSec — это не просто устранение уязвимостей, а важный инструмент для роста бизнеса? Как показать реальную пользу безопасности на языке цифр?

Меня зовут Анастасия Арсеньева, я аналитик данных в AppSec Solutions (ГК Swordfish Security). В этой статье расскажу о ключевых метриках AppSec, которые помогают компаниям принимать обоснованные решения.

Хабр, привет! Меня зовут Юрий Родионов, и я эксперт практики объединенных коммуникаций в К2Тех. Сегодня я хочу поговорить о теме, волнующей многих ИТ-администраторов и инженеров – о харденинге информационных систем и сервисов. В статье я поделюсь своим опытом проектирования и разработки архитектуры решения и дизайна ландшафта на примере сервиса электронной почты в периметре заказчика с применением подходов харденинга и концепции построения надежной и устойчивой ИТ-инфраструктуры. Сразу предупрежу: для профессионалов крупных государственных или коммерческих холдингов, где усиление инфраструктуры и ее отказоустойчивости – повседневная практика, мои советы вряд ли станут откровением. Однако материал может быть полезен тем, кто только начинает выстраивает защищенную инфраструктуру, развивает это направление в своей компании, старается придерживаться принципов гигиены информационной безопасности, стремиться повысить надежность сервисов и приложений, минимизировать риски простоев и обеспечить бесперебойную работу ИТ-ландшафта.

Привет, Хабр! Меня зовут Нияз Кашапов, я AppSec Lead в Купере. Недавно я рассказывал на ecom.tech Information Security meetup, как выстраивается процесс написания безопасного кода и разбора срабатываний статических анализаторов. Эта статья — изложение моего выступления с дополнительными комментариями. Я опишу подход, к которому мы пришли, и открою секрет, как мотивировать разработчиков смотреть свой код на безопасность.

DevSecOps — это не просто модное словечко, а целая философия, объединяющая разработку, безопасность и операции. Но как применить эту философию на практике? Здесь на помощь приходят международные стандарты.

В этой статье мы рассмотрим пять основных международных DevSecOps-стандартов: DSOMM, BSIMM, OWASP SAMM, Microsoft SDL и NIST SP 800-64. Мы разберем их особенности, сильные и слабые стороны, а также поговорим о том, как адаптировать эти стандарты к российским реалиям.

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

Театр начинается с вешалки, а официальные взаимоотношения компаний с подписания NDA – соглашения о неразглашении конфиденциальной информации. Вроде все просто. Подписал бумажку да пошел дальше. Но нет. На этом этапе часто начинаются разногласия между юристами и/или безопасниками двух компаний. Споры возникают из-за разных вещей. Например, из-за способа передачи конфиденциальной информации. Для одной компании будет приемлемо осуществлять обмен  посредством электронной почты, а для другой – только в бумажном виде с составлением акта приема-передачи. 

Киберустойчивость — неотъемлемое качество бизнеса в современных реалиях. Чтобы её достичь необходимо не только внедрять современные технологии, новые продукты и решения, но и грамотно управлять внутренними и внешними процессами. В этом помогают ИТ-методологии — в частности, ITIL и COBIT.

Меня зовут Ольга Агешина, я ИТ-консультант Innostage, и я расскажу о том, как популярные ИТ-методологии могут применяться в ИБ, а также на примере разберу их внедрение в конкретные процессы. В этой статье остановимся на ITIL, а в следующей — разберу COBIT.

1 Терминология

В «Надежность в процессах. Часть 1» [OpRes24-1] были определены (упрощены): надежность, процесс и надежность в процессах. Надежность – это способность безотказно работать (работать без отказов). Надежность процесса – это как способность безотказно работать («главное процесс»), так и выдавать требуемый результат («главное результат»). Количественно – это вероятность безотказной работы (вероятность застать процесс работоспособным) и вероятность требуемого результата на выходе процесса.

Для восстанавливаемых систем, а процессы в основном – это восстанавливаемые системы, применяют коэффициент готовности – вероятность в произвольный момент времени застать систему (в данном случае процесс) в работоспособном состоянии.

Это относится как ИТ-системе (кластер серверов) и не ИТ-системе (сейф), так и к системе процессов (операций) и составных частей процесса, включая его ресурсы.

Если в классической теории надёжности (Надёжность в технике [27.002]) обычно рассматриваются внутренние воздействующие деструктивные факторы на техническую систему типа отказ \ сбой оборудования \ ПО, то «Надежность в процессах и операциях» (операционная надёжность) рассматривает также непреднамеренные ошибки персонала (операционные риски) и внутреннее мошенничество, внешние атаки на процессы компании, клиентов компании (социальная инженерия), стихийные бедствия (техногенные катастрофы). В конечном счете неважно: «система процессов» отказала (не выполнила задачу) из-за какой-либо поломки или из-за ее перегрузки (от нежданного «наплыва клиентов» до DDoS-атаки), поэтому в состав показателей Надежность в процессах добавляем «доступность»:

Привет, Хабр! Меня зовут Ирина, я аналитик по информационной безопасности в Авито. В этой статье я делюсь нашим опытом и моими личными впечатлениями о выстраивании процесса оценки и управлении рисками информационной безопасности в Авито.

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

Прежде, чем объединяться, нам надо решительно размежеваться (Business continuity management vs Business Process Continuity vs Dependability in technics)

Синонимы: Надежность в процессах = надежность процессов = надежность операций = операционная надежность (с учетом синонимии словосочетаниями «сущ. + сущ.» [Морф23]).

En: dependability, reliability, resilience (availability, stability) Business Process. Непрерывность процессов — в контексте «business continuity» (Business Process Continuity, BPC) и т. п.

Привет! Я Максим Коровенков, DevSecOps Lead в Купере (ex СберМаркет). Хочу поделиться мыслями по поводу минимально необходимого набора процессов, сопутствующих внедрению сканеров безопасности в пайплайны разработки. 

В результате попытаюсь ответить на вопрос: «А что, собственно, стоит иметь в виду под фразой “Мы внедрили сканеры безопасности в пайплайны разработки”?» 

Да, в тысячный раз про пайплайны, но, как вы, думаю, догадываетесь, желание поделиться казалось бы очевидными мыслями появилось не случайно! Не так давно я завершил найм и укомплектовал свою DevSecOps-команду. В рамках поиска пришлось провести достаточное количество интервью, на которых я любопытствовал, как обстоят дела у соискателей с пайплайнами безопасности на текущем/предыдущем месте работы. Это удивительно, но для 90% респондентов фраза «внедрение сканеров безопасности в пайплайны» означает только факт внедрения. Лишь некоторые кандидаты упоминали отправку результатов в VMs/ASOC систему. 

Ведь действительно кажется, что все просто: запаслись вокабуляром из нескольких аббревиатур, внедрили инструменты, SAST, SCA, может что-то еще, настроили отправку результатов для AppSec-ов и, как-будто, можно идти бить баклуши. Но я на своем опыте убедился, что DevSecOps — это про глубокую проработку процессов. Поэтому в данной статье сконцентрируюсь больше на процессах, нежели на технике. 

Предлагаю наконец переходить к сути!

Когда занимаешься каким-то делом достаточно долго, начинаешь ощущать себя сидящим на берегу бурной реки. Мимо проносятся годы, теории, подходы и принципы, можно пронаблюдать весь жизненный цикл каких-то явлений и течений. Одним из таких явлений стало появление бизнес-партнёров по информационной безопасности, которых в англоязычном мире принято величать Business Information Security Officer (BISO). Явлению этому менее 10 лет (если говорить о формировании как института и роли), но оно стало уже достаточно популярным как в российском дискурсе, так и в зарубежном. На пути от олдскульного «специалиста по защите информации» к BISO происходило много событий, но, как известно, дорогу осилит идущий.

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