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

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


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

Пример № 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
Поделиться публикацией
Комментарии 24
    +12
    Выжимка: «Безопасность ПО – это не только шифрование данных и каналов связи, но и предотвращение несанкционированного доступа к данным путём разделения доступа, а также с помощью изоляции возможных путей нелегального проникновения в систему».

    Всё верно передал? :)
      0
      Да, короче не скажут, даже те, кто любят сест. тлнта!
      Хоть в этом ничего нового и нет, но вашу выжимку надо распечатать, повесить и повторять как мантру.
      А также показывать всем, кто действительно задумывается о всесторонней безопасности.
        0
        Прошу прощения, ответил ниже. Пока не приспособился.
          +1
          Бывает! Добро пожаловать в наши ряды!
          Сразу видно человека привыкшего много писать. Вы уж попробуйте понять новое поколение — они мы не привыкли много читать, вернее некогда! Нам надо бы желательно покороче да по существу! Уж простите за бестактность!
          0
          Имхо, нет. Главное — это правильно и точно преобразовать «отрицательные» неформальные требования заказчика в «положительные» требования спецификации. Ну и объяснить/доказать ему, почему спецификация описывает именно то, что он хочет.
          0
          Краткость — сестра таланта :-)
          Слова, явно, криптографа.
          Я так коротко не могу. Поэтому я бы перефразировал:
          Безопасность ПО – это не только шифрование данных и каналов связи, не только предотвращение несанкционированного доступа к данным путём разделения доступа, но и:
          — тщательный анализ потребности в защищенности;
          — выбор адекватных средств защиты;
          — тщательное планирование архитектуры;
          — безопасное кодирование;
          — тщательное тестирование.
          Наверно, подумав, можно еще написать многое.

            0
            Безопасность ПО, ИМХО, зависит еще и от грамотного использования инструментов этой самой безопасности :) Админ с головой + ПО «с головой» = безопасность.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Думаю, здесь webzest отвечала на мой комментарий, а не на статью. Я забыл упомянуть в нем важность корректной эксплуатации. Просто последние лет 10 я, в основном, нахожусь на строне разработчика…
            +1
            Дочитал до конца. То, что много написано — это неплохо. Надо учиться читать и вдумываться, а не «скользить по поверхности».
            Все правильно пишете. Но в противовес ко всему сказанному — нельзя доходить до фанатизма, т.к. порой получается обратный эффект)
              0
              Ну так один из основных принципов построения безопасности, это принцип: что защиты должна быть адекватна возможному ущербу.
              Ибо если построить сложную систему защиты на данных которые стоят копейки, то вы только потеряете деньги и усложните себе работу, а если пренебречь защитой на данных которые стоят миллионы то в один день можно остаться без них.

              К коддингу это относиться лишь косвенно, но просто я в совей специфике организационной защиты.
              +2
              Безопасная программа это не столько программа которая делает всё то что должна, сколько программа которая НЕ делает то что не должна. © моё

              Остальное лирика.
                0
                Да, вот с такой выжимкой я полностью согласен, это и есть главная мысль.
                  0
                  Речь, на сколько я понимаю, идет о защите информации(ЗИ), а это всегда комплекс мер, как технических (программных), так и организационных.
                  То, о чем написали Вы — это есть не декларированные возможности (НДВ). Если необходимо, допустим при сертификации ПО, программы проходят испытания по уровню НДВ.
                  Уровней НДВ несколько, в зависимости от уровня конфиденциальности обрабатываемой информации. Под секреты — не ниже 2 (могу ошибаться). Тут есть требования к 2 уровню НДВ.
                  Одной проверки на НДВ не достаточно!
                    0
                    Простите, не осилил ссылку на требования НДВ-2
                    lit.ac/3f
                      0
                      >>> это всегда комплекс мер, как технических (программных), так и организационных.
                      Да, и я затронул только технические. (Почему я и сказал «Безопасная программа это ...»)
                      Я специализируюсь на именно технической части, по этому и судить могу лишь о ней.
                    –1
                    > При этом они очень и очень интеллектуальные люди, даже по меркам программистов

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

                      А вообще в этих примерах я хотел всеми способами показать, что такой подход, который я считаю, скажем так, не совсем удобным при анализе, разделяют люди с интеллектом и образованием очень выше среднего.
                      0
                      Один отставной товарищ в УЦ «Информзащита» очень любит повторять: «Безопасность, это процесс!» (по аналогии с высказыванием профессора мед.института: «Клизма — это процесс, а то о чем вы толкуете — резиновая груша»).

                      А Шнайдер вообще утверждает, что безопасность — это фигня =)
                        0
                        * Шнайер конечно же, Брюс Шнайер
                        +1
                        Букв много. Еле осилил.
                          0
                          Статья ни о чем. Имеет громкое название «Информационная безопасность», а речь идет то ли о безопасности ПО, то ли о ПО для безопасности.
                            +1
                            Что такое безопасность? Безопасность — это состояние.

                            Подставьте «здоровье» вместо «безопасности» и все сразу встанет на свои места!

                            Здоровье — не процесс, процесс — это то, чем занимается здоровая система.
                            Здоровье — не область деятельности, область деятельности (и N+1 процессов) — это охрана и поддержание здоровья.
                            Здоровье — не фигня (no comment).
                            Здоровье — это даже не свойство, а, разве что, «метасвойство», как обобщающее, так и определяющее все другие свойства и поведение системы по отношению к среде.

                            Из цитаты Viega&McGraw я бы оставил только последнее предложение, как наиболее разумное и непротиворечивое, имхо. А то они, приравнивая безопасность к "-ility", уже будто бы готовы были ее к CIA triad приравнять, но одумались.
                            Security is behavioral property of complete system in particular environment.
                              0
                              Некоторое время назад был на научной школе по данной теме, выступал Хорев (надеюсь, многие знают, кто это), так он говорил, что у нас в нормативной части этой области полный бардак: имеющиеся определения в законах и ГОСТах зачастую противоречат друг другу, стандарты зачастую являются переводами западных стандартов, сделанными (переводы) черт знает как и кто во что горазд.

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

                              Самое читаемое