ЧАСТЬ ПЯТАЯ. СУГГЕСТИЯ И БЕЗОПАСНОСТЬ

26 (2).5. Защита информации в защищенной системе

(принципы целостности и изменчивости в решении задачи обеспечения безопасности)

Нелегко с Кащеем сладить: его смерть на конце иглы, та игла в яйце, яйцо в утке. утка в зайце, тот заяц сидит в каменном сундуке, а сундук стоит на высоком дубу, и тот дуб Кащей Бессмертный, как свой глаз, бережет.

Русская народная сказка.

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

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

Только на сколько сертификат уменьшит степень риска, если никто не может этот риск измерить количественно с достаточной степенью точности? Может быть это уменьшение будет на две десятых или пять сотых? Единой шкалы нет и в ближайшее время не предвидится в силу ряда объективных причин.

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

Как известно, в общем виде проблема обеспечения гарантированной защиты любой системы относится к алгоритмически неразрешимым проблемам.

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

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

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

1) авторизация доступа: идентификация пользователей и процессов;

2) целостность программ и данных;

3) доступность информации в соответствии с заявленными правами доступа.

Однако раз нельзя обеспечить гарантированную защиту, тогда зачем постулировать принципы обеспечения компьютерной безопасности? Что они позволяют для практика?

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

Может быть названные принципы фиксируют высоту забора, через который не каждый злоумышленник рискнет перелезть?

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

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

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

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

- проверка по книгам учета, в случае бухгалтерских ревизий;

- просчет контрольных сумм, в случае работы "компьютерных ревизоров" и т.п.

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

На что направлен принцип целостности?

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

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

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

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

Не тупиковый ли это путь? И нужно ли идти этим путем, если главной задачей является безопасность всей системы в целом?

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

"не спит собака дачу охраняет, И я не сплю - собаку стерегу!"

классический пример доведения принципа целостности до абсурда, но 100% гарантии обеспечения сохранности защищаемого объекта все равно нет.

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

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

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

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

В чем может выразиться применение принципа "постоянной изменчивости" в приложении к защите знаний системы.

Исследуем применение этого принципа к защите данных, обрабатываемой средствами вычислительной техники?

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

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

Что же касается светлого будущего для такого принципа организации защиты, как изменчивость, то есть резон прислушаться к словам представителей фантастики, например Роберта Шекли. В двух его произведениях: рассказе "Может, поговорим?" и романе "Хождение Джоэниса" очень образно показано что лучшая защита - это постоянное изменение системы. Особенно характерен первый рассказ, суть которого в следующем.

Земляне в далеком будущем осваивают вселенную, но стараются сделать это так, чтобы избежать войн с местными жителями, поэтому используется испытанная веками схема колонизации, когда посланец за бесценок скупает землю аборигенов. Главное условие - наличие взаимосогласованного и безукоризненного с точки зрения законов аборигенов договора. Схема такая: посланец высаживается на планете; изучает язык; изучает законодательство; покупает недвижимость, оформляя соответствующие договора и начинает вытеснять местную публику. Обратите внимание - классическая схема работы вируса! Но вот на одной из далеких планет происходит осечка. Местный язык изменяется с такой скоростью, что внешний по отношению к системе субъект, человек по имени Джексон, не в состоянии его освоить. "Язык планеты На был подобен реке Гераклита, в которую нельзя войти дважды, ибо там постоянно сменяется вода... Дело само по себе скверное, но еще хуже то, что сторонний наблюдатель вроде Джексона вообще не имел ни малейших надежд на фиксацию или обособление хотя бы одного единственного термина из динамически меняющейся сети терминов, составляющих язык планета На. Влезть в систему - значит непредсказуемо изменить ее, а если вычленить отдельный термин, то его связь с системой нарушится, ч сам термин будет пониматься ошибочно. А посему, согласуясь с фактам постоянного изменения, язык не поддается идентификации и контролю и через неопределенность сопротивляется всем попыткам им овладеть" (Р.Шекли. "Может, поговорим?").

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

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

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

Кстати, подобный путь - это классический путь для такого направления программирования, как функциональное. А.Филд и П.Харрисон отмечают : [101]: "Цель создания программы, корректной и легко понимаемой, часто вступает в конфликт с одновременно выдвигаемым требованиями эффективности ее выполнения, т.е. за короткое время и с использованием возможно меньшего объема памяти. Таким образом идеальным было бы желание получить начальное решение, концентрируясь на ясности и корректности и практически не обращая внимания на его эффективность,а затем преобразовать это решение в эффективную форму, используя манипуляции, гарантирующие сохранение смысла программы". Функциональное программирование готово для этого пути предоставив необходимую теоретическую базу, это [101]:

- трансформационная методология Берсталла и Дарлингтона, со своими сохраняющими смысл правилами порождения новых рекурсивных уравнений;

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

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

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

Работать метапрограмма может по следующему алгоритму:

1) в режиме эмуляции определить адреса вызова основных подпрограмм;

2) перенаправить вызов всех найденных подпрограмм (например, операторы CALL, INT - их легко определить в режиме эмуляции) на резидентную метапрограмму;

3) по зафиксированным вызовам подпрограмм постоянно вести мемо-таблицу, вида:

<адрес><входные значения><результат><частота вызова>;

4) при повторном вызове той или иной подпрограммы готовый результат брать из мемо-таблицы без обращения к соответствующей подпрограмме;

5) периодически осуществлять в мемо-таблице чистку "мусора", чтобы не допустить ее переполнение;

6) наиболее часто вызываемые и связанные друг с другом подпрограммы, согласно мемо-таблицы, размещать в рамках одного сегмента памяти, изъяв их из прикладных задач и операционной системы, внеся туда соответствующие изменения;

7) все сказанное имеет отношение и к подпрограммам самой Метапрограммы.

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

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

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

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

Также критически можно посмотреть и на все остальные принципы.

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

Для чего все сказанное было сказано? Исключительно для того, чтобы уважаемый читатель помнил, там где речь идет о творческом процессе догматические принципы, требования и нормативы никогда не являются панацеей от всех бед. А главным принципом обеспечения "гарантированной" безопасности является принцип "творческого подхода". Что же касается остальных, то эффективность их применения в первую очередь определяется конкретной ситуацией: решаемыми задачами, значимостью информации, работающими людьми и т.п.; где-то имеет смысл считать контрольные суммы, а где-то постоянно держать программное обеспечение "в тонусе перемен"; где-то необходимо установить программно-аппаратные парольные системы, а где-то разрешить доступ всем, но закамуфлировать самое ценное под "пенек в лесу". Как это делается для форматов данных и вычислительных процессов показано в [I].