Во Владивостоке на неделе проходил Cisco Security Day, где я выступал с несколькими докладами. Один из них, рассматривающий несколько крупных инцидентов (Equifax, MAERSK, British Airways, DNSpionage, Olympic Destroyer и т.п.), я и выкладываю. В нем я попробовал подсветить ряд вопросов, связанных с тем, почему крупные организации, тратящие миллионы на свою защиту, не смогли обнаружить и среагировать на эти и схожие инциденты.
Показаны сообщения с ярлыком внутренние угрозы. Показать все сообщения
Показаны сообщения с ярлыком внутренние угрозы. Показать все сообщения
27.10.16
Kill chain для внутреннего нарушителя
Вчерашняя заметка, как справедливо отметили коллеги в комментариях, ориентирована на внешнего нарушителя и не очень хорошо подходит для описания нарушителя внутреннего. Это и так и не так одновременно. Все зависит от того, о каком нарушителе мы ведем речь. Если это обычный сотрудник, который решил поживиться ценной информацией перед своим увольнением, приведенная Lockheed Martin схема будет избыточной. А вот если мы говорим о специально внедренном на какой-либо критически важный объект "казачке", задача которого проникнуть в святая святых и используя внешние связи получить доступ к важной системе или информации с использованием специально подготовленного "кибероружия", то убийственная цепочка продолжает оставаться актуальной. Но таких ситуаций все-таки не так много и поэтому давайте попробуем составить Kill Chain для инсайдера.
С чего начинается процесс нанесения ущерба компании? Либо с найма инсайдера, либо с доведения его до точки кипения, когда он принимает решение нанести ущерб своему работодателю. Это может быть отказ от повышения, невыплата бонуса, плохое слово руководства, подкуп конкурентами и т.п. За этим спустя некоторое время (инсайдеру надо созреть) следует поиск информации, которая может быть интересна инсайдеру. Для этого используется либо специализированный инструментарий, либо, что чаще всего, злоумышленник и так знает, что может быть интересно на новом месте работы или конкурентам (списки клиентов, условия обслуживания, тарифы, ноу-хау, интеллектуальная собственность и т.п.)
После этапа разведки инсайдер, знающий где и что плохо лежит, пытается получить доступ к системе и захватить/собрать конфиденциальную информацию. Для этого инсайдер может воспользоваться либо своими правами доступа, либо специальным ПО, которое позволяет получить доступ в обход существующей системе разграничения доступа. Бывает и так, если вспомнить историю Сноудена и если в нее верить, что инсайдер, пользуясь хорошими отношениями с коллегами, использует их учетные записи для получения несанкционированного доступа.
Финальным аккордом является факт утечки собранной информации через облачные технологии, электронную почту, флешку или внешний жесткий диск (возможны и иные каналы утечки). Визуально это схему можно представить так:
На самом деле указанная схема описывает наиболее популярную историю с кражей именно информации, в то время как возможны и иные действия инсайдеров - кража ПО, внесение изменений в ПО, уничтожение ПО, изменение конфигурации оборудования и тому подобные действия. В этом случае мы просто меняем последних два этапа на нужный нам. Ну а дальше все тоже самое, что и для внешней Kill Chain - выработка методов обнаружения и нейтрализации нарушителей.
ЗЫ. Хочется отметить, что эти две разных убийственных цепочки очень хорошо показывают различия в действиях внешних и внутренних нарушителей и в необходимости разработки разных так называемых use cases при построении и эксплуатации SOC, о чем мы тоже будем говорить на ноябрьском SOC Forum.
С чего начинается процесс нанесения ущерба компании? Либо с найма инсайдера, либо с доведения его до точки кипения, когда он принимает решение нанести ущерб своему работодателю. Это может быть отказ от повышения, невыплата бонуса, плохое слово руководства, подкуп конкурентами и т.п. За этим спустя некоторое время (инсайдеру надо созреть) следует поиск информации, которая может быть интересна инсайдеру. Для этого используется либо специализированный инструментарий, либо, что чаще всего, злоумышленник и так знает, что может быть интересно на новом месте работы или конкурентам (списки клиентов, условия обслуживания, тарифы, ноу-хау, интеллектуальная собственность и т.п.)
После этапа разведки инсайдер, знающий где и что плохо лежит, пытается получить доступ к системе и захватить/собрать конфиденциальную информацию. Для этого инсайдер может воспользоваться либо своими правами доступа, либо специальным ПО, которое позволяет получить доступ в обход существующей системе разграничения доступа. Бывает и так, если вспомнить историю Сноудена и если в нее верить, что инсайдер, пользуясь хорошими отношениями с коллегами, использует их учетные записи для получения несанкционированного доступа.
Финальным аккордом является факт утечки собранной информации через облачные технологии, электронную почту, флешку или внешний жесткий диск (возможны и иные каналы утечки). Визуально это схему можно представить так:
ЗЫ. Хочется отметить, что эти две разных убийственных цепочки очень хорошо показывают различия в действиях внешних и внутренних нарушителей и в необходимости разработки разных так называемых use cases при построении и эксплуатации SOC, о чем мы тоже будем говорить на ноябрьском SOC Forum.
29.9.16
Борьба с внутренними угрозами. Обзор технологий. Презентация с "Кода ИБ"
Вторая презентация с "Кода ИБ" была посвящена обзору технологий борьбы с внутренними угрозами. Точнее даже не совсем технологиям, а тому, что может стать источником данных для обнаружения внутренних угроз и на работу с чем и нужны то есть или иные технологии. Специально не ограничивался банальными DLP, которые уже немного набили оскомину (хотя набор функций у Infowatch Traffic Monitor меня впечатлил). Технологии борьбы с внутренними угрозами не ограничиваются только DLP. Об этом и презентация.
2.8.16
Аппаратная закладка в корпоративную сеть, о которой молчал Сноуден
Тема недокументированных возможностей на системном или прикладном уровне программного обеспечения не дает покоя многим специалистам по информационной безопасности, которые либо закладывают эту проблему в свою модель угроз, либо активно пишут о якобы внедренных закладках в ПО или железо различных иностранных или отечественных производителей. Однако бывают и более простые способы вторжения в корпоративную сеть, даже в физически изолированную от внешнего мира.
Вот два кейса из практики Cisco Red Team, которые повторяются из раза в раз, в разных компаниях, в разных странах мира, включая и Россию. Первый достаточно банален - подбрасывание заранее "заряженных" флешек перед офисом компании-жертвы. Поставьте себя на место рядового сотрудника. Вы утром находите флешку на парковке перед офисом или на своем этаже в бизнес-центре. Ваша реакция? С очень высокой вероятностью, особенно если флешка выглядит новенькой, вы поднимете ее. И мысли у вас будут предсказуемые - от "может она большого объема" до "а вдруг там что-то интересненькое". А уж если на флешке написать "фото с корпоратива" или "фото Оли", то вероятность того, что вы эту флешку поднимите и воткнете в свой компьютер будет приближаться к 100%.
Как показывает наш опыт, не было еще ни одной компании, которая бы не попалась на эту, дешевую в реализации, но эффективную "удочку".
Мне можно возразить, что средства контроля периферийных носителей спасают от этой напасти. Кроме того, заражение компьютера и захват управления им еще не означают, что злоумышленник может выйти наружу и отправить украденную внутри информацию. Я не буду вступать в полемику, приводя примеры того, что и флешки контролируются далеко не всегда, и существует куча способов инкапсулировать украденную информацию в плохо контролируемый на периметре DNS-трафик. Я рассмотрю второй кейс, который также почти всегда дает эффект в рамках работы Cisco Red Team.
Речь идет об аппаратных закладках. Но не о тех, что внедряются на уровне операционной системе оборудования или в виде отдельных чипов, о которых писал Сноуден, но которых никто не видел. Речь идет о платформе Raspberry Pi, которая может быть использована для создания портативных компьютеров, которые могут быть подключены к корпоративной сети для негласного съема информации.
Масштаб этого устройства дает ему возможность долго оставаться незамеченным, если его подключить в какой-нибудь переговорке или в лобби офиса компании-жертвы. Отследить его, особенно если оно работает в пассивном режиме сниффера, достаточно сложно. В зависимости от реализации оно может как накапливать информацию без ее передачи наружу (достаточно повторно прийти в компанию и снять его), так и пытаться "слить" все через стандартные каналы или через встроенный беспроводной интерфейс. Ниже представлено видео того, как действовал сотрудник Cisco Red Team у одного из заказчиков (на английском языке, но там все понятно).
За кадром остался показ сотруднице на reception фальшивого письма о необходимости проведения регламентных работ, которое не вызвали никаких подозрений. Дальше к IP-телефону было подключено портативное устройство съема информации и дело оказалось в шляпе. Если IP-телефоны в компании внедряются без учета требований по ИБ, без соответствующей сегментации сети, без настроек шифрования, без контроля доступа, то злоумышленник может не только перехватывать голосовой трафик или "притвориться" телефоном и попробовать вывести из строя цифровую АТС, но и проникнуть внутрь других сегментов сети с последующим распространением по ней. Обнаружить такую "закладку" непросто; в отличие от ее создания и внедрения.
Выводы из этих двух кейсов будут очень простыми:
Вот два кейса из практики Cisco Red Team, которые повторяются из раза в раз, в разных компаниях, в разных странах мира, включая и Россию. Первый достаточно банален - подбрасывание заранее "заряженных" флешек перед офисом компании-жертвы. Поставьте себя на место рядового сотрудника. Вы утром находите флешку на парковке перед офисом или на своем этаже в бизнес-центре. Ваша реакция? С очень высокой вероятностью, особенно если флешка выглядит новенькой, вы поднимете ее. И мысли у вас будут предсказуемые - от "может она большого объема" до "а вдруг там что-то интересненькое". А уж если на флешке написать "фото с корпоратива" или "фото Оли", то вероятность того, что вы эту флешку поднимите и воткнете в свой компьютер будет приближаться к 100%.
Как показывает наш опыт, не было еще ни одной компании, которая бы не попалась на эту, дешевую в реализации, но эффективную "удочку".
Мне можно возразить, что средства контроля периферийных носителей спасают от этой напасти. Кроме того, заражение компьютера и захват управления им еще не означают, что злоумышленник может выйти наружу и отправить украденную внутри информацию. Я не буду вступать в полемику, приводя примеры того, что и флешки контролируются далеко не всегда, и существует куча способов инкапсулировать украденную информацию в плохо контролируемый на периметре DNS-трафик. Я рассмотрю второй кейс, который также почти всегда дает эффект в рамках работы Cisco Red Team.
Речь идет об аппаратных закладках. Но не о тех, что внедряются на уровне операционной системе оборудования или в виде отдельных чипов, о которых писал Сноуден, но которых никто не видел. Речь идет о платформе Raspberry Pi, которая может быть использована для создания портативных компьютеров, которые могут быть подключены к корпоративной сети для негласного съема информации.
Масштаб этого устройства дает ему возможность долго оставаться незамеченным, если его подключить в какой-нибудь переговорке или в лобби офиса компании-жертвы. Отследить его, особенно если оно работает в пассивном режиме сниффера, достаточно сложно. В зависимости от реализации оно может как накапливать информацию без ее передачи наружу (достаточно повторно прийти в компанию и снять его), так и пытаться "слить" все через стандартные каналы или через встроенный беспроводной интерфейс. Ниже представлено видео того, как действовал сотрудник Cisco Red Team у одного из заказчиков (на английском языке, но там все понятно).
За кадром остался показ сотруднице на reception фальшивого письма о необходимости проведения регламентных работ, которое не вызвали никаких подозрений. Дальше к IP-телефону было подключено портативное устройство съема информации и дело оказалось в шляпе. Если IP-телефоны в компании внедряются без учета требований по ИБ, без соответствующей сегментации сети, без настроек шифрования, без контроля доступа, то злоумышленник может не только перехватывать голосовой трафик или "притвориться" телефоном и попробовать вывести из строя цифровую АТС, но и проникнуть внутрь других сегментов сети с последующим распространением по ней. Обнаружить такую "закладку" непросто; в отличие от ее создания и внедрения.
Выводы из этих двух кейсов будут очень простыми:
- далеко не всегда проникновение в сеть осуществляется через периметр
- пользователи по-прежнему остаются самым слабым звеном
- пентест не позволяет отследить такие проблемы
- существуют гораздо более практичные способы "аппаратного" проникновения, чем мифические закладки от вендоров или от спецслужб.
А бороться с ними можно следующими методами:
- повышение осведомленности персонала
- сегментирование сети (в том числе и динамическое)
- анализ аномалий во внутренней сети
- контроль сетевого доступа
- физический осмотр мест, доступных для посещения.
5.4.16
Куалункуизмо в деле Mossac Fonseca
На сегодня у меня была запланирована немного другая заметка, но шумиха, поднявшаяся вокруг "утечки" из Mossac Fonseca заставила меня пересмотреть планы и жахнуть про этот инцидент, который вообще-то произошел год назад, а сейчас только стали известны его результаты. Итак, несколько фактов:
Это если вкратце пройтись по известным фактам. Теперь несколько размышлений об этом инциденте с точки зрения информационной безопасности. Во-первых, он мне сразу напомнил историю с утечкой данных четырехлетней давности из Ernst & Young, аудитор которой сливала данные Навальному, который боролся с коррупцией. Понятно, что делалось это в благих целях, но явно незаконными методами.
Во-вторых, если провести обычные математические расчеты, то получается, что 11,5 миллионов документов было проанализировано 400 журналистами за год. Получается по 28650 документов на журналиста в год или 80 документов в день, если работать без выходных. Даже если верить заметке на securitylab.ru, раскрывающей секреты моей работоспособности, то даже мне не под силу такой ритм работы :-) 80 документов в день при условии, что у журналистов была наверное и другая работа. А ведь еще нужно было все это оформить соответствующим образом. Офигительная работоспособность.
Кстати, насчет оформления. Зайдите на портал организации независимых журналистских расследований, ссылку на который я дал выше. Очень солидная работа проделана. Хорошие ролики сняты. Инфографика, онлайн-игра... Денег это явно требовало немало.
Пробежавшись по основным новостным агентствам, обращает внимание тот факт, что почему-то все на первые страницы помещают Путина и его ближайшее окружение (кстати, буквально за день-два до публикации панамских бумаг Путин подписал очередной план борьбы с коррупцией). Потом уже пишут про Кэмерона, исландского премьера, Порошенко, Джеки Чана, Месси, ФИФА и т.п. А вот, например, про Обаму ни слова. Североамериканских политиков вообще этот скандал не затронул, судя по прессе. Cui prodest?
А теперь на фоне всех странностей, которыми обросли панамские бумаги, стоит обратиться к нашей теме - к информационной безопасности. По версии самой Mossac Fonseca это был внешний взлом почтового сервера. Осталось только добавить, что это были русские хакеры и тогда все бы встало на свои места, полностью соответствуя общепринятому взгляду на хакерские проделки.
Однако если чуть подумать, то выглядит странно, что 11,5 миллионов документов за 40 лет работы компании хранились на одном почтовом сервере. Обычно почтовый сервер используется не для хранения документов в течении 40 лет. Взлом извне... Утечка 2,6 Тб данных... Врядли они хранили такие документы на Gmail. Как вы думаете, сколько времени надо, чтобы утянуть 2,6 Тб данных?.. И сколько времени надо, чтобы отследить такую активность на самой ранней стадии? Тут даже не ИБшники, а ИТшники должны были забить тревогу, так как такой всплеск сетевой активности был явно за гранью типичной картины.
Один из банковских юристов, специализирующихся на борьбе с отмыванием денег, в своем блоге написал, что по версии панамских инсайдеров, утечка была внутренней и произошла по вине экс-любовницы одного их партнеров фирмы Mossac Fonseca, также бывшей работницы этой компании. После разрыва отношений она в отместку выкрала все документы и передала немецкой прессе. Версия более правдоподобная, но местами вызывающая не меньшее количество вопросов, чем версия с внешним взломом.
Откуда у сотрудницы компании доступ ко всем документам работодателя за 40 лет? Она там архивариусом служила что-ли? И почему ее активность никто не отследил? Она жесткий диск с собой забрала, выдернув его из сервера? Или по сети столько накачала? Второй случай отслеживается элементарно путем анализа сетевого трафика. Первый случай тоже не является чем-то уж таким уникальным для его обнаружения.
Мне вообще кажется, что это все спланированная акция, цель которой спровоцировать шум в международной прессе, парламентские расследования, громкие политические отставки. И все для того, чтобы скрыть или не мешать неким иным событиям и действиям, которые могут произойти (или уже произошли) в самое ближайшее время.
ЗЫ. На вопрос, а что такое куалункуизмо, упомянутое в заголовке заметки отвечаю:
- Из панамской компании Mossac Fonseca, занимающейся оффшрными сделками, пропали документы за 40 лет работы компании.
- Документы попали в немецкую газету, которая распространила эти документы среди 100 с лишним медийных компаний.
- 400 журналистов в течение года занимались анализа 11,46 миллионов документов.
- Украденные документы составили в объеме свыше 2,6 терабайт данных.
- Все расследования об уходе от налогов (коррупции) в высших эшелонах власти разных государств, организаций, политиков, звезд спорта и шоу-бизнеса очень красиво оформленные выкладываются на специально созданном портале.
Это если вкратце пройтись по известным фактам. Теперь несколько размышлений об этом инциденте с точки зрения информационной безопасности. Во-первых, он мне сразу напомнил историю с утечкой данных четырехлетней давности из Ernst & Young, аудитор которой сливала данные Навальному, который боролся с коррупцией. Понятно, что делалось это в благих целях, но явно незаконными методами.
Во-вторых, если провести обычные математические расчеты, то получается, что 11,5 миллионов документов было проанализировано 400 журналистами за год. Получается по 28650 документов на журналиста в год или 80 документов в день, если работать без выходных. Даже если верить заметке на securitylab.ru, раскрывающей секреты моей работоспособности, то даже мне не под силу такой ритм работы :-) 80 документов в день при условии, что у журналистов была наверное и другая работа. А ведь еще нужно было все это оформить соответствующим образом. Офигительная работоспособность.
Кстати, насчет оформления. Зайдите на портал организации независимых журналистских расследований, ссылку на который я дал выше. Очень солидная работа проделана. Хорошие ролики сняты. Инфографика, онлайн-игра... Денег это явно требовало немало.
Пробежавшись по основным новостным агентствам, обращает внимание тот факт, что почему-то все на первые страницы помещают Путина и его ближайшее окружение (кстати, буквально за день-два до публикации панамских бумаг Путин подписал очередной план борьбы с коррупцией). Потом уже пишут про Кэмерона, исландского премьера, Порошенко, Джеки Чана, Месси, ФИФА и т.п. А вот, например, про Обаму ни слова. Североамериканских политиков вообще этот скандал не затронул, судя по прессе. Cui prodest?
За год каких-либо серьезных утечек по поводу данного расследования не было и только на прошлой неделе пресс-секретарь Путина заявил, что против России готовится очередной информационный вброс. Достаточно странно выглядит, что при таком вовлечении народа эта информация год держалась в тайне и никто ее не продал, не сдал. Такой секретности можно только позавидовать.
А теперь на фоне всех странностей, которыми обросли панамские бумаги, стоит обратиться к нашей теме - к информационной безопасности. По версии самой Mossac Fonseca это был внешний взлом почтового сервера. Осталось только добавить, что это были русские хакеры и тогда все бы встало на свои места, полностью соответствуя общепринятому взгляду на хакерские проделки.
Однако если чуть подумать, то выглядит странно, что 11,5 миллионов документов за 40 лет работы компании хранились на одном почтовом сервере. Обычно почтовый сервер используется не для хранения документов в течении 40 лет. Взлом извне... Утечка 2,6 Тб данных... Врядли они хранили такие документы на Gmail. Как вы думаете, сколько времени надо, чтобы утянуть 2,6 Тб данных?.. И сколько времени надо, чтобы отследить такую активность на самой ранней стадии? Тут даже не ИБшники, а ИТшники должны были забить тревогу, так как такой всплеск сетевой активности был явно за гранью типичной картины.
Один из банковских юристов, специализирующихся на борьбе с отмыванием денег, в своем блоге написал, что по версии панамских инсайдеров, утечка была внутренней и произошла по вине экс-любовницы одного их партнеров фирмы Mossac Fonseca, также бывшей работницы этой компании. После разрыва отношений она в отместку выкрала все документы и передала немецкой прессе. Версия более правдоподобная, но местами вызывающая не меньшее количество вопросов, чем версия с внешним взломом.
Откуда у сотрудницы компании доступ ко всем документам работодателя за 40 лет? Она там архивариусом служила что-ли? И почему ее активность никто не отследил? Она жесткий диск с собой забрала, выдернув его из сервера? Или по сети столько накачала? Второй случай отслеживается элементарно путем анализа сетевого трафика. Первый случай тоже не является чем-то уж таким уникальным для его обнаружения.
 |
| Cisco CTD отслеживает утечку данных по превышению порогового значения |
ЗЫ. На вопрос, а что такое куалункуизмо, упомянутое в заголовке заметки отвечаю:
1.11.13
Пара заметок по борьбе с APT и внутренними угрозами
На днях опубликовал вне этого блога пару заметок по борьбе с APT и внутренними угрозами:
Такая активность на тему APT связана с интересным кейсом, который у нас был в одном банке. С помощью системы мониторинга ИБ внутренней сети, установленной в пилотном режиме, уже по истечении первой недели нам удалось найти нескольких ботов, троянца Zeus, а также ряд других "приятных" сюрпризов. Вот про эту проблему я написал две заметки.
28.5.13
К черту контент, важен контекст!
После того, как в 21-м приказе ФСТЭК появилась мера по контролю утечек персональных данных (аналогичная мера по конфиденциальной информации будет и в 17-м приказе), а Банк России в Магнитогорске заявил о проработке вопроса о создании отдельного документа по DLP с банковской спецификой тема контроля утечек вновь стала более чем актуальной. Кто-то стал разрабатывать новые решения по части DLP, кто-то стал в очередной раз пиарить свой продукт. Вообще я уже не раз проходился по этой тематике, но хочу в очередной раз потроллить тему ;-) Да и на PHD III рассказывали как обойти современные DLP. Как будто это настолько распространенный продукт, что он стал стандартом де-факто в корпоративной среде.
Давайте сразу исключим из области рассмотрения задачу контроля голосового и видео трафика. Допустим, что у нас никакая конфиденциальная информация по этим каналам не передается. И ActiveSync нам контролировать не надо. И в базах данных у нас нет критичных данных. Будем тупо контролировать утечки в почте, в файлах, при печати. Т.е. то, что умеют делать большинство продуктов. Представим, что в контролируемом трафике мы встречаем нечто похожее на:
Так и в более сложных случаях. Допустим мы встречаем в тексте набор "ключевых" фраз - "месторождение", "объем запасов", "миллион кубометров". По всем параметрам это утечка информации. А оказывается, что кто-то просто переслал рекламную листовку с соответствующими текстовыми вкраплениями. А все потому, что мы контролировали контент, забывая про контекст.Давайте сразу исключим из области рассмотрения задачу контроля голосового и видео трафика. Допустим, что у нас никакая конфиденциальная информация по этим каналам не передается. И ActiveSync нам контролировать не надо. И в базах данных у нас нет критичных данных. Будем тупо контролировать утечки в почте, в файлах, при печати. Т.е. то, что умеют делать большинство продуктов. Представим, что в контролируемом трафике мы встречаем нечто похожее на:
Что это? Буква "В" русского алфавита? Буква "B" английского алфавита? Несчастливое число "13"? А вот фиг его знает. Мы не знаем. Да и DLP тоже не знает. Если не рассматривать анализ графических файлов и опять ограничить область распространения голым текстом, то максимум, что DLP может определить, что это символ какого-то алфавита или число..
Не могу сказать, что мысль нова. Но в последнее время становится все более понятно, что по другому (по старинке) выстраивать систему защиты уже неправильно. Она перестает выполнять стоящие перед ней задачи, а точнее выполняет их процентов на 20-30. Вот, например, что может сделать обычная система анализа сетевого трафика:
Ничего сверхестественного. Ну видим, что с определенных адресов уходит большой объем данных, на порядок превышающий установленные лимиты. Но в среде с динамической адресацией, это ничего и никому ни о чем не говорит. А если добавить контекст?
Картина уже иная. Мы смогли привязать информацию к пользователю и даже его устройству. С учетом же контекста мы можем не только что-то мониторить и отслеживать, но и писать политики, которые будут реализовываться. Например, вот так может выглядеть политика доступа к внутренним ресурсам организации:
Тут вам и беспроводной и проводной доступ, доступ с личных (BYOD) и корпоративных устройств, доступ со станционарных и мобильных устройств, доступ с устройств, за которыми пользователь аутентифицируется и за которыми он не работает (IP-телефон или игровая приставка), пользователи, которые прошли оценку соответствия и которых дополнительно аутентифицируют по сертификатам... Очень гибкая схема, отличающаяся от стандартной "пользователю ivanov111 можно получить доступ к IP-адресу 10.10.10.10".
Думаю, что за такими системами будущее.
20.10.09
Новая версия курса по модели угроз
В новую версию курса "Построение модели угроз" были добавлены следующие разделы/темы:
- 6-й метод определения вероятности угрозы
- психология восприятия риска при моделировании угроз экспертами
- как оформлять модель угроз по мнению ФСТЭК
- модель угроз Банка России.
14.9.09
Детальная программа курса "Построение модели угроз"
Я уже писал, что затеял курс "Построение модели угроз". Учитывая обязательное требование наличия модели в документах по персданным, вопрос ее построения не праздный. А оценив сколько стоит разработка такой модели - вопрос не праздный вдвойне. На выходных читал этот курс и теперь могу описать программу более детально, чем это было сделано в июле.
Основная цель - анализ существующих подходов к разработке модели угроз. Причем акцент делается на том, "как правильно", а не как надо "для галочки" (хотя и его тоже рассматриваю). Большое внимание уделяется различным стандартам, которые упоминают про разработку модели угроз.
Среди рассматриваемых стандартов по данной теме: ГОСТ Р 52448-2005, ГОСТ Р ИСО/МЭК 13335-3-2007, ГОСТ Р ИСО/МЭК 13335-4-2007, ГОСТ Р 51901.1-2002, MAGERIT, ГОСТ 51275-2006, ГОСТ Р 51344-99, ГОСТ Р ИСО/МЭК18045, ISO\IEC TR 13569, IT-Grundschutz Methodology, AS/NZS 4360:2004, EBIOS, MEHARI, OCTAVE, FRAP, NIST 800-30, MG-2, MG-3, SOMAP, IRAM, РС БР ИББС-2.2-2009 "Методика оценки рисков нарушения информационной безопасности", Cisco SAFE и т.п.
Ближайший курс пройдет в Москве 28-го сентября в Институте банковского дела АРБ (очно и онлайн).
Презентация курса: часть 1, часть 2, часть 3, часть 4 и часть 5.
Основная цель - анализ существующих подходов к разработке модели угроз. Причем акцент делается на том, "как правильно", а не как надо "для галочки" (хотя и его тоже рассматриваю). Большое внимание уделяется различным стандартам, которые упоминают про разработку модели угроз.
- Что такое угроза и риск?
- Классификация источников угроз
- Характеристики угроз и элементы риска
- Анализ рисков vs. анализ угроз
- Зачем нужно моделирование угроз
- Общий подход к моделированию угроз в современном мире
- Качественная и количественная оценка: сравнение подходов
- Можно ли доверять экспертам? Метод Дельфи
- Моделирование угроз на разных этапах жизненного цикла системы
- 4 стратегии анализа рисков
- Процесс моделирования угроз
- Идентификация угроз
- Анализ последствий (ущерба)
- Классификация последствий
- Анализ неопределенностей (чувствительности)
- Как проверить адекватность модели угроз?
- Классификация нарушителей
- Каталоги угроз
- 16 методов анализа рисков и определения опасностей. Как выбрать адекватный метод?
- Оценка рисков
- 5 методов оценки вероятности угроз
- Потенциал нападения
- Какая градация вероятностей угроз правильная? 9-тиуровневая, 6-тиуровневая, 3-хуровневая...
- Как оценить ущерб? Может ли ущерб измеряться не деньгами?
- Ценность материальных и нематерильных активов. Имеет ли информация стоимость?
- 12 методов оценки стоимости информации
- Зарубежные и отечественные методики моделирования угроз - ГОСТ Р ИСО/МЭК 13335-3-2007, ISO\IEC TR 13569, ГОСТ Р 51344-99, "дерево атак", модель угроз Microsoft (методы DREAD и STRIDE), модель угроз OWASP, модель Trike, модель N-Softgoal, модель Digital Security, методики ФСТЭК для персональных данных, коммерческой тайны и ключевых систем информационной инфраструктуры, методика ФСБ и т.п.
- Примеры моделей угроз
- Средства автоматизации моделирования угроз
- Как оформить модель угроз?
Среди рассматриваемых стандартов по данной теме: ГОСТ Р 52448-2005, ГОСТ Р ИСО/МЭК 13335-3-2007, ГОСТ Р ИСО/МЭК 13335-4-2007, ГОСТ Р 51901.1-2002, MAGERIT, ГОСТ 51275-2006, ГОСТ Р 51344-99, ГОСТ Р ИСО/МЭК18045, ISO\IEC TR 13569, IT-Grundschutz Methodology, AS/NZS 4360:2004, EBIOS, MEHARI, OCTAVE, FRAP, NIST 800-30, MG-2, MG-3, SOMAP, IRAM, РС БР ИББС-2.2-2009 "Методика оценки рисков нарушения информационной безопасности", Cisco SAFE и т.п.
Ближайший курс пройдет в Москве 28-го сентября в Институте банковского дела АРБ (очно и онлайн).
Презентация курса: часть 1, часть 2, часть 3, часть 4 и часть 5.
29.6.09
18.2.09
Лучшие практики по борьбе с внутренними угрозами
Часто координационный центр CERT воспринимается многими специалистами, как организация, которая анализирует инциденты ИБ и публикует статистику в этой области. Отчасти это так. Но гораздо полезнее материалы, которые публикует CERT по совершенно иным вопросам. В частности недавно CERT опубликовал уже третью редакцию (версия 3.1) своего отчета "Common Sense Guide to Prevention and Detection of Insider Threats".
88-тистраничный отчет отвечает на многие интересные вопросы:
Нельзя сказать, что CERT придумал что-то новое, но они аккумулировали все разрозненные рекомендации в рамках единого подхода и опубликовали его.
ЗЫ. А вообще CERT ведет обширные исследование по части внутренних угроз и публикует их результаты на своем сайте.
88-тистраничный отчет отвечает на многие интересные вопросы:
- что такое внутренняя угроза и кто такой инсайдер (в контексте ИБ)?
- насколько реальна внутренняя угроза?
- можно ли остановить инсайдеров?
- типы внутренних угроз (оказывается, утечки - не самая распространенная внутренняя проблема ;-)
- каковы лучшие практики по борьбе с инсайдерами и внутренними угрозами?
- Рассматривайте внутренние угрозы в контексте ИБ и управления рисками всей компании.
- Предусмотрите вопросы борьбы с внутренними угрозами в технических и организационных политиках ИБ.
- Проводите регулярно повышение осведомленности сотрудников.
- Мониторьте и реагируйте на подозрительное поведение, начиная с приема на работу.
- Предвосхищайте и управляйте негативными повседневными рабочими вопросами.
- Отслеживайте и защищайте оборудование.
- Внедряйте политики и практики управления паролями.
- Принцип разделения полномочий и минимума привилегий.
- Учитывайте внутренние угрозы при разработке ПО (SDLC).
- Обратите внимание на привилегированных пользователей.
- Контролируйте изменения в системе.
- Регистрируйте и мониторьте действия сотрудников.
- Эшелонированная оборона против удаленных атак.
- Деактивируйте учетную запись после увольнения сотрудника.
- Внедрите систему защищенного резервирования и восстановления данных.
- План реагирования на инциденты инсайдеров.
Нельзя сказать, что CERT придумал что-то новое, но они аккумулировали все разрозненные рекомендации в рамках единого подхода и опубликовали его.
ЗЫ. А вообще CERT ведет обширные исследование по части внутренних угроз и публикует их результаты на своем сайте.
Подписаться на:
Сообщения (Atom)
