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

Определение обязанностей при разработке программного обеспечения

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

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

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

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

Утверждение правил разработки программного обеспечения

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

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

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

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

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

Управление доступом к программному обеспечению

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

В дополнение к уже предложенным рекомендациям по безопасности разработки программного обеспечения существуют еще две формулировки, которые могут помочь предотвратить такие проблемы. Несмотря на их схожесть, они написаны, чтобы предусмотреть все возможные точки доступа, которые дают возможность преодолеть защиту. Формулировки правил выглядят следующим образом.

Нельзя инсталлировать (и даже делать попытки инсталляции) программное обеспечение демонстрационных программ, в котором имеются "лазейки" или любые другие точки доступа, позволяющие обойти защиту программного обеспечения.
Нельзя инсталлировать (и даже делать попытки инсталляции) программное обеспечение, в которое включены особые привилегии для доступа в него разработчиков.

Правила доступа и HIPAA
Тот, кто, работая в сфере здравоохранения, сталкивался с изложенными здесь фактами, обнаружит в них немало противоречий с постановлениями Закона страхования здоровья и ответственности за него (NIPAA— Health Insurance Portability and Account ability Act). Несмотря на то, что HIPAA составлен для обеспечения безопасности и конфиденциальности личных данных, с которыми работают в здравоохранительных органах, в нем также имеется постановление, позволяющее практикующим врачам получать доступ к информации пациентов клиники без выяснения личности запрашивающего или его аутентификации. Назначение этого встроенного нелегального входа или средства быстрого доступа, требуемого HIPAA, заключается в том, чтобы получить доступ к секретным данным в экстремальных ситуациях сотрудникам органов здравоохранения.
Несмотря на то, что HIPAA не разъясняет, как разрабатывать правила и процедуры для экстремальных ситуаций, здравоохранительные организации должны руководствоваться не только HIPAA, но и определять в своих правилах баланс между необходимостью предоставления быстрой медицинской помощи и конфиденциальностью этих личных данных.

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

Все средства привилегированного доступа, а также средства управления, встроенные в собственное программное обеспечение, должны соответствовать стандартам на административные средства управления, как это отмечено в правилах и соответствующих директивах.

Дополнительные соображения по поводу правил

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

Один управляющий универсального магазина был обеспокоен по поводу распространения микрокомпьютеров и нового языка программирования. В течение всего периода разработки правил он убеждал комиссию включить в правила следующую формулировку.

Во всех разработках программного обеспечения необходимо использовать один язык программирования, согласованный на этапе проектирования.

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

Во всех разработках программного обеспечения необходимо рассматривать возможность повторного использования компонентов из других проектов. При разработке программного обеспечения необходимо учитывать возможность повторного использования проекта.

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

Во всех разработках программного обеспечения необходимо использоватъ только полностью доработанные средства разработки и методики.

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

Во всех разработках программного обеспечения должно использоваться единое правило присваивания имен для всех производственных файлов.

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

Рекомендации по разработке аутентификации

Большое количество программного обеспечения предназначено для поддержки производственных функций, доступ к которым должен быть предоставлен только определенным пользователям. Несмотря на то, что такие требования не всегда выдвигаются, большая часть разрабатываемого программного обеспечения должна удовлетворять требованиям идентификации пользователей и установки полномочий пользователей по отношению к этим функциям. Идентификация и авторизация (Identification and Authorization — I&A) являются основными средствами защиты прямого доступа к программе. Это очень важно, поэтому во многих организациях рассматривают возможность включить в правила безопасности дополнительные положения, подкрепляющие правила разработки программного обеспечения, чтобы гарантировать, что I&A будет обязательно включено в разработку.

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

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

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

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