Сказ о том, как Фома предотвратил многомиллионные потери фирмы и похвалу получил

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

Макс Фрай, «Тихий город»

Предисловие

Вы даже представить не можете, на что может пойти человек ради быстрого обогащения. Да мы, к слову, и сами не могли, до поры до времени. У кого-то моральные устои и принципы настолько высоки, что человек за свою жизнь так и не приблизится ни разу к той планке, которая преграждает его от нарушения закона. У других же эта планка так низко, что соблазн нарушить закон и избить человека во дворе ради лишних 100 долларов очень велик. Но, как правило, это недалёкие личности, которые мыслят в категории сегодня, максимум завтра, а не ближайший месяц, год, пять лет. У них несколько низменных целей, к которым они стремятся, не задумываясь о будущем. И вряд ли у таких получится попасть в хорошую фирму, и уж тем более, на высокую должность.
Но есть ещё и третий тип людей, которые не будут совершать преступление ради даже нескольких сот тысяч долларов, но вот чуть больше задумаются: «А почему бы и нет?». И конечно же таких абсолютное большинство, и один из таких типов людей попал в нашу компанию, иначе бы не было этого рассказа, Вы ведь понимаете?

Наша компания достаточно маленькая по размеру (порядка 25-30 человек), но заняты мы достаточно в узкой и наукоёмкой сфере. Прямых конкурентов нам практически нет, поэтому вроде живём, вроде даже хорошо живём, но не сильно шикуем. В любом случае, наш коллектив всё полностью устраивает. Так как сфера предприятия, как я уже упоминал раннее, наукоёмкая, то по всем профильным направлениям мы стараемся нанимать людей с высшим образованием или опытом работы в данной сфере от 5 лет. А с учётом того, что сфера деятельности достаточно узка, то и людей, работающих в ней, мало. И последний фактор, который ужасно сокращает наши шансы найти кому-нибудь замену хотя бы за несколько месяцев: мы находимся вне Москвы.

Завязка

Каждый рассказ имеет завязку, развитие и развязку. Завязкой этой истории послужил найм в нашу компанию тестировщика ПО, которое мы же и разрабатываем. В силу того, что разработка ведётся под натиском постоянной нехватки времени, периодически появляются различные ошибки, так как разработчикам тяжело контролировать качество кода в условиях сжатых сроков. Когда все дедлайны уже давно сгорели и тлеют, а самые важные заказчики просят добавить «Ну там всего же одну кнопочку», становится немного не до качества архитектуры и кода. Хотелось бы отметить, что так бывает далеко не всегда и подавляющий объём ПО всё же написан грамотно.
Но есть некоторые модули, которые даже открывать страшно: того и гляди, просто открывая исходный файл, ошибку занесёшь. Те мне менее, иногда приходится править и подобные файлы. И очень не хочется, чтобы ПО, которое используется на крупных промышленных объектах, падало и предлагало отправить отчёт об ошибке в Microsoft. Именно поэтому мы и начали искать человека, который будет проводить тестирование того, что мы написали.
Шёл месяц, второй, уже подходил срок выпуска новой версии, а тестировщика как не было, так и нет. Было несколько человек, которые показались нам достаточно ответственными, но мы в них ошиблись. За две недели до выпуска новой версии, мы нашли человека, который нам подходил и которому подходили мы. Было решено тестировать совместными усилиями: он, прочтя документацию, пытался бы настроить систему как неискушённый пользователь, а наши разработчики подсказывали бы ему некоторые особенности настройки и записывали бы за ним те ошибки, которые были найдены. Обучался нашей системе он достаточно быстро, хоть она и достаточно сложна в настройке, и руководство этому радовалось, а, как оказалось, зря…

Продолжаем сотрудничество

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

Немного об организации работы

Наше ПО защищается HASP ключом, стоит немалых денег и просто так, отдельно от оборудования, не распространяется. Более того, перепродаже тоже не подлежит, что указано в договоре использования. Оборудование мы также собираем сами у себя.
Зачем нам защита ключом? Всё просто. Наши конкуренты смогли сами собрать оборудование, аналогичное нашему и продавать его немного дешевле. Так и продают. Но проблема в том, что оборудование наше работает только с нашим софтом, а с их оборудованием наш софт не работает. Более того, наш софт можно купить только с нашим оборудованием, поэтому клиенты, которые идут к этому конкуренту, могут получить только достаточно сырую версию ПО, которое они разрабатывают.
В качестве системы контроля версий когда-то был выбран SVN, и так и остался. В качестве системы отслеживания ошибок также когда-то был выбран Trac.
Каждый, кто имеет отношение, пусть даже косвенное, к разработке ПО, имеет учётную запись на Trac. Соответственно, как только перед отделом разработки возникает необходимость в выпуске новой версии, создаётся тикет с заголовком «Тестирование версии . Pre-release». К тикету прикрепляется незащищённый HASP-ключом дистрибутив ПО, тестировщик устанавливает его себе, проверяет, выписывает в комментарии обнаруженные проблемы, они исправляются и новая сборка ПО прикрепляется к тикету на повторное тестирование. И так до тех пор, пока не останется ошибок.
Оглядываясь назад я понимаю, что это и была первая ошибка: выпускать незащищённый ключом релиз за пределы круга разработчиков. Но у этого решения была причина: порой за день собиралось несколько новых дистрибутивов, и каждый из них подписывать было бы достаточно утомительным процессом. Но информационная безопасность и удобство, зачастую, лежат на разных концах отрезка, и приближаясь к одному концу, мы отдаляемся от второго.

Первая утечка ПО

Вечером одного понедельника, уже спустя несколько новых версий (около 10 месяцев) к начальнику отдела разработки пришёл директор предприятия и попросил его зайти на сайт конкурентов. Как только начальник отдела нажал <Enter>, он просто обомлел: на главной странице сайта конкурентов красовался скриншот нашей программы, а над изображением был кричащий заголовок «Новая версия программы! Расширенные возможности только для Вас! Узнайте подробнее.»
— Но как? откуда у них наша программа?
— Ты меня спрашиваешь?! Мне кажется, это я должен тебя спросить! Узнай, как они её достали и сразу же скажи мне!
После этого вечера начались поиски канала утечки. Да, я знаю, вы все уже знаете, кто был причиной утечки, но позвольте мне рассказать. Сначала нам пришлось потратиться на покупку нашего же ПО у конкурентов, чтобы окончательно убедиться. Сказано – сделано. Руководство компании выделило средства и была куплена программа. После установки начали исследовать купленный софт: всё было одинаково, абсолютно всё, за исключением пары деталей: версия не была защищена HASP-ключом и распространялась как есть, а все копирайты были потёрты, где вместо нашей информации о нашей компании, были проставлены логотипы, ссылки, адреса и названия конкурентов. Но было абсолютное доказательство того, что это программа наша (хотя и всего перечисленного уже более, чем достаточно): в коде у нас объявлена следующая сигнатура:

const char *g_app_sign = "*** (C) 1997"; 

Где *** – название нашей фирмы, а 1997 – это год начала разработки первого модуля, который уже канул в лету. И в *.exe файле, установленном из дистрибутива конкурентов, была такая же сигнатура. Ресурсы-то они заменили, а вот более глубокий анализ решили не проводить за ненадобностью.
Когда стало ясно, что программа явно наша, мы начали искать, каким образом открытая версия утекла в свободный доступ. Но все проверки были тщетны. Компьютеры сотрудников перетряхивались от и до, на них не было ничего, относящегося к сливу софта конкурентам. Хочу сразу заметить, что всё это делалось с добровольного согласия сотрудников. А так как все понимали последствия данной утечки и коллектив был устоявшимся, то практически никто не был против. Конечно к тем, кто отказался от такой проверки, руководство стало присматриваться внимательнее, но они никак не ущемлялись. Был проверен почти каждый компьютер, вся история всех браузеров, история переписки сотрудников по ICQ, Skype, файлы, документы. Подобная проверка длилась чуть меньше месяца и, к сожалению, она ничего не дала.
После этого было решено проверять логи корпоративного сервера, через который все ходят в сеть. Были и файлообменники, и торрент-трекеры, но, судя по логам, ничего такого, что могло бы указывать на утечку программы конкурентам.

Безопасность против удобства

Тотальные проверки не увенчались успехом и работа компании стала возвращаться в прежнее русло. Но некоторые меры всё же были предприняты: был утверждён список лиц, которые получают незащищённую сборку в руки (туда автоматически попали все разработчики), в отдел тестирования теперь стала отдаваться только защищённая HASP-ключом сборка, системный администратор теперь должен был докладывать о каждом заходе на сайт конкурентов с применением санкций к нему, если он делает это несвоевременно, подпись HASP-ключом проводит только один конкретный человек, а не тот разработчик, у которого нашлось время.
После этого утечки ПО прекратились, актуальная версия ушла достаточно далеко вперёд относительно той, что утекла и та часть клиентов, которые хотели новые возможности, стали вновь приходить к нам. Работа фирмы стала налаживаться, но директор продолжал достаточно строго следить за соблюдением дисциплины. Его можно понять: конкуренты так близко подобрались, как никогда раньше, и он достаточно долго находился в поиске новых решений по укреплению безопасности.
Посоветовавшись с начальником IT-отдела они решили, что есть всего два возможных способа утечки той версии программы: через почту и через флеш-накопитель. В первом случае в утечке участвует системный администратор, который затёр нужные логи, так как только у него есть доступ к серверу. Во втором случае все те, у кого был доступ к незащищённой версии. Было принято волевое решение установить софт по наблюдению за теми сотрудниками, которые могли быть причастны к этой утечке. Сказано – сделано.

Вторая утечка ПО

Спустя несколько месяцев после введения подобных организационных мер, произошла вторая утечка ПО. Начальник отдела разработки периодически просматривал сайт конкурентов. И вновь на главной странице красовался скриншот с подменёнными копирайтами. Мы начали пытаться заполучить новую версию ПО для анализа, параллельно готовясь к судебным тяжбам. Но купить второй раз эту программу не представлялось возможным, так как руководство не выделило на это деньги, посчитав излишним.
По скриншотам было видно, что функционал немного отличался. Та «небольшая кнопочка», которую нас когда-то просили добавить, была добавлена. Но ведь мы этого не делали! Откуда у них появился доступ к исходным кодам? Учитывая, что часть функционала, которым была наделена новая украденная версия, появилась уже после утечки, то конкуренты изменяли тот исходный код, который появился относительно недавно.
После того, как стало известно о второй утечке, руководитель начал сам лично проверять все отчёты, которые присылала ему программа по наблюдению за сотрудниками. И бинго! Нашёл! В тот же день системному администратору и тестировщику пришлось написать «по собственному».

Разбор полётов

Так что же там всё таки произошло? А произошло следующее: в первой утечке был виновен сам тестировщик, он сам в этом признался, когда всё раскрылось. Просто скинул себе дистрибутив по кабелю на телефон и продал конкурентам за хорошие деньги (точной суммы я не знаю, но порядок – сотни тысяч рублей). Вот так просто. Именно поэтому конкуренты максимум что смогли сделать – это заменить ресурсы программы, а исходный код остался нетронутым.
Со второй утечкой всё намного интереснее. Так как тестировщик лишился незащищённых дистрибутивов, он начал искать другие пути добыть незащищённую версию программы. И через какое-то время нашёл. Он знал, что у нас до его прихода работали ещё два разработчика, которые ушли в другие компании. Он списался по Skype с системным администратором и сказал, что ему для добавления страницы по тестированию специфического модуля необходимо зайти в админку системы управления версиями, но у него нет доступа туда и попросил администратора дать ему такие права. Но так как были введены новые организационные меры, то для выполнения такой операции системный администратор должен был поговорить с директором предприятия, а ему это не очень хотелось делать. Немного подумав, он вспомнил про тех уволившихся разработчиков, а также о том, что их учётные записи не были деактивированы. И он просто скопировал данные в скайп тестировщику.
Когда тот зашёл под аккаунтом разработчика, то увидел вкладку «Исходный код», а зайдя туда увидел svn адрес. После этого, с помощью svn-клиента скачал все исходники нашей компании себе так же на телефон, и продал конкурентам за куда большие деньги, чем просто дистрибутив. Именно весь лог всех компьютерных действий системного администратора и тестировщика директор и видел, так что в те пару раз, когда тестировщик пытался юлить и врал в открытую, директор поправлял его нестыковки в повествовании на основании тех отчётов, что он видел.
Конкурентам мы пригрозили судом, указав на то, что их информатор был пойман с поличным. В итоге они отказались от продажи нашей программы под своим именем добровольно. А в новую версию ПО и оборудования была добавлена небольшая проверка, которая не позволит старой версии программы работать с новым ПО и наоборот.

Заключение

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

1. Надо обязательно деактивировать аккаунты, имеющие права администратора, и которые больше не будут использоваться.
2. Ни в коем случае не наделяйте человека правами больше, чем ему необходимо для выполнения рабочих обязанностей.
3. Не стоит совсем расслаблять подчинённых, они всё же в первую очередь подчинённые, а не друзья.
4. Дисциплина – это хорошо. Если бы мы применили совсем чуть-чуть дисциплины в начале, то нам не пришлось бы там сильно затягивать гайки при выяснении обстоятельств утечки.
5. Программа по наблюдению за сотрудниками иногда тоже хорошо, но надо знать меру и не шпионить за подчинёнными, а анализировать общие отчёты о производительности и строить бизнес-процессы с оглядкой на это (Если кому интересно, что мы использовали — пишите в ЛС или на моём сайте есть почта).

Спасибо за внимание!
Ах, да, попробуйте угадать в комментариях, кто такой Фома? 😉