- Разработка систем
- Управление разработкой
- Этапы жизненного цикла
- Инициирование проекта
- Управление рисками
- Анализ рисков
- Функциональное проектирование и планирование
- Техническое задание на разработку системы
- Разработка программного обеспечения
- Установка и внедрение
- Эксплуатация и сопровождение
- Удаление
- Виды тестирования
- Анализ завершенного проекта
Для реализации наиболее эффективной системы безопасности, она должна планироваться и управляется на протяжении всего жизненного цикла программного обеспечения, а не реализовываться с помощью сторонних средств, интегрированных во фронтальную часть системы после ее разработки. На протяжении своего жизненного цикла, продукт сталкивается со множеством различных рисков безопасности и инцидентов, поэтому вопросы безопасности должны учитываться с самого начала, с этапа планирования продукта, и на всех последующих этапах – проектирования, кодирования, внедрения и эксплуатации. Если безопасность была добавлена на завершающем этапе разработки продукта, а не учитывалась на каждом этапе его жизненного цикла, стоимость и время, необходимые для обеспечения безопасности такого продукта, резко возрастают. Безопасность не следует рассматривать как короткий спринт, это длинный марафон со множеством препятствий.
Многие разработчики, программисты и архитекторы знают, что добавление безопасности на поздних этапах реализации системы значительно дороже и сложнее, чем ее интеграция в систему, начиная с этапов планирования и проектирования. Различные компоненты безопасности при их реализации на поздних этапах реализации системы, могут оказать негативное воздействие на многие аспекты ее функционирования, ограничивая ряд уже разработанных функций и заставляя систему работать нестандартными и не предусмотренными способами. Такой подход обходится дороже, поскольку разработчикам нужно вернуться к проектированию, внести изменения в код программы, пересмотреть отдельные аспекты архитектуры системы.
Многие разработчики знают, что хорошее управление проектом обеспечивает движение проекта в правильном направлении, наличие необходимых ресурсов и информации, а также планов на случай возникновения проблем и непредвитенных обстоятельств (по принципу «надейся на лучшее, но готовься к худшему»). Управление проектами является важной частью разработки программных продуктов, а управление безопасностью является важной частью управления проектами.
План обеспечения безопасности должен быть составлен в начале проекта разработки и интегрирован в функциональный план. Это гарантирует, что безопасность не будет забыта. Первоначальный план носит общий характер, охватывает весь проект и ссылается на документы, содержащие более подробную информацию. Он может ссылаться на компьютерные стандарты (RFC, стандарты IEEE и лучшие практики), документы, разработанные в рамках предыдущих проектов, политики безопасности, планы реагирования на инциденты, национальные или международные руководящие документы (Оранжевая книга, Красная книга, Общие Критерии и т.п.). Это поможет обеспечить эффективность плана.
У плана обеспечения безопасности должен быть собственный жизненный цикл. Он должен дополняться, изменяться и детализироваться по мере выполнения проекта. Важно поддерживать его в актуальном состоянии, чтобы на него можно было ссылаться в будущих проектах. Эффективно контролировать работы и решения при реализации крупного и сложного проекта – непростая задача.
Планирование безопасности и деятельность в рамках управления проектом должны контролироваться, чтобы сохранять уверенность в правильности принятых решений в отношении безопасности. Если требуется обеспечить гарантии необходимого уровня защиты, нужно подтвердить, что безопасность учитывалась на каждом этапе жизненного цикла проекта, при выполнении определенных процедур, в процессе разработки, при принятии решений и выполнении иной деятельности в рамках проекта. Документация по проекту должна в точности отражать все аспекты процесса разработки продукта, а также все аспекты его функционирования после внедрения в реальную среду.
Для разработки программного обеспечения может использоваться несколько различных типов моделей, которые используют различные жизненные циклы. В этом разделе описаны основные компоненты, общие для всех этих моделей. В основном, каждая модель выполняет одно и то же, главное различие между ними заключается в том, как именно разбиты на части разработка и эксплуатация системы.
Проект может начинаться просто с хорошей идеи, что потребует импровизации от программистов и инженеров, либо проект может быть изначально тщательно продуман и структурирован, чтобы следовать определенным жизненным циклам, а программисты и инженеры должны следовать этому плану. Первый вариант вначале может показаться более интересным, поскольку команда может пропустить скучные требования, забыть про документацию и произвести продукт в более короткие сроки и в рамках бюджета. Однако команда, которая потратит время на проработку всех сценариев каждого из этапов жизненного цикла, в итоге получит больше удовольствия, т.к. ее продукт будет более качественным, клиенты будут больше доверять ему, а команда заработает больше денег в долгосрочной перспективе, ей не нужно будет хаотично разрабатывать и поддерживать патчи, закрывающие дыры в системе безопасности, пропущенные изначально.
Различные модели, так или иначе, содержат следующие этапы:
- Инициирование проекта
- Функциональное проектирование и планирование
- Техническое задание на разработку системы
- Разработка программного обеспечения
- Установка / внедрение
- Эксплуатация / сопровождение
- Удаление
На этом этапе все пытаются понять, зачем нужен проект и каковы его границы. Проект может быть направлен на реализацию конкретных потребностей конкретного клиента, либо на удовлетворение возникшего на рынке спроса на новый продукт. На этом этапе команда управления проектом анализирует необходимые характеристики и функциональность нового продукта, проводит мозговые штурмы и рассматривает возможные ограничения.
Должно быть разработано концептуальное определение проекта, что обеспечит правильное понимание проекта всеми участниками, и позволит разрабатывать продукт более эффективно и результативно. На этом этапе может проводиться оценка уже имеющихся на рынке продуктов, определение требований, которым имеющиеся продукты не удовлетворяют. Также это может быть прямой запрос от клиента на разработку конкретного продукта.
В любом случае, предназначен ли разрабатываемый продукт для конкретного клиента или для всего рынка, должен быть проведен первоначальный анализ продукта, должно быть сформулировано первоначальное высокоуровневое заявление, в котором будут указаны необходимые для реализации этого проекта ресурсы, прогнозируемые сроки разработки. Также должна быть проведена оценка ожидаемой прибыли от продукта. Эта информация должна быть представлена высшему руководству, которое будет принимать решение, нужно ли переходить к следующему этапу или требуется дополнительная информация.
На этом этапе должны быть определены потребности пользователя и подтверждены основные цели безопасности продукта. Должно быть установлено, будет ли продукт обрабатывать критичные данные, и, если да, должны быть определены уровни критичности данных. Должен быть проведен первоначальный анализ рисков, в рамках которого будут оценены угрозы и уязвимости, оценка соотношения стоимости и преимуществ различных мер безопасности. Необходимо учесть вопросы, относящиеся к безопасности: вопросы целостности, конфиденциальности и доступности. Должны появиться очертания целевого уровня для каждого атрибута безопасности.
После проработки базовой структуры безопасности, которой будет следовать проект, должны быть организованы процессы управления рисками. Управление рисками должно продолжаться в течение всего жизненного цикла проекта. Информацию о рисках можно начинать собирать и анализировать уже на этапе инициирования проекта, она будет детализироваться по мере выполнения этапов функционального проектирования и разработки технического задания.
Одним из наиболее важных аспектов управления рисками, является умение задавать правильные вопросы. Мы уже рассматривали управление рисками в Домене 01, поэтому в этом Домене мы рассмотрим только те риски, которые непосредственно влияют на бизнес в целом. Управление рисками должно продолжаться на этапах разработки и внедрения программного обеспечения.
В процессе разработки программного обеспечения, обычно все фокусируются на создании богатой функциональности и скорейшем выпуске продукта на рынок. Очень часто безопасность не учитывается должным образом или она быстро отходит на второй план, когда начинают «поджимать» сроки. Для обеспечения безопасности продукта недостаточно только того, чтобы программисты знали о методах безопасного программирования, безопасность должна пронизывать весь проект. Разработчики программного обеспечения должны учесть сценарии реализации угроз безопасности и предусмотреть соответствующие решения. Однако в действительности безопасность никогда не рассматривается, как один из важных компонентов процесса разработки. Разработчики не вспоминают про безопасность, пока продукт не купят, а покупатели не столкнуться с успешными атаками, основанными на уязвимостях, вызванных организацией процесса разработки продукта. Но будет уже слишком поздно, чтобы надлежащим образом интегрировать безопасность в проект. Вместо этого разработчики подготовят и выпустят патч.
Первыми шагами в управлении рисками является выявление угроз и уязвимостей, расчет уровня риска. После оценки всех рисков, руководство должно принять решение о приемлемом уровне риска. Конечно, было бы неплохо, чтобы руководство не принимало вообще никаких рисков, чтобы продукт был разработан максимально качественно и всестороне протестирован и защищен «от дурака», однако это слишком сильно увеличило бы сроки разработки продукта и значтельно повысило бы его стоимость. Необходимо пойти на определенные компромиссы и принять соответствующие решения, чтобы обеспечить баланс между рисками и экономической целесообразностью.
Анализ рисков проводится для выявления рисков, связанных с продуктом, и возможных последствий их реализации, с которыми клиент может столкнуться при использовании этого разрабатываемого продукта. Обычно в рамках процесса анализа рисков задается множество вопросов, составляется длинный список уязвимостей и угроз, с указанием вероятности эксплуатации этих уязвимостей и последствий реализации каждой из угроз. Для различных продуктов задаются разные вопросы, они зависят от таких факторов, как цель продукта, ожидания в отношении среды, в которой он будет функционировать, задействованного персонала, а также типа бизнеса компаний, которые будут приобретать и использовать этот продукт. Ниже приводится краткий список вопросов, которые должны быть заданы в процессе анализа рисков программного обеспечения:
- Существует ли возможность переполнения буфера, как ее избежать и протестировать?
- Выполняет ли продукт надлежащую проверку формата / правильности всех данных, вводимых пользователем?
- Какие источники угроз существуют во внешней и внутренней среде? Что это за источники?
- Бизнес какого типа зависит от этого продукта, в бизнесе какого типа может возникнуть ущерб, если продукт не будет работать некоторое время?
- Существуют ли угрозы утечки информации через скрытые каналы, которые должны быть учтены?
- Отказоустойчивость какого типа должен обеспечивать продукт, и когда реализация этого будет инициирована?
- Необходимо ли шифрование? Какого типа? Какая требуется стойкость?
- Нужны ли планы действий на случай экстренных ситуаций?
- Будет другая сторона (например, интернет-провайдер или хостинг-провайдер) сопровождать этот продукт для клиента?
- Необходим ли мобильный код? Зачем? Как он может быть реализован?
- Будет ли этот продукт работать в среде, подключенной к сети Интернет? Какие последствия это может иметь для продукта?
- Нужно ли этому продукту взаимодействовать с уязвимыми системами?
- Уязвим ли этот продукт к DoS-атакам?
- Уязвим ли этот продукт для вирусов?
- Необходимы ли механизмы предупреждения о вторжениях?
- Будут ли у сотрудников клиента или внешних лиц мотивы саботировать этот продукт? Зачем? В чем может выражаться такой саботаж?
- Будут ли у компаний-конкурентов клиента мотивы совершить мошенничество с помощью этого продукта? Зачем? Как может быть реализовано такое мошенничество?
- Какие другие системы будут затронуты, если этот продукт выйдет из строя?
После выявления всех рисков, нужно количественно оценить вероятность и последствия их реализации, чтобы обеспечить выбор и применение надлежащих контрмер в процессе разработки и в самом продукте. Если продукт будет использоваться только для создания текстовых документов, для него потребуется меньший уровень защиты и меньший объем тестирования, по сравнению с продуктом, который будет работать с данными банковских карт.
Большинство шагов прцесса анализа рисков, описанных в Домене 01, могут быть применены и в процессе анализа рисков при разработке продукта. После того, как членами проектной команды выявлены все угрозы, расчитана вероятность их реализации и последствия этого, риски могут быть перечислены в порядке их критичности. Если существуют риски высокого уровня, реализация которых может разорить клиентов, такие риски должен быть указаны в самом верху списка. Риск с низким уровнем критичности следует расположить внизу списка. Таким образом мы получим список, в котором наиболее вероятные и потенциально разрушительные риски идут первыми, а менее вероятные и менее опасные риски следуют за ними.
Эти риски должны быть учтены в архитектуре продукта, также как и функциональность продукта, они требуют выполнения определенных процедур на этапах разработки и сопровождения. Например, архитектура банковского программного обеспечения может требовать установки фермы веб-серверов в демилитаризованной зоне (DMZ), а других компонентов и базы данных – за межсетевым экраном, чтобы обеспечит дополнительный уровень защиты. Архитектура этого продукта будет включать разделение компонентов системы, что потребует разработать методы взаимодействия между различными компонентами. Если продукт будет предоставлять функции безопасной электронной почты, все риски, связанные с работой такого сервиса, должны быть проанализированы и должным образом учтены. Также должны быть продуманы и учтены процедуры внедрения. Каким образом клиент установил этот продукт? Каковы системные требования и требования к среде? Этот продукт должен работать с инфраструктурой открытых ключей (PKI)? Для многих продуктов очень важен уровень поддержки после установки продукта. Потребуется ли от производителя держать клиентов в курсе выявляемых проблем безопасности? Требуется ли ведение журналирования и аудита? Чем больше таких вопросов будет продумано в самом начале, тем меньше проблем возникнет в конце этого процесса.
Важно понимать разницу между анализом рисков проекта и анализом рисков безопасности. Часто эти понятия считают синонимами. Проектная группа может провести анализ рисков только в отношении самого проекта. Это сильно отличается от анализа рисков безопасности, при котором рассматриваются различные угрозы и недостатки. Понимать и выполнять нужно оба этих анализа, но разными способами.
На этом этапе план проекта уже разработан, определена архитектура программного обеспечения и действия, необходимые для обеспечения безопасности и создания контрольных точек безопасности, гарантирующих качество реализованных защитных мер, определены процессы управления конфигурацией и изменениями. К данному моменту определены ресурсы проекта, начато формирование графиков тестирования, разработаны критерии оценки, позволяющие надлежащим образом проверить реализованные защитные меры. Формально оформлены функциональные требования, т.е. ожидания от продукта изложены официально (как правило, описаны в соответствующих документах). Разработан план тестирования, который будет актуализироваться на каждом этапе, что обеспечит надлежащую проверку всех вопросов.
Требования безопасности могут быть получены из нескольких различных источников:
- Функциональные требования к программному обеспечению
- Государственные, международные или локальные (на уровне компании) стандарты и руководящие принципы
- Экспортные ограничения
- Уровень критичности обрабатываемых данных (например, военные стратегические данные или данные обычной коммерческой компании)
- Соответствующая политика безопасности
- Анализ затрат и выгод
- Требуемый уровень защиты для достижения целевого рейтинга уровня гарантий (assurance level rating)
На этом этапе учитывается функциональность, требуемая от продукта и указанная в проектной документации. Если продукт разрабатывается для конкретного заказчика, проектная документация используется в качестве инструмента, помогающего убедить заказчика, что команда разработки понимает его требования к продукту. Проектная документация, как правило, разрабатывается аналитиками, под руководством разработчиков и архитекторов, а затем предоставляется заказчику. Изучая ее, заказчик решает, нужно ли добавить какие-либо функции или что-то убрать, после чего в документацию вносятся соответствующие изменения. После согласования проектной документации с заказчиком, команда разработчиков вместе с заказчиком может конкретизировать все ожидания заказчика по отношению к продукту.
Вопросы в отношении безопасности должны быть заданы при обсуждении высокоуровневых вопросов. Примерами таких вопросов могут быть: Нужна ли аутентификация и авторизация? Нужно ли шифрование? Должен ли продукт взаимодействовать с другими системами? Будет ли осуществляться доступ к продукту напрямую из сети Интернет?
Многие компании пропускают этап функционального проектирования и сразу перепрыгивают на разработку технических требований для продукта. Либо они разрабатывают проектную документацию, но не показывают ее клиенту. Это может привести к значительным задержкам и вызвать необходимость пересмотра проекта, поскольку перед тем, как начать прорабатывать детали, требуется продумать в общих чертах продукт в целом. Если клиент не участвует в этом процессе, вполне вероятно, может получиться так, что он думает, что разработчики создают продукт, который выполняет Х, тогда как команда разработчиков считает, что клиент хочет Y. Много времени можно потратить впустую, разрабатывая продукт, не являющийся тем, что на самом деле хочет клиент. Поэтому необходимо четко определить направление и цели перед тем, как приступать к кодированию. Обычно это является важной функцией команды управления проектом.
Требования к программному обеспечению могут исходить из трех моделей:
- Информационная модель. Указывает, какой тип информации будет обрабатываться, и как она будет обрабатываться.
- Функциональная модель. Определяет задачи и функции, которые должно выполнять приложение.
- Поведенческая модель. Описывает состояния, в которых приложение будет находиться в процессе и после определенных переходов.
Данные информационной, функциональной и поведенческой моделей используются в качестве требований при проектировании программного обеспечения. В результате проектирования мы получаем такие данные, как архитектурный и процедурный проекты, показанные на Рисунке 9-11.
Рисунок 9-11. Информация всех трех моделей учитывается при проектировании
Архитекторы и разработчики берут сведения об организации данных и данные информационной модели, а затем преобразовывают их в структуры данных, которые необходимы для разработки программного обеспечения. Архитектурный проект определяет отношения между крупными структурами и компонентами программного продукта. Процедурный проект преобразует структурные компоненты в описательные процедуры.
Итак, к настоящему моменту выбраны механизмы контроля доступа, определены права доступа и разрешения, выбраны методы и алгоритмы шифрования, вопросы с обработкой критичных данных улажены, идентифицированы необходимые объекты и компоненты, оценены межпроцессные коммуникации, определены механизмы обеспечения целостности, проанализированы все остальные требования безопасности, определены соответствующие решения.
Для следующих этапов должна быть проведена декомпозиция работ (WBS – work breakdown structure), включая этапы разработки и внедрения, учитывая временной график и детализацию работ по тестированию, разработке, подготовке, интеграционному тестированию и поставке продукта.
Техническое задание – это инструмент, применяемый для описания требований пользователей и внутреннего поведения системы. Эти два элемента связываются друг с другом, чтобы показать, как внутреннее поведение реально выполняет требования пользователей.
Этот этап нужен для того, чтобы увидеть больше деталей о продукте и среде, в которую он будет внедрен. Требуемая функциональность была определена на предыдущем этапе. Данный этап учитывает механизмы, необходимые для реализации этой функциональности, и определяет, как будет разрабатываться код продукта, как он будет тестироваться и внедряться.
Необходимо учитывать модульность и возможность повторного использования продукта, или компонентов продукта. Код, который реализует критичные с точки зрения безопасности функции, должен быть максимально простым (чтобы в нем было проще обнаружить ошибки) и достаточно небольшим (чтобы можно было провести его всестороннее тестирование в различных ситуациях). Компоненты могут вызыватья и использоваться различными частями продукта или другими приложениями. Возможность повторного использования компонентов продукта помогает оптимизировать продукт и обеспечить более эффективную и структурированную среду разработки.
Могут возникнуть проблемы переносимости продукта между различными платформами. Эти проблемы должны рассмотрены и решены на ранних этапах разработки продукта. Если продукт должен работать на Windows или Unix-системах, требования к разработке его кода будут существенно отличаться от требований к разработке кода приложения, которое будет устанавливаться только на мэйнфреймах. Также должна быть рассмотрена среда, в которую будет устанавливаться этот продукт. Будет ли этот продукт использоваться отдельными пользователями, либо все пользователи сети получат тот или иной вариант доступа к этому продукту? Будет ли продукт однопользовательским или многопользовательским, имеет большое значение при разработке необходимых спецификаций.
Тестируемость (контролируемость) продукта и его компонентов должна быть продумана на этом раннем этапе, а не на более поздних этапах. Программисты могут внедрить в код перехватчики (hooks, хуки), которые покажут тестировщикам состояние продукта на разных этапах обработки данных. Одно только то, что работа продукта выглядит правильной, и он дает на выходе правильные результаты, не означает отсутствия внутренних ошибок. Именно поэтому для тестирования должен использоваться модульный подход, при тестировании нужно следовать за потоком данных, проверяя каждый шаг их обработки.
На этом этапе должны быть внимательно рассмотрены все вопросы, заданные при инициировании проекта, нужно убедиться, что по каждому учтенному вопросу разработаны соответствующие спецификации. Например, если в продукте будет выполняться аутентификация, на данном этапе будут изложены все детали осуществления этого процесса. Если при использовании продукта возникает большой риск мошенничества, на данном этапе должны быть определены все необходимые контрмеры, должно быть показано, каким образом они должны быть интегрированы в продукт. Если существует риск утечки информации через скрытые каналы, необходимо рассмотреть этот вопрос и разработать соответствующий псевдокод, который покажет, каким образом будет исключен или минимизирован этот риск.
Если продукт разрабатывается для конкретного клиента, спецификации продукта должны быть доведены до сведения этого клиента, чтобы еще раз убедиться, что все понимают продукт одинаково и все движутся в верном направлении. Этот этап предназначен для того, чтобы решить все вопросы, сложности, устранить любую путаницу до начала реальной разработки кода продукта.
Решения, принятые на данном этапе проектирования, являются ключевыми шагами для этапа разработки. Проектирование – это единственный способ перевода требований клиента в программные компоненты, поэтому проектирование программного обеспечения является основой и значительно влияет на качество получаемого в результате продукта и его поддержки. Если продукт изначально не был хорошо спроектирован, последующие этапы станут гораздо более сложными.
Это этап, на котором к работе приступают программисты и разработчики. Обычно они участвуют в работе и до этого момента, указывая направления и давая советы, но на данном этапе на них падает вся основная работа.
На этом этапе программисты должны разрабатывать код, используя методы безопасного программирования, не допускающие возможности компрометации программного обеспечения. Также, программисты должны добавлять в программу код для проверки длины входящих данных, чтобы предотвратить переполнение буфера; проверять код программы на отсутствие скрытых каналов; проверять правильность использования типов данных; убедиться, что пользователи не смогут обойти контрольные точки; проверять синтаксис команд, а также рассчитывать значения контрольных сумм. Следует пройти по различным сценариям атак, чтобы увидеть, каким образом код может быть атакован или несанкционированно изменен. Проведение отладки и анализа кода должно выполняться одинаковыми по уровню профессионализма разработчиками, и все должно быть четко задокументировано.
Большинству программистов не нравится ничего документировать, и они ищут способ избежать этой задачи. Шесть – двенадцать месяцев спустя, никто уже не будет помнить конкретные вопросы, которые были рассмотрены, как они решались, как решались возникшие проблемы, либо программист, который знал все подробности, перейдет на работу к конкуренту или выиграет в лотерею и уедет жить на остров. Это еще один повод переработать и потратить дополнительные человеко-часы. Документация является чрезвычайно важной по различным причинам, она может сэкономить компании немалые деньги в долгосрочной перспективе.
Верификация и проверка
Верификация (Verification) определяет, насколько точно продукт отражает и соответствует техническому заданию. Поскольку в результате разработки может быть получен продукт, который не соответствует первоначальному техническому заданию, необходим этот шаг, гарантирующий отсутствие расхождений.
Проверка (Validation) определяет, обеспечивает ли продукт необходимые решения для соответствующей проблемы реального мира. В крупных проектах, легко потерять из виду основную цель. Проведение проверки гарантирует, что основная цель данного проекта достигнута.Формальное и неформальное тестирование должно начинаться как можно раньше. Тестирование модулей может начаться еще в самом начале разработки. Как только программист разработает компонент или модуль кода, проводится его проверка с несколькими различными значениями входных данных во множестве различных ситуаций. Обычно тестирование модулей продолжается в течение всего процесса разработки. По окончании разработки официальное тестирование продукта должна провести абсолютно другая группа людей, в которую не входит никто из тех, кто разрабатывал продукт или ранее участвовал в тестировании его модулей. Это пример разделения обязанностей. Не должно быть так, что программист разрабатывает, тестирует, а затем и готовит окончательный релиз программного обеспечения. Чем больше глаз увидит код, чем больше рук поработают с программным обеспечением, тем выше вероятность того, что ошибки будут найдены до выпуска продукта.
Разумеется, любые программные перехватчики и закладки, вставленные программистами для тестирования или внесения изменений, должны быть удалены из приложения до того, как оно начнет использоваться в реальной работе, поскольку они могут легко могут стать той дверью, через которую в продукт проникнут злоумышленники.
Не существует универсального рецепта для тестирования безопасности, поскольку программные продукты очень сильно различаются по своей функциональности и задачам безопасности. Важно связать риски безопасности с кодом и тестовыми задачами. Выполняя этот процесс линейно, можно выявлять уязвимость, готовить специальный тестовый сценарий, проводить тестирование, а затем анализировать код на предмет того, насколько хорошо он готов противодействовать реализации этой уязвимости. На этом этапе, должно быть проведено тестирование в близкой реальной среде, которая должна отражать производственную среду, что позволит убедиться в том, что код работает не только в лаборатории.
На данном этапе обычно проводятся атаки, пытающиеся скомпрометировать безопасность продукта, тесты на проникновение. Они направлены на выявление любых пропущенных уязвимостей. Оценивается функциональность, производительность приложения, а также его сопротивляемость попыткам взлома. Все необходимая функциональность продукта должна быть внесена в чек-лист для того, чтобы гарантировать, что в процессе тестирования учтена каждая функция.
Тесты безопасности должны быть проведены в отношение уязвимостей, выявленных ранее в процессе реализации проекта. Должны быть проведены попытки переполнения буфера, проведения атак, взлома программного обеспечения. Должна быть проверена реакция всех интерфейсов на ввод неожиданных данных, воздействие на систему DoS-атак, необычной работы пользователей. Если в программе происходит сбой, она должна надлежащим образом обработать эту ситуацию и вернуться обратно в безопасное состояние. Продукт должен быть проверен в различных средах с различными приложениями, конфигурациями и аппаратными платформами. Продукт может прекрасно работать при установке на чистую Windows 2000 на отдельном компьютере, но он может выдавать неожиданные ошибки при установке на ноутбук, который удаленно подключен к сети и, на котором установлен клиент SMS.
Разделение обязанностей. Различные типы сред (среда разработки, тестирования и эксплуатации) должны быть надлежащим образом разделены, их функциональность и выполняемые в них операции не должны дублироваться. Разработчики не должны иметь доступа к коду, работающему в промышленной среде. Код должен быть протестирован, сохранен в библиотеке, а уже затем установлен в промышленной среде. В процессе проведения тестирования модулей и официальном тестировании, все выявленные проблемы должны направляться команде разработчиков в виде отчетов по проблемам. Разработчики исправляют проблемы, после чего производится повторное тестирование. Этот процесс продолжается, пока все не убедятся, что продукт готов к промышленной эксплуатации. Если продукт разрабатывался для конкретного заказчика, он будет проводить ряд собственных тестов, прежде чем официально примет продукт. После официальной приемки продукта, он выпускается на рынок или передается заказчику.
ПРИМЕЧАНИЕ. Иногда разработчики вносят в продукт строки кода, которые позволяют им, нажав несколько клавиш, получить доступ в приложение в обход любых мер безопасности и средств контроля доступа. Это требуется разработчикам, чтобы они могли быстро получить доступ в приложение или к его коду на этапе разработки. Это называется «черным ходом» или «закладкой для поддержки». Они должны быть полностью удалены перед тем, как продукт начнет реально использоваться.
Этап внедрения фокусируется на функционировании и эксплуатации разработанного программного обеспечения. На этом этапе клиент приобретает разработанный продукт и устанавливает его в своей среде. Затем продукт должен быть настроен для обеспечения требуемого уровня защиты. После этого дожна быть протестирована функциональность и производительность приложения, его средства безопасности должны быть проанализированы и сопоставлены с требованиями, предъявляемыми компанией к безопасности.
Настройки должны быть документированы производителем, документация должна поставляться вместе с продуктом для использования клиентами. Должны быть разработаны руководства для пользователей, а также руководства по эксплуатации и сопровождению продукта. Изучив их, пользователи будут знать, как правильно работать с системой, а технический персонал будет знать, как правильно настроить продукт. Функционирование средств безопасности системы должно контролироваться, чтобы быть уверенным в работе системы в соответствии с тем, что обещано в соглашении об уровне обслуживания.
В период между внедрением и началом эксплуатации системы должна быть проведена ее аккредитация. Этот процесс следует за процессом сертификации, в рамках которого формально или неформально тестируются все функции безопасности, чтобы определить, удовлетворяют ли они требованиям безопасности, предъявляемым компанией. Сертификация представляет собой процесс анализа и оценки средств и функций безопасности. Как правило, эта задача ставится перед независимым внешним экспертом (вопросы сертификации и аккредитации были подробно рассмотрены в Домене 03).
Аккредитация – это официальное принятие системы руководством компании и явное принятие риска. При аккредитации рассматривается вся система, а не только отдельное приложение или усовершенствованная функция, поскольку безопасность – это сервис, который реализуется на разных уровнях системы и может проявляться по-разному. В процессе аккредитации представители руководства и технический персонал должны работать совместно, чтобы убедиться в качестве и уровне защиты, обеспечиваемом приобретенной и внедренной технологией. Технический персонал хорошо понимает вопросы функционирования системы и технические вопросы, а руководящий персонал понимает миссию компании, разбирается в ее финансовых вопросах и вопросах ответственности. Вместе они могут охватить большую область в процессе сертификации и аккредитации.
Если руководство убедилось, что новая система обеспечивает безопасность, понимает и принимает на себя остаточный риск, оно должно выпустить официальное заявление об аккредитации.
Для новой системы должен быть настроен и включен аудит, должен проводиться мониторинг происхоящих в ней событий, должны быть разработаны планы и процедуры восстановления в случае чрезвычайных ситуаций. Указанные планы и процедуры должны быть протестированы, чтобы убедиться, что система в случае сбоя или чрезвычайной ситуации реагирует так, как это было запланировано.
Когда вы дошли до этого этапа, не думайте, что теперь работы по безопасности завершены и все под контролем. Напротив, на этапе эксплуатации безопасность является такой же или даже более важной задачей, по сравнению с предыдущими этапами.
Начальная часть этого этапа включает в себя настройку новой системы и ее правильную интеграцию с сетью и средой. Часто оказывается, что средства безопасности не включены или неправильно (для конкретной среды) настроены. Даже если они были изначально хорошо разработаны, это может оказаться совершенно не важным, если они не используются в действительности или используются ненадлежащим образом.
Операционные гарантии (operational assurance) обеспечиваются путем постоянного проведения тестирования на уязвимости, аудита и мониторинга событий. Именно благодаря деятельности по обеспечению операционных гарантий, администратор узнает о новых уязвимостях или компрометациях безопасности, и может предпринимать нужные действия.
Если в системе или среде происходят существенные изменения, может потребоваться провести новый анализ рисков, а также новую сертификацию и аккредитацию. Такими изменениями может быть добавление новых систем и / или приложений, переезд в другое здание или изменение уровня критичности обрабатываемых данных.
Если пришло время заменять старое программное обеспечение на новое, должны быть выполнены определенные шаги, обеспечивающие безопасность такого перехода. Для этого могут потребоваться различные мероприятия, зависящие от уровня критичности данных, содержащихся в системе. Может потребоваться создать архивную копию информации или резервную копию всей системы вместе с данными, перед тем уничтожить данные выводимой из эксплуатации системы. Если удаляемые данные являются критичными, они должны быть уничтожены специальными методами, такими как многократная перезапись, размагничивание или физическое уничтожение носителя информации. Выбор способа уничтожения критичных данных зависит уровня их критичности, а также от политики компании по уничтожению информации.
Если выводимый из эксплуатации продукт является простым текстовым редактором или антивирусной программой, этот этап может быть простым. Но если этот продукт интегрирован во все компоненты инфраструктуры компании, надлежащее выведение его из эксплуатации без нанесения ущерба производительности работы и безопасности, может оказаться непосильной задачей.
Если нам нужна уверенность в качестве нашего программного обеспечения, мы должны протестировать его. Существуют различные виды тестов, через которые должно пройти программное обеспечение, направленные на поиск различных недостатков, которые могут быть в программе. Ниже приведены некоторые из наиболее часто используемых подходов к тестированию:
- Тестирование модулей (Unit testing). Отдельные компоненты помещаются в контролируемую среду, в которой программисты проверяют структуры данных, логику и граничные условия.
- Интеграционное тестирование (Integration testing). Проверка того, как компоненты работают вместе, и насколько их совместная работа соответствует описанию в проектной документации.
- Приемочное тестирование (Acceptance testing). Проверяет соответствие кода требованиям заказчика.
- Регрессионное тестирование (Regression testing). После внесения изменений в систему, проводится повторное тестирование, направленное на то, чтобы убедиться в функциональности, производительности и защите измененной системы.
- Должны быть введены данные различных типов
- Должны быть введены данные из разных точек в пределах диапазона допустимых данных
- Произвести проверку границ, чтобы выявить возможности для переполнения буфера
- Проконтролировать процедуры проверки данных, чтобы убедиться, что программное обеспечение принимает данные только тех типов, которые ему нужны (т.е. приложение не должно принимать буквы в строке ввода числовой информации и т.п.)
- Ввести данные, выходящие за пределы допустимого диапазона
- Проверить реакцию программы на различные действия пользователя
- Проверить данные до и после обработки, чтобы выявить неправильные изменения
- Проверить отсутствие возможности (уязвимости) повторного использования объекта
- Субъект может получить несанкционированный доступ к остаточным данным в объекте или области памяти
- Проверка входных данных
- Обнаружение и исправление ошибок
- Значения дайджестов сообщений (хэш-функций)
- Транзакционные и денежные счетчики
- Меры контроля повторного представления (resubmission) и самопроверки
- Контроль на выходе
- Обработка ошибок
- Значения для проверки (reconciliation values)
- Процедуры обработки
- Журналы аудита и журналирование
Сбор мусора (garbage collection) – это автоматизированный механизм операционной системы, входящий в состав работ по управлению памятью. Сборщик мусора (garbage collector) находит выделенные ранее блоки памяти, которые больше не используются, и освобождает эти блоки, помечая их как свободные. Также он выполняет сбор рассеянных (scattered) блоков свободной памяти, и объединяет их в более крупные блоки. Это помогает обеспечить более стабильную среду и не тратить драгоценную память. Некоторые языки программирования, такие как Java, автоматически выполняют сбор мусора; другие, например, C, требуют, чтобы разработчик выполнял эту задачу вручную, что оставляет возможности для ошибок. Плохие парни постоянно будут пытаться взломать любое программное обеспечение, поэтому только целостное программирование и тестирование поможет защитить ваш продукт от деятельности злоумышленников.
Важно после завершения проекта собрать всю команду, чтобы обсудить проект в целом и те вещи, которые должны быть улучшены в следующий раз. Если отнестись серьезно к этому этапу и правильно его провести, компания может сэкономить деньги и время в будущих проектах, т.к. команда сможет извлечь уроки, проанализировать свои ошибки, чтобы не повторять их, упорядочить свои процессы. Все это будет способствовать тому, что следующий проект будет выполняться более плавно, с меньшим количеством ошибок и за меньшее время.
Это должно быть упорядоченным событием, кто-то должен вести встречу, кто-то должен делать пометки (вести протокол), но при этом встреча должна проходить в расслабленной атмосфере, каждый член команды должен чувствовать возможность выразить свое мнение и идеи. Эта встреча не должна превратиться в поток взаимных обвинений или жалоб.
Некоторые компании не видят смысла в этом мероприятии и просто заканчивают один проект, чтобы начать следующий, который, скорее всего, столкнется с теми же проблемами, что и предыдущий проект. Выполнение проектов – это процесс обучения, а бизнес считает лучшим продуктом тот продукт, который сделан за минимальное время и с наименьшими затратами. Руководству нужно понимать, как эти два аспекта могут идти рука об руку, и убедиться, что завершающий анализ должен являться частью каждого проекта. Наиболее успешные компании оптимизируют процессы реализации проектов и управление проектами, они оттачивают свое мастерство, превращая работу над проектом в повторяемые процедуры, которые позволяют производить продукт ожидаемого уровня качества. Такие компании постоянно тратят время на то, чтобы посмотреть, каким образом можно усовершенствовать свои процессы.
Этапы жизненного цикла программного обеспечения. Ниже приведены общие этапы разработки программного обеспечения с указанием ключевых задач по безопасности, которые должны выполняться на каждом этапе.В этом Домене описывается жизненный цикл, состоящий из семи этапов. В других моделях могут использоваться другие жизненные циклы, состоящие из иного количества этапов, но, по сути, на них будут решаться те же основные задачи.
- Инициирование проекта
- Определение концепции проекта
- Заявление и первоначальное изучение
- Первичный анализ рисков
- Функциональное проектирование и планирование
- Требования выявлены и определены
- Спецификация системного окружения определена
- Формальный проект разработан
- Техническое задание на разработку системы
- Анализ функционального проекта
- Разбивка функциональности
- Проведение детального планирования
- Проектирование кода
- Разработка программного обеспечения
- Разработка кода программного обеспечения
- Установка / внедрение
- Установка и внедрение продукта
- Тестирование и аудит
- Эксплуатация / сопровождение
- Изменения, исправления, а также незначительные модификации продукта
- Удаление
- Замена продукта новым продуктом
Комментариев нет:
Отправить комментарий