Информационная безопасность » Модель информационных потоков

Контроль построения модели информационных потоков

admin — Mon, 06 Oct 2008 06:24:21 +0000

Убедиться, что всё информационные потоки определены правильно и информация во время всего следования защищена надежно — задача, сравнимая по сложности с самим построением схемы информационных потоков. Если все информационные системы обладают возможностью защиты передаваемых данных, то убедиться в правильности построения схемы защиты для неспециалиста будет затруднительно: для этого необходимо анализировать техническую документацию к системам и конфигурацию работающих систем.
Однако, если одна из систем была спроектирована до 1990 года или в начале 90-х годов, и после этого модификаций ядра или модели безопасности не проводилось — высока вероятность того, что система может воспринимать и выдавать только простые текстовые файлы. В этом случае необходимо дополнительно выяснить, как производится защита этого файла в промежуток времени после выгрузки из одной системы до загрузки в другую. Если никаких дополнительных мероприятий не предусмотрено, то следует задать следующие вопросы.
□ Как защищен этот файл от постороннего прочтения?
□ Как производится проверка того, что данные не были изменены непосредственно перед загрузкой в систему?
□ Что происходит, если выгруженный файл был испорчен или удален?
В зависимости от ответов на них, можно представить картину мероприятий по организации защиты данных при перемещении от одной системы к другой.
В качестве тестового испытания полноты созданной модели, наиболее простого для выполнения со стороны менеджера проекта или руководителя отдела, можно порекомендовать следующую “проверку”. Соберите все штатные (не тестовые) распечатки обрабатываемой системой информации, которые случайно найдутся у вас на столе или в сейфе. Затем исследуйте модель потоков, созданную специалистами по информационной безопасности, и проверьте, все ли виды распечаток, имеющиеся у вас, отражены в ней как ответвления информационных потоков.

Средства создания схем информационных потоков

admin — Mon, 06 Oct 2008 06:23:51 +0000

Теперь несколько слов собственно о создании схем информационных потоков. Здесь затруднительно предложить общую методику по причине специфики информационных систем и в значительной степени бизнес-процессов (и бизнес-потоков) в конкретном предприятии. Вполне возможно использование уже имеющегося механизма составления таких схем — универсального языка моделирования UML (Unified Modeling Language). Это достаточно сложный инструмент, для серьезной работы с ним может потребоваться квалифицированный специалист. Однако для профессионалов, знакомых с объектно-ориентированной концепцией, не составит труда использовать элементы UML при составлении схем.
При использовании UML или любого другого инструмента построения моделей следует помнить, что результирующая, рабочая схема должна описывать не абстрактную “безопасность”, а конкретные ее категории. Соответственно, оперируя параметрами и функциями объектов схемы, необходимо разделять их на отвечающие за конфиденциальность, целостность и т. д. Если вспомнить о необходимости многоуровневого анализа построения защиты, о котором упоминалось в разделе “Защита сетевых процессов обмена данными”этой главы, то становится ясно, что построение качественной схемы — задача отнюдь не тривиальная.

Вопросы построения полной и функциональной схемы информ

admin — Mon, 06 Oct 2008 06:23:24 +0000

При построении схемы информационных потоков следует задуматься о возможности миграции информации по категориям классификации в зависимости от того, на какой стадии информационного потока она находится. Наиболее простой пример таков. Ряд пользователей или систем, каждый сам по себе, обладает частью информации, не представляющей особой важности и находящейся в низкой категории классификации. Та же информация, собранная в одной системе вместе, составляет критически важные данные, подлежащие особой защите, требующие размещения в верхней части таблицы классификации. Обратный пример — часть критически важной по конфиденциальности информации, может быть разглашена на определенном этапе, без ущерба для общего набора информации.
Таким образом, необходимо проводить оценку безопасности информации с точки зрения ее жизненных циклов и других условий. При построении информационного потока следует учитывать возможные ответвления от него, не являющиеся очевидными на первый взгляд. Приведем два примера.
□ Информация следует от системы А через Б к В, на первый взгляд вся цепочка надежно защищена. Однако выясняется, что в системе Б пользователь распечатывает часть данных и передает другому пользователю для анализа. Поскольку данное ответвление находится вне электронного взаимодействия, оно может быть упущено, между тем если информация критична по конфиденциальности, необходимо применение соответствующих дополнительных мер.
□ Информация также следует от системы А через Б к В. На этапе Б, перед тем как перейти к В, информация может быть изменена пользователем на основе других данных (например, на основе информации, поступившей от системы Б2). Как информационный поток защищен от ошибок в системе Б2, если система Б2 — это производственное совещание?
Возможно, примеры несколько надуманы, но наша цель — показать возможность участия неучтенных внешних факторов в потоке.

Защита экспорта файлов

admin — Mon, 06 Oct 2008 06:22:26 +0000

Если обмен данными ведется по самому примитивному варианту (одна система записывает текстовый файл в каталог на сервере, другая считывает его оттуда), возможно использовать дополнительные варианты защиты:
□ средствами операционной системы (при условии, конечно, что сама операционная система поддерживает необходимые механизмы безопасности). Установить доступ на каталог импорта/экспорта только для специальных пользователей, от имени которых работают системы. Снизить до минимума или исключить возможность вмешательства администратора приложения или файлового сервера в работу систем. Возможно, предусмотреть дополнительный сервис, который бы брал на себя контроль за состоянием файла после его создания первой системой и уничтожение его после импорта второй системой. Создание средствами операционной системы или коммуникационными устройствами шифрованного или VLAN-канала между серверами приложения взаимодействующих систем и файловым сервером импорта/экспорта;

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

Защита сетевых процессов обмена данными

admin — Mon, 06 Oct 2008 06:21:18 +0000

Те, кто прочитал раздел “Классификация средств обработки информации: стандарт CCITSE” главы 6, возможно, обратили внимание на классы FTP и FCS, которые составляют для системы основу безопасного обмена данными с другими системами. Это как раз те механизмы обеспечения защиты обмена данными, когда информация не остается незащищенной ни на каком из этапов перемещения между системами. В. основном, работа таких механизмов основана, конечно, на работе криптографических средств.
Если информационное пространство предприятия ориентировано на стек TCP/IP и есть возможность в случае необходимости дорабатывать системы, то в настоящее время с появлением новых механизмов и протоколов защиты обеспечивать безопасность такого пространства становится проще. В главе 22, посвященной сетевым протоколам безопасности, будут затронуты такие средства, как IPSec, ISAKMP, IKE, SSL и пр., которые делают обмен данными защищенным и работают одинаково вне зависимости от того, располагаются ли информационные системы в одной локальной сети или используют в качестве канала связи Интернет.
При этом независимо от того, используется ли в качестве сетевого протокола TCP/IP или другой стек протоколов, следует помнить о классической семиуровневой сетевой модели (OSI — Open System Interconnection). Это означает, что построение механизмов защиты должно также носить многоуровневый характер. Проще пояснить это на примерах. Если нас интересует только защита конфиденциальности и целостности данных в приложениях, то, обычно, этот вопрос можно решить на верхних уровнях (приложения или представления данных). Если встает вопрос об обеспечении надежной доставки — акценты смещаются к транспортному уровню. Если обмен информацией между системами должен скрывать внутреннюю сетевую структуру систем, то речь идет о сетевом уровне. Если необходимо учесть опасность широковещательных сообщений (например, угрозы использования пассивного прослушивания сегмента), следует говорить о канальном уровне. Физический уровень обычно затрагивается, когда речь идет о защите от побочных электромагнитных излучениях или возможности физического внедрения злоумышленника в канал связи. Когда в главе 5 рассматривалась проблема инвентаризации информационных систем, одними из рекомендуемых ко включению в обследование вопросов были источники получения и цели отправления информации. Если это обследование было произведено качественно, то становится легко составить схему информационных потоков (причем не виртуально, а именно нарисовать на бумаге). Возможно, части этой схемы следует показать обследуемым и опрашиваемым пользователям для уточнения. Теперь, имея подобную схему, можно проанализировать тонкие места построенной или планируемой системы защиты данных.
Если обе системы, между которыми происходит обмен данными, поддерживают одни и те же протоколы безопасности, то при соответствующей настройке они смогут обеспечить требуемый уровень безопасности. А если одна из систем представляет собой “черный ящик” без возможности модификаций и не может импортировать/экспортировать никакие другие данные, кроме как в обычном текстовом или другом незащищенном формате?
Здесь необходимо подойти к вопросу оценки необходимости защиты с точки зрения классификации информации, используемой в системе, т. е. определить, к какой категории относится данная информация, какая составляющая для нее наиболее критична: конфиденциальность, целостность, доступность и т. д. Далее необходимо проанализировать, какие альтернативные средства защиты, предоставляемые системой, можно использовать. Возможно, система может рассчитывать некую контрольную сумму экспортируемых/импортируемых данных (аналог электронно-цифровой подписи), либо она ведет расширенный регистрационный журнал загруженных/выгруженных данных и т. п. Необходимо рассмотреть, как имеющиеся средства могут быть использованы второй системой.

Направления защиты процессов обмена информацией

admin — Mon, 06 Oct 2008 06:07:17 +0000

Те, кто изучал или принимал участие в процессе внедрения систем, возможно, сталкивался с ситуацией, когда система с тщательно продуманной моделью безопасности, с устойчивыми механизмами идентификации и аутентификации, с тонко настраиваемым доступом и правами, с хранением данных, защищенных сильными криптографическими средствами, допускает экспорт практически всех значимых данных (например, для некоторого круга пользователей, у которых есть право на подобный экспорт) в виде абсолютно незащищенного набора данных (обычного текстового файла). С точки зрения бизнес-логики в этом нет ничего противоестественного, система должна обмениваться данными с другими системами, которые могут ничего не знать о форматах данных исходной системы, о ее криптографических алгоритмах и тем более о способах обмена ключами шифрования и т. д. С точки зрения самой системы также все в порядке — она надежно защищала данные внутри себя, предоставила право на экспорт только уполномоченному лицу. Однако с точки зрения комплексной безопасности всего информационного пространства возникает проблема — система освободила себя от забот по обеспечению безопасности! Кто теперь берет на себя эти обязанности?
Экспорт данных. В решении этой проблемы существуют два пути: проективный и реактивный. Первый вариант возможен только тогда, когда соответствующие специалисты задумались о проблеме безопасности обмена данных до того, как была приобретена или разработана информационная система, которая должна обмениваться данными с другими системами и в которой отсутствуют механизмы обеспечения защищенного обмена данными. В этом случае есть возможность определить и выставить требование поддержки защищенного обмена данными для каждой устанавливаемой в информационном пространстве системы. При этих условиях исходная информационная система при экспорте (в этом случае некорректно говорить “экспорт” — речь идет об отправке данных в систему-получатель) не перестает обеспечивать защиту данных до тех пор, пока эту роль не возьмет на себя система-получатель. Таким образом, появляется возможность планировать общий уровень безопасности пространства при внедрении новых систем. Но возможно это только в том случае, когда служба информационной безопасности принимает участие в вопросах проектирования и внедрения систем на самом раннем этапе.
Второй вариант распространен, когда уже внедрено определенное число информационных систем, ничего не знающих друг о друге, и встает вопрос об обеспечении безопасности обмена данными между ними. Скорее всего красиво это сделать уже не удастся. Наилучший из возможных способов, когда система имеет встроенные возможности для дополнительной доработки — прикладные программные интерфейсы (англ. Application Programming Interface — API) или интерфейсы, ориентированные специально на обеспечение безопасности (англ. Security Services Provider Interface, в некоторых источниках — Security Support Provider Interface, — SSPI). Но такую возможность должна иметь каждая пара систем, обменивающихся данными. В этом случае с помощью своих разработчиков либо по дополнительному соглашению с поставщиком системы можно провести соответствующую модификацию. В противном случае придется разрабатывать дополнительные процедуры, в которых необходимо будет использовать возможности операционной системы, устройств передачи данных и каналов связи, дополнительные организационные мероприятия.
Это наиболее часто встречающаяся проблема, однако существуют и другие ответвления информационных потоков, которые не очевидны на первый взгляд и о которых не всегда задумываются. Если мы говорим именно об информационной безопасности, а не только о компьютерной, необходимо прослеживать весь путь и жизненный цикл информации от того момента, как она покинула свой источник создания (например, человеческий мозг), до того, как она перестала существовать (например, потеряла актуальность в архиве). Проще всего это сделать, построив соответствующие схемы, тогда можно проследить, где информация оседает в виде распечаток, на дискетах ит. п., в местах, которые не были очевидны с первого взгляда.

Модель информационных потоков

admin — Mon, 06 Oct 2008 06:04:08 +0000

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