Привет, Хабр! Меня зовут Сергей Бондарев, я старший инженер нагрузочного тестирования в InfoWatch ARMA. В компании я занимаюсь разработкой методик нагрузочного тестирования, разработкой новых сценариев тестирования NGFW и написанием скриптов тестирования под различные нагрузчики.

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

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

Это одна из основных задач проведения нагрузочного тестирования. 

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

Для проведения тестирования в качестве генератора тестового трафика будет использоваться open-source-проект Cisco Trex

Привет, Хабр! Меня зовут Сергей, я работаю в компании InfoWatch разработчиком на продукте ARMA Стена (NGFW). Подробнее о том, что такое ARMA Стена, можно прочитать тут.

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

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

Статья состоит из двух частей:

1) Что такое формальная верификация и где она применятся

2) Решение бизнес-задачи в NGFW

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

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

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

Привет, Хабр! Если интересно проанализировать недостатки инструмента inotify с позиции решения ИБ-задачи контроля целостности (именно самого инструмента в его первозданном виде), то добро пожаловать под кат!

Введение

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

Какие инструменты контроля целостности в Linux приходят сразу на ум?

AIDE (Advanced Intrusion Detection Environment)
AFICK (Another File Integrity Checker)
tripwire
wazuh
OSSEC

Из перечисленных инструментов aide, afick и tripwire работают по принципу «редкого» мониторинга, а wazuh, ossec — постоянного (более подробно эти понятия раскроются дальше).

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

Мы не будем досконально рассматривать сам механизм ядра Linux, хорошего материала на эту тему достаточно, в том числе и на Хабре. Также не станем проводить глубокий анализ работы прекрасных утилит inotify-tools или incron. Речь пойдет именно про сам inotify в его первозданном виде без каких-либо обвязок и библиотек. Нам важно понять, с какими проблемами можно столкнуться в случае проектирования ПО, использующего сам inotify. Что касается inotify-tools, то здесь мы посмотрим на то, закрывают ли утилиты данного пакета описанные проблемы.

Как устроен конвейер

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

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

Как всё было хорошо и просто раньше

До 2025 года такие закрытые ключи в комплекте с открытыми ключами и с сертификатами открытых ключей можно было приобрести у компании GlobalSign в виде отчуждаемого крипто-контейнера PFX в формате pkcs12, доступ к содержимому которого был защищён паролем.

Привет!

С 26 по 30 января проходит ежегодная неделя защиты конфиденциальности данных (Data Privacy Week), поэтому мы решили подготовить для вас полезный материал по персональным данным.

Меня зовут Илья Башкиров, я юрист по ИБ InfoWatch, и сегодня хочу поделиться статьёй в двух актах. Акт 1 — обзор опыта и судов 2025 года: кого, за что и как штрафовали и на что стоит обратить внимание. Акт 2 — небольшой гайд по front-end-privacy-compliance, то есть по работе с персональными данными, формами согласий и кукисов, политиками и прочим на сайтах и в приложениях.

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

Привет! В первой части мы обсудили само понятие инноваций и инновации в DLP-системах, в этой же статье поговорим о:

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

Отличия инноваций в зависимости от сфер деятельности

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

То есть сама база тут одна, а вот уже под конкретные задачи можно накручивать разные полезные дополнения. Скажем, та же потоковая кластеризация вообще не зависит от сферы применения — потому что она про события, а события есть везде (просто у этих событий разная тематика). Плюс не забываем, что всё, связанное со 152 ФЗ (персональные данные), теперь тоже стало важным практически для всех. 

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

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

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

Меня зовут Сергей Рябов, я руководитель научно-исследовательской разработки ГК 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, в статье разберем кто и как атакует предприятия реального сектора, какие сегменты промышленных сетей самые уязвимые и что за средства используются злоумышленниками для атак.