Application Security Training
Application Security Training Redefined.
Accelerating Application Security Training and Software Security Education through Interactive Learning
Who We Are
Kontra is built by industry veterans who invented and pioneered the first interactive application security training platform.
What Makes us Different
We don’t offer secure coding quizzes, that are effectively re-skinned multiple-choice questions.
If that’s your idea of educating developers about software security, we are not the company for you.
Developers are who we serve. Adding artificial metrics, meaningless rewards and silly badges is not what we do.
We respect their time far too much to patronize them with these gimmicks.
The days of heavily scripted OWASP Top 10 training videos with robotic voice-overs are over.
Interactive storytelling with realness and purpose in short bursts is what put’s developers in the middle of the action and drives a truly engaging learning experience.
Ludic Fallacy i.e. the misuse of games to model real-life situations is how we think of training labs.
Developers are more engaged in training if the content has a basis in reality rather than contrived examples.
KONTRA
Developer First Application Security Training
Built For Developers, By Developers
Simply Beautiful
We set out to design the most beautiful application security training experience ever built. Backed by the same team that invented the first-ever interactive application security training platform for enterprise developers, we repeatedly pored over every pixel and design element to create a visually stunning and engaging learning experience.
Every minute detail, whether it be a simple tooltip to annotate vulnerable code blocks, or a complex user interface layout has been meticulously crafted from the ground up and relentlessly refined.
Interactive Learning
Learn software security issues visually by tracing a vulnerability from the UI to its source.
Interact with vulnerable components and business logic of real-world examples.
Think like a hacker, analyzing attack surfaces in your applications and recreating their steps.
Understand and apply security code fixes to remediate vulnerabilities.
Integrate with leading Learning Management Systems
Kontra’s SCORM compliant content works out-of-the-box with leading third-party learning management systems and enterprise training platforms to enable faster integration and deployment.
The key providers include WorkDay, Skillsoft, SAP Success Factors, SAP Litmos, Saba Cloud, Oracle PeopleSoft, Looop, Docebo, Cornerstone Learning, Adobe Captivate, Absorb LMS, 360Learning, Rise and many more.
SCORM FIRST
Enterprise Ready
Kontra’s application security training platform is built for companies of all sizes.
From startups that need a solid understanding of application security issues, all the way to the largest enterprises with complex content & scaling needs, our purpose-built learning management system comes with all the features you’d expect from an enterprise-grade appsec training platform.
Learn application security with the frameworks you love
Front-end
Back-end
Mobile
Embedded
DevOps
KONTRA Builder
Want to convert your historical app sec risks into beautiful interactive training content? Easy! Using our powerful content authoring tool, Kontra Builder, we can help you author immersive and captivating learning experiences that are 10x more interesting and relevant for your developers.
Design, build and deploy SCORM compliant interactive applications
Rapidly prototype & build vulnerability scenarios using the storyline editor.
Configure vulnerable applications using our prebuilt template library or build new ones to develop realistic vulnerability simulations.
Configure helper widgets to showcase what’s happening under the hood.
Add code snippets and build beautiful code walkthroughs to showcase how vulnerabilities manifest at a code level.
Publish your content as SCORM packages or integrate them on our Learning Management System.
Ready to start?
Are you ready to take your developer security training to the next level? Request a personalized demo to learn how KONTRA can help you transform your organization’s application security training program.
OWASP TOP-10: практический взгляд на безопасность веб-приложений
Хабр, привет! Мы — Иван Притула и Дмитрий Агапитов, занимаемся разработкой решений, которые делают жизнь людей проще и комфортнее. Сегодня мы хотим представить один из наших новых сервисов – это платежный агрегатор SimplePay. Все что мы делаем продиктовано мучительной невозможностью мириться с несовершенством в целом, и несовершенством конкретных программных решений в частности. Именно в погоне за совершенством и рождаются наши продукты. Стараемся мы изо всех сил, а уж насколько мы близки, судить не нам.
Чтобы Всем было интереснее, мы не будем рекламировать свой сервис (ну если только чуть-чуть). Вместо этого, мы подготовили первую серию публикаций, которая будет посвящена такой увлекательной и крайне актуальной теме, как безопасность Web-приложений. Мы постараемся раскрыть опасности, сопутствующие любому действующему интернет-проекту и простым языком донести всю важность ответственного подхода к рутинным, казалось бы, мелочам в вопросах безопасности данных. Надеемся наши статьи будут не бесполезны для Вас. Уверены, так Вы узнаете нас гораздо лучше.
SimplePay — это современный высокотехнологичный агрегатор платежей. Компания создана в 2014г., зарегистрирована в г. Москве и ведет свою деятельность в соответствии с законодательством Российской Федерации. Наша основная задача, это обеспечение простой, удобной возможности организации приема платежей на интернет-сайтах компаний, вне зависимости от сферы деятельности, масштаба бизнеса и наличия подготовленного технического персонала.
Мы предлагаем следующие услуги:
Безопасность веб-приложений
Современный мир несет в себе тысячи угроз и потенциальных опасностей буквально на каждом шагу и в каждый момент времени. Всемирная сеть, ставшая неотъемлемой частью нашей жизни, не является исключением.
Киберпреступность сейчас развита как никогда – ведь почти каждая компания имеет свой сайт в интернете, а злоумышленник в сети может легко оставаться абсолютно анонимным.
При этом все компании, имеющие сайт в интернете, делятся на три типа:
Акцент на возможности практического применения сделан не случайно. Мы считаем, что недостаточно знать теорию для понимания истинного масштаба угрозы – ведь уязвимости, которые выглядят не очень страшно в теории, зачастую могут нести катастрофические для бизнеса последствия.
Количество угроз растет пропорционально росту бизнеса, однако как показала многолетняя практика, 99% атак происходят через десяток стандартных ошибок валидации входящих данных, либо обнаруженные уязвимости в установленных компонентах программного обеспечения сторонних производителей, либо банально, по халатности системных администраторов, использующих настройки и пароли, установленные по-умолчанию.
Классификацией векторов атак и уязвимостей занимается сообщество OWASP (Open Web Application Security Project). Это международная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения.
OWASP создал список из 10-и самых опасных векторов атак на Web-приложения, этот список получил название OWASP TOP-10 и в нем сосредоточены самые опасные уязвимости, которые могут стоить некоторым людям больших денег, или подрыва деловой репутации, вплоть до потери бизнеса.
В этой вводной статье мы пробежимся по списку OWASP TOP-10, а далее в рамках серии наших статей «Теория и практика защиты Web-приложений» подробно рассмотрим каждый из перечисленных векторов атак, методы практической эксплуатации, степень опасности на примерах реального бизнеса, а также методы практической защиты Web-приложений и Web-сервисов.
Мы постараемся вести изложение максимально доступно, с целью донести информацию не только и не столько до технических специалистов, но также до собственников и управляющих бизнеса, которые, порой, пребывают в счастливом неведении, пока их не сломали злоумышленники, и занимаются онлайн-бизнесом, не ведая о серьезнейшей опасности, нависшей над ними.
1. Инъекции — Injections
Все данные, как правило, хранятся в специальных базах, обращения к которым строятся в виде запросов, чаще всего написанных на специальном языке запросов SQL (Structured Query Language – структурированный язык запросов).
Приложения используют SQL-запросы для того, чтобы получать, добавлять, изменять или удалять данные, например при редактировании пользователем своих личных данных или заполнении анкеты на сайте. При недостаточной проверке данных от пользователя, злоумышленник может внедрить в форму Web-интерфейса приложения специальный код, содержащий кусок SQL-запроса.
Такой вид атаки называется инъекция, в данном случае самый распространённый — SQL-инъекция. Это опаснейшая уязвимость, позволяющая злоумышленнику получить доступ к базе данных и возможность читать/изменять/удалять информацию, которая для него не предназначена.
Например, изменить вместе с именем и фамилией баланс своего счета, посмотреть баланс чужого счета, или же, похитить конфиденциальные личные данные.
Эта уязвимость является следствием недостаточной проверки данных, поступающих от пользователя. Это позволяет злоумышленнику «подсунуть», например, в веб-формы, специально подготовленные запросы, которые «обманут» приложение и позволят прочитать или записать нелегитимные данные.
В целом эта разновидность атак имеет общее название «Ошибки валидации», к ней относятся далеко не только SQL-инъекции и мы будем упоминать этот вектор еще не раз.
2. Недочеты системы аутентификации и хранения сессий (Broken Authentication and Session Management)
Для того, чтобы отличать одного пользователя от другого, web-приложение использует так называемые сессионные куки. После того, как Вы ввели логин и пароль и приложение вас авторизовало, в хранилище браузера сохраняется специальный идентификатор, который браузер в дальнейшем предъявляет серверу при каждом запросе страницы вашего web-приложения. Именно так web-приложение понимает, что Вы это именно Вы.
В случае, если ваш идентификатор украдет злоумышленник, а в системе не были реализованы проверки, скажем IP-адреса сессии, или проверки наличия более одного соединения в одной сессии, злоумышленник сможет получить доступ в систему с правами вашего аккаунта. А если это интернет-банк или кабинет платежной системы, о последствиях такого несанкционированного доступа Вы можете легко догадаться сами.
3. Межсайтовый скриптинг – XSS (Cross Site Scripting)
Межсайтовый скриптинг – еще одна ошибка валидации пользовательских данных, которая позволяет передать JavaScript код на исполнение в браузер пользователя. Атаки такого рода часто также называют HTML-инъекциями, ведь механизм их внедрения очень схож с SQL-инъекциями, но в отличие от последних, внедряемый код исполняется в браузере пользователя. Чем это чревато?
Во-первых, злоумышленник может украсть вашу сессионную cookie, последствия чего были описаны во втором пункте, буквально парой абзацев выше. Нужно отметить, что далеко не все серверы приложений уязвимы к данному типу атак, об этом мы отдельно поговорим в пункте под номером 5.
Во-вторых, могут быть украдены данные, вводимые в формы на зараженной странице. А это могут быть конфиденциальные персональные данные, или, что еще хуже, данные кредитной карты вместе с CVC-кодом.
В третьих, через JavaScript можно изменять данные, расположенные на странице, например, там могут быть реквизиты для банковского перевода, которые злоумышленник с удовольствием подделает и заменит подставными.
4. Небезопасные прямые ссылки на объекты (Insecure Direct Object References)
Данный вид уязвимости является также следствием недостаточной проверки пользовательских данных. Суть ее заключается в том, что при выводе каких-либо конфиденциальных данных, например личных сообщений или учетных карточек клиентов, для доступа к объекту используется идентификатор, который передается в открытом виде в адресной строке браузера, И не реализована проверка прав доступа к объектам. Например, есть страница, которая отображает личное сообщение и она имеет адрес вида:
Перебирая число после «id=» можно будет читать чужие личные сообщения. Эксплуатация данной уязвимости очень проста и не требует вообще никаких специальных навыков – достаточно лишь перебирать число в адресной строке браузера и наслаждаться результатом. Как ни парадоксально, но этой детской болезни, порой были подвержены достаточно крупные европейские платежные системы.
5. Небезопасная конфигурация (Security Misconfiguration)
Безопасность Web-приложения требует наличия безопасной конфигурации всех компонентов инфраструктуры: компонентов приложения (таких как фреймворки – frameworks), веб-сервера, сервера баз данных и самой платформы. Настройки компонентов сервера по-умолчанию зачастую небезопасны и открывают возможности к атакам. Например, кража сессионной cookie через JavaScript при XSS-атаке становится возможна благодаря выключенной по-умолчанию настройке cookie_http only.
При правильной настройке сервера и включенной опции cookie_httponly, получить сессионную cookie через JavaScript невозможно, но зачастую эта простая и важная настройка отсутствовала в таких критично важных местах, как личные кабинеты платежных систем.
Еще один пример детской уязвимости – использование настроек по-умолчанию в серверах баз данных, таких как Redis, Memcached и других – закрытая служба может быть доступна на публичном IP-адресе сервера, и/или использовались пароли, установленные производителем по-умолчанию. Это позволяет злоумышленнику запросто читать и изменять данные, в числе которых, нередко бывают и сессионные cookies (чем это чревато – мы уже знаем) и выводимые пользователям в браузер данные (что позволяет еще и XSS-атаку применить).
Кроме того, программное обеспечение должно быть в актуальном состоянии: уязвимости находят каждый день в самых различных программных компонентах – операционной системе, web-серверах, серверах баз данных, почтовых серверах и т.д. И даже если ваше приложение правильно написано и тщательно проверяет все входящие данные, и вообще, хорошо защищено, это не означает что в один прекрасный момент не найдется уязвимость в вашей ОС или Web-сервере.
6. Незащищенность критичных данных (Sensitive Data Exposure)
Многие веб-приложения не защищают конфиденциальные данные, такие как кредитные карты и учетные данные для аутентификации. Злоумышленники могут украсть или модифицировать такие слабо защищенные данные для использования в своих корыстных целях.
Самый простой пример – передача данных по протоколу HTTP. Дело в том, что данные передаваемые по протоколу HTTP никак не шифруются, а при прохождении данных от компьютера пользователя до Web-сервера, данные пройдут достаточно много различных узлов: маршрутизатор офиса или домашний роутер, маршрутизатор провайдера, маршрутизатор на канале, маршрутизатор в дата-центре хостинг-провайдера сервера и так далее. На каждом из этих узлов может затаиться зловред, так называемый сниффер, программа, которая считывает весь трафик и передает злоумышленнику. А последний просматривает полученные данные на предмет персональных данных и данных кредитных карт.
Такие данные должны передаваться исключительно по протоколу HTTPS, о чем должна гласить соответствующая надпись в адресной строке браузера:
Еще одна задача SSL-сертификата (а именно так называется специальный ключ, при помощи которого осуществляется проверка подлинности и шифрование в HTTPS) – подтвердить, что он выдан именно для данного сайта. В случае, если сертификат просрочен или подделан, Вы увидите следующую картину:
Другой пример – отсутствие шифрования критичных данных, таких как пароли или номера кредитных карт. В случае, если данные зашифрованы, то даже в случае получения несанкционированного доступа на сервер, злоумышленник не сможет украсть критичные данные. К паролям, в частности, должна применяться необратимая хеш-функция – расшифровать шифрограмму при этом не возможно и проверка пароля происходит путем формирования шифрограммы введенного пароля и сравнения ее с имеющейся в базе.
7. Отсутствие функций контроля доступа (Missing Function Level Access Control)
Суть уязвимости, как следует из названия, заключается в отсутствии проверки наличия надлежащего доступа к запрашиваемому объекту.
Большинство веб-приложений проверяют права доступа, прежде чем отобразить данные в пользовательском интерфейсе. Тем не менее, приложения должны выполнять те же проверки контроля доступа на сервере при запросе любой функции. Ведь есть еще множество вспомогательных служебных запросов, которые, зачастую отправляются в фоновом режиме асинхронно, при помощи технологии AJAX.
Если параметры запроса не достаточно тщательно проверяются, злоумышленники смогут подделать запрос для доступа к данным без надлежащего разрешения.
Частный, и пожалуй, самый распространенный случай данной уязвимости мы уже рассмотрели в 4 пункте нашей статьи – отсутствие проверки пользователя в личных сообщениях.
8. Межсайтовая подделка запроса (Cross-Site Request Forgery, CSRF/XSRF)
Вектор атаки CSRF, также известный как XSRF, позволяет злоумышленнику выполнять от имени жертвы действия на сервере, где не реализованы дополнительные проверки.
Например, в некоторой платежной системе для перевода средств на другой аккаунт, есть страница вида:
demobank.com/transfer_money.jsp?transfer_amount=1000&transfer_account=123456789
где transfer_amount – сумма для перевода и transfer_account – номер аккаунта, куда должны быть переведены средства.
Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на вышеуказанную страницу платежной системы. Как результат – деньги уйдут на счет злоумышленника, после чего, вероятно, будут оперативно обменяны на Bitcoin или переведены в другую безвозвратную платежную систему, и получить их назад уже не получится.
Предполагается, что жертва должна была предварительно пройти аутентификацию в платежной системе и должна быть открыта активная сессия (скажем, страница платежной системы открыта в другой вкладке браузера).
Решается проблема достаточно просто и об этом мы расскажем в отдельной статье, посвященной CSRF.
9. Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities)
Зачастую web-приложения написаны с использованием специальных библиотек или «фреймворков» (англ – framework), которые поставляются сторонними компаниями. В большинстве случаев эти компоненты имеют открытый исходный код, а это означает, что они есть не только у вас, но и у миллионов людей во всем мире, которые штудируют их исходный код, в том числе, и на предмет уязвимостей. И нужно отметить, что делают они это отнюдь не безуспешно.
Также уязвимости ищут (и находят) в более низкоуровневых компонентах системы, таких как сервер базы данных, web-сервер, и наконец, компоненты операционной системы вплоть до ее ядра.
Очень важно использовать последние версии компонентов и следить за появляющимися известными уязвимостями на сайтах типа securityfocus.com.
10. Непроверенные переадресации и пересылки (Unvalidated Redirects and Forwards)
Web-приложения зачастую переадресуют пользователя с одной страницы на другую. В процессе могут использоваться ненадлежащим образом проверяемые параметры с указанием страницы конечного назначения переадресации.
Без соответствующих проверок, атакующий может использовать такие страницы для переадресации жертвы на подложный сайт, который, к примеру, может иметь очень схожий или неотличимый интерфейс, но украдет ваши данные кредитной карты или другие критичные конфиденциальные данные.
Этот вид уязвимостей, также как и многие другие перечисленные выше, является разновидностью ошибок проверки входящих данных (input validation).
Вместо заключения
Мы рассмотрели основные виды уязвимостей из OWASP TOP-10 в общем виде, постарались рассказать о них максимально простым языком, а также показать на простых практических примерах, какие риски несут для вашего бизнеса те или иные векторы атак.
В первую очередь эта статья была рассчитана на собственников интернет-проектов и молодых разработчиков. В дальнейших статьях мы осветим более подробно каждый из упомянутых векторов атак, уже с развернутыми техническими подробностями и наглядными примерами, и конечно же, способами защиты.
Если Вы – собственник бизнеса, мы надеемся, что ваше понимание рисков, связанных с IT-безопасностью стало более полным, а следующие статьи могут стать отличным пособием для ваших IT-специалистов.
Страх и ненависть DevSecOps
У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то надо иди до конца.
Источник. Авторы персонажей: Джастин Ройланд и Дэн Хармон.
Что такое SecDevOps? А DevSecOps? В чем отличия? Application Security — о чём это? Почему классический подход больше не работает? На все эти вопросы знает ответ Юрий Шабалин из Swordfish Security. Юрий подробно на всё ответит и разберет проблемы перехода от классической модели Application Security к процессу DevSecOps: как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать при этом, как пройти основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить, чтобы избежать подводных камней.
О спикере: Юрий Шабалин — Chief Security Architect в компании Swordfish Security. Отвечает за внедрение SSDL, за общую интеграцию инструментов анализа приложений в единую экосистему разработки и тестирования. 7 лет опыта в информационной безопасности. Работал в Альфа-Банк, Сбербанк и в Positive Technologies, которая разрабатывает софт и предоставляет сервисы. Спикер международных конференций ZerONights, PHDays, RISSPA, OWASP.
Application Security: о чём это?
Application Security — это раздел безопасности, который отвечает за безопасность приложений. Это не относится к инфраструктуре или к сетевой безопасности, а именно к тому, что мы пишем и над чем работают разработчики — это недостатки и уязвимости самого приложения.
Направление SDL или SDLC — Security development lifecycle — разработала компания Microsoft. На схеме — каноническая модель SDLC, основная задача которой — участие безопасности на каждом этапе разработки, от требований, до релиза и выхода в продакшн. В Microsoft поняли, что в проме слишком много багов, их становится больше и с этим надо что-то делать, и предложили этот подход, который стал каноническим.
Application Security и SSDL направлены не на обнаружение уязвимостей, как принято считать, а на предотвращение их появления. Со временем канонический подход от Microsoft был улучшен, развит, в нем появилось более глубокое детальное погружение.
Канонический SDLC сильно детализирован в различных методологиях — OpenSAMM, BSIMM, OWASP. Методологии отличаются, но, в целом, похожи.
Building Security In Maturity Model
Мне больше всего по душе BSIMM — Building Security In Maturity Model. Основа методологии — разделение процесса Application Security на 4 домена: Governance, Intelligence, SSDL Touchpoints и Deployment. В каждом домене 12 практик, которые представлены в виде 112 активностей.
У каждой из 112 активностей есть 3 уровня зрелости: начальный, средний и продвинутый. Все 12 практик можно изучать по разделам, отбирать важные для вас вещи, разбираться, как их внедрять и постепенно добавлять элементы, например, статический и динамический анализ кода или code review. Расписываете план и по нему спокойно работаете в рамках внедрения выбранных активностей.
Почему DevSecOps
DevOps — это общий большой процесс, в котором нужно заботиться о безопасности.
Изначально DevOps предполагал проверки на безопасность. На практике, численность команд безопасности была намного меньше, чем сейчас, и они выступали не как участники процесса, а как контрольный и надзорный орган, который предъявляет к нему требования и проверяет качество продукта в конце релиза. Это классический подход, в котором команды безопасности находились за стеной от разработки и не принимали участия в процессе.
Основная проблема как раз в том, что ИБ стоят отдельно от разработки. Обычно это некий контур ИБ и в нём 2-3 больших и дорогих инструмента. Раз в полгода прилетает исходный код или приложение, которое нужно проверить, а раз в год производятся пентесты. Это все приводит к тому, что сроки выхода в пром откладываются, а на разработчика вываливается огромное количество уязвимостей из автоматизированных средств. Всё это невозможно разобрать и починить, потому что еще за предыдущие полгода не разобрали результаты, а тут новая партия.
В процессе работы нашей компании мы видим, что безопасность во всех сферах и индустриях понимает, что пора подтягиваться и крутиться с разработкой в одном колесе — в Agile. Парадигма DevSecOps замечательно ложится на методологию гибкой разработки, на внедрение, поддержку и участие в каждом релизе и итерации.
Переход к DevSecOps
Самое важное слово в Security Development Lifecycle — это «процесс». Вы должны это понять, прежде чем думать о покупке инструментов.
Просто включить инструменты в процесс DevOps недостаточно — важно взаимодействие и понимание между участниками процесса.
Важнее люди, а не инструменты
Часто планирование процесса безопасной разработки начинается с выбора и покупки инструмента, а заканчивается — попытками интегрировать инструмент в текущий процесс, которые так и остаются попытками. Это приводит к печальным последствиям, потому что у всех инструментов свои особенности и ограничения.
Распространенный случай, когда отдел безопасности выбрал хороший, дорогой инструмент, с широкими возможностями, и пришел к разработчикам — встраивать в процесс. Но не выходит — процесс построен так, что ограничения уже купленного инструмента не ложатся в текущую парадигму.
Сначала опишите, какой результат вы хотите и как будет выглядеть процесс. Это поможет понять роли инструмента и безопасности в процессе.
Начните с того, что уже используется
Перед покупкой дорогих инструментов посмотрите на то, что у вас уже есть. В каждой компании есть требования по безопасности, которые предъявляются разработке, есть проверки, пентесты — почему бы не преобразить всё это в понятный и удобный для всех вид?
Обычно требования — это бумажный талмуд, который лежит на полочке. Был случай, когда мы приходим в компанию, чтобы посмотреть процессы и просим показать требования по безопасности к софту. Специалист, который этим занимался, долго искал:
— Сейчас, где-то в заметках был путь, где лежит этот документ.
В итоге мы получили документ спустя неделю.
Для требований, проверок и прочего, создайте страницу, например, на Confluence — это удобно всем.
Проще переформатировать то, что уже есть и использовать для старта.
Используйте Security Champions
Обычно, в средней компании на 100-200 разработчиков трудится один безопасник, который выполняет несколько функций, и физически не успевает все проверять. Даже если он старается изо всех сил — в одиночку не проверит весь код, который генерирует разработка. Для таких случаев разработан концепт — Security Champions.
Security Champions — это человек внутри команды разработки, который заинтересован в безопасности вашего продукта.
Security Champion — точка входа в команду разработки и евангелист безопасности в одном лице.
Обычно, когда в команду разработки приходит безопасник и указывает на ошибку в коде, то получает удивленный ответ:
— А вы кто? Я вас вижу в первый раз. У меня все хорошо — мне старший товарищ на code review поставил «apply», мы идем дальше!
Это типичная ситуация, потому что к старшим или просто коллегам по команде, с которыми разработчик постоянно взаимодействует по работе и в code review, доверия намного больше. Если вместо безопасника на ошибку и последствия укажет Security Champion, то его слово будет иметь больше веса.
Также разработчики лучше знают свой код, чем любой безопасник. Для человека, у которого минимум 5 проектов в инструменте статического анализа, обычно сложно помнить все нюансы. Security Champions знают свой продукт: что с чем взаимодействует и на что смотреть в первую очередь — они эффективнее.
Так что задумайтесь над тем, чтобы внедрить Security Champions и расширить влияние команды безопасности. Для самого чемпиона это также полезно: профессиональное развитие в новой области, расширение технического кругозора, прокачка технических, управленческих и лидерских навыков, повышение рыночной стоимости. Это некоторый элемент социальной инженерии, ваши «глаза» в команде разработки.
Этапы тестирования
Парадигма 20 на 80 гласит, что 20% усилий дают 80% результата. Эти 20% — это практики анализа приложений, которые можно и нужно автоматизировать. Примеры таких активностей — это статический анализ — SAST, динамический анализ — DAST, и контроль Open Source. Расскажу подробнее про активности, а также про инструменты, с какими особенностями мы обычно сталкиваемся при их внедрении в процесс, и как это делать правильно.
Основные проблемы инструментов
Выделю актуальные для всех инструментов проблемы, которые требуют внимания. Разберу их подробнее, чтобы не повторяться дальше.
Долгое время анализа. Если от коммита до выхода на прод уходит 30 минут на все тесты и сборку, то проверки на информационную безопасность займут сутки. Так тормозить процесс никто не будет. Учитывайте эту особенность и делайте выводы.
Высокий уровень False Negative или False Positive. Все продукты разные, все используют разные фреймворки и свой стиль написания кода. На разных кодовых базах и технологиях инструменты могут показывать разный уровень False Negative и False Positive. Поэтому смотрите, что именно в вашей компании и для ваших приложений будет показывать хороший и достоверный результат.
Нет интеграций с существующими инструментами. Смотрите на инструменты с точки зрения интеграций, с тем, что вы уже используете. Например, если у вас Jenkins или TeamCity — проверьте интеграцию инструментов именно с этим ПО, а не с GitLab CI, который вы не используете.
Отсутствие или чрезмерная сложность кастомизации. Если у инструмента нет API, то зачем он нужен? Всё, что можно сделать в интерфейсе должно быть доступно через API. В идеале, у инструмента должна быть возможность кастомизации проверок.
Нет Roadmap развития продукта. Разработка не стоит на месте, мы всегда используем новые фреймворки и функции, переписываем старый код на новые языки. Мы хотим быть уверенными, что инструмент, который мы купим, будет поддерживать новые фреймворки и технологии. Поэтому важно знать, что у продукта есть реальный и правильный Roadmap развития.
Особенности процесса
Кроме особенностей инструментов учитывайте и особенности процесса разработки. Например, мешать разработке — это типичная ошибка. Давайте посмотрим какие ещё особенности следует учитывать и на что обратить внимание команде безопасности.
Чтобы не срывать сроки разработки и релиза, создайте разные правила и разные show stoppers — критерии остановки процесса сборки при наличии уязвимостей — для разных сред. К примеру, мы понимаем, что текущая ветка идет на девелоперский стенд или UAT, значит мы не останавливаем и не говорим:
— У вас здесь уязвимости, вы никуда дальше не пойдете!
На этом этапе важно сказать разработчикам, что есть проблемы безопасности, на которые стоит обратить внимание.
Наличие уязвимостей — не преграда для дальнейшего тестирования: ручного, интеграционного или мануального. С другой стороны, нам нужно как-то повысить безопасность продукта, и чтобы разработчики не забивали на то, что находит безопасность. Поэтому иногда мы поступаем так: на стенде, когда выкатывается на девелоперское окружение, просто оповещаем разработку:
— Ребята, у вас есть проблемы, пожалуйста, обратите на них внимание.
На этапе UAT опять показываем предупреждения о уязвимостях, а на этапе выхода в пром говорим:
— Ребята, мы несколько раз предупреждали, вы ничего не сделали — с этим не вас не выпустим.
Если говорить про код и динамику, то необходимо показывать и предупреждать об уязвимостях только тех фич и кода, который был написан только что в этой фиче. Если разработчик передвинул кнопочку на 3 пикселя и мы ему говорим, что у него там SQL-инъекция и поэтому нужно срочно поправить — это неправильно. Смотрите только на то, что написано сейчас, и на то изменение, которое приходит в приложение.
Допустим, у нас есть некий функциональный дефект — то, как приложение не должно работать: деньги не переводятся, при клике на кнопку нет перехода на следующую страницу или не загружается товар. Дефекты безопасности — это такие же дефекты, но не в разрезе работы приложения, а безопасности.
Не все проблемы качества ПО — это проблемы безопасности. Но все проблемы безопасности связаны с качеством ПО. Sherif Mansour, Expedia.
Поскольку все уязвимости — это такие же дефекты, они должны находится там же, где и все дефекты разработки. Поэтому забудьте об отчетах и страшных PDF, которые никто не читает.
Когда я работал в компании, которая занималась разработкой, мне пришел отчет из инструментов статического анализа. Я его открыл, ужаснулся, заварил кофе, полистал 350 страниц, закрыл и пошел работать дальше. Большие отчеты — мёртвые отчёты. Обычно они никуда не идут, письма удаляются, забываются, теряются или бизнес говорит, что он принимает риски.
Что делать? Подтвержденные дефекты, которые нашли, просто преобразуем в удобный для разработки вид, например, складываем в backlog в Jira. Дефекты приоритезируем и устраняем в порядке приоритета наравне с функциональными дефектами и дефектами тестов.
Статический анализ — SAST
Это анализ кода на наличие уязвимостей, но это не то же самое, что SonarQube. Мы проверяем не только по паттернам или стилю. При анализе применяется ряд подходов: по дереву уязвимостей, по DataFlow, по анализу конфигурационных файлов. Это все, что касается непосредственно кода.
Плюсы подхода: выявление уязвимостей в коде на раннем этапе разработки, когда еще нет стендов и готового инструмента, и возможность инкрементального сканирования: сканирование участка кода, который изменился, и только той фичи, которую мы сейчас делаем, что уменьшает время сканирования.
Минусы — это отсутствие поддержки необходимых языков.
Необходимые интеграции, которые должны быть в инструментах, по моему субъективному мнению:
Важны не инструменты, а процесс, поэтому существуют Open Source решения, которые также хороши для обкатки процесса.
SAST Open Source не найдут огромное количество уязвимостей или сложные DataFlow, но при построении процесса их можно и нужно использовать. Они помогают понять, как будет построен процесс, кто будет отвечать на баги, кто репортить, кто — отчитываться. Если вы хотите провести начальный этап построения безопасности вашего кода — используйте Open Source решения.
Как это можно интегрировать, если вы в начале пути, у вас нет ничего: ни CI, ни Jenkins, ни TeamCity? Рассмотрим интеграции в процесс.
Интеграция на уровне CVS
Если у вас есть Bitbucket или GitLab, можно сделать интеграцию на уровне Concurrent Versions System.
По событию — pull request, commit. Вы сканируете код и в статусе build’а показываете, что проверка на безопасность прошла или не прошла.
Обратная связь. Безусловно, обратная связь нужна всегда. Если вы просто выполнили на стороне security, в коробочку сложили и никому ничего не рассказали об этом, а потом в конце месяца вывалили кучу багов — это не правильно и не хорошо.
Интеграция с системой code review
Однажды, мы ставили в ряде важных проектов дефолтным ревьюером технического пользователя AppSec. В зависимости от того, выявлены ли ошибки в новом коде или ошибок нет, на pull request ревьюер проставляет статус на «accept» или «need work» — либо все ОК, либо нужно доработать и ссылки на то, что именно доработать. На интеграцию с версией, которая идет в прод, у нас был включен запрет merge, если тест по ИБ не пройден. Мы это включали в ручное code review, и остальные участники процесса видели статусы по безопасности именно для этого конкретного процесса.
Интеграция с SonarQube
У многих есть quality gate по качеству кода. Здесь то же самое — можно сделать те же самые gates только для инструментов SAST. Будет тот же интерфейс, тот же quality gate, только называться он будет security gate. И так же, если у вас поставлен процесс с использованием SonarQube, можно спокойно все туда интегрировать.
Интеграция на уровне CI
Здесь тоже все достаточно просто:
Например, мы взяли большой проект и решили, что теперь будем сканировать его SAST’ом — ОК. Мы запихнули этот проект в SAST, он нам выдал 20 000 уязвимостей и волевым решением мы приняли, что все хорошо. 20 000 уязвимостей — это наш технический долг. Долг поместим в коробочку, будем потихонечку разгребать и заводить баги в дефект-трекеры. Наймем компанию, сделаем все сами или нам будут помогать Security Champions — и технический долг будет уменьшаться.
А все вновь появляющиеся уязвимости в новом коде должны быть устранены также, как ошибки в юнит или в автотестах. Условно говоря, запустилась сборка, прогнали, свалилось два теста и два теста по безопасности. ОК — сходили, посмотрели, что случилось, поправили одно, поправили второе, следующий раз прогнали — все хорошо, новых уязвимостей не появилось, тесты не провалены. Если эта задача глубже и нужно хорошо в ней разобраться, или исправление уязвимостей затрагивает большие пласты того, что лежит под капотом: завели баг в дефект-трекер, он приоретизируется и исправляется. К сожалению, мир не идеален и тесты иногда падают.
Пример security gate — аналог quality gate, по наличию и количеству уязвимостей в коде.
Интегрируем с SonarQube — плагин ставится, все очень удобно и классно.
Интеграция cо средой разработки
В нашей среде разработки Intellij IDEA просто появляется дополнительный пункт, который сообщает, что во время сканирования обнаружены такие уязвимости. Можно сразу править код, смотреть рекомендации и Flow Graph. Это все расположено на рабочем месте разработчика, что очень удобно — не надо ходить по остальным ссылкам и смотреть что-то дополнительно.
Open Source
Это моя любимая тема. Все используют Open Source библиотеки — зачем писать кучу костылей и велосипедов, когда можно взять готовую библиотеку, в которой все уже реализовано?
Конечно, это так, но библиотеки также пишутся людьми, также включают в себя определенные риски и также там присутствуют уязвимости, о которых периодически, или постоянно, сообщается. Поэтому есть следующий шаг в Application Security — это анализ Open Source компонент.
Анализ Open Source — OSA
Инструмент включает в себя три больших этапа.
Поиск уязвимостей в библиотеках. Например, инструмент знает, что мы используем какую-то библиотеку, и что в CVE или в баг-трекерах есть какие-то уязвимости, которые относятся к этой версии библиотеки. При попытке ее использования инструмент выдаст предупреждение, что библиотека уязвима, и советует использовать другую версию, где уязвимостей нет.
Анализ лицензионной чистоты. У нас это пока не особо популярно, но если вы работаете с заграницей, то там периодически можно получить атата за использование компоненты с открытым исходным кодом, которую нельзя использовать или модифицировать. Согласно политике лицензионной библиотеки, мы это делать не можем. Либо, если мы ее модифицировали и используем, то должны выложить свой код. Конечно, никто не хочет выкладывать код своих продуктов, но от этого тоже можно защититься.
Анализ компонент, которые используются в промышленной среде. Представим гипотетическую ситуацию, что мы наконец завершили разработку и выпустили в пром последний релиз нашего микросервиса. Он там замечательно живет — неделю, месяц, год. Мы его не собираем, проверки по безопасности не проводим, вроде все хорошо. Но внезапно через две недели после выпуска выходит критическая уязвимость в Open Source компоненте, которую мы используем именно в этой сборке, в пром-среде. Если мы не записываем, что и где мы используем, то эту уязвимость просто не увидим. В некоторых инструментах есть возможность мониторинга уязвимостей в библиотеках, которые сейчас используются в проме. Это очень полезно.
Единственный бесплатный из них — это Dependency-Check от OWASP. Его можно на первых этапах включить, посмотреть, как он работает и что поддерживает. В основном это все облачные продукты, либо on-premise, но за своей базой они все равно отправляются в интернет. Они отсылают не ваши библиотеки, а хэши или свои значения, которые высчитывают, и фингерпринты к себе на сервер, чтобы получить известие о наличии уязвимостей.
Интеграция в процесс
Контроль библиотек в периметре, которые скачиваются из внешних источников. У нас есть внешний и внутренний репозитории. Например, внутри Event Central стоит Nexus, и мы хотим, чтобы внутри нашего репозитория не было уязвимостей со статусом «критичный» или «высокий». Можно настроить проксирование с помощью инструмента Nexus Firewall Lifecycle так, чтобы такие уязвимости отсекались и не попадали во внутренний репозиторий.
Интеграция с артефакториями: Nexus и JFrog.
Интеграция в среду разработки. Инструменты, которые вы выбираете, должны иметь интеграцию со средами разработки. Разработчик должен со своего рабочего места иметь доступ к результатам сканирования, либо возможность самому просканировать и проверить код на наличие уязвимостей до коммита в CVS.
Интеграция в CD. Это классная фишка, которая мне очень нравится и про которую я уже рассказывал — мониторинг появления новых уязвимостей в промышленной среде. Это работает примерно так.
У нас есть Public Component Repositories — некие инструменты вовне, и наш внутренний репозиторий. Мы хотим, чтобы в нем были только trusted components. При проксировании запроса проверяем, что у скачиваемой библиотеки нет уязвимостей. Если она попадает под определенные политики, которые мы устанавливаем и обязательно согласовываем с разработкой, то ее не закачиваем и приходит отбивка на использование другой версии. Соответственно, если в библиотеке есть что-то реально критическое и плохое, то разработчик еще на этапе установки не получит библиотеку — пусть использует версию выше или ниже.
Динамический анализ — DAST
Инструменты динамического анализа кардинально отличаются от всего, что было сказано до этого. Это некая имитация работы пользователя с приложением. Если это веб-приложение, мы отправляем запросы, имитируя работу клиента, нажимаем на кнопки на фронте, посылаем искусственные данные из формы: кавычки, скобки, символы в разной кодировке, чтобы посмотреть на то, как приложение работает и обрабатывает внешние данные.
Эта же система позволяет проверять шаблонные уязвимости в Open Source. Так как DAST не знает, какой Open Source мы используем, он просто кидает «зловредные» паттерны и анализирует ответы сервера:
— Ага, тут есть проблема десериализации, а тут нет.
В этом есть большие риски, потому что если вы проводите этот тест безопасности на том же стенде, с которым работают тестировщики — могут случиться неприятные вещи.
— Ребята, вы издеваетесь?! Мы вам дали учетки, а вы стенд положили!
Учитывайте возможные риски. В идеале готовьте отдельный стенд для тестирования ИБ, который будет изолирован от остального окружения хотя бы как-то, и условно проверять админку желательно в ручном режиме. Это пентест — те оставшиеся проценты усилий, которые мы сейчас не рассматриваем.
Стоит учесть, что можно использовать это как аналог нагрузочного тестирования. На первом этапе можно включить динамический сканер в 10-15 потоков и посмотреть, что получится, но обычно, как показывает практика, ничего хорошего.
Несколько ресурсов, которые обычно используем.
Стоит выделить Burp Suite — это «швейцарский нож» для любого специалиста по безопасности. Его используют все, и он очень удобный. Сейчас вышла новая демо-версия enterprise edition. Если раньше это была просто stand alone утилита с плагинами, то сейчас наконец-то разработчики делают большой сервер, с которого можно будет управлять несколькими агентами. Это круто, советую попробовать.
Интеграция в процесс
Интеграция происходит достаточно хорошо и просто: запуск сканирования после успешной установки приложения на стенд и сканирование после успешного проведения интеграционного тестирования.
Если интеграции не работают или там стоят заглушки и mock-функции, это бессмысленно и бесполезно — какой бы мы паттерн не отправляли, сервер будет все равно отвечать одинаково.
Процесс
Немножко обобщенно про процесс вообще и про работу каждого инструмента, в частности. Все приложения разные — у одного лучше работает динамический анализ, у другого статический, у третьего анализ OpenSource, пентесты или вообще что-то другое, например, события с Waf.
Каждый процесс нуждается в контроле.
Чтобы понять как работает процесс и где его можно улучшить, нужно собирать метрики со всего, до чего дотянутся руки, в том числе производственные метрики, метрики с инструментов и из дефект-трекеров.
Любые данные полезны. Нужно смотреть в различных разрезах на то, где лучше применяется тот или иной инструмент, где процесс конкретно проседает. Может быть, стоит посмотреть на время отклика разработки, чтобы понять где улучшить процесс на основе времени. Чем больше данных, тем больше разрезов можно построить от верхнеуровневых до деталей каждого процесса.
Так как у всех статических и динамических анализаторов свои API, свои способы запуска, принципы, у одних есть шедулеры, у других нет — мы пишем инструмент AppSec Оркестратор, который позволяет сделать единую точку входа в весь процесс с изделия и управлять им из одной точки.
У менеджеров, разработчиков и security-инженеров одна точка входа, из которой можно посмотреть, что запущено, настроить и запустить сканирование, получить результаты сканирования, предъявить требования. Мы стараемся уходить от бумажек, переводить все в человеческий, который использует разработка — страницы на Confluence со статусом и метриками, дефекты в Jira или в различных дефект-трекерах, либо встраивание в синхронный/асинхронный процесс в CI/CD.
Key Takeaways
Инструменты не главное. Сначала продумать процесс — затем внедрять инструменты. Инструменты хороши, но дороги, поэтому можно начать с процесса и настроить взаимодействие и понимание между разработкой и безопасностью. С точки зрения безопасности — не нужно «стопить» все подряд, С точки зрения разработки — если есть что-то high mega super critical, то это нужно устранять, а не закрывать на проблему глаза.
Качество продукта — общая цель как безопасности, так и разработки. Мы делаем одно дело, стараемся, чтобы все правильно работало и не было репутационных рисков и финансовых потерь. Именно поэтому мы пропагандируем подход к DevSecOps, SecDevOps, чтобы наладить общение и сделать продукт качественнее.
Начните с того, что уже есть: требования, архитектура, частичные проверки, тренинги, гайдлайны. Не нужно сразу применять все практики на все проекты — двигайтесь итерационно. Единого стандарта нет — экспериментируйте и пробуйте различные подходы и решения.
Между дефектами ИБ и функциональными дефектами знак равенства.
Автоматизируйте всё, что двигается. Всё, что не двигается — двигайте и автоматизируйте. Если что-то делается руками, это не хороший участок процесса. Возможно, стоит его пересмотреть и тоже автоматизировать.
Если размер команды ИБ небольшой — используйте Security Champions.
Возможно, то, о чем я рассказывал, вам не подойдет и вы придумаете что-то свое — и это хорошо. Но выбирайте инструменты, исходя из требований именно к своему процессу. Не смотрите на то, что говорит community, что этот инструмент плохой, а этот хороший. Возможно, именно на вашем продукте окажется все наоборот.
Требования к инструментам.
Доклад Юрия выбрали одним из лучших на DevOpsConf 2018. Чтобы познакомиться с еще большим количеством интересных идей и практических кейсов приходите 27 и 28 мая в Сколково на DevOpsConf в рамках фестиваля РИТ++. А еще лучше, если вы готовы делиться своим опытом, тогда подавайте заявку на доклад до 21 апреля.
