How-to: инструменты для проведения конкурентного анализа программных продуктов

^[1]

Изображение: Stephen Bowler, Flickr ^[2]

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

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

Мы в Positive Technologies начали процесс погружения в КА еще несколько лет назад — вот наша статья о разработке методики ^[3] проведения анализа. В дальнейшем она получила свое развитие в виде внутреннего инструмента для конкурентного анализа — о нем мы сегодня и поговорим.

Как это работает

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

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

Наш опыт

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

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

Далее мы решили, что сократим количество тестов до 10-15 самых важных и увеличим количество конкурентов до 2-3, а в отчет включим сравнение по большему количеству параметров. Формат ответа на вопрос «кто нашел больше» при этом сохраняется, но более глубокий анализ данных позволяет находить и ответ на вопрос о том, почему конкурент обошел нас по конкретному параметру?

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

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

Не все так просто

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

Если задача заключается в сравнении двух разных сканеров уязвимости, то обычно мы сталкиваемся с такими трудностями:

1. Конкурирующие продукты имеют разные форматы отчетов и логов — это значит, что нужно придумать единый формат и конвертировать все в него.
2. На выходе продукты предоставляют разную информацию — например, даже при выполнении одних и тех же задач, в отчетности продукты могут использовать разные описания. А значит нужно разрабатывать средства автоматизации, чтобы понимать, когда мы имеем дело с одинаковыми понятиями.
3. Конкуренты умеют искать разные типы уязвимостей — один продукт ищет уязвимости A и B, а второй определяет B и C. Простое сравнение количества уязвимостей в двух множествах будет неэффективным, необходимо анализировать их пересечение, только тогда картина будет полной.
4. Конкуренты по-разному называют одну и ту же уязвимость — тут ситуация повторяет второй пункт.
5. Конкурирующий продукт на какой-то цели показывает большое количество ложных срабатываний — в итоге наш сканер может найти 1000 уязвимостей, а конкурент все 10000, значит нам нужно придумывать, как автоматически обнаруживать такие ложные срабатывания, чтобы получить возможность корректно сравнивать результаты.
6. Сканер не может полностью просканировать какую-либо CMS — даже если мы нашли отличную цель для сканирования, все это не поможет, если конкурирующий продукт не может сделать тоже самое (например, не может пройти авторизацию в CMS). Приходится адаптировать цели, чтобы все-таки иметь возможность провести сравнение.

Инструменты конкурентного анализа

Поговорим о том, с помощью каких инструментов можно проводить конкурентный анализ софта. Для управления процессом анализа мы используем собственный инструмент под названием InAC (Intellectual Analysis of Competitors). Без облака OpenStack процесс также был бы невозможен, для сохранения результатов используется TFS и сетевой диск, кроме того мы применяем в анализе нейросети (об этом будет отдельная статья), но все отдать машинам невозможно, поэтому разбор результатов проводится и вручную с помощью браузеров, IDE и burp, в заключение создается отчет в вебе. Изначально мы использовали Excel, однако он не способен выводить большое количество графиков в удобном для пользователя виде.

Заключение: что нужно уметь для проведения КА

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

В нашем случае, специалисты по тестированию обладают навыками ИБ-исследователей и проведения пентестов, кроме того, им нужно знать PHP, Java EE, ASP.NET (C#), Python (желательно), уметь работать с Docker, TFS, Salt, git

P.S. Рассказ о нашем опыте конкурентного анализа программных продуктов был представлен в рамках DevOps-митапа, который состоялся осенью 2016 года в Москве.

Видео:

Слайды:

По ссылке ^[4] представлены презентации 16 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений добавлены в таблицу в конце этого топика-анонса ^[5].

Автор: Владимир Софин ^[6]

Автор: Positive Technologies

Источник ^[7]