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

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

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

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

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

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

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

Правила безопасности для разработки программного обеспечения должны определять, как правильное распределение обязанностей способствует разработке защиты и развертыванию программного обеспечения. Подобно вопросам ответственности за информацию, которые обсуждались в главе 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 завершения работы.

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

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

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

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

Генерирование тестовых данных

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

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

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

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

Тестирование и принятие в эксплуатацию

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

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

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

Требования к документации

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

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

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

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

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

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

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

Процедуры запросов на замену версий

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

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

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

Управление конфигурацией и настройки защиты

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

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

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

Управление конфигурацией и обновление

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

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

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

Тестирование перед инсталляцией

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

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

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

Процедуры инсталляции

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

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

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

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

Правила, гарантирующие целостность программного обеспечения

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

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

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

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

Ограничение коммерческого распространения

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

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

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

Передача программного обеспечения третьей стороне

Как-то автор работал с производителем систем встроенного телекоммуникационного оборудования. Однажды шеф попросил автора создать набор PROMoв (Programmable Read Only Memory— перепрограммируемое постоянное запоминающее устройство, специальные блоки памяти, на которых данные не могут быть вытерты). Затем он захотел, чтобы автор книги распечатал исходники программ, которые хранились на этих PROMax, и отдал их тем, кто передал бы их тому, кто будет их хранить. Автор поинтересовался, зачем это нужно. Оказывается, был запрос от клиента, который беспокоился о том, какие меры необходимо предпринять в случае ликвидации предприятия.

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

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

Следующая формулировка правил была позаимствована у клиента, который являлся разработчиком Web.

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

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

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

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

Большинство организаций имеют правила защиты интеллектуальной собственности, которые не связаны с правилами информационной безопасности. Эти правила обычно разрабатываются юристами для защиты интеллектуальной собственности независимо от того, для чего эта собственность предназначена. Если в вашей организации существуют такие правила, их не стоит включать в правила безопасности. Лучше внести еще один абзац в правила надежной работы (см. главу 11 "Правила надежной работы"), чтобы информировать пользователя о существовании таких правил.

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

искусство компилирования закодированных инструкций таким

Разработка программного обеспечения представляет собой искусство компилирования закодированных инструкций таким образом, чтобы преобразовать их в понятную программу для запуска ее на компьютере. Подобно другим видам искусства, основанным на научных теориях, ошибки и упущения могут привести к катастрофическим результатам. Довольно часто обеспечением безопасности начинают заниматься уже после разработки, что приводит к необходимости применения экстраординарных мер. Включив в правила безопасности организации положения о разработке программного обеспечения, можно избежать последующей доработки программного обеспечения собственными силами, вызванной необходимостью обеспечить безопасность программного обеспечения и систем. Даже если организация не занимается разработкой собственного программного обеспечения, некоторые положения этих правил могут оказаться довольно полезными.
1. Этапы разработки программного обеспечения. Наличие правил разработки программного обеспечения является гарантией того, что вопросы безопасности будут учтены при проектировании и разработке. Правила безопасности, регламентирующие разработку программного обеспечения, должны определять, введение каких обязанностей способствует разработке мер безопасности и корректному использованию программного обеспечения. Введение правил разработки программного обеспечения должно базироваться на трех основных рекомендациях, соблюдение которых, также как и соблюдение правил разработки программного обеспечения, будет способствовать разработке безопасного программного обеспечения: требования разработки спецификаций, контроль и квитовка вводимой пользователем информации и контроль предельных значений данных во время пересылки. Кроме этих основных правил защиты разработки программного обеспечения существуют еще два правила, которые должны помочь предотвратить проблемы с защитой: исключить "лазейки" или любые другие точки доступа, позволяющие обойти защиту программного обеспечения, которые нарушают безопасность, и исключение особых привилегий для разработчиков. Средства управления доступом, встроенные в собственное программное обеспечение, должны соответствовать стандартам на их применение и инструкциям. При проектировании и развертывании программного обеспечения собственной разработки в нем должна применяться идентификация и авторизация, которые должны базироваться на встроенных в операционную систему, базу данных или в системы сервисного программного обеспечения алгоритмах. Другие правила, затрагивающие процесс разработки идентификации и авторизации, касаются обработки информации, которую содержат пароли. 2. Тестирование и документирование. Одной из самых запущенных тем в правилах безопасности, касающихся разработки программного обеспечения, является тема тестирования и документирования. Это очень важные компоненты разработки программного обеспечения, которые затрагивают и вопросы безопасности. В правила необходимо включить требования обеспечить защиту личной и патентованной информации о клиентах путем ограничения ее использования при тестировании программного обеспечения. Процедура тестирования предназначена для выявления всех возможных проблем и нарушений защиты. Можно записать в правила, что запрещено инсталлировать программное обеспечение, если оно не прошло тестирование и не было утверждено руководством. Наличие документации - это не требование обеспечения безопасности. Документация необходима будущим разработчикам, чтобы изучить программные интерфейсы, а также определить, как эти интерфейсы будут функционировать в будущем. Знание интерфейсов максимально раскрывает суть работы системы программного обеспечения, оно необходимо при проведении анализа возможности возникновения в системе проблем и побочных эффектов, которые могут отразиться на информационной безопасности системы. 3. Замена версий и управление конфигурацией. Для управления заменой версий необходимо знать конфигурацию системы и ее компонентов. Зная, что должно быть в системе и в сети, администраторы смогут докладывать о нарушениях безопасности и неисправных программах, установленных в системе. Одним из ключевых аспектов, касающихся безопасности при замене версий и управлении конфигурацией, является возможность отслеживания изменений. Этими правилами устанавливается требование письменных запросов на внесение в систему изменений, которые затрагивают безопасность. Считается неизбежным, что установленное программное обеспечение имеет ошибки. Всегда следует решать такие проблемы немедленно, чтобы предотвратить появление новых проблем. Однако, установка патчей, даже переданных поставщиком, может привести к непредвиденным результатам. Правила, регламентирующие эту сферу, должны вводить процедуры тестирования и требовать установку исправлений, касающихся защиты до установки всего программного обеспечения. Независимо от того, насколько часто тестируется программное обеспечение, может возникнуть необходимость выгрузить из работающей системы установленное ранее программное обеспечение или патчи. В правила управления конфигурацией необходимо включить требование как по инсталляции, так и по
"откату" к предыдущей версии. 4. Сторонняя разработка. Некоторые организации не обладают достаточным опытом, необходимым для разработки собственного программного обеспечения. Проекты, разработанные на заказ, представляют собой потенциальную угрозу безопасности и могут создать в организации определенные проблемы. Когда организация прибегает к помощи со стороны для разработки программного обеспечения, необходимо позаботиться о целостности этого программного обеспечения. Правила в данной области подобны правилам разработки программного обеспечения. Разница в том, что эти правила касаются сторонних организаций и соглашений, определяющих взаимоотношения с ними. В дополнение к обеспечению того, что программное обеспечение функционирует так, как было определено в техническом задании, необходимо, чтобы оно могло работать со средствами управления безопасностью операционной среды, в которой установлено. Если работа программного обеспечения не будет согласована с принятыми инструкциями и алгоритмами, то она может свести на нет требования правил безопасности. Когда организация для разработки программного обеспечения нанимает разработчика со стороны, сторонняя организация может оценить достоинства ваших технологий и рассмотреть возможность продажи на открытом рынке пакета программного обеспечения, созданного для организации, оплатившей разработку. Может быть страхи и преувеличены, но сторонняя организация может даже продать конкурентам технологии вашей организации. Поэтому можно разработать правила, предписывающие, чтобы в соглашениях со сторонними организациями содержались условия продажи и распространения. Учитывая волну банкротств, коснувшуюся многих компаний, вашей организации захочется выяснить, что произойдет, если компания, которая разработала для организации Web-сайт, будет ликвидирована. В большинстве случаев, когда компании закрываются, получение любых ее активов затруднено. Однако, если организация передала на хранение третьей стороне копии программного обеспечения (включая исходники), то она может либо поддерживать программное обеспечение силами собственных разработчиков, либо эту информацию можно передать другой, третьей стороне на сопровождение. 5. Вопросы интеллектуальной собственности. Независимо от того, кто занимается разработкой, конечный результат считается интеллектуальной собственностью организации. Эта собственность включает технологии и другую патентованную информацию о том, каким образом работает организация. Программы должны рассматриваться как ценные активы, принадлежащие организации. Организациям, не имеющим правил защиты интеллектуальной собственности, стоило бы выделить ресурсы на разработку таких правил. Поскольку эти правила не должны противоречить соответствующим законам об интеллектуальной собственности, которые могут быть довольно запутанными, лучше пригласить на работу юриста, который специализируется на вопросах интеллектуальной собственности.