Русский
Русский
English
Статистика
Реклама

Research

Telegram, Signal, Wickr Me выбираем самый безопасный мессенджер и разбираемся, существует ли он

12.11.2020 10:07:10 | Автор: admin


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

О каких мессенджерах пойдет речь?


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

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

  1. Signal некоммерческий проект Open Whisper Systems
  2. Telegram некоммерческий проект Telegram FZ-LLC
  3. Wickr Me коммерческий проект Wickr Inc с бесплатной версией

Для исследования мессенджеров использовали последние версии, доступные на момент исследования в App Store и Google Play.

Мессенджеры устанавливались на смартфоны с iOS версии 13.3.1 и Android версии 7.1.2, при этом на смартфонах заранее были получены права суперпользователя (jailbreak для iOS и root-доступ для Android).

Как сравнивали мессенджеры?


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

Для проведения анализа мы выбрали три основные категории:

  1. Открытость сообществу
  2. Архитектура
  3. Основная функциональность

В категории Открытость сообществу оценивались:

  • наличие отчетов внешних аудиторов (в том числе наличие bug bounty-программ)
  • доступность исходного кода мессенджера для исследователей (клиентская и серверная часть, протокол шифрования)
  • наличие доступной и подробной документации для пользователей мессенджера

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

В категориях Архитектура и Основная функциональность оценка складывалась на основе результатов технических (инструментальных) проверок, которые проводились по стандарту OWASP Mobile Security Testing Guide.

В категории Архитектура после проведения инструментальных проверок мы получили оценку:

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

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

В категории Основная функциональность оценивалась корректность работы следующих функций мессенджеров:

  • обмен сообщениями (включая файлы различных форматов)
  • совершение видео- и аудиовызовов

Максимальная оценка в этой категории 120 баллов.

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

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

И что получилось?


Пришло время поделиться результатами исследования: как видно на диаграмме ниже, наибольшее количество баллов набрал Wickr Me 304 из 332 возможных:

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

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

Открытость сообществу


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

Wickr Me набрал меньше баллов, так как мессенджер не раскрывает исходный код.

Архитектура


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

Лидером в категории Архитектура является Wickr Me, который содержит меньше выявленных недостатков, чем у конкурентов.

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

Из плюсов следует отметить, что все мессенджеры поддерживают E2EE-шифрование передаваемых данных, поэтому оценка Certificate pinning не проводилась.

Основная функциональность


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

  • обмен сообщениями
  • совершение аудио- и видеозвонков

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

Лидерами данной категории стали Wickr Me и Telegram, набрав максимальное количество баллов.

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

Информация о найденных недостатках


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

Напомним, что все выявленные недостатки были обнаружены на устройствах с root-доступом (или к устройству применен jailbreak).

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

Возможность обхода биометрической аутентификации


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

iOS


У всех приложений, в том числе мессенджеров из нашего списка, для платформы iOS биометрическая аутентификация пользователя осуществляется при помощи Local Authentication Framework с использованием функции evaluatePolicy класса LAContext. Рассмотрим работу биометрической аутентификации немного подробнее.

Как выглядит биометрическая аутентификация для пользователя?

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

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

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

У всех исследуемых мессенджеров недостаток реализации биометрической аутентификации состоит в том, что пользователь аутентифицируется лишь на основе результата функции evaluatePolicy (true или false) и мессенджер не использует системные механизмы авторизации при доступе к значениям из защищенного хранилища Keychain. Более подробно о локальной аутентификации можно узнать в Mobile Security Testing Guide: здесь и здесь.

Как устранить недостаток?

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

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

Android


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

В приложении для платформы Android биометрическая аутентификация пользователя осуществляется с использованием классов FingerprintManager (не используется с Android 9), BiometricPrompt, BiometricManager.

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

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

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

Как устранить недостаток?

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

Хранение чувствительной информации в локальном хранилище


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

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

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

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

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

Как устранить недостаток?

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

Еще раз напомним, что вышеуказанные чувствительные данные мессенджера недоступны без использования root-доступа (или jailbreak) на устройстве.

Некорректная обработка исключений


Данная уязвимость относится только к платформе Android и мессенджеру Signal.

При исследовании основной функциональности мессенджеров осуществлялась отправка файлов разных форматов. В результате был найден один сценарий, при котором отправка файла вызывала остановку в работе мессенджера со следующей ошибкой: Signal has stopped.

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

Как устранить недостаток?

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

Ответы разработчиков


Обо всех описанных выше недостатках наша команда сообщила разработчикам мессенджеров. На момент публикации мы получили ответ от двух из трех мессенджеров (Signal и Telegram), третий на наши вопросы так и не ответил.

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

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

Вывод


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

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

По итогам всех проверок лидером нашего исследования стал мессенджер Wickr Me, который набрал 304 балла и у которого выявлено меньше всего недостатков.

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

21 метод UX-исследований какой выбрать

20.07.2020 06:19:52 | Автор: admin



Нравится тебе оно или нет, но при создании ИТ-продукта никак не обойти тему проверки UX на прочность. Любой специалист, которому хоть сколько-нибудь не наплевать на свою работу, хочет, чтобы результаты потраченных человеко-часов были по достоинству оценены конечным пользователем.

Часть методов UX-исследований настолько очевидны и прямолинейны, что у некоторых из ИТ-шников при первом знакомстве в классификацией тестов появится логичный вопрос А что, кто-то этого не делает? и следующий за ним Их ещё не поувольняли?.

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

В этой статье собран 21 метод UX-исследований. Некоторые из них простые и банальные, некоторые более изощрённые. Выбирай тот, что тебе по вкусу. Но сначала посмотрим, какими характеристиками они отличаются.



Отличия методов


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

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

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

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

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

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

Методы UX-исследований


1. Проверка концепции
2. Сортировка карточек
3. Фокус-группа
4. Этнографическое исследование
5. Привлечение к проектированию
6. Древовидное тестирование
7. Оценка предпочтений
8. Лабораторное исследование
9. Айтрекинг
10. Исследование дневников
11. Удалённое исследование
12. 5-секундный тест
13. Немодерируемое панельное исследование
14. A/B-тестирование
15. Юзабилити бенчмаркинг
16. Экспертный обзор
17. Кликстрим
18. Сбор обратной связи
19. Email-опрос
20. Исследование истинного намерения
21. Интервью


1. Проверка концепции (Concept Testing)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: смешанное
Этап: планирование

Обзор
Метод сосредоточен на выделении ключевых качеств продукта, чтобы определить, соответствуют ли они потребностям целевой аудитории. Тот, кто знаком с концепцией MVP (minimum viable product), наверняка понимает, о чём речь. Может выполняться как один-на-один, так и с большей аудиторией. Главная цель понять, есть ли хоть какая-то потребность в таком продукте.

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


2. Сортировка карточек (Card Sorting)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: планирование

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

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

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


3. Фокус-группа (Focus Groups)


Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: планирование, разработка

Обзор
Группа из 310 участников под руководством модератора обсуждает свои взгляды на будущий продукт. Роль модератора скорее поддерживать поток мнений, чем направлять его. Фокус-группа может ответить на несколько основных вопросов, но не должна превращаться в интервью (см. метод 21).

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


4. Этнографическое исследование (Ethnographic Field Studies)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное
Этап: планирование, разработка

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

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

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

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


5. Привлечение к проектированию (Participatory Design)


Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное или по сценарию
Этап: планирование, разработка

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

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

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


6. Древовидное тестирование (Tree Testing)


Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: без участия
Этап: планирование, разработка

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

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

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


7. Оценка предпочтений (Desirability Studies)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное, по сценарию
Этап: планирование, разработка

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

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


8. Лабораторное исследование (Usability-Lab Studies)


Качественный/количественный: качественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка

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

Подробнее о том, как подобное исследование проводится, можно почитать в статье UX-исследование ДБО: наш опыт, ошибки и открытия.

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


9. Айтрекинг (Eyetracking)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное или по сценарию
Этап: разработка

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

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

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


10. Исследование дневников (Diary/Camera Studies)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: разработка

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

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

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


11. Удалённое исследование (Remote Usability Studies)


Качественный/количественный: скорее качественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка, подведение итогов

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

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


12. 5-секундный тест (Five second test)


Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: разработка, подведение итогов

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

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


13. Немодерируемое панельное исследование (Unmoderated Remote Panel Studies)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное или по сценарию
Этап: разработка, подведение итогов

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

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

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


14. A/B-тестирование (A/B Testing)


Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное
Этап: разработка, подведение итогов

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

После достижения статистической значимости делается вывод, какой вариант победил по выбранному KPI (например, покупки в приложении). Проводится в специальных сервисах, таких как Google Optimize для сайтов и Optimizely для приложений.

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


15. Юзабилити бенчмаркинг (Usability Benchmarking)


Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: по сценарию
Этап: разработка, подведение итогов

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

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


16. Экспертный обзор (Expert Review)


Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное или по сценарию
Этап: разработка, подведение итогов

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

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


17. Анализ кликстрима (Clickstream Analysis)


Качественный/количественный: количественный
Поведенческий/отношенческий: поведенческий
Участие продукта: естественное
Этап: разработка, подведение итогов

Обзор
Анализ данных о том, какие страницы и в каком порядке посещал пользователь. Легко провести с помощью системы аналитики Google Analytics, Яндекс.Метрика, Firebase, Mixpanel. Позволяет выявить проблемы, связанные с навигацией по сайту или приложению. Не помогает с поиском их причин. Для выяснения причин стоит использовать юзабилити-исследования (методы 8, 11).

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


18. Сбор обратной связи (Customer Feedback)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: естественное
Этап: подведение итогов

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

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


19. Email-опрос (Email Survey)


Качественный/количественный: возможны оба
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: подведение итогов

Обзор
Анкетирование пользователей по email, в отличие от сбора обратной связи, общее и не триггерное. Касается предыдущих взаимодействий с продуктом, поэтому оценивает только его восприятие аудиторией. Проще для проведения, чем интервью (см. метод 21), но выше вероятность отказа. Количество вопросов обычно не превышает 10, чтобы не отпугнуть респондентов.

Когда использовать
Для анализа эффективности действующего продукта и сравнения с конкурентами.


20. Исследование истинного намерения (True-Intent Studies)


Качественный/количественный: количественный
Поведенческий/отношенческий: возможны оба
Участие продукта: естественное
Этап: подведение итогов

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

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

Когда использовать
После запуска продукта, когда достаточный объём трафика достигнут. Чтобы узнать, отвечает ли разработка запросам пользователей, и выполняет ли задуманные функции.


21. Интервью (Interviews)


Качественный/количественный: качественный
Поведенческий/отношенческий: отношенческий
Участие продукта: без участия
Этап: подведение итогов

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

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

Итог


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

Спасибо Станиславу Лушину за помощь в написании статьи.
А также Елене Ефимовой за инфографику, Татьяне Китаевой за редактуру.

Список источников:
When to Use Which User-Experience Research Methods
7 Great, Tried and Tested UX Research Techniques
Five second tests
Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories
Подробнее..

Как работать с неизвестностью и неопределенностью в разработке

19.12.2020 12:08:03 | Автор: admin

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

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

Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.

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

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

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

Неопределенности технических продуктов

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

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

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

Основа нашей системы это три техники, пришедшие из Agile/Scrum:

  1. Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.

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

  3. Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.

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

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

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

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

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

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

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

Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.

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

1. Анализ

Начинайте с проведения анализа если:

  • У вас есть проблема

  • Вы не знаете как её решить

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

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

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

  • Насколько трудоёмкая будет реализация

  • Насколько дорого это выйдет

  • Сколько времени потребуется

  • Какой гибкости мы лишаемся, принимая именно это решение

  • Насколько этим удобно будет пользоваться

Под разные команды значимость тех или иных факторов может быть разная.

В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:

  • Наша операционная нагрузка

  • Наш автобусный фактор

  • Скорость нашей команды

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

Одним из распространенных результатов анализа это документация типа такой:


Repository: плюсы и минусы

  • Плюсы

    • Это эффективный способ предоставлять доступ большомуобъему данных: записал один раз и читаешь отовсюду

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

    • Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных

    • Работа с данными происходит по общей схеме, поэтомулегче подключать новые подсистемы

  • Минусы

    • Подсистемы должны работать с общей схемой, что может влиять на производительность

    • Эволюция данных: "дорого" принимать новую модель данных,потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать

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

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


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

2. Spike

Спайк нужен, когда:

  • У вас есть проблема

  • У вас есть хоть какая-то идея как её решить

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

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

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

Хороший пример это бумажный прототип.

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

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

3. Трассер

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

  • У вас есть проблема

  • У вас есть решение, но вы не знаете как много времени это займет.

Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:

  • очень небольшое

  • запускается в продакшен окружении

  • остается, а не выбрасывается

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

  • успешно получает текст из поля ввода

  • отправляет этот текст в Segment

  • идёт в customer.io из Segment

  • обновляет список для рассылки

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

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

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

Цикл Анализ Спайк Трассер

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"

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

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

Благодарю Антона Сметанина @dizzy_dalvin за помощь в редактуре

Подробнее..

Перевод Как работать с неизвестностью и неопределенностью в разработке

19.12.2020 14:20:36 | Автор: admin

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

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

Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.

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

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

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

Неопределенности технических продуктов

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

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

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

Основа нашей системы это три техники, пришедшие из Agile/Scrum:

  1. Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.

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

  3. Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.

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

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

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

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

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

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

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

Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.

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

1. Анализ

Начинайте с проведения анализа если:

  • У вас есть проблема

  • Вы не знаете как её решить

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

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

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

  • Насколько трудоёмкая будет реализация

  • Насколько дорого это выйдет

  • Сколько времени потребуется

  • Какой гибкости мы лишаемся, принимая именно это решение

  • Насколько этим удобно будет пользоваться

Под разные команды значимость тех или иных факторов может быть разная.

В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:

  • Наша операционная нагрузка

  • Наш автобусный фактор

  • Скорость нашей команды

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

Одним из распространенных результатов анализа это документация типа такой:


Repository: плюсы и минусы

  • Плюсы

    • Это эффективный способ предоставлять доступ большомуобъему данных: записал один раз и читаешь отовсюду

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

    • Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных

    • Работа с данными происходит по общей схеме, поэтомулегче подключать новые подсистемы

  • Минусы

    • Подсистемы должны работать с общей схемой, что может влиять на производительность

    • Эволюция данных: "дорого" принимать новую модель данных,потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать

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

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


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

2. Spike

Спайк нужен, когда:

  • У вас есть проблема

  • У вас есть хоть какая-то идея как её решить

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

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

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

Хороший пример это бумажный прототип.

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

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

3. Трассер

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

  • У вас есть проблема

  • У вас есть решение, но вы не знаете как много времени это займет.

Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:

  • очень небольшое

  • запускается в продакшен окружении

  • остается, а не выбрасывается

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

  • успешно получает текст из поля ввода

  • отправляет этот текст в Segment

  • идёт в customer.io из Segment

  • обновляет список для рассылки

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

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

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

Цикл Анализ Спайк Трассер

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"

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

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

Подробнее..

Научно-исследовательские инициативы JetBrains

03.03.2021 14:04:54 | Автор: admin
Develop with pleasure, The drive to develop об этом вы наверняка от нас слышали. Но наши интересы далеко не ограничиваются разработкой и созданием мощных инструментов для повышения продуктивности. Мы верим, что можем многое изменить и сделать мир лучше. Один из верных способов проведение исследований в области передовых технологий и образования. Совместно с ведущими научными учреждениями мира мы занимается прикладными исследованиями, способными влиять на жизни людей и двигать нас всех вперед.

Наши научные исследования объединены в рамках направления JetBrains Research.

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

Наука сегодня для технологий будущего



JetBrains Research объединяет более 150 исследователей, участвующих в проектах более 19 лабораторий и групп. Лаборатории и группы ведут работу в самых разных направлениях от физики элементарных частиц до разработки ПО.


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



Исследовательские группы



BioLabs


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


Задача BioLabs раскрыть механизмы эпигенетической регуляции у людей и животных и понять, какое значение эти механизмы играют в процессах дифференцировки и старения клеток. Самым крупным является проект старения, реализуемый BioLabs совместно с Университетом Вашингтона в Сент-Луисе. Другие исследовательские проекты посвящены различным темам, включая новые алгоритмы анализа данных, эффективные инструменты обработки данных для секвенирования нового поколения (Next Generation Sequencing), масштабируемые конвейеры данных, подходы к визуализации и мета-анализу существующих баз данных с информацией о механизмах эпигенетической регуляции. BioLabs также отвечает за PubTrends новый сервис для анализа научных публикаций, позволяющий быстрее анализировать тренды и находить значимые работы. Такой сервис необходим, поскольку число работ, публикуемых каждый год, неуклонно растет, и уследить за всеми публикациями по выбранной теме практически невозможно.


Вернуться к списку исследовательских групп


Группа биоинформатики


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

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


Вернуться к списку исследовательских групп


Лаборатория нейробиологии и физиологии развития


Нейробиология и физиология развития прошли долгий путь и накопили фундаментальную базу исследований. И тем не менее многое в этой науке по-прежнему остается неизведанным. А ведь эти науки таят в себе огромный потенциал к пониманию человеческого мозга.
Задача лаборатории нейробиологии и физиологии развития разработать вычислительный фреймворк для создания динамических пространственных моделей структуры нервных тканей и динамики базовых стимулов. Проект Biological Cellular Neural Network Modeling (BCNNM) использует последовательности биохимических реакций для запуска сложных моделей нейронных сетей при формировании исходных стволовых клеток. Фреймворк можно использовать для in silico репликации экспериментов, проведенных in vitro, чтобы получать измерения с ключевых компонентов, а также выполнять предварительную вычислительную проверку новых гипотез.


Вернуться к списку исследовательских групп



Лаборатория прикладного машинного обучения и глубокого обучения
и
Лаборатория агентных систем и обучения с подкреплением


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


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


Вернуться к списку исследовательских групп


Исследовательская группа Paper-Analyzer


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


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


Вернуться к списку исследовательских групп


Лаборатория криптографии


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


Лаборатория криптографии занимается исследованиями современных задач в области криптографии и информационной безопасности. Она сотрудничает с COSIC исследовательской группой компьютерной безопасности и промышленной криптографии в Левене (Бельгия), Selmer Center в Университете Бергена (Норвегия) и INRIA (Франция). Исследования ведутся по различным направлениям: криптографические логические функции, симметричные шифры, легковесная криптография, технология блокчейна, квантовая криптография и информационная безопасность. Помимо публикации монографий и статей в ведущих журналах о криптографии, сотрудники лаборатории преподают криптографию в Новосибирском государственном университете и организуют NSUCRYPTO Международную студенческую олимпиаду по криптографии.


Вернуться к списку исследовательских групп


Группа HoTT и зависимых типов


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


Исследовательская группа занимается созданием Arend зависимо-типизированного языка и инструмента доказательства теорем, основанного на гомотопической теории типов. HTT является более продвинутым фреймворком, чем те, на которых основаны инструменты вроде Agda и Coq. Конечная цель создать онлайн-помощник для доказательства теорем, основанный на современной теории типов, который бы позволил формализовать определенные разделы математики.


Вернуться к списку исследовательских групп


Лаборатория методов ядерно-физических экспериментов


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


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


Лаборатория методов ядерно-физических экспериментов


Вернуться к списку исследовательских групп


Лаборатория исследований процессов обучения


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


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


  1. Кто идет в STEM и программирование?
  2. Какие факторы (когнитивные возможности, история семьи и т. д.) приводят человека к лучшим результатам и уменьшают вероятность забросить учебу?
  3. Существуют ли характерные установки (мотивация, вовлеченность и т.д.), способные пересилить первоначальные данные?
  4. Какие методологии обучения приносят успех, а какие повышают вероятность неудачи?

Вернуться к списку исследовательских групп


Лаборатория алгоритмов мобильных роботов


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


Лаборатория алгоритмов мобильных роботов объединяет исследования в области разработки эффективных алгоритмов для мобильных роботов. В лаборатории имеется единственный в России экземпляр Duckietown платформы и среды, позволяющих разрабатывать алгоритмы для мобильных роботов. В центре внимания лаборатории задача одновременной локализации и построения карты (SLAM). SLAM подразумевает составление и последующее поддержание карты неизвестной среды; при этом благодаря анализу данных с различных датчиков можно отслеживать местонахождение агента в среде. Сложность задачи SLAM связана с шумами, свойственными физическим датчикам, а также с необходимостью следить за изменениями в динамической среде. Кроме того, многие алгоритмы SLAM рассчитаны на недорогое оборудование, которое задает строгие требования к производительности. В 2019 году лаборатория роботов участвовала в третьих AI Driving Olympics соревнованиях роботов, управляющих беспилотным транспортом. Эти престижные соревнования считаются местом силы для развития знаний в сфере беспилотных автомобилей. Наша лаборатория заняла первое место во всех трех состязаниях. Примечательно, что это был первый прецедент победы алгоритма глубокого обучения на этих соревнованиях.


Исследователи лаборатории преподают множество курсов по дисциплинам STEM в университетах. Также они предлагают курсы по мобильной разработке для школьников и принимают студентов из MIT, приезжающих по программе MISTI.


Лаборатория алгоритмов мобильных роботов


Вернуться к списку исследовательских групп


Проблемы оптимизации в программной инженерии


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


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


Вернуться к списку исследовательских групп


Группа параметризованных алгоритмов


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


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


Вернуться к списку исследовательских групп


Лаборатория параллельных вычислений


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


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


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


Вернуться к списку исследовательских групп


Лаборатория киберфизических систем


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


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


Вернуться к списку исследовательских групп


Методы машинного обучения в области программной инженерии


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


Группа методов машинного обучения в области программной инженерии занимается разработкой и тестированием методов улучшения инструментов и процессов разработки путем применения анализа данных (включая машинное обучение) к данным из программных репозиториев. Совместно с командами нескольких продуктов JetBrains группа занимается интеграцией в продукты современных методов на основе данных. В данный момент группа работает над десятком исследовательских проектов на различные темы от поддержки библиотек сбора данных до генерации кода из описаний на естественном языке. Недавние результаты работы группы включают новый подход к рекомендации рефакторингов Move method, исследование нарушений лицензий в заимствованном коде на GitHub, современный подход к присуждению авторства исходного кода и метод построения векторных представлений стиля кода без явных признаков.


Вернуться к списку исследовательских групп


Лаборатория языковых инструментов


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


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


Вернуться к списку исследовательских групп


Лаборатория верификации и анализа программ (VorPAL)


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


В лаборатории верификации и анализа программ студенты, аспиранты и исследователи занимаются разработкой программных технологий, основанных на формальных методах, таких как верификация, статический анализ и методы трансформации программ. Эти методы помогают повысить продуктивность разработчиков при использовании ими автономных инструментов, расширений языков программирования и плагинов для IDE.
Существенная часть исследований посвящена изучению возможностей по расширению Kotlin. Мы верим, что Kotlin можно продолжать улучшать и расширять. Например, это могут быть макросы, liquid-типы, pattern matching, вариативные дженерики. Также в лаборатории занимаются исследованием применения
конколического тестирования в Kotlin, различных техник фаззинга компилятора и других областей.


Лаборатория верификации и анализа программ (VorPAL)


Вернуться к списку исследовательских групп


Лаборатория инструментов совместной работы


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


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


Вернуться к списку исследовательских групп



Если вы хотите присоединиться к какой-либо из групп, создать совместный проект или у вас есть общие вопросы, пишите нам по адресу info@research.jetbrains.org.


Благодарим Ольгу Андреевских за помощь в подготовке этой публикации.



Ваша команда JetBrains Research
The Drive to Develop
Подробнее..

Перевод Как тестировали в 2020 технологии QA, общемировая статистика и тренды

19.03.2021 16:09:40 | Автор: admin

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

Кому будет полезно: QA-лидам, тест-дизайнерам, тест-менеджерам, другим неравнодушным.

Тенденции инструментов тестирования

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

  • Согласно отчету PractiTest, 47% опрошенных тестировщиков используют инструменты для тестирования или обеспечения качества, такие как HP ALM, Team Foundation Server, PractiTest или Xray.

  • Согласно отчету JetBrains, 44% разработчиков регулярно используют баг-трекинговые инструменты, а 10% используют инструменты для проверки кода, такие как Collaborator, Review Assistant или CodeScene.

  • Самым распространенным баг-трекером остается Jira (68%). На втором месте GitHub Issues (26%).

В исследовании Russia Quality Report от Performance Lab за 2020 год говорится, что Jira в качестве TMS используют 73% российских компаний, 29% применяют Excel. Свои разработки в этой сфере применяют 13% опрошенных.

Что касается инструментов автоматизации, в совместно подготовленном исследовании QATestLab и Test IT говорится о том, что наиболее популярными для веб-тестирования являются Selenium и Apache JMeter, для API Postman.

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

Тенденции методик тестирования

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

  • Самая распространенная модель тестирования разработки программного обеспечения Agile или нечто похожее на Agile: 87% компаний использовали этот подход в 2019 году. Следующим шагом был DevOps с показателем 36% по сравнению с 28% в 2018 году (по данным PractiTest).

  • 82% компаний используют исследовательское тестирование в качестве методологии тестирования программного обеспечения, а 61% используют обычную проверку на основе сценариев (по данным PractiTest).

  • 78% организаций используют автоматизацию тестирования для функционального и регрессионного тестирования. Только 11% компаний не автоматизируют тесты (по данным PractiTest).

Рост популярности Agile в России, впрочем, не означает, что отечественные компании перестали сталкиваться с проблемами при внедрении в практику гибких методологий разработки. Согласно исследованию Russia Quality Report, чаще всего опрошенные указывали на невозможность применения автоматизации тестирования в необходимом объеме. Еще 17% респондентов отметили недостаточное понимание подходов Agile к тестированию.

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

Тенденции разработки ПО

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

  • Наиболее востребованным языком программирования на сегодняшний день является Rust (83,5%), за ним следует Python (73,1%). Разработчики больше всего не любили VBA (75,2%), а Python хочет изучить 25,7% опрошенных программистов (StackOverflow).

  • 25% сотрудников мировой IT-индустрии считают, что самая большая проблема, стоящая перед стартапами, приоритизировать разработку ПО (CodingSans).

  • Безопасность горячая тема: 69% респондентов отметили, что разработчики должны уметь писать безопасный код, но 68% считают, что добрая половина разработчиков не может самостоятельно обнаружить уязвимые части кода, которые обнаруживаются позже (GitHub).

Тенденции тестирования ПО

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

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

  • Тестировщики часто выполняют работу за рамками своей роли в компании. 74% тестировщиков также пишут сценарии и делают автоматизацию, 57% также выполняют тесты управления данными (PractiTest).

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

  • Web по-прежнему является самой популярной платформой для тестирования, 77% тестировщиков работали над web-тестированием в 2019 году. Это меньше, чем 79% в 2018 году (PractiTest).

Также важной частью QA-процесса является нагрузочное тестирование.

Тенденции QA-команд

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

  • Сложности: 44% тестирующих команд назвали сложным или невозможным участие в проектах своей компании в начале процесса, в то время как 43% командам трудно работать с данными и тестовыми средами (PractiTest).

  • Состав: 48% QA-команд состояли из 1-5 сотрудников, а 24% имели от 6 до 15 тестировщиков в 2019 году (PractiTest).

  • Задачи: по статистике, 63% задач команд по тестированию связаны с анализом требований, 55% задач связаны с ретроспективными встречами по проектам.

Карьерные тенденции в QA

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

  • Только 18% тестировщиков планировали стать тестировщиками ПО и изучали процессы. 24% стали тестировщиками случайно (PractiTest).

  • 65% получили знания о тестировании ПО в процессе самого тестирования. 58% читали книги по тестированию, а 44% закончили курсы и получили профильные сертификаты (PractiTest).

  • 75% отметили важность коммуникативных навыков, 63% назвали необходимым умение писать тестовые сценарии и умение автоматизировать тесты (PractiTest).

Тенденции дефектов ПО

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

  • Баг-репорты являются наиболее распространенной тестовой документацией, используемой компаниями 79% пользователей отмечают их использование (PractiTest).

  • 76% тестировщиков использовали баг-трекеры, такие как Jira Bugzilla или Redmine, что делает их наиболее распространенным инструментом управления тестированием. Следующим по популярности инструментом был Agile Workflow tools (59%) (PractiTest).

  • Наиболее распространенной ошибкой на проде было выкатывание непроверенного или сломанного кода более чем на 60%. Второй наиболее распространенной ошибкой была удаленная база данных (HackerRank).

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

Другие тенденции QA

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

  • В 2019 году 36% тестировщиков были подотчетны PM, по сравнению с 43% в 2018. 34% тестировщиков отчитывались перед руководителем отдела разработки (PractiTest).

  • 73% разработчиков заявили. что научились программированию самостоятельно, чуть меньшее количество училось разработке на курсах или в университете (69%) (HackerRank).

  • На 100 тыс. человек приходится 5,2 тестировщиков. В Ирландии самый высокий процент тестировщиков на душу населения 61,2 на 100 тыс. человек. Далее следуют США и Канада, затем в списке Израиль (QualiTest Group).

Согласно исследованию Russia Quality Report, в России большинство работодателей не считает, что профильное образование в сфере IT или дополнительные сертификаты так уж необходимы тестировщику. Значение придается наличию у соискателя опыта работы (в среднем - 1-3 года) и таким личным качествам, как внимательность, ответственность и дотошность.

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

Помните, баги всегда прячутся в самых неожиданных местах. Удачи!

Перевод статьи

Автор: Nuala Turner

Также при подготовке использовался источник RQR2020 и исследование QATestLab и Test IT

Подробнее..

Перевод Переосмысление предобучения и самообучения

21.04.2021 18:22:57 | Автор: admin

Перевод статьи подготовлен в преддверии старта курса "Deep Learning. Basic".

Предлагаем также всем желающим посмотреть запись вебинара
Knowledge distillation: нейросети обучают нейросети.


В конце 2018 года исследователи из FAIR опубликовали статью Переосмысление предобучения в ImageNet, которая впоследствии была представлена на ICCV2019. В статье представлены некоторые очень интересные выводы относительно предобучения. Я тогда не стал посвящать этому событию отдельный пост, но мы долго обсуждали его в нашем слаке (KaggleNoobs). Исследователи из Google Research and Brain team предложили расширенную версию той же концепции. Их новая публикация затрагивает не только тему предобучения (pre-training), она также исследует самообучение (self-training), сравнивая его с предобучением и обучением без учителя (self-supervised learning) на тех же наборах задач.

Введение

Прежде чем мы углубимся в детали, представленные в публикации, давайте сделаем один шаг назад и обсудим сначала несколько понятий. Предобучение очень распространенная практика в различных областях, таких как компьютерное зрение, NLP и генерация речи. Когда речь заходит о компьютерном зрении, мы ожидаем, что модель, предварительно обученная на одном наборе данных, поможет другой модели. Например, предобучение ImageNet с учителем является широко используемым методом инициализации для моделей обнаружения и сегментации объектов. Трансферное обучение (transfer learning) и точная настройка (fine-tuning) два распространенных метода для реализации этой затеи.

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

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

Что ж, хватит болтовни! Мудреные определения в сторону, ведь вы до сих пор не понимаете, о чем конкретно эта статья? Или мы собрались здесь, чтобы определения почитать?

Мотивация

Мы используем эти методы уже достаточно давно. Авторы заинтересованы в том, чтобы найти ответы на следующие вопросы:

  1. Насколько может помочь предобучение? Когда предобучение не приносит пользы?

  2. Можем ли мы использовать самообучение вместо предобучения и получить аналогичные или лучшие результаты по сравнению с предобучением и обучением без учителя?

  3. Если самообучение превосходит предобучение (если предположить, что это так), то насколько оно лучше, чем предобучение?

  4. В каких случаях самообучение лучше предобучения?

  5. Насколько самообучение гибкое и масштабируемое?

Сетап

Наборы данных и модели

  1. Обнаружение объектов: авторы использовали набор данных COCO (118K изображений) для обнаружения объектов с применением обучения с учителем. ImageNet (1,2М изображений) и OpenImages (1,7М изображений) использовались в качестве немаркированных наборов данных. Были использован детектор RetinaNet с EfficientNet-B7 в качестве базовой сети (backbone). Разрешение изображений было до 640 x 640, слои пирамиды от P3-P7 и использовались 9 якорей на пиксель.

  2. Семантическая сегментация: для обучения с учителем использовался набор для обучения сегментации PASCAL VOC 2012 (1,5K изображений). Для самообучения авторы использовали аугментированный набор данных PASCAL (9K изображений), COCO (240K размеченных, а также неразмеченных изображений) и ImageNet (1,2M изображений). Использовалась модель NAS-FPN с EfficientNet-B7 и EfficientNet-L2 в качестве базовых сетей.

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

Аугментация данных

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

  1. Augment-S1: это стандартная Flip and Crop (переворот и кадрирование) аугментация. Стандартный метод flip and crop состоит из горизонтальных переворотов изображения и флуктуаций масштаба (scale jittering). Операция флуктации также может быть случайной, так же как то как мы изменяем размер изображения до (0.8, 1.2) от размера исходного изображения, а затем обрезаем его.

  2. Augment-S2: состоит из AutoAugment и переворотов и кадрирований.

  3. Augment-S3: включает сильную флуктуацию масштаба, AutoAugment, перевороты и кадрирование. Флуктуация масштаба увеличен до (0.5, 2.0).

  4. Augment-S4: комбинация RandAugment, переворотов и кадрирования и сильной флуктуацией масштаба. Флуктуация масштаба такая же, как и в Augment-S2/S3.

Предварительное обучение

Для изучения эффективности предобучения использовались предварительно обученные контрольные точки (checkpoints) ImageNet. EfficientNet-B7 архитектура, используемая для оценки. Для этой модели использовались две разные контрольные точки. Они обозначаются как:

  1. ImageNet: контрольная точка EfficientNet-B7, обученная с помощью AutoAugment, которая достигает 84,5% top-1 точности в ImageNet.

  2. ImageNet++: контрольная точка EfficientNet-B7, обученная с помощью метода Noisy Student, который использует дополнительные 300 млн неразмеченных изображений и обеспечивает 86,9% top-1 точности.

Обучение из случайной инициализации обозначается как Rand Init.

Самообучение

Реализация самообучения основана на алгоритме Noisy Student и состоит из трех этапов:

  1. Модель-учитель обучается на размеченных данных, например, на наборе данных COCO.

  2. Затем модель-учитель используется для создания псевдометок для неразмеченных данных, например ImageNet.

  3. Модель-ученик обучается оптимизировать потери на человеческой разметке и псевдо-метках одновременно.

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

Эксперименты

Влияние увеличения и размера размеченного набора данных на предобучение

Авторы использовали ImageNet для предварительного обучения с учителем и варьировали размер размеченного набора данных COCO для изучения эффекта предобучения. Разнился не только размер размеченных данных, но и аугментации разной силы для обучения RetinaNet с EfficientNet-B7 в качестве базовой сети. Авторы наблюдали следующие факты:

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

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

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

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

Влияние увеличения и размера размеченного набора данных на самообучение

Теперь, когда мы увидели влияние предварительного обучения, пришло время проверить результаты с той же задачей (в данном случае обнаружение объекта COCO) с той же моделью (RetinaNet детектор с базой EfficientNet-B7), но на этот раз с самообучением. Авторы использовали для самообучения набор данных ImageNet (метки для ImageNet в этом случае отбрасываются). Авторы отметили следующее:

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

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

Погодите-ка секундочку! Когда используется ImageNet++ init, выигрыш невелик по сравнению с выигрышем в Rand init и ImageNet init. Есть какая-то конкретная причина?

Да, ImageNet++ init получается из контрольной точки, для которой использовались дополнительные 300M неразмеченных изображений.

Предварительное обучение с учителем против самообучения

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

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

Не хочется вас разочаровывать, но ответ НЕТ. Чтобы исследовать эффекты обучения без учителя, авторы использовали полный набор данных COCO и сильнейшие аугментации. Цель состояла в том, чтобы сравнить случайную инициализацию с моделью, предварительно обученной с помощью современного алгоритма с обучения без учителя. Контрольная точка для SimCLR в этом эксперименте использовалась до того, как она была тонко настроена (fine-tuned) в ImageNet. Поскольку SimCLR использует только ResNet50, основа детектора RetinaNet была заменена на ResNet50. Вот результаты:

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

Что мы узнали?

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

Мы увидели, что предварительное обучение (как контролируемое, так и самостоятельное) не всегда приводит к повышению эффективности. Более того, оно всегда уступает самообучению. Почему так происходит? Почему предобучение ImageNet не так хорошо для обнаружения объектов COCO? Почему представления, полученные с помощью предобучения без учителя, не помогли повысить эффективность?

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

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

Совместное обучение

Как указали авторы, одна из сильных сторон парадигмы самообучения состоит в том, что оно совместно обучает цели с учителем и цели самообучения, тем самым устраняя несоответствие между ними. Мы всегда можем утверждать, что вместо того, чтобы искать какой-либо другой метод устранения несоответствия различий между задачами, почему мы не можем обучаться вместе, например, совместно обучая ImageNet и COCO?

Авторы использовали тот же сетап, что и при самообучении для этого эксперимента, и обнаружили, что предобучение ImageNet дает улучшение +2,6AP, но использование случайной инициализации и совместного обучения дает больший выигрыш +2,9AP. Более того, предобучение, совместная тренировка и самообучение все могут работать вместе. Используя тот же источник данных ImageNet, предобучение ImageNet получает улучшение +2,6AP, предобучение + совместное обучение дает +0,7AP, а комбинация предобучения + совместного обучение + самообучение дает улучшение +3,3AP.

Важность согласования задач

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

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

  2. При сильной аугментации данных (Augment-S4) обучение с помощью PASCAL (наборы данных для обучения + аугментация) на самом деле снижает точность. Между тем, псевдометки, созданные путем самообучения на одном и том же наборе данных, повышают точность.

Масштабируемость, универсальность и гибкость самообучения

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

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

  2. Самообучение не зависит от архитектуры или набора данных. Он хорошо работает с различными архитектурами, такими как ResNets, EfficientNets, SpineNet и т. д., а также с различными наборами данных, такими как ImageNet, COCO, PASCAL и т. д.

  3. В общем, самообучение хорошо работает, когда предобучение терпит неудачу, но также и когда предобучение обучение тоже работает хорошо.

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

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

Ограничения самообучения

Хотя у самообучение есть свои преимущества, у него также есть несколько ограничений.

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

  2. Ускорение от предобучения варьируется от 1,3x до 8x, в зависимости от качества предобученной модели, силы аугментации данных и размера набора данных.

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

Заключение

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


Узнать подробнее о курсе "Deep Learning. Basic".

Смотреть запись вебинара Knowledge distillation: нейросети обучают нейросети.

Подробнее..

Крошка Енот как операторы JS-сниффера FakeSecurity распространяли стилер Raccoon

07.12.2020 12:09:16 | Автор: admin


Летом 2020 года специалисты Group-IB обратили внимание на необычную кампанию по распространению стилера Raccoon. Сам стилер хорошо известен: он умеет собирать системную информацию, данные учетных записей в браузерах, данные банковских карт, а также ищет информацию о крипто-кошельках.

Сюрприз оказался в другом. Никита Ростовцев, аналитик Group-IB Threat Intelligence & Attribution, рассказывает, как в ходе исследования удалось восстановить хронологию вредоносной кампании, установить связи с другими элементами инфраструктуры злоумышленников. Забегая вперед, отметим, что енот оказался прикормленным уже известной нам группой.

Начнем с того, что сам стилер Raccoon распространяется по модели Malware-As-a-Service на одном из даркнет-форумов в связке с Telegram-каналами для того, чтобы обходить блокировку актуальных C&C-серверов.


Мы разделили кампанию на четыре этапа, которые отличаются используемыми инструментами (типом вредоносного ПО, регистраторами для создания инфраструктуры и т.п.):

  • Первая волна: 19 февраля 5 марта 2020 года
  • Вторая волна: 13 марта 22 мая 2020 года
  • Третья волна: 29 июня 2 июля 2020 года
  • Четвертая волна: 24 августа 12 сентября 2020 года


Большинство доменов в рамках исследуемой кампании были зарегистрированы у двух регистраторов Cloud2m и Host Africa. Cloud2m использовался в более ранних атаках. В середине июля 2020 года некоторые из этих доменов переехали на Host Africa.


Таймлайн вредоносных кампаний хакерской группы FakeSecurity

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

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


Схема заражения жертв в кампаниях хакерской группы FakeSecurity

Схема распространения вредоносного ПО напомнила нашим экспертам паттерн, который использовали операторы семейства JS-сниффера FakeSecurity в кампании, описанной в ноябре 2019 года. Помимо сходств в инструментариях двух серий атак, они обе были нацелены на e-commerce-компании. Так, в мае 2020-го эксперты Group-IB обнаружили онлайн-магазины, которые были заражены модифицированным JS-сниффером из кампании FakeSecurity. JS-сниффер был обфусцирован при помощи aaencode, а для хранения кода и сбора украденных данных банковских карт использовались домены, которые были зарегистрированы в период активности второй волны и у тех же регистраторов, что и домены, которые мы обнаружили в исследуемой вредоносной кампании. Таким образом, за компанией по распространению стилеров, как мы считаем, стоят операторы JS-сниффера FakeSecurity.


Доменная инфраструктура вредоносных кампаний FakeSecurity

Первая волна


Первая волна регистрации доменов началась в зоне co.za 19 февраля 2020 года. Подозрительные домены содержали ключевые слова cloud, document и Microsoft. Примеры доменов, зарегистрированных в первую волну:

msupdater[.]co.za 2020-02-19
documents-cloud-server[.]co.za 2020-03-05
cloudupdate[.]co.za 2020-02-21

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

Документы с макросами


Уже спустя девять дней после регистрации первого домена, 28 февраля, на VirusTotal через веб-интерфейс из США был загружен файл Bank001.xlsm (SHA1: b1799345152f0f11a0a573b91093a1867d64e119):


Этот файл является документом-приманкой с вредоносными макросами, который при их активации загружает полезную нагрузку из cloudupdate.co[.]za/documents/msofficeupdate.exe.

Частично обфусцированный в Base64 вредоносный макрос группы FakeSecurity

В результате происходит выполнение файла msofficeupdate.exe (SHA1: f3498ba783b9c8c84d754af8a687d2ff189615d9). C&C-сервером данного образца является badlandsparks[.]com. Этот домен был зарегистрирован 27 февраля 2020 года и связан с IP-адресом 185.244.149[.]100. Только к этому домену производят сетевое подключение более 30 файлов.

Связанная c доменом инфраструктура, выстроенная с помощью технологии графого анализа Group-IB Threat Intelligence & Attribution

Среди таких файлов присутствуют 13b7afe8ee87977ae34734812482ca7efd62b9b6 и 596a3cb4d82e6ab4d7223be640f614b0f7bd14af. Эти файлы производят сетевое подключение одновременно к gineuter[.]info, fastandprettycleaner[.]hk и к badlandsparks[.]com. Судя по запросам, которые они выполняют для загрузки библиотек, и данным из открытых источников, файл msofficeupdate.exe и подобные ему являются образцами стилера Vidar. Этот стилер злоумышленники используют для кражи данных из браузеров, в том числе истории просмотров веб-страниц и данных учетных записей, а также данных банковских карт, файлов крипто-кошельков, переписок в мессенджерах и т.д.

Админ-панель стилера Vidar

Сетевое взаимодействие образца SHA1: 596a3cb4d82e6ab4d7223be640f614b0f7bd14af (построено с помощью графа Group-IB TI&A)

Список специфичных для Vidar HTTP-запросов, а также его подробный обзор доступен по ссылке:

/ (i.e 162) <- Config
ip-api.com/line/ <- Get Network Info
/msvcp140.dll <- Required DLL
/nss3.dll <- Required DLL
/softokn3.dll <- Required DLL
/vcruntime140.dll <- Required DLL
/ <- Pushing Victim Archive to C2


Файл BankStatement1.xlsm (SHA1: c2f8d217877b1a28e4951286d3375212f8dc2335) также является документом-приманкой с вредоносными макросами и при их активации загружает файл из download-plugin[.]co.za/documents/msofficeupdate.exe. Загружаемый файл SHA1: 430a406f2134b48908363e473dd6da11a172a7e1 также является стилером Vidar и доступен для загрузки из:

  • download-plugin.co[.]za/documents/msofficeupdate.exe
  • msupdater.co[.]za/documents/msofficeupdate.exe
  • cloudupdate.co[.]za/documents/msofficeupdate.exe

Пример доступности файла 430a406f2134b48908363e473dd6da11a172a7e1 из разных источников

Фишинг-кит Mephistophilus


Вторым исходным вектором в рамках первой волны атак было использование фейковых веб-страниц для распространения вредоносного ПО.

Так, обнаруженные домены msupdater[.]co.za, cloudupdate[.]co.za и documents-cloud-server[.]co.za имели одинаковую А-запись 160.119.253[.]53 в одно и то же время. Судя по данным графового анализа Group-IB, на сайте documents-cloud-server[.]co.za находился фишинг-кит Mephistophilus.

Связанная инфраструктура указанных доменов (построено с помощью графа Group-IB TI&A)

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

  • онлайн-просмотрщик документов Microsoft Office 365, Word или Excel
  • онлайн-просмотрщик PDF-файлов
  • страница-клон сервиса YouTube



Административная панель Mephistophilus


Фейковое окно обновления Adobe Reader

На домене documents-cloud-server[.]co.za находится веб-фейк, имитирующий страницу обновления плагина для Adobe Reader. Чтобы продолжить чтение документа, пользователю требуется скачать плагин. После того как жертва кликает Download plugin, загружается вредоносный файл по ссылке www[.]documents-cloud-server[.]co.za/file_d/adobe-reader-update-10.21.01.exe.

<!DOCTYPE html><html><head><title>Statment00810012.pdf</title><link href="http://personeltest.ru/aways/fonts.googleapis.com/css?family=Roboto" rel="stylesheet"><link rel="stylesheet" href="http://personeltest.ru/away/www.documents-cloud-server[.]co.za/view/pdf_v3/css/style.css"><script type="text/javascript" src="http://personeltest.ru/away/www.documents-cloud-server [.]co.za/view/pdf_v3/js/jquery.js"></script></head><body topmargin="0" leftmargin="0"><div class="toolbar"></div><div class="layer"><div class="tab"><table width="100%" height="100%" cellpadding="0" cellspacing="0"><tr><td class="tdo" width="307" valign="top" align="center"><div class="logo"></div><br><br><br><div class="bottom-text" align="center">Copyright  2017 Adobe Systems<br> Software Ireland Ltd. <br>All rights reserved</div></td><td class="tds" width="493" valign="top" align="center"><h2>Plugin update required</h2><span class="text">This document cannot be displayed correctly<br>You are using an older version of Adobe Reader PDF Plugin<br>for Google Chrome<br></span><br><br><br><a class="button" data-url="http://personeltest.ru/away/www.documents-cloud-server[.]co.za/file_d/adobe-reader-update-10.21.01.exe">Download plugin</a><br><br><br><br><div class="bottom-text" align="center"><a href="http://personeltest.ru/aways/www.adobe.com/" target="_blank" class="link">Adobe</a> / <a href="http://personeltest.ru/aways/www.adobe.com/legal/terms.html" target="_blank" class="link">Terms of Use</a> / <a href="http://personeltest.ru/aways/www.adobe.com/privacy.html" target="_blank" class="link">Privacy</a></div></td></tr></table></div></div><script>setTimeout(function(){var width = $(window).width();var height = $(window).height();$('.layer').show();$('.layer').animate({'height':height}, 1000);setTimeout(function(){$('.tab').show();},1200);},1800);$('.button').click(function(){$.post(location.href, {dl:"dlPDF2",cname:"Statement00810011"});var link = $(this).attr("data-url");window.open(link);});$(window).resize(function(){var width = $(window).width();var height = $(window).height();$('.layer').css("width",width);$('.layer').css("height",height);});</script></body></html>

Исходный код фишинговой страницы


Файл с таким же именем adobe-reader-update-10.21.01.exe впервые был загружен на VirusTotal 13 марта 2020 года и был доступен для загрузки по следующим ссылкам:

  • documents-cloud-server5[.]co.za/file_d/adobe-reader-update-10.21.01.exe
  • documents-cloud-server1[.]co.za/file_d/adobe-reader-update-10.21.01.exe
  • documents-cloud-server9[.]co.za/file_d/adobe-reader-update-10.21.01.exe
  • documents-cloud-server8[.]co.za/file_d/adobe-reader-update-10.21.01.exe

Пример доступности файла f33c1f0930231fe6f5d0f00978188857cbb0e90d из разных источников

Другой файл msofficeupdater.exe (SHA1: bdfefdff7b755a89d60de22309da72b82df70ecb) был доступен по следующим путям:

  • documents-cloud-server7[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server5[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server7[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server6[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server1[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server6[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server5[.]co.za/doc/msofficeupdater.exe
  • documents-cloud-server1[.]co.za/doc/msofficeupdater.exe

Пример доступности файла bdfefdff7b755a89d60de22309da72b82df70ecb из разных источников

Вторая волна


Домены, связанные с файлом SHA1: bdfefdff7b755a89d60de22309da72b82df70ecb, вывели нас на еще одну группу доменов, относящихся к инфраструктуре злоумышленников. Эти домены были зарегистрированы в два этапа: первая группа 13 марта 2020 года, вторая 22 мая 2020 года.

Примеры доменов второй волны:

1 группа 2 группа
cloud-server-updater[.]co.za cloud-server-updater17[.]co.za
cloud-server-updater1[.]co.za cloud-server-updater18[.]co.za
cloud-server-updater15[.]co.za cloud-server-updater27[.]co.za
cloud-server-updater16[.]co.za cloud-server-updater28[.]co.za

Эти домены были созданы для распространения стилера Raccoon. Чтобы связать данные группы доменов, можно взглянуть на файлы SHA1: b326f9a6d6087f10ef3a9f554a874243f000549d и SHA1: F2B2F74F4572BF8BD2D948B34147FFE303F92A0F. Эти файлы в процессе работы устанавливают сетевое соединение со следующими ресурсами:

  • cloudupdates[.]co.za
  • cloud-server-updater2[.]co.za
  • cloud-server-updater19[.]co.za

Сетевое взаимодействие файла b326f9a6d6087f10ef3a9f554a874243f000549d (построено с помощью графа Group-IB TI&A)

C доменом cloudupdates[.]co.za связано порядка 50 вредоносных файлов из публичных источников. Их первые загрузки датируются 30 апреля 2020 года, а сам домен похож на найденный ранее cloudupdate.co[.]za. Кроме схожего имени домена, он зарегистрирован через регистратора cloud2m, а в качестве NS-записей у него указаны ns1.host-ww.net и ns2.host-ww.net так же, как и у msupdater[.]co.za и cloudupdate[.]co.za.

Данные из WHOIS-записей трёх доменов

Со всеми доменами второй волны связано порядка 300 файлов из публичных песочниц. Все эти файлы являются документами-приманками, содержащими вредоносные макросы, с названиями MyBankStatement_2436.xlsm, MyBankStatement_3269.xlsm, MyBankStatement_5763.xlsm и т.п.

Образец документа-приманки 6685955C5F006C2D83A92952EB5EB3FB9598C783

Один из таких файлов MyBank_5710.xlsm (SHA1: 6685955C5F006C2D83A92952EB5EB3FB9598C783). После активации макросов в этом документе происходила загрузка файла из cloud-server-updater22[.]co.za/doc/officebuilder. Загруженный файл c SHA1: 3657CF5F2142C7E30F72E231E87518B82710DC1C является стилером Raccoon. Он подключается к своему C&C-серверу (35.228.95[.]80) для эксфильтрации собранной информации, используя инфраструктуру Google для придания легитимности запросам. В свою очередь Raccoon производит сетевое подключение к cloud-server-updater1[.]co.za/doc/officeupdate.exe для загрузки RAT AveMaria (SHA1: a10925364347bde843a1d4105dddf4a4eb88c746), C&C-сервер которого расположен на IP-адресе 102.130.118[.]152.

AveMaria RAT это троян удаленного доступа, который был обнаружен в конце 2018 года, когда он использовался для атак на итальянскую организацию, работающую в нефтегазовом секторе. Функциональные возможности данного RAT:

  • Повышение привилегий, поддержка от Windows 7 до Windows 10;
  • Персистентность;
  • Инжект кода;
  • Кейлоггер;
  • Доступ к камере;
  • Управление процессами;
  • Управление файлами: создание, загрузка, скачивание, удаление;
  • RDP с использованием rdpwrap;
  • Функция инфостилера:

  1. Google Chrome;
  2. Firefox;
  3. Internet Explore;
  4. Outlook;
  5. Thunderbird;
  6. Foxmail.


Последовательность выполнения файла 6685955C5F006C2D83A92952EB5EB3FB9598C783

Во время исполнения Raccoon выполняет следующие сетевые запросы:

Сетевые запросы файла 3657CF5F2142C7E30F72E231E87518B82710DC1C

Среди этих сетевых запросов присутствует подключение к Telegram-каналу с названием blintick.

Создатели Raccoon использовали Telegram для обхода блокировок C&C-серверов. Так, стилер выполняет запрос к Telegram-каналу, из описания которого получает зашифрованный адрес нового C&C-сервера. Первые образцы, использующие эту технику, начали появляться на VirusTotal уже в конце мая 2020 года.

Сообщение авторов стилера Raccoon

Telegram-канал blintick и его описание:


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

Третья волна


29 июня 2020 года началась регистрация доменов третьей волны:

  • microsoft-cloud1[.]co.za
  • microsoft-cloud6[.]co.za
  • microsoft-cloud7[.]co.za
  • microsoft-cloud8[.]co.za
  • microsoft-cloud9[.]co.za
  • microsoft-cloud10[.]co.za
  • microsoft-cloud11[.]co.za
  • microsoft-cloud12[.]co.za
  • microsoft-cloud13[.]co.za
  • microsoft-cloud14[.]co.za
  • microsoft-cloud15[.]co.za

Все зарегистрированные домены указывали на IP-адрес 102.130.112[.]195. Первые вредоносные файлы, связанные с этой волной, начали появляться в публичных песочницах уже 2 июля 2020 года. Названия этих документов-приманок почти ничем не отличаются от названия файлов, рассылаемых в прошлом: BankStatement0109_13169.xlsm, My_Statement_4211.xlsm и т.д. С вышеупомянутыми доменами, а также с доменом cloud-server-updater1[.]co.za связано порядка 30 файлов:

Сетевая инфраструктура. Связь файлов с доменами двух волн

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

Пример документа-приманки 618C894C06633E3D7ADD228531F6E775A180A7F7

Один из анализируемых файлов, My_Statement_1953.xlsm (SHA1: 618C894C06633E3D7ADD228531F6E775A180A7F7), во время активации макросов выполняет запрос к серверу для загрузки файла из microsoft-cloud13[.]co.za/msofficeupdate.exe. Данный файл также представляет собой стилер Raccoon. Файл стилера (SHA1: 6639081791A8909F042E4A4197DF7051382B04E5) выполняет серию запросов на свой C&C-сервер 35.198.88[.]195, а также пытается загрузить файл из cloud-server-updater1[.]co.za/doc/officeupdate.exe, но получает в ответ ошибку 302 и редирект на cloud-server-updater1[.]co.za/cgi-sys/suspendedpage.cgi вследствие блокировки оригинального домена. По всей видимости, данный образец пытался загрузить RAT AVEMARIA, как и в предыдущей волне. Кроме того, все файлы данной кампании производили сетевые запросы в том числе и к вышеупомянутому Telegram-каналу telete.in/blintick.

Сетевое взаимодействие Raccoon стилера 6639081791A8909F042E4A4197DF7051382B04E5 (построено с помощью графа Group-IB TI&A)

Использование загрузчиков


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

30 апреля 2020 года на VirusTotal был загружен xls-документ (SHA1: 6c6680659b09d18ccab0f933daf5bf1910168b1a). Во время исполнения вредоносного кода он загружает полезную нагрузку из cloud-server-updater2.co[.]za/doc/buer.exe.

Сетевое взаимодействие файла SHA1:6c6680659b09d18ccab0f933daf5bf1910168b1a (построено с помощью графа Group-IB TI&A)
Кроме того, эти файлы были загружены и на публичный ресурс bazaar.abuse.ch.

Название файлов и проставленные теги относят нас к Buer Loader: bazaar.abuse.ch/sample/bc96c38e3f85c43923a37f57c096eb5b3913b516dbcb11b46cb9cfd0c1d167ce/.

Сетевое взаимодействие файла SHA1:7b1a5d9bb21d852a6dbf3146fabb1cd1ca276ed9
(построено с помощью графа Group-IB TI&A)

В ходе мониторинга инфраструктуры злоумышленников мы выявили группу связанных доменов, которая была зарегистрирована в период с 24 августа по 12 сентября 2020 года. Пример таких доменов:

Domain name Data IP-address
code-cloud[1-6][.]co.za 24.08.2020 102.130.115.44
google-document[.]co.za 24.08.2020 102.130.115.44
azure-cloud[1-4][.]co.za 4.09.2020 102.130.119.232
azure-cloud[1-3].web.za 4.09.2020 102.130.119.232
Updateadobeonline[.]co.za 8.09.2020 102.130.115.44
Updateforadobenew[.]co.za 9.09.2020 102.130.118.209
Oneupdateadobe[1-4][.]co.za 9.09.2020 102.130.118.209
Updateadobe[.]co.za 12.09.2020 102.130.121.74

Схожие WHOIS-записи доменов

WHOIS-записи этих доменов совпадают с WHOIS-записями доменов, ранее замеченных в этой кампании. Уже 26 августа 2020 года на публичных ресурсах начали появляться вредоносные файлы, связанные с доменами code-cloud[1-6][.]co.za и google-document[.]co.za. Один из таких файлов BankStatement_1390868739.doc (SHA1: ed5c20371bae393df0a713be72220b055e5cbdad).

Сетевое взаимодействие файла SHA1: ed5c20371bae393df0a713be72220b055e5cbdad (построено с помощью графа Group-IB TI&A)

В процессе выполнения вредоносного кода этот файл загружает полезную нагрузку из google-document[.]co.za/doc/loader.exe. Сигнатурный анализ показал, что загружаемый файл является образцом Smoke Loader.

Анализ файла loader.exe и проставленный тег Smoke loader

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

Четвертая волна


Часть доменов, зарегистрированных в начале сентября 2020 года, мимикрировала под Adobe в своих названиях. Уже начиная с 14 сентября 2020 года на этих хостах, как и в первой волне, был обнаружен Mephistophilus с идентичным шаблоном.

Связь между Mephistophilus-инфраструктурой кампаний 2019 и 2020 года


Скриншот страницы-приманки Mephistophilus

Нажатие на кнопку Download plugin приводит к загрузке файла SHA1: bcfb45e5451435530156f1f02ddbb9cadf6338e9 из updateforadobenew[.]co.za/file_d/adobe-reader-v13.11.1.3.exe, который является стилером Raccoon.

Результат анализа вредоносного файла из модуля Polygon комплексной системы Group-IB Threat Hunting Framework

Создание матрицы анализируемого файла

Примечание: Примерно в середине июля 2020 года, злоумышленники удалили свой Telegram-канал. Он был восстановлен 14 сентября 2020 года и в описании также содержал зашифрованный адрес актуального C&C-сервера. На момент написания данного исследования канал вновь неактивен.

Содержимое Telegram-канала blintick

Связь с FakeSecurity


Данная вредоносная кампания имеет явное сходство с серией атак с использованием семейства JS-снифферов FakeSecurity, описанной экспертами Group-IB в ноябре 2019 года. Жертвами прошлых атак стали владельцы сайтов онлайн-магазинов, работающих на CMS Magento. В описанной ранее кампании злоумышленники также использовали такие инструменты, как стилер Vidar и фиш-кит Mephistophilus с идентичным шаблоном под обновления для Adobe. Кроме того, в обеих кампаниях злоумышленники регистрировали домены на одних и тех же хостингах.

В кампании 2020 года мы видим использование такого же вектора атак с последующим распространением стилера Raccoon. Кроме того, в ходе исследования этой кампании мы обнаружили письма, отправленные нескольким онлайн-магазинам с email-адресов bezco.quise1988@wp.pl и outtia.lene1985@wp.pl.

При детальном исследовании первой волны распространения вредоносных программ через веб-фейки Mephistophilus мы обнаружили связь между доменами этой кампании, в частности documents-cloud-server*[.]co.za, и кампанией FakeSecurity. В кампании 2020 года веб-фейки были доступны по следующим URL:

Список доменов с идентичной структурой

Согласно ресурсу urlscan[.]io, с похожей структурой было доступно порядка 20 сайтов. Среди них выделяется alloaypparel[.]com. Этот домен использовался в кампании FakeSecurity.
С марта 2020 года специалисты Group-IB начали детектировать заражения онлайн-магазинов JS-сниффером, обфусцированным при помощи алгоритма aaencode (http://personeltest.ru/aways/utf-8.jp/public/aaencode.html). Вредоносный код подгружался с домена get-js[.]com. Домен get-js[.]com имел WHOIS-записи, схожие с ранее использованными доменами этой группы:

  • fiswedbesign[.]com
  • alloaypparel[.]com
  • firstofbanks[.]com
  • magento-security[.]org
  • mage-security[.]org


Связь между инфраструктурой группы FakeSecutiry кампании 2019 года и доменом get-js[.]com

Фрагмент кода JS-сниффера, обфусцированного при помощи алгоритма aaencode

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

Деобфусцированный код модифицированной версии сниффера FakeSecurity

В мае 2020 года специалисты Group-IB обнаружили новые заражения сайтов онлайн-магазинов. В ходе этой кампании снова использовался модифицированный сниффер FakeSecurity, обфусцированный при помощи aaencode. Вредоносный код внедрялся либо по ссылке при помощи тега script, либо путем модификации существующих JavaScript-файлов сайта. С помощью этого сниффера был скомпрометирован 21 онлайн-магазин. Для хранения кода и сбора украденных данных банковских карт в ходе новой кампании использовались следующие домены:

  • cloud-js[.]co.za
  • host-js[.]co.za
  • magento-cloud[.]co.za
  • magento-js[.]co.za
  • magento-security[.]co.za
  • marketplace-magento[.]co.za
  • marketplacemagento[.]co.za
  • node-js[.]co.za
  • node-js[.]co.za
  • payment-js[.]co.za
  • security-js[.]co.za
  • web-js[.]co.za

Дата их создания 24 апреля 2020 года (вторая волна). Эти домены были зарегистрированы у тех же регистраторов, что и домены, использовавшиеся для распространения стилеров Vidar, Raccoon, а также загрузчиков Buer и Smoke.

Формат ссылок на файлы JS-снифферов, а также используемое семейство вредоносного кода позволяют предположить, что за кампанией по заражению сайтов онлайн-магазинов стоят операторы семейства JS-снифферов FakeSecurity.

Кроме того, некоторые домены исследуемой кампании хостили страницу заглушки с надписью test page похожая страница заглушки хостится и на доменах FakeSecurity:

  • urlscan.io/result/0299b3e5-cbba-40be-adce-7ba437e4cb39/ microsoft-cloud10[.]co.za
  • urlscan.io/result/8f244d1b-2186-4db5-9c52-6122584dafa9/ documents-cloud-server[.]co.za





Варианты схожих заглушек test page на гейтах FakeSecurity и исследуемых доменах co.za

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

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


Для того, чтобы проверить свои системы защиты на готовность к отражению атак, описанных в нашем блоге, мы приводим матрицу MITRE ATT&CK и MITRE Shield. Все эти технологии защиты реализованы в новом классе решений Group-IB для исследования киберугроз и охоты за атакующими. При возникновении вопросов или подозрений на инцидент обращайтесь на response@cert-gib.com.

Tactics Techniques of adversaries Mitigations & Active Defense Techniques Group-IB mitigation & protection products
Reconnaissance T1595 Active Scanning

T1583. Acquire Infrastructure
M1016. Vulnerability Scanning Security Assessment
Initial Access T1566 Phishing

T1190 Exploit Public-Facing Application
M1049. Antivirus/Antimalware

M1031. Network Intrusion Prevention

M1021. Restrict Web-Based Content

M1017. User Training

M1050. Exploit Protection

M1051. Update Software

M1027. Password Policies

DTE0035. User Training

DTE0019. Email Manipulation

DTE0027. Network Monitoring
Threat Hunting Framework

Threat Intelligence & Attribution

Cyber Education

Red Teaming
Execution T1059. Command and Scripting Interpreter

T1204. User Execution

T1059.007. JavaScript/JScript
M1049. Antivirus/Antimalware

M1038. Execution Prevention

M1021. Restrict Web-Based Content

M1026. Privileged Account Management

DTE0035. User Training

DTE0021. Hunting

DTE0018. Detonate Malware

DTE0007. Behavioral Analytics

DTE0003. API Monitoring

DTE0034. System Activity Monitoring
Threat Hunting Framework

Red Teaming

Incident Response

Fraud Hunting Platform
Defense Evasion T1036. Masquerading

T1027. Obfuscated Files or Information
Credential Access T1056. Input Capture
M1049. Antivirus/Antimalware

DTE0007. Behavioral Analytics

DTE0003. API Monitoring

DTE0034. System Activity Monitoring
Threat Hunting Framework
Collection
Command and Control T1219. Remote Access Software M1038. Execution Prevention

M1031. Network Intrusion Prevention

DTE0021. Hunting

DTE0022. Isolation

DTE0027. Network Monitoring

DTE0003. API Monitoring

DTE0034. System Activity Monitoring

DTE0031. Protocol Decoder
Threat Hunting Framework
Exfiltration T1041. Exfiltration Over C2 Channel

P.S. Автор выражает благодарность Виктору Окорокову, аналитику Group-IB Threat Intelligence & Attribution, за помощь в подготовке данной публикации.

P.P.S. Если ты, также как и мы считаешь, что зло в любом цифровом обличии должно быть наказано, залетай посмотреть наши актуальные вакансии в департаменте Threat Intelligence & Attribution. Group-IB это новое поколение инженеров, воплощающих смелые инновационные идеи предотвращения кибератак, основанные на технологиях хантинга, слежения за атакующими, их тактикой, инструментами и инфраструктурой. Ежедневно мы боремся с международной киберпреступностью, создавая продукты и сервисы, способные защитить людей, бизнес и государства во всем мире. И если твои скилы могут пригодиться для того, чтобы создавать новые решения, пилить крутые интерфейсы, то у нас есть огромное количество вакансий в департаменте разработки. Присоединяйся!

Индикаторы
TG not mal telete[.]in/blintick

8623aq9z046whQWysOHRvL9zM/GAADZbWXUG4TKc3D8n3r00X34-v70

73309q9z046whQWytOHdtItzM+WEADZfJFUetXe10DMG+8VUP7A==26-v30
Raccoon cloud-server-updater[.]co.za

cloud-server-updater1[.]co.za

cloud-server-updater2[.]co.za

cloud-server-updater3[.]co.za

cloud-server-updater4[.]co.za

cloud-server-updater5[.]co.za

cloud-server-updater6[.]co.za

cloud-server-updater7[.]co.za

cloud-server-updater8[.]co.za

cloud-server-updater9[.]co.za

cloud-server-updater10[.]co.za

cloud-server-updater11[.]co.za

cloud-server-updater12[.]co.za

cloud-server-updater13[.]co.za

cloud-server-updater14[.]co.za

cloud-server-updater15[.]co.za

cloud-server-updater16[.]co.za

cloud-server-updater17[.]co.za

cloud-server-updater18[.]co.za

cloud-server-updater19[.]co.za

cloud-server-updater20[.]co.za

cloud-server-updater21[.]co.za

cloud-server-updater22[.]co.za

cloud-server-updater23[.]co.za

cloud-server-updater24[.]co.za

cloud-server-updater25[.]co.za

cloud-server-updater26[.]co.za

cloud-server-updater27[.]co.za

cloud-server-updater28[.]co.za

35.228.95[.]80

35.198.88[.]195

34.105.255[.]170

102.130.113[.]55

34.105.219[.]83

oneupdateadobe.co.za

oneupdateadobe2.co.za

oneupdateadobe3.co.za

oneupdateadobe4.co.za

updateforadobenew.co.za

oneupdateadobe.org.za

oneupdateadobe2.org.za

oneupdateadobe3.org.za

microsoft-cloud1[.]co.za

microsoft-cloud6[.]co.za

microsoft-cloud7[.]co.za

microsoft-cloud8[.]co.za

microsoft-cloud9[.]co.za

microsoft-cloud10[.]co.za

microsoft-cloud11[.]co.za

microsoft-cloud12[.]co.za

microsoft-cloud13[.]co.za

microsoft-cloud14[.]co.za

microsoft-cloud15[.]co.za

cloudupdates[.]co.za
FakeSecurity cloud-js[.]co.za

host-js[.]co.za

magento-cloud[.]co.za

magento-js[.]co.za

magento-security[.]co.za

marketplace-magento[.]co.za

marketplacemagento[.]co.za

node-js[.]co.za

node-js[.]co.za

payment-js[.]co.za

security-js[.]co.za

web-js[.]co.za
Mephistophilus documents-cloud-server1[.]co.za

documents-cloud-server2[.]co.za

documents-cloud-server3[.]co.za

documents-cloud-server4[.]co.za

documents-cloud-server6[.]co.za

documents-cloud-server7[.]co.za

documents-cloud-server8[.]co.za

documents-cloud-server9[.]co.za

documents-cloud-server[.]co.za

oneupdateadobe.co.za

oneupdateadobe2.co.za

oneupdateadobe3.co.za

oneupdateadobe4.co.za

updateforadobenew.co.za

oneupdateadobe.org.za

oneupdateadobe2.org.za

oneupdateadobe3.org.za

oneupdateadobe3.com
Vidar badlandsparks.com

gineuter.info

paunsaugunt.com

precambrianera.com

biscayneinn.com

msupdater[.]co.za

cloudupdate[.]co.za

cloudupdates[.]co.za

securitycloudserver[.]co.za

fastandprettycleaner[.]hk

download-plugin[.]co.za

download-plugins[.]co.za

downloadplugins[.]co.za
Другие индикаторы code-cloud1[.]co.za

code-cloud2[.]co.za

code-cloud3[.]co.za

code-cloud4[.]co.za

code-cloud5[.]co.za

code-cloud6[.]co.za

google-document[.]co.za

azure-cloud1[.]co.za

azure-cloud2[.]co.za

azure-cloud3[.]co.za

azure-cloud4[.]co.za

azure-cloud1.web.za

azure-cloud2.web.za

azure-cloud3].web.za

Updateadobeonline[.]co.za
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru