Loading...
Новости

Решение проблемы безопасности программного обеспечения для финансовых услуг в 2021 году

Решение проблемы безопасности

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

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

В то время как некоторые правила являются явными, например PCI-DSS, другие являются более общими, просто заявляя, что PII должна быть защищена от атак. Однако, чтобы соответствовать любому основному нормативному стандарту, организации должны иметь представление о рисках, уязвимостях и потоках данных в своем программном обеспечении. У них также должны быть системы и план для решения этих проблем.

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

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

Приложения для ранжирования рисков

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

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

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

Установление четких требований безопасности

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

Например, организация может (и должна) диктовать эти приложения не могут быть развернуты, если обнаружена «серьезная» уязвимость. Автоматизированный процесс сборки приложения должен останавливаться, если и когда возникает это условие.

Постоянное выявление уязвимостей

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

Решения для статического тестирования безопасности приложений (SAST) могут интегрироваться в SDLC с самого начала этапа кода, через репозиторий исходного кода при проверке нового исходного кода или добавлении в процессы автоматизированной сборки. Анализ состава программного обеспечения (SCA) может использоваться в ранних сборках для выявления зависимостей с открытым исходным кодом и сопоставления компонентов с публично раскрытыми уязвимостями, продолжаясь на этапе тестирования / обеспечения качества. Интегрированное тестирование безопасности приложений (IAST) может выполняться во время автоматизированного функционального тестирования на этапе тестирования / контроля качества.

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

Предоставление разработчикам возможности безопасно кодировать с самого начала

Это важно чтобы группы безопасности с самого начала играли активную роль во взаимодействии и сотрудничестве со своими коллегами DevOps. Обучение здесь имеет огромное значение.

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

За счет внедрения передовых методов и обеспечения безопасности Обучение программированию (SCE) — это непрерывный процесс, группы безопасности могут упростить разработчикам безопасный код с самого начала. Разработчики также могут быть более восприимчивыми к обучению, когда оно актуально, с большей готовностью усваивать извлеченные уроки и, в конечном итоге, становиться лучшими защитниками безопасности для организации. Также может быть полезно специально определить чемпионов по безопасности в командах разработчиков, чтобы стать лицом этой команды по вопросам безопасности и иметь более тесную связь с группой безопасности по сравнению с остальной командой разработчиков.

Помнить, что безопасность приложений — это не разовая задача

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

Крайне важно продолжать мониторинг программного обеспечения с открытым исходным кодом на предмет недавно обнаруженных уязвимостей в SDLC. Некоторые уязвимости, такие как ShellShock (CVE-2014-6271), были обнаружены только спустя десятилетия после появления исходной уязвимости. Без видимости как версии компонента с открытым исходным кодом, так и его местоположения в кодовой базе очень сложно найти и исправить уязвимости. Эффективная безопасность приложений сегодня должна быть непрерывной.

Проложить курс для достижения успеха

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

То, как финансовые организации создают программное обеспечение сегодня, резко отличается от того, что было десять лет назад, с новыми моделями разработки, которые помогают доставлять программное обеспечение быстрее, чем когда-либо прежде.

Хотя на сегодняшний день организации, предоставляющие финансовые услуги, имеют хорошую репутацию, им необходимо активизировать усилия и сделать их непрерывными с самого начала в SDLC, интегрируя различные инструменты тестирования в единую целостную перспективу с комбинацией результатов SAST, SCA и IAST. На таком высококонкурентном рынке просто больше невозможно поставлять что-то, что не было проверено на наличие проблем безопасности на протяжении всего процесса разработки. Риски просто слишком велики.

Мы полагаемся как на само программное обеспечение, так и на его безопасность, чтобы совершать миллиарды транзакций каждый день. Пришло время обеспечить интеграцию безопасности с самого начала SDLC. Это только поможет компаниям в этой области лучше управлять, измерять и устранять риски, расширять возможности групп разработчиков и гарантировать безопасную доставку программного обеспечения со скоростью DevOps.