Журнал "Information Security/ Информационная безопасность" #1, 2021

– Да, конечно. Но я не люблю термин "безопасная разработка", он понятен только профессионалам в информа- ционной безопасности. Вы знаете, очень тяжело переводить на русский язык анг- лийские слова, потому что Secure и Security – это разные понятия, а Security Development Lifecycle и Secure Develop- ment Lifecycle переводят одинаково – как жизненный цикл безопасной разра- ботки. Но есть разница... Часто этот термин ассоциируют с раз- работкой безопасных систем, но это тоже не совсем точно. Потому что это создает иллюзию, что, проверив резуль- тат разработки на отсутствие уязвимо- стей и НДВ, мы можем говорить о его безопасности. Поэтому, когда мы гово- рим о безопасной разработке, наверное, правильнее было бы иметь в виду, что требования обеспечения безопасности должны учитываться во всех процессах разработки наравне с требованиями функциональности, производительности, надежности и т.д. Вы верно подметили в начале нашего разговора, что безопасность системы гораздо шире, чем информационная безопасность. Это нужно иметь в виду, когда речь идет о безопасной разработ- ке: безопасность – это не только отсут- ствие уязвимостей и борьба с утечкой информации, но это также и основная составляющая общей надежности про- дукта. Почему-то, создавая информа- ционные системы, разработчики всегда думают о надежности работы, об отсут- ствии ошибок, об удобстве использова- ния и т.д., но ведь наличие уязвимости – та же ошибка, и с ней нужно ровно так же бороться, как с неправильно рабо- тающей кнопкой в интерфейсе. Раньше продукты выпускались на рынок практически без тестирования, потому что нужно было "быстрее- быстрее, вперед-вперед". Что уж гово- рить о контроле безопасности разработ- ки! Сейчас, когда мы говорим о каче- ственной разработке, то подразумеваем наличие систем автодокументирования, автоматическое тестирование и т.д. Вот точно так же нужно говорить об автоте- стах на безопасность, как и об автотестах на все остальное. Конечно, это следствие появления Agile-концепции в ИТ, и это неплохо. Просто нужно уметь правильно ей пользоваться. Как? Для этого необхо- димо вдумчиво читать литературу, а не ограничиваться поверхностным ознаком- лением с двенадцатью принципами Agile. Ведь существует огромное количество фреймворков, которые позволяют сде- лать Agile надежным, безопасным, управ- ляемым, предсказуемым. А еще береж- ливым – есть даже такой термин, Lean Agile (бережливый), эта тема сейчас очень актуальна. Последнее время активно развиваются фреймворки, которые позволяют управ- лять большими проектами разработки. Agile – это хорошо, гибко, быстро и эффективно, когда есть самооргани- зующаяся команда, как правило, разме- ром не более десяти человек. Как только в команде оказывается более десяти человек, необходимо тратить дополни- тельные усилия на их организацию. В этот момент и возникают проблемы нормализации работы. Agile-разработку часто называют хаотичной в противовес "водопаду". Я заметил, что многие компании стали задумываться о том, как сформулировать новые принципы разработки, во многом заново изобретая велосипед. Например, Sbergile – фреймворк, который Сбербанк создал и позиционирует на российском рынке как систему управления крупной разработкой. Впрочем, Сбербанк, несо- мненно, может себе позволить потратить большое количество ресурсов и времени на создание собственного фреймворка управления Agile-разработкой. Большин- ству же компаний, наверное, целесооб- разней выбрать один из имеющихся. Есть различные готовые фреймворки, например SAFe, который позволяет командам с десятками, сотнями и тысяча- ми разработчиков выстроить управление и получать запланированный результат в прогнозируемый срок в рамках выде- ленного бюджета, не забывая при этом про безопасность. И здесь без изменения образа мыслей, культуры разработчиков, представителей ИБ, как, впрочем, и вла- дельцев бизнеса, не обойтись. Это то, чем мы сейчас активно занимаемся. Некоторое время назад один из ведущих мировых производителей систем для управления разработкой подписал с нами дистрибьюторское соглашение, и в дан- ный момент мы активно продвигаем это решение на рынке. Речь о Digital AI. Это название появилось только в прошлом году вследствие объединения нескольких компаний, которые занимались управ- лением разработкой. Так в нашем порт- феле появился новый класс продуктов Intelligent Value Stream Management Plat- form, но это, наверное, тема другого раз- говора. – То есть можно сделать вывод, что безопасность систем зало- жена в процессе безопасной раз- работки? – Именно так. Есть актуальный термин Shift Left, смысл которого можно пере- дать как "давайте думать пораньше". Я уже упоминал русскую поговорку про солому, так вот, давайте думать, где мы можем упасть, заранее, и давайте возь- мем с собой правильную "соломку", я говорю об интегрированной безопасно- сти. Концепция Shift Left позволяет в условиях хаотичной разработки смещать контрольные функции, функции дизайна безопасности на более ранние этапы. Другими словами, недостаточно тести- ровать конечный продукт, тестирование должно происходить на более ранних фазах, когда продукт только начинает разрабатываться, а еще лучше тестиро- вать на безопасность алгоритмические модели, когда они только придумывают- ся. Это, конечно, непросто, это требует изменения культурного кода разработки, но это дает хороший результат, и прежде всего в деньгах, в повышении качества и скорости разработки. Безопасная разработка – это целый комплекс мероприятий, который требует изменения подхода к процессу разра- ботки. Я горячо поддерживаю ФСТЭК, который вынуждает разработчиков систем безопасности не ограничиваться проверкой кода на уязвимости и недек- ларированные возможности, но и раз- вивать новый подход к обеспечению уровня доверия к процессу разработки, а это и есть Shift Left. Необходимо рас- ширить этот подход на создание всех информационных систем, критичных для бизнеса, пользователей и нашей страны в целом. То есть мы должны быть уве- рены в процессе нашей разработки, в ней уже реализован определенный ком- плекс мер, обеспечивающий безопас- ность. Вот это и есть Security by Nature! – Цифровизация образования, экономики, медицины и других сфер – это хорошо или плохо? – Это отлично! Это повышение доступ- ности. – И минусов нет? – Минусы есть везде. Цифровизация – это хороший тренд, но многие путают цифровизацию и автоматизацию, а это абсолютно разные вещи. Так же, как мно- гие берут свои классические команды разработки, называют их Agile-командами или переименовывают программ-менед- жеров в продакт-менеджеров, хотя это разные роли и без изменения образа мысли это не работает. Поэтому, когда речь идет о цифровизации, многие думают, что, переведя процессы в автоматизиро- ванную систему, они выполнили условия цифровизации. Категорически – нет! Цифровизация требует не только замены инструментов; замены бумаги на электронные бланки недостаточно. Цифровизация требует радикального изменения в подходах к ведению бизне- са, созданию цифрового продукта, к раз- работке нового программного обеспече- ния, отвечающего этому подходу, сейчас ПО становится основным средством про- изводства пользовательской ценности, которым раньше были станки и конвей- еры, и его безопасность нужно обес- печивать по-другому. ПО нельзя поста- вить за забор и нанять охрану, оно гораздо доступней для вторжения извне и внутренней диверсии, именно поэтому вопросы информационной безопасности настолько важны в современном мире. Но при всем при этом не нужно на них зацикливаться, это лишь один из крите- риев надежности, необходимый, но недо- статочный для успеха бизнеса. • 9 ПЕРСОНЫ www.itsec.ru