Forwarded from SecAtor
Лаборатория Касперского выпустила отчет по киберинцидентам за 2022 год. Что можем по этому поводу сказать?
Во-первых, HR ЛК необходимо срочно ввести в программу повышения квалификации сотрудников такой предмет как арифметика. Потому что при сложении 5 четных чисел у них получается число нечетное, ага.
Во-вторых. Почти в 43% инцидентов, отработанных Касперскими, первичным вектором атаки была эксплуатация уязвимостей в публично доступных приложениях. А из них - в 67% случаев использовались 10 наиболее популярных уязвимостей, из которых только 1 (sic!) обнаружена в 2022 году. Ну вы понели (с).
Таким образом, применив хитрую науку арифметику, можно сделать вывод, что как минимум в 30% киберинцидентов (а скорее всего больше) причиной проникновения стали не низкая зарплата CISO и не недостаточный штат SOC, а отсутствие внятной политики обновления используемого ПО либо ее невыполнение.
А в-третьих, компот. Потому что нам пишут, что мы делаем слишком длинные посты.
Во-первых, HR ЛК необходимо срочно ввести в программу повышения квалификации сотрудников такой предмет как арифметика. Потому что при сложении 5 четных чисел у них получается число нечетное, ага.
Во-вторых. Почти в 43% инцидентов, отработанных Касперскими, первичным вектором атаки была эксплуатация уязвимостей в публично доступных приложениях. А из них - в 67% случаев использовались 10 наиболее популярных уязвимостей, из которых только 1 (sic!) обнаружена в 2022 году. Ну вы понели (с).
Таким образом, применив хитрую науку арифметику, можно сделать вывод, что как минимум в 30% киберинцидентов (а скорее всего больше) причиной проникновения стали не низкая зарплата CISO и не недостаточный штат SOC, а отсутствие внятной политики обновления используемого ПО либо ее невыполнение.
А в-третьих, компот. Потому что нам пишут, что мы делаем слишком длинные посты.
securelist.ru
Отчет по реагированию на инциденты за 2022 год
Отчет сервиса «Лаборатории Касперского» по реагированию на инциденты информационной безопасности за 2022 год: статистика по реальным инцидентам, основные тренды и выводы, рекомендации экспертов.
👍2
Открытая прямая трансляция интенсивной конференции по ИБ phd12.
https://phdays.com/broadcast/
Сейчас там очень людно, так что это хорошая альтернатива очному визиту.
https://phdays.com/broadcast/
Сейчас там очень людно, так что это хорошая альтернатива очному визиту.
phdays.com
Positive Hack Days
An international cyberfestival for those who want to dive into the world of cybersecurity and have a great time
https://www.bleepingcomputer.com/news/security/cybercrime-gang-pre-infects-millions-of-android-devices-with-malware/ Самое время учесть в модели угроз для ваших корп устройств.
BleepingComputer
Cybercrime gang pre-infects millions of Android devices with malware
A cybercriminal tracked as the "Lemon Group" has been infecting millions of Android-based smartphones, watches, TVs, and TV boxes, with a malware strain named 'Guerilla.'
Forwarded from Пост Лукацкого
Немецкий BSI выпустил не очень большой, но все-таки интересный отчет с обзором различных проблем и атак на системы, базирующиеся на искусственном интеллекте. Как введение в проблему вполне себе подойдет.
https://www.breaches.cloud/ набор инцидентов для облака. пригодится для моделирования угроз и оценки рисков.
www.breaches.cloud
Public Cloud Security Breaches
Breaches.cloud - Your Source for Public Cloud Security Mistakes
Forwarded from Пост Лукацкого
OWASP разработал свою десятку рисков для языковых моделей OWASP LLM Top Ten v.1:
🚀 Prompt Injections
💧 Data Leakage
🏖 Inadequate Sandboxing
📜 Unauthorized Code Execution
🌐 SSRF Vulnerabilities
⚖️ Overreliance on LLM-generated Content
🧭 Inadequate AI Alignment
🚫 Insufficient Access Controls
⚠️ Improper Error Handling
💀 Training Data Poisoning
🚀 Prompt Injections
💧 Data Leakage
🏖 Inadequate Sandboxing
📜 Unauthorized Code Execution
🌐 SSRF Vulnerabilities
⚖️ Overreliance on LLM-generated Content
🧭 Inadequate AI Alignment
🚫 Insufficient Access Controls
⚠️ Improper Error Handling
💀 Training Data Poisoning
owasp.org
OWASP Top 10 for Large Language Model Applications | OWASP Foundation
Aims to educate developers, designers, architects, managers, and organizations about the potential security risks when deploying and managing Large Language Models (LLMs)
Forwarded from Резбез
Привет! В прошлую субботу (20 мая) в рамках фестиваля кибербезопасности Positive Hack Days 12 состоялась презентация платформы rezbez.ru для обмена знаниями и опытом экспертов в области ИБ разных организаций. В течении этой недели планируется закончить выкладывать на платформу первую партию контента с базовыми методиками результативной кибербезопасности.
Если у вас уже сейчас есть предложения по контенту, который вы хотели бы опубликовать на платформе открытой методологии результативной кибербезопасности, то можно связаться с командой организаторов оставив комментарии к этому посту.
Если у вас уже сейчас есть предложения по контенту, который вы хотели бы опубликовать на платформе открытой методологии результативной кибербезопасности, то можно связаться с командой организаторов оставив комментарии к этому посту.
Forwarded from Пост Лукацкого
ФСТЭК, спустя 2 месяца с публикации проекта своего методического «Руководства по организации процесса управления уязвимостями в органе (организации)» утвердил этот документ. Я пока глубоко не погружался в документ, но он мне понравился - явных косяков я в нем не увидел, кроме одного (о нем ниже). Во-первых, сразу бросается в глаза оформление - наконец-то в методичках стали появляться иллюстрации, блок-схемы, таблицы... Работать с таким документом гораздо приятнее и удобнее.
Во-вторых, предположу, что приказы 17/21/31/31/239 уже не будут сильно меняться (хотя я бы все-таки реализовал задумку с единым каталогом защитных мер и ссылками на него из разных приказов), и ФСТЭК займется процессами, стоящими за большинством из мер защиты. Работа эта небыстрая, но зато благодарная - становится понятно, что скрывается за отдельными пунктами приказов регулятора. А самое главное, что кибербез становится непрерывным, а не дискретным (от аттестации до аттестации).
В-третьих, документ устанавливает следующие сроки устранения выявленных уязвимостей:
🔥 критический уровень опасности - до 24 часов
⚡ высокий уровень опасности - до 7 дней
🖕 средний уровень опасности - до 4 недель
🪫 низкий уровень опасности - до 4 месяцев.
При этом важно помнить, что фразу "устранение уязвимостей" надо трактовать не буквально. Как мне кажется речь идет о невозможности использования выявленных уязвимостей, что может быть достигнуто как установкой обновлений (прямое прочтение термина "устранение уязвимостей"), так и реализацией компенсирующих мер, о чем методичка тоже говорит достаточно явно. Если вспомнить выступление В.С.Лютикова на PHDays, то он об этом также говорил (либо патч, либо компенсирующие меры).
Во-вторых, предположу, что приказы 17/21/31/31/239 уже не будут сильно меняться (хотя я бы все-таки реализовал задумку с единым каталогом защитных мер и ссылками на него из разных приказов), и ФСТЭК займется процессами, стоящими за большинством из мер защиты. Работа эта небыстрая, но зато благодарная - становится понятно, что скрывается за отдельными пунктами приказов регулятора. А самое главное, что кибербез становится непрерывным, а не дискретным (от аттестации до аттестации).
В-третьих, документ устанавливает следующие сроки устранения выявленных уязвимостей:
🪫 низкий уровень опасности - до 4 месяцев.
При этом важно помнить, что фразу "устранение уязвимостей" надо трактовать не буквально. Как мне кажется речь идет о невозможности использования выявленных уязвимостей, что может быть достигнуто как установкой обновлений (прямое прочтение термина "устранение уязвимостей"), так и реализацией компенсирующих мер, о чем методичка тоже говорит достаточно явно. Если вспомнить выступление В.С.Лютикова на PHDays, то он об этом также говорил (либо патч, либо компенсирующие меры).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from Пост Лукацкого
В любом случае помните, что документ является основой для разработки собственных документов по управлению уязвимостями. То есть он не догма, как его будут рассматривать многие, а руководство к действию. Но и сильно отходить от него не нужно.
Ложка дегтя - не учтена история с АСУ ТП, в которых не всегда работают те же подходы, что и при управлении уязвимостями в ИТ-инфраструктуре. А уж устранение критических уязвимостей в течение суток в средствах промышленной автоматизации... это вообще космос. Но опять же - взяв документ, разработанный ФСТЭК, за основу, можно что-то сделать и для своих АСУ ТП.
Ложка дегтя - не учтена история с АСУ ТП, в которых не всегда работают те же подходы, что и при управлении уязвимостями в ИТ-инфраструктуре. А уж устранение критических уязвимостей в течение суток в средствах промышленной автоматизации... это вообще космос. Но опять же - взяв документ, разработанный ФСТЭК, за основу, можно что-то сделать и для своих АСУ ТП.
Forwarded from Пост Лукацкого
Методический_документ_от_17_мая_2023_г_.pdf
2.3 MB
На сайте ФСТЭК выложена совершенно корявая версия методички по управлению уязвимостями в формате PDF - ее, видимо, не проверили после конвертации. Работать с ней нельзя - ни копировать из нее текст, ни делать поиск, ничего этакого. И картинки как-то не очень качественно сжаты. Я в итоге переделал его в то, с чем работать удобнее. Прилагаю.