Information Security
14 March 2011

Что такое безопасность

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


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

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

Пример № 2. Серьезная компания, специализирующаяся на защите информации, занимающаяся, в том числе, и разработкой требований безопасности к информационным системам и программным продуктам. Руководитель департамента. Разговорились. На мои слова «безопасная программа» переспрашивает: «программа с функциями безопасности?».

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

А разве безопасность — не функциональность?


Давайте начнем с достаточно традиционного определения безопасности (я здесь предполагаю, что безопасность и защищенность являются синонимами), которое дают Майкл Ховард и Дэвид Лебланк в своей книге [1]:

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


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

Заметим при этом, что никакого указания на функциональность безопасности в таком определении нет. В то же время, многие специалисты очень явно заявляют о том, что безопасность является нефункциональным свойством программного обеспечения. Так Джон Вьега и Гарри МакГраф в своей книге [2] пишут:

Is security a feature that can be added on to an exiting system? Is it static property of software that remains the same no matter what environment the code is placed in? The answer to these questions is emphatic no.

Bolting security onto an existing system is simply a bad idea. Security is not a feature you add to system at any time. Security is like safety, dependability, reliability, or any other ’ility. Each ’ility is a systemwide emergent property that requires advance planning and careful design. Security is behavioral property of complete system in particular environment.


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

Что особенного в безопасности


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

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

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

Да. И нет.

Допустим, мы хотим предотвратить модификацию информации, записанной на жесткий диск, обеспечить таким образом ее целостность. Если никто не должен иметь возможность записи на диск, давайте просто перережем на контроллере диска дорожку, отвечающую за передачу команды записи. Диск не будет записывать вообще. Мы достигли своей цели: никто не имеет возможности записать на диск и целостность информации будет сохранена. Мы удалили функцию — «безопасность» возросла. Многие из читателей и сами могут привести массу подобных примеров.

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

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

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

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

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

Как это влияет на процесс разработки


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

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

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

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

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

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

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

Еще одно соображение


Очевидно, что покупается программное обеспечение из-за его функциональности, из-за того, что оно делает. Именно функциональность интересует клиента в первую очередь. Никто не будет покупать программу, если она не делает чего-то, что облегчает бизнес заказчика, или не помогает хорошо провести время, как это делают, например, различные «игрушки».

Безопасность является вторичной характеристикой. Более того, часто безопасность противоречит функциональности (помните, функции безопасности — это антифункции?). Покупать безопасный, но бесполезный продукт никто, конечно, не будет. Поэтому при разработке программного обеспечения, к которому предъявляются требования безопасности, важной задачей является разработка не просто безопасного, а сбалансированного продукта. И понимание природы безопасности, ее взаимосвязи с функциональностью продукта для успешного решения этой задачи играет не последнюю роль в наборе необходимых разработчику знаний.

Литература


1.Майкл Ховард, Дэвид Лебланк «Защищенный код» Microsoft Press, Русское издание 2005, ISBN 5-7502-0238-0, стр. 2

2.John Viega, Gary McGraw “Building Secure Software. How to Avoid Security Problems the Right Way”, Addison-Wesley 2005, ISBN 0-201-72152-X, p. 13

3.Майерс Г. «Надежность программного обеспечения», Мир 1980

+23
4.1k 30
Comments 24