Угроза информационной безопасности в связи с проблемой 2000 года.
Неясные очертания кризиса, наступление которого ожидается с началом 2000 года, проявляются все отчетливее, и все (будем надеяться, что все) пытаются что-то в связи с этим предпринять. Каким образом готовится к нему ваша организация? Возможно, еще ничего не сделано, или пока сделано очень мало. Если это так - вы не одиноки. Но даже если вы последовательно выполняете план по решению проблемы 2000 года в стремлении избежать сбоев и других серьезных проблем на рубеже веков, все же одному аспекту этой проблемы, а именно - информационной безопасности, вы, скорее всего, не уделяете должного внимания.
Чтобы сберечь ваше время и избавить вас от излишних переживаний, ниже мы приводим некоторые практические советы экспертов по вопросам защиты информации в связи с проблемой 2000 года.
УТЕЧКА МОЗГОВ, И НЕ ТОЛЬКО
Одно из серьезных последствий проблемы 2000 года в том, что ее решение отнимает время и силы, которые отдел ИС мог бы потратить на подготовку и укрепление вашего узла Web для электронной коммерции или на создание адекватной защиты для корпоративной сети Intranet. Чери Якоби, сертифицированный специалист по защите информационных систем (CISSP) из компании Price Waterhause, предлагает несколько примеров того, как проблема 2000 года может негативно отразиться на инициативах в области защиты информации.
"Проблема 2000 года отвлекает на себя значительные ресурсы - интеллект, деньги и силы, - подчеркивает она. - Практически все считают, что сейчас не время для инвестиций в новые технологии, в том числе в системы защиты. Более того, если все лучшие силы брошены на решение проблемы 2000 года, то об остальном просто некому заботиться".
Якоби предостерегает от недо-оценки трудностей соблюдения бaланса между усилиями, направленными на решение проблемы 2000 года, и требованиями информационной безопасности.
Самый неприятный аспект проблемы 2000 года, как считает она, состоит в зависимости от сторонних компаний при ее решении: "Это всегда увеличивает риск".
ПРОБЛЕМА 2000: ИНФОРМАЦИОННАЯ ВОЙНА?
Какую угрозу может представлять испорченный из-за ошибки 2000 года код? Кейт Алан Родес, заместитель по техническим вопросам директора Центрального финансово-контрольного управления США, считает, что такая угроза, безусловно, велика. "Лихорадка в связи с приближением 2000 года сопровождается появлением новых методов нападения, но они, к сожалению, представляют собой всего лишь еще один симптом заболевания под названием "недостаточная защита, отсутствие дисциплины и полное равнодушие к организации защиты, - замечает он. - В обычной ситуации злоумышленник анализирует надежность защиты активов интересующей его организации, регистрирует случаи нарушения защиты и реагирует на них. Благодаря приближению 2000 года ему просто нужно сидеть и ждать, когда паника, охватившая намеченную организацию, позволит ему получить доступ к нужной информации без особого труда. К примеру, осознавая серьезность проблемы 2000 года, вы определили, какие из ваших систем являются критически важными. Как оказалось, внутренних ресурсов для решения этой проблемы у компании недостаточно, поэтому вы предложили руководству передать большую часть операций по обработке и программированию провайдеру услуг. Но многие из провайдеров отказываются брать новых клиентов; у них и так уже хватает работы. Некоторые заключают договоры с новыми клиентами, но передают соответствующую работу за границу. Так, Индия стала сейчас настоящей фабрикой по переработке программного кода. Какова ситуация в вашей фирме? Вы подписываете договор с заслуживающей доверия компанией на определенную сумму. Но эта компания передает работы по вашему контракту независимой компании в другой стране, а та в свою очередь может передать их еще дальше. Мне известны случаи, когда число субподрядчиков доходило до семи. Теперь у вас возникает проблема намного более серьезная, чем ошибка 2000 года, и с приближением срока окончания работ ситуация все больше усложняется".
Какие меры вы можете предпринять, чтобы предотвратить или по крайней мере узнать о подобной "провокации"? Родес дает ряд советов: "Стремление решить проблему 2000 года не должно заставить вас отказаться от требований, которые вы обычно предъявляете к разработкам. Помните, что самое серьезное беспокойство вызывают как раз самые важные для вас системы. Не отдавайте их в чужие руки только потому, что не укладываетесь в сроки".
Родес добавляет, что то, в какой мере удастся предупредить подобную опасность, зависит от того, насколько хорошо вы сможете быть осведомлены, контролировать и проверить ход работ и людей, их выполняющих. "Довольно сложно проконтролировать человека, который работает в другой стране, причем на субподрядчика, - замечает он. - Намного проще следить за работой специалиста, работающего в вашем офисе, с вашими сотрудниками и в вашей среде".
Что касается проверки, то Родес советует прибегать к независимой экспертизе. Другими словами, кто-то должен независимо проверить результаты тестов и код. "Это не дешево и не просто, - подчеркивает он, - но вы открываете для посторонних критически важные системы, и будет лучше проверить их дважды. Кроме того, сейчас же начните подготовку плана действий на случай непредвиденных обстоятельств; он должен не просто перечислять действия при наступлении сбоя конкретной системы, но представлять собой план по обеспечению работоспособности всей компании. Таким образом, даже в самом худшем случае вы сможете спасти свой бизнес".
КОНСУЛЬТАНТЫ
Для многих организаций одним из наиболее важных моментов для успешной реализации программы по решению проблемы 2000 года является вопрос выбора консультантов. Роберт Мартин, менеджер по информационным технологиям из консалтинговой компании Mitre, предлагает некоторые критерии оценки претендентов.
Первое, что вам необходимо, - оценить опыт консультанта. Как давно он работает в области информационных технологий? Сколько времени он занимается решением проблемы 2000 года? С какими предложениями консультант знаком? С какими клиентами он работал?
Кроме того, необходимо оценить ресурсы, которыми располагает консультант. Выясните, сколько человек он может выделить для решения проблемы 2000 года в вашей компании и какие инструментарий и средства тестирования он предлагает. Какие партнерские соглашения связывают консультанта с другими компаниями? При оценке возможностей консалтинговой компании не забудьте узнать ее финансовую историю и перспективы.
Еще один важный критерий - методология. Есть ли у консультанта стандартная методология? Как давно она используется и какова ее "прикладная" область?
ПРОГРАММА РЕШЕНИЯ ПРОБЛЕМЫ 2000 ГОДА
Виктор Бленчард, консультант компании Coopers and Lybrand, очертил программу решения проблемы 2000 года, указав шесть различных этапов, через которые вам необходимо пройти.
- Уведомление. Информируйте высшее руководство компании о риске, которому она подвергается вследствие проблемы 2000 года.
- Оценка. Определите объем и диапазон задач, возникающих в связи с проблемой 2000 года.
- Исследование и планирование. Установите способ представления даты и стандарты тестирования.
- Преобразование и тестирование. Модернизируйте и протестируйте все выбранные системы.
- Реализация. Реализуйте все измененные объекты и файлы в производственных системах.
- Мониторинг. Проверьте, идентифицируйте и исправьте ошибки.
Уведомление. Бленчард подчеркивает, что во время первого этапа знакомства с проблемой руководство должно осознать, помимо необходимости изменений в коде для исправления способа представления и обработки даты, важность поддержания приемлемого контроля за информационной безопасностью в течение всего периода решения проблемы 2000 года. "Защита информации не теряет своего значения, - говорит он. - Если вы решите пригласить консультантов и предоставить все, что им требуется для решения этой проблемы, то тем самым вы можете подвергнуть себя серьезному риску с точки зрения защиты информации. Если организация слишком поздно занялась решением вопросов, связанных с проблемой 2000 года, то она может больше внимания уделять удобству, а не защите".
Кроме того, организации должны поддерживать контроль за существующими системами. К примеру, при решении проблемы 2000 года они должны твердо придерживаться принятой политики и процедур и уделять внимание физической защите центра обработки данных. Вдобавок, они должны по-прежнему осуществлять контроль за доступом к операционной системе, приложениям и данным. Конечно, принятая в компании политика контроля может оказаться недостаточной, поэтому некоторым организациям потребуется принять дополнительные меры и усилить контроль доступа.
Еще один важный вопрос, на который следует ответить во время этапа уведомления: "Кому будут принадлежать права собственности на проект?"
Оценка. По мнению Бленчарда, вопрос защиты информации следует рассматривать во время разработки предварительных планов по подготовке таких ресурсов, как персонал, аппаратное и программное обеспечение и система хранения.
Он объясняет это так: "Если вы выявите вопросы в области обеспечения защиты информации после начала изменений в связи с решением проблемы 2000 года, то их будет сложно снять, поскольку они не были учтены в бюджете. Каждый раз, когда придется тратить средства на решение вопросов защиты, вы будете вынуждены вносить изменения в бюджет, чему руководство вряд ли обрадуется. Поэтому учет вопросов защиты и назначение ответственных за них лиц на этапе планирования приобретает критическое значение".
Кроме того, убедитесь, что все инструментальные средства, которые вы планируете использовать для поиска дефектов во время модернизации систем, не представляют угрозы для безопасности информации.
Исследование и планирование, преобразование и тестирование. Два этих этапа предусматривают создание и проведение тестов на решение проблемы 2000 года. Вдобавок, они ставят два фундаментальных вопроса в области защиты. Первая проблема связана со средой тестирования. Бленчард спрашивает: "Должны ли для тестовой среды поддерживаться те же самые уровень контроля, правила и процедуры доступа, что и для рабочей среды? Если вы намерены копировать все данные и приложения в другую среду, то они должны быть защищены точно так же".
Более того, если тестирование предусматривает перевод системных часов, то оно может оказаться небезопасным с точки зрения защиты информации. К примеру, изменение системного времени способно привести к нарушению целостности системы и журналов защиты. К тому же на этапе преобразования и тестирования вы должны убедиться, что используемые для изменения исходных текстов инструментальные средства соответствуют внутренним стандартам тестирования и контроля.
Вторая проблема защиты касается используемых во время тестирования типов данных и приложений и способов контроля доступа к этим ресурсам. К примеру, как отметил Бленчард, консультанты обычно не создают тестовые данные для целей тестирования, а вместо этого копируют реальную информацию и переносят ее в тестовую среду. "Какие меры контроля и защиты вы предпринимаете для обеспечения безопасности информации, доступ к которой получают консультанты? - задается вопросом Бленчард. - Вполне может оказаться, что это информация о зарплате сотрудников, а может быть - перспективные планы развития компании. Возможно, это будут данные, представляющие особую важность для высшего руководства компании. Вовсе не обязательно, чтобы все консультанты, посещавшие вашу компанию, получали доступ к этой информации".
Кроме того, консультанты - не единственные, чей доступ к информации требуется контролировать, наверняка и кто-то из сотрудников компании работает вместе с ними над проблемой 2000 года. Если члены этой группы получат неограниченные права на копирование информации о зарплате с целью тестирования, то они будут знать все о зарплате своих коллег.
Реализация. Изменение исходных текстов программ может отразиться как на тестовой, так и на производственной среде непредсказуемым и потенциально опасным образом. "Огромное число разнотипных изменений в исходных текстах затронет самые разные аспекты вашей среды, - отмечает Бленчард. - К примеру, вам придется изменить операционную систему и даже программное обеспечение защиты".
Вы должны подготовить план мер на тот случай, если изменения в операционной системе или других важных системах приведут к серьезному сбою системы. Помните, что восстановление систем после подобных сбоев может привести к возникновению вопросов, связанных с контролем доступа.
Мониторинг. Мониторинг системных ресурсов и операций доступа ставит некоторые уникальные вопросы с точки зрения обеспечения безопасности во время процесса решения проблемы 2000 года. Бленчард объясняет: "Естественно, что при мониторинге вы ищете испорченные данные, системные ошибки, изъяны в защите, идентифицируете попытки несанкционированного доступа и проникновения в систему. Но это далеко не все, о чем следует побеспокоиться в процессе решения проблемы 2000 года. К примеру, вы определили отдельные области, где предстоит внести изменения в исходные тексты; мониторинг операций между этими областями и реальной производственной средой приобретает особо важное значение.
Возможно, отслеживать определенные операции окажется чуть сложнее, чем остальные, все зависит от того, как настроены специальные бюджеты, созданные для консультантов и сотрудников, работающих над проблемой 2000 года. Представьте себе, что доступ к вашей системе имеет группа из 20 человек. Обычно членам этой группы присваивают особые идентификаторы. Но кто из этих людей какие действия выполняет - неизвестно. Все, что вы знаете, - это то, что некто, имевший доступ к обычному идентификатору, выполнил действия, приведшие к подаче сигнала тревоги. Поэтому, в определенных случаях, кто конкретно принимал участие в подконтрольных действиях, не так-то просто узнать".
Ричард Пауэр - директор по публикациям в Институте компьютерной защиты. С ним можно связаться по адресу: rpower@mtf.com. Рик Фэрроу - независимый консультант по вопросам безопасности. С ним можно связаться по адресу: rik@spirit.com.