Сегодня предлагаем к рассмотрению новую модель смарт-карт ридера JCR721 производства"Аладдин Р.Д.".JCR721 профессиональный отечественный доверенный смарт-карт ридер для работы со смарт-картами в корпоративной среде, имеет привычный вид дляEnterprise-сегмента.

Немного о полезных свойствах и корпусе

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

Смарт-карта погружается плавно за счёт специального механизма микролифт^TM, благодаря которому смарт-карт ридер не царапает поверхность карты.

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

В случае с карт-ридеромJCR721 контактная площадка остаётся невредимой даже после 10 тысяч подключений.

Так выглядит карта и контактная площадкапосле 1 000подключений на обычном ридере со скользящими контактами

Так выглядит карта и контактная площадкапосле 10 000подключений на ридере JCR721 с механизмом микролифт^TM

Отметим, что ресурс карт-ридераJCR721 не менее 200 000 подключений смарт-карт (вместо50000).

Внешний вид и подключение

Смарт-карт ридерJCR721 имеет пластиковый корпус, шнур для подключения к персональному компьютеру. Разъём шнура для подключения стандартныйUSB2.0Type-A. Для корректной работы на ПК требуется хотя бы один свободный порт USB 2.0 Full-speed (12 Мбит/с), ридер также может работать с USB 1.1, 2.0, 3.0, 3.1. Необходимо обеспечить подачу электропитания 5В 0.25В при токе 300 мА, которое должно обеспечиваться исправным USB-портом (USB 2.0). Для стабильной работы требуется подключение к ПК, не используя дополнительные переходники, можно использоватьUSB-хабы с внешним источником питания, но еслиUSB-хаб не имеет внешнего источника, то этого может быть недостаточно для работы ридера, т.к. сам по себеUSB-хаб обеспечивает менее 100мАна порт.

Также ридерJCR721 имеет и шнур для подключения к современным ноутбукам и портативным устройствам, имеющим разъемUSB3.1Type-C.

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

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

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

Можно отметить, учитывая все эти параметры, что ридер предназначен для интенсивного использования с любыми типами контактных микропроцессорных смарт-карт. Поддерживает работу с любыми контактными смарт-картами (MCU) стандарта ГОСТ Р ИСО/МЭК 7816-3-2013 Class A, B, C (5V, 3V, 1.8V) по протоколам Т=0/Т=1. Может использоваться в системах ГИС, АСУ ТП, для обеспечения безопасности персональных данных 1-го уровня защищённости, на предприятиях КИИ (критической информационной инфраструктуры), в госорганах, на предприятиях ОПК, Министерства Обороны, в банках, многофункциональных центрах (МФЦ), офисах обслуживания, в проектах типа "Электронное удостоверение", "Электронное правительство", "Электронное декларирование" и многих других.

Компания "Аладдин Р.Д." заявляет, что ридер является доверенным средством работы с данными пользователя, которые хранятся или будут храниться на смарт-картах. Ридер спроектирован по новым Требованиям доверия ФСТЭК России, в том числе для работы с гостайной.

Если рассматривать ридер для поддержки Memory-карт, работавшими по протоколам I²C (S=8), 3-wire(S=9), 2-wire(S=10), картами-счётчиками, ранее применявшимися в "телефонных картах", то на данном этапе этой поддержки нет.

Ещё немного о преимуществах нового смарт-карт ридера JCR721

Ридер очень быстрый, поддерживает все современные смарт-карты, реальная подтверждённая скорость обмена данными со смарт-картой до 625 Кбит/с. Быстродействие ридеров при работе со смарт-картой зависит от нескольких факторов. Фактор 1 скорость обмена с хостом (ПК) по интерфейсу USB 2.0., а также фактор 2 тактовая частота, подаваемая ридером на смарт-карту.

В большинстве ридеров эта частота, фиксированная (как правило, 4 МГц). Некоторые ридеры могут подавать различные частоты из фиксированного перечня (указывается в функциональном дескрипторе CCID-устройства). Смарт-карт, работающих на частоте выше 5 МГц, практически нет, поэтому чем выше частота, подаваемая ридером на смарт-карту, тем больше шансов, что данный ридер будет несовместим с большинством имеющихся на рынке смарт-карт. Стоит различать скорость обмена данными со смарт-картой и скорость при работе со смарт-картой. Последняя складывается из времени отправки команды на смарт-карту, времени обработки команды смарт-картой и времени передачи ответа от смарт-карты на ПК.

Работает смарт-карт ридер JCR721 со всеми современными операционными системами, включая Linux (со всеми российскими дистрибутивами), macOS, ОС "Эльбрус", МС ВС, Android, Sailfish/Аврора, на процессорах IA-32, IA-64, x86-64, ARM, Эльбрус, Байкал и на Microsoft Windows. Также ридер может быть подключен к ПК, где используются средства виртуализации, такие, как Hyper-V, Citrix XenServer, Virtual Box, VMWare и др.

Для работы ридера JCR721 не требуется установки специального прикладного ПО, работа ведётся через стандартные программные интерфейсы PC/SC, является CCID-совместимым устройством, не требует установки специальных драйверов и работает сразу при подключении к USB-порту компьютера (Plug and Play).

Нужно отметить, что в современных версиях ОС Windows, Linux, macOS, МС ВС, "Эльбрус", Android8 (Oreo), Sailfish Mobile при подключении ридер в системе должен определиться автоматически, при этом на его корпусе должен загореться зелёный индикатор. В этих операционных системах для работы уже существует предустановленный CCID-драйвер и входит в состав данных операционных систем. А вот для работы с операционными системами версий Microsoft Windows XP SP3 CCID-драйвер может быть установлен администратором из "Каталога Центра обновления" Microsoft при первом подключении к рабочей станции. Также для архитектуры X86, CCID-драйвер можно скачать по ссылке:http://catalog.update.microsoft.com/v7/site/ScopedViewRedirect.aspx?updateid=8e217a56-9ed7-456b-aee8-674c5c7bcdbe

Актуальный список поддерживаемых ОС, гипервизоров, виртуальных сред и процессоров можно узнать на продуктовой странице сайта Производителя https://www.aladdin-rd.ru/catalog/readers/JCR-721

Но вот если ридер автоматически не определился в системе, то одной из возможных причин может быть использование устаревших версий ОС или версий Firmware ("прошивок") терминального оборудования. Для устранения проблемы следует прописать указанные VID/PID в Info.plis и/или обратиться с этой проблемой к производителю ОС или терминального оборудования.

Идентификатор класса устройств USB: 0x0B

VID (Vendor ID): 0х24DC

PID (Product ID): 0х0428

Для Astra Linux 1.4, Astra Linux 1.5 и МС ВС 3.0 подсистема поддержки работы со смарт-картами PC/SC и CCID-драйвер перед первым использованием ридера должны быть установлены на рабочую станцию администратором, согласно инструкциям для определённого типа операционных систем. Работа ридера в этих ОС "из коробки" не гарантируется.

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

Итак, производитель заявляет следующий ряд характеристик:

- Климатическое исполнениеустройства: группа 1.1 УХЛ-4

- Температура эксплуатации: +2510С

- Относительная влажность воздуха: от 40% до 60%

- Атмосферное давление: 96 кПа - 103 кПа (720 - 770 мм рт. ст.)

Предельными условиями эксплуатацииявляются параметры:

- Температура: от 0С до +70С, при температуре воздуха выше +30С влажность не должна превышать 70%

- Относительная влажность воздуха: до 80%, без конденсата

- Атмосферное давление: 84 кПа - 106,7 кПа (630 - 800 мм рт. ст.)

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

Ридер безопасен для здоровья человекаи соответствует требованиям Единых санитарно-эпидемиологических и гигиенических требований к товарам, подлежащим санитарно-эпидемиологическому надзору. Сертификат соответствия можно найти на сайте производителя во вкладке "Доп. ресурсы"https://www.aladdin-rd.ru/catalog/readers/JCR-721.

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

Небольшое сравнение ридера JCR721 с ближайшими аналогами

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

Качество контактной группы, её ресурс:

Поддержка различных типов карт:

Безопасность и доверие:

Немаловажно отметить, что цена для ридера адекватна для больших проектов.

Цена взята с сайта рассматриваемых поставщиков в России посостоянию на 14 октября 2020 г.

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

Потребность в оценке защищенности ИТ-инфраструктуры появилась практически одновременно с компьютерными системами. В 50-е годы прошлого столетия ученые начали предполагать, что на компьютерные системы возможны атаки, а в 1988 году Робертом Моррисом младшимбыл создан первый массовый сетевой червь, который по скромным оценкам нанес ущерб в 96 млн долларов. Тогда общественность всерьез задумалась над угрозой компьютерных атак.

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

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

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

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

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

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

Поэтому среди экспертов ИБ так популярны соревнования Capture the Flag (CTF). На CTF-площадках участники могут искать уязвимости в сервисах и использовать их для развития векторов атак на другие команды без негативного влияния на бизнес-функции компаний. Кроме того, эти соревнования отличный способ обучения экспертов ИБ (исследователей, пентестеров, участников Red Team и Bug Hunter). И если раньше бизнес не относился серьезно к CTF, считая это лишь развлечением, то сейчас мы видим, что многие общепризнанные эксперты ИБ, которые теперь занимают высокие должности, когда-то принимали участие в CTF. Правда, соревнования за более чем 20-летнюю историю преобразились.

До 2010 года CTF-соревнования были далеки от реальной жизни и инфраструктуры, уязвимости искусственны, а результат игры неприменим для бизнеса. Есть два формата проведения CTF:

• Task-based, в котором требуется решать отдельные задачи и получать очки за правильные ответы (флаги).

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

Во время соревнований участники отрабатывают навыки быстрого поиска и закрытия уязвимостей, они учатся работать в команде, развиваются как эксперты. Сегодня работодатели приветствуют опыт в CTF как для пентестеров, так и для специалистов службы ИБ и SOC. Компании даже сами устраивают соревнования, например Trend Micro с 2015 года, Google с 2016 года. Кроме того, появились публичные программы bug bounty, в которых любой желающий может протестировать сервисы и продукты известных компаний и получить денежное вознаграждение за выявленные уязвимости. Так, за zero-click-уязвимость с исполнением кода на ядре компания Apple готова заплатить 1 млн долларов.

В 2010 году НАТО впервые провела открытые соревнования Locked Shields, в которых столкнулись Red Team (атакующие) и Blue Team (защитники). С 2001 года подобные соревнования под названием Cyber Defense Exercise проводило Агентство национальной безопасности США, но только для учащихся военных академий США. Формат таких соревнований не похож на CTF, это киберучения, эмулирующие реальный мир. В киберучениях применяются ИТ-системы, выполняющие бизнес-процессы, присущие реальным компаниям. Так, в декабре 2020 года Европейское агентство по сетевой иинформационной безопасности(ENISA) проведет Cyber Europe 2020, в котором организаторы смоделируют сценарии, касающиеся здравоохранения.

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

С появлением киберполигона The Standoff у сообщества появилась среда для моделирования кибератак, оценки значимости ресурсов и реализуемости рисков на цифровом макете реального города. В инфраструктуру города заложены живые бизнес-сценарии нефтяной компании, ТЭЦ, подстанции, химического завода, аэропорта, банка, железной дороги, морского порта, а значит, участники столкнутся с настоящим оборудованием и сервисами, используемыми в этих компаниях. The Standoff это уникальная возможность довести вектор атаки до конца и посмотреть, к чему это приведет: будет ли украден миллиард и надолго ли останется город без электричества после выхода из строя паровой турбины ТЭЦ. При проектировании The Standoff были использованы реальные контроллеры, которые используются на идентичных объектах критически значимой инфраструктуры, а значит, у экспертов ИБ есть возможность протестировать сценарии атак до конца. Если атака будет успешной и электростанция остановится, значит, она остановилась бы и в реальной жизни.

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

Изучить киберполигон The Standoff вживую вы сможете уже завтра 12 ноября. The Standoff стартует в онлайн-формате и продлится в этом году целых шесть дней. Помимо активностей, связанных с кибер-битвой, вы сможете послушать доклады лучших экспертов в области практической кибербезопасности со всего мира: более 30 спикеров из России, США, стран Европы и Азии поделятся с вами своими последними наработками. Для участия в мероприятии достаточно лишь подключиться к онлайн-платформе.

Автор: Ольга Зиненко, аналитики информационной безопасностиPositiveTechnologies

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

1. Обучение пользователей основам ИБ. Борьба с фишингом.

2. Обучение пользователей основам ИБ. Phishman.

3. Обучение и тренировка навыков по ИБ. Антифишинг.

Сводка с полей

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

Например, вендор Check Point в одном из своих отчетов сообщает, что только в ноябре 2020 года - количество фишинговых кампаний увеличилось более чем в 2.5 раза по сравнению с октябрем 2020 года.

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

Разбор атаки

Тема письма: Cyber Monday | Only 24 Hours Left!

Отправитель: Pandora Jewellery (no-reply\@amazon.com)

Содержимое:

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

• Рассылка с домена Amazon является подменой с применением механизма spoofing.

• Ошибка в слове Jewellery в теме письма. (прим. корректное написание - jewelry).

• Если попытаться перейти на сайт по ссылке в письме, то открывается URL: www[.]wellpand[.]com. Сам сайт был зарегистрирован как раз осенью 2020 года и имитирует содержимое оригинального сайта компании Pandora.

Именно эта массовая фишинг-атака была адресована пользователям из США, Англии и Болгарии, но в целом такой подход используется по всему миру. Какие шаги можно предпринять, чтобы ваши покупки на новогодние праздники не закончились обманом ?

1. Бесплатный сыр бывает только в мышеловке. При покупке того или иного товара нужно объективно оценивать его стоимость, например, если вам предлагают новый Iphone со скидкой 80%, скорее всего, это обман.

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

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

4. Социальная инженерия важна. Обращайте внимание на стиль написания полученного письма (синтаксические и орфографические ошибки и прочее).

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

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

Обзор решений

Ранее мы познакомили вас с некоторыми продуктами из категории Security Awareness Computer-Based Training, в том числе с Open-source решением GoPhish и отечественными продуктами: Phishman, Антифишинг. Пришло время обратиться ко всем известному Gartner и кратко ознакомиться с топ-5 (в рамках статьи был выбран регион Europe, Middle East And Africa, от 1 к 5).

KnowBe4

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

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

1) Выбор теста

2) Конфигурация обучающей кампании фишинга

3) Выбор шаблона для рассылки

5) Настройка страницы для переадресации "жертв"

6) Панель мониторинга и сбора статистики

Общее впечатление:

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

Kaspersky-Cybersecurity Awareness Training

Платный продукт от широко известной для российской публики компании - Лаборатория Касперского.

Его отличие от других решений в том, что обучение подготовлено для самих IT-специалистов в рамках которого рассматривается :

• Цифровая криминалистика. Формирование и улучшение практических навыков поиска цифровых улик киберпреступлений и анализа различных типов данных для восстановления хронологии атак и определения их источников.

• Анализ вредоносного ПО. Подготовка специалистов по IT-безопасности анализировать вредоносное ПО, находить индикаторы компрометации (IoC), создавать сигнатуры для обнаружения вредоносного ПО на зараженных компьютерах и восстанавливать зараженные и зашифрованные файлы.

• Реагирование на инциденты.

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

Общее впечатление:

Данный сервис как платформа позволит вашим сотрудникам обучаться противостоять наиболее актуальным и современным типам атак. Решение требует определенного уровня подготовки и наличия навыков в IT, в том числе ИБ. Активно используется большими компаниями (банки, промышленность и т.д.).

OutThink Human Risk Management Platform (SaaS)

Платный продукт позиционирует себя как результат долгих исследований в Security Group (ISG), Royal Holloway, University of London. Эксперты компании суммарно имеют опыт более 100 лет в ИБ, науке о поведении человека, психологии и Data Science.

Общее впечатление:

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

Infosec IQ

Платное решение от Европейской компании LX Labs, который предлагают более 700 ресурсов для обучения персонала, более 1000 шаблонов для симуляции фишинг-сообщений и удобный интерфейс для взаимодействия.

Общее впечатление:

Прост, масштабируем и эффективен - так один из заказчиков отзывается о продукте на сайте Gartner. Если говорить о технической стороне вопроса, то отмечается удобная интеграция с AD (Active Directory), простой запуск фишинговых кампаний, поддержка быстрого перехода к статистике через кнопку управления в Outlook. Если вас заинтересовало решение, то вы можете запросить демо у вендора по ссылке.

Keepnet Labs

Одноименный вендор предлагает различные решения в области ИБ:

• Incident Responder. Позволяет пользователям отправлять на проверку подозрительные email-сообщения, после чего они могут блокироваться на постоянной основе.

• Email threat simulator. Решение позволяет периодически проверять вашу инфраструктуру (файрволл, антиспам, антивирус и т.д.) на уязвимости в настройках, благодаря которым могут пройти атаки в рамках фишинга.

• Threat Intelligence. Умный движок постоянно изучает сайты на предмет их взлома или утечки информации с целью выявить компрометацию ваших персональных корпоративных данных.

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

• Awareness Educator. Обучающий портал, который может быть интегрирован в Phishing Simulator.

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

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

Общее впечатление:

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

Вместо заключения

Сегодня мы рассмотрели один классический праздничный пример фишинг атаки и кратко познакомились с мировыми лидерами в области Security Awareness Computer-Based Training, под постом будет запущено голосование о приглянувшемся для вас продукте, возможно сделаем на него полноценный обзор. Почитать и протестировать решения (GoPhish, Phishman и Антифишинг) вы можете обратившись к нам на почту.

Привет! Завершаем год традиционным дайджестом классических и нетривиальных ИБ-инцидентов, о которых писали зарубежные и российские СМИ в декабре. Нас лично впечатлило, как создатели Чёрного зеркала предсказали свои собственные проблемы. А вас?

У них

Оживший сюжет

Что случилось: Одна из крупнейших продюсерских студий мира EndemolShine, которая создает и распространяет телешоу Большой брат и Голос (в Нидерландах), а также сериал Чёрное зеркало, столкнулась с вымогателями.

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

По сообщениям СМИ, среди скомпрометированных файлов есть доказательства того, что деятельность Endemol не полностью отвечает требованиям Общего регламента о защите данных (GDRP). А это грозит фирме серьезными штрафами.

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

Страховка от утечки

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

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

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

Слив по бразильской системе

Что случилось: Журналисты газеты Estadao обнаружили логин и пароль к базе данных Министерства здравоохранения в исходном коде сайта ведомства. Просмотреть его мог любой, просто нажав F12 в своем браузере. Эти данные позволяли получить доступ к SUS (Sistema nico de Sade), официальной базе Минздрава Бразилии, в которой хранится информация о 243 млн граждан (в том числе, умерших) полное имя, домашний адрес, номер телефона, медицинские сведения.

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

По иронии судьбы, это уже второй в стране ИБ-инцидент с медицинской информацией за последнее время. В прошлом месяце по схожей причине в Бразилии утекли данные 16 млн пациентов с COVID-19. Похоже, госсектор+персданные опасная смесь не только для России.

У нас

Адрес смерти

Что случилось: В Павловском районе Нижегородской области осудили очередных участников тандема полицейский + ритуальщик.

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

Скучающий торговец

Что случилось: ИБ-специалист телеком-компании в подмосковном Реутове засек подозрительные обращения в корпоративную базу с персданными клиентов. Кто-то обращался к ней трижды с перерывом в несколько дней.

Кто виноват: Нарушителем оказался менеджер по работе с клиентами. По словам сотрудника, он зашел в систему от скуки на фоне отсутствия покупателей. При этом сфотографировал данные 14 абонентов, что позднее подтвердили записи с камер видеонаблюдения в салоне. Данные были нужны ему для перепродажи.

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

Один на всех и все на одного

Что случилось: Маркетолог компании-разработчика мобильного приложения SkinSwipe для обмена игровыми предметами из CS:GO, Dota 2 и Team Fortress 2 поделился историей о мошенничестве. В выходной день кто-то начал массовую распродажу промокодов и игровой валюты из приложения, хотя команда такую активность не планировала.

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

Продвинутый поиск

Что случилось: В Сеть утекли учетные данные нескольких медучреждений для подключения к закрытой IT-системе. Слив произошел через поисковую строку Яндекса.

Кто виноват: Логины и пароли поисковику передали пользователи. Оказалось, что сотрудники учреждений для быстрого поиска страницы входа вставляли в адресную строку запрос вида полная ссылка на ресурс+логин+пароль. То есть копировали строки из таблицы, в которой хранились учетки. Яндекс принимал их в качестве запросов и выдавал как подсказки любым пользователям. Неизвестно, воспользовался ли случаем посторонний юзер с дурными намерениями. Но поисковый сервис проблему со своей стороны устранил.

Двухфакторная аутентификация, говорите? Регулярное обновление парольных фраз? А выходит, начинать нужно с азов что можно, а что нельзя вводить в поисковую строку Яндекса и Гугла.

Таким был ИБ-декабрь. До встречи в январе. Пусть каникулы будут фантастическими, а Новый год счастливым!

Последнее время кажется, что мошенники стали звонить даже чаще, чем друзья и знакомые. К якобы службе безопасности якобы Сбербанка, которая интересуется, делал ли я перевод Ивану И. из Новосибирска, я как-то даже привык. Но тут позвонили с новым для меня заходом: на этот раз про кредит. Возможно, кто-то из вас даже сталкивался с подобной схемой, но я лично первый раз.

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

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

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

О чем со мной говорили мошенники

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

Сколько у вас карт в нашем банке? Какой на них остаток? Какая была последняя операция?

Эмм карта одна, пользуюсь периодически, но, к сожалению, сумму не помню.

Есть ли у кого-то еще доступ к картам и счету?

Данные есть еще у жены и у мамы.

Есть ли накопительный счет или депозит?

Здесь решил дать волю фантазии и сказал, что на депозите у меня 3 млн руб. Ну, а почему бы и нет?

На том конце послышалась суетапосле чего девушка продолжила:

Есть ли счета в других банках?

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

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

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

Мне пообещали помочь и переключили на старшего специалиста.

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

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

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

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

Что должно было быть дальше

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

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

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

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

Кстати, звонок был с номера +7-499-009-10-76.

Что я сделал после

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

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

Словом, не теряйте бдительность и будьте на чеку.

Если в вашей компании активно используется домен Windows, рано или поздно перед вами встанет задача повысить безопасность используемых паролей. Штатных средств (кроме тривиальной групповой парольной политики) тут нет, нормальных продуктов тоже нет. Пароли хранятся в виде хэшей, которые ещё и достаточно сложно достать, поэтому прямой анализ безопасности не возможен. Я попытался построить процесс, который, при нужной сноровке, не займет у вас больше нескольких часов и будет прекрасно повторяем. Можно будет напрямую отслеживать, как ваши усилия увеличивают стойкость паролей в компании, а это всегда приятно.

Атаки на пароли

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

Из онлайн атак у нас есть password spay и password replay.

По данным Майкрософт password spraying самая распространенная атака на пароли, ответственная за ~40% успешных взломов аккаунтов М365. Злоумышленники пробуют одинаковый пароль сразу на нескольких аккаунтах (тысячах). Это обеспечивает высокую скорость подбора пароля, при этом политика временной блокировки аккаунта при многократном вводе неправильного пароля не срабатывает.

Password replay вторая по частоте атака. Злоумышленники используют базы данных слитых учётных записей, пробуя их на ваших системах. Если сотрудник использует тот же самый пароль, который был у его аккаунта LinkedIn в 2012 году двери открыты. Это, действительно, проблема нашего времени. Средний пользователь помнит 8 разных паролей, но использует более 40 аккаунтов (включая личные), следовательно пароли используются повторно, и задача корпоративной ИБ убедить пользователя выделить драгоценное место в своей памяти под уникальный пароль для корпоративного аккаунта. Самая дорогая память в ИТ это память пользователя.

Проверить свой пароль на наличие/отсутствие в утечках можно тут (но лучше не надо).

Требования к паролям

Собственно, теперь у нас есть основные требования к корпоративным паролям:

• Пароль не должен быть частью какой-либо утечки

• Пароль должен быть уникальным

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

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

Достать хэши

Хэши хранит любой контроллер домена в файле ntds.dit. Ключи шифрования, необходимые для извлечения хэшей, хранятся в ветке SYSTEM реестра контроллера домена.

Чтобы извлечь ntds.dit нужно:

• Открыть на контроллере домена консоль PowerShell

• Создать теневую копию с помощью команды

vssadmin.exe create shadow /for=C:

• Зайти в папку Windows и выбрать Properties у папки NTDS

• Скопировать теневую копию папки из вкладки Previous versions

• (Не обязательно) удалить теневую копию

Vssadmin.exe list shadowsVssadmin.exe delete shadows /shadow=<тут идентификатор копии>

Скопировать ветку SYSTEM реестра контроллера домена:

reg SAVE HKLM\SYSTEM C:\temp\SYSTEM

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

Все дальнейшие операции имеет смысл проводить на отдельной системе, которую можно даже отключить от сети и потом полностью очистить. Файл NTDS.DIT + SYSTEM это, по сути, ключи от вашего домена. Не стоит их хранить на рабочем компьютере.

Я уже привык работать в WSL (windows subsystem for linux, Ubuntu встроенная в консоль Windows 10). Поэтому первым шагом рекомендую установить WSL (вручную или через магазин приложений) и RSAT (включает PowerShell модуль для работы с доменом) для вашей версии windows 10.

Запускаем WSL из консоли PowerShell командой bash.

Устанавливаем Python 3 и хакерскую утилиту impacket. Она нужна для вытаскивания NTLM хэшей из ntds.dit

sudo apt install python3sudo apt install python3-pippython3 -m pip install impacket

Из пакета Impacket нам нужен файл secretsdump.py. Его можно найти внутри Python модуля или скачать с Гитхаба

wget https://github.com/SecureAuthCorp/impacket/releases/download/impacket_0_9_22/impacket-0.9.22.tar.gztar -xvzf impacket-0.9.22.tar.gzcd impacket-0.9.22/examples

извлекаем хэши

python3 secretsdump.py  -system /mnt/c/Temp/SYSTEM -ntds /mnt/c/Temp/ntds.dit LOCAL -outputfile /mnt/c/Temp/hashes.lst

Сразу проверяем наличие и содержимое файла hashes.lst.ntds.cleartext. Это пароли от тех аккаунтов, в свойствах которых стоит галка Store password using reversible encryption. Стоит проверить, что это действительно необходимость.
В файле много мусора. Убрать лишнее можно так:

cat hashes.lst.ntds | cut -d":" -f 1,4 | sort > hashes_sorted.lst

получится список вида:

domain\sam_account_name:ntlm_hash

Заглянем на секунду ещё раз в исходный файл. У каждого аккаунта указано по 2 хэша LM и NTLM. Вместо первого LM хэша вы везде должны видеть aad3b435b51404eeaad3b435b51404ee. Если там что-то другое аудит можно останавливать и переключить все силы на апгрейд домена.

Любимые пароли

Дальше лично я предпочитаю работать в Экселе. Вот тут мой шаблон файла , хотя, конечно, разобраться без подсказок в нём сложновато, и вам вероятно придётся создать свой.
Первое, что я обычно делаю ищу аккаунты с одинаковым хэшем (т.е. те аккаунты, где используется одинаковый пароль). Если один и тот же хэш встречается больше 2х раз пароль придётся сменить.
Но перед этим ещё стоит отфильтровать неактивные аккаунты. Для этого можно использовать командлет Get-ADUser (часть RSAT, я импортирую результат в свой эксель файл). Сразу можно собрать почтовые ящики - понадобится в будущем для рассылки предупреждений о сбросе пароля. В некоторых компаниях старые аккаунты не выключают, но устанавливают ExpirationDate. Так лучше не делать, но я собирают и эти данные тоже.

Get-ADUser -Filter * -Properties mail, AccountExpirationDate | Where { $_.Enabled -eq $True} | Select Name,samaccountname,mail,AccountExpirationDate | Export-csv C:\Temp\enabled_accounts.csv -NoTypeInformation

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

Слабые пароли

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

Если какой-либо из наших хэшей находится в этой базе значит он утёк, и соответствующий пароль мы будем называть слабым. Наша цель принудить пользователей использовать уникальный пароль для рабочего аккаунта.
Качаем и распаковываем базу (сегодня это ~22 Гб, но она растёт). Первое, что нужно сделать перевести все хэши в низкий регистр и избавится от счетчика (т.е. было так: 0717B19E4348445872D8BB57D5E562B7:14, станет так: 0717b19e4348445872d8bb57d5e562b7)

cat pwned-passwords-ntlm-ordered-by-hash-v7.txt | cut -d":" -f 1 | awk '{print tolower($0)}' > hash_db.lst 

Через 5-7 минут вы должны получить отсортированный файл хэшей в нужном формате.
Из дампа нужно тоже оставить одни отсортированные уникальные хэши:

cat hashes_sorted.lst | cut -d":" -f 2 | sort -u > hashes_only_sorted.lst

Теперь нам нужно сравнить два массива хэшей, один из которых занимает ~20 Гб.
На моем ноутбуке это оказалось непосильной задачей. Питон съел всю память и ничего не сделал. Тогда мне пришлось разбить hash_db на части по 3-5 Гб и дело сдвинулось с мертвой точки.
Т.е. теперь алгоритм выглядит так: разбиваем 20Гб файл на части по 3-5 Гб (кратно 33 байта, чтобы все хэши остались целыми). Сравниваем попарно каждый кусок с массивом хэшей из дампа с помощью питоновского set.intersection. На выходе будет файл с пересечением множеств хэшей из дампа и базы данных утекших паролей.
Небольшой скрипт на питоне, который делает всё вышеперечисленное, вы можете увидеть тут.
Работает он 5-20 минут на среднем компьютере. Можно, кончено, оптимизировать, но зачем?
Получившийся файл я забираю в свою эксельку и фильтрую по флагу enabled_account. Для наглядности, я беру несколько популярных в компании слитых хэшей и перегоняю их в пароли через сайты типа hashes.com или crackstation.net. Это нужно для наглядности и хорошо смотрится на слайдах, но не является целью всей затеи. Мы хорошие парни, хэшей нам уже достаточно.
Вторая половина тоже готова. Теперь начинается самое интересное...

Что будем считать?

Если мы внимательно посмотрим на получившийся файл, то увидим прекрасный КПИ для отдела ИБ процент аккаунтов со стойким паролем. Вычислить его просто:

P = 1 enabled_accounts_with_weak_password / total_enabled_accounts

Где enabled_accounts_with_weak_password активные аккаунты, пароль которых принадлежит множеству утекших или повторяющихся паролей (или обоим множествам одновременно)
Задача отдела ИБ теперь в том, чтобы этот процент неуклонно рос до, скажем, 95%.
Я так же считаю другой показатель количество пользователей, которые сменили один слабый пароль на другой слабый пароль после предупреждения службы ИБ. Эта та аудитория, с которой нужно работать. Внутри компании мы договорились о 3х предупреждениях, и если не помогло - беседе с HR.
Прежде чем начинать аудит, нужно подготовить материалы по повышению осведомленности пользователей. Иначе смысл всей затеи пропадёт.
Подготовьте страничку с описанием того, как правильно выбрать хороший пароль. Хорошо бы развесить по офису постеры (вот пример бесплатных) и сделать тематическую корпоративную рассылку. Важный этап запланировать встречи с ИТ техподдержкой и убедить в важности выбора хороших паролей, в первую очередь, их. Обычно самый повторяющийся в компании пароль как раз тот, который ИТ присваивает новым аккаунтам по-умолчанию.
Самая тяжёлая часть это сервис-аккаунты. Многие из них могут быть созданы подрядчиками, и пароль India12345 с чекбоксом never expired тут обыденность. Менять такие пароли нужно аккуратно, ибо чёрт знает в каком продакшн скрипте их закодили.
Если вам удастся правильно построить работу службы ИБ, то на плечи красной команды ляжет только мониторинг. Самая тяжелая часть уйдет в ИТ.
Вот, пожалуй, и всё. Пишите комментарии и задавайте вопросы!

Были ли у вас случаи, когда из-за требований к ИБ приходилось заново проектировать систему/ вносить значительные изменения в проект? Часто подразделения, отвечающие за ИБ, привлекаются к проекту на поздних этапах, из-за чего объем работы может вырасти в разы. Мы работаем с крупным бизнесом и государственными организациями, где традиционно сильны процедуры и регламенты, поэтому сполна можем поделиться своим опытом и советами на тему, как предотвратить такие ситуации. В этой статье речь пойдет о проблемах при внедрении СЭД, но, думаю, это актуально и для других проектов для крупных заказчиков.

Как это происходит на практике

Начну с примера проекта по внедрению специализированной АС, в рамках которого мы столкнулись с проблемами ИБ, причем проблемы были не технического характера, а скорее организационного. В ТЗ было явно прописано условие реализации работ по ИБ в рамках другого проекта, и мы со спокойной душой приступил к проектированию. Спокойствие вскоре было нарушено: на этапе согласования ЧТЗ выплыли замечания от службы ИБ. Они не подразумевали реализацию подсистемы ИБ, но требовали учитывать внутренние регламенты при проектировании и сдаче системы в эксплуатацию. В результате плановые сроки на этапе проектирования были затянуты, однако, благодаря участию представителей службы ИБ, в плане работ на следующий этап по сдаче системы в эксплуатацию получилось спрогнозировать изменения, связанные с требованиями службы ИБ и минимизировать риски.

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

Что касается СЭД

Часто документы, обработанные в СЭД, требуют отдельного внимания к сохранности от влияний негативного характера. Обеспечение информационной безопасности представляет собой комплекс организационных и технических мероприятий, которые должны выполняться в соответствии с разработанной политикой ИБ в компании и законодательством РФ в области ИБ.

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

1. Посреди проекта появляются новые требования по ИБ от соответствующего департамента и меняется скоуп проекта;

2. На этапе сдачи проекта к приемке подключается специалист ИБ и не принимает проект в промышленную эксплуатацию;

3. Эксплуатируемая система уязвима к угрозам ИБ.

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

Почему нужно принимать во внимание требования по обеспечению ИБ?

Основные причины:

1. Выполнение требований законодательства РФ. За их нарушение предусмотрена административная и, в отдельных случаях, уголовная ответственность как ответственных работников за данной АС, так и руководителя компании.

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

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

Базовые принципы

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

1. Законность и обоснованность защиты. Защищаемой информации по правовому статусу требуется защита.

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

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

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

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

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

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

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

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

На что обратить внимание?

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

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

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

Если же вам повезло и проект предусматривает реализацию требований ИБ (или проектирования подсистемы ИБ) и у вашей организации есть соответствующие лицензии на осуществление этой деятельности в области ЗИ (политика в области лицензирования отдельных видов деятельности определяется Постановлением Правительства Российской Федерации от 24 декабря 1994 г. 1418 О лицензировании отдельных видов деятельности), то при построении (модернизации) подсистемы ИБ целесообразно реализовывать следующий цикл работ, включающий обязательный этап диагностического обследования с оценкой уязвимостей автоматизированной системы и угроз:

1. Обследование:

• Аудит системы (комплексное обследование подсистемы ИБ);

• Описание существующих ИТ-ресурсов/ сервисов/ бизнес-процессов;

• Анализ угроз и уязвимостей;

• Анализ рисков.

2. Проектирование:

• Разработка проектных решений по защите информации;

• Разработка рабочей и эксплуатационной документации на подсистему ИБ.

3. Внедрение СрЗИ.

4. Аттестация АС (при необходимости).

Есть ли оптимальное решение задачи защиты информации в СЭД?

При проектировании защищенной СЭД должны быть выполнены следующие условия:

1. Создание и администрирование комплексной системы защиты информации в СЭД должно обеспечиваться в соответствии с требованиями законодательства Российской Федерации, а также с принципами построения систем комплексной ЗИ, стандартами информационной безопасности, определяемыми документами ФСТЭК России, разработанной политикой информационной безопасности организации.

2. В соответствии с требованиями ФСТЭК России проектирование систем ЗИ осуществляется только лицензиатом по защите информации.

Мы проектируем и внедряем системы, учитывая наш многолетний опыт, особенности конкретной организации, требования заказчиков и регуляторов (ФСТЭК и ФСБ России) к обеспечению ИБ при обработке информации в СЭД. В нашем случае оптимальным решением является использование СЭД на базе платформы Docsvision (сертифицированная версия), которая закрывает ряд требований ИБ, таких как: отсутствие уязвимостей и НДВ, идентификация и аутентификация пользователей, управление доступом и логирование действий пользователей в системе. При таком решении существенно снижается финансовая нагрузка на внедрение дополнительных СЗИ. Мы лицензиаты ФСТЭК России и имеем специальные компетенции по построению систем защиты информации, поэтому можем оптимально спланировать бюджет на внедрение СЭД и избежать сопутствующих рисков.

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

• На предпроектном этапе с заказчиком четко определите и зафиксируйте ответственность за выполнение требований ИБ;

• Привлекайте представителей служб ИБ на этапе проектирования;

• При наличии в ТЗ требований по ИБ настоятельно рекомендую обратиться в специализированную компанию, имеющую соответствующие лицензии и опыт реализации подобных проектов.

Нормативная база по теме

1. Федеральный закон от 27 июля 2006 года 152-ФЗ "О персональных данных" (с изменениями на 30 декабря 2020 года);

2. Федеральный закон от 27 июля 2006 г. 149-ФЗ Об информации, информационных технологиях и о защите информации (с изменениями на 30 декабря 2020 года), принят Государственной Думой 8 июля 2006 года;

3. Указ Президента РФ от 06 марта 1997 188 (ред. от 13.07.2015) Об утверждении Перечня сведений конфиденциального характера (с изменениями на 13 июля 2015 года);

4. Постановление Правительства РФ от 06.07.2015 N 676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации";

5.Постановление Правительства РФ от 01.11.2012 N 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных";

6. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Классификация автоматизированных систем и требования по защите информации. Решение председателя Гостехкомиссии России от 30 марта 1992 года;

7.Руководящий документ. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации Утверждена решением Гостехкомиссии при Президенте Российской Федерации от 30 марта 1992 года.

8.Положение по аттестации объектов информатизации по требованиям безопасности информации. Утверждено председателем ГТК при Президенте РФ 25 ноября 1994 года (обновлено 17 июля 2017 года);

9.Приказ ФСТЭК России от 11.02.2013 N 17 "Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах";

10.Приказ ФСТЭК России от 18.02.2013 N 21 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных";

11. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;

12.ГОСТ 34.201-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем;

13. ГОСТ Р 51583-2014 Защита информации. Порядок создания автоматизированных систем в защищенном исполнении.

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

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

Пара слов о Всемирном банке, где, как выясняется, тоже бывают инциденты

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

Решение о создании Всемирного банка, а также Международного валютного фонда, было принято на Бреттон-Вудской конференции, состоявшейся в США в 1944 году. Банк начал активную деятельность в 1945-м и ставил своей целью кредитование стран, которым требовалась помощь в восстановлении экономики, пострадавшей от Второй мировой войны. Таким образом, практически весь восстановившийся послевоенный мир оказался со временем должен Всемирному банку. Позднее кредитная организация добавила в число своих клиентов-должников неохваченные изначально развивающиеся страны.

Как такие, как Амели, становятся мистером Вульфом, который решает все проблемы

Прежде чем рассказать о сути инцидента, несколько слов о человеке, который с ним справился. Амели Коран закончила колледж в 1993-м, изучала программирование и социологию. Поработала в Xerox дизайнером пользовательских интерфейсов, системным администратором, отвечала за безопасность серверной инфраструктуры Американского химического сообщества. По-настоящему масштабные задачи ждали Амели в компании, отвечавшей за поставки газа и электричества в ряд штатов США. Не успела она устроиться туда, в службу DFIR (Digital Forensics and Incident Response), как налетел ураган и вывел из строя часть инфраструктуры. Пришлось на ходу и на ветру менять подходы к проектированию катастрофоустойчивых ЦОД, а заодно учиться работать в авральном режиме. Полученный опыт Амели развила в компании Mandiant, специализировавшейся на кибербезопасности и позднее в FireEye одном из мировых лидеров по борьбе с угрозами нулевого дня.

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

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

Инцидент

Система мониторинга целостности файлов Всемирного банка зафиксировала изменения на одном из серверов, HSM (Hardware Security Module), по сути, секретном шкафчике со всем банковским криптографическим материалом. Служба безопасности выяснила, что к событиям не причастны системные администраторы, подозревали кого-то из посторонних.

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

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

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

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

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

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

Амели Коран вспоминает, как во время очередного безумного конф-колла, где принимали участие CIO, CISO и прочие шишки, ей, скромному наемному подрядчику, даже пришлось прикрикнуть на них: Успокойтесь все, черт вас возьми! В оригинале фраза звучала грубее. Сожалений за этот эмоциональный всплеск она не испытывает. Наоборот. Одна из основных задач специалиста по сложным инцидентам, считает она, внести хоть какое-то подобие порядка в ситуацию, когда у людей от стресса уже идет пар из ушей. Ни высокий IQ, ни глубокие познания в киберрасследованиях не заменят холодной головы.

Вчера в кабинете, а завтра в газете!

Рядовым сотрудникам банка не были известны подробности инцидента, зато о них как-то прознала пресса. Издание Wall Street Journal, а затем и Fox News сообщили, в частности, что Всемирный банк переживает беспрецедентный кризис, сославшись на письмо технического директора. То, что ситуация стала публичной, добавило нервозности. Но главное, злоумышленник, если еще не был в курсе, узнал, что его обнаружили.

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

Амели начала составлять список возможных кротов, первым делом начала присматриваться к айтишникам и топам. Она изучала цитаты из статей и терпеливо искала что-то похожее в переписке главных подозреваемых (эксперт не рассказывает подробности, но судя по всему в 2008 году такой анализ она проводила вручную, никаких DLP-систем как подмоги у нее не было). Постепенно и сами участники группы расследования, и топ-менеджеры начали косо смотреть друг на друга как в игре Among us. Военсовет превращался в битву взглядов, когда каждый пытался разглядеть внутреннего врага в ком-то из коллег.

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

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

Крупная рыба

С жесткого диска ПК инсайдера был сделан отпечаток. Использовав для этого EnCase (инструмент для форензики) и некоторые другие инструменты, эксперт обнаружила, что письма в СМИ сотрудник отправлял через веб-почту Yahoo, а не через корпоративную Lotus Notes.

Параллельно выяснилось, что инсайдер был связан с прежним руководителем Всемирного банка Полом Вольфовицем (Paul Wolfowitz). Об этом человеке стоит рассказать чуть подробнее. Кандидатуру Пола в качестве руководителя Всемирного банка предложил не кто-нибудь, а лично президент США Джорж Буш-младший. Это вызвало недоумение у финансовых журналистов, поскольку прежней должностью Пола была заместитель Министра обороны. Правда, уволен Пол был не по причине финансового или военного скандала, а потому что устроил в банк свою знакомую.

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

Таким образом одна из проблем слив информации в СМИ была решена. Амели, распутав один клубок, смогла впервые за многие дни переночевать дома, а не на одеяле под столом, где работала все последнее время. Ночевать под столом, по ее словам, удовольствие то еще.

Как и зачем преступники вошли в банк?

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

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

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

Так кому же потребовался взлом Всемирного банка?

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

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