Автор
KL FC Bot
в Новости и события из мира информационной безопасности
-
Похожий контент
-
Автор KL FC Bot
Даже компании со зрелой ИБ и достаточными инвестициями в это направление не застрахованы от киберинцидентов. Атакующие могут использовать уязвимости нулевого дня или скомпрометировать цепочку поставок, сотрудники могут стать жертвой сложной мошеннической схемы по проникновению в компанию, сама команда ИБ может допустить ошибку в настройках защитных инструментов или процедуре реагирования. Но каждый такой случай — повод улучшать процессы и системы, делать защиту еще эффективнее. И это не просто мотивационный афоризм, а практический подход, который вполне успешно работает в других сферах, например в авиационной безопасности.
В авиации требования по обмену информацией для предотвращения инцидентов предъявляются ко всем участникам — от производителей самолетов до стюардесс. И речь идет не обязательно об авариях или сбоях, в этой отрасли принято сообщать и о потенциальных проблемах. Сообщения постоянно анализируются и на их основе корректируются меры безопасности. Постоянное внедрение новых мер и технологий привело к снижению числа фатальных инцидентов с 40 на миллион вылетов в 1959 году до 0,1 — в 2015-м.
Но главное — в авиации давно поняли, что такая схема не будет работать, если ее участники боятся сообщать о нарушениях процедур, проблемах качества и других причинах инцидентов. Поэтому авиационные стандарты включают требования non-punitive reporting и just culture — то есть сообщения о проблемах и нарушениях не должны приводить к наказанию. Есть подобный принцип и у инженеров DevOps, они обычно называют это blameless culture и используют при разборе масштабных сбоев. Незаменим такой подход и в кибербезопасности.
У каждой ошибки есть фамилия?
Противоположностью blameless culture является принцип «у каждой ошибки есть фамилия», то есть конкретный виновник, который ее совершил. В рамках этой концепции за каждую ошибку применяют дисциплинарные взыскания вплоть до увольнения. Однако в реальности использование этого принципа вредно и не ведет к повышению защищенности.
Сотрудники боятся ответственности и искажают факты при расследовании случившихся инцидентов, а то и уничтожают информацию, пытаясь скрыть улики. Искаженная или частично уничтоженная информация об инциденте усложняет реагирование и ухудшает общий исход, потому что ИБ не может правильно и быстро оценить масштаб инцидента. При разборе инцидентов фокус на конкретном виновнике не позволяет сосредоточиться на том, как надо изменить систему, чтобы подобные инциденты не повторялись впредь. Сотрудники боятся сообщать о нарушениях политик и практик ИТ и ИБ, поэтому компания упускает шанс устранить дефекты защиты ДО ТОГО, как они стали причиной критического инцидента. Сотрудники не мотивированы обсуждать вопросы кибербезопасности, обучать друг друга, корректировать ошибки коллег. Чтобы все в компании могли внести вклад в ее защиту, надо действовать иначе.
View the full article
-
Автор KL FC Bot
Традиционная модель безопасности сети с защищенным периметром и зашифрованными каналами внешнего доступа внутрь периметра трещит по швам. Облачные сервисы и удаленная работа поставили саму концепцию «периметра» под сомнение, а основной способ доступа в периметр — через VPN — за последние годы стал излюбленным вектором атак злоумышленников. Многие «громкие» взломы начались с эксплуатации дефектов в VPN-решениях: CVE-2023-46805, CVE-2024-21887 и CVE-2024-21893 в Ivanti Connect Secure, CVE-2023-4966 в решениях Citrix. Скомпрометировав VPN-сервер, который обязан быть доступен через Интернет, злоумышленники получают привилегированный доступ к внутренней сети предприятия и широкие возможности по скрытному развитию атаки.
Серверные и корпоративные приложения часто настроены таким образом, что доверяют и доступны всем хостам в интрасети, поэтому в них проще находить и эксплуатировать новые уязвимости, извлекать, шифровать или уничтожать важные данные.
VPN-доступ часто предоставляют и подрядчикам организации. Если подрядчик нарушает требования ИБ, а доступ по VPN выдан стандартный, с широкими правами в сети организации, то компрометация подрядчика позволяет атакующим проникнуть в сеть компании и получить доступ к информации, пользуясь аккаунтами и правами подрядчика. При этом их деятельность может остаться незамеченной долгое время.
Радикальное решение этих проблем сетевой безопасности требует нового подхода к ее организации. В рамках этого подхода каждое сетевое соединение детально анализируется, проверяются реквизиты и права доступа у его участников, и доступ запрещается всем, кто явно не указан как имеющий право на работу с конкретным ресурсом. Этот подход применим как к сервисам во внутренней сети, так и к публичным и облачным сервисам. Недавно агентства по киберзащите США, Канады и Новой Зеландии выпустили совместную рекомендацию о том, как перейти на эту модель безопасности. Вот из каких инструментов и подходов она состоит.
Zero Trust
Модель Zero Trust создана для предотвращения несанкционированного доступа к данным и службам благодаря детальному, точному контролю доступа. Каждый запрос на доступ к ресурсу или микросервису отдельно анализируется, и решение принимается на основе ролевой модели доступа и принципа наименьших привилегий. Каждый пользователь, устройство, приложение должны регулярно проходить аутентификацию и авторизацию во время работы — разумеется, технические средства делают эти процессы незаметными для пользователя.
Подробнее о Zero Trust и его воплощении мы писали в отдельном материале.
View the full article
-
Автор KL FC Bot
В галерее вашего смартфона почти наверняка найдется важная информация, сфотографированная для надежности и удобства — например, фото документов, банковских договоров или сид-фраз, позволяющих восстановить доступ к криптокошелькам. Все эти данные могут быть украдены вредоносным приложением, подобным обнаруженному нами стилеру SparkCat. В текущей конфигурации этот зловред обучен красть данные криптокошельков, но с другими настройками он может мгновенно перейти к краже любой другой ценной информации.
Самое неприятное — этот зловред пробрался в официальные магазины приложений, и только из Google Play зараженные им аппы суммарно загрузили почти 250 тысяч раз. И если в Google Play вредоносные приложения не единожды обнаруживались и до этого, то в App Store троян-стилер обнаружен впервые. Как же устроена эта угроза и что сделать для защиты?
Довесок к легитимным приложениям
Приложения, содержащие вредоносные компоненты SparkCat, делятся на две группы. Некоторые из них — например, многочисленные схожие мессенджеры с заявленными функциями ИИ от одного и того же разработчика — очевидно, опубликованы сугубо как приманка. Но есть и другие — легитимные приложения сервисов доставки еды, чтения новостей, утилиты для владельцев криптокошельков. Как в них появилась троянская функциональность, мы не знаем. Возможно, это была атака на цепочку поставок, при которой был заражен один из вспомогательных компонентов — «кирпичиков», из которых собрано готовое приложение, или же разработчики намеренно встраивали трояна в свои приложения.
Первое приложение, в котором мы обнаружили SparkCat — это сервис для доставки еды в ОАЭ и Индонезии под названием ComeCome. Зараженное приложение было обнаружено как в Google Play, так и в App Store
View the full article
-
Автор LoWiX
Здравствуйте, недавно установил обход блокировки системы и после этого при незначительном простое ПК нагружается на сотку видеокарта, процессор. Прикрепляю логи ниже. Буду признателен если поможете.CollectionLog-2024.12.22-15.08.zip
-
Автор Ta2i4
Со вчерашнего дня регулярно - при открытии любой темы выдается ошибка "Извините, возникла проблема. Что-то пошло не так. Пожалуйста, попробуйте еще раз".
Проблему решает рефреш страницы (F5), но это нужно теперь делать всякий раз при открытии какой-либо темы, чтобы ознакомиться с ее содержимым.
UPD: После создания новой темы выскакивает такая же ошибка. Но тема при этом создается.
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти