Архив за месяц: Февраль 2023

февральскому Microsoft Patch Tuesday

Обновил Vul­ris­tics-отчет по февральскому Microsoft Patch Tues­day. Пофиксил детекты софтов и типов уязвимостей, добавил комментарии из обзоров Ten­able, Qualys, Rapid7, ZDI, Kreb­sOn­Se­cu­ri­ty. Блогопостом и вядяшкой вероятнее всего займусь уже под конец праздников.

С днем защитника Отечества всех!

Про карту рынка Импортозамещение 2023 от CNews

Про карту рынка Импортозамещение 2023 от CNewsПро карту рынка Импортозамещение 2023 от CNews

Про карту рынка Импортозамещение 2023 от CNews. Это что-то феерическое. "Производители самых известных российских аппаратных и программных ИТ-продуктов, предлагаемых для замены зарубежных решений в наиболее важных сегментах." Интерес у меня был прежде всего к разделу "Корпоративное программное обеспечение -> Информационная безопасность".

То, что Vul­ner­a­bil­i­ty Management‑у, и даже в целом анализу защищенности, место не нашлось это ещё ладно. Допустим место нашей темы где-то в аналитике. Но то, что Pos­i­tive Tech­nolo­gies вообще нигде не упомянули, включая раздел SIEM, это просто смешно. 😀 Получается ИскраУралТЕЛ (без негатива, просто как пример) входит в список самых известных российских ИБ вендоров, а PT нет. 😅

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

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

Один очень популярный западный мессенджер заблокировал возможность делать голосовые вызовы. Пишет, что ему нужно выдать дополнительные права, чтобы совершать телефонные звонки и управлять ими. 🤨 А с чего бы это вдруг? И нафига?

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

Про Perplexity AI

Про Perplexity AIПро Perplexity AI

Про Per­plex­i­ty AI. По поводу Chat­G­PT моё мнение не поменялось. Это малополезный бредогенератор. Однако это не значит, что я против ИИ чатботов вообще. Приемлемая альтернатива, с которой я теперь частенько играюсь, это Per­plex­i­ty AI. Сервис также использует модель GPT‑3, но в отличие от Chat­G­PT имеет ряд важных преимуществ:

- можно использовать бесплатно и без регистрации
- работает с актуальными данными (например знает о MS Patch Tues­day на прошлой неделе)
- показывает пруфлинки, можно залезть и проверить на основании чего был нагенерен текст
- позволяет исключать нерелевантные ссылки и перегенерировать текст (например в запросе об "Alexan­der V. Leonov" можно убрать инфу подтянутую из биографии тезки-океанолога)

В общем, вполне удобная штука, если нужно быстро узнать мнение по какому-то вопросу, а самому искать, ходить по ссылкам и вычитывать странички не хочется. 🙂 На скриншотах сбор ссылок с обзорами MS Patch Tues­day и сбор громких кейсов по фишинговым атакам.

Антифишинг и Управление Уязвимостями

Антифишинг и Управление Уязвимостями. Возвращаясь к обзору рынка Vul­ner­a­bil­i­ty Man­age­ment систем от Anti-Mal­ware, наибольший интерес у меня вызвал вендор Holm Secu­ri­ty.

1. Раньше я о них не слышал. Из шведских VM-щиков я знал и общался только с Outpost24 . А тут оказывается есть ещё один шведский вендор, да ещё и существует с 2015 года. Круто!
2. Основная их фишка в том, что они совместили в одно решение Антифишинг и Управление Уязвимостями. 🤯 Очень необычно. Это меня особенно порадовало, т.к. на работе я как раз занимаюсь и Управлением Уязвимостями, и Антифишингом. 😅 Так сложилось. О нашей системе антифишинга был доклад на прошлом Off­zone (презентацию готовил я, а докладывал Павел Жерелин). Так вот, мне всегда казалось, что Антифишинг это для меня непрофильная нагрузка. А оказалось, что в Holm Secu­ri­ty всерьез позиционируют Антифишинг как часть VM‑а. "Благодаря Next-Gen подходу [Vul­ner­a­bil­i­ty Man­age­ment] платформа борется со всеми векторами атак, которым подвергается организация, включая защиту одного из самых важных активов — ваших сотрудников". Если сотрудники попадаются на фишинг, то это тоже своего рода уязвимость, которая исправляется обучением и другими мероприятиями. Согласитесь, довольно нестандартный подход. Так что теперь при случае могу говорить, что занимаюсь VM-ом не только для IT-инфраструктуры, но и для людей. 😁

Я, конечно, сомневаюсь, что в Holm Secu­ri­ty действительно считают Антифишинг такой уж неотъемлемой частью процесса Управления Уязвимостями. Вероятнее, что у них были эти 2 решения в портфеле и их маркетологи решили, что они будут эффективнее продаваться в рамках одной платформы. Ну и подвели некоторую базу под это. Однако, если в эту тему поиграться, то действительно можно сделать некоторые занимательные выводы и для Антифишинга, и для Управления Уязвимостями.

Смотрим на Антифишинг с точки зрения Управления Уязвимостями:
1. Если актив уязвим (сотрудник попался), то должен быть ответственный за актив, который сделает фикс. А кто этот ответственный? Видимо это непосредственный руководитель сотрудника, который должен был проводить инструктаж. И спрашивать нужно в первую очередь с него, а не с попавшегося человека.
2. Если в VM мы стремимся к полному покрытию IT-активов, то Антифишинг не должен быть выборочным, а должен покрывать всех сотрудников.
3. Если в VM мы не проверяем активы только на одну уязвимость, а стараемся проводить проверки для всех возможных уязвимостей, то и Антифишинг должен касаться разнообразных техник и психологических манипуляций, с которыми может столкнуться сотрудник в реальной фишинговой атаке.

Смотрим на Управление Уязвимостями со стороны Антифишинга:
1. Если в Антифишинге мы предлагаем попавшемуся сотруднику пройти обучение по ИБ, почему бы не назначать курс по ИБ для владельца уязвимого актива? Пусть разбирается почему обновляться это важно.
2. Если в Антифишинге мы ограничиваем доступ к входящем письмам тем сотрудникам, которым обучение не помогает, то почему бы не ограничивать работу владельцам уязвимых активов, которые не справились с поддержанием их в безопасном (обновленном) состоянии? Показал, что не можешь полноценно владеть активом и обучение не помогло — теряешь доступ к этому активу, пусть более ответственные люди за него отвечают.

Т.е. возможно подводить Управление Уязвимостями и Антифишинг под некоторый общий базис это не такая бредовая идея, как может показаться на первый взгляд. 🙂

Сколько нужно VM-щиков, чтобы поменять лампочку?

Сколько нужно VM-щиков, чтобы поменять лампочку? Андрей Прозоров спрашивает про ИБ-шников, но я за них за всех не скажу, поэтому давайте сфокусируемся на решении задачи именно с точки зрения Управления Уязвимостями.

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

1. Инвентаризация и аудит состояния (в первую очередь светимости). Мы вообще понимаем сколько у нас лампочек в организации, где они расположены, какого они типа, какой у них ресурс, какой регламент по их замене? Если нет, то это нужно собирать и поддерживать в актуальном состоянии (проверять, что в данных нет аномалий). В качестве исходных данных можно взять планы помещений, информацию по закупкам и остаткам на складе. Аудит может представлять собой периодический поэтажный обход, а возможно есть и более продвинутые способы мониторинга. Возможно в компании используются smart-лампочки, к которым можно относиться как к части IT-инфраструктуры? А возможно перегоревшие лампочки можно детектировать через анализ изображения с камер? Вариантов может быть много, нужно обсуждать с IT и АХО. VM-щик здесь должен быть заинтересован в первую очередь в том, чтобы процессом были покрыты все лампочки во всех помещениях (и во всех филиалах).

2. Агрегация данных и исправление. Сырые данные о состоянии лампочек нужно собирать, обрабатывать, заводить задачи на исправление на ответственных (у разных лампочек в разных локациях могут быть разные ответственные), отслеживать статус задач на исправление, при необходимости эскалировать (нужно понимать на кого и как именно). VM-щик здесь должен быть заинтересован в том, чтобы не было перегоревших лампочек без задач по исправлению, не было задач без ответственных и чтобы задачи выполнялись в срок. Идеально было бы, чтобы у ответственных за лампочки был регламент по контролю и плановой замене. Тогда и задачки бы закрывались сами или даже не заводились бы. Но это требует внедрения такого регламента и применение штрафных санкций за его невыполнение.

3.* Приоиритизация и применение компенсирующих мер. По мне если лампочка перегорела — она должна быть оперативно заменена. Но есть разные взгляды на этот вопрос. Например, лампочки могут перегорать слишком быстро и их будут не успевать менять. Как по мне, то это вопрос к инфраструктуре и архитектуре, почему нам так сложно лампочки заменять? Нормально ли это вообще? Но есть мнение, что нужно наоборот смириться с обстоятельствами и заменять лампочки только там где это ДЕЙСТВИТЕЛЬНО НУЖНО. Там, где люди уже ноги ломали, нужно менять в первую очередь, а там где просто мигать начала или из трех одна пока светит, менять во вторую очередь или вообще не менять. В принципе это также можно учитывать в заведении тасков. VM-щик здесь должен принимать во внимание кучу факторов о локациях и лампочках, чтобы ставить в приоритет к исполнению именно то, что требуется в первую очередь. Но как по мне, лучше этой ерундой не заниматься вовсе, если есть такая возможность.

Можно ли покрыть эти процессы одним человеком? Можно, но он будет постоянно переключать контекст, будет малоэффективно. Лучше чтобы это были разные люди, которые бы специализировались и целиком отвечали за свою часть работы. Т.е. от 2–3 человек, затем увеличивать при необходимости. 🙂

Positive Technologies открыли прием заявок на стажировку для студентов ИБ-шников третьего курса или старше

Pos­i­tive Tech­nolo­gies открыли прием заявок на стажировку для студентов ИБ-шников третьего курса или старше. Заявки принимаются до 27 февраля, а занятия начнутся 6 марта.

1 этап. Лабораторки, знакомство с продуктами компании. 1,5 месяца.
2 этап. Интенсивы по специализациям. 3 недели.
3 этап. Оплачиваемая стажировка в подразделениях компании для лучших студентов. До конца июня.

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

Что я об этом думаю.

Первое место работы/стажировки это очень важно. Зачастую это закладывает дальнейший вектор развития. Если бы я сразу после Бауманки не попал в Pos­i­tive Tech­nolo­gies в команду разработки базы знаний Max­Pa­trol 8, то и никакого "Управления Уязвимостями" в моей жизни не было бы. А так получилась прикольная рабочая история длиною 6,5 лет и хорошая база на будущее. Очень благодарен PT за это. 😇

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

Советую тем, кто будет принимать участие в стажировке в PT (да и в любом ИБ-вендоре), с самого начала присмотреться что в компании есть интересного лично для вас, чем вам хотелось бы заниматься, какие знания у вас уже есть для этого, какие знания вам нужно для этого получить. Если вы в этом сами для себя разберетесь и начнете это как-то артикулировать, то уже будете сильно выделяться на общем фоне тех, кто "может копать, может не копать".

У студентов часто есть такой взгляд "хочу в offen­sive, хочу в pen­test" или "хочу в SOC, хочу злодеев ловить". Да, темы модные и в PT это есть. И пентесты, и разнообразный ресерч, и SOC. Но ещё есть и очень крутые команды разработки: Vul­ner­a­bil­i­ty Man­age­ment (и куча направлений по поддерживаемым системам внутри), SIEM, SAST/DAST/IAST, WAF, NGFW, XDR и т.д. Если туда попадете, то будете в деталях понимать как эти штуки работают изнутри. Это уникальный востребованный опыт, который нигде как ИБ-вендоре не получишь.

Кроме того, нужно понимать что ситуация с ИБ продуктами в РФ стремительно меняется. Ещё лет 5 назад было достаточно справедливо сказать, что российские ИБ решения это для госов и около-госов, а все остальные используют зарубежные решения. Теперь идет массовый переход на продукты отечественных ИБ-вендоров (в том числе PT). И тут вы с опытом не только эксплуатации продукта, но и глубокими знаниями как продукт изнутри работает ("Использовал? Ха, да я его сам разрабатывал!"). Смекаете перспективы? 😉

В общем, если вы студент, подумайте над программой стажировки в PT. Если у вас есть знакомые студенты ИБ-шники, перешлите это им.