Привет, Хабр! Недавно мы рассказывали, что запустили подкаст «Под защитой», в рамках которого разбираем разные аспекты, связанные с информационной безопасностью. Знаем, что кому-то проще слушать подкасты дома или в пути, а кому-то — комфортнее читать текст. Такт что подготовили для вас ещё и версию одного из выпусков в формате статьи.

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

Меня зовут Сергей Рябов, я руководитель научно-исследовательской разработки ГК InfoWatch, и вот что мы обсуждали на подкасте.

Термины и понятия

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

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

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

Искусственный интеллект находит все более широкое применения для автоматизации и оптимизации кибератак. Средства ИИ позволяют злоумышленникам генерировать вредоносный код, анализировать системы и обходить системы защиты, по минимуму привлекая ручной труд. Большие языковые модели (large language models, LLM) позволили значительно ускорить кибератаки и намного удешевили их. Кроме того, такие модели сделали разработку механизмов атак более доступной для киберпреступников с небольшим опытом. В результате использование ИИ приносит массу новых наборов для атак, которые реализуются быстрее и обладают отличной масштабируемостью. И такие атаки уже практически невозможно остановить, имея лишь традиционные средства информационной безопасности.

Как ИИ используется киберпреступностью

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

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

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

Сегодня в эфире:

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

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

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

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

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

Привет! Меня зовут Аня, я работаю системным аналитиком в InfoWatch на продукте Device Monitor. Это система контроля утечек информации на рабочих станциях, позволяющая организации контролировать и блокировать вынос конфиденциальных данных за пределы ее безопасного контура.

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

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

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

Вредные советы

#1 Аналитик — он и в Африке аналитик

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

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

Метрики

Количество клиентских багов

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

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

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

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

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

OKR — штука в целом полезная, если знаете, зачем и как её внедрять.

Сегодня я не собираюсь вам продавать OKR как «идею» или «мечту» как способ достичь того, что не получается с помощью обычных средств. Моя цель сейчас — скорее, рассказать вам, как сделать в инструменте удобный механизм ведения Целей и Результатов (а именно так переводятся Objectives and Key Results) их дальнейшего отслеживания. В качестве инструмента будет выступать Jira, в качестве дополнительного удобства — плагин Structure с его удобными фишками. Рассказ будет поделен на 2 части — о создании механизма и о создании мониторинга.

В конце вас ждёт инструмент, который поможет вам сэкономить на покупке платного плагина для Jira. И который вы сделаете сами с помощью этого гайда.

Часть 1. Создаём механизм

На этапе, когда в компании началось массовое внедрение и команды начали знакомиться с этим подходом, предлагалось ведение всех целей в таблицах и файлах-документах. Для одной команды — вполне себе неплохой вариант, но когда команд за 30 и часть Целей зависит от других Целей, то понять общую картину в куче Excel-таблиц, где каждая команда, хоть и соблюдая общие принципы, но всё же ведет все по-своему — становится крайне тяжело.  И мне это очень не понравилось.

Я решил попробовать найти или сделать механизм для этого.

Привет, Хабр!

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

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

Вышло 6 выпусков, все уже доступны для просмотра или прослушивания, кто какой формат предпочитает. 

Вот темы выпусков:

И сразу отвечу на вопрос, зачем это вообще может понадобиться. 

Есть четыре типовых ситуации:

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

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

3. У вас попросили консультацию — на профессиональной основе или в формате помощи другу.

4. Вы не собираетесь ни на новую работу, ни покупать чей-то бизнес — вам просто кажется, что у вас сейчас на работе что-то идёт не так, и вы хотите всё оценить и понять, что именно.

В этой статье я расскажу, как адекватно и полноценно оценить состояние разработки. Меня зовут Андрей Бирюков, в разработке я 25 лет — начинал как разработчик, сейчас руковожу разработкой и клиентскими сервисами в InfoWatch. С этой темой я выступал на CTO conf, теперь подготовил для вас текстовую версию.

Привет!

Ко дню программиста мы с коллегами из TrueConf предлагали вам пройти небольшой ИБ-опрос. Целиком форму заполнили 106 человек, теперь же, как обещали — сводная статистика.

Привет, Хабр! Меня зовут Иван Калашников, я занимаюсь автотестированием в Инфовотч.

В мире web и тонких клиентов по-прежнему приходится тестировать классические приложения: Office apps, Explorer, Telegram, WhatsApp. Сегодня для примера мы возьмем WhatsApp.

Погрузившись в автоматизацию ручных кликов в приложениях Windows с помощью Python, я попробовал несколько известных библиотек, каждая из которых поодиночке оставляла ощущение «чего-то не хватает». PyAutoGUI не видит скрытые элементы, плохо находит элементы с экранами разного масштаба и разрешения, а pywinauto требует разбирать дерево элементов UIA (Microsoft UI Automation), которого может попросту не быть.

В этой статье разберём, как объединение этих инструментов позволяет обойти ограничения каждого и надёжно автоматизировать windows-приложения. Комбинация UI-ориентированных (pywinauto, Win32/UIA) и image-based (PyAutoGUI) техник остаётся самым гибким способом тестировать Windows-приложения. Но чтобы смесь действительно работала, нужны: сравнение бэкендов, явные ожидания, DPI-awareness.

Мы пройдем через ряд мини-кейсов — от кликов, поиска, отправки сообщения, до чтения текста с экрана и выясним, как справляется связка Python-библиотек.

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

В этой статье расскажу:

- как мы за два года прошли путь от оформительства до полноценного дизайн‑процесса;

- какие грабли собрали;

- что реально изменилось в продуктах и в работе команды;

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

Это не будет очередной теоретической статьей про «как надо». Только реальный опыт и — самое главное — конкретные примеры того, что сработало именно у нас.

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

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

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

Привет, Хабр! Меня зовут Эликс Смирнов, я ведущий кейс‑аналитик компании InfoWatch, занимаюсь анализом практики применения DLP‑систем. Много раз на демонстрациях возможностей ПО я сталкивался с мнением, что DLP‑система бессильна против стеганографии. Поэтому и решил написать на эту тему статью, которая покажет, как оно на самом деле. Важно — я ни разу не инженер. И статью написал простым языком, без технических подробностей, почитаемых на Хабре. Надеюсь, что такой подход не сделает текст менее интересным и полезным для офицеров информационной безопасности и их руководителей.

Привет, Хабр! Меня зовут Илья Башкиров. Я юрист по информационной безопасности в ГК InfoWatch. Только ленивый не написал, что с июня этого года в России вводятся оборотные штрафы и другие санкции для компаний за утечку персональных данных. Здесь Россия движется в фарватере общемировых практик. Однако подход к оценке рисков и санкциям за нарушения у нас отличается от американского или европейского, изложенного в GDPR. Как и сама мотивация, стоящая за регулированием оборота персональных данных государством. Кстати, GDPR — это не первая европейская инициатива по защите персональных данных. Вы знали, что продажа персональных данных началась задолго до появления Интернета? В этой статье расскажу про эти и другие факты, поделюсь данными и сделаю небольшой футурологический прогноз.

Всем привет! Меня зовут Диана Бутько, я студентка 3 курса, изучаю информационные системы и программирование. В InfoWatch я пришла на практику, и одной из моих задач стал сравнительный анализ различных методов поиска похожих векторов. Это один из ключевых аспектов машинного обучения и анализа данных, используемых в рекомендательных системах, кластеризации, семантическом поиске и других областях. Но чем больше объем данных, тем важнее становится выбор инструментов: полный перебор векторов требует больших вычислительных ресурсов, а в других алгоритмах порой необходимо балансировать между точностью и скоростью поиска.

В этой статье я сравниваю пять методов поиска похожих векторов:
— полный перебор по евклидову расстоянию с реализацией в Python;
— FAISS с индексами IndexFlatL2 (полный перебор, евклидово расстояние) и IndexIVFFlat (сегментирование по ячейкам, евклидово расстояние);
— векторный поиск в ClickHouse с индексом HNSW и метриками расстояния L2Distance (евклидово расстояние) и cosineDistance (косинусное сходство).

Привет, Хабр! Я Роман Сафиуллин, руковожу отделом защиты информации InfoWatch ARMA. Мы занимаемся защитой инфраструктуры промышленных предприятий от киберугроз, и сегодня хочу поделиться с вами инструкцией по разбору промышленных протоколов на примере протоколов IEC104 и Fanuc Focas.  В основе статьи – мой доклад на конференции Industrial++. Совместно с коллегами из отдела разработки ARMA – Сергеем Калдыркаевым и Алексеем Пуцем, собрали для вас немного цифр по атакам на промышленность, примеры интересной малвари и, собственно, туториал по разбору пром. протоколов.

Привет, дорогие хабровчане! Меня зовут Илья Лощаков. Я работаю инженером-автоматизатором процессов безопасной разработки в InfoWatch — то есть, devsecops’ом. Расскажу личную историю о том, как я кардинальным способом справился с процессуальным выгоранием, будучи ручным тестировщиком. Не всем подобный путь может подойти, но может кто-то почерпнет для себя полезное, а может даже вдохновится на перемены. А может и нет. В общем, как говорила Наталья Морская Пехота СТАРТУЕМ!

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

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

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

Всем привет! Я Екатерина Васильева, старший инженер по автоматизации тестирования в InfoWatch, и сегодня хочу поделиться своими наработками в области автотестирования веб-сайтов. В процессе работы нужно было работать со сторонними сайтами – в нашем случае это были VK, Telegram, Yandex Messenger, Whatsapp, и попросить разработчиков создать специальные ключи для автотестов было невозможно. Поэтому на данном проекте пригодился мой десятилетний опыт в автотестировании, в частности – составлении локаторов. Так как сайты сторонние была особенно актуальна тема стабильных локаторов. В статье делюсь информацией, необходимой для составления устойчивых локаторов – то есть таких, которые не нужно будет часто менять. Это крайне необходимо для автоматизации, когда локаторы вполне могут поменяться из-за обновления тегов и их атрибутов программистами, например, во время рефакторинга или написания нового функционала.

Привет! Меня зовут Зайнулла, я разработчик‑исследователь в InfoWatch и преподаватель в МГТУ им. Баумана. Сегодня расскажу о результатах не совсем типичного для меня исследования.

В статье «Уменьшать срок или платёж, что выгоднее: наглядное сравнение способов досрочного погашения кредита» проделана большая работа и сделаны правильные выводы, но меня смущает, что проведено исследование ипотеки как чёрного ящика, т. е. методом подстановки чисел в ипотечные калькуляторы с последующим сравнением результатов. Говорится о том, что показана математическая равнозначность методов, но сравнение результатов из ипотечных калькуляторов для нескольких частных случаев нельзя назвать доказательством в математическом смысле. Хотелось бы понимать причины равнозначности методов.

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