Резюме

Разработка программного обеспечения представляет собой искусство компилирования закодированных инструкций таким образом, чтобы преобразовать их в понятную программу для запуска ее на компьютере. Подобно другим видам искусства, основанным на научных теориях, ошибки и упущения могут привести к катастрофическим результатам. Довольно часто обеспечением безопасности начинают заниматься уже после разработки, что приводит к необходимости применения экстраординарных мер. Включив в правила безопасности организации положения о разработке программного обеспечения, можно избежать последующей доработки программного обеспечения собственными силами, вызванной необходимостью обеспечить безопасность программного обеспечения и систем. Даже если организация не занимается разработкой собственного программного обеспечения, некоторые положения этих правил могут оказаться довольно полезными.

1. Этапы разработки программного обеспечения.

• Наличие правил разработки программного обеспечения является гарантией того, что вопросы безопасности будут учтены при проектировании и разработке.
• Правила безопасности, регламентирующие разработку программного обеспечения, должны определять, введение каких обязанностей способствует разработке мер безопасности и корректному использованию программного обеспечения.
• Введение правил разработки программного обеспечения должно базироваться на трех основных рекомендациях, соблюдение которых, также как и соблюдение правил разработки программного обеспечения, будет способствовать разработке безопасного программного обеспечения: требования разработки спецификаций, контроль и квитовка вводимой пользователем информации и контроль предельных значений данных во время пересылки.
• Кроме этих основных правил защиты разработки программного обеспечения существуют еще два правила, которые должны помочь предотвратить проблемы с защитой: исключить "лазейки" или любые другие точки доступа, позволяющие обойти защиту программного обеспечения, которые нарушают безопасность, и исключение особых привилегий для разработчиков.
• Средства управления доступом, встроенные в собственное программное обеспечение, должны соответствовать стандартам на их применение и инструкциям.
• При проектировании и развертывании программного обеспечения собственной разработки в нем должна применяться идентификация и авторизация, которые должны базироваться на встроенных в операционную систему, базу данных или в системы сервисного программного обеспечения алгоритмах.
• Другие правила, затрагивающие процесс разработки идентификации и авторизации, касаются обработки информации, которую содержат пароли.

2. Тестирование и документирование.

• Одной из самых запущенных тем в правилах безопасности, касающихся разработки программного обеспечения, является тема тестирования и документирования. Это очень важные компоненты разработки программного обеспечения, которые затрагивают и вопросы безопасности.
• В правила необходимо включить требования обеспечить защиту личной и патентованной информации о клиентах путем ограничения ее использования при тестировании программного обеспечения.
• Процедура тестирования предназначена для выявления всех возможных проблем и нарушений защиты. Можно записать в правила, что запрещено инсталлировать программное обеспечение, если оно не прошло тестирование и не было утверждено руководством.
• Наличие документации - это не требование обеспечения безопасности. Документация необходима будущим разработчикам, чтобы изучить программные интерфейсы, а также определить, как эти интерфейсы будут функционировать в будущем. Знание интерфейсов максимально раскрывает суть работы системы программного обеспечения, оно необходимо при проведении анализа возможности возникновения в системе проблем и побочных эффектов, которые могут отразиться на информационной безопасности системы.

3. Замена версий и управление конфигурацией.

• Для управления заменой версий необходимо знать конфигурацию системы и ее компонентов. Зная, что должно быть в системе и в сети, администраторы смогут докладывать о нарушениях безопасности и неисправных программах, установленных в системе.
• Одним из ключевых аспектов, касающихся безопасности при замене версий и управлении конфигурацией, является возможность отслеживания изменений. Этими правилами устанавливается требование письменных запросов на внесение в систему изменений, которые затрагивают безопасность.
• Считается неизбежным, что установленное программное обеспечение имеет ошибки. Всегда следует решать такие проблемы немедленно, чтобы предотвратить появление новых проблем. Однако, установка патчей, даже переданных поставщиком, может привести к непредвиденным результатам. Правила, регламентирующие эту сферу, должны вводить процедуры тестирования и требовать установку исправлений, касающихся защиты до установки всего программного обеспечения.
• Независимо от того, насколько часто тестируется программное обеспечение, может возникнуть необходимость выгрузить из работающей системы установленное ранее программное обеспечение или патчи. В правила управления конфигурацией необходимо включить требование как по инсталляции, так и по
  "откату" к предыдущей версии.

4. Сторонняя разработка.

• Некоторые организации не обладают достаточным опытом, необходимым для разработки собственного программного обеспечения. Проекты, разработанные на заказ, представляют собой потенциальную угрозу безопасности и могут создать в организации определенные проблемы.
• Когда организация прибегает к помощи со стороны для разработки программного обеспечения, необходимо позаботиться о целостности этого программного обеспечения. Правила в данной области подобны правилам разработки программного обеспечения. Разница в том, что эти правила касаются сторонних организаций и соглашений, определяющих взаимоотношения с ними.
• В дополнение к обеспечению того, что программное обеспечение функционирует так, как было определено в техническом задании, необходимо, чтобы оно могло работать со средствами управления безопасностью операционной среды, в которой установлено. Если работа программного обеспечения не будет согласована с принятыми инструкциями и алгоритмами, то она может свести на нет требования правил безопасности.
• Когда организация для разработки программного обеспечения нанимает разработчика со стороны, сторонняя организация может оценить достоинства ваших технологий и рассмотреть возможность продажи на открытом рынке пакета программного обеспечения, созданного для организации, оплатившей разработку. Может быть страхи и преувеличены, но сторонняя организация может даже продать конкурентам технологии вашей организации. Поэтому можно разработать правила, предписывающие, чтобы в соглашениях со сторонними организациями содержались условия продажи и распространения.
• Учитывая волну банкротств, коснувшуюся многих компаний, вашей организации захочется выяснить, что произойдет, если компания, которая разработала для организации Web-сайт, будет ликвидирована. В большинстве случаев, когда компании закрываются, получение любых ее активов затруднено. Однако, если организация передала на хранение третьей стороне копии программного обеспечения (включая исходники), то она может либо поддерживать программное обеспечение силами собственных разработчиков, либо эту информацию можно передать другой, третьей стороне на сопровождение.

5. Вопросы интеллектуальной собственности.

• Независимо от того, кто занимается разработкой, конечный результат считается интеллектуальной собственностью организации. Эта собственность включает технологии и другую патентованную информацию о том, каким образом работает организация. Программы должны рассматриваться как ценные активы, принадлежащие организации.
• Организациям, не имеющим правил защиты интеллектуальной собственности, стоило бы выделить ресурсы на разработку таких правил. Поскольку эти правила не должны противоречить соответствующим законам об интеллектуальной собственности, которые могут быть довольно запутанными, лучше пригласить на работу юриста, который специализируется на вопросах интеллектуальной собственности.