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

Быть проактивным – зна- чит действовать сейчас для того, чтобы предотвратить проблемы в будущем. Если говорить о разработке, это означает писать код и строить архитектуру так, чтобы в будущем избежать неприятных сюрпризов. На практике далеко не каждая компания имеет пра- вильное представление и ресурсы для создания и под- держки нормального про- цесса проактивной разра- ботки. В последнее время при разработке особенно остро встают проблемы архитектуры, когда ошиб- ки допускаются при напи- сании кода, а при про- ектировании приложения. Примером могут служить хране- ние открытых паролей в сессиях и базах данных, возможность просматривать серверные ката- логи за пределами дозволенного или отсутствие контроля доступа по списку адресов и др. При возникновении брешей в безопасности и их эксплуатации злоумышленниками несправед- ливо будет обвинять лишь изъя- ны в исходном коде. Немало- важную, а иногда и главную роль в обеспечении надежности игра- ет сетевая, серверная безопас- ность. Поэтому следует уделять внимание и качеству разработки, и защите инфраструктуры. Чем грозит использование уязвимости, обнаруженной злоумышленниками? На этот вопрос можно отвечать бесконечно долго и развернуто, но в двух словах: ничем хоро- шим, чаще – очень плохим. В конечном счете все закончится убытками, а также тяжелыми судебными процессами с клиен- тами, партнерами или регули- рующими органами. Компроме- тация защищенных данных, нарушение финансовых потоков, ненужные звонки и СМС, нару- шение режима работы оборудо- вания и вывод его из строя – очень серьезные, но далеко не самые опасные проблемы. Если абстрагироваться от корпора- тивных рисков и вспомнить, с какой скоростью набирает обо- роты использование IoT, то несложно представить, к чему может получить доступ запущен- ный злоумышленником бот, достучавшись до вашей камеры или микрофона. Особенности организации проактивной разработки Быть проактивным – значит действовать сейчас для того, чтобы предотвратить проблемы в будущем. Если говорить о раз- работке, это означает писать код и строить архитектуру так, чтобы в будущем избежать неприятных сюрпризов. Именно проактивность часто становится большим препятстви- ем на пути эффективного взаи- модействия ИТ и бизнеса, ведь она влечет: l увеличение времени разра- ботки, как следствие – ее стои- мости; l повышение затрат на специа- листов, понимающих принципы безопасной разработки и умею- щих ее сопровождать; l повышение требований к чет- кости и слаженности процессов разработки, то есть в компании должны быть специалисты, соз- дающие и поддерживающие эти процессы. Данные факторы рассматри- ваются в многочисленных ком- паниях как "избыточная" разра- ботка, а написание кода в них начинает строиться по непра- вильной траектории: поверхност- ное ТЗ – беглый анализ – быстрая разработка – быстрое тестирование (иногда и вовсе без этого шага) – релиз – патчинг. Это порочный круг. В таких условиях практически любой задаче, решаемой дополнением кода в ПО, потребуется даль- нейшая поддержка. В этом слу- чае будет удачей, если между очередным патчем и новой про- блемой не случится крупномас- штабного инцидента (инъекции, утечки данных, накрутки исхо- дящих звонков и т.д.). В организации процессов разработки не должно быть компромиссов В настоящее время бизнес все чаще основан на ИТ, и вполне целесообразно рассматривать разработку как самолет, на кото- ром летит вся компания. В этой аналогии можно поставить вопрос таким образом: хотели бы вы искать компромиссы в безопасности полета? Думаю, ответ очевиден. К сожалению, на практике далеко не каждая компания имеет правильное представле- ние и ресурсы для создания и поддержки нормального процес- са проактивной разработки. А если ресурсы появляются, то не очень понятно, с чего и как начинать. Давайте попробуем разобрать- ся с самого начала. Безопасная разработка на старте Если вы только стартуете и находитесь на этапе формиро- вания процессов и архитектуры, как полностью с нуля, так и, воз- можно, начинаете новый проект на имеющейся инфраструктуре, то важнейшими факторами для проактивной безопасности будут бизнес-процессы разработки и ключевые этапы жизненного цикла любой задачи. Здесь неважно, по какой мето- дологии вы будете работать, но важно соблюдать стандартные требования, в том числе: 1. Таск-трекинг. Желательно с возможностью формирования бизнес-процесса с разделением на подпроекты (Jira, YouTrack, Basecamp). Особенно важен момент именно с бизнес-про- цессом, так как при увеличении объема задач, как правило, постановка и анализ часто ста- новятся поверхностными, 42 • ТЕХНОЛОГИИ Проактивный поиск уязвимостей в исходном коде настоящее время можно выделить более пятисот видов уязвимостей, встречающихся в исходном коде ПО. Это различные инъекции (“внедрения”), возникающие при слабой параметризации и валидации запросов, проблемы с шифрованием, утечка памяти, межсайтовый скриптинг и многие другие проблемы, способные создать серьезные неприятности тогда, когда вы будете меньше всего к этому готовы. В Владимир Кислицин, технический директор (CTO) Finsight Ventures