Опубликовала Ольга Иншакова 11 апреля 2023 г. 10:30:00 MSK
Как со временем меняются подходы к безопасной разработке в России? С какими вызовами мы сталкиваемся сегодня? Какие инструменты выбрать, чтобы отвечать на эти вызовы? Обсудили эти и другие вопросы с Даниилом Черновым, директором Центра Solar appScreener компании "РТК-Солар".
Даниил Чернов,
РТК-Солар
"Важно не только заниматься безопасной разработкой внутри своей компании, но и обмениваться опытом в рамках сообществ, рабочих групп и т. д., взаимодействовать с регуляторами. В том числе, на таких мероприятиях как SDL DAY на ТБ Форуме".
– Как, на ваш взгляд, поменялся подход к безопасной разработке в нашей стране за последние несколько лет?– Вопросами контроля безопасности ПО раньше в основном занимались только те организации, которым было важно пройти сертификацию. Испытательные лаборатории проверяли их на соответствие тем или иным требованиям и выдавали сертификат. Инструментальные подходы тоже применялись, но они были достаточно формализованными и общими. То есть базовая безопасность присутствовала, но она нуждалась в развитии и доработке.
Первым важным шагом на пути к этому стало появление ГОСТа по безопасной разработке, благодаря которому у нас появилась своя система координат. Развивались системы сертификации ФСБ и ФСТЭК России. Быстрее всего ситуация с контролем безопасности ПО улучшалась в финансовых организациях. Их эффективность сильно зависит от киберзащищенности. Поэтому они без оглядки на отечественные стандарты и правила применяли лучшие мировые практики.
Что касается инструментов, то это были, прежде всего, пентест и статический анализ (SAST). Когда компании задумывались о безопасности ПО, они нанимали пентестеров, чтобы те проверяли инфраструктуру и искали уязвимости. Некоторые приложения проверяли с помощью SAST.
– Почему именно статический анализ является базовым инструментом?
– У него есть несколько преимуществ, которые позволяют решать основные задачи, связанные с безопасностью ПО. В отличие от пентеста SAST обеспечивает полное покрытие кода. Он увидит все уязвимости, а не только те, которые получилось проэксплуатировать у пентестеров. При этом если речь идет о зрелом продукте, то такой анализатор не просто подсвечивает найденные уязвимости, но и выдает детализированную информацию с рекомендациями по устранению. Кроме того, SAST можно интегрировать в сборочную инфраструктуру на разных этапах разработки ПО в рамках процессов DevSecOps.
– Что изменилось сегодня?
– В нынешних условиях такого двухфакторного подхода, когда мы часть приложений проверяем с помощью пентестов, часть – статическим анализатором, недостаточно. По данным нашего центра противодействия кибератакам Solar JSOC, в 2022 году значительно увеличилось количество атак в отношении органов власти, российских компаний, различных отечественных веб-сервисов. Так, общее количество зафиксированных событий информационной безопасности выросло за прошлый год почти в два раза. Open Source, который мы считали доверенным, стал компрометироваться, туда активно стали внедряться недекларированные возможности и вредоносный код. И в целом риски информационной безопасности критически возросли.
Сегодня при организации процесса безопасной разработки нужно применять комплексный подход, сочетающий все возможные инструменты. Это и статический анализ кода, и динамический, и фаззинг тестирование. Если при разработке используется Open Source, надо также применять такие инструменты, как Software Composition Analysis, чтобы контролировать безопасность сторонних компонентов. При этом процесс управления уязвимостями должен быть непрерывным и не заканчиваться с выпуском продукта. Особое внимание стоит уделить внедрению процессов, обеспечивающих безопасность на всех этапах разработки приложений, системно работать над выявлением и устранением уязвимостей и недекларированных возможностей (НДВ).
– Что в этой ситуации меняется для вендоров, которые выпускают решения для контроля безопасности ПО?
– Нам уже сейчас понятна необходимость объединять различные инструменты в одном интерфейсе, чтобы организации получили удобный и эффективный инструмент. Это позволит скоррелировать данные, полученные с помощью разных инструментов, и получить единую картину: что за уязвимость, где она себя проявляет и какими способами ее можно устранить. Первый, но очень важный шаг в этом направлении мы уже сделали. Последняя версия нашего решения Solar appScreener позволяет выполнить не только статический анализ кода, но и динамический, а также провести корреляцию результатов. И все это в рамках одного интерфейса. Это позволяет повысить качество поиска уязвимостей и снизить количество ложных срабатываний.
– Что сегодня подразумевается под внедрением процессов безопасной разработки? Как оно проходит?
– Все начинается с полного аудита безопасности информационных систем на предмет уязвимостей кода. Затем мы выдаем заказчику рекомендации по выбору методов поиска уязвимостей, проводим тестирование безопасности приложений, обрабатываем результаты и выдаем полный отчет заказчику. И уже на этой основе идет внедрение механизмов контроля безопасности ПО. Происходит интеграция с репозиториями, системами отслеживания ошибок, интегрированными средами разработки и сервисами CI/CD. В итоге анализатор кода бесшовно встраивается в цикл разработки ПО. В идеале нужно прийти к созданию собственного центра контроля безопасности ПО, чтобы системно работать над выявлением и устранением уязвимостей. Кстати, мы в этом тоже помогаем нашим заказчикам.
– Как изменилась нормативно-правовая база безопасной разработки?
– Благодаря совместным усилиям государственных регуляторов и профессионального сообщества все меняется в лучшую сторону. Раньше специалисты по безопасности ПО испытывали сложности с тем, чтобы объяснить руководству, почему те или иные практики и инструменты важно применять в организации. А потом появились нормативно-правовые основания. Прежде всего, это ГОСТ по безопасной разработке, а также системы сертификации ФСБ и ФСТЭК России. При этом последняя стала гораздо более зрелой благодаря появлению Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении. В ней детализированы и описаны все возможные типы проверок. Это монументальный документ, который пережил уже третью редакцию. Он живет и развивается вместе с сообществом, вместе с регуляторами, вместе с теми рисками и вызовами, которые существуют в отрасли.
Кроме того, теперь владельцы объектов КИИ при вводе в эксплуатацию информационных систем обязаны проверять ПО на предмет соответствия требованиям безопасной разработки. Также есть целый ряд требований Банка России к контролю безопасности ПО. А когда появляются требования к вводу в эксплуатацию системы, которая обязательно должна быть проверена, разработчикам нужно к этому заранее подготовиться, то есть применять методы DevSecOps.
– Что еще нужно для того, чтобы культура безопасной разработки развивалась в нашей стране?
– Важно не только заниматься безопасной разработкой внутри своей компании, но и обмениваться опытом в рамках сообществ, рабочих групп и т. д., взаимодействовать с регуляторами. Совместная работа над основополагающими нормативными документами, обмен лучшими практиками позволят существенно повысить защищенность как отдельных организаций, так и нашей страны в целом.
Поделитесь вашими идеями