Защита, продуманная во всём

Защита, продуманная во всём

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

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

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

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

Оценка угроз

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

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

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

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

Консультант в области безопасности и пионер внедрения брандмауэров, директор по безопасности компании Tenable Security Маркус Рейнам уверен, что обычный, количественный анализ рисков — часто лишь пустая трата времени и денег. Такой анализ строится на гипотезах и их оценке, и его главная цель — обосновать интуитивные рекомендации и решения, уже принятые специалистом.

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

С другой стороны, в анализе рисков есть свои сложности, требующие специальных знаний. Брюс Шнейер, директор по технологиям безопасности компании BT и автор книг, считает, что по крайней мере основную часть этой заботы следует передать в руки опытного подрядчика: "Это вещи трудные, сложные и неуловимые. Взаимодействия тут таинственны и совсем не те, о которых вы думали. Самое лучшее, что можно сделать в большинстве случаев, это найти кого-то, кто сведущ в этом деле и сделает для вас всё нужное".

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

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

Создание политики

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

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

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

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

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

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

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

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

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

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

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

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

Добиться сотрудничества пользователей

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

Взять классическую дилемму политик аутентификации пользователей. Сотрудники не любят аутентификацию и будут искать любую возможность, чтобы упростить или обойти этот процесс. Если вы заставляете их помнить сложные пароли, они ответят тем, что будут записывать их на бумажке, создавая вместо одной уязвимости другую. Многие годы специалисты по безопасности пытались "обучить" пользователей — но лишь с тем, чтобы обнаружить, что они (и даже ИТ-персонал) просто не желают сотрудничать.

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

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

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

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

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

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

Внедрение политики

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

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

"Самая большая проблема с политикой в том, что ее делают слишком сложной и не пишут на человеческом языке, — говорит Эмман Хо, вице-президент по ИТ-услугам A&E Television Networks. — Можно сделать политику, как телефонный справочник, и я гарантирую, что никто не будет читать каждую строку".

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

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

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

Источник: PC Week
www.pcweek.ru