Тестирование и документирование
Одной из самых запущенных тем в правилах безопасности, касающихся разработки программного обеспечения, является тема тестирования и документирования. Это очень важные компоненты разработки программного обеспечения, которые затрагивают и вопросы безопасности. Программа полного тестирования может помочь обнаружить проблемы до того, как они проявят себя в эксплуатируемом программном продукте. Кроме того, соответствующая документация необходима тем, кто проводит тестирование, чтобы было понятно, что нужно проверять. Поэтому, такие правила должны начинаться с требований по тестированию и документированию. Формулировка может выглядеть следующим образом.
Все собственные разработки должны быть протестированы и задокументированы перед сдачей их в промышленную эксплуатацию.
Важно отметить, что эта формулировка устанавливает требование, но не тип тестирования или формат документации. Данное предложение необходимо включить в правила для всего программного обеспечения и в процедуры.
Генерирование тестовых данных
Много лет назад, находясь в командировке с целью консультации сотрудников одной организации, автор начал работать с группой, отвечающей за тестирование программного обеспечения, разработанного автором. Когда проводившие тестирование специалисты имитировали какие-нибудь проблемы, автор обратил внимание на то, что в используемой тестовой информации присутствуют данные личного характера хорошо известных клиентов этой организации. Увидев несколько знакомых имен, автор поинтересовался, откуда появились эти данные. Группа испытателей призналась, что они для создания тестов извлекли реальные данные из базы данных организации.
Автор был шокирован. Данные содержали информацию личного свойства об известных людях, которая никогда публично не раскрывалась. Кроме того, было очевидно, что группа испытателей читала эти данные. Позже, когда автор стал серьезно заниматься информационной безопасностью и разработкой правил, он стал настаивать на включении в правила положений, касающихся защиты секретных данных от раскрытия во время проведения подобных работ.
Спустя некоторое время появилось множество аргументов, касающихся использования реальных данных для тестирования. Наиболее неотразимый аргумент заключался в том, что это полная имитация тех данных, которые, по идее, должны при реальной работе обрабатывать программы. После того, как автор рассказал свою историю, он спросил о том, каким образом планируется охранять личную или патентованную информацию клиентов. После долгих размышлений большинство согласилось с тем. что какая-то защита необходима. Когда дебаты поутихли, в правила включили следующую формулировку.
Данные, используемые для тестирования, должны создаваться на основе реальных данных, чтобы полностью имитировать реальную ситуацию. Перед использованием данных из них необходимо удалить секретную или патентованную информацию.
Тестирование и принятие в эксплуатацию
Чтобы выявить все возможные недоработки в программном обеспечении и нарушения требований безопасности, необходимо разработать руководство по тестированию. После того, как программное обеспечение прошло этап тестирования, оно должно быть принято в эксплуатацию (подписано руководством) и установлено в реальной системе. Хотя эти процедуры и не относятся к правилам информационной безопасности, определенные детали могут быть отражены в правилах. В контексте информационной безопасности необходимо отслеживать и предотвращать отказы в работе, вызванные тем, что в инсталлированном программном обеспечении имеются ошибки, или оно может неожиданно выполнять непредсказуемые операции.
Когда тестирование успешно завершено, в правилах следует зафиксировать, что необходимо разработать методику проведения инсталляции нового программного обеспечения. Не имеет значения, доработанное ли это программное обеспечение или оно является абсолютно новой разработкой: в методике необходимо предусмотреть оповещение пользователей программного обеспечения о проведении инсталляции, рабочую документацию и способ проведения повторной инсталляции в случае возникновения каких-либо проблем. Все эти вопросы можно выразить в трех коротких формулировках правил.
Принятое после завершения тестирования программное обеспечение должно быть снабжено методикой инсталляции в реальную систему. В методику следует включить процедуры по выгрузке из системы программного обеспечения, если это необходимо.
Инсталляция не должна проводиться без предварительного уведомления пользователей о том, что им необходимо представить отчет об ошибках.
Принятое в эксплуатацию программное обеспечение не должно инсталлироваться без соответствующей рабочей документации.
Требования к документации
Наличие документации – это не требование обеспечения безопасности. Документация необходима для понимания персоналом того, каким образом эксплуатировать систему и как работает сама система. Эта документация необходима будущим разработчикам для изучения программных интерфейсов с целью определить, как эти интерфейсы должны функционировать в будущем. Знание интерфейсов максимально раскрывает суть работы системы программного обеспечения, оно необходимо при проведении анализа возможности возникновения в системе проблем и побочных эффектов, которые могут отразиться на информационной безопасности системы.
В документацию на систему должна входить не только пользовательская документация. В соответствии с требованиями разработчикам следует представить документацию на весь проект, на каждый программный модуль и их интерфейсы. Таким образом можно избежать дублирования в работе, а также задокументировать заложенные в программное обеспечение функции управления, на которые распространяются требования безопасности. Правило, в котором изложены эти рекомендации, может быть таким.
Процесс разработки программного обеспечения должен включать разработку пользовательской и технической документации, в которой описано, как функционирует программное обеспечение, как им управлять, его входные и выходные данные, интерфейсы с системой и другие компоненты, а также используемые средства обеспечения безопасности.