У астрофизиков и у нас, сотрудников служб информационной безопасности (ИБ) предприятий и организаций, схожие проблемы: области наших наблюдений с неумолимой стремительностью расширяются, и повернуть время вспять невозможно. Нас бомбардируют все более ужесточающимися требованиями к соблюдению законодательства и конфиденциальности персональных данных, в то время как наносимые взломщиками разрушения становятся все более ощутимыми. Среди наших противников - все меньше "любителей" и все больше организованного криминалитета; пока принимают все новые законы о неразглашении и аудите, затраты на восстановление скомпрометированных систем увеличиваются, а реактивная модель ИТ-безопасности демонстрирует свою вопиющую неэффективность. Словом, куда ни глянь, повсюду ставки растут, и нас, определенно, ждут большие перемены.
Не нужно быть семи пядей во лбу, чтобы понять важность правильной расстановки приоритетов при выработке стратегии безопасности ИТ в условиях ограниченного финансирования. Определите, какие системы и наборы данных наиболее важны для вашей организации. Оцените степень каждого риска, которому они могут подвергнуться. Решите, какие именно риски вы готовы принять на себя, а какие - переложить на стороннюю организацию. Выработайте план действий и в соответствии с ним распределите имеющиеся у вас ресурсы.
Если бы все было так просто! В обеспечении безопасности нет и не может быть одного универсального подхода, процесса или механизма. Тем не менее, проанализировав успехи и ошибки, переговорив с экспертами индустрии безопасности, мы выявили одну важную тенденцию - предприятия и организации перестают видеть картину безопасности ИТ в черно-белом цвете, предпочитая прагматичный взгляд, взвешивая риски и действуя на основе их оценки.
Нам нужно добиваться, чтобы подход, основанный на управлении рисками, реализовывался всеми бизнес-процессами, тщательнее отбирать проекты, не ограничиваться "противопожарными мерами" и грамотно инвестировать в технологии. Для некоторых специалистов по ИТ вышеперечисленное означает полную трансформацию бизнеса. Перед тем как пойти на этот шаг, проанализируйте, насколько критически важны для вас все эти факторы.
Новое мышление
Отовсюду мы только и слышим: "соблюдение законодательства" и "управление рисками". И то, и другое, похоже, стало главным критерием в позиционировании продуктов ИБ. Остается спорным, отвечают ли эти продукты истинной философии управления рисками и соблюдения законов, но и то, и другое, безусловно, важно. Мы беремся утверждать, что эффективность любой ИТ-службы скоро будет определяться тем, насколько она владеет искусством управления рисками. Если нам не суждено преуспеть в этом деле, мы сами рискуем оказаться беспомощными перед шквалом угроз безопасности организаций, интересы которых, будучи профессионалами, должны защищать.
Чем в данном случае определяется мера профессионализма? Зрелостью суждений. Предложения, основывающиеся на смутных предчувствиях или броских статейках о ставших достоянием гласности взломах, будут оставлены без малейшего внимания большинством руководителей высшего звена. Не сформулированные в четких терминах "языка оценки рисков" (читай: "языка денег") любые соображения в отношении ИБ не будут услышаны.
Но бесконечное повторение мантр, состоящих из модных терминов, не имеет ничего общего с по-настоящему активным управлением рисками. За этой концепцией стоят наука и сложнейшие процессы. Степень зрелости сферы управления рисками изменчива; здесь наряду с местными страховыми компаниями работают такие корифеи, как Lloyd"s of London, а методики оценки рисков в ИТ представлены такими документами, как ANZ 4360, NIST 800-30 и Factor Analysis of Information Risk (FAIR). Но, каким бы глубоким ни было ваше понимание проблемы, и какую бы формальную методику вы ни выбрали, - в любом случае имеются критически важные положения, которые необходимо учесть, и шаги, которые необходимо предпринять.
Обсуждая и оценивая риск, прежде всего важно понимать аудиторию, к которой вы обращаетесь, и цель, которую вы хотите достичь. Специализирующийся на обеспечении ИБ в сфере финансовых услуг Майк Мюррей на собственном горьком опыте убедился, что бросаться терминами из области управления рисками не следует, когда речь заходит об ИТ-проектах в страховых компаниях. Общаясь с аудиторией, привыкшей иметь дело с таблицами актуарных расчетов, вы испытаете чувство неловкости, если не будете внимательными и выйдете за рамки своей компетенции.
Употреблять правильные термины чрезвычайно важно, и исторически индустрии ИТ здесь похвастаться нечем. К примеру, в ИТ слово "ресурс" может означать все, что угодно, - от USB-накопителя до автоматизированной системы размещения заказов или СУБД (скажем, чертежей отдела НИР). Дело осложняется еще и тем, как служба ИТ именует эти ресурсы (web14 или, хуже того, 10.1.2.3), при этом бизнес-назначение того или иного ресурса (являющегося, например, частью системы контроля за исполнением заказов) полностью игнорируется. Чтобы вести конструктивные дискуссии на тему управления рисками, необходимо устранить этот разрыв. Наиболее прогрессивные службы ИТ и безопасности уже навели здесь мосты совместно с заинтересованными бизнес-подразделениями компаний. Без этих шагов шансы конструктивно обсудить риски будут ничтожно малы, а уж их ранжировать - и того меньше.
В процессе обсуждения также важно правильно употреблять термины "уязвимость" и "угроза", поскольку их часто путают. Нестрогие определения гласят, что уязвимость - это состояние или нахождение в нем ресурса, результатом чего может быть нанесение вреда предприятию; а угроза - это сущность или действие, способные нанести такой вред. Дальнейшее погружение в тонкости использования этих терминов в ИТ и ИБ потребовало бы написания отдельной статьи. Пока же мы ограничимся еще одним напоминанием о важности их правильного употребления при обсуждении рисков. Как на пример всеобъемлющей дискуссии на тему терминологии в управлении рисками в ИТ сошлемся на методику FAIR.
Что может случиться?
Определившись с ресурсами, уязвимостями и угрозами, мы наконец вплотную подошли к весьма и весьма "скользкой" теме, а именно: определению вероятности. К сожалению, и здесь управление рисками в ИТ нуждается в совершенствовании как никакая другая отрасль, среди прочего, вследствие значительной доли субъективизма при недостатке статистических данных. Зрелый подход подсказывает, что понятие вероятности, в большинстве случаев выражаемой качественно, следовало бы заменить понятием частоты, оцениваемой количественно и рассчитываемой статистически. Подразделения ИТ, образующие еще сравнительно молодое сообщество среди профессионалов в области управления рисками, едва ли могут рассчитывать на скорое появление в их распоряжении актуарных таблиц по всем возможным инцидентам, если такое вообще возможно. Можно надеяться, что овладение методиками, вроде FAIR, и использование Байесовского подхода поможет заполнить некоторые имеющиеся пробелы, но даже если вначале мы ограничимся лишь определением важнейших метрик, событий и критических потерь, то уже одно это станет большим шагом вперед.
Оставим на время разговор об основах управления рисками и зададим себе вот какой важный вопрос: как научиться спокойно воспринимать происходящее? Общаясь со сторонниками традиционного подхода к ИБ, после слов "определить риск" обычно слышишь "ослабить риск", реже - "переложить риск", а уж о "допустимом риске" никто из них вообще не говорит. Здесь следовало бы кое-что уточнить, а именно: "перекладывание риска" не имеет ничего общего с технологией, а лежит целиком в сфере страхования и законодательства, и здесь многому еще предстоит учиться.
Тем не менее допустить риск не представляется для нас чем-то необычным, мы часто идем на это, но, как правило, в наименее рискованных ситуациях. Нельзя ли делать это чаще? И если можно, то как не ошибиться при этом?
Переводя разговор в привычную плоскость ИБ, сформулируем вопрос по-другому: что для вашей организации важнее - борьба с "червями" и вирусами или шифрование персональных данных? Снизит ли обнаружение сетевых вторжений риск больше, чем шифрование дисков всех ноутбуков организации? Известно ли нам, какие системы предприятия являются критически важными и какие - наименее важными, учитываем ли мы это различие на практике? Не нужно ли в процессе обучения пользователей основам ИБ наряду с мерами защиты от "зла" также уделять внимание мерам защиты от "дурака"? Ну и, наконец, что следует предпочесть - плохонькую защиту всего и вся или надлежащую защиту минимального набора ресурсов?
Как показывает исторический опыт, чаще всего предпочитают первое... На самом же деле для достижения успеха в обеспечении ИБ важно последнее. Не научившись количественно измерять степень риска и грамотно формулировать свои аргументы, нечего и надеяться на то, что нам удастся убедить руководство в необходимости - или, напротив, - бесполезности тех или иных мер защиты. Усвоив же терминологию, овладев умением грамотно пользоваться ею, выработав формальную методику определения и количественной оценки рисков, их соотнесения с соответствующими ресурсами, понятную представителям бизнес-подразделений, служба ИТ получит неплохой шанс добиться своей цели в деле расстановки приоритетов ИБ, отвечающих потребностям организации на всех уровнях.
Тщательно выбирайте проект...
Когда речь заходит о конкретных шагах в деле обеспечения ИБ, на ум всегда приходит одна и та же заученная мантра: "Будьте проактивными!" К сожалению, на практике упор по-прежнему делается на принятии мер, направленных на предотвращение уже случившегося... Разумеется, реагировать на события реального мира - это не чья-то прихоть, а насущная необходимость. Но не позволяйте боязни прошлого полностью овладеть вами. Здесь вас подстерегают две опасности: нарушение баланса стратегических и тактических мер и страх упустить из виду непрерывно развивающуюся ситуацию с возникновением все новых угроз.
Как же разрушить этот порочный круг? Вот тут-то и может помочь подход, основанный на управлении рисками. Он позволит вам сформулировать сценарии сетевых аномалий и выработать рациональную методику применения соответствующих мер противодействия. Учтите, что практические меры безопасности должны укладываться в общий стратегический план.
Например, риск уязвимости ОС, часто становящейся причиной взломов и вирусных эпидемий, устраняется с помощью современных средств управления "заплатами", в то время как в отношении обеспечения безопасности приложений эти инструменты пока действуют не столь эффективно.
Многие предприятия всерьез занялись безопасностью своих систем лишь в последние год-два, и большинство их инициатив все еще пребывает в младенчестве. Среди них типичными можно назвать сканирование веб-приложений, наивные попытки собственными силами проверить приложения "на прочность", аудит их исходного кода сторонними консультантами и приобретение МЭ прикладного уровня.
Большинство этих усилий стали шагами в правильном направлении, но без мер стратегического характера, таких, как обучение разработчиков и контроль за соблюдением требований безопасности на стадиях проектирования, программирования и сопровождения корпоративных приложений, а также включение в контракты с поставщиками ПО положений об ответственности последних за его безопасность, вы будете по-прежнему вынуждены бороться с симптомами "болезни", упуская из виду ее причину.
Пример с уязвимостью приложений, хотя и единственный, но своевременный. Предприятиям, которые полагаются на метод управления рисками, следует проинвестировать как тактическую, так и стратегическую составляющие безопасности своих ИТ-проектов.
...и принимайте правильные решения
Безусловно, в ИБ технологии играют главную роль, но, к сожалению, мы склонны переоценивать их значение. Среди специалистов по безопасности ИТ даже бытует мнение, что, чем больше технологий, тем лучше. Его сторонникам следовало бы проявлять больше воображения, решая проблемы ИБ простым перебиранием продуктов, способных, по их убеждению, "сделать все необходимое".
Оглядываясь назад, невольно спрашиваешь себя, где были наши головы раньше? Ну вот, например, во времена мэйнфреймов мы целиком полагались на пользовательские имена и пароли как на вполне адекватный механизм управления доступом к вычислительным ресурсам. Странным образом мы затем почему-то решили, что их окажется вполне достаточно, когда появились сети на основе протоколов IPX и IP и воцарилась клиент-серверная архитектура.
Тогда всем нам пришлось усвоить ряд уроков, и в частно-сти следующий: механизм парольной защиты не спасет нас от зла. Поэтому появились межсетевые экраны, и мы опять целиком положились на технологию. И вновь оказались поверженными. Затем последовали долгие дебаты об уязвимости наших ОС. Корпоративные пользователи и поставщики ПО игнорировали очевидную опасность до тех пор, пока "вирусные эпидемии" и волна взломов ОС не заставили их отнестись к проблеме со всей серьезностью. Последовали щедрые инвестиции в системы сканирования уязвимостей и управления "заплатами".
Путешествие продолжается. Мы потратили сотни миллионов долларов на системы обнаружения вторжений, не отдавая себе отчета в их эффективности по отношению к себестоимости. IDS-гонка логически привела нас к системам предотвращения вторжений, которые и по сей день работают лишь вполсилы, а уж о развертывании инфраструктуры открытых ключей предприятия и слышать не хотят. В разочарованиях теми или иными продуктами ИБ недостатка не наблюдается. Инсталляция системы IPS уровня хоста оборачивается сущим кошмаром. Отсутствие инноваций на антивирусном фронте пугает. Программное обеспечение управления событиями безопасности развивается, но по-прежнему стоит дорого, а ПО защиты конечных узлов едва-едва только появилось.
От профессионалов ИБ нам часто приходится слышать следующее: "Наша система контроля уязвимостей превосходно работала полгода, затем мы деинсталлировали ее".
Нужно ли нам остановиться на этом и признать, что все технологии ИБ, мягко говоря, далеки от совершенства? Нет, мы все-таки умеем извлекать уроки из прошлого: парольная защита по-прежнему служит нам, но мы не полагаемся исключительно на нее. Процедуры "латания" и обновления ПО встраиваются теперь непосредственно в ОС, и, даже если не принимать в расчет рекламную шумиху вокруг NAC, поступающие на рынок сетевые устройства оснащаются защитными функциями. Да и среди поставщиков ПО наблюдается стремление гарантировать качество и безопасность их продукции.
Двигаясь дальше, мы вынуждены не только продолжать учиться на своих ошибках, но и принимать на вооружение инновационные стратегии. Для начала не упустите из виду тенденцию к консолидации наборов свойств продуктов. Когда какая-нибудь защитная функция ИТ-продукта преподносится в качестве его базовой характеристики, следует задаться вопросом: это все-таки продукт или функция? Для примера возьмем полнодисковое шифрование (Full Disk Encryption - FDE). Неудивительно, что после волны утечек конфиденциальной информации, ставших результатами краж ноутбуков, внедрение в ИТ-продукты технологий FDE развернулось полным ходом. До недавних пор предприятия внедряли у себя специализированные FDE-пакеты, сегодня же ведущие производители встраивают эти функции в свои продукты. Для примера: ряд моделей ноутбуков Think-Pad от Lenovo поставляются со встроенными функциями FDE, доступными благодаря использованию поддерживающих шифрование жестких дисков Seagate Momentus; опция FDE, известная под названием BitLocker, имеется также в некоторых версиях ОС Windows Vista. Учитывая данную тенденцию к консолидации, продвинутые предприятия и организации требуют от своих поставщиков ИТ, чтобы те изначально включали функции безопасности как в инфраструктурные решения, так и в продукты для конечных пользователей.
Глядя вперед
Для обеспечения ИБ так или иначе нужны продукты и технологии, но при всем при этом не менее необходим сбалансированный подход. Следует ли поддаваться пропаганде и заниматься внедрением решений NAC или лучше зашифровать все носители данных? Поможет ли выявление аномалий поведения пользователей в сети снизить степень риска для организации или в данном отношении для нее важнее тщательно выверенные процедуры выделения ресурсов? Не лучше ли заняться выработкой политики безопасности для мобильных устройств, чем тратить время на анализ журналов событий систем IDS?
Не отвергая ничего из вышеперечисленного, всегда задавайте себе подобные вопросы, чтобы не оказаться заложником технологий. В перспективе все организации должны будут внедрить у себя формальные процессы управления рисками. Фактически это приведет к появлению новой руководящей должности - лица, ответственного за управление рисками (Chief Risk Officer - CRO).
В связи с этим возникают вопросы: какая часть ответственности за ИБ предприятия отойдет к CRO и какая останется за службой ИТ? не игнорируем ли мы имеющую место в действительности тесную связь ИБ с непрерывностью ведения бизнеса и его устойчивостью к катастрофам (disaster recovery/business continuity)? Этим вопросам уже начинают уделять внимание, но, на наш взгляд, недостаточное.
Для нас очевидно одно: либо нам, профессионалам ИТ, нужно сделать над собой усилие и стать менеджерами по управлению рисками, либо вместо нас ими станут другие..