В данной статье рассматривается новый подход к безопасности - совместная работа групп обеспечения качества и разработки программного обеспечения для экспоненциального повышения эффективности. В ней объясняется, как процессы обеспечения качества помогают сделать информационные технологии более безопасными, и как системы ИТ-безопасности обеспечивают более эффективную защиту среды тестирования. Читатели также узнают, как лучше внедрить тестирование системы безопасности в жизненный цикл разработки ПО.
Унификация обеспечения качества (QA) программного обеспечения и ИТ-безопасности привела к симбиотическим взаимоотношениям, но лишь немногие организации начали реализовывать преимущества совместной работы в двух этих направлениях. Альянс групп обеспечения качества и ИТ-безопасности естественен, поскольку ИТ-безопасность - это форма обеспечения качества на его базовом уровне. Любой вид незащищенности является проблемой обеспечения качества.
И ИТ-безопасность, и обеспечение качества направлены на уменьшение рисков. Группы ИТ-безопасности занимаются устранением рисков, связанных с безопасностью, а группы обеспечения качества - устранением рисков, связанных с качеством. Таким образом, этот союз не мог не возникнуть несколько лет назад. В данной статье рассматриваются естественные поведенческие точки интеграции между двумя этими подразделениями, а также объясняется, какую помощь может оказать интеграция семейства программных продуктов IBM Rational, Information Management, WebSphere и Tivoli Security.
Важнейшей областью интересов для групп обеспечения качества и ИТ-безопасности является управление доступом. Управление доступом постоянно изменяется и развивается на основе внутренних организационных стандартов и внешних изменений в нормативных документах или в соответствии с политикой ИТ-безопасности. Обычно управление доступом поручается группе разработки ПО. Оно рассматривается как обычное требование, реализуемое в приложении вместе с другими требованиями. Такая практика мешает группам ИТ-безопасности и аудита при трассировке и изменении политик управления доступом оперативно реагировать на изменения требований нормативных документов, таких как SOX, HIPAA, PCI и т.д.
Если политики управления доступом прописаны в приложении, они претендуют на те же ресурсы, что и усовершенствования или улучшения приложения. Владельцы приложений с большей вероятностью захотят потратить деньги на усовершенствования или улучшения приложений, чем на обновление политик управления доступом. В конечном итоге это создает необходимость выноса политик управления доступом за рамки приложения. Кроме того, изменчивая природа нормативных документов еще больше увеличивает необходимость внешнего управления доступом. Организации понимают, что вынос управления доступом за рамки приложения не может не иметь последствий.
Так как же вынести управление доступом за рамки приложения? Группа ИТ-безопасности должна быть вовлечена в жизненный цикл разработки приложения (software development life cycle - SDLC).
Политики должны утверждаться так же, как любые другие требования. Политика безопасности должна быть перечислена в списке требований, в идеале с использованием IBM Rational DOORS, Rational RequisitePro или Rational Requirements Composer. Это важно, поскольку при изменении политик безопасности будет меняться управление доступом. Понимание и отслеживание этих изменений является передовой методикой. Группа обеспечения качества постоянно работает с владельцами приложений и может обеспечить подобный уровень поддержки политик управления доступом.
Сегодня новым стандартом управления доступом является язык Extensible Access Control Markup Language (XACML) - повторно используемый XML-стандарт для управления доступом. XACML предназначен для предоставления надлежащим людям надлежащей информации в надлежащее время. Многие компании внедрили XACML без учета процесса успешной его реализации. Встраивание XACML-процесса в SDLC создает связь с группой разработки ПО. Это идеальный подход для организаций, которые уже имеют встроенные в приложение политики безопасности.
Организации, намеревающиеся применить XACML-подход для управления политиками безопасности, часто сдерживает предположение, что удаление из работающих приложений всех существующих политик безопасности и воссоздание их с использованием XACML трудно выполнить на практике. Данный подход дает организациям возможность сохранить существующие политики безопасности и параллельно создать новые политики в XACML. Работая с группой обеспечения качества, вы фактически встраиваете XACML-процесс в SDLC, а значит при необходимости сможете изменить как архитектуру приложения, так и архитектуру XACML. Это устраняет необходимость удаления всех политик безопасности из существующего приложения и позволяет применить более гибкий подход. Решение, менять существующую политику или использовать новую, повторно используемую XACML-политику, вы сможете принять позже.
Если вы намереваетесь использовать IBM Tivoli Security Policy Manager как средство авторинга XACML-политик, такое ПО как IBM Rational ClearCase и IBM Rational Team Concert может оказаться полезным для управления исходным кодом активов управления доступом. Активы Tivoli Security Policy Manager основаны на XML и легко могут быть сохранены в любом инструментальном средстве. При помощи IBM Rational Functional Tester и IBM Rational Performance Tester можно создавать автоматизированные тесты. Затем можно автоматически тестировать поведение XACML-сценариев при выпуске новых версий продуктов. Кроме того, такие инструментальные средства как DOORS, RequisitePro и Rational Requirements Composer разрешают трассируемость требований к активам Tivoli Security Policy Manager. На рисунке 1 представлены нефункциональные XACML-требования к системе, размещенные в Rational Requisite Composer.
IBM WebSphere ILOG имеет функциональность, позволяющую системам управления бизнес-правилами предоставлять данные механизму Rational Requirements Composer и продуктам Tivoli Security Policy Manager для реализации высокоуровневой абстракции и улучшения трассируемости по всему предприятию. Совместное использование этих продуктов дает возможность организации не только вынести управление доступом за рамки приложения, но и сделать это повторяемым, стабильным и естественным способом, позволяющим развиваться и изменяться.
Рисунок 1. Нефункциональные требования в представлении Rational Requirements Composer
Современные организации разрабатывают приложения, не задумываясь о безопасности до окончания разработки. Это типичный сценарий "молча передать в группу ИТ-безопасности". Проблема этого сценария в том, что любые проблемы безопасности, идентифицированные непосредственно перед развертыванием приложения, доставят большую головную боль как группе разработки, так и группе ИТ-безопасности. Продукт либо будет развернут с дырами в системе безопасности, либо его выпуск задержится, поскольку потребуется больше циклов в SDLC для устранения риска нарушения безопасности.
Давно замечено, что профессионалы по обеспечению качества должны вовлекаться на ранних стадиях жизненного цикла разработки приложений по нескольким причинам. Во-первых, обнаружение проблем с качеством непосредственно перед развертыванием доставляет большую головную боль. Также замечено, что намного легче и дешевле исправить проблемы, обнаруженные на этапе сбора требований, чем после того, как разработчики что-нибудь напишут. Раннее вовлечение в SDLC полезно также потому, что группы обеспечения качества могут приступить к созданию контрольных тестов и сценариев тестирования до компоновки ПО.
Группа безопасности должна делать то же самое, работая рука об руку с группой обеспечения качества, системными аналитиками и разработчиками, помогая системным аналитикам собрать требования и встроить дизайн системы безопасности в дизайн ПО. Аналитики ИТ-безопасности должны также разработать типы тестов, которые необходимо выполнять на каждой стадии. Профессионалы ИТ-безопасности совместно с группой обеспечения качества должны написать контрольные тесты и планы тестирования для каждого теста, который пожелает выполнить группа ИТ-безопасности.
Последние пять лет хакеры атакуют Web-приложения, пользуясь отсутствием взаимодействия между группами обеспечения качества и ИТ-безопасности, приводящим к огромным дырам в приложениях. Деятельность сообщества хакеров сформировала еще одну точку взаимодействия между группами обеспечения качества и ИТ-безопасности. Идея заключается в более раннем начале тестирования безопасности в жизненном цикле разработки ПО. Группы обеспечения качества и ИТ-безопасности будут определять нефункциональные требования, которых должны придерживаться разработчики. Эти нефункциональные требования являются основой для создания групп разработчиков, постоянно думающих о безопасности, а группа обеспечения качества должна работать рука об руку с группой ИТ-безопасности с самого начала. Группа ИТ-безопасности совместно с группой обеспечения качества могут способствовать созданию центра качества для определения стандартных методик безопасного кодирования и тестирования безопасности, а также определить уровни подготовки и обучения программистов в области безопасности.
Простая истина хорошего бизнеса гласит, что выявление дыр в системе безопасности на ранних этапах обойдется организации дешевле, чем их исправление. С другой стороны, выявление дыр в системе безопасности после развертывания приложения или при его подготовке к развертыванию является плохой практикой. Группы обеспечения качества боролись с тестированием безопасности, поскольку эти тесты отличаются от функциональных тестов и тестов производительности. При функциональном тестировании и тестировании производительности ожидаемые результаты документируются до начала теста, и группа обеспечения качества анализирует, насколько ожидаемые результаты соответствуют реальным. При тестировании безопасности группа обеспечения качества имеет дело только с непредвиденными результатами и тестирует неизвестность. Группы ИТ-безопасности могут помочь им в создании этих тестов. Семейство программных продуктов для реализации системы безопасности IBM Rational AppScan может очень помочь группе обеспечения качества быстро начать тестирование уязвимостей приложения. Rational AppScan можно запустить с приложением для обнаружения дыр в системе безопасности на уровне приложения или инфраструктуры.
Сегодня многие организации начали применять корпоративный единый вход, поскольку он предлагает как экономию средств в плане уменьшения времени доступа к данным, так и улучшение безопасности в плане управления паролями. Одной из проблем корпоративного единого входа является профилирование клиентов для работы с различными приложениями внутри организации. В связи с динамической природой экранов входа в систему клиент корпоративного единого входа (ESSO-клиент) может иметь затруднения при распознавании экранов и полей, используемых системой IBM Tivoli Access Manager for Enterprise Single Sign-On (TA MESSO).
Группы ИТ-безопасности могут обратиться за помощью в создании более сложных профилей к группам обеспечения качества. Процесс создания расширенного профиля во многом аналогичен процессу создания сценария автоматизированного тестирования. Группы обеспечения качества, работающие с автоматизированными сценариями, лучше разбираются в работе оконных систем, поэтому они могут предоставить подробную информацию о поведении экранов. Кроме того, тестировщики ПО, расходующие много времени на освоение поведения экранов приложения, могут предложить прагматичный подход к отладке сложного экрана входа.
Также, для поиска причины неправильной работы экрана можно использовать такие средства как IBM Rational Functional Tester и IBM Rational Robot. Проверки правильности в инструментах функционального тестирования могут быть очень полезны для понимания того, какие свойства меняются в данном поле. Рисунок 2 представляет собой снимок экрана программы Rational Functional Tester, отображающего важные свойства окна входа путем проверки правильности свойства и выделения изменяемого свойства. Приведенная на рисунке 2 информация трудна для понимания группой ИТ-безопасности, но проста для идентификации таким инструментальным средством как Rational Functional Tester. Тестировщики программного обеспечения знают множество приемов (например, WinSpy и другие средства), которые могут быть очень полезны при отладке меняющихся окон. Организации могут воспользоваться этими же ресурсами для автоматизированного тестирования и корпоративного единого входа.
Рисунок 2. Пример проверки правильности в Rational Functional Tester
Еще одной проблемой тестирования является безопасность данных вне среды эксплуатации. Сегодня многие организации копируют эксплуатационные данные в среды разработки и тестирования. Проблема заключается в том, что при загрузке в эти среды реальных данных разработчики и тестировщики получают доступ к персональной идентификационной информации (PII), такой, например, как номер социального страхования и дата рождения. Если PII загружается в непроизводственную систему, такая система должна соответствовать всем требованиям SOX, HIPAA, PCI и т.д., а также подвергаться аналогичному аудиту и санкциям. Во многих организациях подобная практика приводит к отрицательным выводам аудита системы безопасности и выливается в многочисленные штрафы.
Еще одной точкой пересечения является оказание группой ИТ-безопасности помощи группе обеспечения качества в создании повторяемых процессов для заполнения очищенными данными непроизводственных сред компании. Группа ИТ-безопасности должна помочь создать сценарии, которые удалят PII из данных до их попадания в среду тестирования и разработки. Группа ИТ-безопасности может помочь группе разработки создать повторяемый процесс заполнения данными, гарантирующий использование очищенных данных.
Программное обеспечение IBM Rational, Information Management и Tivoli способствует этому, предоставляя поддержку создания такой среды на уровне инструментальных средств. Можно интегрировать продукт IBM Optim Integrated Data Management в Rational Quality Manager, что позволит заполнять систему свежими очищенными данными до начала тестирования. Этот процесс помогает также группе обеспечения качества, обеспечивая стабильный стенд для тестирования состояния приложения, облегчающий создание сценариев автоматизированных тестов. Продукты Tivoli Security Information и Event Manager можно также использовать для мониторинга процесса очистки, чтобы гарантировать загрузку корректных очищенных данных и отправки предупреждений при обнаружении ошибок.
Группы ИТ-безопасности и обеспечения качества должны совместно работать над безопасностью приложений, управлением доступом, корпоративным единым входом и управлением тестовыми данными. Два совместно работающих бизнес-подразделения экспоненциально увеличивают свою эффективность. Результатом будет подразделение обеспечения качества, более ориентированное на безопасность, и подразделение ИТ-безопасности, более ориентированное на качество, что поможет устранению большего количества рисков и обеспечит лучшую преемственность.