Вы — вице-президент по вопросам поставок большой компании, выпускающей компьютеры. Прошлый год был напряженнее других, так как ваша компания решила перейти на аутсорсинговую модель поставок своей продукции, что затронуло все стороны деятельности вашей службы. Этот переход завершен, все идет гладко, и вы наконец-то облегченно вздохнули. Вы на себе ощутили всю тяжесть задачи выбора правильного партнера по перевозке продукции и перехода на новую бизнес-модель.
Сейчас, когда вы и ваша команда осуществили цели, поставленные компанией перед вашим подразделением, наступает время выбраться всем коллективом на природу. Вы запланировали провести ваш отпуск на лыжах в Аспене. Так как утром уже надо уезжать, вы хотите отправить несколько сообщений по электронной почте и убрать на рабочем столе.
Вы закончили уборку стола, отправку почты и готовы уйти. Но когда вы отрываете на мгновение свой взгляд от стола, то замечаете директора по информационным технологиям, быстро идущего по проходу. Кажется, он направляется в ваш офис. Взглянув на него снова, вы видите, что его походка стремительна, а выражение лица — агрессивно. Ну вот. Вам уже приходилось видеть его таким. Это предвещает неприятности.
Да, он действительно шел в ваш офис. Он вошел и закрыл дверь. Вместо того чтобы поблагодарить вас за хорошо сделанную работу, он обрушивается на вас с упреками в отношении выбранной вами компании для перевозки продукции. Очевидно, хакер взломал сеть этой компании. Наступил пик продаж, происходящий в конце каждого года, но не удается отправить ни одной единицы продукции!
Вы замечаете, что лицо директора становится багровым и его всего трясет. Вот-вот он раздавит вас, как жука. Ну как вы могли знать, что системы вашего нового партнера не защищены? Вы доверили ему отправку вашей продукции и считали, что он будет поддерживать безопасность со своей стороны.
Но вы не знаете (и можете никогда не узнать), что хакер пробрался из вашей сети в сеть подрядчика и обрушил все его системы. На его стороне защита в полном порядке. Это ваша сеть поставила его под угрозу. Так как вы уже тонете, то вы, разумеется, не собираетесь копаться во внутренних процедурах. Вместо этого вы показываете пальцем на партнера (и обвиняете во всем его).
Как не оказаться на месте этого партнера? Ведь слишком часто сторонние подрядчики становятся объектом обвинений из-за ошибки основного партнера. Рассмотрим пример…
Забыли о безопасности?
Как и многие другие компании в 90-х годах, фирма S&B Systems искала прогрессивные методы ведения своего бизнеса. И как многие свои современники, фирма ухватилась за идею аутсорсинга.
В принципе аутсорсинг означает оплату услуг другой компании по выполнению части ваших функций. Например, S&B не хотела непосредственно нанимать (и платить им жалованье) 70 секретарей для работы по приему посетителей в различных странах. Вместо этого они передали эту службу подрядчику. Такой секретарь, сидящий в холле, выглядел внешне как служащий S&B Systems, но в действительности он работал в фирме по обеспечению обслуживающим персоналом с названием Job Power. После успешного аутсорсинга с секретарями S&B стала искать, как применить этот подход и для другого персонала.
Однажды руководство компании решило перевести на аутсорсинг все операции по перевозкам. Оно выбрало в качестве партнера фирму Express Time, имевшую многолетний опыт своевременных поставок и солидную репутацию. Для облегчения этого процесса S&B подключила Express Time к своей сети. Переход, казалось, проходил плавно. Вскоре у S&B Systems не было забот о поддержке и обеспечении персоналом отдела перевозок. Их выбор Express Time казался огромной удачей для обеих сторон.
Но высшие руководители S&B Systems и Express Time не знали, что система, соединяющая две компании, не была настроена так, чтобы обеспечивать безопасность. Каждый, кто получал доступ в эту межсетевую систему, мог заходить то в одну компанию, то в другую и собирать, изменять или уничтожать информацию как в S&B Systems, так и в Express Time.
Прошел целый год, пока не заметили, что обе эти сети являются легкими целями. В условиях такого большого риска компаниям просто повезло, что их системы не были обрушены одновременно. Ведь это было невероятно легко сделать!
И действительно, только случайно S&B Systems обнаружила, какой большой риск создает межсетевое соединение.
День 1-й: Осмотр средств обеспечения безопасности
Все началось довольно обычно. Меня наняли как независимого аудитора для тестирования безопасности некоторых систем S&B Systems. Одному из менеджеров технической поддержки S&B, Шелли Бергер, потребовался аудит клиентской сети, так как ее персонал планировал переход на новую версию (апгрейд) операционных систем сети. Планировался также апгрейд брандмауэра, соединяющего их сеть с Express Time. Перед проведением такого перехода Шелли захотела узнать, как хорошо настроены средства безопасности систем.
Шелли поступила очень мудро. Перед тем как проводить общий апгрейд, всегда нужно убедиться, что вы понимаете, в какой среде он будет проводиться. Предварительный аудит является лучшим способом избежать отвратительных мелких сюрпризов в будущем.
Группа Шелли уже закончила аудит брандмауэра и теперь готовилась к его апгрейду. Поэтому основное внимание я обратила на внутренние системы S&B.
Шелли предоставила мне офис для посетителей с видом из окна, собственной системой, схемой сети и толстой стопкой политик и процедур. Она также дала мне краткий список персонала технической поддержки S&B. Обязанности по обеспечению безопасности разделялись между несколькими группами. В двух словах: у них имелись группа обеспечения безопасности, группа системных администраторов и группа обслуживания сети. Группа обеспечения безопасности отвечала за проведение аудитов безопасности, реагирование на взломы и рецензирование кода. Системные администраторы отвечали за установку систем, проведение апгрейда и работу с пользователями. Группа обслуживания сети отвечала за техническую поддержку сети и брандмауэрных соединений. Я знала, что такая структура технической поддержки довольно типична для компании с размерами? как у S&B. Меня особенно впечатлила глубокая продуманность описания ролей и обязанностей.
Шелли было все равно, какой подход я выберу для тестирования систем. Ей просто нужно было узнать, какие существуют риски. Я попросила ее создать мне учетную запись на одном из серверов базы данных и запланировать встречи с группой обеспечения безопасности и системными администраторами на следующий день.
Шелли оставила меня обдумывать сетевую схему и политики, и процедуры. В сущности, это был спокойный аудит, в котором я должна была определить меры по предотвращению проблем с безопасностью, а не реагировать на свершившиеся факты. С другой стороны, это меня не вдохновляло. Я углубилась в изучение политик и процедур, ожидая, когда ко мне придет вдохновение.
Через несколько часов я просмотрела больше их половины. При более глубоком изучении они не казались такими уж восхитительными. Скорее, они подходили под то, что я называю политиками безопасности с высоты 30 000 футов — пространными и тяжеловесными инструкциями, которые должны были произвести впечатление на начальство, но мало полезны людям «в окопах».
День уже заканчивался, а вдохновение все еще не приходило. Обычно меня подстегивает одна только мысль предстоящего обнаружения риска. Но в этот раз меня ничего не подстегивало.
Я знала, что Шелли скоро проводит меня к выходу, поэтому я посвятила последние минуты просмотру сетевой схемы. В компании S&B имелись тонны серверов базы данных, и клиентская сеть была видна сразу. Было также видно, что к сети было подключено три различных клиента. Каждое соединение было защищено своим брандмауэром. Я догадалась, что это были именно те брандмауэры, которые они только что проверили и готовили к апгрейду.
В этот момент появилась Шелли. Я постаралась запомнить мои мысли о сетевой схеме, чтобы обдумать их позднее. Моя голова уже переключилась на работу, которая меня ждала в моей домашней сети. Один из моих жестких дисков «полетел», и мне нужно было его заменить и восстановить информацию. Впереди был не самый приятный вечер, но это нужно было сделать.
День 2-й: Сетевые соединения
Приехав в S&B Systems, я начала снова думать о сетевой схеме и вспомнила, что они только что провели аудит безопасности соединений их клиентской сети. Заехав на стоянку, я пыталась понять, кто же у них делал аудит.
Шелли уже ждала меня в холле. По дороге в мой временный офис я рассказала ей о том, что вчера потратила вторую половину дня на просмотр политик и процедур. Когда мы прибыли в мой офис, я показала ей сетевую схему и заметила: «Я не представляла себе, что несколько различных компаний подключены к вашей сети». Она ответила: «Это так. Мы многое перевели на аутсорсинг в этом году. Мы оставили в компании лишь в главные функции, а остальные отдали подрядчикам». Показывая на сетевую схему, я спросила: «Это те системы, на которых только что проводился аудит?» Она ответила: «Да, и вон те системы тоже». Шелли показала на группу серверов баз данных (обозначенных как DBS1 — DBS 10), которые явно принадлежали интранет S&B и не были похожи на клиентскую сеть (экстранет).
Но Шелли сказала: «Нет, это тоже клиентские системы. Видите ли, мы в прошлом году перевели на аутсорсинг отдел перевозок, а это системы его баз данных». Это все проясняло. DBS должно было обозначать «база данных о перевозках» (database shipping).
Теперь я почувствовала прилив энергии. Это как раз был такой риск, который я искала.
Шелли начала рассказывать мне, что когда S&B переводила на аутсорсинг операции по перевозкам, то она подключила системы DBS к сети Express Time. S&B по-прежнему поддерживала и обновляла базу данных, но Express использовала информацию о перевозках, хранящуюся на этих системах, для поставки изготовленных машин потребителям.
При более пристальном изучении схемы я заметила, что система DBS 10 имела два сетевых соединения. Одно шло к интранет S&B, а другое не имело обозначения. Я предположила, что оно идет к сети Express Time.
В технике Шелли не очень разбиралась. Иначе она бы поняла, что из сказанного ей выходило так, что серверы службы перевозок S&B были подключены к сети Express Time. Таким образом, как только вы открывали сессию на сервере перевозок, вы могли получать доступ к любой системе сети Express Time. И наоборот, открытие сессии на сервере перевозок со стороны Express Time позволяло получать доступ к любой системе сети S&B.
Чтобы пояснить сказанное, представьте себе замок на двери вашего офиса. Пусть вы работаете на 20-этаже здания. На том же этаже располагается компания, которой вы передали по аутсорсингу все ваши операции по закупкам. Разумеется, у вас есть ключ от вашего офиса на 20 этаже. Но, хотя партнер этого не знает, ваш ключ подходит и к его двери. Вы можете пробраться в его офис и просматривать его файлы, пока его там нет. Вы даже можете внести изменения в его финансовые документы, чтобы поправить свои дела за счет аутсорсинга! Таким же образом ключ вашего партнера подходит и к вашей двери. Каждый из его фирмы может пробраться к вам и тоже поменять информацию в ваших файлах по своему усмотрению.
Теперь вы понимаете, почему я чувствовала себя, как будто я только что получила главный выигрыш! Конечно, это все еще было догадкой. Мне нужно было войти в систему и прозондировать ее для подтверждения моей теории.
Поразительные ошибки в защите
Я попросила Шелли подтвердить мои назначенные встречи и убедиться в том, что в этот список включены люди, проводившие аудит систем DBS и других клиентских сетевых соединений. Я также попросила дать мне копии отчетов по проведенным аудитам.
Шелли продолжала говорить, но я уже полностью настроилась на другую тему. Я могла думать только о том, что мне нужно будет искать в системе DBS 10. Я начала думать о подходе к своему аудиту. Проведение аудита самой сети — это превосходно, но из него всего понять невозможно. Например, вы не сможете сказать, каким образом устанавливаются разрешения на доступ к файловой системе или какие скрипты определения ID пользователя (setuid) используются.
При проведении аудитов я использую различные подходы и иногда различные инструменты, Но набор вопросов, на которые я пытаюсь получить ответ, остается постоянным независимо от используемых подходов и инструментов. Если я пропущу хотя бы один важный шаг аудита, то, уходя, оставлю всю систему открытой. Как профессиональный аудитор, я не могу позволить себе такой ошибки.
Я задумала сейчас просто войти в сеть, попытаться получить доступ в DBS 10 и оценить риски. После этого я проведу все остальные обязательные тесты.
Сначала я проверила таблицу паролей сетевой информационной службы (NIS-Network Information Service). S&B использовала файл сетевых паролей с зашифрованными паролями. В таблице было около 100 паролей. Я вынула мою «дорожную» дискету из портфеля и переписала один из моих любимых инструментов для проверки защиты — программу взлома паролей под названием Crack. (Подробнее см. Приложение А, «Люди и продукты, о которых следует знать».) Я немедленно запустила Crack на работу с файлом паролей. Уже через 60 секунд Crack взломал 10 паролей. Один из них был для учетной записи, названной dbadmin, как я предположила — для администрирования базы данных!
Моя догадка, что для всех серверов базы данных используется учетная запись dbadmin, оказалась верной. Теперь я имела доступ ко всем серверам перевозок. Мне даже не надо было регистрироваться с помощью учетной записи, которую создала для меня Шелли.
Сейчас, когда я была в сети, я открыла сессию на DBS 10 и проверила свое предположение. Оно оказалось правильным! DBS 10 был подключен к сети Express Time, и у него не было настроек безопасности вообще — даже патчей. После получения полного доступа к DBS 10 я легко добилась полного контроля (прав суперпользователя) над системой. Я могла, как мне заблагорассудится, перескакивать из одной системы в другую на правах суперпользователя.
Это было ужасно. Я легко бы смогла обрушить эти системы, не оставляя следов моего визита. То же мог сделать каждый имевший доступ в любую из сетей! Для любого плохого парня, желающего украсть информацию, внедрить «Троянского коня», спустить с поводка вирус или установить бомбу с часовым механизмом, S&B была настоящей находкой.
Я продолжала тестировать другие системы сети и обнаружила те же проблемы с защитой, повторяющиеся снова и снова. Уровень безопасности этих систем был типичным для стандартной установки. И к этому изначальному риску системные администраторы добавили еще больший риск, установив доверительную конфигурацию.
Теперь я выявила главные проблемы. Разумеется, в этом месте книги вы почти все из них уже знаете наизусть.
• Никто не писал каких-либо политик и процедур аудита.
• Точно так же никто не писал каких-либо политик и процедур по поддержке клиентских сетей.
• Персонал технической поддержки не получал должного обучения по вопросам безопасности.
• Безопасность сети для клиентских подключений была недостаточной.
• Слишком легко мог быть получен доступ к корневому каталогу.
• Не были установлены патчи, повышающие безопасность.
• Разрешения на доступ к файлам раздавались направо и налево.
• Были включены ненужные сетевые службы.
• И любой восьмилетний ребенок мог бы легко отгадать многие используемые пароли.
В этот момент появилась Шелли, чтобы сопроводить меня на беседу с сотрудниками. Сбор информации придется закончить позднее.
Техническая поддержка при отсутствии обучения и опыта
Сначала Шелли устроила мне встречу с системным администратором Эндрю Клейном. Эндрю только что поступил на работу в качестве сотрудника по технической поддержке систем сети S&B. Он имел опыт по обслуживанию больших компьютеров и начал осваивать UNIX около года назад, так как считал, что мейнфреймы вымирают, как динозавры.
Эндрю впервые пришлось обслуживать распределенную сеть. Он думал, что системы DBS находятся в клиентской сети и защищены брандмауэром. Так как он не представлял в действительности, в чем заключается безопасность систем, то он никогда ее и не контролировал. В конце концов, эти системы были установлены до того, как он принял сеть. Он полагал, что тот, кто устанавливал системы, знал, что он делает.
Я немного поговорила с Эндрю о риске, которому подвергаются как клиентские системы, так и системы S&B. Казалось, он очень удивлен тем, что риск, о котором я говорила, вообще возможен. Я настоятельно ему порекомендовала пройти обучение по вопросам безопасности, если он рассчитывает и дальше работать в качестве сотрудника технической поддержки сети такого типа.
Мое следующее интервью было с администратором группы обеспечения безопасности Джимом Барнсом. Джим принес мне копии отчетов по аудитам безопасности, которые охватывали и систему DBS. Просмотрев их, я увидела, что он проверил некоторые важные системные настройки, но не все из них. В его отчетах было указано на избыточность разрешений доступа к файлам и ненужные сетевые службы, но он никогда не проверял установку патчей, повышающих безопасность, и не пытался взламывать пароли пользователей. И конечно, он не ответил на вопрос, вполне подходящий для телевикторины $64 000 Question: «Почему DBS 10 была подключена к двум сетям без какой-либо защиты брандмауэром?»
Джим выглядел очень смышленым парнем, но он только начинал свою карьеру и не имел опыта в аудите систем. В этом деле он был новичком. Так как в компании бытовал подход к обучению «плыви или тони», то власть предержащие проинструктировали его: «Послушай! Иди и проведи аудит этих систем».
Разумеется, Джим не имел ни малейшего представления, как правильно проводить аудит. Требовать от кого-либо провести аудит группы систем без выработанного подхода или соответствующего обучения глупо и жестоко по отношению к этому сотруднику. Это похоже на то, как если бы ваш механик из автосервиса попросил вас припарковать машину на железнодорожных путях тогда, как вы оба знали бы, что у машины неисправен стартер. «Не беспокойтесь, — говорит он вам. — Если машина не будет заводиться, когда покажется поезд, то позвоните мне». Это не тот уровень риска, с которым бы компании могли мириться в своих сетях.
Этим интервью закончился мой рабочий день, и я отправилась домой. Теперь я была довольна ходом аудита. Я определила множество рисков, которые нужно было устранить перед апгрейдом, для того, чтобы обновленная структура систем была достаточно безопасна для использования.
Дни 3-й и 4-й: Понимает ли проблему руководство?
Я закончила сбор информации для подтверждения моих заключений и написала окончательный вариант отчета по аудиту. Собранные сведения представляли собой большую охапку ярких доказательств, дополняющих мой отчет.
Теперь мне нужно было потратить некоторое время на объяснение рисков и проблем руководству. Риск, который представляют такие виды конфигураций, труден для понимания.
Но когда ситуация действительно окончательно назрела, то вы должны объяснять ее именно руководителям компании. (При этом лица у них становятся бледными.)
Я покинула компанию, оставив после себя почти бесцветные лица руководителей S&B Systems. Теперь мяч был на их половине площадки, и они должны были решать проблемы сами.
Резюме: Аутсорсинговые системы должны быть защищены
Из этого исследования можно сделать два вывода. Во-первых, аутсорсинг функций компании не означает аутсорсинга обязанностей по поддержанию безопасности. На самом деле эти обязанности должны быть уточнены и пересмотрены. Вспомните 7 главу, в которой мы говорили о необходимости определения ролей и обязанностей внутри компании. Ну так вот, аутсорсинг функций компании обычно означает, что вы распространяете роли и обязанности по обеспечению безопасности и на подрядчика. Необходимость обеспечения безопасности не исчезает вместе с выбывшим из ваших платежных ведомостей персоналом. Напротив, аутсорсинг может перевести вас на новый уровень сложности в этом процессе (а то и добавить совершенно новую сеть!).
Второй вывод состоит в том, что вам необходимо тестировать безопасность! В любом случае проблемы безопасности можно обнаружить, только проводя их поиск. Этим в основном занимается аудитор. Альтернативой является ожидание, когда эти проблемы станут сами вас находить. Такая стратегия не является лучшей, если только вам не хочется, чтобы и вашу работу передали на аутсорсинг.
Мы пойдем другой дорогой…
Удача S&B Systems и Express Times заключалась в том, что я обнаружила представляющее риск клиентское соединение. Разумеется, такое подключение не должно было быть сделано.
Вот что S&B следовало сделать, чтобы избежать проблем.
Проводить оценку безопасности
Существует много способов проводить аудит систем. Вы можете проводить аудит сети, чтобы протестировать общеизвестные уязвимые места (те, о которых обычно знают хакеры и постоянно их ищут). Такой вид аудита следует проводить регулярно.
Однако имейте в виду, что его не обязательно должен проводить человек. В Sun мы автоматизировали проведение аудита безопасности при помощи инструмента, названного AutoHack. AutoHack тестирует более 20 000 систем на наличие уязвимых мест и посылает системам сообщения об обнаруженных проблемах. Он отличается в лучшую сторону тем, что в своем сообщении указывает степень серьезности обнаруженной проблемы. При обнаружении в системе серьезной проблемы он сообщает о ней ее владельцу.
Проводить ее правильно
Без правильных процедур ваши люди легко могут пропустить важные шаги при проведении ими аудита. В результате этого у вас могут появиться двойные запоры на дверях при широко открытых окнах. Чтобы этого избежать, обеспечьте наличие подробных процедур для проведения ваших аудитов. И проследите, чтобы эти процедуры выполнялись.
Проводить ее регулярно
В дополнение к процедурам аудита вам нужно разработать политику аудита, в которой должно быть точно указано, когда и при каких обстоятельствах проводить аудиты. Например, можно указать, что аудит нужно проводить каждые шесть месяцев и каждый раз при переводе новых систем в онлайновый режим. Если ваша сеть имеет очень динамичную конфигурацию (например, является средой разработки программного обеспечения), то вам лучше проводить аудит безопасности каждые две недели независимо от того, кто на вас работает.
Главное заключается в том, что вам нужно быть последовательным. Не позволяйте вашим сотрудникам из группы обеспечения безопасности отказываться от проведения аудита в этом месяце из-за того, что должны быть представлены квартальные отчеты, а они запаздывают со своими разделами. Добейтесь того, чтобы даты и условия проведения аудитов были «высечены на камне».
Решать обнаруженные вами проблемы
Вы не поверите тому количеству случаев, когда я «обнаруживала» проблемы, о которых раньше уже докладывалось (и не раз), но которые никогда не решались. Конечно, их решение назначалось на какой-либо день, но каким-то образом этот день никогда не наступал.
Риск сам по себе со временем не исчезнет. Напротив, он использует такую передышку для того, чтобы вырасти в размерах и сделаться более сложным. Если вы откладываете решение проблемы безопасности потому, что у вас нет средств в этом квартале, то вы будете платить гораздо больше в более поздний срок. Представьте себе затраты S&B Systems в том случае, если хакер нащупает обнаруженное мной незащищенное место и перекроет сбыт всей их продукции.
Не использовать ПОДХОД «ПЛЫВИ ИЛИ ТОНИ»
Подход «плыви или тони» к обучению вопросам безопасности никогда не приносил плодов. Ожидать того, что ваши новые администраторы средств безопасности дойдут до всего сами, — это жестоко и неэффективно.
Будет мало пользы от назначения нового администратора средств безопасности, если вы не дадите ему обучения, необходимого для работы. В идеале вы, конечно, можете нанять опытного специалиста. Но это нелегко сделать. Профессионалы в области обеспечения безопасности пользуются большим спросом. Как сообщает ZDNet, недостаток в персонале данной профессии будет составлять по прогнозу на ближайшие годы 50 000-75 000 человек. Их оклады уже возросли за 2001 год на 50 процентов — верный признак надвигающейся их нехватки.
Чувствуя отчаяние работодателей, некоторые предприимчивые хакеры пытаются выставлять себя на рынок рабочей силы как экспертов по обеспечению безопасности, заявляя, что их криминальное прошлое свидетельствует об их опытности. Министерство обороны США имеет давнее знакомство с хакерами, стоившее ему 25 миллиардов долларов, потерянных из-за 22 000 атак только в 1999 году. Сегодня Министерство обороны открыто принимает на работу хакеров-«белых шляп». Хотя его подход к «черным шляпам» менее открыт, есть сообщения о том, что им делались предложения гражданам других государств (таким, как русский хакер Верс).
При безнадежной нехватке действительно квалифицированных профессионалов, которая сопровождается стремлением хакеров замаскироваться под экспертов в области безопасности, у вас остается лишь один выбор — самим вырастить собственного эксперта.
Контрольный список
Используйте этот список для определения того, подвергается ли ваша компания риску из-за применяемого ей аутсорсинга и/или состояния процедур проведения аудита. Можете ли вы поставить «Да» против каждого его пункта?
Аутсорсинг
— Проводятся ли аудиты клиентских подключений (экстранет) на регулярной основе?
— Существует ли официально оформленная архитектура подключения клиентов (экстранет) к вашей сети?
— Существует ли официальная политика, четко определяющая, когда, почему и каким образом должны разрешаться подключения экстранет?
— Требуется ли разрешение руководства на перевод экстранет в онлайновый режим?
— Требуется ли проведение аудита безопасности перед тем, как перевести экстранет в онлайновый режим?
Процедуры проведения аудита
— Имеется ли в вашей компании официальная политика проведения аудита?
— Имеются ли в вашей компании процедуры проведения аудита для тестирования безопасности в письменной форме?
— Находится ли в рабочем состоянии программное обеспечение для проведения аудита, установленное на всех платформах?
— Обеспечивается ли необходимое финансирование приобретения необходимых инструментов проведения аудита?
— Поддерживает ли руководство проведение аудита безопасности, обеспечивая правильную подготовку аудиторов?
Заключительные слова
Аутсорсинг быстро становится стратегией корпораций нашего десятилетия. Если ваша компания не воспользовалась аутсорсингом для каких-либо своих нужд, то велика вероятность, что она скоро это сделает.
Перед тем как проводить какую-либо аутсорсинговую реорганизацию, включающую в себя предоставление совместного доступа к вашей компьютерной сети, убедитесь в том, что вы владеете всеми фактами. Какой тип подключения будет нужен? Как будет защищено такое подключение? Как обеспечивается безопасность стороны подрядчика? Повлияют ли доступ с его стороны и имеющиеся у него процедуры на безопасность вашей информации? Получите ответы, пока подключение не создано.
В то же время всегда помните, что проблемы безопасности будут время от времени возникать. Это — природное явление. Для лучшей защиты вашей драгоценной информации в этих неизбежных испытаниях положитесь на тщательные, планируемые регулярно аудиты безопасности, проводимые хорошо обученными профессионалами.
Не впадайте в благодушное состояние, полагаясь на репутацию вашего партнера по аутсорсингу. Уже скомпрометированы некоторые из величайших и ярчайших компаний. Одной из причин столь длительного выздоровления от вируса Code Red является то, что сайт windowsupdate.Microsoft.com сам был заражен им. Поэтому многие заразились вирусом Code Red, когда «скачивали» те самые обновления для программ, которые должны были защитить их от будущих атак.
Разумеется, вирус является зверем, значительно отличающимся от чрезмерно доверяющего сервера. Но я настаиваю на том, что вы должны отвечать за все, что происходит в вашей сети. Нет разницы в том, будет ли эта тварь в диске с демоверсией продукта гиганта индустрии программного обеспечения или в облегченном доступе из компании, которой вы доверили ваши операции по перевозкам. Целостность вашей информации зависит от вашей неусыпной бдительности.