Безопасность: шаг за шагом

ПЯТЬ КРИТИЧЕСКИХ ЗВЕНЬЕВ В ЦЕПИ ИБ

Если спросить людей, с чем у них непосредственно ассоциируется словосочетание “сентябрь 2001-го”, вам скорее всего ответят “Всемирный торговый центр” или “террористы”. Лишь специалисты могут вспомнить, что через неделю после 11 сентября состоялась общемировая атака червя Nimda, которую сегодня многие расценивают как качественный скачок в усложнении и, как следствие, в росте скорости распространения и жесткости атак на э-бизнес.

По оценкам канадского университета Калгари, Nimda в течение суток инфицировал 2,2 млн. систем, санация которых обошлась в общей сложности в 539 млн. долл.

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

Так, через два года после Nimda по миру прогулялся червь Slammer, нанесший суммарные убытки в миллиарды долларов. А появившийся в 2005-м червь Sober генерировал в разгар своей эпидемии до 70% мирового объема трафика электронной почты. Все это случилось в результате халатности в оценке рисков и определении необходимых мер предупреждения атак, а также из-за всеобщего дефицита бдительности, недостаточности инвестиций в обнаружение инцидентов и реагирование на них.

Не случайно, что пять звеньев в цепи безопасности — оценка риска, предупреждение, обнаружение атак, реагирование на инцидент и создание климата бдительности — были пятью постоянными разделами в большой серии обзоров eWeek Labs под названием “Пять шагов к корпоративной безопасности”, публиковавшихся начиная с ноября 2001 г. Настоящая статья является новой версией этих обзоров, и её цель — ещё раз указать на моменты, которые по-прежнему остаются критическими, и усилить внимание к факторам, появившимся или обострившимся за прошедшее время.

Шаг первый: оценка ситуации

Питер Коффи

Год, прошедший после первой публикации обзора eWeek Labs “Пять шагов к корпоративной безопасности” (ноябре 2001), памятен шквальной реакцией на бухгалтерские махинации, обнаруженные при расследовании банкротства компании Enron в декабре того же 2001-го.

В сентябре 2006-го, в пятую годовщину “атак 9/11”, члены Совета корпоративных партнеров eWeek высказали мнение, что реакция на эти атаки в гораздо большей мере выразилась в новых мерах физической безопасности, чем в усилении внимания к безопасности в сфере ИТ. По словам многих, главными факторами перемен в их ИТ-инфраструктурах оказались широкомасштабная законотворческая реакция на инцидент с Enron, включая закон Сарбейнса — Оксли (SOX) и другие нормативные акты в отношении корпораций, а также публичная озабоченность защитой личных тайн и рисками кражи персональных данных.

Для примера упомянем принятый в Калифорнии акт под номером SB 1386, распространяющийся на любую компанию, если та имеет хотя бы одного клиента в этом штате. Он требует широкого оповещения о любой замеченной утечке незашифрованной персональной информации, под которой понимается фамилия и имя (или инициалы) конкретного человека в комбинации с одним или несколькими из следующих номеров: номер полиса социального страхования, номер или идентификатор водительского удостоверения, номер денежного счёта вместе с соответствующим кодом защиты или паролём.

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

Основной эффект законов SOX, SB 1386 и других аналогичных мер, принятых в других штатах, состоит в том, что невнимание старших менеджеров к корпоративной безопасности сегодня имеет чёткое финансовое выражение: при небрежном отношении к ИТ-безопасности можно потерять немало денег. Если руководство организации не сможет достоверно отчитаться, что и как оно делает, то ему грозит крупный штраф или даже тюремный срок. А акции компании в любом случае упадут в цене.

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

Хотя можно придумать массу формальных инструкций по оценке и смягчению рисков, решить эту задачу в реальной жизни зачастую очень непросто. До атаки “9/11” и случая с Enron ИТ-безопасность была преимущественно внутренним делом организации — операторов, отвечающих за стабильную работу систем, и пользователей, нуждающихся в доступе к приложениям и в уверенности в качестве и защищенности данных. Нынешняя же ситуация требует гораздо большего внимания к внешним ресурсам и внешнему контролю.

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

После атаки “9/11” на роль головного центра в идеологии обеспечения безопасности выдвинулось Управление национальной безопасности США (NSA). Его методологии IAM (NSA Information Assurance Methodology, или Infosec Assessment Methodology) широко освещены в публикациях и являются предметом изучения.

В IAM есть понятие “критичных атрибутов” (impact attributes), которое следует усвоить корпоративным ИТ-специалистам. К базовым критичным атрибутам часто относят конфиденциальность, целостность и доступность. Они очень важны для всего, что достойно называться инфраструктурой безопасности.

Что влияет на безопасность

Для конкретных задач могут играть роль и другие атрибуты методологии IAM, которые надо поддерживать на должном уровне. Компания Security Horizon составила руководство по NSA IAM (выпущено Syngress Publishing в 2004 г. в виде книги под названием Security Assessment). В нем приводятся и такие значимые атрибуты (мы их дополняем определениями, предложенными eWeek Labs), которые перечислены ниже.

• Подотчетность (Accountability). Кто ввёл конкретную информацию, внёс конкретные изменения или предпринял конкретные действия?
• Невозможность отказа от авторства (Nonrepudiation.). Кто произвел те или иные транзакции, и как другие могут проконтролировать их?
• Авторизация. Кто имеет разрешения на выполнение конкретных действий? Кем это разрешено? Какие комбинации разрешений являются недопустимыми?
• Аудит. Какие действия были предприняты при доступе к конкретной информации, и как это можно проконтролировать? Кем? Когда? Откуда?
• Контроль доступа. Каким лицам или группам предоставлены конкретные режимы доступа к конкретным ресурсам и на основе каких политик?

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

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

Шаг второй: предупреждение

Эндрю Гарсиа

Заглядывая внутрь

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

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

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

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

Подтверждением важности этой стратегии может служить комплект обновлений Windows, выпущенный Microsoft в декабре 2006 г. Все три обновления были снабжены следующим описанием уязвимости: “Злоумышленник, успешно воспользовавшийся этой уязвимостью, может приобрести те же права, что и локальный пользователь. При этом пользователям учётных записей с более низким уровнем прав в отношении системы угрожает меньшая опасность, чем пользователям, работающим с правами администратора”.

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

Microsoft это явно признает. Присутствующая в Windows Vista функция User Account Control (UAC) изначально старается ограничивать привилегии, требуя одобрения пользователя или дополнительной аутентификации при выполнении потенциально рискованных для системы задач. Аналогичный вид защиты возможен и в клиентских системах на базе Windows XP и Windows 2000.

Наиболее трудным аспектом принятия философии Least-Privileged User Account (LUA) является адаптация плохо написанных приложений к режиму ограниченных полномочий, однако существуют такие средства, как Microsoft Standard User Analyzer, которые помогают распознавать, в каких случаях приложения будут конфликтовать с LUA. Другие средства помогают администраторам целенаправленно регулировать полномочия, повышая уровень привилегий только там, где это абсолютно необходимо. Одно из таких решений — Privilege Manager компании BeyondTrust.

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

Сегодня установка обновлений является реактивным процессом защиты, поскольку соотношение между уязвимостью, методом её использования и обновлением безопасности необратимо изменилось. Администраторы, видимо, уже привыкли к установившейся стандартной процедуре: Microsoft выпускает обновление, документируя уязвимость; далее на основе этого обновления путем обратного конструирования пишется код использования уязвимости, который уходит в “свободное плавание”, и это оставляет считанные дни для тестирования и развертывания обновления.

Однако в связи с растущими познаниями по части безопасности продуктов Microsoft детали и код использования уязвимости часто оказываются известными ещё до выпуска обновления. Это резко сокращает время для инсталляции обновлений, и администраторам надо усердно совершенствовать процессы их тестирования и развёртывания.

На администраторах ныне также лежит обязанность регулярно следить за списками известных, но неисправленных уязвимостей (например, за информацией сайта research.eeye.com/html/alerts/zeroday/index.html). Они должны оценивать потенциальное воздействие этих уязвимостей на сеть и взвешивать выгоды и затраты по установке временных решений для заделки дыр.

Серьезным поводом для беспокойства остаются потери мобильной информации, так как известна масса примеров утерь и краж ноутбуков, содержавших тысячи, а то и миллионы записей с персональными данными. Очевидный способ борьбы с этой угрозой, позволяющий защитить файлы, папки или целые тома от любопытных глаз, если устройство попадет в чужие руки, — использование продуктов для криптозащиты (например, Pointsec фирмы Check Point Software Technologies или портфель ПО SafeGuard компании Utimaco Safeware).

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

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

Шаг третий: обнаружение вторжений

Камерон Стардевант

Обнаруженный взлом базы данных Калифорнийского университета (Лос-Анджелес) был сам по себе очень неприятным известием. Тот факт, что свыше 800 тыс. записей персональных данных были уязвимыми в течение целых 13 месяцев, показывает, что все успехи в разработке технологий обнаружения бесполезны, если их не реализуют на практике. Это тем более непонятно и досадно, что к тому времени уже имелся целый класс средств обнаружения сетевых аномалий и предотвращения утечек данных, не говоря о новом поколении инструментов обнаружения и предупреждения вторжений на узловые серверы.

В 2001 г. в разделе “Обнаружение” нашей серии обзоров “Пять шагов к корпоративной безопасности” мы писали, что обнаружение сетевых атак — не только наука, но и в равной мере искусство. Это по-прежнему так, однако научная сторона усовершенствовалась, отчасти благодаря законодательным мерам, заставившим организации обратить внимание на то, как хранятся, используются и передаются персональные данные.

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

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

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

Со времени нашего отчета 2001 г. появился целый класс средств предотвращения утечек данных, которые обнаруживают ненормальное (в смысле политики безопасности) их использование, сигнализируя или блокируя незаконное перемещение информации. Vontu, GTB Technologies, Verdasys, Reconnex, Tablus и Vericept — вот лишь несколько компаний, предлагающих средства, которые базируются на принципах выявления и блокировки неразрешенного использования данных, даже если это делается работником организации.

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

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

И вот здесь-то вступает в игру искусство — а возможно, и политика — обнаружения. Чтобы продемонстрировать, что системы обнаружения работают, следует генерировать такой тип отчетов, который будет понятен и топ-менеджерам, не связанным с ИТ.

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

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

Заметим, почти все инструменты безопасности, которые тестирует eWeek Labs, действуют исходя из задаваемой отсчётной базы “хорошего поведения”.

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

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

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

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

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

Шаг четвертый: реагирование

Джим Рапоза

В 2001-м главными факторами устрашения были черви Nimda и Code Red. А сегодня это почти что безобидные приколы по сравнению такими вредоносными программами, как руткиты.

Что же делал Code Red, некогда так пугавший ИТ-администраторов? По существу он портил страницы Web-сайтов. Даже Nimda — для своего времени весьма деструктивный червь — бледнеет на фоне руткитов, главной нынешней угрозы ИТ-администраторов и менеджеров по безопасности.

И если восстановление бизнес-систем после налёта Nimda и Code Red можно было сравнить с очисткой дома, который забросали яйцами хулиганистые соседские дети, то последствия успешной атаки руткита подобны ситуации, когда забравшийся в дом вор украл ваши документы, поставил в комнатах и на телефоне “жучки” и перерыл все ваше добро.

Как должны себя повести ИТ-менеджеры, обнаружившие, что руткит превратил их системы в центр своих развлечений? К сожалению, наилучший выход зачастую сводится к лаконичной рекомендации, которую дали компании в обзоре eWeek Labs “Anatomy of a rootkit hack”: надо полностью всё снести. Иными словами, следует демонтировать систему, в которую имплантировался руткит, и заново построить её с нуля.

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

Когда надо выдергивать штепсель

Для большинства стандартных системных инфекций первый шаг после обнаружения проблемы состоит буквально в том, чтобы “выдернуть штепсель”. Это бесспорно правильно, если затронута лишь одна система, однако как выдернуть штепсель для целой сети? Если рассматриваемая сеть является внутрикорпоративным сегментом, надо выдергивать вилку для всего сегмента. Несмотря на протесты пользователей, также абсолютно необходимо отключить поражённые системы от Интернета.

Что касается ресурсов, которые отключать нельзя, — например, сегментов сети с Web-серверами, серверами баз данных или приложений, ориентированными на внешний мир, то для них может понадобиться мера, предпринятая компанией, упомянутой в статье “Anatomy of a rootkit hack”, а именно умышленная порча собственных DNS-таблиц. Это собьёт с толку контроллеры руткита в плане местонахождения заражённых систем.

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

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

Именно так поступило руководство ИТ-отдела компании из нашего очерка “Anatomy of a rootkit hack”, которое к своему прискорбию обнаружило, что один из ИТ-специалистов использовал имя и пароль администратора домена в системе, уже инфицированной руткитом и клавиатурным шпионом. Этот промах предоставил атакующим ключи практически ко всем закоулкам ИТ-инфраструктуры компании.

А теперь надо себе представить наихудший сценарий развития событий. Раз некие темные личности завладели детальной информацией обо всех ваших важных паролях и механизмах доступа, они могут её использовать в любых целях. Значит, нужно всё менять — пароли, параметры учетных записей пользователей и систем аутентификации — всё, что могло быть отсканировано или доступно из инфицированных систем.

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

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

Но по большому счёту в работе над безопасностью не должно быть передышек. Жертвы инфекции руткитов, как и люди, у которых украли документы, никогда не смогут быть стопроцентно уверены, что всё выправилось. Единственно эффективная ответная реакция — постоянная бдительность.

Шаг пятый: поддержание бдительности

Питер Коффи

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

Оценки расходов на выполнение нормативов SOX могут служить некоторым ориентиром для оценки затрат на безопасность в целом, и уровни этих расходов, как и тенденции их роста, поражают воображение. Опрос членов правления корпораций, осуществленный в 2004 г. RHR International и The Directorship Search Group, показал, что среднегодовые затраты компаний на соблюдение SOX составляют около 16 млн. долл., причём у некоторых организаций эти показатели почти в 20 раз выше. И это вовсе не начальные вложения, а порядок величины текущих расходов.

Даже самую разумную стратегию безопасности на деле можно довести до абсурда. Однако большинство компаний право в том, что им ещё предстоит выйти на уровень “достаточно хорошей” безопасности и пока нечего опасаться перебора. Прошлогодний опрос ControlPath — разработчика автоматизированных решений, управляющих соблюдением нормативов, — показал, что лишь 28% организаций уверены в том, что полностью выполняют требования законов, регулирующих их процессы. А ведь простого выполнения законов или предписаний далеко не достаточно, чтобы сведущие ИТ-специалисты могли спокойно спать. Ещё требуется много работы.

Культура и халатность

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

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

Вот некоторые наглядные примеры новых источников риска.

В обработке данных. Машина “Deep Crack”, построенная в 1998 г. Electronic Frontier Foundation для демонстрации осуществимости жестких атак на алгоритм DES (Data Encryption Standard), тогда стоила 250 000 долл. Сегодня аналогичная по возможностям система, видимо, будет стоить куда меньше десяти тысяч. Для той же цели можно придумать и алгоритм параллельных вычислений в публичной grid-системе Sun Microsystems (www.network.com) с затратой 1 долл. за час процессорного времени.

В соединениях систем. В 2001-м был придуман термин “war driving”, означающий целенаправленный поиск и нелегальное подключение к незащищенным точкам беспроводного доступа. Сегодня карманный детектор размером меньше 20 кв. см и стоимостью менее 60 долл. показывает на своем ЖК-экране сетевой SSID-идентификатор, уровень сигнала, статус криптозащиты и распределение каналов любой точки Wi-Fi-доступа, находящейся в радиусе его действия. С его помощью шпион, припарковав неподалеку свой автомобиль, может в два счета находить беспризорные и незащищенные Wi-Fi-устройства уровня отделов и небольших компаний, чтобы затем входить в их сети.

В хранении данных. USB-устройства флэш-памяти, прежде слишком малоёмкие, чтобы быть опасными, теперь развились до такого уровня, что стоимость 1 Гб памяти упала (вслед за Wi-Fi-детекторами) ниже 60 долл. Их можно запрятать в самые неожиданные предметы, например в шариковую ручку или в складной швейцарский нож.

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

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

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