Информационная безопасность IT

1 412 постов • 25 505 подписчиков

Руководство по парольной политике. Часть 3⁠⁠

6. Многофакторная аутентификация (МФА)

Этот раздел посвящен обсуждению того факта, что одного пароля недостаточно для надежной защиты учетных записей. А также обоснованию утверждения о необходимости внедрения многофакторной аутентификации.

6.1. Что такое МФА и почему она важна?

Авторизация только по паролю не является лучшим решением для обеспечения безопасности.

МФА, иногда называемая двухфакторной аутентификацией (2ФА), является улучшенной версией аутентификации по паролю, позволяющей пользователю предъявлять два или более доказательств (называемых факторами) при входе в систему. МФА доказала свою эффективность в борьбе с компрометацией учетных записей. Злоумышленнику в этом случае необходимо получить от пользователя не один фактор, а несколько, что создает много проблем, и, как правило, скомпрометировать такие учетные записи не удается.

Факторы могут относиться к одной из трех категорий:

✧ «То, что вы знаете» (фактор знания): пароль или персональный идентификационный номер (PIN).

✧ «То, что у вас есть» (фактор владения): смарт-карта, токен безопасности, приложение для аутентификации или текст SMS-сообщения на мобильный телефон пользователя.

✧ «То, кем вы являетесь» (фактор неотъемлемости): отпечаток пальца или рисунок сетчатки глаза.

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

МФА – самый надежный метод аутентификации пользователей из доступных на сегодняшний момент, и оказывающий минимальное влияние на удобство использования систем.

Примечание. «Двухэтапная» или «многоэтапная» аутентификация – это не то же самое, что 2ФА или МФА. «Двухэтапная» или «многоэтапная» аутентификация предполагает последовательное прохождение в целевой системе одного или нескольких дополнительных шагов аутентификации после успешного выполнения первого шага. Каждый из этих шагов может включать или не включать различные факторы аутентификации. По сути, каждый шаг является независимым рубежом, и успех на нем приближает пользователя к цели – доступу к системе. 2ФА или МФА –более надежный подход, предполагающий одновременное предоставление всех факторов для учетной записи, которые целевая система проверяет на валидность. Система принимает или не принимает учетные данные в целом, не указывая, какой фактор был признан неверным. Можно использовать 2ФА или МФА в качестве одного из этапов «двухэтапного» или «многоэтапного» процесса аутентификации.

6.2. Проблемы, связанные с МФА

Основная проблема – сложность внедрения.

МФА – отличный инструмент, который находит все большее применение в самых разных системах. Например, большинство банковских веб-приложений сегодня поддерживает 2ФА через приложение аутентификации или SMS-сообщение на мобильный телефон пользователя. Однако эта технология еще не так широко распространена и не так стандартизирована, как использование паролей.

Некоторые особенности МФА:

1. МФА часто включает пароль в качестве одного из факторов, поэтому хорошая парольная политика по-прежнему необходима.

2. В подавляющем большинстве случаев МФА не является компонентом самой информационной системы, а представляет из себя дополнение, реализованное сторонним разработчиком. Организациям рекомендуется ограничить количество применяемых решений по МФА, в идеальном варианте использовать только одно. Это облегчит поддержку такого программного обеспечения (обновление, отслеживание опубликованных уязвимостей и их исправление).

3. «То, что вы знаете» считается самым слабым фактором, а «То, кем вы являетесь» – самым сильным.

4. «То, что вы знаете» считается наиболее эффективным по затратам и простым в реализации, а «То, кем вы являетесь» — наиболее дорогим и сложным в реализации (нужен физический считыватель).

5. «То, что у вас есть» – наиболее распространенный фактор в 2ФА, используемый в сочетании с паролем. Самыми популярными формами этого фактора являются:

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

✧ Приложение для аутентификации на мобильном устройстве пользователя: с точки зрения пользователя этот метод очень похож на метод SMS, за исключением того, что уникальный код генерируется приложением на его мобильном устройстве. Число таких приложений растет, и не все они совместимы друг с другом (Google Authenticator, LastPass, Microsoft Authenticator, Authy, RSA SecureID).

✧ Токен физической безопасности: существует два распространенных типа токенов:

➣ уникальный идентификатор: с точки зрения пользователя это то же самое, что и использование приложения аутентификации за исключением того, что уникальный код генерируется и отображается на отдельном физическом устройстве (RSA SecureID Token, Fortinet FortiToken);

➣ физический предмет: эти устройства предназначены для установки или прикладывания к считывателю (через USB или NFC) и указывают на присутствие человека. Некоторые из них также включают авторизацию по уникальному идентификатору через соответствующее приложение (Yubico Yubikey, Google Titan).

Двухфакторные методы аутентификации более безопасны, чем одни пароли, но у каждого из них есть свои недостатки, которые следует учитывать:

1. Фактор «То, что вы знаете» – это, по сути, пароли, и они должны соответствовать рекомендациям парольной политики, приведенным в Разделе 5.

2. Из факторов «То, что у вас есть», приложения для аутентификации и физические маркеры считаются очень надежными, а вот с SMS-сообщениями есть проблемы:

✧ SMS-тексты проходят по телефонной сети общего пользования (ТСОП), которая находится вне контроля пользователя или администраторов сети;

✧ ТСОП фактически представляют собой совокупность объединенных в сеть компьютеров, посылающих друг другу голосовые вызовы и SMS-сообщения по протоколу, известному как Signaling System 7 (SS7). Этот протокол имеет известные уязвимости, позволяющие перенаправлять текстовые SMS-сообщения на телефон злоумышленника;

✧ С помощью методов социальной инженерии злоумышленники могут без особого труда убедить службы поддержки поставщика услуг мобильной связи в том, что телефон пользователя был утерян или поврежден, и его номер необходимо присвоить его новому телефону (принадлежащему злоумышленнику).

Примечание. В связи с этими проблемами мы рассматривали возможность исключения из рекомендаций использование SMS в качестве второго фактора. Но из-за его повсеместной распространенности и того, что он, возможно, лучше, чем ничего, убирать его не стали. Мы настоятельно рекомендуем всем, кто использует SMS для 2ФА, разработать план по отказу от этого метода как можно скорее.

3. Факторы «То, чем вы являетесь» многие считают самыми безопасными, поскольку они основаны на физических характеристиках пользователя, которые невозможно изменить (отпечаток пальца, рисунок сетчатки глаза и т.д.). Такой подход кажется идеальным, но существует довольно много проблем с использованием этих факторов в качестве основного средства аутентификации. Они должны использоваться в паре с секретным небиометрическим атрибутом (например, паролем).

В качестве примера возьмем отпечаток пальца:

✧ отпечаток пальца пользователя, как и все биометрические данные, не является секретным, как пароль или закрытый ключ шифрования, и может быть снят любым человеком, следящим за пользователем. Самая большая проблема с несекретными факторами аутентификации заключается в том, что их легко скопировать для злонамеренного повторного использования. Например, в июне 2015 года китайская APT-группа украла более 5,6 миллионов записей отпечатков пальцев граждан США, содержащихся в базе соискателей на получение допуска к секретности;

✧ при сканировании отпечатка пальца пользователя он должен быть сопоставлен с сохраненным отпечатком пальца. Сохраненные данные отпечатков пальцев представляют из себя отображение реального отпечатка пальца и не являются действительно уникальными. Отпечаток пальца пользователя превращается в серию особых точек, где отмечаются концы папиллярных линий и их ветвления. Изображение, которое хранится в базе данных, и соответствие которому оценивается при аутентификации, на самом деле больше похоже на рисунок небесного созвездия, чем на реальный отпечаток пальца;

✧ отпечаток пальца – не пароль, который можно легко поменять, и не уникальный идентификатор, который действителен в течение 5 минут. Если отпечаток пальца был скомпрометирован, то это навсегда.

В данном разделе описаны плюсы и минусы от реализации различных форм МФА. В конечном итоге, решение о внедрении МФА во многом зависит от уровня требуемой безопасности, бюджета, а также политик и процедур, установленных лицами, принимающими решения.

7. Выводы

Общая цель данного руководства – свести большую часть современных рекомендаций по паролям в единый краткий документ и изложить реальные причины, по которым эти рекомендации были сделаны.

Безусловно, на сегодняшний день не в каждой системе имеется возможность реализации всех этих рекомендаций (по разным причинам), но со временем их будут поддерживать большинство систем, если не все. Ни одна из приведенных здесь рекомендаций не является технически сложной для выполнения, и каждая из них имеет свои примеры реализации.

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

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

8. Приложение: что делает пароль хорошим?

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

Пароли всегда будут несовершенным средством защиты, но при правильном использовании они играют важную роль в обеспечении безопасности информационных систем. Руководство по парольной политике в сочетании с обучением пользователей может сделать пароли надежным и безопасным инструментом. Чтобы облегчить обучение, рассмотрим ключевые моменты в создании надежных паролей.

8.1. Как создать хороший пароль

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

1. Длина – самая важная характеристика хорошего пароля: в общем случае, чем длиннее пароль, тем лучше.

2. Используйте парольную фразу, а не пароль: используя одно «слово», трудно придумать что-то длинное и запоминающееся, но, если использовать «фразу», состоящую из 4 или более слов, сделать это будет гораздо проще.

Слова из 14 и более символов: Антидепрессант, Фундаментализм, Привлекательность и т.д. Такие пароли сложно запоминать, не говоря уже об их правильном написании.

Фразы из 14 и более символов (с пробелами и без пробелов для удобочитаемости):

✧ с пробелами — Мой Дядя Живет в Грузии, без пробелов — МойДядяЖиветвГрузии;

✧ с пробелами -Лучшая Машина Ваз Жигули, без -ЛучшаяМашинаВазЖигули;

✧ с пробелами -Дальний Восток Моя Родина, без -ДальнийВостокМояРодина.

3. Избегайте шаблонов: не используйте последовательности цифр-букв или клавиатурные шаблоны типа 12345671234567, abcdefgabcdefg, passwordpassword, abc123abc123ab, qwertyuqwertyu и т.д.

4. Не используйте пароль повторно и не используйте похожие пароли в нескольких системах: особенно в домашней и рабочей учетных записях. Основная причина запрета в том, что, если кто-то узнает один из ваших паролей, то он получит доступ к нескольким вашим учетным записям.Это, пожалуй, самая сложная из четырех основных идей, но вы можете использовать приемы, например, название группы/песни/фильма/актера для создания релевантной и запоминающейся фразы:

✧ финансовый аккаунт: с пробелами — АББА Мани Мани Мани, без — АББАМаниМаниМани;

✧ аккаунт в магазине: с пробелами — Гарцующий Пони Фродо Бэггинс, без — ГарцующийПониФродоБэггинс;

✧ медицинский аккаунт: с пробелами — Доктор Хаус Хью Лори, без — ДокторХаусХьюЛори.

8.2. Более продвинутые приемы

Теперь вы хотите выйти за рамки основ и создать действительно впечатляющие пароли!

1. Избегайте слов, связанных с вашей личной информацией или общими интересами: избегайте фактов, которые люди могут найти о вас в Интернете. Если вы являетесь президентом местного автомобильного клуба любителей Жигулей, вам, вероятно, не следует использовать слово «Жигули» в качестве пароля.

С учетом сказанного, можно ли использовать предыдущий пример ЛучшаяМашинаВазЖигули? Конечно, есть варианты и получше, но слово «Жигули» составляет только 6 из 21 символов парольной фразы (15 символов еще неизвестны), так что это все равно неплохо!

2. Ограничьте использование словарных слов: как правило, злоумышленники подбирают пароли, пробуя сначала различные словарные комбинации. Это много слов, но вариантов все равно гораздо меньше, чем если пробовать все возможные комбинации букв.Например, возьмем пароль из 3 латинских символов. Если использовать только строчные буквы, то существует 263 = 17 576 комбинаций букв (включая такие, как zxy, rhb, qqt и т.д.), но допустимых трехбуквенных слов гораздо меньше (1 355 по одному онлайн-словарю). Это меньше, чем одна десятая часть.

Ситуация становится намного хуже по мере добавления символов:

✧ все комбинации из 8 символов: 208,827,064,576;

✧ все комбинации из 12 символов: 95,428,956,661,682,176;

✧ все комбинации из 16 символов: 43,608,742,899,428,874,059,776.К сожалению, настоящих слов из них не так много: существует всего 88,342 английских слова длиной от 3 до 15 символов. Теперь понятно, что перебор словарных слов закончится намного быстрее, чем перебор всех возможных комбинаций букв для пароля заданной длины.

Использование нескольких словарных слов в парольной фразе также усложнит работу противника, но, если вы действительно хотите доставить ему неприятности, добавьте что-нибудь, чего нет в словаре. Например:

✧ вместо ЛучшаяМашинаВазЖигули, попробуйте ЛучшаяМашинаВазЖигули№1!

✧ вместо ДальнийВостокМояРодина попробуйте Дальний;Восток;Моя;Родина.

✧ вместо МойДядяЖиветвГрузии, попробуйте МойДядяЖивет-вГрузии!

Можно также заменить некоторые буквы на числовые и символьные представления. Например:

✧ ЛучшаяМашинаВазЖигули№1! – Лу4ш@яМ@шин@8@3Жигули№1!

✧ Дальний;Восток;Моя;Родина – Д@льний;80(т0к;М0я;Родина@

✧ МойДядяЖивет-вГрузии! – М0йДядяЖи83т-8Гру3ии!

Выполнение каждого из этих действий сделает ваш пароль чуть более надежным и устойчивым к взлому злоумышленником, но отдача от этого будет снижаться. Почему? Потому что злоумышленники знают про эти трюки и учитывают это при взломе паролей.

Если вы хотите получить действительно хороший пароль, вам нужен длинный пароль, сгенерированный случайным образом и сохраненный в менеджере паролей, потому что вы, скорее всего, не запомните результат, который будет выглядеть примерно так:

✧ GHj*65%789JnF4$#$68IJHr54^78

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

Перевод: Аделина Любимова, Origin Security

Ссылка на первоисточник

Показать полностью 1

[моё] IT Полезное Пароль Руководство Хакеры Информационная безопасность Длиннопост

originsecurity

1 год назад

Информационная безопасность IT

Руководство по парольной политике. Часть 2⁠⁠

Продолжение. С первой частью можно ознакомиться здесь.

5. Рекомендации

В этом разделе каждая из предыдущих рекомендаций будет рассмотрена более подробно.

5.1. Ключевые рекомендации

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

5.1.1. Длина пароля или парольной фразы

Разрешите использование длинных парольных фраз, но не применяйте их принудительно.

В соответствии с общей целью заставить пользователей создавать не слишком слабые пароли, рекомендуемая минимальная длина пароля составляет 8 символов для учетной записи с МФА, и 14 символов — для учетной записи, использующей только пароль. При выборе максимальной длины пароля стоит отталкиваться от наибольшего значения, позволяемого возможностями системы/программного обеспечения, а не ограничиваться политикой.

В целом верно, что длинные пароли лучше коротких (их труднее взломать). Но также верно и то, что категоричные требования к длине используемых паролей предсказуемо вызывают нежелательное поведение пользователей. Например, требование иметь минимум 16-символьный пароль может заставить их выбирать повторяющиеся шаблоны типа «PasswordPassword» или «1234123412341234», которые соответствуют правилу, но легко угадываются злоумышленниками. К тому же, предписание иметь длинные пароли увеличивает вероятность того, что пользователи будут применять и другие небезопасные методы для упрощения работы с ними. Например, записывать их, использовать повторно или хранить в незашифрованном виде в своих документах.

Установление разумной минимальной длины без ограничения максимального количества символов увеличивает среднюю длину используемого пароля (и, следовательно, его надежность).

5.1.1.1. Парольные фразы

Обучите пользователей применению парольных фраз. Это приведет к созданию более длинных и надежных паролей.

В парольной фразе используется ряд слов, которые могут включать или не включать пробелы: correcthorsebatterystaple – пример парольной фразы из известного комикса XKCD на эту тему. Несмотря на то, что парольные фразы часто содержат больше символов, чем пароли, они всегда содержат меньше «компонентов» (четыре слова вместо, скажем, 12 случайных символов).

В конечном счете, все дело — в соотношении длины и легкости запоминания. Именно поэтому обучение пользователей таким приемам, как применение парольных фраз, позволяющих создавать более длинные и легко запоминающиеся пароли — весьма эффективная практика.

Примечание. Для получения более подробной информации об использовании парольных фраз, см. Приложение: что делает пароль хорошим?

Итоговая рекомендация:

5.1.2. Состав/сложность пароля

Разрешите использование символов любого типа, но не принуждайте использовать символы определенных типов.

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

✧ заглавные символы;

✧ строчные символы;

✧ неалфавитные символы, такие как цифры или специальные символы, например <*&(^%$>!):.

В настоящее время не существует стандарта для состава пароля, поэтому очень часто эти требования варьируются от системы к системе (например, одна система разрешает специальные символы, а другая – нет).

Требования к составу пароля являются слабой защитой от атаки Password Guessing. Принуждение пользователей к выбору некоторой комбинации символов верхнего и нижнего регистра, цифр и специальных символов нередко влечет негативные последствия. Это создает дополнительную нагрузку на пользователей, и многие из них будут обращаться к предсказуемым шаблонам (например, заглавная буква в первой позиции, затем строчные буквы, затем одна или две цифры и «специальный символ» в конце). Злоумышленники знают об этом, и в ходе словарных атак часто используют эти популярные шаблоны, а также наиболее распространенные замены, например, $ на s, @ на a, 1 на l, 0 на o.

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

Итоговая рекомендация:

5.1.3. Срок действия пароля

Меняйте пароли в зависимости от событий, с ежегодной «подстраховкой».

Чрезмерные требования к сроку действия паролей приносят больше вреда, чем пользы, поскольку заставляют пользователей выбирать предсказуемые пароли, состоящие из последовательных слов и цифр, тесно связанных друг с другом. В таких случаях следующий пароль можно предсказать на основе предыдущего (например, увеличивая используемое в пароле число).

Требование обязательной смены пароля по истечении определенного срока действия не дает никаких преимуществ в плане сопротивления злоумышленникам, поскольку те часто используют учетные данные сразу после их получения. Вместо расписания, немедленная смена пароля должна основываться на ключевых событиях, таких, как (перечень не является исчерпывающим):

✧ появление признаков компрометации;

✧ смена ролей пользователя;

✧ увольнение пользователя.

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

Дополнительно мы рекомендуем проводить ежегодную смену паролей. Это связано в первую очередь с тем, что, при всех своих благих намерениях, пользователи будут использовать одни и те же учетные данные в разных системах. Впоследствии, даже если утечка данных из какой-либо системы получит публичную огласку, человек может просто не увидеть сообщение об этом факте, или вообще забыть, что у него был аккаунт, например, на скомпрометированном сайте. Подобная ситуация может сделать общие учетные данные уязвимыми на неопределенный срок. Парольная политика организации, предусматривающая ежегодную смену однолетних паролей, является разумным компромиссом для смягчения описанной проблемы при минимальной нагрузке на пользователя.

Примечание. Существуют организации, использующие автоматически генерируемые одноразовые пароли для каждого доступа к учетной записи (такой тип парольной политики выходит за рамки данного документа). В этих случаях пароль для каждой учетной записи может меняться по многу раз в день. Системы подобного типа отличают беспрецедентный уровень безопасности и почти такая же редкость.

Итоговая рекомендация:

5.1.4. Запрет использования словарных паролей

Проверяйте пароли по списку плохих паролей.

Организациям следует запретить использование распространенных словарных паролей. Это снижает восприимчивость к атакам Brute Force и Password Spraying. Несколько примеров часто используемых паролей: abdcefg, password, qwerty, iloveyou и 12345678 (более полный список распространенных паролей можно найти здесь).

При обработке запросов на создание или изменение пароля, новый пароль должен быть проверен по списку, который содержит часто используемые, словарные или скомпрометированные пароли. Например, список должен включать (но не ограничиваться):

✧ пароли, скомпрометированные в результате предыдущих взломов;

✧ словарные слова;

✧ повторяющиеся или последовательные символы (например, aaaaaa, 1234abcd);

✧ контекстно-специфические слова, такие как название службы, имя пользователя и производные от них;

✧ ранее использовавшиеся пароли для этой учетной записи с задержкой их изменения;

✧ личные идентификационные данные пользователя, если это возможно (дата рождения, фамилия и т.д.).

Проверка должна происходить непосредственно при создании пароля. Если пароль пользователя не прошел проверку по списку запрещенных слов, пользователь должен быть уведомлен о том, что пароль не может быть применен с кратким объяснением причины. Затем пользователю должно быть предложено ввести новый пароль.

Списки запрета паролей — относительно новый инструмент, но он становится все более распространенным, так как утечки учетных данных пользователей становятся все более частыми. Дополнительная информация по использованию списков запретов и примеры плохих паролей доступны по URL-адресам:

Azure Active Directory Password Protection
Have I Been Pwned?

Примечание. Необходимо подходить к созданию списка запретов с осторожностью и соблюдать меру. В противном случае существует вероятность сделать перечень настолько всеобъемлющим, что пользователю будет очень сложно подобрать правильный пароль.

Итоговая рекомендация:

5.1.5. Блокировка сеанса при бездействии

Блокировка сеанса при бездействии является разумной мерой предосторожности.

Нет никакой пользы в том, чтобы система или сеанс оставались активными, когда пользователь не работает. Узнать, когда пользователь активен, можно с помощью обнаружения пользовательского ввода (ввод с клавиатуры, движение мыши и т.д.).

Примечание. Вход в систему после такой блокировки должен соответствовать всем рекомендациям, применяемым для обычной аутентификации. Неудачные попытки входа должны также отслеживаться и ограничиваться (см. раздел 5.1.6 Ограничение неудачных попыток входа (блокировка)). Способ авторизации для учетной записи, заблокированной во время бездействия пользователя, должен быть того же типа, что и при обычной процедуре входа, без какого-либо упрощения. То есть учетная запись, для которой настроена МФА, в случае блокировки также должная быть авторизована с МФА, а не с применением сокращенного метода аутентификации, вроде пароля.

Итоговая рекомендация:

5.1.6. Ограничение неудачных попыток входа (блокировка)

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

Условимся не рассматривать ситуации, когда злоумышленник получает пароль пользователя в открытом виде с помощью социальной инженерии, ненадежного хранения паролей и т.д., (здесь надежность пароля, по сути, не имеет значения). В таком случае цель создания надежных паролей — не дать злоумышленнику получить доступ к целевой учетной записи или системе в результате недолгого подбора легко угадываемого пароля. «Подбор» означает, что атакующий, прежде чем обнаружить настоящий пароль, должен сделать несколько неудачных попыток авторизации в целевой системе. Именно поэтому принудительное ограничение количества попыток входа для атакующего — наиболее важная из всех мер, принимаемых для повышения надежности пароля. Временная (15-минутная) блокировка учетной записи после 5 последовательных неудачных попыток входа в систему доказала свою эффективность в борьбе с попытками перебора и угадывания пароля.

Необходимо помнить, что временная блокировка предназначена для предотвращения несанкционированного доступа, а не для создания дополнительных проблем честным пользователям и администраторам систем каждый раз, когда первые неправильно вводят пароли. Например, длительная блокировка рабочих аккаунтов (снятие которой возможно только при участии администратора) в крупной компании, действующей в нескольких часовых поясах, скорее всего, создаст больше лишних сложностей, чем принесёт пользы. В отдельных случаях разумной альтернативой может стать установка определенного количества временных блокировок, при превышении которого будет производиться уже постоянная блокировка аккаунта, требующая участия администратора для отмены (рекомендуемое значение — 10 неудачных попыток подряд).

Другая техника, набирающая популярность, – это замедление входа (login throttling), при котором каждая неудача постепенно увеличивает задержку перед следующей попыткой входа в систему.

Схемы замедления могут быть разными, но обычно они выглядят так:

✧ первая неудача, немедленная повторная попытка разрешена;

✧ вторая последовательная неудача, одна минута ожидания;

✧ двукратное увеличение времени ожидания при каждой следующей неудачной попытке;

✧ при достижении предельного значения попыток — постоянная блокировка учетной записи (требуется участие ИТ-специалистов).

Замедление входа ограничивает количество попыток угадывания, которые может предпринять злоумышленник, одновременно предоставляя пользователям несколько возможностей вспомнить свой пароль. Этот метод не так распространен в современных системах, как блокировка учетной записи по количеству неудачных попыток, но он набирает популярность в системах, работающих через Интернет. Оба метода обеспечивают хороший баланс между безопасностью, удобством использования и снижением нагрузки на работников ИТ-служб.

Примечание. Независимо от метода, используемого для ограничения неудачных попыток входа в систему, параллельно в целях безопасности должны быть настроены функции мониторинга и оповещения (см п 5.1.7 «Мониторинг неудачных попыток входа в систему»).

Примечание. Ограничение неудачных попыток входа не предотвращает компрометацию пароля с помощью методов Password Spraying (т.е. использование одного и того же пароля для многих различных учетных записей пользователей). Напротив, оно стимулирует злоумышленников использовать эту технику, чтобы избежать блокировки, что является очевидной аномалией и может быть обнаружено с помощью систем мониторинга.

Итоговая рекомендация:

5.1.7. Мониторинг неудачных попыток входа в систему

Контроль входа в систему – обязательное условие (ключевая рекомендация).

Цель создания надежных паролей – предотвратить получение неавторизованными пользователями (в частности, злоумышленниками) доступа к системам или учетным записям. В свою очередь, ведение журнала авторизации является ключевым компонентом анализа попыток получения доступа к учетной записи, будь то аккаунт обычного пользователя или администратора. Необходимо как минимум отслеживать в журнале неудачные попытки входа в систему и оповещать о них ответственный персонал.

Для обеспечения контроля неудачных попыток входа в систему предлагается следующее:

✧ регистрировать все неудачные попытки входа в систему;

✧ оповещать ответственный персонал о фактах временной или постоянной блокировки учетных записей;

✧ регистрировать попытки входа в систему из неожиданных географических зон и оповещать о них ответственный персонал;

✧ регистрировать попытки входа в систему в необычное время и оповещать о них ответственный персонал;

✧ регистрировать попытки авторизации от имени специальных сигнальных учетных записей (записи-приманки для злоумышленников, “Honeypot”) и оповещать о них ответственный

персонал.

Примечание. Мониторинг может принимать различные формы в зависимости от типа системы. Системы, подключенные к одному домену/корпоративной сети, могут контролироваться централизованно с помощью системы управления событиями безопасности (SIEM), которая объединяет и контролирует журналы событий из различных систем. Автономные системы (например, устройства Интернета вещей) могут использовать что-то элементарное, например, электронное письмо или SMS-сообщение, чтобы сообщить пользователю о превышении лимита попыток авторизации. Конечная цель состоит в том, чтобы при неудачных попытках входа в систему связаться с нужным человеком.

Итоговая рекомендация:

5.1.8. Блокирование учетной записи при неиспользовании

Неиспользуемые учетные записи должны автоматически отключаться.

Было бы идеально, если бы администраторы немедленно отключали неактивные учетные записи людей, потерявших право доступа в систему (ушедших из компании, сменивших отдел и т.д.). К сожалению, так бывает не всегда, поэтому разумно иметь техническое решение на случай, если ручной блокировки не произойдет: резервным планом может стать автоматическая приостановка учетной записи после X дней неиспользования (мы рекомендуем 45 дней).

Если пользователь не авторизовался в учетной записи в течение 45 дней с последнего успешного входа, система автоматически отключит ее. Пользователь может ее разблокировать, но для этого ему необходимо связаться с ИТ-отделом для восстановления учетной записи и обосновать, почему она по-прежнему необходима.

Итоговая рекомендация:

5.1.9. Парольные подсказки

Не разрешайте парольные подсказки.

В случае, если пользователь забыл свой пароль, подсказка позволяет вспомнить его, решив проблему самостоятельно, без привлечения ИТ-отдела. Но создаваемые риски в данном решении перевешивают всю пользу. Не существует надежного способа убедиться, что подсказка, предоставленная пользователем, не является слишком очевидной и не позволит злоумышленнику легко получить доступ к системе. Более эффективный подход – позволить пользователям создавать легко запоминающиеся пароли (парольные фразы).

Итоговая рекомендация:

5.2. Опциональные рекомендации

Эти рекомендации необязательны, и их можно применять после выполнения основных, приведенных в разделе 5.1. Опциональные рекомендации являются более специфичными и подходят не для всех случаев.
Например, если пользователь использует только один пароль, то необходимость в менеджере паролей отсутствует.

5.2.1. Индикатор надежности пароля при создании

Показатели надежности полезны, поскольку большинство людей действительно хотят создать надежный пароль.

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

Итоговая рекомендация:

5.2.2. Отображение пароля

Существует два основных случая отображения паролей.

5.2.2.1. При создании пароля

Возможность отображения пароля при его создании предпочтительнее, чем требование повторного слепого ввода

Чтобы помочь пользователю в создании пароля, система должна предложить возможность его полного отображения (без скрытия с использованием точек или звездочек). Это позволит пользователю проверить свой ввод, если обстановка позволяет безопасно отобразить его на экране. Данная возможность работает гораздо лучше, чем дублирование ввода пароля вслепую для исключения ошибок.

5.2.2.2. При введении пароля

Предоставление пользователю возможности на краткое время увидеть то, что он вводит в поле пароля, снижает количество ошибок при вводе.

Система должна опционально позволять устройству пользователя отображать отдельные введенные символы в течение короткого времени после ввода каждого символа для проверки правильности ввода (затем заменяя их звездочкой или точкой). Это может быть особенно полезно на мобильных устройствах, где текстовые поля небольшого размера, а текст в них трудноразличим.

Итоговая рекомендация:

5.2.3. Менеджеры паролей

Поощрение использования утвержденного менеджера паролей позволяет пользователям создавать надежные и уникальные для разных систем пароли.

Менеджер паролей похож на записную книжку для паролей пользователя, запертую главным ключом, о котором не знает никто, кроме владельца. На первый взгляд это может показаться неудачной идеей. Что, если кто-то узнает главный пароль пользователя? Это обоснованное опасение. Однако, при условии, что пользователь выбрал надежный, уникальный и запоминающийся основной пароль, который он больше нигде не использует, или, что еще лучше, МФА, менеджеры паролей достаточно эффективны. Как и все остальные инструменты в сфере информационной безопасности, менеджеры паролей не обеспечивают 100% безопасности, но они представляют собой отличную альтернативу для пользователей, которым необходимо управлять несколькими надежными паролями для разных учетных записей. Они позволяют избежать повторного использования одного и того же пароля для нескольких учетных записей, хранения паролей открытым текстом в системе или их записи и хранения в незащищенном месте.

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

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

Примечание. Пароли, генерируемые системой и создаваемые менеджером паролей, намного надежнее, чем пароли, создаваемые человеком, поскольку в них используется последовательность символов с большими требованиями к минимальной длине и составу (сложности). Пользователю не нужно запоминать пароль. Вместо этого менеджер паролей хранит их для пользователя.

Примечание. Вход в менеджер паролей должен соответствовать всем рекомендациям обычного входа в систему и правилам, принятым для неудачных попыток входа и мониторинга (см. раздел 5.1.6 Ограничение неудачных попыток входа (блокировка)).

Примечание. Менеджеры паролей предназначены для запоминания всех учетных данных пользователя: и имени пользователя и пароля. Следовательно, помимо сложного пароля пользователь может также создать и сложное уникальное имя пользователя для любой учетной записи. Это делает любые утекшие учетные данные еще менее полезными для злоумышленника, поскольку кроме модификации самого пароля к другой учетной записи ему нужно подобрать еще и имя пользователя. Конечно, это предполагает, что целевая система допускает определенную гибкость в выборе имени пользователя.

Итоговая рекомендация:

5.2.4. Разрешение вставки пароляРазрешите вставку в поле пароля при использовании менеджера паролей.

Системам рекомендуется разрешать пользователям функцию вставки при вводе пароля, поскольку это облегчает применение менеджеров паролей (см. раздел 5.2.3 Менеджеры паролей).

Основное опасение компаний по поводу разрешения данной функции заключается в том, что пароли хранятся в буфере обмена. Действительно, когда пользователь обращается к функции копирования/вставки, скопированное содержимое сохраняется в буфере обмена, откуда его можно вставлять сколько угодно раз. Любое программное обеспечение, установленное на компьютере (или человек, управляющий им), имеет доступ к буферу обмена и может видеть, что было скопировано. Однако большинство менеджеров паролей стирают буфер обмена сразу после вставки пароля, а некоторые вообще обходятся без буфера обмена, вводя пароль с помощью виртуальной клавиатуры. Эти возможности могут быть частью критериев выбора менеджера паролей.

Итоговая рекомендация:

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

продолжение - в заключительной, третьей части

Перевод: Аделина Любимова, Origin Security

ссылка на первоисточник

Показать полностью 13

[моё] Пароль Информационная безопасность IT Хакеры Полезное Интернет Руководство Длиннопост

Grap

1 год назад

Информационная безопасность IT

Что делать с мошенническими сайтами⁠⁠

Осторожно: длиннопост и много слов.

Всем доброго дня. Каждый из нас если и не сталкивался, то хотя бы слышал о разного рода мошенниках, орудующих в сети. По большей части это сайты, цель которых - сбор персональных данных, в том числе Логинов и паролей, данных банковских карт. Среди них и некоторое число условно безопасных, которые просто за счёт "похожести" доменного имени на какой-либо легитимный сайт "воруют" трафик и живут на рекламу с показов (однако, таких меньшинство и этот факт не отменяет их вредоносности).

Как же бороться с ними?

В первую очередь стоит проверить через сервис whois чей это сайт и у кого зарегистрирован.
(Спойлер: всё, что зарегистрировано в России с вероятностью в 0.95 можно легко снять
с делегирования aka отобрать).
В случае, если сайт "находится" на нероссийской доменной зоне верхнего уровня (.com, .org, .uk, .pw и тд), то никаких гарантий никого дать не сможет, особенно в это непростое время).

(Дальше речь пойдет про "российские" доменные зоны, про иностранцев речь пойдет позже)

Что нам поможет в этой борьбе с мошенниками?

1. Правила регистрации доменных имён в зоне ru, рф (особенно пункт 5.7);
2. Компетентные организации.

Из правил регистрации доменных имён в зонах ru, рф (пункт 5.7):

Регистратор вправе прекратить делегирование домена при поступлении регистратору мотивированного обращения организации, указанной Координатором как компетентной в определении нарушений в сети Интернет, если обращение содержит сведения о том, что адресуемая с использованием домена информационная система применяется:
1) для получения от третьих лиц (пользователей системы) конфиденциальных сведений за счет введения этих лиц в заблуждение относительно ее принадлежности (подлинности) вследствие сходства доменных имен, оформления или содержания информации (фишинг);
2) для несанкционированного доступа в информационные системы третьих лиц (пользователей, посетителей) или для заражения этих систем вредоносными программами или для управления такими программами (управления ботнетом);
3) для распространения материалов с порнографическими изображениями несовершеннолетних;

Компетентные организации

В 2012 году Координационный центр внедрил практику взаимодействия с организациями, компетентными в определении нарушений в сети Интернет. Такие организации предоставляют Координационному центру и регистраторам доменных имен информацию о ресурсах с противоправным контентом, о случаях фишинга, несанкционированного доступа к информационным системам и распространения вредоносных программ с доменных имен, находящихся в зонах .РФ и .RU. Регистраторы вправе прекратить делегирование доменных имен для подобных ресурсов. Сегодня с Координационным центром сотрудничают двенадцать компетентных организаций — Национальный координационный центр по компьютерным инцидентам, Лига безопасного интернета, Group-IB, Лаборатория Касперского, RU-CERT, РОЦИТ, Роскомнадзор, БИЗон, Банк России, Доктор Веб и Интеграл. Любой пользователь сети может сообщить об обнаруженном им случае неподобающего использования доменного имени на Горячую линию одной из этих организаций — и меры будут приняты незамедлительно.

В общем, обращение к компетентным организациям при наличии оснований гарантирует снятия вредоносного домена с делегирования. Однако стоит учесть, что по текущим НПА регистратор в праве восстановить делегирование в случае отсутствия "негативного" контента на сайте при обращении владельца домена, если он данный контент уберет.

Как же обратиться к компетентным организациям?

У каждой из перечисленных выше организации есть электронная почта, на которые они принимают обращения.

Далее представлен список компетентных организаций (с наибольшей зоной компетенции*) и зоны их компетенции.

1. Национальный координационный центр по компьютерным инцидентам (НКЦКИ) incident@cert.gov.ru (.RU, .РФ, .SU, .ORG.RU, .NET.RU, .PP.RU)

НКЦКИ создан приказом ФСБ России N 366 от 24 июля 2018 года. В соответствии с положением о НКЦКИ Национальный координационный центр по компьютерным инцидентам является составной частью сил, предназначенных для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты (ГосСОПКА).

2. Group-IB (ООО «Траст») info@group-ib.com (.RU, .РФ, .SU, .ORG.RU, .NET.RU, .PP.RU)

Компания Group-IB основана в 2003 году и является одним из ведущих разработчиков решений для предотвращения кибератак, борьбы с мошенничеством и защиты брендов от цифровых рисков со штаб-квартирой в Москве.

3. Центральный банк Российской Федерации fincert@cbr.ru (.RU, .РФ, .SU, .ORG.RU, .NET.RU, .PP.RU)

4. ООО «БИЗон» info@bi.zone (.RU, .РФ, .SU, .ORG.RU, .NET.RU, .PP.RU)

BI.ZONE — компания по управлению цифровыми рисками.

5. АНО «ЦРКИ» info@cert.ru (.RU, .РФ, .SU, .ORG.RU, .NET.RU, .PP.RU)

АНО «ЦРКИ» – российский центр реагирования на компьютерные инциденты. Основная задача центра – снижение уровня угроз информационной безопасности для пользователей российского сегмента сети Интернет.

Все указанные организации являются компетентными по вопросам:
· Phishing;
· Malware;
· Botnet controllers;
· Несанкционированный доступ;
· Детская порнография.

Лично моя рекомендация:
Наиболее эффективно писать сразу всем указанным организациям. Так и увеличивается шанс помощи вам, а также скорость блокировки ресурса. Даже если какая-то из организаций вам откажет, все равно есть шанс на то, что остальные примут меры.

Что необходимо указать при обращении?

- Непосредственно URI вредоносного контента (адрес страницы).

Что стоит так же дополнительно указать:

- адрес легитимного ресурса (если таковой имеется);
- скриншот страницы.

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

Стоит отметить, что блокировка не происходит мгновенно. Срок снятия домена с делегирования может составлять несколько суток. При этом, если владелец уберет контент, делегирование восстановится. Если срок аренды домена пройдет (а с ним и пройдет и "разделегирование"), любое лицо в праве купить такой домен и разместить любой контент.

Такое стоит отметить, что указанные организации не смогут помочь по вопросам явного мошенничества, что является компетенцией МВД России.

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

P.S. вся информация взята с официальных сайтов указанных организаций и координационного центра https://cctld.ru

P.P.S за шакалистые изображения прошу прощения

P.P.P.S пост не является рекламой. Все описанные действия являются общественно полезными и бесплатными

Показать полностью 6

[моё] Информационная безопасность IT Интернет-мошенники Регистраторы доменных имен Длиннопост Безопасность Мошенничество Противодействие Фишинг Центральный банк РФ ФСБ МВД Бизон Group-IB Нелегальные сайты Негатив

originsecurity

1 год назад

Информационная безопасность IT

Руководство по парольной политике. Часть 1⁠⁠

Первая часть практического руководства по созданию эффективных паролей от коллектива иностранных авторов, переведённого экспертами Origin Security специально для наших читателей

1. Примечание переводчика

Оригинальный материал и этот перевод находятся под действием лицензии
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

2. Введение

Пароли повсеместно используются в современном мире. Если у вас есть учетная запись на компьютере, то наверняка будет хотя бы один пароль. Пароли использовались в компьютерах с момента появления вычислительной техники. Первой операционной системой с реализованным механизмом аутентификации на основе пароля стала Compatible Time-Sharing System (CTSS), представленная в Массачусетском технологическом институте в 1961 году.

Пароли – это самая простая форма реализации информационной безопасности. В течение многих лет эксперты пробовали сделать пароли более сложными для взлома, применяя различные правила создания и использования паролей (т.н. парольные политики).

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

Поэтому, чтобы эффективно противодействовать злоумышленнику, парольная политика должна иметь реальное обоснование и не приводить пользователей в замешательство и расстройство. Некоторые крупные игроки в области стандартизации информационных технологий (NIST, Microsoft и пр.) недавно разработали новые парольные политики, основанные на двух базовых принципах:

1. Использование данных о техниках и тактиках действий злоумышленников.

2. Облегчение пользователям создания, запоминания и использования надежных паролей (учет человеческого фактора).

Цель этого документа – не изобретать велосипед, но объединить новые руководства по парольной политике в одном месте. Создать универсальную парольную политику, которую можно использовать везде, где это потребуется.

2.1 Обзор лучших практик

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

2.1.1. Многофакторная аутентификация (МФА)

МФА – это самый эффективный метод защиты, и, хотя в руководстве ему посвящён отдельный раздел, здесь он заслуживает особого упоминания. МФА должна быть приоритетным вариантом при проектировании системы аутентификации для всех пользователей и везде, где это возможно. Особенно она необходима для безопасности доступа администраторов и других привилегированных учетных записей. Понятно, что МФА сама по себе не является панацеей хотя бы потому, что далеко не во всех информационных системах возможна её техническая реализация. Кроме того, даже при использовании МФА иметь стойкий пароль полезно, поскольку он используется как один из факторов.

2.1.2 Менеджер паролей

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

2.1.3 Политика создания и применения паролей пользователями

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

3. Обзор рекомендаций

Краткое описание рекомендаций по парольной политике представлено в таблице ниже. Детальная информация по каждой рекомендации раскрыта в главе 5.

Руководство по парольной политике. Часть 1 IT, Полезное, Пароль, Информационная безопасность, Менеджер паролей, Хакеры, Руководство, Cis, Длиннопост

Общая цель эффективной парольной политики – позволить пользователям легко создавать достаточно надежные пароли для доступа к системе, а затем отслеживать и ограничивать попытки доступа для обнаружения/предотвращения их несанкционированного использования.

4. Насколько важен пользовательский пароль?

Ввиду повсеместного использования паролей для доступа к компьютерным системам всех типов, очевидно, что пароли очень важны. Но существует ли компромисс между безопасностью и удобством использования? Не привели ли попытки разработать политику, чтобы сделать более безопасными применяемые пароли, к фактическому снижению уровня безопасности системы из-за человеческого фактора? В известной статье Алекса Вайнерта (Microsoft) «Your Pa$word doesn’t matter» приведено описание реальных атак на пользовательские пароли, развеяны распространенные мифы о надежности паролей и поведении пользователей. Обобщенная информация представлена в следующей таблице:

Из всех распространенных атак, перечисленных выше, надежность пароля имеет значение только в двух случаях:

✧ проводимые онлайн: перебор учетных записей (password spraying, password guessing);

✧ проводимые офлайн: перебор паролей, взлом (brute force, database extraction, cracking).

Давайте рассмотрим их подробнее.

4.1 Атаки, проводимые онлайн

Password Guessing или Hammering – это систематический подбор пароля злоумышленником к одной целевой учетной записи. Перебор проводится преимущественно по словарям и по утечкам, найденным в Интернете.

Password Spraying – это вариант атаки, при котором злоумышленник использует те же списки паролей, но нацеливается на множество общедоступных или легко определяемых (например, общий формат имени учетной записи) учетных записей пользователей.

В случае с Password Guessing кажется, что здесь важна надежность пароля, но на самом деле гораздо важнее мониторинг и ограничение неудачных попыток входа. При наличии разумных ограничений и мониторинга тот факт, что современные технологии позволяют перебирать миллиарды паролей в секунду, не имеет значения, поскольку учетная запись будет заблокирована, а администратор безопасности – уведомлен об инциденте. Именно поэтому более распространенной формой атаки стал Password Spraying, но чтобы он был эффективным, злоумышленнику необходимо избегать блокировки учетных записей. Добиться этого можно, если узнать формат имени учетной записи, принятый в целевой организации. В таком случае атака заключается в переборе ограниченного словаря паролей, но в отношении множества учетных записей, что не приводит к их блокировке и позволяет злоумышленнику не попадать в поле зрения команды защитников.

Даже в этих случаях более сложный пароль не является лучшим решением. Гораздо более эффективным и простым для пользователей вариантом будет использование более длинных, сложных и разнообразных имен учетных записей. Действенным способом обнаружения атак типа Password Spraying является использование специальных сигнальных учетных записей. Это действительные аккаунты с минимальными привилегиями, которые соответствуют принятой парольной политике, но не предназначены для доступа. Попытки авторизации с их помощью свидетельствуют о компьютерной атаке, расследование которой позволяет администраторам информационной безопасности заранее обнаружить угрозу и не допустить компрометации паролей настоящих учетных записей.

4.2 Атаки, проводимые офлайн

Это единственный вариант, когда сложность пароля по-настоящему имеет значение. При такой атаке злоумышленник уже завладел базой данных учетных записей/паролей целевой компании, в которой пароли хранятся в хэшированном виде (вместо обычных текстовых паролей, что было бы слишком просто). В дальнейшем злоумышленник восстанавливает настоящие пароли из найденных хэш-сумм методом перебора с применением одного из множества свободно распространяемых инструментов (например, John the Ripper или L0phtCrack) или специальной программой, разработанной для этого самим злоумышленником.

Мы не будем подробно описывать принцип работы этих программ (существует множество открытых источников по взлому паролей), но в общем случае злоумышленник может сделать следующее:

1. Создать «брут-машину»: стандартное компьютерное оборудование с высокопроизводительной видеокартой, которое может вычислять и проверять несколько миллиардов несложных хэшей (MD5, SHA1, NTLM и т.д.) в секунду. Легкодоступные установки для добычи криптовалют (майнеры) могут без труда достичь скорости перебора в 100 миллиардов хэшей в секунду, а хорошо финансируемые злоумышленники (прогосударственные группировки) могут достичь скорости и в 100-1000 раз выше.

2. Перебрать все возможные пароли. При использовании майнера и предположении, что мощность словаря пароля составляет 96 символов, бездумное перебирание всех вариантов пароля займёт следующее время:

3. Ускорить перебор, используя дополнительные техники и знания:

✧ изучив целевую организацию, злоумышленник может выяснить алгоритм хэширования и специфичные для неё правила генерации паролей (минимальная/максимальная длина, сложность и т. д.);

✧ использовать списки паролей, полученные в результате предыдущих взломов (огромное количество паролей уже находятся в свободном доступе). После хеширования проводится проверка на совпадение с хэшами в целевой базе данных. По статистике, это позволяет взломать около 70% паролей пользователей;

✧ если это не сработает, злоумышленник может составить список всех популярных фраз, текстов песен, заголовков новостей, частых запросов поисковых систем, википедии, популярных статей и т.д. Или взять готовый — подобные списки доступны в различных сообществах «хэшбрейкеров». Таким образом можно подобрать еще 5-7% паролей пользователей;

✧ наконец, злоумышленник может использовать предугаданные шаблоны (например, пароль всегда начинается с заглавной буквы, затем 3-6 строчных букв, 2-4 цифры и восклицательный знак в конце) и подобрать более длинные пароли (до 12 символов). Это позволяет вскрыть еще 5-7% пользовательских паролей.

4. В случае использования «соли» для хранения паролей в базе (применения к хэшу дополнительного преобразования, усложняющего автоматический перебор), данные техники применяются не для всех хэшей, а для одного. Вместе с тем, атака проводится с высокой вероятностью успеха почти в 85% и за относительно короткий промежуток времени, что позволяет злоумышленнику перейти к следующей учетной записи и последовательно перебрать их все.

Здесь стоит отметить следующее:

✧ данный метод перебора работает только в том случае, когда у атакующего есть база учетных записей/паролей. Как злоумышленник получил ее? Если уровень доступа атакующего достаточен, чтобы получить базу данных, то целью он, скорее всего, уже владеет;

✧ если база данных учетных записей/паролей, полученная злоумышленником, не относится к цели, то взломанный пароль все равно нужно попробовать на реальной учетной записи в целевой системе;

✧ человек вряд ли сможет создать надежный пароль, который выдержит описанные попытки взлома. Если противодействие им необходимо, используйте длинный и сложный пароль, сгенерированный автоматически. Например, созданный и управляемый менеджером паролей;

✧ технические возможности для взлома хэшей постоянно растут. Неужели мы будем постоянно гнаться за ними, делая пароли всё длиннее, сложнее и труднее для запоминания, пытаясь справиться с одним-единственным сценарием атаки? Очевидно, будет лучше использовать более комплексный подход.

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

Перевод: Аделина Любимова, Origin Security

Ссылка на первоисточник

Показать полностью 3

[моё] IT Полезное Пароль Информационная безопасность Менеджер паролей Хакеры Руководство Cis Длиннопост

originsecurity

1 год назад

Информационная безопасность IT

Указ Президента 250. Разъяснение. Введение⁠⁠

Сегодня мы начинаем публиковать цикл статей, в которых постараемся ответить на вопросы, касающиеся применения указа Президента Российской Федерации от 01.05.2022 № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации» (указ президента 250).

Цель данной статьи – провести обзорный анализ каждого пункта указа, прокомментировать часто задаваемые вопросы и поделиться ссылками на смежные нормативные акты, проясняющие ситуацию (гиперссылки по тексту).

Сразу отметим, что продолжаем сбор вопросов от читателей по двум обширным темам, лишь затронутым в этом тексте — «ГосСопка и взаимодействие с ГосСОПКА» и «250 указ президента. Персональная ответственность руководителей». Вопросы можно задавать в комментариях к данной статье. Это поможет нашим экспертам подготовить максимально полезные с практической точки зрения материалы для следующих статей цикла.

Итак, начнем. Текст указа здесь .

П.1 Указа

1. Руководителям федеральных органов исполнительной власти, высших исполнительных органов государственной власти субъектов Российской Федерации, государственных фондов, государственных корпораций (компаний) и иных организаций, созданных на основании федеральных законов, стратегических предприятий, стратегических акционерных обществ и системообразующих организаций российской экономики, юридических лиц, являющихся субъектами критической информационной инфраструктуры Российской Федерации (далее — органы (организации):

Какие именно органы и организации имеются в виду?

Эксперты расходятся во мнениях: существует, как минимум, два варианта трактовки данного пункта указа.

✧ Вариант 1. Только субъекты КИИ, а именно органы власти, являющиеся субъектами кии, фонды, являющиеся субъектами кии, корпорации, являющиеся субъектами кии и юрлица, являющиеся субъектами кии;

✧ Вариант 2. Юрлица, являющиеся субъектами КИИ, а также органы власти, фонды, корпорации.

Разъяснений, судебной практики, результатов проверок регуляторов, могущих внести ясность, на данный момент нет. Отметим, что, используемое в тексте понятие «юридического лица» так или иначе обобщает остальные виды субъектов (органы власти, фонды, корпорации и т.д.) —

юридическим лицом признается организация, которая имеет обособленное имущество и отвечает им по своим обязательствам, может от своего имени приобретать и осуществлять гражданские права и нести гражданские обязанности, быть истцом и ответчиком в суде (Ст.48 ГК РФ).

Также обратим внимание на определение «Субъект КИИ» из ФЗ-187.

субъекты критической информационной инфраструктуры — государственные органы, государственные учреждения, российские юридические лица и (или) индивидуальные предприниматели, которым на праве собственности, аренды или на ином законном основании принадлежат информационные системы, информационно-телекоммуникационные сети, автоматизированные системы управления, функционирующие в сфере здравоохранения, науки, транспорта, связи, энергетики, банковской сфере и иных сферах финансового рынка, топливно-энергетического комплекса, в области атомной энергии, оборонной, ракетно-космической, горнодобывающей, металлургической и химической промышленности, российские юридические лица и (или) индивидуальные предприниматели, которые обеспечивают взаимодействие указанных систем или сетей (ст. 2 187-ФЗ)

Какой можно сделать вывод?

К индивидуальным предпринимателям (далее – ИП) — субъектам КИИ данный пункт Указа не относится. На остальные субъекты КИИ указ распространяется.

Таким образом, требования первого пункта указа обязательны для руководителей

✧ субъектов КИИ, кроме ИП (1 вариант);

✧ субъектов КИИ, кроме ИП, а также всех указанных ОИВ, ОГВ, госфондов, корпораций, предприятий (2 вариант).

Исходя из собственной практики, мы придерживаемся мнения, что указ распространяется как на субъекты КИИ, так и на тех, кто ими не является (вариант 2).

Пп.а) б) п.1 Указа

а) возложить на заместителя руководителя органа (организации) полномочия по обеспечению информационной безопасности органа (организации), в том числе по обнаружению, предупреждению и ликвидации последствий компьютерных атак и реагированию на компьютерные инциденты;

б) создать в органе (организации) структурное подразделение, осуществляющее функции по обеспечению информационной безопасности органа (организации), в том числе по обнаружению, предупреждению и ликвидации последствий компьютерных атак и реагированию на компьютерные инциденты, либо возложить данные функции на существующее структурное подразделение;

Указанные требования довольно сложны в реализации, так как субъектом КИИ могут быть и малые предприятия с совсем небольшим штатом. Очевидно, что создание собственной службы ИБ может серьёзно подорвать бюджет условной частной клиники со штатом в 5-7 человек.

Отставив экономические моменты, обнаружим, что и с юридической точки зрения в этом подпункте тоже есть нюансы.

С одной стороны, «возложение полномочий» относится к взаимоотношениям между работником и работодателем. Заключать договор имеет право работодатель (Ст.20 ТК РФ), и, соответственно, он же может определять «Трудовые функции» работника в трудовом договоре (Ст.57 ТК РФ). Однако, на основании указа президента 250, государство фактически забирает себе часть полномочий работодателя, обязывая его изменить должностную инструкцию своего заместителя или даже внести изменения в штатное расписание организации в случае отсутствия зама.

Пп.в) п.1 Указа

в) принимать в случае необходимости решения о привлечении организаций к осуществлению мероприятий по обеспечению информационной безопасности органа (организации). При этом могут привлекаться исключительно организации, имеющие лицензии на осуществление деятельности по технической защите конфиденциальной информации;

Данный пункт не раскрывает понятия «Мероприятия по обеспечению информационной безопасности». Возникает вопрос: речь идёт только о мероприятиях, которые определены в «Положении о лицензировании деятельности по технической защите конфиденциальной информации» (утв. постановлением Правительства РФ от 3 февраля 2012 г. N 79), или предполагается расширение этого перечня мероприятий?

Утверждение положений о лицензировании конкретных видов деятельности и принятие нормативных правовых актов по вопросам лицензирования относятся к полномочиям не Президента, а Правительства РФ (Ст.5 ФЗ-99). Поэтому мы склоняемся к мнению, что перечень расширяться не будет, и под «мероприятиями по обеспечению информационной безопасности» имеются в виду именно лицензируемые услуги:

а) услуги по контролю защищенности конфиденциальной информации от утечки по техническим каналам;

б) услуги по контролю защищенности конфиденциальной информации от несанкционированного доступа и ее модификации в средствах и системах информатизации;

в) услуги по мониторингу информационной безопасности средств и систем информатизации;

г) работы и услуги по аттестационным испытаниям и аттестации на соответствие требованиям по защите информации;

д) работы и услуги по проектированию в защищенном исполнении;

е) услуги по установке, монтажу, наладке, испытаниям, ремонту средств защиты информации.

Пп. г) п.1 Указа

г) принимать в случае необходимости решения о привлечении организаций к осуществлению мероприятий по обнаружению, предупреждению и ликвидации последствий компьютерных атак и реагированию на компьютерные инциденты. При этом могут привлекаться исключительно организации, являющиеся аккредитованными центрами государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации, за исключением случая, предусмотренного подпунктом «б» пункта 5 настоящего Указа;

Вопросы касающиеся этого требования, как правило, связаны не с мероприятиями по обнаружению, предупреждению и ликвидации последствий компьютерных атак (далее – КА) и реагированию на компьютерные инциденты (далее – КИ), а именно с взаимодействием (подключением) с ГосСОПКА, ведомственными и корпоративными Центрами ГосСОПКА. Однако тема эта — очень важная и обширная, поэтому предлагаем рассмотреть её в отдельной статье. А для того, чтобы сделать статью максимально полезной, хотим попросить вас, уважаемые читатели, оставить в комментариях волнующие вас вопросы по данной проблеме. Давайте вместе сделаем гайд по работе с ГосСОПКА, который поможет не одному десятку компаний разобраться в этой непростой теме!

Пока же вернемся к вопросу мероприятий. В числе упомянутых — обнаружение, предупреждение, ликвидация, реагирование. Что именно понимает нормотворец под этими словами? На данный момент эти термины официально не разъясняются, однако в проекте ГОСТ Р «Защита информации. Обнаружение, предупреждение и ликвидация последствий компьютерных атак и реагирование на компьютерные инциденты. Термины и определения» они уже появились. Мы не сторонники использования не введенных в действие документов, но, тем не менее, считаем, что данные определения уже могут быть полезны:

✧ ликвидация последствий компьютерного инцидента: Комплекс мероприятий по восстановлению штатного режима функционирования информационных ресурсов после КИ.

✧ обнаружение компьютерных атак: Комплекс мероприятий по выявлению и анализу признаков КА и определению ее типа.

✧ предупреждение компьютерных атак: Комплекс превентивных мероприятий, направленных на снижение количества КИ и повышение уровня защищенности информационных ресурсов.

✧ реагирование на компьютерный инцидент: Процесс (процедура, функция) автоматической (автоматизированной) обработки КИ.

По поводу аккредитации центров ГосСОПКА — ждем порядок аккредитации от ФСБ (см. п.5 УП-250).

Стоит отметить, что пп.г) п.1 указа 250 явно разделены мероприятия по обеспечению ИБ и по обнаружению, предупреждению и ликвидации последствий для КА и КИ. В первом случае компаниям необходимо пройти процедуру лицензирования по ТЗКИ (ФСТЭК), во втором – аккредитации (ФСБ).

Пп. д) п.1 Указа

д) обеспечивать должностным лицам органов федеральной службы безопасности беспрепятственный доступ (в том числе удаленный) к принадлежащим органам (организациям) либо используемым ими информационным ресурсам, доступ к которым обеспечивается посредством использования информационно-телекоммуникационной сети «Интернет», в целях осуществления мониторинга, предусмотренного подпунктом «в» пункта 5 настоящего Указа, а также обеспечивать исполнение указаний, данных органами федеральной службы безопасности по результатам такого мониторинга;

Основные вопросы, которые следует рассмотреть применительно к данному пункту: в рамках каких именно мероприятий необходимо давать доступ представителям ФСБ? и где взять порядок осуществления мониторинга?

В п. 5 указа 250 мы видим, что порядок осуществления мониторинга определяет ФСБ. На данный момент он не разработан и не опубликован. Следует набраться терпения и ожидать разработки порядка осуществления мониторинга от наших старших коллег.

Пп.е) п.1 Указа

е) обеспечивать незамедлительную реализацию организационных и технических мер, решения о необходимости осуществления которых принимаются Федеральной службой безопасности Российской Федерации и Федеральной службой по техническому и экспортному контролю в пределах их компетенции и направляются на регулярной основе в органы (организации) с учетом меняющихся угроз в информационной сфере.

Незамедлительно и на регулярной основе – это как? Отсутствие толкования понятий в данном пункте может вызвать обоснованное недоумение.

Понятие «Незамедлительно» отсутствует в нормах права, однако в судебной практике определение данного термина приводится. Постановлением ФАС Поволжского округа от 14 апреля 2008 г. N А55-6599/07 определено, что «Понятие незамедлительно означает, как только это окажется возможным.».

Фраза «решения … направляются на регулярной основе в органы (организации)» дает понять, что эти решения будут являться ненормативными правовыми актами, то есть «постановлений, приказов, правил, инструкций и положений» ожидать не стоит. Вероятно, предполагаются целевые письма со списком рассылки.

П. 2 Указа

2. Возложить на руководителей органов (организаций) персональную ответственность за обеспечение информационной безопасности соответствующих органов (организаций).

Тема персональной ответственности руководителей органов (организаций) за обеспечение информационной безопасности, безусловно, тоже заслуживает отдельного разговора. Наши эксперты планируют посвятить ей одну из следующих статей. Кроме того, мы также ждем ваши вопросы по данной теме в комментариях.

П. 3 Указа

3. Правительству Российской Федерации в месячный срок:
а) утвердить:
типовое положение о заместителе руководителя органа (организации), ответственного за обеспечение информационной безопасности органа (организации);
типовое положение о структурном подразделении органа (организации), обеспечивающем информационную безопасность органа (организации);
б) определить перечень ключевых органов (организаций), которым необходимо осуществить мероприятия по оценке уровня защищенности своих информационных систем с привлечением организаций, имеющих соответствующие лицензии Федеральной службы безопасности Российской Федерации и Федеральной службы по техническому и экспортному контролю.

Указанные в пп. а) п.3 Указа типовые положения утверждены Постановлением правительства РФ от 15.07.2022 №1272.

Перечень ключевых органов (организаций), упомянутый в пп. б) п.3 Указа, утвержден Распоряжением Правительства РФ от 22 июня 2022 г. N 1661-р.

Стоит добавить одну ремарку – подведомственные организации, а также филиалы, имеющие ИНН, отличный от ключевого органа (организации) в данный перечень не входят.

П.4 Указа

4. Органам (организациям), включенным в перечень, определенный в соответствии с подпунктом «б» пункта 3 настоящего Указа, осуществить мероприятия по оценке уровня защищенности своих информационных систем и до 1 июля 2022 г. представить доклад в Правительство Российской Федерации.

Здесь содержится очень тонкий юридический момент: самостоятельно данная оценка должна быть проведена ключевым органом (организацией) до 1 июля 2022 года, однако для оценки с привлечением организаций-лицензиатов срок не указан. Поэтому нарушением не будет, например, следующая ситуация: ключевой орган до 1 июля 2022 года оформил «акт оценки» самостоятельно и запланировал на конец года оценку уровня защищенности своих информационных систем лицензиатом.

Формат оценки уровня защищенности также не определен. Термин «оценка уровня защищенности информационных систем» в нормативных документах и стандартах не закреплен, поэтому в данный момент следует ожидать разъяснений правительства и появления судебной и регуляторной практики. До того времени оценку уровня защищенности допускается делать по собственным разработанным программам и методикам, либо по формам, соответствующим типу принадлежащих информационных систем. Это могут быть аттестация (ГИС, АС), приемочные испытания (АСУТП, ЗОКИИ), контроль за выполнением требований (ИСПДн) или контроль защиты информации (по «Порядку и организации проведения работ по аттестации…»). Вместе с тем, Минцифры России разработало Типовое техническое задание на выполнение работ по оценке уровня защищенности информационной инфраструктуры, но использование его является необязательным.

П.5 Указа

5. Федеральной службе безопасности Российской Федерации:
а) организовать аккредитацию центров государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации;
б) определить переходный период, в течение которого допускается осуществлять мероприятия по обнаружению, предупреждению и ликвидации последствий компьютерных атак и реагированию на компьютерные инциденты в интересах органов (организаций) на основании заключенных с Федеральной службой безопасности Российской Федерации (Национальным координационным центром по компьютерным инцидентам) соглашений о сотрудничестве (взаимодействии) в области обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты;
в) определить порядок осуществления мониторинга защищенности информационных ресурсов, принадлежащих органам (организациям) либо используемых ими, и осуществлять такой мониторинг.

Документы, разъясняющие вопросы аккредитации, переходного периода и определения порядка осуществления мониторинга, на данный момент еще не опубликованы. Ждем подзаконные акты от ФСБ России.

П.6. Указа

6. Установить, что с 1 января 2025 г. органам (организациям) запрещается использовать средства защиты информации, странами происхождения которых являются иностранные государства, совершающие в отношении Российской Федерации, российских юридических лиц и физических лиц недружественные действия, либо производителями которых являются организации, находящиеся под юрисдикцией таких иностранных государств, прямо или косвенно подконтрольные им либо аффилированные с ними.

Следует обратить внимание, что данный пункт предписывается всем органам (организациям), а не только ключевым. Для определения перечня средств защиты, которые попадают под «импортозамещение», рекомендуем изучить термины «Средство защиты информации» и «Защита информации»:

✧ средство защиты информации (ГОСТ 50922): техническое, программное, программно-техническое средство, вещество и (или) материал, предназначенные или используемые для защиты информации;

✧ защита информации (ГОСТ 50922): деятельность, направленная на предотвращение утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на защищаемую информацию.

Таким образом, под «импортозамещение» до 2025 года попадают технические, программные, программно-технические средства, вещества и (или) материалы, предназначенные и используемые в целях предотвращения утечки защищаемой информации, а также несанкционированных и непреднамеренных воздействий на неё.

Список недружественных стран установлен Распоряжением Правительства РФ от 05.03.2022 N 430-р. На момент написания статьи в него входят следующие страны и территории: Австралия, Албания, Андорра, Багамские Острова, Великобритания, Государства — члены Европейского союза, Исландия, Канада, Лихтенштейн, Микронезия, Монако, Новая Зеландия, Норвегия, Республика Корея, Сан-Марино, Северная Македония, Сингапур, Соединенные Штаты Америки, Тайвань (Китай), Украина, Черногория, Швейцария, Япония.

П. 7 Указа

7. Настоящий Указ вступает в силу со дня его официального опубликования.

Дата официального опубликования указа – 01.05.2022 (www.pravo.gov.ru).

Автор: Роман Антонов, Origin Security

ссылка на первоисточник

Показать полностью 1

[моё] Информационная безопасность Указ президента РФ Право Законодательство Персональные данные Нормативные акты Защита информации Длиннопост

originsecurity

1 год назад

Информационная безопасность IT

Продолжаем про «замочки». Разбираемся с понятиями «транзитивность доверия» и «сертификат проверки электронной подписи»⁠⁠

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

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

Самое главное понятие – это «доверие». Чтобы без страха вбивать все данные своей банковской карты в форму заказа интернет-магазина, надо быть более-менее уверенным, что это именно форма магазина, а магазин – тот, за кого себя выдает. В противном случае можно очень легко пополнить статистику банковского «фрода», подарив свои кровные мошенникам, ворующим средства с пластиковых карт.

Что такое «доверие»? Вроде бы интуитивно — понятно, но объяснить, ничего не упустив, довольно сложно. Придумано множество определений – философские, математические, экономические, существуют даже шкалы доверия и другая страшная матлогика. Нам в данном случае нет смысла точно определять понятие, достаточно «житейского» понимания, что «доверие» — «это когда чему-то можно доверять».

Доверие приходится трудно и долго завоевывать, но его очень легко потерять. Достаточно один раз не оправдать доверия – и все, репутация испорчена.

Однако, вернемся к нашим «замочкам». Их использование было бы невозможным без ещё одного важнейшего понятия «транзитивности доверия». Это свойство можно сравнить с «рекомендацией»: если кто-то, кому вы уже доверяете (например, хороший друг), заверяет вас в чем-то (например, «пиво классное!»), то вы с большой вероятностью не будете обмануты, когда воспользуетесь услугой или купите товар. То есть, производителю пива можно доверять потому, что ему уже доверяет ваш друг, которому, в свою очередь, доверяете вы.

Доверие и транзитивность доверия, кстати, могут быть и недобровольными. Например, государство организует паспортную систему – систему учета граждан, в соответствии с которой все граждане старше 14 лет обязаны иметь некоторое физическое удостоверение – общегражданский паспорт, выданный государством, в котором перечислены персональные данные гражданина. А далее всех субъектов права (тех, кто проверяет личность, то есть пытается установить доверие с другим субъектом) фактически вынуждают доверять государству, а также его органам, выдающим паспорта.

Что же до наших «Контактиков» с котиками? Там пока паспорт не требуется. Да и бухгалтерша Люба (как известно, звезда «Youtube»), не проверяет ИНН и свидетельство о госрегистрации этого «Yotube» в администрации штата Калифорния. Проверять, что стороны информационного обмена – те, за кого себя выдают, придется каким-то другим способом, не прибегая к «традиционным» бюрократическим средствам аналоговой эпохи.

Причем, в разных случаях и варианты проверки могут быть разными. Например, в случае Любы и «Yotube» есть некая «асимметричность: Любе-то очень надо убедиться, что она загружает своё бесценное видео с котиками именно на «Youtube» (а то ещё попадёт не в те руки). Для «Youtube» же Люба не так интересна, потому что возможные потери в случае, если Люба на самом деле окажется какой-нибудь Машей, для него несущественны. А вот в случае Интернет-магазина критичность доверия почти симметрична: потери как для клиента, так и для магазина будут выражаться в деньгах, иногда вполне существенных.

Так какой же выход можно предложить нашей Любе, а заодно с ней и всем пользователям интернета?

Создать электронный аналог удостоверения личности, который можно предъявить удаленно, и доказать, что он принадлежит именно вам.

Как доказать? С помощью математики, а именно ее раздела, изучающего шифры – криптографии. Да-да, те самые шифры, за которыми охотятся все спецслужбы в шпионских детективах и о которых шла речь в предыдущей статье.

Электронное удостоверение личности в российской терминологии (у нас всегда идут своим путем) называется «сертификатом проверки электронной подписи» (про открытую криптографию, подписи, ключи тд – в следующий раз). Англоязычный термин – certificate или digital certificate.

Выдачей сертификатов занимается третья сторона – Удостоверяющий центр, УЦ (англ. Certificate Authority, CA). Можно сказать, что это — тот самый «хороший друг» из примера про пиво. Для выдачи сертификата Удостоверяющий центр проверяет корректность данных, предоставленных претендентом (например, «Youtube», или Гендиректором фирмы, где работает Люба), формирует некий файл, в который записывает эти данные (например, что «Youtube» владеет доменом youtube.com, а Гендиректора зовут Штукенберг Эдмунд Феликсович), а также открытый ключ претендента, и подписывает своей электронной подписью. Этим УЦ подтверждает, что данные проверены, можно доверять. В результате претенденту, который теперь уже будет называться подписчиком, выдается электронный документ — сертификат, который можно прикрепить к сайту в качестве удостоверения. Все сертификаты защищены от подделок с помощью технологий шифрования, что вкупе с репутацией самого УЦ позволяет остальным пользователям им доверять.

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

Удостоверяющие центры могут быть коммерческими (предоставляют услуги всем желающим на возмездной основе), корпоративными, государственными, даже «личными».

Все участники должны по умолчанию доверять УЦ, как всеобщему лучшему другу. Если доверия к УЦ нет – вся инфраструктура разваливается. Именно поэтому удостоверяющие центры уделяют так много внимания собственной информационной безопасности и проверке корректности персональных данных.

Вот таким вот образом любой из миллиардов пользователей всемирной паутины может спокойно оформлять заказы в интернет-магазинах и безбоязненно выкладывать видео с дорогими сердцу питомцами. Всё благодаря шифрованию, транзитивности доверия и работе Удостоверяющих центров.

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

Текст: Максим Теплов, Origin Security

Ссылка на первоисточник

Показать полностью

[моё] Шифрование Информационная безопасность Электронная подпись IT Интернет Полезное Длиннопост

originsecurity

1 год назад

Информационная безопасность IT

Поиск информации в открытых источниках (OSINT). Сбор данных о компании в беспроводных сетях передачи информации. (Часть 4)⁠⁠

В предыдущих частях мы рассказывали о том, как, какую и для каких целей хакеры могут получить информацию о Вас и Вашей компании из открытых источников:

С чего начинается хакерская атака на компанию? (Часть 1)

Получение адресов электронной почты для фишинговых и спам-атак. (Часть 2)

Изучение сотрудников компании для формирования фишинговых писем. (Часть 3)

В заключительной части мы рассмотрим методы использования беспроводных сетей передачи информации (Wi-Fi) злоумышленниками и то, какое значение это может оказать на предприятие.

Дисклеймер: Данная статья имеет исключительно информационный характер и написана в ознакомительных целях. Она не является руководством к неправомерным действиям или обучающим материалом для сокрытия правонарушений. Мы призываем наших читателей не нарушать законодательство РФ и других стран.

Беспроводные сети передачи информации (Wi-Fi), обеспечивая стабильное и скоростное подключение, сегодня являются популярным решением как для дома, так и для офиса. Компании выбирают Wi-Fi, так как это позволяет увеличить производительность труда за счет мобильности сотрудников, позволяет более эффективно использовать рабочее пространство, избежать нагромождения проводов и обеспечить легкое обслуживание. Приятным бонусом является относительно небольшая цена данной технологии на рынке. Однако, основным требованием к любой, и в первую очередь корпоративной, сети является ее защищенность. И здесь, надо отметить, степень безопасности данных, доступ к которым можно получить в любой точке пускай и ограниченной площади, оставляет желать лучшего.

Вернемся к основной теме, — сбору открытой информации. Агрегаторы Wi-Fi сетей, такие как wigle.net или 3wifi.stascorp.com, позволяют найти их идентификаторы с привязкой к карте, а иногда и пароли к ним.

Если злоумышленник может позволить себе приехать к атакуемому объекту, то идентификаторы активных сетей он сможет собрать и самостоятельно при помощи утилиты airodump-ng. Это же ПО позволяет обнаружить идентификаторы, к которым подключались сотрудники организации. Если на смартфоне включен модуль Wi-Fi с автоматическим подключением к сетям, то он будет передавать в эфир список точек доступа, к которым этот гаджет «хочет» подключиться.

При помощи обнаруженных идентификаторов возможно создать так называемую «evil AP» («злую точку доступа») – близнеца запрашиваемой точки. После того как телефон сотрудника автоматически подключится к ней, перехват аутентификационных данных – лишь вопрос времени. А с их помощью, злоумышленник и сам получит доступ к конфиденциальной информации.

Дополнение к предыдущим материалам

Представим, что хакеру не удалось обнаружить информацию о целевой компании. Вы уверены в собственной системе защиты данных, постоянно отслеживаете все, что с ней связано. В этом случае, злоумышленника, вероятно, заинтересует информация о филиалах, подведомственных и дочерних организациях. Он начинает искать фирмы, связанные с целевой. Часто для ускорения документооборота и удобства сотрудников объединяют сетевые инфраструктуры в единое целое, оставляя их организационно и структурно обособленными. Это также может быть использовано в качестве канала для проникновения и проведения атаки на целевую организацию.

Для поиска такой информации в российском сегменте могут быть использованы ресурсы list-org.com и zachestnyibiznes.ru.

Заключение

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

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

Текст: команда Origin Security

Ссылка на источник статьи

Показать полностью 5

[моё] Полезное IT Интернет Osint Хакеры Информационная безопасность Поиск Wi-Fi Длиннопост

Партнёрский материал

specials

Угадайте звездного капитана юмористической команды «Сборная Красноярска» по описанию одного из участников⁠⁠

Ну что, потренировались? А теперь пора браться за дело всерьез.

Показать полностью

Видео ВК Шоу

originsecurity

1 год назад

Информационная безопасность IT

Поиск информации в открытых источниках (OSINT). Изучение сотрудников компании для формирования фишинговых писем. (Часть 3)⁠⁠

В предыдущих частях (часть 1 и часть 2) мы рассмотрели основные действия злоумышленника, осуществляемые для сбора информации в открытых источниках о внешнем периметре организации, а также для поиска адресов корпоративной электронной почты. Последние могут быть использованы преступником для заражения внутренних систем компании вредоносным ПО, однако для этого необходимо, чтобы зловредное письмо было хотя бы открыто. Что же сделает киберпреступник, если этого не произойдет? Отступит? Нет, подойдет к делу более целенаправленно.

На текущий момент, практически любой человек имеет профиль в популярных социальных сетях: Facebook, ВКонтакте, Twitter или Instagram. Такие аккаунты являются ценным источником информации о работе, увлечениях, характере и ближайшем окружении людей. Для формирования более целенаправленного письма, для вызова эмоционального отклика у адресата и, как следствие, для повышения шанса открытия вложения злоумышленники нередко используют открытые данные о работниках целевой компании.

Отправной точкой для поиска личных данных сотрудников является официальный сайт организации, а именно разделы «Контакты», «О нас» и т.д. Опять же, администраторы зачастую оставляют свою контактную информацию при регистрации доменных имен или при оформлении сертификата (см. часть 1).

Поиск информации обычно производится при помощи универсальных поисковых движков, например, Google, Yandex и т.д.

Или, как вариант, при помощи возможностей социальных сетей.

В «Друзьях», выявленных сотрудников целевой компании, всегда найдется парочка коллег. Также всегда существует вероятность, что человек оставил раскрытой дополнительную контактную информацию, например, адрес личной электронной почты, номер телефона или ссылки на другие социальные сети.

Помимо самих данных пользователя, представленных в аккаунте, злоумышленника интересуют используемые логины, никнэймы, номера и другие идентификаторы, по которым можно продолжать поиск на других ресурсах: к примеру, по никнэйму администратора можно найти его репозиторий на Github или аккаунт в LiveJournal, где он рассказывает о специфике работы корпоративных серверов или делится мнением о том, какие пароли лучше использовать.

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

Для того, чтобы проверить не стали ли Ваши данные достоянием интернет-общественности, как нельзя лучше подходит агрегатор утечек haveibeenpwned.com. Вводим почтовый ящик в строку поиска и получаем список утечек, содержащих указанный адрес.

В целях автоматизации описанных действий по поиску информации в открытых источниках, создаются мощные фреймворки для OSINT, например, Maltego, Lampyre и Datasploit. Правда, часть из них являются платными, а для своей работы они требуют множество API-ключей, чтобы подключаться к различным ресурсам.

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

Если и это не помогло: отправленные письма заблокированы спам-фильтром и антивирусом, а все обнаруженные пароли уже давным-давно изменены, — то в таком случае, крайне целеустремленный злоумышленник может попытаться «подобраться поближе». Об этом расскажем в следующей части.

Текст: команда Origin Security

Ссылка на источник статьи

Показать полностью 3

[моё] IT Полезное Интернет Osint Поиск Хакеры Фишинг Информационная безопасность Социальные сети Длиннопост

Отличная работа, все прочитано!

4 5 6 7 8 9 10 11 12 13 14 20 30 40 50 100

Информационная безопасность IT

Популярные теги в сообществе: