Информационная безопасность экосистемы открытого ПО

Согласно данным IDC, объем мирового рынка свободного программного обеспечения (СПО) на конец 2012 г. составил 6 млрд. долл., показав годовой рост на 18%. В России эти показатели за тот же период таковы: примерно 150 млн. долл. и 30% соответственно. В нынешнем году прогнозируется увеличение мирового рынка СПО до 7 млрд. долл., а российского — до 200 млн. долл. Эксперты оценивают этот рынок в России как нарождающийся и перспективный.

В 2010 г. в нашей стране принято правительственное решение о переводе к 2015 г. федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование СПО. Глава Минкомсвязи РФ оценивает потенциал страны для внедрения СПО как большой, отмечая вместе с тем малое количество качественных рыночных СПО-продуктов. Из его слов, высказанных на встрече в мае 2013 г. руководства министерства с представителями экспертного сообщества, где обсуждались вопросы создания Национальной программной платформы (НПП) и поддержки СПО, также следует, что руководство страны все еще не определилось с подходами к поддержке СПО.

СПО и ППО — что безопаснее?

Одним из ключевых требований к СПО, согласно ГОСТ Р 54 593-2011 “ИТ. СПО. Общие положения” (действует с 1.01.2012), является информационная безопасность (ИБ). Половина участников опроса, проведенного PC Week/RE в I квартале 2013 г., убеждена в том, что система разработки СПО обеспечивает его безопасность, в то же время 41% респондентов сомневаются в этом, а остальные 9% затруднились дать определенный ответ.

В оценке количества ошибок, допускаемых разработчиками проприетарного программного обеспечения (ППО) и свободного ПО, голоса принявших участие в опросе разделись на три примерно равные группы: 35% респондентов отдали предпочтение авторам ППО, 31% — создателям СПО, 34% затруднились назвать менее надежную модель разработки ПО.

Примерно половина опрошенных полагает, что в обеспечении безопасности кода в процессе его разработки есть принципиальные отличия между моделями СПО и ППО. Участники круглого стола “Информационная безопасность экосистемы СПО”, проведенного еженедельником PC Week/RE (ведущий – ваш покорный слуга) в рамках форума Russian Open Source Summit 2013 (ROSS 2013), постарались прояснить, чем же эти различия обусловлены, если они действительно существуют, а также рассмотреть другие аспекты ИБ экосистемы СПО.

Ссылаясь на свой более чем десятилетний разносторонний опыт работы в области СПО, Милан Прохаска (VDEL) утверждает, что программные продукты (ПП), разрабатываемые по модели СПО мировым сообществом программистов, более инновационны и быстрее, чем ППО, освобождаются от обнаруживаемых в них уязвимостей, так как модель жизненного цикла ПП в экосистеме СПО выработала механизмы их коллективного тестирования, в том числе и в целях повышения их безопасности.

Однако, по мнению Олега Лекшина (ИВК), у “самотестирования” и “самопроверок” сообществом СПО своих продуктов есть существенный недостаток, о котором следует помнить: в среде СПО нужно выделять программные продукты, используемые широко, и те, что известны мало. Первые действительно хорошо и оперативно тестируется сообществом пользователей и разработчиков, и уязвимости в них быстро устраняются. Зато вторые по причине их слабой проверки следует признать небезопасными.

Александр Максимовский (ФСБ РФ) отмечает, что ведущие мировые вендоры ППО преуспели в качестве своих ПП для широкого потребления и выгодно отличаются этим от вендоров продуктов с открытым кодом. Это означает, что в модели продвижения СПО в среде массового потребления ПО есть что исправлять.

Михаил Рыстенко (“Альбатрос Карго”) обращает внимание на то, что внутри любой структуры, использующей ПП, трудно выделять зоны, где применяется только СПО или только ППО. В то же время корпоративная ИБ должна обеспечиваться сквозь ИТ-среду в целом, независимо от того, на каком ПП функционирует тот или иной ее ИТ-компонент. К тому же, как считает г-н Рыстенко, для безопасности ПП вторично, с помощью какого инструмента он создан — построенного на СПО или ППО. Куда важнее используемая технология разработки ПП. Из этого можно заключить, что с равным для ИБ успехом в компании можно использовать как продукты СПО, так и продукты ППО, при условии, что они включены в технологические процессы, соответствующие установленным в компании требованиям ИБ.

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

Заказчики и поставщики

Особенности экосистемы СПО быстро вывели заседание круглого стола на обсуждение модели отношений между заказчиком программных продуктов и их поставщиком.

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

По экспертной оценке специалистов веб-сайтов InfirmIT.com, Tamingthe Beast.net и CloudTweaks.com, в числе главных недостатков СПО находится его, как они выражаются, бесхозность, которая ставит пользователей СПО в зависимость от настроений группы разработчиков того или иного СПО-продукта продолжать работу над ним, ведь при отсутствии такого настроения пользователи должны быть готовы к тому, чтобы сопровождать продукт собственными силами.

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

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

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

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

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

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

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

Основные фонды российских предприятий списываются в среднем через десять лет, примерно с такой же периодичностью предприятия стараются обновлять ПО, а по многим категориям фондов цикл этот имеет тенденцию сокращаться. Согласно наблюдениям Елены Соломатиной (НЦПР) жизненный цикл ПО у тех заказчиков, с которыми ей приходилось работать, составляет семь лет, более длительная поддержка ПП является исключением.

Ключевым критерием, определяющим продолжительность поддержки ПП, как отметил Андрей Бешков (Microsoft), является предназначение программного обеспечения — общее и специализированное. Работая на массовый рынок, разработчики ПП планируют жизненный цикл своих продуктов, исходя из рыночной конъюнктуры. Следуя за нею, они выпускают новые ПП или продлевают срок поддержки остающихся востребованными (как это произошло, например, с операционной системой Windows XP, поддержка которой продлена до 13 лет).

Будучи исполнителями специальных заказов на ПП (например, закрытого ПО для государственных структур), разработчики берут на себя обязательства по срокам поддержки, диктуемым заказчиком и составляющим порой десятилетия. Взаимодействие таких особенных заказчиков с внешними поставщиками и исполнителями работ определяется установленными регламентами, такими как принятый 7 июня 2013 г. закон № 114-ФЗ “О внесении изменений в Федеральный закон “О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд”.

Российские заказчики, реально озабоченные вопросами ИБ, предпочитают, как отмечает Аркадий Тагиев (РОСА), заключать договоры с российскими же разработчиками ПП, которые в состоянии выполнить весь объем требований, предъявляемых к ПП, использовать для этого любые средства разработки, в том числе и СПО (и в этом случае взять на себя обязанности по документированию и проверке конечного ПП). Такой ПП живет до тех пор, пока заказчик не потребует его утилизации.

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

Как представитель компании, в которой ведется разработка программного обеспечения с использованием СПО и ППО (в том числе и собственного ППО), г-н Рыстенко, рекомендует в тех случаях, когда заказчику важно, чтобы в ПП не было закладок, выбирать СПО, искать специалистов, которые код ПП проанализируют и сертифицируют, или найти уже сертифицированный вариант. Если же это качество второстепенно, то он советует покупать готовые проприетарные ПП — в итоге это будет дешевле.

Г-жа Соломатина усматривает несколько проблем в отношениях разработчиков СПО с госзаказчиками, прежде всего, касающихся ценообразования. По ее мнению, те цены, которые предлагают госзаказчики, не всегда соответствуют ожиданиям разработчиков.

Другой важной проблемой в этой области она называет регулирование прав на интеллектуальную собственность. В соответствии с типовым договором на разработку программный продукт может оказаться собственностью либо заказчика, либо разработчика, либо в совместном владении. Однако госзаказчики, особенно представляющие силовые структуры, на практике реализуют исключительно передачу ПП в свою собственность (разработчик может потом участвовать в конкурсе на поддержку, имея некоторые преференции как провайдер, хорошо знающий объект поддержки). В то же время зарубежные вендоры ППО сохраняют права собственности на свои ПП, даже при их продаже в силовые структуры нашей страны.

Через стандарты и сертификаты к ИБ СПО

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

Как отметил г-н Тагиев, залогом безопасности и надежности ПП является сопроводительная документация, используя которую как раз и можно проверить свойства продукта.

Однако объем кода любого ПП за последние пару десятилетий увеличился в несколько раз (иные эксперты утверждают, что на порядки), и документировать процесс разработки с той же подробностью, что и в 80-е годы (пожелание о чем высказали некоторые участники круглого стола), нереально. В стране назрела потребность пересмотреть с учетом этого действующие в данной области ГОСТы.

Тем не менее, как считает Валерий Иващенко (“КБПМ — Информационная безопасность”), если для решения поставленной заказчиком задачи нужна подробная документация, то разработчики в состоянии выполнить эти требования, важно только, чтобы заказчик трезво оценивал сроки и выделяемые на создание ПП средства.

В нашей стране действуют системы сертификации ПО, определяющие требования на соответствие разным условиям эксплуатации. Так, базовыми требованиями к ПО со стороны одного из главных российских регуляторов — ФСТЭК РФ — являются отсутствие недекларированных возможностей (НДВ) и соответствие реальным и декларированным возможностям (РДВ). По мнению г-жи Соломатиной, разработчики, независимо от того, обладают они какими-либо лицензиями регуляторов или нет, должны иметь более простой доступ к требованиям и методикам регуляторов, касающимся разработки ПО и его сертификации.

Доступность кода для проверки независимо от того, проприетарный он или открытый, является обязательным условием для контроля его безопасности, в том числе и для сертификации. Продукты СПО, как считают некоторые из наших экспертов, выигрывают в сравнении с проприетарным ПО в готовности к проверкам на соответствие требованиям НДВ и РДВ из-за доступности кода и его анализа многими специалистами. Под давлением требований регуляторов иностранные вендоры ППО тоже все активнее инициируют передачу кодов своих ПП в российские сертификационные лаборатории.

Основные выводы

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

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

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

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

Разработчики СПО, участвовавшие в дискуссии, признали, что видят в повышении ИБ своих продуктов перспективы для развития их собственного бизнеса и рынка СПО в целом. Более того, они считают безопасность и стабильность открытого кода локомотивом роста популярности СПО и отмечают при этом, что свойства самой экосистемы СПО позволяют ПП, созданным на базе СПО, проще проходить процедуры сертификации. Они подчеркивают, что среди таких ПП есть имеющие весьма высокие ИБ-сертификаты, в том числе и российские.

По мнению наших экспертов, нынешнее состояние экосистемы СПО и уровень подготовки российских программистов, предпочитающих работать по этой модели, вполне могут соответствовать самым высоким требованиям к ИБ со стороны российских заказчиков, в том числе в спецпроектах. Главным при этом признаются факторы сроков и объемов финансирования.

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

Можно надеяться, что состоявшееся обсуждение вопросов состояния ИБ экосистемы СПО поможет стимулировать поиск новых путей взаимодействия между специалистами, которые занимаются обеспечением ИБ на общегосударственном и корпоративном уровнях, и сообществом, объединяющим энтузиастов СПО.