Управление рисками Open Source в разработке приложений для финансового сектора

Дата: 28.09.2021. Автор: Web Control. Категории: Статьи по информационной безопасности
Управление рисками Open Source в разработке приложений для финансового сектора

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

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

Использование Open Source

Как и в случае со многими другими новыми технологиями, финансовый сектор медленно приходил к использованию open source. Финансовые компании были обеспокоены тем, что они потеряют свои конкурентные преимущества, если будут разрабатывать программное обеспечение на основе open source, или тем, что компоненты с открытым исходным кодом не будут соответствовать строгим нормативным требованиям. И еще шесть или семь лет назад, когда был основан Fintech Open Source Foundation (FINOS), открытый исходный код не был так распространен в банковской сфере, как сегодня.

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

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

Управление риском open source

Сегодня финансовая отрасль понимает огромную ценность open source и практически повсеместно использует его. Разработка с использованием компонентов с открытым исходным кодом необходима для создания высококачественного программного обеспечения со скоростью, которую нам предлагает Agile. C таким широким использованием open source растет внимание к уникальным проблемам его безопасности.

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

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

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

Внедрение управления уязвимостями open source

Банки не склонны к риску. Они понимают, что внедрение программы управления уязвимостями открытого кода — это один из способов снижения риска. Проблема для финансового сектора заключается в управлении open source компонентами как в современных приложениях, так и в унаследованных системах.

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

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

Отделение сканирования от обнаружения уязвимостей

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

Из-за особенностей раскрытия информации об уязвимостях open source сканирование только при фиксации нового кода является ошибкой. Это просто недостаточно часто. Например, приложение может быть безопасным в 7 вечера, а в 8 вечера может обнаружиться и оказаться публично раскрытой информация о критической уязвимости. При этом программный код приложения не менялся. Организации не могут рисковать и ждать несколько часов, прежде чем будет выявлена и устранена уязвимость, которая может привести к раскрытию личной информации. Они должны устранить ее немедленно.

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

Обеспечение прозрачности кода

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

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

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

Анализ композиции кода

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

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

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

Если вы задумываетесь о внедрении системы анализа композиции кода и вам нужна помощь в выборе подходящего решения, можете связаться с нашим экспертом по UAM-решениям [email protected]

© Данная публикация защищена законодательством РФ об авторских и смежных правах. Распространение разрешается при условии указания ссылки на источник и автора.

Web Control

Об авторе Web Control

Компания Web Control – российский дистрибьютор специализированных решений систем управления внутренней безопасностью и оптимизации сетей.
Читать все записи автора Web Control

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *