Мир IT разнообразен донельзя. Кто каких только технологий и решений не создает, что только не разрабатывает! Компании творят продукты каждая по-своему, но многие процессы схожи, а потому могут оказаться полезным опытом для заимствования. Вот мы и подумали: а почему бы не рассказать вам о том, как мы создаем наш флагманский продукт Solar Dozor? Команда у нас очень опытная и энергичная. Каждый день нам приходится решать нетривиальные задачи, искать киллер фичи и увязывать пожелания заказчиков с собственным роудмапом. Вдруг наш опыт кому-то пригодится?
В общем, решили – запускаем серию статей о том, как, где и при каких обстоятельствах рождается наша DLP-система. Все откровенно, по-честному, с фото и, может, даже видеопруфами. А сегодня вы узнаете, с чего начинается создание нашего продукта. Знакомьтесь – discovery-лаборатория Dozor Research Lab.
Как известно, театр начинается с вешалки, а разработка любого продукта – с идеи. Пришел один человек к другому и поделился светлой мыслью, что пришла в голову. Всё. Можно считать процесс исследования в Research Lab запущенным.
Ну а если серьезно, то история технологий говорит словами Стива Джобса: «Инновация отличает лидера от догоняющего». И Dozor Research Lab – это то место, где испытываются и взращиваются наши инновационные технологии. Ключевая деятельность нашей группы – исследовательская (мы её у себя называем по-пижонски discovery). Discovery-процесс находится на стыке бизнеса, разработки, тестирования, внедрения и маркетинга и является необходимой частью рабочего процесса каждого из этих подразделений. Сегодня мы познакомимся с некоторыми особенностями работы Research Lab поближе.
Мы хотели сделать рассказ живым и простым, поэтому сразу отложили в сторону идею использовать язык бизнес-процессов и каких бы то ни было фреймворков процессов разработки (об этом мы расскажем в отдельной статье). Напротив, мы в вольном стиле постарались осветить примечательные стороны работы специалистов Research Lab. И у нас получилась вот такая mind-карта.
А теперь по порядку.
Облако идей
Что греха таить — все мы любим пофантазировать. Только для специалистов нашей группы это необходимость. Поиск новых решений и толковых идей невозможен без должного воображения. Однажды Дэвид Гильберт сказал о своем бывшем ученике: «Он стал поэтом. Для математики у него было слишком мало воображения». Это, конечно, ирония. Создатели некоторых существующих технологий черпали свои идеи у классиков фантастики – писателей и режиссеров. Мораль тут в том, что полет мысли должен сопровождать и труд художника, и работу исследователя.
В своей работе мы регулярно обсуждаем с коллегами, и, главное, с пользователями их собственные идеи и задумки. Даем им возможность помечтать: «Что если сделать вот такую штуку? Или вот этакую». Некоторые мысли звучат лишь раз, а некоторые одновременно и с разных сторон. Образуется так называемое облако идей, из которого нет-нет да и проливается живительная влага на поле деятельности исследователя.
Одна из первых задач исследователя – связать в систему на первый взгляд несвязанные идеи и предложения. Из этого он должен сформировать красивую во всех смыслах модель (концепцию). Поясню это на примере формирования нашего решения анализа поведения сотрудников UBA (User Behavior Analytics).
Мы на протяжении долгого времени обсуждали с коллегами в тесном и широком кругу наши идеи и ответы на вопросы: Что вообще такое поведение? Можно ли измерять поведение сотрудников? Как поведение человека или группы может влиять на информационную защищенность? Мы дискутировали, кто-то выступал с докладами и проводил семинары, кто-то переводил иностранные статьи и на коленке придумывал прототип решения. Во внимание принимались даже приемы из видеоигр.
Довольно необычным стало то, что в результате череды обсуждений и переосмыслений математическая модель поведения оказалась во многом похожей на модель электрона в квантовой механике. Эта модель объекта физического мира содержала в себе наиболее подходящее описание нужных расчетов (часть которых относится к алгоритмам машинного обучения класса Anomaly Detection). Так что, можно сказать, все мы с вами немного электроны.
Вызов
Второй важный элемент процесса discovery – это вызов. Вызов реализовать самую смелую идею, создать прототип сложной концепции, достигнуть первоклассного качества. Именно вызов мотивирует нас на результат. Если вызова нет, то мы можем долго фантазировать, программировать какие-то отдельные части, но ни к чему ощутимому в итоге не придем. Причем вызов может быть разным – стратегическим, командным, личным.
Один из наших стратегических вызовов, общий для всех технологий, которые мы создаем, – сделать их лучшими на рынке. Вызов нашей команде – это показать эффективность результатов ее работы и быть в лидерах инноваций в компании. Мой личный вызов – реализовать с пользой то, чему научился и что перенял у своих учителей.
Так или иначе, вызов придает драйва нашей работе, каждый из членов команды должен его чувствовать, иначе результата не достигнуть.
Уважение к конкурентам
Многие из вас сейчас, наверное, удивятся… Но еще одну особенность discovery-процесса я назову так: чувство уважения к конкурентам. Мы всегда анализируем все интересные технологии, которые создают наши конкуренты.
Надо признать, что у конкурентов коллеги из подобных нашей Research Lab тоже не сидят сложа руки. Анализируя их работу, мы сравниваем их подходы со своими, видим их хорошие находки и недостатки, пытаемся учесть у себя. Случается и так, что конкуренты предлагают интересные возможности, достойные внимания и мысленного «лайка». Хотя иной раз разрядить обстановку юмором или крепким словом о конкурентах не помешает. Например, в ситуациях, когда они начинают копировать наши разработки и даже терминологию, причем делают это непоследовательно и искажают смысл.
Слушать и не опускать рук
В процессе обсуждения новых концепций очень часто приходится сталкиваться с сопротивлением своих же коллег. Нужно быть готовым к самой разной критике. Обсуждение со всеми заинтересованными лицами заставляет заранее скорректировать собственное видение, приготовиться к неудобным, сложным, а порой и чуднЫм, вопросам. Такой навык мы стараемся развивать.
Легендарный Стив Джобс был известен тем, что любил зарубать идеи, с которыми к нему приходили люди. Обычную фразу Джобса «this is shit» следовало понимать, как «объясните мне, почему это «the best way».
Та или иная концепция может серьезно пошатнуться под напором возражений, но для профессионала это не причина опускать руки. Напротив, есть повод крепко подумать (и пару ночей не поспать), изменить условия задачи, добавить или убрать что-то и шаг за шагом прийти к тому самому «the best way». Надо понимать, что для этапа исследования и прототипирования «реакция Джобса» абсолютно нормальна. Но если опустить руки, то результата не получишь точно.
Вот вам очередной пример из разработки UBA. Мы ввели новое понятие – «эго-сеть» сотрудника. В соответствие с разработанным нами алгоритмом, в эго-сеть человека попадают те, с кем он общается тет-а-тет и на регулярной основе. Есть еще понятие «приватная эго-сеть», когда такое общение ведется с никому больше не известными в компании адресатами. Это могут быть как личные и родственные, так и опасные с точки зрения экономической безопасности связи.
Наша введенная терминология поначалу вызвала критику коллег и технических писателей. Рассматривались и другие подходы к терминологии. Пришлось провести не один мозгоштурм, несколько интервью заказчиков и экспертов по безопасности, пропилотировать прототип – всё для того, чтобы убедиться, что из всех вариантов этот оказался наиболее подходящим и быстро лег на язык пользователей.
Эксперимент – первый судья
Эксперименты в рамках процесса discovery необходимы – главное, не бояться экспериментировать. Никто не придет и не расскажет тебе, как именно нужно проверять функциональность. Ты должен придумать сам, как испытать модель на прочность – это сродни автомобильным краш-тестам.
Например, как мы экспериментировали с технологией распознавания графических образов в изображениях? Брали обычную печать нашей компании и шлепали ее на всевозможных документах, на изображениях или даже на руку. Затем распечатывали, сканировали, фотографировали, изучали все ее возможные вариации и искажения. И отправляли получившиеся образцы в наш инструмент распознавания. Конечно, мы потом готовили репрезентативную выборку исходных примеров. Но начинается обычно все с максимально широких и быстрых экспериментов.
Честно поставленный эксперимент – сильное подспорье при начальной оценке рисков и выдвижении гипотез.
P.S. Растим таланты
Эту часть нашей работы можно считать второстепенной по отношению к основной деятельности. Но на самом деле она очень важна для всей компании. Бывает, к нам в лабораторию приходят сотрудники, которые не представляют себе, чем именно в IT они хотели бы заниматься. Например, с образованием в области информационной безопасности, но без каких-либо навыков программирования. И вот за 1-2 года с помощью коллег и собственного упорства человек с нуля осваивает программирование и становится одним из лучших разработчиков в своем направлении.
Как это получается? Просто в рамках нашего процесса discovery мы сразу после трудоустройства предлагаем новичкам пул задач по возможности разного плана. Это позволяет выявить сильные стороны человека и сильно повышает его эффективность. В нашей группе достаточно возможностей для саморазвития. Мы стараемся строить работу так, чтобы задачи не давили на человека, а позволяли ему расти.
Организация процесса discovery на примере Solar Dozor UBA
Про отдельные детали нашего пазла Discovery поговорили – теперь попробуем посмотреть на него со стороны и описать основные этапы исследовательской деятельности. В качестве иллюстрации я расскажу, как проходил процесс исследования нашего нового продукта Solar Dozor UBA из класса UEBA-систем.
Пару слов о длительности discovery-процесса
здесь
Длительность процесса зависит от следующих факторов:
Здесь мы не рассматриваем внешние и общие для разных бизнес-процессов факторы. Очевидно, что учитываются и дорожная карта продукта, приоритеты разработки, форс-мажорные ситуации и прочее.
- сложности системы пользовательских функций, под которые ведется исследование;
- истории опытных образцов;
- новизны предмета исследований и базы зарекомендовавших себя научных статей;
- перечня возможных технологий;
- наличия отзывов и требований наших пользователей.
Здесь мы не рассматриваем внешние и общие для разных бизнес-процессов факторы. Очевидно, что учитываются и дорожная карта продукта, приоритеты разработки, форс-мажорные ситуации и прочее.
Еще до разработки модуля анализа поведения Solar Dozor UBA на процесс discovery ушел год с небольшим. Время, с одной стороны, немалое. С другой стороны, смелая начальная концепция вылилась в немалую систему функций, каждая из которых имела свое бизнес-обоснование. Поэтому спешка могла разрушить эту систему.
На старте исследований в пределах России не было подтвержденных примеров работающих отечественных решений класса UEBA. Поэтому прежде всего мы опирались на опыт и значимые научные публикации иностранных разработчиков подобных решений, которые тоже только набирают обороты и предлагают часто очень разные инструменты и фреймворки. Ни о каком «традиционном» наборе технологий анализа данных речи не шло, и мы не могли просто прийти к заказчику с красивыми идеями.
Глубокое погружение
Подробности
Отдельным этапом исследований является кропотливое штудирование открытых научных и не очень научных публикаций на тему. Хочется отметить необходимое для этого владение техническим английским и умение реферировать материал. Наиболее интересные и подходящие материалы ложатся в нашу базу знаний.
К этому этапу можно также отнести часто возникающую необходимость быстро освоить новую подходящую технологию, инструмент, язык программирования. Вместе с некоторой свободой выбора технологии мы (специалисты Research Lab) получаем в нагрузку и обязанность в кратчайшие сроки разобраться в ней и научиться эффективно использовать её. У нас нет такой роскоши – иметь отдельного спеца под каждый инструментарий. Мне и самому, знаете ли, пришлось не так давно осваивать инструменты компьютерной анимации, хотя прежде всего в душе я остаюсь математиком.
К этому этапу можно также отнести часто возникающую необходимость быстро освоить новую подходящую технологию, инструмент, язык программирования. Вместе с некоторой свободой выбора технологии мы (специалисты Research Lab) получаем в нагрузку и обязанность в кратчайшие сроки разобраться в ней и научиться эффективно использовать её. У нас нет такой роскоши – иметь отдельного спеца под каждый инструментарий. Мне и самому, знаете ли, пришлось не так давно осваивать инструменты компьютерной анимации, хотя прежде всего в душе я остаюсь математиком.
Параллельно мы обсуждали наши идеи внутри команды – проводили регулярные совещания с team-лидами, системными архитекторами, бизнес-аналитиками. Шел сбор мнений и критики. Нельзя не отметить определяющую позицию руководства по ключевым вопросам. Так родилась модель исследуемого объекта (поведения человека) и был очерчен круг технологий, способных ее реализовать. Силами исследовательской группы был сделан работающий прототип решения.
Детали первого прототипа
на примере Solar Dozor UBA
Прототип мы делали на языке Python, используя библиотеки анализа данных Pandas, и с веб-интерфейсом, реализованным на Plotly. В качестве СУБД использовалась PosgreSQL.
Модель, по-научному, представляла из себя реализацию набора стохастических процессов. Они описывали динамику измеримых показателей поведения человека. Для этого мы решили использовать эмпирические переходные плотности вероятности, порождаемые уникальными свойствами данных пользователей. Этот подход принято относить к алгоритмам машинного обучения без учителя категории Anomaly Detection, а точнее к LOF-алгоритмам. Для качественного анализа состава коммуникаций были использованы алгоритмы теории графов. А вот лингвистический анализ и классификацию информации взял на себя движок системы Solar Dozor, в которую и встроен модуль Solar Dozor UBA.
Модель, по-научному, представляла из себя реализацию набора стохастических процессов. Они описывали динамику измеримых показателей поведения человека. Для этого мы решили использовать эмпирические переходные плотности вероятности, порождаемые уникальными свойствами данных пользователей. Этот подход принято относить к алгоритмам машинного обучения без учителя категории Anomaly Detection, а точнее к LOF-алгоритмам. Для качественного анализа состава коммуникаций были использованы алгоритмы теории графов. А вот лингвистический анализ и классификацию информации взял на себя движок системы Solar Dozor, в которую и встроен модуль Solar Dozor UBA.
Естественно, на этапе пилотирования прототипа не все идет как по маслу. Важно выстроить коммуникации и завоевать высокую лояльность заказчика. Важно найти и собрать команду ответственных и квалифицированных коллег со стороны заказчика, готовых к совместной работе. Для этого заранее нужно позаботиться о планировании пилота, его целях, задачах и пользе для каждого участника команды.
Пилоты и опытная эксплуатация отчуждаемого прототипа Solar Dozor UBA заняли немало времени в общей длительности discovery. В тоже время, они дали нам возможность сделать важные корректировки в системе пользовательских функций и в нашей математической модели. Мы смогли оставить часть функций, в которых стали уверены, и одновременно отбросили некоторые наши неподтвержденные гипотезы. Также реальная эксплуатация прототипа выявила новые возможности и зоны интереса пользователей. Мы хотим поблагодарить увлеченных нашей технологией заказчиков, которые согласились провести у себя испытания решения и дали нам столь полезный отклик!
Не все технологии проходят с успехом опытную эксплуатацию, и это нормально.
Примеры
Это так. Например, некоторое время назад мы проводили исследования технологий нейронных сетей в приложении к обнаружению косвенных признаков утечек информации. Такие технологии сами находят события безопасности на основе пары десятков косвенных признаков. Нейронная сеть обучалась параллельно с нашей DLP-системой, смотрела, как Solar Dozor распределяет события, а потом сама должна была анализировать трафик и определять, какие события являются инцидентом безопасности, а какие нет. Мы получили неплохие результаты, но бизнес сказал, что заказчики пока не готовы к переходу на эти технологии. Это не значит, что технология бесперспективна. Возможно сейчас просто не сошлись все звезды на рынке безопасности.
Одно время мы вели исследования в области категоризации интернет-ресурсов для определения так называемых серых сайтов, с помощью алгоритмов машинного обучения. Мы проработали технологию до стадии работающей модели. Она определяла «серые» сайты, близкие по тематикам. Эта технология уже в силу слабых качественных результатов для задач безопасности была прохладно встречена первыми возможными заказчиками и пока легла на полку.
Полагаю, не менее половины изначальных идей прорабатываются до стадии создания прототипа, но в итоге не взлетают. Мы относимся к этому спокойно, по сути, это естественная часть процесса discovery. Главное, любые, даже малые наработки, сохранять в организованную базу знаний и иметь к ним легкий доступ.
Одно время мы вели исследования в области категоризации интернет-ресурсов для определения так называемых серых сайтов, с помощью алгоритмов машинного обучения. Мы проработали технологию до стадии работающей модели. Она определяла «серые» сайты, близкие по тематикам. Эта технология уже в силу слабых качественных результатов для задач безопасности была прохладно встречена первыми возможными заказчиками и пока легла на полку.
Полагаю, не менее половины изначальных идей прорабатываются до стадии создания прототипа, но в итоге не взлетают. Мы относимся к этому спокойно, по сути, это естественная часть процесса discovery. Главное, любые, даже малые наработки, сохранять в организованную базу знаний и иметь к ним легкий доступ.
По завершении опытной эксплуатации прототипа мы проводим интервью первых пользователей, лучше с выездом к заказчику. С учетом того, что мы говорим о новых возможностях и функциях для пользователя, крайне полезно такие контакты производить с участием бизнес-аналитиков и непосредственных разработчиков прототипа. Дело в том, что на этой стадии цена ошибки неверно истолковать слова заказчика очень высока и может увести в сторону от лучших решений. И, конечно, все коммуникации должны протоколироваться. Это помогает во множестве спорных ситуаций и в дальнейшем может сказаться на определении минимально полезного функционала (MVP) первой версии продукта на рынке.
Соответственно, на финишной прямой ключевым результатом исследовательской работы является эскизное предложение с описанием минимально полезного функционала. Проводится ревью всех отчетов и расстановка приоритетов тех или иных возможностей и функций. В это время необходимо широко освещать эти результаты для заинтересованных коллег и руководства. Даже очень хорошие результаты без должного вовлечения коллег из разработки, бизнеса и маркетинга могут остаться незамеченными или не до конца понятыми.
Вот, пожалуй, и все основные моменты, которые сопровождают процесс исследований в нашей Research Lab, независимо от размера исследования, большого или маленького. Если исследования проходят успешно, и овчинка стоит выделки, то дальше их подхватывает департамент разработки. Здесь уже может выделяться отдельная команда разработчиков. Запускаются основные процессы разработки продукта на основе стандарта Agile по методике Scrum. Но это уже следующая и богатая на интересные детали история.
Автор текста:Максим Бузинов,
руководитель Dozor Research Lab.
Иллюстрации:
Анна Яковленко,
Аналитик данных.
