originsecurity

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

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

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

Недостатки работы без единой парадигмы:

• Периметровый принцип защиты

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

• Игнорирование социального фактора

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

• Ошибочная модель злоумышленника

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

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

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

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

Парадигмы в обеспечении информационной безопасности

• Предположение о проникновении (assume breach, assume compromise)

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

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

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

Парадигма «предположение о проникновении» основывается на:

1. аутентификации и непрерывной проверке;

2. гранулярном контроле доступа;

3. постоянном аудите доступа;

4. отсутствии безусловного административного доступа;

5. подходах just-in-time (предоставление привилегированного доступа строго на определенное время) и just-enough (предоставление минимальных необходимых прав) в выделении административного доступа.

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

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

Жить спокойно в парадигме предположения о проникновении получится только со «здоровой» инфраструктурой, в которой:

• нет типовых «болячек»;

• проведены оценка и ранжирование критичности ресурсов;

• осуществляется непрерывный мониторинг;

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

Это и есть парадигма «Assume compromise», позволяющая эффективно находить нарушителя, противостоять его действиям и минимизировать среднее время пребывания злоумышленника в сети и вероятность совершения недопустимых событий.

• Принцип наименьших привилегий (principle of least privilege)

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

Проблема привилегий заключается в устоявшейся практике их избыточного предоставления. Объяснить её проще всего на примере. Нередко злоумышленники находят учетную запись администратора домена в памяти того же хоста, который и являлся точкой входа в сеть. Если нет, то с высокой вероятностью поможет техника pass-the-hash: учетная запись с желаемыми привилегиями обнаружится в памяти одного из соседних компьютеров.

Можно предположить, что корнем проблемы здесь является уязвимость систем к упомянутой выше технике. Допустим, атаки pass-the-hash в инфраструктуре будут исключены. В таком случае злоумышленник сменит тактику действий, но не стратегию: вместо кражи аутентификационных данных из памяти устройства он установит кейлоггер (программу, считывающую нажатия клавиш) и все равно перехватит вводимый пользователем пароль. Суть проблемы на самом деле заключается в административных привилегиях скомпрометированной учетной записи, которые ей абсолютно не нужны.

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

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

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

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

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

1. внедрение надежной парольной политики и многофакторной аутентификации;

2. защита учетных записей локального администратора;

3. контроль использования сервисных учетных записей;

4. защита привилегированных групп пользователей;

5. управление привилегированным доступом (PIM, PAM и т.д.);

6. контроль доступа на основе ролевой модели (RBAC).

• Нулевое доверие (zero trust)

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

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

В различных источниках подчеркивается, что основой парадигмы нулевого доверия является концепция устранения периметра сети. Однако далее в них принципы нулевого доверия описываются на тех или иных проявлениях периметра (микросегментация, микропериметры), что в какой-то степени противоречит первоначальной идее. Такое несоответствие можно объяснить только тем, что нулевое доверие – всего лишь парадигма. Её постулаты являются идеальной целью, но не все они могут быть полностью реализованы в чистом виде в конкретной инфраструктуре. Поэтому мы опишем основные постулаты нулевого доверия по принципу «что должно быть включено», а не «чего быть не должно».

Архитектура нулевого доверия разрабатывается и внедряется с соблюдением следующих основных принципов (постулатов):

1. Все данные и сервисы считаются ресурсами.

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

2.  Любой доступ проходит процедуру проверки независимо от местоположения сегментов сети.

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

3.  Сессионный режим доступа к ресурсам предприятия.

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

4.  Решение о доступе к ресурсам принимается по результатам комплексного анализа всех имеющихся параметров.

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

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

Решение о доступе принимается на основе допустимого уровня риска для бизнес-процессов организации и может отличаться в зависимости от чувствительности запрашиваемого ресурса/данных.

5.  Организация контролирует и измеряет целостность и безопасность всех принадлежащих активов.

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

Условно выделяются разные состояния активов, например:

• устройства, находящиеся в безопасном состоянии;

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

• активы, не управляемые организацией;

• устройства в личной собственности работников.

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

6.  Аутентификация и авторизация ресурсов происходит динамически и строго до того, как будет предоставлен доступ. Процесс сканирования, поиска и исследования угроз, адаптации и переоценки доверия происходит непрерывно.

Инфраструктура, внедряющая нулевое доверие, должна иметь систему управления идентификацией, учетными записями и доступом (Identity, Credential, and Access Management (ICAM). Это позволит обеспечивать постоянный мониторинг доступа с возможностью требования повторной аутентификации в ходе операции пользователя (например, по времени, новому запрашиваемому ресурсу, изменению статуса ресурса, обнаружению аномальной активности субъекта). В организации должна быть принята политика предоставления доступа, которая обеспечивает проведение такой проверки,  и при этом стремится к достижению баланса безопасности, доступности и удобства использования активов.

7.  Постоянный анализ состояния всей инфраструктуры.

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

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

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

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

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

• «Число кибератак в 2022 г. выросло в три раза» — Group-IB;

• «В целом за 2022 год количество кибератак на российские компании выросло в 2 раза» — Ростелеком-Солар;

• «Общее количество инцидентов в 2022 году увеличилось на 20,8%» – Positive Technologies.

Руководители больших и маленьких компаний все чаще начинают задаваться вопросом: «А у нас все защищено?». И случается, что в ответ специалисты IT-службы пожимают плечами и стыдливо отводят глаза в сторону. Или нарочито громко заявляют: «По-другому и быть не может!», хотя в головах витает мысль: «Без понятия…».

Задача обеспечения информационной безопасности компании — не тривиальная. Есть несколько подходов к ее решению:

1. Метод «Неуловимого Джо».

«По сравнению с Microsoft и Google мы мелкие, а значит, нас никто не будет атаковать. Следовательно, и вкладываться в инфобез не нужно. Тем более он денег не приносит». Приблизительно такая логическая цепочка выстраивается в голове у многих владельцев бизнеса. Этот подход к ИБ львиной доли организаций понятен, и оспорить его сложно. Но можно. Проблема в том, что он не отвечает современным угрозам безопасности.

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

2. Добавление задач IT-службе.

«Вроде бы и там и там компьютеры – значит, справятся». Да, и IT, и ИБ — это все про компьютеры, но подход к ним у каждой службы разный.

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

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

3. Создание собственной ИБ-службы и поручение ей задачи обеспечения ИБ.

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

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

Аутсорсинг — это передача организацией определенных функций (в данном случае — функции обеспечения информационной безопасности) на исполнение другой компании. Может передаваться вообще все («Сделайте нам красиво!»), а могут конкретные процессы или задачи: настройка средств защиты информации, мониторинг событий информационной безопасности, поддержание в актуальном состоянии документации и прочие.

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

В аутсорсинге информационной безопасности есть множество плюсов:

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

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

3. Быстрее. Все процессы у подрядчика уже отработаны – остается только внедрить.

4. Профессиональнее. Аутсорсинг дает возможность доступа к широкому спектру компетенций. У ИБ-аутсорсера их явно больше, чем у одного штатного сотрудника. Также не стоит забывать о глубине экспертизы и широте опыта, которые нарабатываются годами в профильных компаниях.

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

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

1. Зависимость от поставщика услуг. В случае разрыва договора компания может остаться без защиты. Нивелируется заблаговременной проработкой процесса смены компании-аутсорсера.

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

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

Что же останавливает компании от передачи ИБ на аутсорсинг? Возражения и страхи, вызванные, как правило, отсутствием опыта работы с адекватным и профессиональным подрядчиком и неактуальные на практике:

• «Это дорого!». Выше уже упоминалось, за счет чего аутсорсинг выигрывает у штатной команды в стоимости. Добавим немного конкретики: вы не организуете рабочих мест для персонала, не платите им премий, не посылаете их на учебу, не платите за них налоги. Да, все эти издержки заложены в стоимость услуг аутсорсера, но они распределяются между множеством заказчиков. В итоге получается дешевле. По мнению компании Инфосистемы Джет, аутсорсинг дешевле штата в среднем на 20-30 %, а в некоторых случаях и на 50 %.

• «Невозможно полноценно оценивать все процессы, точно ли аутсорсеры справятся как надо». Вопрос доверия — краеугольный в сфере ИБ. Но точно также невозможно оценить врача, который вас лечит, или педагога, который вас учит. Для того, чтобы быть уверенным в подрядчике, следует основательно подойти к вопросу его выбора. Найти надежную компанию, которой доверяете как себе, бывает нелегко, но эта игра стоит свеч.

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

• «Исполнитель не подчиняется напрямую, из-за этого теряется оперативность». Для выполнения задач под управлением штатных сотрудников есть свой вид аутсорсинга — аутстаффинг. Вы покупаете время специалиста, и он подчиняется вам напрямую – никаких потерь драгоценного времени.

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

• «Аутсорсеры делают небезопасные удалёнки». Тут сама формулировка намекает: если подрядчик ИБ устанавливает небезопасные удаленные подключения, он этим расписывается в своей профнепригодности. Следует отказаться от его услуг и искать проверенную компанию.

• «Постоянно отвлекают наших штатных IT-шников». Это убеждение опровергнуть сложнее всего, ибо процесс обеспечения ИБ действительно тесно связан с ИТ. И как бы противоречиво это не звучало – информационную безопасность обеспечивают в первую очередь сотрудники службы ИТ. Специалисты ИБ занимаются контролем и выработкой мер, которые внедряют ИТ. Можно сказать, что безопасники – голова, а администраторы – руки единого организма, обеспечивающего информационную безопасность систем компании. Так что, увы – без «отвлекания айтишников» ничего не получится. Но точно также будет работать и ваш собственный специалист ИБ. Получается, это возражение касается не столько аутсорсинга, сколько работы службы ИБ в принципе.

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

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

Текст: Аделина Любимова, Origin Security

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

Большая часть компьютерных атак становятся успешными благодаря социальной инженерии. Ежедневная рутина сопровождается прочтением десятков писем, среди которых легко пропустить единственное «поддельное».
Мы провели более 20 успешных проверок, в которых использовалась социальная инженерия. Раз за разом один результат – удивление и фраза «мы знали о таком, но сами не видели». Банальные и базовые ошибки в работе сотрудников и недоумевающий взгляд администраторов.
Таким образом, получилось сформулировать задачу – наглядно указать, на что обратить внимание в ежедневной работе, чтобы не стать жертвой таких атак.

Кому и как это использовать?

• Администраторам и специалистам по ИБ – пожалуйста, используйте материал как брошюру для обучения сотрудников. Информация для вас лично указана отдельной сноской.

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

Общие правила при прочтении писем

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

Мы получили следующее письмо:

Предупреждения на этапе прочтения письма

Предупреждения почтового клиента – это не нормально:

Это еще не делает письмо фишинговым, но обязано насторожить.

Важно!

Такие предупреждения – один случай на сотню. В большинстве случаев никаких предупреждений не будет:

Адрес отправителя

Мы знаем, что наш почтовый адрес — zubilin@originsecurity.ru.
Адрес отправителя — originsecurity@mailer.xyz.

Первое правило:
ВСЕ, что написано ДО знака «@» – неважно!
Письмо отправили не ваши коллеги, если есть различие хоть в одном символе после знака «@».
Такое письмо необязательно фишинговое, но уже нельзя слепо верить написанному, сразу же открывать вложения и переходить по ссылкам.

Важно!

originsecurity.ru и 0riginsecurity.ru, например, являются разными именами. Злоумышленник использует такие способы маскировки, как: замена буквы «о» на цифру «0» или буквы «l» на цифру «1», две буквы «rn» на одну «m» и наоборот и т. д.

Как видно – письмо отправили не сотрудники финансового отдела, как написано в тексте. После «@» имя другого предприятия. Это уже повод обратиться в отдел информационной безопасности или к другому администратору, который подскажет куда обратиться и что сделать.

Для администраторов и специалистов ИБ:

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

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

Далее.

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

Подпись отправителя

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

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

Вложение в письме

Если на компьютере установлен антивирус – это ни в коем случае не защищает вас на 100%.
Внимательность – лучшее средство защиты.
Следующая задача – посмотреть на имя файла вложения:

Формируем новое правило:
Важно только то, что написано после ПОСЛЕДНЕЙ точки.

Мы указали только популярные форматы. Если файл вызывает подозрения, то лучше перестраховаться и получить рекомендацию администратора.

Для администраторов и специалистов ИБ:

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

В подготовке правил фильтрации почтовых вложений помогут уже существующие наработки. Так, автор Oletools собрал в одном месте расширения исполняемых файлов (https://github.com/decalage2/oletools/blob/master/oletools/rtfobj.py, 280 строка).

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

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

Документы Microsoft Office

Если потенциальному злоумышленнику удалось убедить вас открыть документ Microsoft Office – запомните еще одно простое правило:
Если источник недоверенный, как бы вас не просили – НИКОГДА не нажимайте на кнопку
сверху. На любую кнопку сверху.
Ни «Разрешить редактирование», ни «Включить содержимое», ни что-либо еще.
Формулировка на таких кнопках не передает сути и масштаба угрозы. Равносильно кнопке «Заразить компьютер».

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

Для администраторов и специалистов ИБ

Мы не рассматриваем сценарии, когда атака направлена на эксплуатацию уязвимостей MS Office. Ведь у ваших сотрудников установлена актуальная версия ПО и автоматическим его обновлением занимается сервер WSUS.

Ссылки в тексте

Просьба перейти по ссылке и ввести свои данные – главное оружие в фишинге.

Вы переходите по ссылке в письме и видите сайт вашего предприятия.

Первое, что мы проверим – соответствие адреса сайта в адресной строке адресу сайта вашего предприятия:

Внимание на строку, отмеченную красным. Строчка, отмеченная зеленым ничего не значит. Злоумышленник способен написать там что угодно!

Различие хоть в одном символе сигнализирует об опасности сайта (сайт-оригинал goSuslugi.ru, в примере же ссылка на goZuslugi.ru) – закрываем сайт и обращаемся к администратору.

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

Замочек возле сайта

Иллюзию безопасности сайта создает замочек возле него (обычно зеленый или серый).
Запомните раз и навсегда:
Никакой замочек возле сайта не является гарантией безопасности!
Важен только адрес сайта. Ничего больше.

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

Виды почтовых атак. Фишинг целевой

Это случай, рассмотренный ранее:

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

Для администраторов и специалистов ИБ

При обнаружении таких писем собственноручно или при получении информации от сотрудника рекомендуется:

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

2. Определить получателей писем по фишинговому почтовому домену;

3. Если масштабы проблемы ограничены несколькими получателями, лично обсудить рассылку (кто что открыл, куда перешел и т.д.);

4. Заблокировать утекшие учетные данные при их наличии;

5. Добавить домен в черный список на почтовом сервере или средстве защиты;

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

Виды почтовых атак. Фишинг массовый

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

Виды почтовых атак. Вейлинг

Фишинговые атаки на конкретного человека на предприятии. Крайне тщательно подготовленные вредоносные вложения и тематика. Злоумышленник изучает жертву, либо знает о деятельности жертвы (направляет фишинговое письмо на тему закупок по адресу zakupki@originsecurity.ru, например).

Для администраторов и специалистов ИБ

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

Виды телефонных атак. Вишинг

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

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

Злоумышленник может заговаривать зубы и даже угрожать (увольнением, лишением премии и т.д.). Кладите трубку с фразой: «Я не могу обсуждать это по телефону, всего доброго». И заявляете о своих подозрениях специалистам информационной безопасности или администраторам. Никаких претензий или штрафных санкций к вам после такого заявления не может быть применено.

Для администраторов и специалистов ИБ

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

Виды физических атак. Подбрасывание носителей информации

Подобранные (на территории предприятия или в домашнем подъезде, неважно) носители информации (флеш-карты памяти, диски и т.д.) запрещено подключать к компьютерам предприятия.
Популярная атака – раскидать флешки (или что проще – диски, подписанные «Зарплата кадры 2023») по периметру предприятия, в надежде на любопытство жертвы. Сразу при подключении такого носителя компьютер заражается, и злоумышленник проникает в сеть.

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

Для администраторов и специалистов ИБ

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

Виды физических атак. Подключение носителей информации сторонними лицами

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

Заключение

В заключении сформулируем еще одно, последнее правило:
Не пересылайте потенциально опасный документ коллегам!
Обычно это происходит со словами: «У меня не открывается, попробуй ты». Мы сталкиваемся с такой инициативой на каждом третьем аудите. Будьте внимательней.

То, что на первый взгляд кажется объемным справочником – на деле перечень простых правил, которые помогут распознать большинство атак с использованием социальной инженерии.
Даже если вы попались на уловку злоумышленника, сообщили какую-либо информацию, открыли документ или ввели учетные данные – ОБЯЗАТЕЛЬНО сообщите об этом в отдел информационной безопасности или администраторам. Таким образом вы снимите с себя ответственность, а специалисты смогут быстро отреагировать и не дать злоумышленнику использовать полученную информацию.

Для администраторов и специалистов ИБ

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

Чтобы ничего не забыть, сделали для вас плакат-напоминание. Печатаем, вешаем на стену,
пользуемся. Оригинал по ссылке

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

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

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

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

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-адресам:

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

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

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.2. Отображение пароля

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

П.1 Указа

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

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

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

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

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

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

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

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

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

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

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

✧ субъектов КИИ, кроме ИП, а также всех указанных ОИВ, ОГВ, госфондов, корпораций, предприятий (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. Федеральной службе безопасности Российской Федерации:

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

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

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

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

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

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

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

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

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

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

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

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