-
Похожий контент
-
Автор KL FC Bot
Атаки на информационную инфраструктуру компаний (в первую очередь с использованием ransomware) и прочие киберинциденты все чаще можно найти на вершине хит-парада рисков для непрерывности бизнеса. Но главное, они прочно захватывают внимание советов директоров — менеджмент перестал задавать вопрос «могут ли нас атаковать» и перешел к обсуждению вопроса «что мы будем делать, если нас атакуют». В результате многие компании пытаются выработать киберустойчивость.
Всемирный экономический форум (WEF) определяет киберустойчивость как способность организации минимизировать влияние существенных киберинцидентов на ее основные бизнес-цели и задачи. Американский NIST уточняет: киберустойчивость — способность предвидеть, выдерживать, восстанавливаться и адаптироваться к неблагоприятным условиям, атакам или компрометациям ИТ-систем.
Все согласны, что киберустойчивость нужна современной компании, но практическая реализация стратегии киберустойчивости сталкивается с многочисленными трудностями. По результатам опроса 3100 руководителей ИТ и ИБ, проведенного компанией Cohesity, 98% компаний декларируют, что должны восстанавливаться после кибератаки в течение 24 часов, но реально восстановить работу в этот срок могут лишь 2%. А 80% бизнесов на восстановление потребуется от четырех дней до трех недель.
Семь основ киберустойчивости
В своем «компасе киберустойчивости» консультанты WEF выделяют следующие компоненты стратегии:
Leadership (лидерство): интеграция киберустойчивости в стратегические цели компании; отправка политических сигналов командам о важности киберустойчивости; принятие высокоуровневого решения о том, насколько компания терпима к основным киберрискам; наделение полномочиями тех, кто будет разрабатывать, а при плохом сценарии и воплощать сценарии быстрого реагирования. Governance, risk & compliance (управление, риски и соответствие): определение профиля рисков; назначение явных владельцев конкретных рисков и определение ответственности в случае их наступления; планирование и внедрение мер снижения и смягчения рисков; соблюдение регуляторных требований. People and culture (люди и культура): развитие киберкомпетенций; повышение осведомленности в сфере ИБ с учетом круга обязанностей каждого сотрудника; наем сотрудников с нужным набором ИБ-навыков; создание безопасной среды для всех сотрудников, в которой они смелее сообщают об инцидентах и ошибках. Business processes (бизнес-процессы): распределение ИТ-сервисов по уровням их важности для непрерывного ведения бизнеса; подготовка к наихудшим сценариям и внедрение адаптивности. Сюда входит детальная проработка того, как будут работать критически важные процессы при масштабных ИТ-сбоях. Technical systems (технические системы) — для каждой системы вырабатываются и регулярно пересматриваются меры по улучшению ее защиты. Такие, например, как использование максимально безопасных настроек (hardnening), подготовка запасных мощностей (redundancy), микросегментация сети, многофакторная аутентификация (MFA), создание защищенных от удаления резервных копий данных, внедрение управления журналами. Порядок внедрения защитных мер и выделяемые для этого ресурсы должны соответствовать важности системы.
Чтобы своевременно и эффективно реагировать на угрозы, следует обязательно внедрять системы, сочетающие детальный мониторинг инфраструктуры с полуавтоматическим реагированием: XDR, комбинация SIEM и SOAR и подобные. Crisis management (кризисное управление): формирование команд реагирования; совершенствование планов восстановления; определение, кто будет принимать решения в кризисной ситуации; подготовка запасных технических средств (например, каналов общения, если корпоративная почта и мессенджеры недоступны); разработка стратегий внешней коммуникации. Ecosystem engagement (взаимодействие в экосистеме): сотрудничество с партнерами по цепочке поставок, регулирующими органами и конкурентами для повышения общей устойчивости.
View the full article
-
Автор KL FC Bot
Сканирование жестких дисков рабочих компьютеров — простая ежедневная процедура, которая не мешает пользователю и не требует никаких ручных действий. Однако в случае с серверами ситуация осложняется, особенно если сканирование проводится при реагировании на инциденты и нужно внепланово проверить вообще все хранилища компании, а там — десятки терабайт данных. И при этом нужно обеспечить полную сохранность данных и не допустить заметного пользователям падения производительности. Чтобы не потерять время зря и не допустить дополнительных инцидентов, воспользуйтесь нашими советами и предосторожностями по списку. Советы, касающиеся непосредственно наших решений, мы даем на примерах Kaspersky Endpoint Security, но та же логика применима к другим защитным продуктам EPP/EDR.
Предварительные проверки
Проверьте конфигурацию компьютера, который будет проводить сканирование. Важно убедиться, что он имеет свежую и обновленную версию ОС, которая способна подключиться ко всем проверяемым дискам и корректно обработать данные: «понимает» длинные имена файлов с Unicode, может работать с файлами очень большого размера, файлами на разделах, чувствительных к регистру символов в именах, и так далее. Для ускорения проверки важно выбрать компьютер с мощным многоядерным процессором, значительным количеством памяти и быстрым локальным хранилищем для временных файлов.
Убедитесь, что доступ к дискам будет быстрым. Компьютер должен подключаться ко всем хранилищам либо напрямую (local storage), либо через быстрый сетевой интерфейс по производительному протоколу (в идеале — по разновидности SAN).
Проверьте резервные копии. Хотя сканирование не должно влиять на хранимые данные, в ситуации возможного заражения ВПО или повреждения файлов важно заранее продумать план «Б». Поэтому нужно тщательно проверить дату и состав свежей резервной копии всех данных, учесть, когда были учения по восстановлению данных, в общем, подтвердить полезность текущих версий бэкапа. Если актуальных резервных копий нет, нужно оценить риски, сроки и, возможно, создать резервную копию критических данных перед сканированием.
View the full article
-
Автор KL FC Bot
Хотя автоматизация и машинное обучения используются в ИБ почти 20 лет, эксперименты в этой области не останавливаются ни на минуту. Защитникам нужно бороться с более сложными киберугрозами и большим числом атак без существенного роста бюджета и численности ИБ-отделов. ИИ помогает значительно разгрузить команду аналитиков и ускорить многие фазы работы с инцидентом — от обнаружения до реагирования. Но ряд очевидных, казалось бы, сценариев применения машинного обучения оказываются недостаточно эффективными.
Автоматическое обнаружение киберугроз с помощью ИИ
Предельно упрощая эту большую тему, рассмотрим два основных и давно протестированных способа применения машинного обучения:
Поиск атак. Обучив ИИ на примерах фишинговых писем, вредоносных файлов и опасного поведения приложений, можно добиться приемлемого уровня обнаружения похожих угроз. Основной подводный камень — эта сфера слишком динамична, злоумышленники постоянно придумывают новые способы маскировки, поэтому модель нужно очень часто обучать заново, чтобы поддерживать ее эффективность. При этом нужен размеченный набор данных, то есть большой набор свежих примеров доказанного вредоносного поведения. Обученный таким образом алгоритм не эффективен против принципиально новых атак, которые он «не видел» раньше. Кроме того, есть определенные сложности при обнаружении атак, целиком опирающихся на легитимные ИТ-инструменты (LOTL). Несмотря на ограничения, этот способ применяется большинством производителей ИБ-решений, например, он весьма эффективен для анализа e-mail, поиска фишинга, обнаружения определенных классов вредоносного программного обеспечения. Однако ни полной автоматизации, ни 100%-ной надежности он не обещает. Поиск аномалий. Обучив ИИ на «нормальной» деятельности серверов и рабочих станций, можно выявлять отклонения от этой нормы, когда, например, бухгалтер внезапно начинает выполнять административные действия с почтовым сервером. Подводные камни — этот способ требует собирать и хранить очень много телеметрии, переобучать ИИ на регулярной основе, чтобы он поспевал за изменениями в ИТ-инфраструктуре. Но все равно ложных срабатываний будет немало, да и обнаружение атак не гарантировано. Поиск аномалий должен быть адаптирован к конкретной организации, поэтому применение такого инструмента требует от сотрудников высокой квалификации как в сфере кибербезопасности, так и в анализе данных и машинном обучении. И подобные «золотые» кадры должны сопровождать систему на ежедневной основе. Подводя промежуточный философский итог, можно сказать, что ИИ прекрасно подходит для решения рутинных задач, в которых предметная область и характеристики объектов редко и медленно меняются: написание связных текстов, распознавание пород собак и тому подобное. Когда за изучаемыми данными стоит активно сопротивляющийся этому изучению человеческий ум, статично настроенный ИИ постепенно становится менее эффективен. Аналитики дообучают и настраивают ИИ вместо того, чтобы писать правила детектирования киберугроз, — фронт работ меняется, но, вопреки распространенному заблуждению, экономии человеческих сил не происходит. При этом стремление повысить уровень ИИ-детектирования угроз (True Positive, TP) неизбежно приводит к увеличению и числа ложноположительных срабатываний (False Positive, FP), а это напрямую увеличивает нагрузку на людей. Если же попытаться свести FP почти к нулю, то понижается и TP, то есть растет риск пропустить кибератаку.
В результате ИИ занимает свое место в ансамбле инструментов детектирования, но не способен стать «серебряной пулей», то есть окончательно решить проблемы детектирования в ИБ или работать целиком автономно.
ИИ-напарник аналитика SOC
ИИ нельзя целиком доверить поиск киберугроз, но он может снизить нагрузку на человека, самостоятельно разбирая простые предупреждения SIEM и подсказывая аналитикам в остальных случаях:
Фильтрация ложных срабатываний. Обучившись на предупреждениях из SIEM-системы и вердиктах команды аналитиков, ИИ способен достаточно надежно фильтровать ложноположительные срабатывания (FP) — в практике сервиса Kaspersky MDR это снижает нагрузку на команду SOC примерно на 25%. Подробности реализации «автоаналитика» мы опишем в отдельном посте. Приоритизация предупреждений. Тот же механизм машинного обучения может не только фильтровать ложные срабатывания, но и оценивать вероятность того, что обнаружен признак серьезной вредоносной активности. Такие серьезные предупреждения передаются для приоритетного анализа экспертам. Альтернативно «вероятность угрозы» может быть просто визуальным индикатором, помогающим аналитику обрабатывать наиболее важные оповещения с наибольшим приоритетом. Поиск аномалий. ИИ может быстро предупреждать об аномалиях в защищаемой инфраструктуре, отслеживая такие явления, как всплеск количества предупреждений, резкое увеличение или уменьшение потока телеметрии с конкретных сенсоров или изменение ее структуры. Поиск подозрительного поведения. Хотя сложности поиска произвольных аномалий в сети значительны, некоторые частные сценарии хорошо автоматизируются и машинное обучение работает в них эффективней статичных правил. Примеры: поиск несанкционированного использования учетных записей из необычных подсетей, детектирование аномального обращения к файловым серверам и их сканирования, поиск атак с использованием чужих билетов TGS (атаки Pass-the-Ticket). Большие языковые модели в ИБ
Наиболее модная тема ИИ-индустрии, большие языковые модели (LLM), тоже многократно опробована ИБ-компаниями. Оставляя полностью за скобками такие темы, как написание фишинговых писем и ВПО при помощи GPT, отметим многочисленные интересные эксперименты по привлечению LLM к рутинным работам:
генерация расширенных описаний киберугроз; подготовка черновиков отчетов по расследованию инцидентов; нечеткий поиск в архивных данных и логах через чат; генерация тестов, тест-кейсов, кода для фаззинга; первичный анализ декомпилированного исходного кода при реверс-инжиниринге; снятие обфускации и объяснение длинных командных строк (такая технология уже используется нашим сервисом MDR); генерация подсказок и рекомендаций при написании детектирующих правил и скриптов. Большинство перечисленных по ссылке работ и статей являются нишевыми внедрениями или научными экспериментами, поэтому они не дают измеримой оценки эффективности. Более того, имеющиеся исследования эффективности квалифицированных работников, которым в помощь выданы LLM, показывают противоречивые результаты. Поэтому внедрение подобных решений должно проводиться медленно и поэтапно, с предварительной оценкой потенциала экономии, детальной оценкой вложенного времени и качества результата.
View the full article
-
Автор wadim1904
На компьютерах с kaspersky endpoint security 10 при открытии сайта Госуслуги нет значка ГОСТ (картинка приложена). Как я понял из-за того, что касперский использует свой корневой центр для проверки сертификатов.
Как отключить эту функцию?
-
Автор KL FC Bot
«Безопасность» и «переработки» — почти синонимы. По результатам недавнего опроса, каждый пятый CISO работает 65 часов в неделю, а не 38 или 40, как написано в контракте. В среднем переработки составляют 16 часов в неделю. То же касается рядовых сотрудников ИБ-команды — примерно половина жалуется на выгорание из-за постоянного стресса и переработок. При этом кадровый дефицит и ограничения бюджета сильно затрудняют самое очевидное решение проблемы — нанять больше людей. Но есть и другие пути! Мы изучили, какие задачи занимают большую часть времени у ИБ-команд и что можно сделать для снижения этих затрат.
Оповещения безопасности
Уверенный победитель в номинации «за потраченное время» — оповещения, генерируемые ИБ- и IT-системами компании. Поскольку число систем часто исчисляется десятками, то требующих обработки событий — тысячи. В среднем ИБ-специалисту приходится проверять 23 оповещения в час, и это включает совершенно нерабочее время. 38% опрошенных признались, что им приходилось реагировать на оповещения ночью.
Что делать
Используйте больше решений одного производителя. Централизованная консоль управления и интегрированная система оповещений снижают количество этих сигналов и ускоряют их обработку. Внедряйте автоматизацию. Например, решение XDR позволяет автоматизировать типовые сценарии анализа и реагирования, а также снижает число оповещений, соединяя разнородные события в один инцидент. Привлеките MSSP, сервис MDR или коммерческий SoC. Это самый эффективный способ гибко масштабировать работу с оповещениями. Штатные сотрудники смогут сосредоточиться на построении общей системы безопасности и расследовании сложных ситуаций.
Посмотреть статью полностью
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти