Этапы разработки программного обеспечения
Дополнительные соображения по поводу правил
В принципе, в этом разделе рассматривается достаточное количество вопросов, чтобы гарантировать, что есть все необходимое для разработки безопасного программного обеспечения. Однако, в некоторых организациях считают, что требуется включить в правила дополнительные положения, чтобы можно было использовать правила безопасности для дальнейшего подкрепления усилий по разработке программного обеспечения.
Один управляющий универсального магазина был обеспокоен по поводу распространения микрокомпьютеров и нового языка программирования. В течение всего периода разработки правил он убеждал комиссию включить в правила следующую формулировку.
Во всех разработках программного обеспечения необходимо использовать один язык программирования, согласованный на этапе проектирования.
В другой организации пытались перейти от универсальных компьютеров к серверам и микропроцессорам. Ее руководители были обеспокоены по поводу разработки защищенного программного обеспечения и возможности повторного использования его в проектах. Вместо внесения этой специфики в вопросы безопасности они написали формулировку, касающуюся возможности повторного использования. Формулировка выглядела примерно так.
Во всех разработках программного обеспечения необходимо рассматривать возможность повторного использования компонентов из других проектов. При разработке программного обеспечения необходимо учитывать возможность повторного использования проекта.
Увеличение количества открытых программных продуктов беспокоит некоторых руководителей. Эти руководители тревожатся по поводу того, что такие средства недостаточно доработаны в отношении предотвращения некоторых классических проблем программного обеспечения, наподобие переполнения буфера. Одна организация, обеспокоенная данным вопросом, написала следующую формулировку правил.
Во всех разработках программного обеспечения необходимо использовать только полностью доработанные средства разработки и методики.
И, наконец, одна организация была обеспокоена по поводу того, что установленное программное обеспечение может оказаться в той же области памяти, где располагается область идентификаторов системы, а обнаружить и устранить проблему будет невозможно. После долгого спора между членами комиссии был найден компромисс и составлена следующая формулировка.
Во всех разработках программного обеспечения должно использоваться единое правило присваивания имен для всех производственных файлов.
Проблема с правилами разработки программного обеспечения заключается в том, что их обсуждение перерастает в жаркие дискуссии. Несмотря на то, что в правила можно включить все, что угодно, автор советует тщательно изучать дополнительные предложения, которые, возможно, потом лучше включить в процедуры.
Рекомендации по разработке аутентификации
Большое количество программного обеспечения предназначено для поддержки производственных функций, доступ к которым должен быть предоставлен только определенным пользователям. Несмотря на то, что такие требования не всегда выдвигаются, большая часть разрабатываемого программного обеспечения должна удовлетворять требованиям идентификации пользователей и установки полномочий пользователей по отношению к этим функциям. Идентификация и авторизация (Identification and Authorization – I&A) являются основными средствами защиты прямого доступа к программе. Это очень важно, поэтому во многих организациях рассматривают возможность включить в правила безопасности дополнительные положения, подкрепляющие правила разработки программного обеспечения, чтобы гарантировать, что I&A будет обязательно включено в разработку.
Один руководитель проекта подметил, что, когда он пришел в организацию, во многих проектах, которые разрабатывались в организации, использовалось несколько различных алгоритмов для обеспечения функций I&A. Некоторые из них даже были несовместимы с операционной системой, базой данных или другими алгоритмами, которые использовались в программном обеспечении большинства систем. Исправить такое положение можно, если постараться использовать единый алгоритм, встроенный в систему или базу данных. Помимо того, что становится проще управлять разработкой, в этом алгоритме используются постоянно доступные и продуманные алгоритмы защиты, которые служат для защиты как собственных разработок, так и системы или базы данных. Этот руководитель предложил следующую формулировку правил.
При проектировании и развертывании программного обеспечения собственной разработки в нем должны применяться идентификация и авторизация, которые базируются на встроенных в операционную систему, базу данных или в системы сервисного программного обеспечения алгоритмах.
Другие правила, затрагивающие процесс разработки I&A, сфокусированы на обработке информации, которую содержат пароли. Несмотря на то, что некоторые из этих правил декларируют подходы к разработке I&A, основанные исключительно на здравом смысле, многие уже поняли, что правила могут быть забыты, хотя они являются частью процесса разработки. Поэтому, возможно, будет лучше включить требования к паролям в правила безопасности. В некоторые правила может быть включены следующие формулировки.
Пароли не должны пересылаться электронной почтой в незашифрованном виде.
Пароли, не должны пересылаться открытым текстом по сети в незашифрованном виде.
Пароли нельзя хранить в открытом виде на доступных запоминающих устройствах.
Пароли никогда не должны быть константой, хранящейся внутри программы (жестко закодированной).
Память, используемая для дешифрования и проверки паролей, должна очищаться nocлe завершения работы.