Программное обеспечение с открытым исходным кодом становится все более распространенным явлением в организациях, создавая другой набор рисков и предполагаемых проблем по сравнению с закрытым исходным кодом или проприетарным программным обеспечением.
Сегодня Форум информационной безопасности (ISF) опубликовал отчет, чтобы помочь специалистам по безопасности осознать преимущества и предполагаемые проблемы использования программного обеспечения с открытым исходным кодом.
«Развертывание программного обеспечения с открытым исходным кодом: проблемы и вознаграждения», в котором IFS созывает информационный документ, посвященный разработке программы защитных мер для эффективного управления развертыванием OSS.
Одна из его целей — детализировать разницу между мифами и реалиями, связанными с использованием открытого исходного кода. Согласно ISF, это понимание имеет решающее значение для защиты компонентов с открытым исходным кодом в приложениях со смешанным кодом.
Программное обеспечение с открытым исходным кодом становится основной частью ИТ-инфраструктуры и приложений. По словам ISF, этот статус в значительной степени обусловлен растущей популярностью методологий гибкой разработки и практик DevOps. В связи с тем, что значительное количество коммерческих и пользовательских приложений, включающих OSS, не может и не должно игнорироваться.
Поскольку OSS становится основой разработки приложений и инфраструктуры, специалистам по безопасности необходимо понимать OSS и решать возникающие проблемы. связано с его компонентами. Исправления этих проблем безопасности должны быть реализованы в рамках программы управления OSS, возглавляемой руководителем, назначенным на должность руководителя программы OSS, настоятельно призывает организацию.
Объединение всех этих мер в единую всеобъемлющую Программа обеспечит целостный и скоординированный подход к управлению рисками OSS, сказал Пол Холланд, главный исследователь-аналитик ISF. Это крайне необходимо для обеспечения безопасности.
«Многие организации внедряют гибкие методологии и методологии DevOps, что способствует расширению использования OSS и, в свою очередь, созданию новых приложений со смешанным исходным кодом». сказал Холланд.
Содержание статьи
Цели далеко идущие
Руководство ISF по развертыванию программного обеспечения с открытым исходным кодом объединяет быстрое исследование для ИТ-работников и других пользователей с открытым исходным кодом на предприятии. Он предоставляет полезные подходы к тому, как организации могут эффективно управлять проблемами использования OSS и почему они должны это делать.
В руководстве также рассказывается о том, как максимизировать преимущества и пожинать плоды использования программного обеспечения с открытым исходным кодом. , В некотором смысле, это практическое руководство от ISF является попыткой закрыть дверь сарая программного обеспечения до того, как в него войдет больше вредоносных программ.
Программное обеспечение с закрытым исходным кодом было одним из основных компонентов ИТ-приложений и инфраструктуры организации. Но многие устоявшиеся и популярные программы на самом деле имеют открытый исходный код. Таким образом, организации должны признать, что OSS уже может существовать в их собственной среде. Он часто используется в сочетании с программным обеспечением с закрытым исходным кодом, создавая то, что называют «смешанным программным обеспечением».
Программное обеспечение со смешанным исходным кодом может быть получено из любого числа комбинаций компонентов OSS. Возможности включают в себя программное обеспечение с закрытым исходным кодом, приобретенный код и внутренний код. Затем разработчики могут объединить эти компоненты вместе для создания специализированного программного приложения со смешанным исходным кодом.
Риски безопасности, связанные с использованием OSS в ИТ-инфраструктуре и приложениях, создают основные проблемы, которые необходимо минимизировать, предупреждает руководство. Эта задача усложняется, если организации имеют ограниченную осведомленность об используемых компонентах OSS. К ним относятся сложные обязательства по лицензированию и интеллектуальной собственности, нехватка соответствующих навыков OSS и отсутствие безопасности в практиках DevOps.
Необходим баланс
Согласованные усилия для надлежащего управления использованием OSS и эффективно необходимо. Растущая распространенность OSS должна быть сбалансирована, призвал Голландия. Для некоторых организаций первым шагом является осознание того, что мифы, связанные с OSS, являются просто иллюзиями.
Для других организаций привлекательность OSS и программного обеспечения со смешанным исходным кодом уже очевидна. Это позволяет им безопасно разрабатывать новые приложения и увеличивать скорость продвижения на рынок новых идей, пояснил он.
OSS часто считают небезопасным и неподдерживаемым. Поскольку эти негативные коннотации продолжают портить его репутацию, некоторые организации официально запрещают его, даже если они могут по незнанию использовать OSS.
Другие с энтузиазмом принимают OSS, используя его преимущества, такие как помощь в гибком и быстром развитии. OSS может оказать положительное влияние на разработку программного обеспечения. Но это может произойти только в том случае, если оно используется и управляется ответственно, согласно последнему руководству ISF.
Поддержка необходима
Руководство рекомендует поддержать руководителя программы OSS организации необходимыми средствами и ресурсами. разработать жизнеспособную программу и команду. Хотя в некоторых случаях существующие инструменты для программного обеспечения с закрытым исходным кодом могут быть расширены для обеспечения безопасности и управления OSS.
Другие случаи интеграции требуют, чтобы команда программы приобрела дополнительные инструменты для дальнейшего повышения безопасности OSS. В соответствии с руководством ISF группа также должна отслеживать каналы аналитики угроз для упоминания компонентов OSS, которые использует организация.
«Сопротивление переходу на OSS может ограничить способность организации к прогрессу и развитию. При эффективном использовании OSS потенциально может стать ускорителем для бизнеса », — сказал Холланд. «Поэтому содействие программе управления OSS жизненно важно для обеспечения безопасности и управления OSS, позволяя организации безопасно его использовать».
Необходимая подготовка
Сочетание динамики открытого источника с устоявшимися практиками управления программного обеспечения с закрытым исходным кодом предоставит последовательную, всеобъемлющую программу управления программным обеспечением. Результат обеспечит наилучшую возможность для достижения успеха, добавил Холланд.
Многие поставщики программного обеспечения с традиционно закрытым исходным кодом принимают принципы OSS. Это означает, что OSS здесь, чтобы остаться, заявил ISF.
Гибкость программного обеспечения с открытым и смешанным исходным кодом может привести к сокращению программного обеспечения с закрытым исходным кодом. В свою очередь, это может привести к фундаментальному сдвигу в управлении программным обеспечением, лицензировании и безопасности.
Исправление неполадок
«Развертывание программного обеспечения с открытым исходным кодом: проблемы и вознаграждения» представляет ряд проблем и предлагает исправления для ряда типичных ИТ-ситуаций. В информации упоминаются конкретные проблемы, связанные с использованием компонентов с открытым исходным кодом.
Одна из представленных проблем заключается в том, как некоторые организации используют программные приложения, в которых открытый код непреднамеренно включен в ИТ-инфраструктуру. Или организации не хватает полного представления обо всех компонентах OSS, развернутых в их среде.
Ситуация включает в себя компоненты с открытым исходным кодом, реализованные неконтролируемым образом и потенциально оставленные в небезопасном состоянии с устаревшими, незапатченными и склонными к уязвимости уязвимостей. Не имея достаточных знаний о том, где и как используется OSS, организация рискует допустить уязвимости в своей инфраструктуре, о которых ИТ-персонал не знает и, следовательно, не может активно ее устранять.
В руководстве отмечается, что это является примером того, что привело к нарушению Equifax. в сентябре 2017 года. В этом случае злоумышленники использовали устаревшую версию Apache Struts, платформы веб-приложений OSS для приложений Java. ИТ-специалисты не знали, что этот компонент платформы OSS существует в корпоративной среде. Поэтому он не был включен в процессы и графики управления исправлениями компании.
Исправления в руководстве
ISF объясняет исправление для этой неработающей проблемы. Это предполагает, что организации создают и поддерживают точную, актуальную инвентаризацию всех компонентов OSS в своей корпоративной среде. Начальная фаза обнаружения может потребоваться, если инвентарь еще не создан или если организация рассматривает возможность использования OSS без официального признания или документирования.
В каталогизируемой информации должны содержаться сведения о копировании закрытого источника. программное обеспечение, источник OSS (например, поставщик, сторонний разработчик, репозиторий OSS или проект внутренней разработки), развернутые версии компонентов OSS, зависимости программного обеспечения, поставщики поддержки и местоположения безопасных обновлений, доступных для загрузки.
Компиляция такой инвентарь может быть создан вручную. Альтернативным вариантом является развертывание инструмента автоматического обнаружения, который сканирует и контролирует инфраструктуру для создания базы данных программного обеспечения и используемых версий.
Отсутствие безопасности в практиках DevOps
Еще одна критическая проблема в Руководство ISF использует пример гибких разработчиков и разработчиков DevOps, которые предпочитают быстрое развертывание приложений, а не безопасность кода. Предлагаемые исправления устанавливают скорость, которая должна быть лучшей практикой для кодирования приложений.
Руководство ISF предлагает, чтобы внутренние разработчики были осведомлены и обучены методам безопасного кодирования, связанным с OSS и некоторыми проблем, с которыми OSS сталкивается при обеспечении безопасности приложений со смешанным исходным кодом. Обязательства разработчиков по безопасному кодированию должны быть изложены в жизненном цикле безопасной разработки (SDL), характерном для OSS.
Это, в свою очередь, должно быть тесно связано с методологией SDL для программного обеспечения с закрытым исходным кодом. Сроки и сроки написания кода должны учитывать внедрение безопасности на этапе проектирования.
Как все устроено
Если организация использует программное обеспечение с открытым исходным кодом и использует центральную модель ИТ, должна быть операторы или кто-то, кто отвечает за ИТ-операции в целом. Этот человек отвечает за обслуживание исправлений и обеспечение выполнения обновлений, по словам Вей Лиен Данга, соучредителя и директора по стратегии в StackRox.
«Это также может быть сделано кем-то в процессе разработки или DevOps команда. Хотя программное обеспечение с открытым исходным кодом часто является экономичным выбором, это не значит, что оно не обходится без накладных расходов. Это происходит в форме опыта и / или обучения для обеспечения того, чтобы код OSS был исправлен и защищен », — сказал он LinuxInsider.
Это одна из причин, по которой организации используют коммерческое программное обеспечение или службу, управляемую облаком. , В этих случаях поставщик программного обеспечения или облачного хранилища несет ответственность за предоставление исправлений. Он добавляет, что вы получаете дополнительное преимущество в виде поддержки и поддержки со стороны.
Среднестатистический ИТ-работник может не знать, как исправить код OSS. Но не редкость, что человек, принявший решение использовать OSS в организации, несет ответственность за его поддержку, пояснил Данг.
«Но проблема в том, что обслуживание этого программного обеспечения становится племенным знанием. Таким образом, если этот человек уходит, другие люди в ИТ-команде должны выяснить, что делать », — предложил он.
Различные обязанности
Обязанности ИТ-работников сильно различаются от организации к организации организация. Но у большого числа организаций очень мало ИТ-ресурсов, которые ориентированы на исправления, по словам Томаса Хэтча, технического директора и соучредителя SaltStack.
«Современные ИТ-специалисты тратят гораздо больше времени на управление API-интерфейсами высокого уровня и UIs. Им приходится иметь дело с большой группой систем и служб, и они не так сосредоточены на управлении системой и OSS, как это было 10 лет назад », — сказал он LinuxInsider.
Сохранение безопасности открытых компонентов программного обеспечения является проблемой, согласился Хэтч.
«Возможность получать огромное количество бесплатных, непроверенных, Непроверенное и необязательно защищенное программное обеспечение с полки создало ответственность, глубоко укоренившуюся в областях, которые интенсивно используют программное обеспечение с открытым исходным кодом », — сказал он.
Обучение для всех
Если мы говорить о центральном ИТ-персонале или о ком-то с ролью ввода / вывода, тогда да, считает Данг. Любой, кто отвечает за ту часть среды, в которой используется OSS, должен обладать этими знаниями.
Если вы используете открытый исходный код, вы берете на себя ответственность за отслеживание исправлений и раскрытие информации о безопасности. Это должно быть обязанностью лица, принимающего решение, которое решило использовать OSS, утверждает он.
«Они должны взять на себя ответственность за управление той частью стека и средой, в которой работает OSS. Они должны также быть ответственным за работу со своей командой над реализацией процесса поддержки исправлений, иначе они рискуют потерять критически важные знания, если покинут организацию », — сказал Данг.
Все ли OSS используют Culprit?
Преимущества приходят от использования программного обеспечения с открытым исходным кодом, но организации должны быть осторожны, чтобы они понимали, как бороться с уязвимостями и проблемами лицензирования, которые могут создать риски, предупредил Данг.
Разработчики программного обеспечения сосредоточены на создании и доставка программного обеспечения. Существуют практики разработки программного обеспечения, независимо от методологии. Те, кто заимствует у открытого источника, должны учитывать безопасность продукта, убежден Данг.
«Это не уникально для DevOps. Если вы пропустите процесс исправления OSS, вы можете легко подвергнуть риску свою организацию », — сказал он.
При использовании OSS в разработке программного обеспечения необходимо учитывать два основных момента. Во-первых, у вас есть правильные инструменты для обеспечения защиты. Во-вторых, у вас есть правильные процессы для управления исправлениями.
У вас должен быть способ обнаружения уязвимостей, проблем с лицензией и других рисков, связанных с использованием OSS. Методология Agile, DevOps и т. Д. Не должна иметь значения.
«Если вы решите использовать OSS, вам необходимо понимать риски безопасности и их последствия, а также быть готовым к тому, чтобы надлежащим образом с этим справиться , — сказал Данг.
Доступность
«Развертывание программного обеспечения с открытым исходным кодом: проблемы и вознаграждения» доступно для загрузки в формате PDF здесь.
Этот информационный документ бесплатный для членов ISF , Не члены могут загрузить документ после заполнения формы запроса на членство.
