В ИТ, да и в ИБ-индустриях, которые исторически были преимущественно мужскими, многие женщины сталкиваются с ограниченными возможностями для карьерного роста 👵 Согласно исследованию, проведенному компанией Acronis, основными проблемами для женщин являются нехватка наставничества, недостаточные условия для поддержания баланса между работой и личной жизнью, а также, в некоторых случаях, культура исключения 👱🏻‍♀️

Одним из ключевых выводов опроса стало то, что 71% женщин в IT работают сверхурочно 👵, чтобы увеличить свои шансы на карьерный рост. При этом 31% опрошенных женщин считают, что мужчины продвигаются по службе быстрее, несмотря на равное количество выполненной работы 🚶‍♂️ Это указывает на продолжающееся неравенство, хотя 32% женщин отметили, что считают, что мужчин и женщин на рабочем месте уже оценивают одинаково.

Кроме того, 63% женщин в области IT и кибербезопасности отметили недостаток женского лидерства 👠, а 84% опрошенных уверены, что наличие большего числа женщин на руководящих позициях принесло бы пользу технологическим компаниям 🙂

Вопросы карьерного роста также остаются актуальными. Лишь 34% женщин считают, что программы обучения и развития, доступные для женщин, способствуют их продвижению 👠 Большинство (63%) выделяют такие мероприятия, как мастер-классы и курсы обучения, как наиболее важные для их профессионального развития. Также популярными оказались сетевые мероприятия (58%) и участие в профессиональных организациях (44%). Женсовет по ИБ рулит 🍭

Среди инициатив, которые, по мнению опрошенных, компании могли бы реализовать для улучшения гендерного равенства, на первом месте стоят возможности наставничества (51%), привлечение более разнообразных кандидатов (49%) и равенство в оплате труда (49%) 🤨

Примечательно, что 20% женщин назвали отсутствие возможностей основной причиной, по которой женщины не идут в кибербезопасность. Также 25% отметили, что предпочитают сосредоточиться на создании семьи. Некоторые женщины избегают IT, полагая, что "не впишутся" в мужской коллектив (9%) или не хотят работать в индустрии, где доминируют мужчины (15%) 👠

Наконец, 60% женщин в IT регулярно фиксируют свои достижения для дальнейшего использования при продвижении по карьерной лестнице, что может стать ключом к преодолению существующих барьеров 🤬

Алонна Геклер, вице-президент Acronis, подчеркнула, что привлечение женщин в IT не только важно с точки зрения равенства, но и приносит стратегические преимущества ❤️ Женщины вносят новые идеи и креативные подходы, что улучшает работу команд и повышает конкурентоспособность компаний ↗️

Читать полностью…

Ну и снова про Bug Bounty, но со знаком минус 🐞 Как пишет SecurityLab, жительница Красноярска обнаружила ошибку на сайте Wildberries, позволяющую получать товары бесплатно 🛒 Девушка воспользовалась багом и оформила заказов на сумму 1,2 миллиона рублей. Любительницу легкой наживы быстро поймали и сейчас ей грозит до 10 лет лишения свободы за мошенничество в особо крупном размере 👮

А ведь если бы багхантерша легально зарегалась в программе Bug Bounty компании Wildberries, то она могла вполне получить 500 тысяч рублей за найденные уязвимости и накупить себе всякого разного 🛍 Да, это меньше 1,2 миллионов, но зато честно и без риска присесть на 10 лет. Так, глядишь, ей бы понравилось и она бы стала постоянной участницей и заработала бы свои миллионы абсолютно честным путем. Но увы... 😡

Читать полностью…

Как утечки данных влияют на стоимость акций на фондовом рынке 📈📉

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

Основные выводы:
➡️После раскрытия информации о нарушении акции, как правило, падают менее чем на 2%, достигая минимума на 41-й день, после чего начинается их рост.
➡️Цены акций восстанавливаются до уровня, предшествовавшего утечке, примерно через 53 дня после инцидента.
➡️Через шесть месяцев после раскрытия информации об утечке акции демонстрируют рост примерно на 5,9%
➡️Наибольшее снижение стоимости акций наблюдается в секторе здравоохранения, за которым следуют финансовые компании и производственные предприятия.
➡️Утечки конфиденциальных данных, таких как номера социального страхования, оказывают меньшее негативное влияние на стоимость акций по сравнению с утечками неконфиденциальной (или менее критичной) информации, например, адресов электронной почты.
➡️Утечки, затрагивающие большее количество записей, оказывают более значительное негативное влияние на стоимость акций, хотя разница не столь велика.
➡️Наибольшее влияние на стоимость акций оказали нарушения, произошедшие до 2015 года.

Следует отметить, что в методике анализа есть определенные ограничения и нюансы. Рекомендую предварительно с ними ознакомиться, а для большего погружения в данную тему ещё и потыкать в графики с различными фильтрами.

#breach #business #stock

Читать полностью…

Сегодня я весь день на "Форуме Будущего" в Екатеринбурге, где у меня будет визионерский доклад про ближайшее будущее кибербеза ☝️, продолжающий прошлогодний рассказ здесь же, а также, по приглашению друзей из компании УЦСБ, модерация трех дискуссионных панелей про технологический суверенитет, ИБ и искусственный интеллект, а также культуру ИБ. Приходите на ИБ-трек - тут точно скучно не будет 🆗

Читать полностью…

Очередная модель зрелости SOCов ↗️ На этот раз от Accenture. Вполне очевидные переходы с первого до второго уровня - от мониторинга периметра до использование централизованного сбора логов и событий и даже построения Data Lake 👩‍💻 Третий уровень вопросов не вызывал бы, если бы не четвертый - автоматизация и продвинутая аналитика. Где-то они меняются местами, так как проводить более глубокий анализ иногда проще, чем реализовать автоматизацию ⚙️

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

Читать полностью…

В начале сентября 2024 года Microsoft 📱 потеряла облачные логи безопасности за несколько недель, на которые клиенты компании обычно полагаются для обнаружения киберугроз 🔍 Microsoft уведомила пострадавших клиентов о том, что инцидент не связан с какой-либо угрозой безопасности (конечно, верим), но его последствия все же оказались ощутимыми 💥

Согласно публичному отчету Microsoft ⛈, причиной инцидента стал сбой в работе внутреннего агента мониторинга компании. Ошибка была вызвана, когда компания попыталась устранить другую ошибку в службе сбора логов (бабка за дедку, дедка за репку). Примерно с 23:00 UTC 2 сентября 2024 года агент мониторинга начал неправильно загружать данные журналов на внутреннюю платформу компании 💭 Это привело к частичному отсутствию указанных журналов для ряда сервисов Microsoft.

Несмотря на попытки компании исправить ситуацию, дважды перезапуская агент или сервер для восстановления сбора данных, часть логов была безвозвратно утеряна 🗑 К 5 сентября команда разработчиков Microsoft внедрила временное решение, которое помогло частично восстановить работу, но не позволило полностью восстановить все утраченные данные 👏

Проблема привела к возможной неполноте данных журналов в следующих сервисах:
1️⃣ Azure Logic Apps (платформенные логи)
2️⃣ Azure Healthcare APIs (платформенные логи)
3️⃣ Microsoft Sentinel (оповещения безопасности)
4️⃣ Azure Monitor (диагностические настройки)
5️⃣ Azure Trusted Signing (неполные логи SignTransaction и SignHistory)
6️⃣ Azure Virtual Desktop (логи в Application Insights)
7️⃣ Power Platform (различия данных в отчетах)
8️⃣ Microsoft Entra (логи входа и активности)

Дополнительно были затронуты логи, проходящие через Azure Monitor и интегрированные в такие продукты безопасности, как Microsoft Sentinel, Microsoft Purview и Microsoft Defender for Cloud. Это повлияло на способность клиентов анализировать данные, обнаруживать угрозы и генерировать оповещения о безопасности 🤦‍♂️

Читать полностью…

Русский нейминг, бессмысленный и беспощадный 🤦‍♂️

ЗЫ. Рекламой не считать 😊

Читать полностью…

Не скажу, что белорусский ОАЦ подгадывал выпуск своих рекомендаций по ИБ к минскому SOCcon, но я увидел этот документ в Интернете буквально на днях. Разбит на 5 частей:
1️⃣ Ответственные лица
2️⃣ Требования по ИБ для общедоступных ПДн и общедоступной информации, а также критически важных объектов (проектирование, создание, аттестация СЗИ и защита при выводе из эксплуатации)
3️⃣ Мониторинг ИБ и реагирование на инциденты
4️⃣ Взаимодействие с ОАЦ (по аналогии с российской ГосСОПКОЙ)
5️⃣ Функционирование национального CERT и локальных CSIRT от SOC

Читать полностью…

CISA добавила в список трендовых уязвимостей новую дыру CVE-2024-23113 в МСЭ Fortinet, которая позволяет выполнять удаленные команды и код без аутентификации. В России таких устройств было 444 еще несколько дней назад - сейчас "всего" 143 (в Беларуси - 38, в Казахстане - 226, в Узбекистане - 66, в Кыргызстане - 6, в Армении и Грузии - 35 и 53 соответственно). Всего же уязвимых устройств Fortinet в мире сейчас больше 86 тысяч. Думаю в Даркнете сейчас появится немало предложений по доступу в скомпрометированные через данную уязвимость компании и организации.

Цифры по России подтверждают исследование ЦСР, в котором говорится, что в России все еще используются решения иностранных вендоров, а продукция Fortinet входит в 10-ку самых распространенных.

Читать полностью…

Стажер в компании ByteDance 📱, Кейю Тянь, на протяжении двух месяцев саботировал проект по разработке нейросетей, умышленно внося ошибки в код 🧑‍💻, что привело к серьезным задержкам и срыву проекта. Его действия нанесли ущерб как команде разработчиков, так и репутации компании, а также вызвали бурную дискуссию на тему, поднятую еще Маяковским, "Что такое хорошо и что такое плохо" 🤔

Из интересного:
💀 Вредоносный код. Тянь загружал Pickle-файлы с скрытым вредоносным кодом, который содержал вирусы и выполнялся случайным образом. Это запутывало команду, так как ошибки возникали стихийно и не поддавались объяснению.
💀 Нарушение работы PyTorch. Тянь получил доступ к библиотеке PyTorch и регулярно вносил мелкие изменения в ее код, что приводило к сбоям в работе нейросетей. Разработчики не проверяли исходный код библиотеки, из-за чего задачи продолжали завершаться с ошибками, а эксперименты давали некорректные результаты.
💀 Манипуляции с чекпоинтами. Он изменял или удалял файлы чекпоинтов, которые сохраняют промежуточные состояния нейросетей во время обучения. В результате этого важные данные пропадали и не могли быть восстановлены.
💀 Участие в митингах. Тянь активно участвовал в командных встречах, где узнавал о планах команды по устранению багов, а затем создавал новые ошибки. Благодаря этому он оставался незамеченным на протяжении долгого времени.
💀 Обнаружение. В конечном итоге Тянь был разоблачен через анализ логов. Его действия привели к двум месяцам безрезультатной работы тридцати разработчиков, что сорвало сроки и привело к потерям для компании.
💀 Последствия. Хотя Тянь был уволен, его университетские наставники не предприняли против него дисциплинарных мер и не осудили его деструктивных действий.

Что можно сказать в качестве выводов и какие рекомендации можно было бы дать, если бы спросили меня (но меня не спросили):
1️⃣Внедрение строгого контроля кода. Инцидент подчеркивает важность регулярного аудита и проверки кода, особенно в крупных проектах с критической важностью для бизнеса. Недостаток контроля позволил одному человеку причинить значительный ущерб команде и проекту.
2️⃣Прозрачность и документирование изменений. Все изменения в ключевых библиотеках и компонентах проекта должны быть тщательно отслеживаемы и проверяемы, чтобы избежать подобных ситуаций.
3️⃣Повышение безопасности и доверия внутри команды. Участие стажера в саботаже подчеркивает необходимость тщательного подбора сотрудников и создания механизмов раннего выявления подозрительных действий.
4️⃣Обучение и ответственность. Работодатели и университеты должны уделять внимание воспитанию этики среди студентов и сотрудников, чтобы предотвратить деструктивные действия в будущем.

У нас на грядущей через 10 дней SOCcon в Минске будет как раз тема интеграции двух направлений - SOC и AppSec/DevSecOps. Ну а пока я задам сакраментальный вопрос - у вас же такой кейс предусмотрен в модели угроз? 🤔

Читать полностью…

Американские агентство по кибербезопасности и инфраструктуре (CISA) и Федеральное бюро расследований (ФБР) 🇺🇸 выпустили совместное руководство, посвященное опасным практикам в области продуктовой ИБ. Документ направлен на разработчиков программного обеспечения, чьи продукты функционируют в критической инфраструктуре, хотя его советы могут применяться ко всем разработчикам 🧑‍💻 Итак, горячая десятка плохих практик выглядит так:
🔤 Использование языков программирования, небезопасных для работы с памятью, например, таких как C или C++.
🔤 Использование пользовательских данных в SQL-запросах, что увеличивает риск SQL-инъекций.
🔤 Использование пользовательских данных в командах операционной системы, что также увеличивает риск инъекций.
🔤 Использование паролей по умолчанию.
🔤 Наличие известных уязвимостей.
🔤 Использование уязвимого открытого ПО.
🔤 Отсутствие многофакторной аутентификации, что увеличивает риск взлома.
🔤 Отсутствие возможности сбора доказательств и артефактов для анализа атак, например, журналов изменений конфигураций и сетевой активности.
🔤 Несвоевременная публикация CVE.
🔤🔤 Отсутствие политики раскрытия уязвимостей, позволяющей специалистам сообщать об уязвимостях и не бояться юридических последствий.

В самом документе также даны более детальные описания указанных практик, рекомендации по борьбе с ними и ссылки на дополнительные материалы 🗡

Читать полностью…

Получили на орехи

Утечка данных, как способ заработать на антикризисе компаний

Любопытный прецедент с антикризисом в формате data breach settlement, что по факту означает «и нашим, и вашим». Ореховая компания Green Valley, спустя 2 года после утечки данных выплатит своим клиентам по 400$, а тем, чьи утекшие данные были использованы в мошеннических схемах, еще плюс 4000$. Итого, 4400$ на нос, кажется вам повезло, если вы — жертва утечки, хохочет таблоид The Sun.

Производитель пекана из Аризоны расщедрился не просто так. После признания киберинцидента в 2022 году, Green Valley ответственно дропнула своим клиентам уведомления, что, мол, данные ваши могли утечь, меняйте пароли, приносим извинения, масштаб проблемы устанавливается. Казалось бы, все правильно сделала. Но ушлые американские граждане по-своему поняли, в чем польза орехов 🤣

Почуяв запах хрустящего доллара, они запилили коллективный иск Green Valley. Главная претензия полна драмы — вы могли предотвратить или уменьшить последствия утечки, приняв разумные меры кибербезопасности, но не сделали этого. Как жи так?

Спустя 2 года, производитель пекана так и не признал вины в утечке, но согласился заплатить неустойку истцам для урегулирования ситуации. Такая практика называется data breach settlement: компания платит клиентам компенсацию, те в ответ отказываются от судебных претензий, win-win. Главное, успеть до даты икс и прислать подтверждение, что ты жертва утечки и любви к орехам. И можно норм подзаработать на прибавку к социальному пособию и продолжать заниматься ничегонеделаньем. Сплошная польза!

#антикризис

Читать полностью…

Недавно произошел инцидент с участием ИБ-компании ESET, но последняя отвергла сообщения о том, что хакеры в рамках израиле-палестинского конфликта скомпрометировали 🥷 ее платформы и использовали их для распространения вредоносного ПО типа wiper, направленного на клиентов ESET в Израиле 🇮🇱 Однако компании все-таки пришлось признать, что их израильский партнер, компания Comsecure, действительно пострадала.

ESET на платформе X заявила:

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

Исследователь по безопасности Кевин Бомонт обратил внимание на инцидент, когда обнаружил, что пользователь на форуме ESET опубликовал скриншот письма, распространяемого якобы от имени ИБ-компании 💻 Письмо содержало тему:

"Правительственные атакующие могут пытаться скомпрометировать ваше устройство!",

и предлагало дополнительную защиту от якобы текущей атаки. Внутри письма находился архив .ZIP, который содержал вредоносное ПО 🦠, предположительно связанное с группировкой Handala, активно действующей в киберконфликте на Ближнем Востоке 🕌

Пока подтверждений, что ESET была взломана, нет. Поэтому можно исходить из версии самой компании - был взломан один из ее партнеров, что все равно не умаляет проблемы атак на цепочку поставок, которые являются №1 и в России 🔗 ИБ-компании тоже ломают - у нас в стране так уже больше десятка случаев за последние пару лет ☄️

Читать полностью…

«Не открывайте вложения с подозрительными расширениями»: основы ИБ для госслужащих от Минцифры

Министерство цифрового развития подготовило рекомендации по информационной безопасности для госслужащих. Советы для чиновников изложены в трёх памятках:
— Меры по обеспечению информационной безопасности;
— Рекомендации по защите учётных записей;
— Правила защиты от мошенников.

Рекомендации появились в Консультанте вчера и сопровождаются письмом врио директора Департамента обеспечения кибербезопасности Минцифры Евгения Хасина от 17 сентября. Министерство рассматривает эти памятки в русле программ по повышению цифровой грамотности — в данном случае среди чиновников.

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

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

Но, наверно, главный вопрос — будет ли польза от рекомендаций в таком формате? Что с ними в лучшем случае сделают в организации? Разошлют по почте? Распечатают и повесят листочки A4 на доске объявлений? Компании, проводящие тренинги по ИБ, много думают над тем, как сделать так, чтобы обучающиеся действительно усвоили материал, а их поведение стало более безопасным. В этом плане памятки не выглядят особо убедительными. Лучше сразу направлять госслужащих на тематический раздел на Госуслугах.

Читать полностью…

Помните видео про фотографию ребенка, которую с помощью ML превратили в живое и повзрослевшее лицо, которое стало говорить со своими родителями про риски цифровой приватности? Вот оно и на русском языке (даже в чуть более полном варианте, чем английский вариант, выложенный у меня) 👨‍👩‍👧‍👦

Читать полностью…

Обновление списка APT-групп, атакующих Россию

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

Сегодня делюсь обновлённой версией:
— добавлены отчёты российских компаний с апреля по октябрь и некоторые более давние, а также отдельные зарубежные отчёты (в том числе и два китайских). Общее количество отчётов удвоилось с 40 до 81, а количество групп в таблице увеличилось с 28 до 41;
— у некоторых групп добавлены дополнительные наименования;
— для групп без указания страны в соответствующем столбце поставлена чёрточка.

Как всегда, буду благодарен за обратную связь и дополнения.

Читать полностью…

Интересная новость - Рамблер&Co запустил программу bug bounty 🤑 для проверки своей защищенности. Можно было бы про это не писать, так как с момента, когда Яндекс запустил первую в России программу Bug Bounty более 10 лет назад, это уже становится нормой и компаний, вышедших на платформы поиска уязвимостей за вознаграждение уже немало (а в приватных программах так и того больше).

Но данный кейс интересен тем, что холдинг Rambler&Co 🖥 объявил вознаграждение не за поиск атомарных уязвимостей в своих приложениях и сервисах, и не за обычное проникновение в рамках пентеста 🤕, а за реализацию недопустимых событий, определенных компанией. За их реализацию компания платит в настоящий момент 3 миллиона рублей 💸

Интересно было бы увидеть результаты по этой программе; хотя она пока и в приватном режиме работает. Может быть к весеннему PHD 🏟 что-то появится и тогда можно будет даже собрать отдельную панельку (а мы уже программу начали формировать) - все-таки компаний, который вышли на Bug Bounty именно на недопустимые события уже не одна, не две, и даже не три. Есть о чем поговорить 💯

Читать полностью…

Интересное исследование, которое показывает влияние инцидентов с утечками данных на стоимость акций публичных компаний. В целом подтверждается давнее исследование Гордона-Лёба про +-2%. Но срок восстановления курса после инцидента существенно вырос - раньше он измерялся днями, а сейчас месяцами. Хорошо пойдет в копилку бизнес-ориентированной ИБ, когда надо показывать топ-менеджменту (если компания публичная, конечно, и работает на конкурентном рынке) реальное влияние ИБ на бизнес-показатели.

Читать полностью…

⚠️ Компанию Check Point оштрафовали за сокрытие факта своего взлома!

Интересное дело. Комиссия по ценным бумагам США (SEC) оштрафовала 4 компании - Unisys, Avaya, Mimecast и Check Point за обман сокрытие факта инцидента ИБ, который произошел у каждой из компаний в результате взлома SolarWinds в 2019-м году 🔓 Иными словами, их подломали в результате компрометации SolarWinds. Интересно, что сами компании подтвердили SEC факт взлома, но публично это отрицают 🤐 Тот же Check Point говорит, что они не нашли доказательств своего взлома, но не стали спорить с Комиссией по ценным бумагам и просто откупились от нее за 1 миллион долларов 💰

Unisys, Avaya, Mimecast и Check Point оштрафованы на 4 и 1 миллиона, а также 990 и 995 тысяч долларов соответственно 🤑 Unisys заплатила больше всех, потому что не только скрыла факт инцидента, но и сознательно принизила его размер 🤐 заявив о том, что "ничего не было". В реальности у нее украли гигабайты данных через внедренную в SolarWinds программную закладку. У Avaya украли корпоративную переписку и часть файлов из облачного хранилища, о чем она скромно умолчала 🤐 У Mimecast украли код и зашифровали часть учетных записей 😬 С Check Point меньше всего ясности - в объяснениях SEC они отделались общими словами и оспаривать штраф регулятора не хотят. Почему? Проще заплатить и идти работать дальше? Или лучше не идти в суд за правдой, чтобы не всплыли неприятные детали взлома? В общем, понятно, что ничего не понятно.

Кейс SolarWinds еще долго будет аукаться и самой компании и ее клиентам, а также клиентам ее клиентов... Ну а мы в очередной раз получаем подтверждение, что ломают всех, даже ИБ-компании, которые также, как и все, зависят от подрядчиков 💡 А как вы контролируете своих подрядчиков?

Читать полностью…

Ситуация с потерей логов Microsoft 📱 напомнила о необходимости усиленного внимания к журналам регистрации, особенно после прошлогоднего инцидента с взломом почтовых аккаунтов в США китайскими хакерами. Тогда Microsoft подверглась критике за то, что не предоставляла достаточного доступа к облачным логам для клиентов без премиум-аккаунтов Microsoft Purview Audit 🤑 Это могло бы позволить обнаружить взлом раньше. В ответ на критику Microsoft расширила доступ к логам для всех пользователей и увеличила период их хранения с 90 до 180 дней.

Но что делать, чтобы такая история не повторилась или как снизить ущерб в случае ее повтора? 🤔 Я бы начал со следующих шагов:
1️⃣ Создание резервных копий журналов регистрации. Клиенты должны рассмотреть возможность сохранения резервных копий логов в независимых хранилищах для избежания потерь при сбоях в облачных сервисах. Правда, это увеличит расходы на переход в облака, но тут придется выбирать.
2️⃣ Мониторинг логов в реальном времени. Использование решений для контроля состояния облачных сервисов в реальном времени поможет оперативно выявлять подобные сбои и предотвращать последствия или снижать их масштаб.
3️⃣ Увеличение времени хранения логов. Клиентам рекомендуется увеличивать периоды хранения логов для долгосрочного анализа и повышения безопасности. Правда, это не спасет от их потери, но по крайней мере позволит иметь длинную историю до и после.
4️⃣ Регулярные аудиты безопасности. Постоянный мониторинг настроек безопасности и доступности журналов позволит своевременно выявлять проблемы и избегать их в будущем.
5️⃣ Отказаться от сервисов Microsoft 🤔

Вообще, переход в облака, это не такая уж и простая история, как кажется на первый взгляд. Если добиваться схожего уровня сервиса и гарантий, как и в on-prem, то экономии может и не случиться (если ее рассматривать в качестве основного мотиватора перехода в облака) ⛈ В будущем организациям стоит уделять внимание правильной настройке сборщиков логов и использовать имеющиеся облачные и on-prem возможности мониторинга для максимальной защиты своих данных и инфраструктуры 👀

Читать полностью…

Если верить исследованиям, компьютерные игры 🎮 улучшают когнитивные способности человека, но почти не влияют на его психическое состояние. Физические упражнения, наоборот, улучшают психическое здоровье, но никак не влияют на когнитивные возможности 🥊 "Игры будущего", прошедшие в Казани, комбинировали оба вида соревнований, позволяя развивать обе стороны человеческого организма 🕹

А что если объединить CTF/киберполигоны с пейнтболом? Не сделает ли это специалистов SOC более внимательными и быстрыми на реакцию? 🤔 Готовы к такому на майском PHD3 в следующем году?

Читать полностью…

Тут подогнали презентации с SOCtech. Если вы там не были, то есть на что посмотреть. Я вот сижу, смотрю...

PS. Заодно и презентации с Positive Security Day подогнали; вдогонку к видео.

Читать полностью…

На GITEX было прикольное ИБшное место - Cyber Escape Room, где вас запускали в помещение, закрывали за вами дверь и давали 30 минут на то, чтобы выйти из закрытой комнаты 🚪 Квиз, но ИБшный, так как решать надо было чисто ИБшные задачки - найти PIN, взломать пароль и т.п. 🤒 Параллельно давались и ложные приманки - фишинговые ссылки и т.п. Но реализация оказалось не так чтобы серьезной - выход был найден за 12 минут. Но сама затея вполне себе прикольная. Думаю, на PHD попробовать такое реализовать 💡

Читать полностью…

Мне тут прислали письмо ✉️ с предложением подать заявку на соискание Премии Рунета (там есть категория по информационной безопасности) 🏆 Все бы ничего, но есть одна странность - чтобы подать заявку на премию, которая присуждается за вклад в развитие российского сегмента сети Интернет, надо заплатить деньги 🤑 Это примерно как "независимый" рейтинг корпоративных ИБ-каналов в Telegram, в который предлагают попасть за копейку малую 🤑 Мне кажется орги слово "вклад" не так трактуют 😂

Я уж как-нибудь обойдусь; тем более, что у меня уже есть Антипремия Рунета, полученная в 2011-м году и свежая "За заслуги в сфере Интернета". Замечу, бесплатно! А платить и не "выиграть" странно. Но если платить и выиграть, то будет ли это вклад в развитие Интернет или вклад в карман организаторов премии? 🤠 Хорошо, что я платную рекламу не размещаю в канале, а то я бы плодил премии каждый день - "За вклад в безопасный понедельник", "За вклад в доверительный вторник", "За вклад в обеспечение надежной среды", "За вклад в четверг без фишинга" и "За вклад в субботнее утро без похмелья" 🏆

Читать полностью…

Выложили тут новый open source инструмент под названием EDRSilencer 😴, который действует очень изящно, - он не пытается обойти или отключить средства защиты ПК, а просто обнаруживает процессы, отвечающие за работу EDR, и использует кастомные правила Windows Filtering Platform (WFP) для блокирования коммуникаций между агентом EDR и сервером управления 🤬 И все! Агент думает, что он отправляет сигналы тревоги, но сервер их не получает, а посему не способен среагировать должным образом и ИБ не знает, что узел скомпрометирован 👨‍💻

Бороться с этим можно путем мониторинга двух событий с ID 5155 и 5157, которые как раз показывают, что WFP блокирует приложения и соединения 📱 Дополнительно, нужно еще отслеживать имя приложения, чтобы отсечь реальную сработку фильтра от работы EDRSilencer. Как вариант, можно также использовать EDR, у которого логика работы реализована на самом агенте, а не на сервере управления. Таких решений не так много, но есть 🤔

На текущий момент EDRSilencer позволяет "отключить" такие решения как:
1️⃣ Microsoft Defender for Endpoint and Microsoft Defender Antivirus
2️⃣ Elastic EDR
3️⃣ Trellix EDR
4️⃣ Qualys EDR
5️⃣ SentinelOne
6️⃣ Cylance
7️⃣ Cybereason
8️⃣ Carbon Black EDR
9️⃣ Carbon Black Cloud
1️⃣0️⃣ Tanium
1️⃣1️⃣ Palo Alto Networks Traps/Cortex XDR
1️⃣2️⃣ FortiEDR
1️⃣3️⃣ Cisco Secure Endpoint (Formerly Cisco AMP)
1️⃣4️⃣ ESET Inspect
1️⃣5️⃣ Harfanglab EDR
1️⃣6️⃣ TrendMicro Apex One

У вас же предусмотрено это в модели угроз? Вы знаете, как проверить, что средства защиты работают и передают телеметрию в SIEM или на сервер управления? 🤔

Читать полностью…

Я тут в LinkedIn наткнулся на статью 📰, в которой обсуждаются различия между валовой прибылью и операционной маржой в публичных компаниях, занимающихся продуктами по кибербезопасности ⚖️ Интересное чтиво, в котором предлагается при оценке перспективности ИБ-компаний смотреть не на показатели валовой прибыли компании, которую обычно все выпячивают ↗️, а на операционную маржу, которая определяет эффективность ведения бизнеса и то, какую стратегию компания для себя выбрала - реально развивать продуктовое направление или продаться кому-то. Я немного пересказал текст, добавив и от себя пару мыслей.

Читать полностью…

Часто слышу, что

«мы не можем вывести в числе KPI на дашборды бизнес-показатели от деятельности ИБ, так как у нас нет исходных данных»

А вот кто-то может 💪 Это же просто данные 📈 Они где-то есть и к ним можно получить доступ. Топ-менеджмент же как-то их получает 🤔 Значит их можно и на SIEM вывести или к порталам ИБ-отчетности подтянуть.

Обычно «мы не можем» означает либо «мы не хотим», либо «мы не умеем», либо «нас в грош не ставят». Три разных причины, но с каждой можно работать и каждую можно решить!

Читать полностью…

Знаете, в России наблюдается 👀 явление под названием «гастарбайтеры», то есть пришлые из других стран люди, предлагающие различные commodity-услуги типа водитель такси 🚕, уборщица, дворник, продавец в магазине, младший медперсонал и т.п. Они недорого стоят и хотя качество их работы часто не очень высоко, их услугами пользуются многие, считая приемлемым баланс «качество-цена» ⚖️

И вот на GITEX 🇦🇪 я заметил схожую картину - на рынок ИТ и ИБ заходят агрессивные индусы, пакистанцы, китайцы и начинают демпинговать, предлагая сетевое оборудование, прикладное ПО, решения по кибербезу, аутсорсинг ИТ и т.п. То есть речь не просто об аутсорсинге разработки, а о предоставлении «ИТ-гастарбайтерами» более высокоуровневых решений 🧑‍💻 И дальше все будет как и в обычной жизни - сначала американские компании будут свысока посматривать на этих "выскочек", считая, что им ни за что не подвинуть лидеров с пьедестала 💪 Потом начнется жесткая конкуренция, а все, поздно 🆘 Стоимость разработки несопоставима у двух миров и доминировать может начать не США. А потом качество может и подтянется. И тогда, для защиты своих позиций США начнут применять явно нерыночные методы конкурентной борьбы, но это будет уже потом и не факт, что это даст свой эффект ⛔️ А пока очень интересно нам будет в ближайшее время.

ЗЫ. К слову, ни Китай, ни Индия не включены в список недружественных стран.😔

ЗЗЫ. К России это наблюдение тоже применимо.

Читать полностью…

А месячник кибербеза все еще идет...

Читать полностью…

На днях вебинар был, где была показана диаграмма 📊, на оси X которой представлены разработчики ПО по распространенности уязвимостей в их продуктах среди корпоративных активов. Пр оси Y отображается скорость устранения этих уязвимостей. Достаточно интересный срез, подтверждающий тезис, что безопасность определяется не числом уязвимостей, а скоростью реагирования на них и устранения 💡

Читать полностью…