Безопасность должна быть главной заботой до, во время и по окончании процесса разработки ПО
Эксперты считают, что хотя абсолютная безопасность приложений почти невозможна, есть главные шаги, которые следует предпринять, чтобы снизить риск.
1. Определите процесс
Первый шаг — это определить процесс, который вы собираетесь использовать для разработки и оценки безопасности вашего ПО.
Разработка ПО включает несколько этапов — от сбора требований и составления проекта до собственно разработки, тестирования и внедрения. Вы должны рассмотреть, как должны быть оснащены ваши существующие процессы на каждом этапе разработки, чтобы обеспечить безопасность, говорит Бен Челф, директор по технологии Coverity, компании, разрабатывающей инструменты статического анализа исходного кода.
“Определение процесса включает продумывание стандартов программирования для ваших разработчиков с тем, чтобы избежать потенциально опасных конструкций кода, а также продумывание того, как спроектировать систему безопасным образом, чтобы не было незапланированного доступа даже в том случае, когда сам код “пуленепробиваемый”, и т. д.”, — говорит Челф.
Безопасность не есть что-то, что можно просто прилепить в конце процесса, после того как выполнена сборка всей системы, добавляет он. Это уже будет слишком поздно. Имея хороший процесс, который охватывает весь жизненный цикл разработки ПО, вы можете установить контрольные точки, чтобы убедиться, что безопасность обеспечивается надлежащим образом.
Однако нет одного такого процесса, который подходит для всех организаций.
“Компании, которые, на мой взгляд, можно отнести к числу самых успешных, набирали команду экспертов в области безопасности, чтобы они помогли определить процессы и стандарты для осуществляемой внутри организации разработки ПО, — сказал Челф. — Эту группу следует рассматривать как помощь, а не как оковы для фирмы, занимающейся такой разработкой”.
Эрик Бидстрап, менеджер программы в группе Security Engineering and Community подразделения Trustworthy Computing в Microsoft, говорит, что важно получить поддержку руководства для обеспечения безопасной разработки ПО.
“Приступая к построению безопасного ПО, добейтесь абсолютной поддержки со стороны руководства, включая предоставление вам полномочий прекратить процесс, если он не отвечает вашим заранее заданным, утвержденным и задокументированным спецификациям по разработке безопасного ПО”, — советует Бидстрап.
В самом деле, должны быть установлены приоритеты, обеспечены подотчетность и взаимное участие, прежде чем будет возможен прогресс в достижении безопасности приложений.
“Такая работа требует партнерства между командами, отвечающими за безопасность, и их коллегами в процессе разработки, — считает Майк Уэйдер, директор по решениям в области безопасности в IBM Rational. — Организации должны сделать это приоритетом наряду с построением новой функциональности и соблюдением сроков. Это относится к приложениям, разрабатываемым и внутри, и вне компании. Положение о том, что сторонние разработчики и зарубежные фирмы несут ответственность за поставку защищенного кода, должно быть предусмотрено заключаемыми контрактами”.
Себастьян Хойст, старший вице-президент по сбыту и маркетингу компании PreEmptive Solutions, также рекомендует проводить детальную инвентаризацию существующей ИТ-среды. “Организация должна иметь точный список того, что она разработала и внедрила, а также достоверные сведения о том, где используются эти приложения, для каких целей и кем”, — сказал Хойст.
Самые большие проблемы возникают, когда организации задумываются о безопасности лишь по окончании разработки, добавил Уэйдер.
“Это всё равно, что озаботиться качеством продукта не во время кодирования, а когда он уже находится в производстве, — считает Уэйдер. — Контроль качества должен идти рука об руку с контролем безопасности. Процесс разработки должен быть организован так, чтобы компании начинали думать о безопасности приложения с самого начала, на стадии формирования требований, проекта, разработки и тестирования”.
Адам Колава, соучредитель и главный управляющий Parasoft, компании — разработчика автоматизированных средств контроля качества ПО, говорит, что разработчики должны понимать, что нет универсального средства для обеспечения безопасности и что безопасность являет собой постоянную проблему.
Колава добавил, что важно отказаться от представления об обеспечении безопасности как об устранении ошибок кодирования, прежде всего нужно убедиться, что в коде отсутствуют ошибки, способные пробить брешь в системе безопасности. “Ошибки в безопасности не должны рассматриваться как просто “баги”, — сказал он. — “Баги” вы можете найти или не найти, но вы должны исключить ошибки в безопасности. Другими словами, вы должны гарантировать, что определенные классы ошибок безопасности не существуют в коде”.
2 . Обучите всех участников
Второй шаг в разработке безопасного ПО — это обучить всех игроков в вашей организации, занимающихся такой разработкой.
Безопасность ПО долгое время не была главной в компьютерной разработке, так что вполне вероятно, что ваши программисты, архитекторы, менеджеры по продуктам, инженеры контроля качества и т. д. не обучены должным образом тому, что это означает — проектировать и внедрять безопасное ПО, подчеркивает Челф из Coverity.
“Дело не просто в том, чтобы программировать безопасно, — сказал Челф. — Если у вас есть система, которая превосходно реализована с точки зрения кодирования, но открывает пользователям доступ из-за плохого выбора паролей для них, то считайте, что она все еще не защищена. Так что в реальности озаботиться безопасностью вашей системы нужно на самой ранней стадии жизненного цикла разработки ПО”.
Челф говорит, что есть множество хороших ресурсов, включая книги и онлайн-курсы, для обучения разработчиков тому, как могут быть скомпрометированы системы.
Но кроме книжных знаний, полагает он, разработчики должны и реально уметь это делать.
“Вы можете создать специальную лабораторию с реальной системой и затем проникнуть в эту систему, используя ее слабое место, — сказал Челф. — Дайте вашим разработчикам возможность приобрести опыт отладки уязвимой системы, позволяющий им докопаться до первопричины ее отказа и непосредственно увидеть не только то, сколь трудно выявить проблему в уязвимой системе, но и то, сколь ничтожной зачастую бывает ошибка, которой можно воспользоваться. Цель такого рода упражнений -- заставить ваших разработчиков почувствовать действительные последствия уязвимых мест в системе безопасности продукта”.
Как дополнение к такой лаборатории, предлагает Бидстрап из Microsoft, наладьте процесс отработки замечаний по линии безопасности кодов. “И будьте готовы обновить жизненный цикл разработки системы безопасности на основе того, что вы узнали из анализа первопричин обнаруженных уязвимых мест”, — сказал Бидстрап.
Уэйдер из IBM Rational зашел даже столь далеко, что заявил, что обучение разработчиков критически важно, чтобы победить в войне за безопасность, и что организации должны взять на себя ответственность за такое обучение. “Разработчики редко получают подготовку в области безопасности во время учебы, так что это должно произойти на работе”, — уверен он.
3. Оснастите свою команду
Третий шаг к безопасной разработке — это снабдить членов команды инструментарием и технологиями, которые помогут им строить приложения, защищенные с самого начала.
Челф предупредил, однако, что некоторые из этих инструментов могут замедлить процесс, а это раздражает и менеджеров, и самих разработчиков.
“Будьте внимательны: добавление процессов обеспечения безопасности в вашу разработку потенциально может увеличить сроки выпуска ПО, — сказал он. — Программистам также не нравится все то, что добавляется к их работе и тормозит ее”.
К счастью, есть инструменты, которые могут помочь разработчикам повысить и безопасность, и эффективность собственной работы, говорит Челф. Статический анализ кода — прекрасный способ, заменяющий обременительный процесс проведения вручную анализа всей базы кода на предмет уязвимостей в безопасности, полагает он.
Есть инструменты и технологии, призванные помочь организациям с проверкой, аттестацией и безопасностью и дающие возможность повысить целостность ПО в масштабе всей системы.
“Преимущества, полученные от обнаружения дефектов на ранних этапах процесса разработки ПО, уравновешивают дополнительное время, которое разработчики по вашей просьбе должны потратить на создание защищенного кода, — уверен Челф. — Я рекомендую выбирать инструменты, специально предназначенные для разработчиков. Вы можете выбрать анализаторы, которые сделаны для команды контроля безопасности или QA [аттестации качества], но самую влиятельную группу людей, способных обеспечить безопасность ПО, составляют ваши разработчики”.
Бидстрап из Microsoft также подчеркнул значимость сведения к минимуму риска уязвимостей в реализации с помощью средств статического анализа кода. Он добавил также, что организациям нужно использовать все средства глубокой обороны, применяя лучшее, что доступно из компиляторов и инструментов сборки.
“Вместе с тем, -- говорит Хойст из PreEmptive, -- организациям следует выбирать общие методы, платформы, технологии, архитектуры и поставщиков, чтобы обеспечить согласованность и соблюдение принципа “наименьшего удивления” в масштабе всей корпорации”.
4 .Тестируйте снова и снова
Четвертый шаг в разработке защищенного ПО — это применение методов тестирования безопасности.
Раньше верификация (проверка того, что программа не откажет) и аттестация (проверка того, что она делает именно то, что было задумано) были первоочередными задачами организации разработки ПО, которые нужно было решить до официального выпуска, говорит Челф.
“Однако разница между верификацией/аттестацией и безопасностью заключается в том, что проверить на безопасность гораздо труднее, — отмечает он. — Тестирование, позволяющее убедиться, что программа работает правильно и не откажет, есть нечто наблюдаемое. Тестирование, выполняемое для того, чтобы посмотреть, не может ли быть использован определенный дефект, гораздо труднее для наблюдения”.
Отчасти это проистекает из того, что разрабатывая ПО с мыслью о безопасности, вы действуете против врага, считает Челф.
“Это совсем другая парадигма, нежели просто стремиться, чтобы ваши заказчики были довольны функциональностью, которая работает, — заявил он. — И, действуя против врага, вы должны не только озаботиться тем, не откажет ли система, но и задуматься, как именно она может отказать, так как хакер испробует каждый режим отказа, какой только сможет, чтобы использовать слабость в вашей системе”.
“Реальность в том, что даже если ваше приложение отказывает в 99,9999% случаев безопасным образом, какой-нибудь хакер сможет-таки обнаружить этот один из миллиона режимов отказа, чтобы взломать ваше приложение, — предостерегает он. — И это очень трудно протестировать”.
Как бы то ни было, доскональное тестирование все равно необходимо, говорят эксперты. “Компоненты приложения нужно тестировать по отдельности и все вместе, — подчеркивает Уэйдер. — Часть приложения может быть защищенной сама по себе, но когда введен код, созданный другим лицом, может создаться новая уязвимость в безопасности. Безопасность никогда нельзя принимать как нечто окончательно данное”.
Более того, считает Уэйдер, в последние годы был ряд потрясающих достижений в повышении качества средств тестирования безопасности. “Используемые в сочетании с хорошим процессом и обучением, эти инструменты могут значительно сократить затраты и время, требуемые на тестирование безопасности”, — сказал он.
5. Контролируйте процесс
Наконец, следует непрерывно контролировать соответствие политикам безопасности.
“Контролируйте соответствие политикам безопасности с помощью автоматизированной инфраструктуры, — советует Колава из Parasoft. — В запланированное время каждую ночь автоматизированная инфраструктура должна извлекать последние модификации кода из блока контроля исходника и определять, соответствует ли этот код политике безопасности. Если обнаружена проблема, то разработчика, который ее создал, следует уведомить в рамках его IDE [интегрированной среды разработки], чтобы обеспечить быстрое исправление”.
Этот шаг включает также анализ кода на предмет безопасности и должной бдительности, когда приложения передаются в производство.
“Ни один проект разработки, как бы хорошо он ни был спланирован или выполнен, не останется на 100% защищенным 100% времени, если предоставлен сам себе”, — говорит Андрей Заикин, эксперт в области безопасности и директор проекта компании Exigen Services, специализирующейся на аутсорсинге.
“Наблюдайте за ходом производства, пересматривайте рабочие журналы по мере разработки и участвуйте в процессе последовательным и непрерывным образом”, — советует Заикин.
