Информационная безопасность

Конспект лекций по дисциплине «Информационная безопасность» 2013 г. 1 1. 2. 3. 4. Основная литература Современная компьютерная безопасность. Теоретические основы. Практические аспекты учеб. пособие для вузов А. Ю. Щербаков - М. Книж. мир 2009 352 с. ил. Закон Российской Федерации «Об информации, информатизации и защите информации» от 25.01.95 г. Защита информации в компьютерных системах и сетях Ю. В. Романец, П. А. Тимофеев, В. Ф. Шаньгин; под ред. В. Ф. Шаньгина - 2-е изд., перераб. и доп. - М. Радио и связь 2001 - 376 с. ил. Программно-аппаратные средства обеспечения информационной безопасности. Защита в операционных системах учеб. пособие для вузов В.Г. Проскурин, С.В. Крутов, И.В. Мацкевич - М. Радио и связь 2000 - 168 с. ил Дополнительная литература 5. Обнаружение хакерских атак. Для профессионалов Дж. Чирилло; пер. с англ. А. Ярцева - СПб. Питер 2003 - 864 с. Ил 6. Сетевые операционные системы учебник для вузов В. Г. Олифер, Н. А. Олифер - 2-е изд. - СПб. Питер 2009 - 669 с. ил. 7. Межсетевое экранирование учеб. пособие О. Р. Лапонина - М. Интернет Унт Информ. Технологий БИНОМ. Лаб. знаний 2007 - 343 с. ил. 8. Информационно-справочная система по документам в области технической защиты информации [Электронный ресурс]/ ФСТЭК России - ФСТЭК России, 2011 – Режим доступа: http://www.fstec.ru/_razd/_isp0o.htm , свободный. – заглавие с экрана. 2 1. Управление безопасностью Управление безопасностью включает в себя управление рисками, политики информационной безопасности, процедуры, стандарты, руководства, базисы, классификацию информации, организацию безопасности и обучение по вопросам безопасности. Эти ключевые аспекты служат основой корпоративной программы безопасности. Целью безопасности и программы безопасности является защита компании и ее активов. Анализ рисков позволяет идентифицировать эти активы, выявить угрозы, вызывающие риски для них, оценить возможные потери и потенциальные убытки, которые компания может понести в случае реализации любой из этих угроз. Результаты анализа рисков помогают руководству подготовить бюджет, учитывающий все необходимые затраты для защиты идентифицированных активов от выявленных угроз, и разрабатывать применимые на практике политики безопасности, которые направляют деятельность по обеспечению безопасности. Обучение и повышение осведомленности по вопросам безопасности позволяет довести необходимый объем информации до сведения всех и каждого сотрудников компании, что упрощает их работу и позволяет достичь целей безопасности. Процесс управления безопасностью является непрерывным. Он начинается с оценки рисков и определения потребностей, затем следует мониторинг и оценка систем и применяемых методов работы. После этого проводится повышение осведомленности сотрудников компании, которое обеспечивает понимание вопросов, которые должны учитываться. Последним шагом является внедрение политик и защитных мер, направленных на снижение рисков и реализацию потребностей, определенных на первом шаге. Затем цикл начинается сначала. Таким образом, этот процесс постоянно анализирует и контролирует безопасность компании, позволяет ей адаптироваться и развиваться с учетом потребностей в обеспечении безопасности и тех условий, в которых компания существует и работает. Управление безопасностью со временем меняется, так как меняется сетевое окружение, компьютеры и приложения, обрабатывающие информацию. Интернет, сети экстранет (сети бизнес-партнеров), сети интранет делают безопасность не только более сложной, но и более критичной. Ядро сетевой архитектуры изменилось с локализованных автономных вычислений на среду распределенных вычислений, что многократно увеличило ее сложность. Хотя доступ из внутренней сети в Интернет дает пользователям ряд важных возможностей и удобств, он увеличивает уязвимость компании из Интернета, что может стать источником дополнительных рисков безопасности. Сегодня большинство организаций не смогут работать без компьютеров и их вычислительных возможностей. Многие крупные корпорации уже осознали, что их данные – это важнейший актив, который нужно защищать наравне со зданиями, оборудованием и другими физическими активами. Безопасность должна меняться одновременно с изменениями сетей и окружения. Безопасность – это больше, чем просто межсетевой экран и маршрутизатор со списком контроля доступа. Эти системы, несомненно, важны, но гораздо большее значение для безопасности имеет управление действиями пользователей и процедурами, которым они следуют. Это приводит к практике управления безопасностью, которая сосредоточена на постоянной защите активов компании. 1.1. Роли в управлении безопасностью В функции руководителя входит определение целей, границ, политик, приоритетов и стратегий. Руководству нужно определить четкие границы и актуальные цели, достижение которых ожидается в результате выполнения программы безопасности. Также 3 руководству нужно оценить цели бизнеса, риски безопасности, продуктивность пользователей, функциональные требования и цели. Наконец, руководство должно определить шаги, обеспечивающие правильное распределение и решение этих задач. Обеспечение информационной и компьютерной безопасности не входит в обязанности ИТ-администратора. Руководство, считающее обратное не воспринимает защиту своих данных и активов всерьез, в результате чего безопасность в таких компаниях выглядит недоразвитой, плохо поддерживаемой, недостаточно финансируемой и неудачной. Безопасность должна учитываться на уровне высшего руководства. Администратор безопасности может консультировать руководство по вопросам безопасности, но безопасность компании не должна быть полностью делегирована ИТ-администратору или администратору безопасности. Управление безопасностью основывается на четко идентифицированных и оцененных активах компании. После идентификации и оценки активов внедряются политики безопасности, процедуры, стандарты и руководства по обеспечению целостности, конфиденциальности и доступности для этих активов. Для классификации данных, выполнения анализа и оценки рисков используются различные инструменты. Эти инструменты помогают выявить уязвимости и показывают уровень их критичности, что позволяет внедрить эффективные контрмеры для снижения рисков наиболее оптимальным способом. В обязанности руководства входит обеспечение защиты ресурсов компании в целом. Этими ресурсами являются люди, капитал, оборудование и информация. Руководство должно принимать в этом участие, чтобы убедиться, что программа безопасности внедрена, угрозы, которые влияют на ресурсы компании, учтены, а также чтобы иметь уверенность в том, что необходимые защитные средства эффективны. Должна быть обеспечена доступность необходимых ресурсов и финансирования, ответственные лица должны быть готовы принять участие в мерах по защите информации и активов предприятия. Руководство должно распределить обязанности и определить роли, необходимые для начала выполнения программы безопасности, обеспечения ее успешного развития и эволюционирования по мере изменения окружения. Руководство также должно интегрировать программу безопасности в имеющуюся бизнес-среду и контролировать их работу. Поддержка руководства – одна из важнейших частей программы безопасности. 1.2. Подход "сверху-вниз". В процессе планирования и внедрения программы безопасности специалист по безопасности должен определить выполняемые функции и ожидаемый конечный результат. Часто компании просто начинают блокировать компьютеры и устанавливать межсетевые экраны, не понимая требования безопасности в целом, цели и уровни доверия, которые они хотели бы получить от безопасности в рамках всего окружения. Группе, вовлеченной в данный процесс, следует начать сверху, с очень широких идей и терминов, и двигаться вниз к детальным конфигурациям и системным параметрам. На каждом этапе члены группы должны держать в уме основные цели безопасности, чтобы каждый новый компонент добавлял больше деталей к соответствующей цели. Политика безопасности является своеобразным фундаментом для программы безопасности компании – совокупности мер и мероприятий по защите информауции. К этой политике нужно относиться серьезно с самого начала, в нее должны быть заложены идеи постоянной актуализации, обеспечивающие постоянное функционирование всех компонентов безопасности и работу по достижению целей, соответствующих целям бизнеса. Следующим шагом является разработка и внедрение процедур, стандартов и руководств, поддерживающих политику безопасности и определяющих контрмеры и 4 методы, которые должны применяться для обеспечения безопасности. Когда эти элементы разработаны, программу безопасности следует детализировать, разработав базисы и конфигурации для выбранных средств и методов безопасности. Если безопасность основана на прочном фундаменте и разработана с учетом целей и задач, компании не придется вносить в нее существенные изменения. В этом случае процесс может быть более методичным, требующим меньше времени, денег и ресурсов, обеспечивая при этом правильный баланс между функциональностью и защитой. Это не является обязательным требованием, но понимание этого может сделать подход вашей компании к безопасности более управляемым. Вы можете объяснить компании, каким образом следует планировать, внедрять и обеспечивать безопасность организованными способами, позволяющими избежать гигантской кучи средств безопасности, разрозненных и полных недостатков. Для программы безопасности следует использовать подход "сверху-вниз", означающий, что инициатива, поддержка и определение направления исходит от топменеджмента и идет через руководителей среднего звена к сотрудникам. Противоположный подход "снизу-вверх" относится к ситуации, когда ИТдепартамент пытается самостоятельно разработать программу безопасности, без должных указаний и поддержки руководства. Подход "снизу-вверх", как правило, менее эффективен, достаточно узок, и обречен на провал. Подход "сверху-вниз" гарантирует, что движущей силой программы являются люди (высшее руководство), которые действительно ответственны за защиту активов компании. 2. Администрирование безопасности и защитные меры Если обязанности администратора безопасности никто не выполняет, руководство должно возложить их. Обязанности администратора безопасности включают в себя контроль основных аспектов программы безопасности. В зависимости от организации, ее размеров и потребностей в безопасности, администрированием безопасности может заниматься один сотрудник или группа сотрудников, работающих централизованно или децентрализовано. Независимо от размеров, администрирование безопасности требует четкой структуры отчетности, понимания обязанностей, а также возможностей проверки и мониторинга, чтобы убедиться в отсутствии нарушений безопасности, вызванных недостатками взаимодействия или понимания. Владельцы информации должны указывать, какие пользователи могут иметь доступ к их ресурсам и что они могут делать с этими ресурсами. Задача администратора безопасности – убедиться, что этот процесс внедрен. Следующие защитные меры следует использовать для выполнения указаний руководства по вопросам безопасности: • Административные меры. Включают в себя разработку и публикацию политик, стандартов, процедур и руководств, управление рисками, подбор персонала, проведение тренингов по вопросам безопасности, внедрение процедур управления изменениями. • Технические (логические) меры включают внедрение и поддержку механизмов управления доступом, управления паролями и ресурсами, методами идентификации и аутентификации, устройствами безопасности, а также настройками инфраструктуры. • Физические меры включают в себя контроль доступа людей в здание и различные помещения, использование замков и удаление неиспользуемых дисководов и приводов CD-ROM, защиту периметра здания, выявление вторжений, контроль окружения. Рис. 1 иллюстрирует совместную работу административных, технических и физических мер безопасности, обеспечивающую необходимый уровень защиты. 5 Рис. 1 – Уровни защитных мер Владельцем информации обычно является ответственный сотрудник, входящий в руководящий состав компании или руководитель соответствующего департамента. Владелец информации обязан обеспечить надлежащую защиту данных, он несет единоличную ответственность за любую халатность в отношении защиты информационных активов компании. Сотрудник, который выполняет эту роль, несет ответственность за классификацию информации, он указывает, как эта информация должна быть защищена. Если защита данных не основана на требованиях владельца информации, если он не контролирует выполнение своих требований, может быть нарушена концепция due care (должной заботы). Следует обеспечить постоянное взаимодействие между группой администраторов безопасности и высшим руководством, чтобы гарантировать, что программа безопасности получает достаточную поддержку, а руководство принимает необходимые решения по ее реализации. Часто высшее руководство полностью исключает свое участие в вопросах безопасности, не принимая во внимание, что в случае возникновения серьезных инцидентов, связанных с безопасностью, именно высшее руководство будет объяснять их причины бизнес-партнерам, акционерам и публике. После такого случая отношение коренным образом изменяется, руководство максимально включается в вопросы безопасности. Следует обеспечить процесс постоянного взаимодействия между группой администраторов безопасности и высшим руководством, обеспечивающий двусторонние взаимоотношения. Неадекватное руководство может свести на нет все усилия компании в области безопасности. Возможными причинами неадекватного руководства может быть недостаточное понимание руководством потребностей компании в обеспечении безопасности, конкуренция безопасности с другими целями руководства, взгляд руководства на безопасность как на дорогую и ненужную затею, поддержка безопасности руководством компании только на словах. Мощные и полезные технологии, устройства, программное обеспечение, процедуры и методология обеспечивают определенный уровень безопасности, но без полноценного управления безопасностью и поддержки руководства они не имеют никакого значения. 6 2.1. Основные принципы безопасности Существует несколько маленьких и больших задач программы безопасности, но 3 основных принципа есть во всех программах: доступность, целостность и конфиденциальность. Это называется AIC-триадой (Availability, Integrity, Confidentiality). Уровень безопасности, необходимый для реализации этих принципов, отличается в различных компаниях, так как каждая компания имеет собственное уникальное сочетание целей бизнеса и безопасности, а также потребностей. Все защитные меры и механизмы безопасности внедряются для реализации одного (или нескольких) из этих принципов, а все риски, угрозы и уязвимости измеряются по их потенциальной способности нарушения одного или всех принципов AIC. AIC-триада показана на Рис. 2. Рис. 2 – Цели безопасности Доступность. Системы и сети должны обеспечивать достаточный уровень предсказуемости в сочетании с приемлемым уровнем производительности. Они должны иметь возможность восстанавливаться после сбоев быстро и безопасно, чтобы это не оказывало негативного воздействия на производительность работы компании. Следует избегать "единых точек отказа", осуществлять резервное копирование, при необходимости обеспечивать определенный уровень избыточности, предотвращать негативное влияние со стороны внешней среды. Необходимо внедрить механизмы защиты от внутренних и внешних угроз, которые могут сказаться на доступности и производительности сети, систем и информации. Доступность обеспечивает уполномоченным лицам надежный и своевременный доступ к данным и ресурсам. На доступность системы может повлиять сбой аппаратного или программного обеспечения. Следует использовать резервное оборудование для возможности оперативной замены критически важных систем. Обслуживающий персонал должен обладать всеми необходимыми знаниями и быть доступен для своевременного перехода на резервные системы и выполнения соответствующих настроек. Внешние факторы, такие как температура, влажность, статическое электричество, пыль могут также повлиять на доступность системы. DoS-атаки являются популярной методикой хакеров, нарушающей работу компании. Такие атаки снижают возможности доступа пользователей к ресурсам систем и информации. Чтобы защититься от них, следует ограничивать количество доступных портов, использовать системы IDS, контролировать сетевой трафик и работу компьютеров. Правильная настройка межсетевых экранов и маршрутизаторов также может уменьшить угрозу DoS-атак. Целостность. Целостность обеспечивает гарантии точности и надежности информации и предоставляющих ее информационных систем, предотвращает возможность 7 несанкционированных изменений. Аппаратные средства, программное обеспечение и коммуникационное оборудование должны работать совместно для надлежащего хранения и обработки данных, их правильного перемещения до места назначения в неизменном виде. Системы и сети должны быть защищены от вмешательства извне. Атаки на системы или ошибки пользователей не должны влиять на целостность систем и данных. Если злоумышленник установит вирус, логическую бомбу или скрытый вход (backdoor), целостность системы будет нарушена. Это может негативно повлиять на целостность информации, хранящейся в системе, и привести к мошенничеству, несанкционированным изменениям программного обеспечения и данных. Для борьбы с этими угрозами необходим строгий контроль доступа, системы выявления вторжений. Пользователи, как правило, влияют на целостность систем или данных в результате ошибок (хотя внутренние пользователи также могут совершать мошеннические или злоумышленные действия). Например, случайное удаление конфигурационных файлов, ввод ошибочной суммы операции и т.д. Меры безопасности должны ограничить возможности пользователей только минимально необходимым набором функций, что снизит вероятность и последствия их ошибок. Доступ к критичным системным файлам должен быть ограничен для пользователей. В приложениях следует предусмотреть механизмы контроля входящей информации, проверяющие ее корректность и адекватность. Права изменения данных в базах данных должны быть предоставлены только уполномоченным лицам, передаваемые по каналам связи данные должны быть защищены с помощью шифрования или других механизмов. Конфиденциальность. Конфиденциальность обеспечивает необходимый уровень секретности в каждой точке обработки данных и предотвращает их несанкционированное раскрытие. Конфиденциальность должна обеспечиваться как при хранении информации, так и в процессе ее передачи. Атакующие могут нарушить конфиденциальность, перехватывая сетевой трафик, подглядывая за работой сотрудников, похищая файлы с паролями, применяя методы социальной инженерии. Пользователи могут преднамеренно или случайно разглашать конфиденциальную информацию, забывая зашифровать ее перед отправкой другому лицу, став жертвой атаки с использованием социальной инженерии, предоставляя доступ к секретной информации компании, не обеспечивая необходимой защиты при обработке конфиденциальной информации. Конфиденциальность может быть обеспечена путем шифрования данных при их хранении и передаче, применения строгой системы контроля доступа, классификации данных, а также обучения персонала правильным методам работы с конфиденциальной информацией. 2.2. Определения безопасности Важно понимать значение слов "уязвимость", "угроза", "риск", "воздействие", а также взаимосвязь между ними. Уязвимость - это недостаток в программном обеспечении, оборудовании или процедуре, который может предоставить атакующему возможность доступа к компьютеру или сети и получения несанкционированного доступа к информационным ресурсам компании. Уязвимость - это отсутствие или слабость защитных мер. Уязвимостью может являться служба, запущенная на сервере, "непропатченное" приложение или операционная система, открытый порт на межсетевом экране, слабая физическая безопасность, позволяющая любому войти в серверную комнату, отсутствие управления паролями на серверах и рабочих станциях. Угроза - это потенциальная опасность для информации или системы. Угрозой является, если кто-то или что-то выявит наличие определенной уязвимости и использует ее против компании или человека. Нечто, дающее возможность использования 8 уязвимости, называется источником угрозы (threat agent). Источником угрозы может быть хакер, получивший доступ к сети через открытый на межсетевом экране порт; процесс, осуществляющий доступ к данным способом, нарушающим политику безопасности; стихийное бедствие, разрушившее здание; сотрудник, совершивший ошибку, которая может привести к утечке конфиденциальной информации или нарушению целостности файлов. Риск - это вероятность того, что источник угрозы воспользуется уязвимостью, что приведет к негативному воздействию на предприятие. Если межсетевой экран имеет несколько открытых портов, существует высокая вероятность, что злоумышленник воспользуется одним из них для несанкционированного доступа к сети. Если пользователи не обучены правильным процессам и процедурам, существует высокая вероятность совершения ими умышленных и неумышленных ошибок, которые могут привести к уничтожению данных. Если в сети не внедрена система IDS, существует высокая вероятность того, что факт проведенной атаки останется не выявленным, пока уже не будет слишком поздно. Воздействие (exposure) - это нечто, приводящее к потерям в связи с действиями источника угрозы. Уязвимости воздействуют на компанию, приводя к возможности нанесения ей ущерба. Если управление паролями слабое, а требования к паролям не внедрены, компания подвержена возможному воздействию в результате компрометации паролей пользователей и их использования для несанкционированного доступа. Если компания не следит за своей электропроводкой и не предпринимает шагов для предотвращения пожара, она подвержена потенциальному воздействию пожара. Контрмеры (или защитные меры) - это меры, внедрение которых позволяет снизить уровень потенциального риска. Контрмерами может быть настройка программного обеспечения, оборудования или процедур, устраняющая уязвимости или снижающая вероятность того, что источник угрозы сможет воспользоваться уязвимостью. Примером контрмер является строгое управление паролями, охрана, механизмы контроля доступа операционных систем, установка паролей BIOS, проведение обучения пользователей по вопросам безопасности. Если компания использует антивирусное программное обеспечение, но не обновляет базы вирусных сигнатур – это уязвимость. Компания уязвима для вирусных атак. Угрозой является то, что вирус проникнет в сеть компании и парализует ее работу. Риск в данном случае - это вероятность проникновения вируса в сеть компании и нанесения ей ущерба. Если вирус проникнет в сеть компании, уязвимость будет использована и компания окажется под воздействием нанесенного им ущерба. Контрмерами в этой ситуации будет поддержка актуальности баз вирусных сигнатур. Взаимосвязь между рисками, уязвимостями, угрозами и контрмерами показана на Рис. 3. Рис. 3 – Взаимосвязь компонентов безопасности 9 2.3. Безопасность посредством неизвестности Неправильное понимание рисков может привести к множеству различных проблем для компании и не позволит обеспечить хорошую работу безопасности. К сожалению, достаточно часто применяется такая практика, как "безопасность посредством неизвестности", которая ведет к плачевным результатам. Корень этой проблемы заключается в отсутствии понимания возможностей современных компьютерных злоумышленников, незнании инструментов, которые они имеют в своем распоряжении, а также недооценке их изобретательности. Это ведет защитников информации к серьезнейшей ошибке – они считают себя умнее своего потенциального противника. Следствием этого являются элементарные ошибки в защите, небрежности и распространение ложного чувства безопасности. Например, распространены ошибочные мнения, что:  уязвимости не могут быть использованы, если они не общеизвестны; скомпилированный код более безопасен, чем открытый исходный код;  перевод HTTP-трафика на порт 8088 обеспечит достаточную защиту;  алгоритмы шифрования собственной разработки остановят злоумышленниками т.п. Это лишь немногие варианты потенциально опасных мнений, возникающих вследствие использования подхода к безопасности посредством неизвестности. Хотя всем хочется верить во врожденную доброту и порядочность своих коллег, если бы это на самом деле было бы так, у специалистов по безопасности не было бы работы. Безопасность не должна строиться на основе неизвестности! В мире криптографии, аналогичные идеи воплощены в принципе Кирхгофа, который еще в 1880-х годах, заявил о том, что нет смысла хранить в тайне алгоритм, т.к. злоумышленник может узнать (или предположить) его. Единственное, что должно быть тайной – это ключ. 3. Организационная модель безопасности Организационная модель безопасности является структурой, состоящей из многих элементов, механизмов защиты, логических, административных и физических компонентов, процедур, бизнес-процессов и конфигураций, которые работают совместно, обеспечивая необходимый уровень безопасности окружения. Каждая модель имеет свои отличия, но все модели реализованы в виде слоев: каждый слой поддерживает вышестоящий слой и защищает нижестоящий слой. Поскольку модель безопасности является структурой, компании могут наполнять ее различными видами технологий, методов и процедур для достижения необходимого уровня защиты своего окружения. Рис. 4 иллюстрирует компоненты, из которых может состоять модель безопасности. Эффективная безопасность требует взвешенного подхода и применения всех компонентов и процедур безопасности. Некоторые компоненты безопасности являются техническими (списки контроля доступа, шифрование), а некоторые - не техническими (физическими и административными, такими, как разработка политики безопасности и обеспечение соответствия ей), но каждый имеет важное место в рамках общей модели. Если один компонент отсутствует или реализуется не в полной мере, это может оказать негативное воздействие на всю структуру. Модель безопасности имеет различные слои и различные виды целей, которые должны быть достигнуты за различные промежутки времени. Цели могут быть ежедневными (операционными), среднесрочными (тактическими) и долгосрочными (стратегическими). 10 Рис. 4 – Эффективная модель безопасности То же самое происходит и в сфере планирования безопасности. Ежедневные (операционные) цели связаны с продуктивностью и выполнением текущих задач, обеспечивающих функционирование компании предсказуемым образом. Среднесрочной (тактической) целью является, например, объединение всех рабочих станций и ресурсов в один домен, чтобы обеспечить возможность централизованного контроля. Примером долгосрочных (стратегических) целей может являться объединение всех беспроводных технологий с целью единого подхода к обеспечению их безопасности. Стратегическое планирование работает с планами, которые находятся на одном уровне с бизнес-целями и целями ИТ. Цели стратегического планирования долгосрочны и имеют широкий горизонт. Стратегическое планирование может включать некоторые из следующих целей: • обеспечить правильное понимание и учет рисков; • обеспечить соответствие требованиям законодательства и регуляторов; • интегрировать обязанности по безопасности в деятельность компании; • создать модель зрелости для обеспечения постоянного улучшения; • использовать безопасность как бизнес-преимущество, чтобы привлечь больше клиентов. Тактическое планирование относится к деятельности и поддержке, которые необходимы для достижения широких целей, выдвинутых в процессе стратегического планирования. В общем случае, тактические планы имеют более короткие сроки и более узкий горизонт планирования по сравнению со стратегическими планами. И, наконец, оперативное планирование – это весьма конкретные планы, сроки и цели. Оперативное планирование предполагает указание конкретных мероприятий, установление жестких сроков и графиков выполнения плана. Это конкретные действия, которые нужно предпринять для достижения целей тактических и стратегических планов. Ниже приводятся несколько примеров оперативного планирования: • выполнения оценки рисков безопасности; • недопущение негативного влияния изменений в системе безопасности на продуктивность; • поддержка и внедрение защитных мер; • постоянное сканирование уязвимостей и установка программных обновлений; 11 • контроль соответствия политикам. Такой подход к планированию называется горизонтом планирования(planning horizon). Безопасность работает лучше всего, если оперативные, тактические и стратегические цели компании определены и работают поддерживая друг друга. 3.1. Компоненты программы безопасности В настоящее время компании, корпорации, государственные учреждения и частные лица значительно больше внимания уделяют вопросам информационной безопасности, чем когда-либо прежде. Это правильно, поскольку означает большую степень вовлеченности в вопросы безопасности тех, кто принимает решения в компании. Ведь технологии являются лишь небольшой частью общей организационной безопасности компании. Однако наиболее часто события в компаниях развиваются по следующему сценарию. Генеральный директор и совет директоров вынуждены обратить внимание на вопросы информационной безопасности, так как появляются новые требования законодательства (ситуация в России с Федеральным законом №152 «О персональных данных»), существенно возрастает ущерб от хакерских и фрикерских атак (характерно для банковского и телекоммуникационного секторов), против компании подаются судебные иски за нарушение защиты информации (утечка СМС-сообщений клиентов с сайтов операторов «большой тройки»). Компания обычно нанимает консультанта, который объясняет генеральному директору и совету директоров, что они нуждаются в политике безопасности и оценке информационных активов. Компания платит за проведение этих работ и верит в то, что теперь она защищена. Однако это ложное чувство, поскольку в компании до сих пор нет программы безопасности, которая выполняется непрерывно. Затем компания нанимает специалиста по безопасности (обычно называемого CSO - Corporate Security Officer (руководитель Службы безопасности компании) или CISO Corporate Information Security Officer (руководитель Службы информационной безопасности компании) и делегирует ему всю работу по обеспечению безопасности и ответственность за нее, но не дает при этом ему каких-либо реальных полномочий и бюджета. Потом, когда инциденты с безопасностью все же случаются, всю ответственность за это возлагают на CISO (CSO). Таким образом, специалисты по безопасности имеют 3 возможных варианта действий: • Спрятать голову в песок, и надеяться, что проблемы обойдут стороной компанию в целом и этого специалиста в частности • Продолжать работать в том же духе, виня судьбу за все разочарования • Понимая, что наше общество делает только первые шаги в развитии информационной безопасности, изучать и использовать лучшие практики, уже разработанные в данной отрасли CISO обязан хорошо понимать бизнес-процессы и цели компании, доводить до сведения высшего руководства информацию о рисках, которые угрожают компании, а также о требованиях законодательства и регуляторов, которым должна соответствовать компания. Он должен разработать и внедрить программу обучения (повышения осведомленности) сотрудников компании по вопросам безопасности. Другими задачами CISO является разработка документов по безопасности: политик, процедур, базисов, стандартов и руководств. CISO должен быть в курсе новых технологий, отслеживать новую информацию, касающуюся вопросов безопасности. Также, в задачи CISO входит оценка реакции на инциденты, подготовка программ обеспечения соответствия компании новым требованиям, разработка метрик безопасности. Выполняя все эти обязанности и требования, CISO будет работать эффективно и обеспечит уверенность компании в надлежащей работе безопасности и учете рисков. 12 Важно, чтобы вопросы безопасности обсуждались и указывались в отчетах на максимально высоком уровне управления компанией, так как негативное воздействие на бизнес проблем безопасности и несоответствия требованиям может быть катастрофическим. Отчитываясь перед CEO (Chief Executive Officer – генеральный директор или президент компании) и другими руководителями высшего звена, CISO должен предоставить достоверную информацию и исключить любое недопонимание. Помимо высшего руководства CISO должен предоставлять отчеты и информацию в департамент ИТ, административный департамент, департамент страхования и управления рисками, юридический департамент, департамент внутреннего аудита, а также в бизнесподразделения. 3.2. Стандарты безопасности CobiT(Control Objectives for Information and related Technology) – это набор стандартов и лучших практик, разработанный ISACA(Information Systems Audit and Control Association) и ITGI(IT Governance Institute). CobiT определяет цели контроля ИТ, которые следует использовать для надлежащего управления ИТ и обеспечения соответствия информационных технологий компании потребностям ее бизнеса. CobiT состоит из четырех доменов: Планирование и Организация, Приобретение и Внедрение, Эксплуатация и Сопровождение, Мониторинг и Оценка. Каждый домен делится на подкатегории. Таким образом, домены CobiT предоставляют компаниям цели и инструкции, применимые при покупке, установке, тестировании, сертификации и аккредитации ИТ-продуктов. CobiT очень полезен, т.к. большинство компаний используют неформальные и непродуманные подходы при закупке ИТ-продуктов и выполнении процедур. Многие требования, а также аудиты основываются на стандарте CobiT. Поэтому, если вы хотите сделать своих аудиторов счастливыми, изучайте, используйте в работе, внедряйте контрольные объекты, которые считаются лучшими практиками. Людей, которые впервые видят CobiT, он просто ошеломляет, так как он имеет очень большой объем и не поддается полномасштабному внедрению даже за пару лет. По каждой из категорий CobiT определяет цели и методы контроля, целевые показатели, факторы успеха, а также модель зрелости. В нем излагается подробный план, которому можно следовать для выполнения каждой из 34 предусмотренных в нем целей контроля. Рис. 5 показывает, как структура CobiT объединяет бизнес требования, ИТ-ресурсы и ИТ-процессы. Многие аудиторы информационной безопасности используют CobiT в качестве критериев оценки результативности применяемых защитных мер. Поэтому, если вы хотите успешно пройти аудит, компании было бы неплохо знать и осмысленно выполнять указанные в CobiT задачи управления. CobiT основан на стандарте COSO, разработанном в 1985 году (разработчик: Committee of Sponsoring Organizations of the Treadway Commission) для борьбы с мошеннической финансовой деятельностью и недостоверной отчетностью. Структура COSO состоит из следующих компонентов: • управление средой • философия управления и стиль работы • культура компании, как отношение к этике и мошенничеству • оценка риска • определение целей в области рисков • возможность управлять внутренними и внешними изменениями • деятельность по контролю • политики, процедуры и практика, применяемая для снижения риска • информация и коммуникации 13 • структура, обеспечивающая, что только уполномоченные лица получают достоверную информацию в то время, когда она им необходима • мониторинг • выявление и реакция на недостатки контроля Рис. 5 - Компоненты CobiT COSO – это модель корпоративного управления, а CobiT – модель управления ИТ. COSO в большей степени относится к стратегическому уровню, а CobiT больше сосредоточен на оперативном уровне. Разработка и внедрение программы безопасности не так сложны, как кажутся многим компаниям, однако это новые для них вещи, которые представляются страшными и запутанными. Поэтому им следует обратиться к отраслевым стандартам и лучшим практикам, которые дают конкретные рекомендации по созданию и реализации полноценной программы безопасности. Наиболее широко для этих целей используется стандарт ISO 17799, основой которого является Британский Стандарт BS 7799. Это признанный на международном уровне стандарт управления информационной безопасностью, который предоставляет высокоуровневые концептуальные рекомендации по обеспечению безопасности компании. BS 7799 состоит из двух частей: в первой части описываются цели управления и ряд средств управления, которые могут быть использованы для достижения этих целей, а во второй части приводится порядок внедрения и поддержки программы безопасности. Вторая часть BS 7799 является базисом, на соответствие которому может быть сертифицирована компания. Сертификация компании может проводиться, например, с целью повышения доверия к ней со стороны клиентов и партнеров, а также с целью использования факта сертификации в качестве инструмента маркетинга. Сертификацию проводит уполномоченная независимая третья сторона, при этом компания может быть сертифицирована на соответствие всему ISO 17799 Part II, либо только отдельным его частям. В настоящее время произведен переход от стандарта ISO 17799 к целой группе стандартов ISO, которые помогают понять и структурировать лучшие практики. ISO 14 использует различные номера серий для различных видов стандартов. Например, серия ISO 9000 содержит ряд стандартов, которые относятся к управлению качеством для бизнес-процессов. Новая серия ISO/IEC 27000 используется для стандартов безопасности и гарантий. ISO подкорректировал стандарты 17799 для их соответствия новому формату нумерации. Ниже представлены стандарты ISO/IEC, которые следует использовать компаниям при разработке своей программы безопасности: • ISO/IEC 27001. Основан на стандарте BS7799 Part II, связанном с организацией, внедрением, контролем и совершенствованием Системы управления информационной безопасностью. • ISO/IEC 27002. Свод правил по управлению защитой информации (предыдущее название – ISO 17799), основан на стандарте BS 7799 Part I. • ISO/IEC 27004. Стандарт для измерений в области управления информационной безопасностью. • ISO/IEC 27005. Предназначен для реализации надлежащей информационной безопасности на основе ориентированного на риски подхода. • ISO/IEC 27006. Руководство по процессу сертификации / регистрации. • ISO/IEC 27799. Руководство по защите персональных данных о здоровье. Домены стандарта ISO/IEC 27002 (который ранее назывался ISO 17799), приведенные ниже, очень близки CISSP CBK (Common Body of Knowledge): • Политика информационной безопасности компании. Карта бизнес-целей в отношении безопасности, поддержки со стороны руководства, целей безопасности и обязанностей. • Создание инфраструктуры информационной безопасности. Создание и поддержка организационной структуры безопасности посредством распределения обязанностей по безопасности, процессов авторизации, учета требований безопасности при аутсорсинге, независимого контроля обеспечения информационной безопасности. • Классификация и управление активами. Разработка инфраструктуры безопасности для защиты активов компании посредством учета, инвентаризации, классификации, процедур использования активов. • Безопасность, связанная с персоналом. Снижение рисков, вызванных "человеческим фактором" за счет тщательного отбора персонала, определения ролей и обязанностей, надлежащего обучения сотрудников, документирования мер воздействия в случае несоблюдения требований. • Физическая безопасность и безопасность окружения. Защита активов компании посредством правильного размещения здания компании, установления и поддержания периметра безопасности, внедрения контроля доступа, защиты оборудования. • Управление коммуникациями и функционированием. Обеспечение безопасности функционирования посредством операционных процедур, надлежащего управления изменениями, разделения обязанностей, планирования ресурсов, управления сетью, работы с носителями информации, мониторинга. • Контроль доступа. Контроль доступа к активам на основе требований бизнеса, управления пользователями, методов аутентификации. • Разработка и поддержка систем. Обеспечение безопасности на всех этапах жизненного цикла систем посредством разработки требований безопасности, криптографии, контроля целостности и процедур разработки программного обеспечения. • Управление инцидентами безопасности. Обеспечение своевременного получения сведений о произошедших инцидентах и возникших уязвимостях, разработка порядка управления инцидентами и их анализа. • Управление непрерывностью бизнеса. Противодействие нарушению нормального функционирования посредством планирования непрерывности и тестирования планов. 15 • Соответствие требованиям. Обеспечение соответствия требованиям регуляторов, законодательства, условиям договоров и другим предписанным требованиям, посредством технических средств контроля и аудита. CobiT и COSO говорят о том, что должно быть достигнуто, но не говорят как. На помощь здесь приходят ITILи серия ISO/IEC 27000. ITIL (Information Technology Infrastructure Library) фактически является стандартом оптимального управления ИТслужбой. ITIL был создан для удовлетворения потребностей бизнеса, в связи с его растущей зависимостью от ИТ. К сожалению, слишком часто в компаниях существует целая пропасть между персоналом бизнес-подразделений и ИТ-подразделений, поскольку они используют различную терминологию и имеют разные цели в компании. Отсутствие понимания между бизнесом и ИТ ведет к неправильному (неэффективному) сочетанию целей бизнеса и функций ИТ, что, в свою очередь, ведет к путанице, нарушению сроков, упущенным возможностям, увеличению затрат времени и сил, а также разочарованиям с обеих сторон. Для решения этой проблемы предназначен ITIL. Там, где CobiT определяет ИТцели, ITIL указывает шаги на уровне процессов, предназначенные для достижения этих целей. Хотя в ITIL есть раздел, связанный с безопасностью, его внимание в основном сконцентрировано на внутренних соглашениях об уровне обслуживания (SLA– Service Level Agreement) между ИТ-департаментом и другими подразделениями компании, которые он обслуживает. В РФ перечисленные стандарты появились в виде следующих стандартов (по сути переводы аналогичных стандартов): ГОСТ Р ИСО/МЭК. 17799 - 2005. Информационная технология. Практические правила управления информационной безопасностью. ГОСТ Р ИСО/МЭК 27001 – 2005. Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования. 3.3. Управление безопасностью на стратегическом уровне Стратегическое управление безопасностью - очень похоже по своему характеру на корпоративное управление и управление ИТ на том же уровне, поскольку существуют дублирующиеся функции и задачи во всех трех. Все три вида управления работают в рамках организационной структуры компании, и имеют одни и те же цели – обеспечение выживания и процветания компании, просто каждый вид управления фокусируется на своей части. Количество требований, которым должны удовлетворять компании, постоянно растет. Советы Директоров компаний несут все больше и больше ответственности за работу бизнеса и эффективность всей компании. В связи с этим, более важную роль начинает играть стратегическое управление безопасностью и защитой информации, что обеспечивает использование надлежащих механизмов и предоставление Совету Директоров (и руководству компании) возможности эффективного надзора с целью управления рисками, поддержания их на приемлемом для компании уровне и ограничения потенциального ущерба. Существует множество различных определений стратегического управления безопасностью. Вот вариант определения, подготовленного ITGI: "Стратегическое управление (governance) – это набор функций, выполняющихся Советом Директоров и высшим руководством, которые задают стратегическое направление, контролируют достижение целей, надлежащее управление рисками и ответственное использование ресурсов компании". Это абсолютно правильное определение, но оно очень высокоуровневое и его трудно понять. Чтобы упростить понимание, давайте сравним две компании. Компания 16 "А" внедрила эффективную программу стратегического управления безопасностью, а компания "Б" нет. Обе компании имеют политику безопасности, процедуры, стандарты, одинаковые технологии управления безопасностью (межсетевые экраны, системы выявления вторжений, системы управления идентификацией и т.д.), подразделение безопасности, которой руководит CISO. Может показаться, что уровень безопасности компаний "А" и "Б" одинаков... Но это не так. Посмотрите на некоторые критические различия, приведенные в таблице 1. Таблица 1. – Сравнение подходов к информационной езопасности. Компания «А» Компания «Б» Члены совета директоров понимают, что Члены Правления не понимают, что информационная безопасность имеет информационная безопасность находится в решающее значение для компании, и их сфере ответственности, и требуют ежеквартально предоставлять сосредотачиваются исключительно на сведения об эффективности безопасности и корпоративном управлении и прибыли. выявленным недостаткам. CEO, CFO,CIO и руководители бизнесCEO, CFO и руководители бизнесподразделений участвуют в работе подразделений считают, что комитета по управлению рисками, который информационная безопасность находится в собирается каждый месяц, тема сфере ответственности CIO, CISO и ИТинформационной безопасности всегда департамента. И поэтому не вмешиваются. является одной из тем повестки дня. Высшее руководство устанавливает CISO использует шаблонные политики приемлемый уровень риска, что является безопасности, включая в них название основой для политики безопасности компании и подпись CEO. компании и всей деятельности в области безопасности Высшее руководство делегировало Вся деятельность, касающаяся руководителям бизнес-подразделений безопасности, осуществляется обязанности по управлению рисками, департаментом безопасности. Таким относящиеся непосредственно к их образом, безопасность остается не подразделениям. интегрированной в работу компании. Критичные бизнес-процессы Бизнес-процессы не документированы, не документированы с учетом рисков, которые проанализированы на наличие им присущи на различных шагах. потенциальных рисков, которые могут повлиять на операции, производительность и рентабельность. Сотрудники несут ответственность за Политики и стандарты разработаны, но не любые нарушения безопасности, исполняются или не осуществляется произошедшие по их вине умышленно или контроль, так как он не был предусмотрен случайно. или внедрен. Средства безопасности и различные услуги Средства безопасности и различные услуги покупаются и внедряются эффективными покупаются и внедряются без каких-либо способами. Их применение постоянно исследований, позволяющих определить анализируется, чтобы убедиться, что они отдачу от инвестиций и эффективность. остаются экономически целесообразными. Компания постоянно пересматривает свои Компания не анализирует свою процессы, включая вопросы обеспечения деятельность с целью ее улучшения, но безопасности, с целью их постоянного постоянно движется вперед, совершая одни совершенствования. и те же ошибки снова и снова. Большинство компаний на сегодняшний день имеют множество частей программы безопасности (политики, стандарты, межсетевые экраны, подразделение безопасности, 17 системы выявления вторжений и т.д.), но руководство в обеспечении безопасности не участвует, а безопасность не интегрирована в деятельность компании. За обеспечение безопасности компании отвечает исключительно подразделение безопасности, что является невозможным практически. Безопасность в таких компаниях является вопросом техники. Но сегодня в мире информационной безопасности такой подход не работает. Сегодняшняя безопасность – это намного большее, чем чисто техническое решение. Специалисты по безопасности должны понимать, что безопасность должна соблюдаться в рамках всей компании, и крайне важно иметь несколько центров ответственности и подотчетности. Стратегическое управление безопасностью является целостной системой, состоящей из различных компонентов (технических средств, персонала, процессов, политик и т.д.), которые существуют для выживания и процветания компании. ПРИМЕЧАНИЕ. Следует также учитывать такой важнейший фактор, как корпоративная культура компании. Даже если компания использует самые современные и передовые решения на рынке, она не сможет обеспечить необходимый уровень безопасности, если эти решения используются необученным, апатичным и беззаботным персоналом. Оценка культуры компании, очень важна при оценке положения безопасности в ней. Для того, чтобы обеспечить управление безопасностью, должно быть нечто такое, чем можно управлять. Набор объектов управления, которыми должна обладать компания, в общем виде называется программой безопасности. Разработка программы безопасности Важно понимать, что программа безопасности имеет непрерывный жизненный цикл, т.к. она должна постоянно оцениваться и совершенствоваться. Для описания жизненного цикла программы безопасности, будем использовать следующие шаги. 1. Планирование и Организация. 2. Реализация (внедрение). 3. Функционирование и Поддержка. 4. Мониторинг и Оценка. Однако многие компании не применяют подход жизненного цикла при разработке, внедрении и поддержании своей программы управления безопасностью. Они не знают, как это делать, или считают, что это слишком сложно и бесполезно. В результате это, как правило, приводит к следующим последствиям: • Написанные политики и процедуры, не отражаются на деятельности по обеспечению безопасности и не поддерживают ее. • Отсутствует взаимодействие и координация между различными сотрудниками компании, задействованными в обеспечении защиты ее активов. • Не проводится оценка результатов, отдачи от инвестиций и распределения ресурсов. • Отсутствует понимание недостатков программы безопасности, не применяются единообразные способы исправления недостатков. • Нет гарантий соответствия требованиям законодательства, регуляторов, требованиям политик. • Компания полностью полагается на технологии для решения всех вопросов безопасности. • Отсутствует единый орган принятия решений в компании. • К любым нарушениям применяется подход "пожарной тревоги", а не спокойный проактивный, детективный подход. • Появляется ложное чувство безопасности. Также, отсутствие жизненного цикла программы безопасности и управления безопасностью приводит к тому, что безопасность рассматривается просто как еще одна задача. А все задачи имеют дату начала и дату завершения, которая означает, что все участники переключаются на другую задачу. В результате компания с течением времени 18 выполняет одни и те же задачи, на них расходуются большие средства, но результат при этом минимален. Основные элементы каждой фазы жизненного цикла программы безопасности представлены ниже: Планирование и Организация • Получение одобрения от руководства. • Создание руководящего комитета по надзору (oversight steering committee). • Оценка бизнес-драйверов (бизнес-драйверы – это люди, информация или задачи, которые обеспечивают реализацию бизнес-целей компании). • Создание профиля угроз компании. • Проведение оценки рисков. • Разработка архитектуры безопасности на организационном, прикладном, сетевом и компонентном уровнях. • Определение решений на каждом уровне архитектуры. • Получение согласия руководства на дальнейшие действия. Реализация (внедрение) • Распределение ролей и обязанностей • Разработка и внедрение политик безопасности, процедур, стандартов, базисов и руководств • Выявление критичных данных на этапах хранения и передачи • Реализация следующих проектов: • Идентификация и управление активами • Управление рисками • Управление уязвимостями • Соответствие требованиям • Управление идентификацией и доступом • Управление изменениями • Жизненный цикл разработки программного обеспечения • Планирование непрерывности бизнеса • Обучение и повышение осведомленности • Физическая безопасность • Реакция на инциденты • Внедрение решений (административных, технических, физических) по каждому проекту • Разработка решений по аудиту и мониторингу для каждого проекта • Установка целей, соглашений об уровне обслуживания (SLA) и метрик по каждому проекту Эксплуатация и Сопровождение • Соблюдение установленных процедур для обеспечения соблюдения базисных уровней в каждом реализованном проекте. • Проведение внутренних и внешних аудитов. • Выполнение задач, намеченных в каждом проекте. • Управление соглашениями об уровне обслуживания по каждому проекту. Мониторинг и Оценка • Анализ лог-файлов, результатов аудита, собранных значений метрик и SLA по каждому проекту • Оценка достижения целей по каждому проекту • Проведение ежеквартальных встреч с руководящими комитетами • Совершенствование действий каждого этапа и их интеграция в фазу Планирования и Организации ПРИМЕЧАНИЕ. Различные компании, консультанты и специалисты по безопасности могут использовать различные подходы к созданию программы 19 безопасности, но в общем они охватывают те же разделы. Каждая компания имеет различные приемлемые для нее уровни риска, внедренные защитные меры, угрозы и бизнес-драйверы, однако их программы безопасности в основном содержат похожие элементы – просто одна компания больше внимания уделяет одним элементам, а другая – другим. Это связано с деятельностью компаний и их потребностях в безопасности. Модели и структуры весьма полезны, но они находятся на очень высоком уровне. Для воплощения их в жизнь необходимо разработать соответствующие проекты (blueprint). Проекты должны соответствовать требованиям безопасности компании, основанным на обязательствах компании, бизнес-драйверах и внутренних требованиях. Например, компания "В" имеет политику конфиденциальности, подразделение безопасности компании разработало стандарты и процедуры, реализующие стратегию обеспечения конфиденциальности, которым все сотрудники компании должны следовать. Затем разрабатывается проект, в проектной документации к которому указывается больше деталей, учитываются процессы и компоненты, к которым относятся требования политики, стандартов и процедур. В проектной документации должно быть, как минимум, следующее: • Схема сети компании • Места в сети, где находятся критичные данные • Сегменты сети, через которые проходят критичные данные • Различные применяемые решения по безопасности (VPN, SSL, PGP), которые защищают критичные данные • Подключения третьих сторон, с которыми совместно используются критичные данные • Используемые меры безопасности в отношении подключений третьих сторон. Проекты должны соответствовать потребностям компании. Если компания "В" использует систему управления идентификацией ( identity management), у нее должен быть соответствующий проект, проектная документация к которому содержит описание ролей, управления регистрацией, источников авторизации, хранения идентификационных данных, применения решений единого входа ( single sign-on) и т.д. Если компания "В" не использует систему управления идентификацией, то ей не нужен проект для этой системы. Ряд проектов, которые следует разработать большинству компаний, приведен ниже: • Управление безопасностью • Непрерывность бизнеса • Журналирование и мониторинг • Управление идентификацией • Целостность приложений • Инфраструктура • Управление активами • Физическая безопасность и безопасность окружения Таким образом, проект должен учитывать решения безопасности, процессы и компоненты, которые использует компания на основании своих потребностей в безопасности. Эти проекты имеют отношение к различным бизнес-подразделениям компании. Например, использование системы управления идентификацией предусматривает участие каждого подразделения компании. Четкое выполнение компанией этих проектов позволяет обеспечить стандартизацию, упростить сбор метрик и управление. Проекты следует разрабатывать с учетом лучших практик (как правило, с учетом ISO 17799). На рисунке 6 показано, где эти проекты вступают в силу при разработке программы безопасности. 20 Рис. 6. – Взаимодействие проектов ИБ в рамках 4. Управление информационными рисками Риск - это вероятность причинения ущерба и возможные последствия. Управление информационными рисками (IRM - Information Risk Management)представляет собой процесс выявления и оценки рисков, снижения их до приемлемого уровня, а также внедрения адекватных механизмов для поддержания этого уровня. Стопроцентной защиты не существует. Каждая система имеет уязвимости и подвержена угрозам. Необходимо выявлять эти угрозы, оценивать вероятность их реализации и ущерб, к которому это может привести. Затем нужно предпринимать правильные шаги для снижения общего уровня риска всего окружения до уровня, считающегося в компании приемлемым. Риски могут иметь различные формы, не обязательно связанные с компьютерами. С точки зрения информационной безопасности, существует несколько видов рисков, которые компания должна понимать и учитывать. Ниже представлен список основных категорий: • Физический ущерб. Пожар, затопление, вандализм, отсутствие электроэнергии, стихийные бедствия. • Действия человека. Случайные или намеренные действия или бездействие, которые могут нарушить работу компании. • Неисправность оборудования. Неработоспособность систем или периферийных устройств. • Внутренние и внешние атаки. Хакинг, крекинг и проведение атак. • Неправильное использование данных. Предоставление совместного доступа к конфиденциальной информации компании, мошенничество, шпионаж, кражи. • Утрата данных. Преднамеренное или непреднамеренное уничтожение информации. 21 • Ошибки приложений. Ошибки в вычислениях, ошибки ввода информации, переполнения буфера. Эти угрозы должны быть выявлены, категорированы, и оценены с точки зрения масштабов потенциальных потерь. Реальные риски очень трудно измерить, однако расставить приоритеты в списке потенциальных рисков и выбрать те, которыми следует заняться в первую очередь, вполне достижимо. 4.1. Кто действительно разбирается в управлении рисками? В действительности людей, которые понимают как управлять рисками, очень мало (в том числе и за рамками вопросов безопасности). В информационной безопасности часто концентрируются на приложениях, устройствах, протоколах, вирусах и т.д. Эти детали безусловно должны быть учтены в процессе управления рисками, но они не должны быть в центре внимания при управлении рисками. Управление рисками в целом значительно важнее отдельных технических мер. Безопасность - задача бизнеса. Однако бизнес работает, чтобы зарабатывать деньги, а не только чтобы быть безопасным. Бизнес часто обращает внимание на безопасность только тогда, когда появляются реальные угрозы основной деятельности потеря репутации и клиентов из-за утечки информации, ущерб в результате вирусной атаки и т.д. Специалисты по информационной безопасности должны понимать эти угрозы, но гораздо важнее, чтобы они понимали как можно рассчитать риски этих угроз и предоставить карту рисков руководителям бизнеса. Чаще всего бюджет является ограниченным, а количество уязвимостей - нет. В этом случае необходимо сконцентрироваться на наиболее критичных уязвимостях, устранение которых даст реальную отдачу для бизнеса. 4.2. Политика управления информационными рисками Полноценное управление рисками требует полноценной поддержки высшего руководства, документированного процесса поддержки миссии организации, IRMполитики и IRM-группы. IRM-политика должна быть частью общей политики управления рисками компании. IRM-политика должна быть отражена и в организационной политике безопасности компании. В IRM-политике должны учитываться следующие аспекты: • Цели IRM-группы • Уровень риска, который компания приняла для себя как приемлемый • Формальные процессы выявления рисков • Связь между IRM-политикой и процессами стратегического планирования компании • Обязанности, связанные с IRM, и роли, необходимые для их выполнения • Связь между рисками и внутренним контролем • Подходы к изменению поведения сотрудников и распределения ресурсов с учетом анализа рисков • Связь между рисками и целевыми показателями и бюджетами • Ключевые показатели для мониторинга эффективности защитных мер IRMполитика предоставляет инфраструктуру для процессов и процедур управления рисками компании. Она должна охватывать все вопросы информационной безопасности, начиная от подбора персонала и инсайдерских угроз, заканчивая физической безопасностью и межсетевыми экранами. Она должна предоставлять механизм передачи информации о рисках от IRM-группы высшему руководству, а также механизм принятия решений о необходимости снижения рисков высшим руководством. 22 4.3. Группа управления рисками (IRM-группа) В зависимости от размеров компании и бюджета безопасности компания может иметь одного или нескольких сотрудников, ответственных за IRM (IRM-группу). Основная цель IRM-группы - обеспечить защиту компании наиболее выгодным (экономически) и эффективным способом. Эта цель может быть достигнута только при наличии следующих компонентов: • Установленный высшим руководством приемлемый уровень риска • Документированные процессы и процедуры оценки рисков • Процедуры выявления и снижения рисков • Адекватные ресурсы и бюджет, предоставленные высшим руководством • Планы действий при возникновении непредвиденных обстоятельств (для тех областей, оценка которых указывает на необходимость таких планов) • Тренинги по вопросам безопасности для всех сотрудников, использующих информационные активы • Возможность расширения (развития) группы в отдельных областях, в случае необходимости • Учет и выполнение требований законодательства и регуляторов • Разработка метрик и показателей эффективности, позволяющих измерить и управлять различными видами рисков • Возможность выявления и оценки новых рисков при изменениях в компании или окружении • Интеграция IRM и процессов управления изменениями компании, чтобы изменения не приводили к появлению новых уязвимостей В большинстве случаев, в IRM-группу включают не отдельных, специально нанятых, сотрудников, а тех, которые уже работают в компании и выполняют другие задачи. В таких случаях совершенно необходима поддержка высшего руководства для надлежащего распределения ресурсов. Как и в любой другой команде, IRM-группе нужен лидер. Он должен заниматься только этим вопросом (либо, в крупных компаниях, он должен уделять этому 50-70% рабочего времени). Руководство должно выделить этому человеку адекватный бюджет, в случае необходимости обеспечить профессиональную подготовку, наличие инструментов для успешного анализа рисков. 5. Анализ рисков Анализ рисков, который на самом деле представляет собой инструмент для управления рисками, является методом выявления уязвимостей и угроз, оценки возможного воздействия, что позволяет выбирать адекватные защитные меры именно для тех систем и процессов, в которых они необходимы. Анализ рисков позволяет сделать безопасность экономически эффективной, актуальной, своевременной и способной реагировать на угрозы. Он также помогает компании приоритезировать список рисков, определить и обосновать разумную стоимость защитных мер. Анализ рисков имеет четыре основные цели: • Идентификация активов и их ценности для компании • Идентификация угроз и уязвимостей • Количественная оценка вероятности и влияния на бизнес этих потенциальных угроз • Обеспечение экономического баланса между ущербом от воздействия угроз и стоимостью контрмер Анализ рисков позволяет сравнить годовую стоимость защитных мер с потенциальным ущербом. Годовая стоимость защитных мер не должна превышать 23 потенциальный годовой ущерб. Также, анализ рисков позволяет связать программу безопасности с целями и требованиями бизнеса компании, что крайне важно для успеха и в том, и в другом. Перед началом работы по выявлению и анализу рисков важно понять цель данной работы, ее объем и ожидаемый результат. Следует учитывать, что попытка проанализировать все риски во всех областях за один раз может оказаться невыполнимой. Одной из первых задач группы анализа рисков является подготовка детального отчета по стоимости активов. Высшее руководство должно проанализировать этот отчет и определить сферу деятельности для IRM-проекта (объем работы), исключив из него те активы, которые не важны на данном этапе. При определении объема работ следует также учитывать бюджет проекта, а также требования законодательства. В ходе обсуждений с руководством, все участники должны иметь ясное представление о ценности обеспечения AIC-триады (доступность, целостность и конфиденциальность) и ее непосредственной связи с потребностями бизнеса. Анализ рисков должен осуществляться при поддержке и управлении со стороны высшего руководства. Только в этом случае он будет успешным. Руководство должно определить цели и масштабы анализа, назначить членов группы для проведения оценки, а также выделить необходимое время и средства для проведения этой работы. Крайне важно, чтобы высшее руководство внимательно отнеслось к результатам проведенной оценки. 5.1. Группа анализа рисков Для наиболее эффективного анализа рисков, компания должна включить в состав группы анализа рисков сотрудников большинства (или всех) своих подразделений, что необходимо для выявления и учета всех рисков. Членами группы могут быть руководители подразделений, разработчики приложений, ИТ-персонал - любые ключевые сотрудники ключевых подразделений компании. Это совершенно необходимо, т.к. группа, состоящая только из ИТ-специалистов, не сможет выявить множество рисков (например, риски, связанные с работой бухгалтерии). Желательно в состав группы включать руководителей подразделений, а не рядовых сотрудников, которые могут не представлять себе работу всего подразделения в целом и, соответственно, не могут выявить все угрозы. Для этого целесообразно установить соответствующий минимальный уровень должности для члена группы. Если по какой-либо причине компания не может включить в группу сотрудников из различных подразделений, необходимо, как минимум, организовать проведение интервью с ключевыми сотрудниками каждого подразделения. При анализе рисков следует задавать следующие вопросы: Что случится при реализации угрозы? Какими могут быть потенциальные последствия? Как часто это может происходить? Какой уровень достоверности ответов на первые три вопроса? Большинство такой информации собирается в ходе внутренних исследований, интервью, собраний рабочих групп. Владельцы рисков Один из наиболее важных вопросов – кто в компании владеет рисками? Ответить на него непросто, т.к. это зависит от ситуации и от того, о каких рисках идет речь. Высшее руководство владеет рисками, связанными с процессом функционирования компании, но оно может переложить их на ответственных за хранение данных или бизнесподразделения для проведения определенных работ, и на это время они должны выполнять отдельные обязанности владельцев рисков. Конечно, риски в конечном итоге всегда остаются у высшего руководства и оно должно быть уверено, что делегированная 24 работа выполняется понятными методами, в процессе нее учитываются существующие риски и предпринимаются действия по их минимизации. 5.2. Ценность информации и активов Ценность информации опредляется трудоемкостью ее подготовки (сбора), стоимостью ее поддержки (сопровождения), величиной возможного ущерба в случае ее потери или уничтожения, стоимостью, которую другие лица (конкуренты, злоумышленники) готовы заплатить за нее, а также величиной возможных последствий и штрафов, в случае ее утраты (утечки). Без проведения оценки информации невозможно адекватно оценить целесообразность затрат денег и ресурсов на ее защиту. Ценность информации обязательно должна учитываться при выборе защитных мер. 5.3. Определение стоимости и ценности Оценка актива может проводиться как количественными, так и качественными методами. Фактическая стоимость актива определяется на основании стоимости его приобретения, разработки и поддержки. Ценность актива определяется его значением, которое он имеет для владельцев, уполномоченных и неуполномоченных пользователей. Некоторая информация является важной для компании и ей присваивается гриф конфиденциальности. Например, стоимость сервера составляет $4000, но это не является его ценностью, учитываемой при оценке рисков. Ценность определяется затратами на его замену или ремонт, потерями из-за снижения производительности, ущербом от повреждения или утраты хранящихся на нем данных. Именно это будет определять ущерб для компании в случае повреждения или утраты сервера по той или иной причине. Следующие вопросы должны быть учтены при определении ценности активов: • Затраты на получение или разработку актива • Затраты на поддержку и защиту актива • Ценность актива для владельцев и пользователей • Ценность актива для злоумышленников (конкурентов) • Ценность интеллектуальной собственности, использованной при разработке актива • Цена, которую другие готовы заплатить за актив • Затраты на замену актива при утрате • Операционная и производственная деятельность, которая зависит от доступности актива • Ответственность в случае компрометации актива • Польза и роль актива в компании Понимание ценности актива является первым шагом к пониманию того, какие средства и механизмы безопасности должны использоваться для его защиты. Ценность актива определяет стоимость защитных мер, которые следует использовать для его защиты. Определение стоимости активов полезно для компании по целому ряду причин, включая следующие: • Для проведения анализа затраты/выгоды (cost/benefit analyse) • Для выбора конкретных контрмер и защитных средств • Для определения необходимого уровня страхового покрытия • Для понимания, чем именно рискует компания • Для выполнения требований законодательства, регуляторов, соблюдения должной заботы (due care) 25 Активы могут быть материальным (компьютеры, оборудование, материалы) или нематериальные (репутация, данные, интеллектуальная собственность). Обычно трудно оценить количественно ценность нематериальных активов (например, репутации), которая может меняться с течением времени. 5.4. Идентификация угроз Как было сказано ранее, риск - это вероятность того, что источник угрозы воспользуется уязвимостью, что приведет к негативному воздействию на бизнес. Существует множество видов источников угрозы, которые могут использовать разные типы уязвимостей, что может привести к определенным угрозам. Некоторые примеры рисков показаны в таблице 2. Таблице 2 – Пример идентификации рисков Источники угрозы Может использовать эту В результате возникает уязвимость угроза Вирус Отсутствие антивирусного Заражение вирусом ПО Хакер Большое количество служб, Несанкционированный запущенных на сервере доступ к конфиденциальной информации Пользователи Неверно настроенный Неисправность системы параметр операционной системы Пожар Отсутствие системы Здание и компьютеры пожаротушения повреждены, возможны человеческие жертвы Сотрудник Отсутствие обучения, Общий доступ к критичной требований или контроля информации Внесение изменений во вводимую информацию и выводимую из приложений обработки данных Подрядчик Слабые механизмы Утечка конфиденциальной контроля доступа информации Атакующий Плохо написанное Проведение атаки приложение «переполнение буфера» Нестрогие настройки Проведение DoS-атаки межсетевого экрана Нарушитель Отсутствие охраны Похищение компьютеров и других устройств Существуют и другие, гораздо более сложные для выявления виды угроз, которые могут произойти в компьютерной среде. Эти угрозы связаны с ошибками в приложениях и ошибками пользователей. Однако, при надлежащей организации контроля и аудита действий пользователей их ошибки (умышленные или случайные) выявить существенно проще. После выявления уязвимостей и связанных с ними угроз должны быть проанализированы последствия их использования, т.е. риски потенциального ущерба. Ущерб может быть связан с повреждением данных или систем (объектов), несанкционированным разглашением конфиденциальной информации, снижением производительности работы и т.д. При проведении анализа рисков, группа должна также рассмотреть вероятный отложенный ущерб (delayed loss), который может произойти по 26 прошествии некоторого времени (от 15 минут до нескольких лет) после реализации риска. Отложенный ущерб может быть вызван, например, снижением производительности работы через определенный период времени, снижением дохода компании, ущербом ее репутации, накопительными штрафами, дополнительными расходами на восстановление окружения, приостановкой приема средств от клиентов и т. д. Например, если в результате атаки на веб-серверы компании они перестали обслуживать клиентов, непосредственным ущербом может быть повреждение данных, затраты рабочего времени на восстановление работы серверов, обновление уязвимого программного обеспечения на них. Кроме того, компания потеряет определенный доход в следствие невозможности обслуживания клиентов в течение времени, которое потребуется ей на восстановление работы своих веб-серверов. Если восстановительные работы займут значительное время (например, неделю), компания может потерять настолько большой объем прибыли, что будет уже не в состоянии оплачивать счета и другие расходы. Это и будет являться отложенным ущербом. А если кроме всего прочего компания еще и потеряет доверие клиентов, она может полностью потерять свой бизнес (на некоторое время или навсегда). Это является крайним случаем отложенного ущерба. Такого рода вопросы существенно усложняют количественную оценку ущерба, но они обязательно должны быть приняты во внимание для получения достоверной оценки. 5.5. Анализ сбоев и дефектов FMEA (Failure Modes and Effect Analysis)– это метод определения функций, выявления функциональных дефектов, оценки причин дефекта и его последствий с помощью структурированного процесса. Применение этого процесса в случае постоянных дефектов позволяет определить место, где ошибка, скорее всего, произойдет. Это очень помогает выявить уязвимые места, точно определить границы уязвимостей и последствия их эксплуатации. В свою очередь, это позволяет не только упростить применение исправлений, устраняющих уязвимости, но и обеспечить более эффективное использование ресурсов в рамках этой задачи. Следуя определенной последовательности шагов, можно достичь наилучших результатов в анализе дефектов. 1. Начните с блок-схемы системы или контроля (объекта анализа). 2. Рассмотрите, что произойдет, если каждый блок диаграммы даст сбой. 3. Нарисуйте таблицу, и укажите в ней дефекты в паре с их последствиями и оценкой этих последствий. 4. Корректируйте проект системы и вносите соответствующие изменения в таблицу до тех пор, пока не станет ясно, что система не подвержена проблемам. 5. Получите несколько инженерных обзоров характера дефектов и анализа последствий. В таблице 3 приведен пример проведения и документирования FMEA. Хотя большинство компаний не имеют ресурсов для столь детальной проработки каждой системы и контроля, она должна проводиться для критичных функций и систем, которые могут оказать существенное влияние на компанию. Очень важно проанализировать защитную меру или систему от микро- до макро-уровня, чтобы в полной мере понять, где могут находиться потенциальные уязвимости или дефекты и каковы последствия эксплуатации этих недостатков. Каждая компьютерная система может состоять из множества различных временных бомб на разных уровнях ее структуры. На уровне компонентов это может быть переполнение буфера или опасные компоненты ActiveX, что может позволить злоумышленнику получить контроль над системой, воспользовавшись уязвимостью. На программном уровне приложение может небезопасно проводить авторизацию или может не защищать свои криптографические ключи должным образом. На системном уровне ядро операционной системы может иметь недостатки, что позволит 27 злоумышленнику без особого труда получить административный доступ. Различные ужасные вещи могут произойти на любом уровне, поэтому необходим столь детальный подход. Изначально FMEA была разработана для исследования систем. Ее цель заключается в том, чтобы изучить потенциальные дефекты в продуктах и связанных с ними процессах. Этот подход оказался успешным и был адаптирован для использования при оценке приоритетов в области управления рисками и минимизации известных угрозуязвимостей. Однако FMEA недостаточно эффективна при выявлении сложных дефектов, в которые могут быть вовлечены несколько различных систем или подсистем. В этом случае более целесообразно использовать анализ дерева сбоев (fault tree analysis). Для анализа с помощью дерева сбоев берется основной процесс. В качестве его корня (самого верхнего элемента этого логического дерева) указывается нежелательное событие. Затем, в качестве ветвей, добавляется ряд логических выражений и событий, которые могут привести к реализации вышестоящего нежелательного события. После этого дерево сбоев помечается цифрами, соответствующими вероятности сбоев (обычно это делается с помощью специализированных компьютерных программ, которые могут рассчитывать вероятности в дереве сбоев). На рисунке 7 показано упрощенное дерево сбоев и различные логические знаки, используемые для представления того, что должно произойти, чтобы вызвать сбой. Таблица 3 - Пример проведения и документирования FMEA Подготовлено: Согласовано: Дата: Версия: Идентификац ия элемента Функция Характер сбоя Причина сбоя Центральный сервер предприятия обновления антивирусных сигнатур Передает обновления сигнатур на серверы и рабочие станции Сбои не позволяют обеспечить адекватную и современную защиту от вредоносного кода Отключается центральный сервер Водяные трубы Тушение пожара в пяти зонах здания 1 Неисправности, приводят к неработоспособ ности Вода в трубах замерзнет Дефект воздействует на Последст Последст Последств вия вия на ия системы более высоком уровне Не Сеть Центральн обновляю заражает ый сервер тся ся может антивирус вредонос быть ы на ным заражен серверах кодом и/или и рабочих заражать станций другие системы Нет В здании 1 тушение пожара не производ ится Трубы системы пожаротуш ения ломаются Метод выявления сбоя Сообщение о текущем состоянии (работоспособ ность) отправляется на консоль и страницу сетевого администратор а Датчики системы пожаротушени я напрямую связываются с центральной консолью пожарной системы И т.д. 28 Рисунок 7. - Дерево сбоев и логические элементы При создании дерева, необходимо точно указать все угрозы или сбои, которые могут произойти с системой. Ветви дерева можно разделить на категории, например, физические угрозы, сетевые угрозы, компьютерные угрозы, интернет-угрозы и угрозы сбоя. Когда все возможные категории отмечены, вы можете подрезать ветви с дерева, удаляя угрозы, неприменимые в данном случае (если система не подключена к Интернету, то связанные с Интернетом ветви можно спокойно срезать с дерева). Некоторые из наиболее распространенных программных сбоев, которые могут быть исследованы с помощью анализа дерева сбоев, приведены ниже: • Ложные срабатывания (тревоги или защиты) • Недостаточная обработка ошибок • Нарушение последовательности или порядка • Некорректная синхронизация выдачи результатов • Корректные, но неожиданные результаты Итак, мы получили надлежащую поддержку руководства в рамках задачи по анализу рисков, создали группу анализа рисков из сотрудников различных подразделений компании, определили ценность каждого из активов компании, определили все возможные угрозы, которые могут повлиять на активы. Мы также приняли во внимание все возможные варианты отложенного ущерба, который может выдержать компания в отношении каждого актива и угрозы. Мы провели анализ сбоев и дефектов (или анализ дерева сбоев) для понимания причин, лежащих в основе выявленных угроз. Следующим шагом является расчет актуальных для компании рисков с использованием качественных и количественных методов. 5.6. Количественный анализ рисков Количественный анализ рисков пытается присвоить реальные и осмысленные числа всем элементам процесса анализа рисков. Этими элементами могут быть стоимость защитных мер, ценность актива, ущерб для бизнеса, частота возникновения угрозы, эффективность защитных мер, вероятность использования уязвимости и т.д. Количественный анализ рисков позволяет получить конкретное значение вероятности (в процентах) реализации угрозы. 29 Каждый элемент в процессе анализа вставляется в количественном виде в уравнение определения общего и остаточного риска. Нужно понимать, что количественный анализ рисков в чистом виде невозможен, так как всегда есть некоторая степень неопределенности в значении отдельных количественных величин (особенно если угрозы сложны, а частота их возникновения невелика). Например, как узнать насколько часто уязвимостью будут пользоваться? Или как узнать точную денежную сумму потерь компании? Даже если вы проанализировали все произошедшие ранее события, максимально точно определили ценность активов, обратились за информацией в организацию, которая оценивает частоту стихийных бедствий в вашей местности, вы все равно не сможете точно сказать, что для вашего дата-центра есть 10%ная вероятность пожара и что пожар приведет к ущербу ровно в $230,000. Будущее предсказать невозможно. Автоматизированные методы анализа рисков Сбор всех данных, которые необходимы для подстановки в уравнения анализа рисков и правильной интерпретации результатов, может быть крайне трудоемким, если он производится вручную. На рынке существует несколько автоматизированных средств анализа рисков, что может существенно упростить данную задачу и повысить точность результатов. Собранные данные могут использоваться повторно, что значительно сократит время проведения повторного анализа. Имеющиеся автоматизированные инструменты могут помочь также при подготовке отчетов и всевозможных графиков для руководства. Цель этих инструментов - сократить объем ручной работы, оперативно выполнять расчеты, оценивать ожидаемые потери, оценивать эффективность и преимущества выбранных контрмер. Шаги процесса анализа рисков. Шаг 1: Определить ценность активов. Для каждого актива необходимо ответить на следующие вопросы для определения его ценности: • В чем заключается ценность данного актива для компании? • Сколько стоит его поддержка? • Какую прибыль он приносит компании? • Сколько за него готовы заплатить конкуренты? • Сколько будет стоить его повторное создание или восстановление? • Сколько стоило его получить или разработать? • Какова мера ответственности в случае компрометации данного актива? Шаг 2: Оценить потенциальные потери от угрозы. Для оценки потенциальных потерь, необходимо ответить на следующие вопросы: • К каким физическим повреждениям может привести угроза и сколько это будет стоить? • Какую потерю продуктивности может вызвать угроза и сколько это будет стоить? • Какие потери понесет компания в случае разглашения конфиденциальной информации? • Какова стоимость восстановления после воздействия угрозы? • Какова стоимость потерь в случае неисправности критичных устройств? • Каков ожидаемый ущерб от единичного инцидента (SLE – Single Loss Expectancy) для каждого актива и каждой угрозы? Это только небольшой список вопросов, на которые необходимо получить ответы. Специфичные вопросы будут зависеть от типов угроз и выявленных группой особенностей. Шаг 3: Выполнить анализ угроз. Для анализа угроз нужно выполнить следующие действия: 30 • Собрать информацию о вероятности каждой угрозы, опросив сотрудников каждого подразделения, проанализировав произведенные ранее записи, а также официальные источники по безопасности, которые предоставляют такую информацию. • Рассчитать среднегодовую частоту возникновения инцидентов (ARO – Annualized Rate of Occurrence), которая показывает сколько инцидентов может произойти за год. Шаг 4: Определить общие годовые потери на угрозу. Для этого нужно выполнить следующее: • Объединить потенциальные потери и вероятность. • Рассчитать ожидаемый среднегодовой ущерб (ALE – Annualized Loss Expectancy) на угрозу, используя информацию, собранную на первых трех шагах. • Выбрать контрмеры для противодействия каждой угрозе. • Выполнить анализ затрат/выгод выбранных контрмер. Шаг 5: Уменьшить, перенести, избежать или принять риск. Для каждого риска необходимо выбрать меры по его снижению, переносу, либо принять его. • Методы снижения риска: • Внедрить защитные меры и средства управления; • Усовершенствовать процедуры; • Изменить окружение; • Внедрить методы раннего обнаружения для своевременного выявления факторов воздействия угрозы и снижения возможных последствий; • Разработать план действий в непредвиденных ситуациях, позволяющий продолжить работу в случае воздействия определенных угроз и снизить последствия от угрозы; • Создать препятствия для реализации угрозы; • Провести тренинг по вопросам безопасности. • Перенос риска– например, застраховать некоторые риски. • Избежание риска– прекратить деятельность, вызывающую риск. • Принятие риска – смириться с риском и не тратить деньги на защиту от него (это целесообразно, если стоимость защитных мер превышает величину возможного ущерба). Однако при этом нужно учитывать, что реализация риска может вести к дополнительным последствиям (например, потере репутации). Принятие риска. Если компания решает принять риск, это решение должно основываться на стоимости (стоимость контрмер превышает возможные потери) и приемлемом уровне риска (при котором компания может жить с уязвимостью или угрозой). Но компания должна также понимать, что это не полноценное решение. Реализация риска может нести также и ущерб репутации, причем не только репутации компании, но и репутации целой отрасли. При проведении количественного анализа рисков необходимы, реальные цифры и расчеты. Ранее уже были упомянуты показатели SLE (ущерб от единичного инцидента)и ALE (ожидаемый среднегодовой ущерб). SLE - это потенциальная сумма (в деньгах) ущерба для компании в результате единичного факта реализации соответствующей угрозы: Ценность актива х Фактор воздействия (EF - Exposure Factor) = SLE EF (фактор воздействия)– это процент ущерба для актива от реализовавшейся угрозы, т.е. часть значения (ценности), которую актив потеряет в результате инцидента. Например, ценность актива "хранилище данных" составляет $150,000. В случае пожара может быть повреждено 25% хранилища (но не более, так как установлена система пожаротушения, поблизости находится пожарная часть и т.д.). В этом случае SLE будет составлять $37,500. Значение SLE используется при расчете ALE: SLE х Среднегодовая частота возникновения инцидентов (ARO -Annualized Rate of Occurrence) = ALE 31 ARO (среднегодовая частота возникновения инцидентов)– это величина, представляющая собой ожидаемую частоту реализации соответствующей угрозы в год. Значение ARO может быть от 0,0 (никогда) до 1,0 (по крайней мере, раз в год) и выше (несколько раз в год). Например, наводнения в той местности, в которой расположено здание компании, происходят в среднем раз в 1000 лет. Значит величина ARO составляет 0,001. Таким образом, если SLE для хранилища данных компании при пожаре равно $37,500, а пожары в аналогичных условия случаются примерно раз в 10 лет (ARO равно 0,1), величина ALE будет равна $3,750 ($37,500 х 0,1 = $3,750). Значение ALE используется при оценке целесообразности внедрения тех или иных мер защиты соответствующего актива от соответствующей угрозы - годовая стоимость защитных мер, обеспечивающих необходимый уровень безопасности актива, не должна превышать значение ALE. Применение более дорогих защитных мер не будет эффективным и целесообразным. Рассмотрим пример результатов анализа рисков (Таблица 4). Используя полученные данные компания может принять обоснованное решение о том, какие угрозы необходимо рассматривать в первую очередь, основываясь на их последствиях и вероятности реализации. Также компания может оценить целесообразный уровень затрат на защиту от каждой угрозы. Актив Здание Коммерческая тайна Файловый сервер Данные Информация о кредитной карте клиента Угроза Пожар Хищение Неисправность Вирус Хищение Таблица 4 – Пример результатов анализа рисков SLE ARO ALE 230 000 0,1 23 000 40 000 0,01 400 11 500 0,1 1 150 6 500 300 000 1,0 3 6 500 900 000 Результаты анализа рисков Группа анализа рисков должна иметь четко определенные цели. Следующий список показывает, что в основном можно ожидать от результатов анализа рисков: • Ценность активов в денежном выражении; • Полный список всех возможных и существенных угроз; • Вероятная частота возникновения каждой угрозы; • Потенциальные потери компании от угроз, которые она может понести в 12-ти месячный срок; • Рекомендуемые меры безопасности, контрмеры и действия. Хотя данный список следует по возможности детализировать, следует сделать краткое резюме для руководства, на основании которого можно быстро сделать выводы о результатах анализа. 5.7. Качественный анализ рисков Другим методом анализа рисков является качественный метод, который не присваивает количественные или денежные значения компонентам и потерям, вместо этого он использует различные сценарии вероятности риска, уровней серьезности угроз и 32 обоснованности различных возможных контрмер. Для качественного анализа рисков применяются суждения, лучшие практики, интуиция и опыт. Примерами техник сбора данных для качественного анализа рисков являются: метод Delphi, мозговой штурм, работа с архивными документами, опросы целевых групп, анкетирование, чек-листы, личные встречи, интервью. Группа анализа рисков должна выбрать лучшую технику в зависимости от видов оцениваемых угроз, культуры компании, людей, вовлеченных в процесс анализа. В группу анализа рисков должны быть включены сотрудники, которые имеют опыт и образование в той области, в которой они будут оценивать угрозы. В процессе оценки угрозы и ущерба каждый член группы высказывает свою оценку, основываясь на своем предчувствии и опыте. Каждый член группы описывает приблизительный сценарий (не более страницы) для каждой существенной угрозы. Тот "эксперт", кто лучше всех разбирается в данном виде угроз, делает общий сценарий, описывающий процесс реализации угрозы. Затем оцениваются защитные меры, уменьшающие опасность этой угрозы, и описывается сценарий противодействия для каждой защитной меры. Возможное воздействие и возможный ущерб должны быть проранжированы по трех (высокий-средний-низкий), пяти или десятибалльной шкале. Уровни вероятности угрозы, потенциальных потерь и преимущества каждой защитной меры объединяются в отчет, который предоставляется руководству для принятия правильного решения. Преимущество данного метода анализа заключается в постоянном взаимодействии между всеми членами группы в процессах ранжирования рисков, определения сильных и слабых сторон защитных мер. Также преимуществом является подготовка окончательного отчета именно тем членом группы, который наиболее компетентен в соответствующей области. Рассмотрим простой пример качественного анализа рисков. Группа анализа рисков написала одностраничный сценарий, описывающий угрозу получения хакером доступа к конфиденциальной информации, хранящейся на файловых серверах компании. Группа распространяет этот сценарий между пятью сотрудниками (ИТ-директор, администратор базы данных, программист, системный инженер и руководители подразделения технической поддержки), которые заполняют лист оценки, ранжируя (от 1 до 5) серьезность угрозы, уровень потенциального ущерба, эффективность каждой защитной меры. Результаты показаны в Таблице 5. Затем на основе этих результатов один из членов группы готовит отчет для руководства, в котором указывает, что из проанализированных трех вариантов защиты (межсетевой экран, система IDS и honeypot (приманка)), наиболее эффективной является защита с помощью межсетевого экрана. Анализируя отчет по анализу рисков, руководство видит оценки серьезности угроз, вероятности их реализации, а также уровень потенциальных потерь от каждой угрозы. На основе этой информации руководство может выбрать наиболее критичные для компании риски, которые должны быть учтены в первую очередь. Таблица 5 - Пример качественного анализа рисков Угроза: Серьезн Вероятн Потенциал Эффективн Эффективн Эффективн Доступ ость ость ьный ость ость ость хакера к угрозы реализац ущерб для защиты с защиты с защиты с конфиденциа ии компании помощью помощью помощью льной угрозы межсетево IDS Honeypot информации го экрана ИТ-директор 4 2 4 4 3 2 Администрат 4 4 4 4 4 1 ор БД Программист 3 3 3 3 2 1 Системный 4 4 3 3 2 1 инженер 33 Руководитель тех. поддержки Итог: 5 4 4 4 4 2 3,6 3,4 3,8 3,8 3,0 1,4 Техника DELPHI Техника Delphi – это метод группового принятия решений, обеспечивающий получение от каждого члена его истинного мнения, не подверженного влиянию мнения других. Каждый член группы указывает свое мнение на листке бумаги, после чего все члены группы показывают свои листки для выполнения окончательного анализа. Результаты объединяются и распространяются между членами группы, которые пишут свои комментарии и возвращают их. Комментарии объединяются и снова распространяются до тех пор, пока не будет достигнут консенсус. Этот метод позволяет получить согласованное общее мнение по стоимости, уровню потерь, вероятности события без устного обсуждения. С использованием данной техники возможно проведение анонимных опросов. 5.8. Количественный или качественный Каждый метод имеет свои преимущества и недостатки. Некоторые из них приведены в Таблице 6. Критерием выбора могут быть особенности группы анализа рисков, мнение руководства, имеющиеся инструменты анализа рисков, культура компании. Целью обоих методов является оценка реальных рисков компании, их классификация по уровню серьезности угроз, что позволит выбрать правильные контрмеры в рамках имеющегося бюджета. 34 Таблица 6 – Характеристики количественного и качественного методов Атрибут Количественный Качественный Требует простых расчетов + Требует более сложных + расчетов Основывается в + значительной степени на предположениях Предоставляет основные + области и показатели риска Проще автоматизировать + Позволяет контролировать + эффективность управления рисками Предоставляет + заслуживающий доверия анализ стоимости/выгоды Использует независимо + проверяемые и объективные метрики Предоставляет мнения + людей, которые в совершенстве знают анализируемые процессы Четко показывает потери, + которые могут нарастать в течении года Недостатки качественного анализа: • Оценка и результаты в основном субъективны; • Обычно исключает возможность оценки денежной оценки затрат/выгод; • Сложно сопоставить цели управления рисками с субъективными оценками; • Нет стандартов. Каждый специалист имеет свою интерпретацию процесса и результатов. Недостатки количественного анализа: • Расчеты более сложны. Сложно объяснить руководству как эти значения были получены; • Процесс очень трудоемок без применения средств автоматизации; • Больше предварительной работы, связанной с получением детальной информации об окружении; • Нет стандартов. Каждый специалист имеет свою интерпретацию процесса и результатов. Уровень неопределенности– это степень неуверенности в оценке. Он измеряется от 0% до 100%. При проведении анализа следует указывать уровень неопределенности, так как это способствует лучшему пониманию результатов анализа. 5.9. Защитные механизмы Следующим шагом является идентификация доступных защитных механизмов (контрмер) и оценка их эффективности. Выбор защитных мер 35 Преимущества внедряемых защитных механизмов должны превышать затраты на них, только в этом случае они будут эффективными. Для проведения такой оценки используется анализ затрат/выгод. Обычно это считают следующим образом: (ALE до ввода защитных мер) – (ALE после ввода защитных мер) – (годовая стоимость защитных мер) = ценность защитных мер Например, ALE угрозы выведения веб-сервера из строя хакерами составляет $12,000 до внедрения соответствующих защитных мер, а после их внедрения ALE снижается до $3,000. При этом годовая стоимость функционирования и поддержки этих защитных мер - $650. В этом случае ценность защитных мер составляет $8,350 в год. Стоимость контрмер – это не просто цена их покупки. Нужно учитывать следующие элементы при расчете полной стоимости контрмер: • Стоимость продукта • Стоимость проектирования / планирования • Стоимость внедрения • Необходимость внесения изменений в окружение • Совместимость с другими контрмерами • Эксплуатационные требования • Тестирование • Стоимость восстановления, замены и обновления • Стоимость эксплуатации и поддержки • Влияние на производительность • Стоимость подписки • Работа сотрудников в нерабочее время и по выходным дням для мониторинга и реакции на сообщения об инцидентах ПРЕДУПРЕЖДЕНИЕ. Очень часто компании покупают новые продукты безопасности, не понимая, что им нужен дополнительный персонал на использование этих продуктов. Хотя инструменты автоматизируют задачи, многие компании ни разу не выполняли эти задачи перед покупкой, поэтому с помощью них они не сэкономят время, а наоборот начнут тратить его еще больше. Например, компания А решает защитить ряд своих ресурсов с помощью IDS, стоимостью $5,500. Эта IDS должна быть протестирована в отдельном тестовом сегменте сети, чтобы ИТ-службы убедились в безопасности ее ввода в промышленную эксплуатацию. После этого ИТ-службы должны установить и настроить сенсоры и программное обеспечение для мониторинга. Затем ИТ-службы должны перенастроить коммуникационное оборудование, направив все потоки трафика через IDS, а также ограничить доступ к консоли IDS, настроить базу данных сигнатур атак. Только после этого IDS можно включить в работу. При этом нужно учесть вероятное снижение производительности сети, возможные неудобства для пользователей, проявление "тонкостей", о которых "забыл" заранее сообщить поставщик, а также затраты времени и денег на обучение персонала, а затем затраты на реагирование на реальные и ложные срабатывания IDS. Кроме того, может возникнуть необходимость закупки средств оповещения администратора безопасности об инцидентах, выявленных IDS (например, отдельного смартфона), от которых будет зависеть время реакции на инциденты. Таким образом, изначальная цена увеличивается: $5,500 стоит сама система IDS, $2,500 стоит обучение персонала, $3,400 стоит тестирование системы, $2,600 - потери производительности пользователей, вызванные внедрением этой системы и еще $4,000 стоит перенастройка коммуникационного оборудования, установка IDS, выявление ошибок, установка патчей. Реальная стоимость этой защитной меры составит $18,000. Если при этом рассчитанная величина вероятного ущерба составляет только $9,000, применение этой IDS неэффективно и приведет к перерасходу адекватного бюджета на 100%. 36 Функциональность и эффективность защитных мер Группа анализа рисков должна оценить функциональность и эффективность защитных мер. При выборе защитных мер некоторые характеристики будут важнее, чем другие, которые должны быть тщательно проанализированы до покупки и внедрения средства обеспечения безопасности. Таблица 7. – Характеристики, которые следует учесть при выборе средств Характеристика Описание Модульная архитектура Система может быть установлена или удалена из окружения без неблагоприятного воздействия на другие механизмы. Обеспечивает стандартную защиту Стандартный уровень безопасности, обеспечивается стандартными настройками всех механизмов. Предоставляет возможность отмены Администратор может отменить функциональности ограничения при необходимости Минимальные привилегии по умолчанию После установки должны применяться настройки по умолчанию, не предусматривающие какие-либо разрешения и права, кроме заданных явно. Независимость средств защиты и Средства защиты могут быть использованы защищаемых активов для защиты различных активов, а различные активы, в свою очередь, могут быть защищены различными средствами. Гибкость и безопасность Должно быть представлено как можно больше функций безопасности, однако настройки при этом должны быть гибкими и позволять выбрать нужный набор функций (а не «все», либо «ничего»). Явное разделение «пользователя» и Пользователь должен иметь минимум «администратора» разрешений на изменение настроек или отключение механизмов защиты. Минимальное вмешательство человека Средства защиты должны предусматривать минимальное вмешательство человека, так как любые производимые вручную настройки и изменений с высокой степенью вероятности приводят к ошибки. Простота обновления Программное обеспечение продолжает развиваться, поэтому важно, чтобы обновления устанавливались безболезненно. Средства аудита Должен существовать механизм, являющийся неотъемлемой частью средства защиты, предоставляющий минимальный и/или подробный аудит событий. Минимальная зависимость от других Средства защиты должны быть гибкими и компонентов не предъявлять жестких требований к окружению, в которое они устанавливаются. Простота использования, незаметность для Средства защиты не должны снижать 37 персонала Исходящая информация (отчеты) должна предоставляться в простом и понятном виде Должна существовать возможность сброса настроек средства защиты Возможность тестирования Отсутствие компромиссов Производительность пользователей систем Качественная система оповещений Не должно оказываться влияние на активы и производительности работы, добавлять дополнительные шаги к простым задачам; пользователи не должны испытывать дискомфорт из-за их применения. Важная информация должна быть представлена в простой для человека форме, понятной и применимой для анализа изменений и тенденций. Средства защиты должны позволять сбросить настройки и вернуться к оригинальной конфигурации и настройкам, что не должно оказывать влияния на защищаемые системы и активы. Должна существовать возможность протестировать работу средств защиты в различном окружении и в различных ситуациях. Средства защиты не должны содержать скрытых каналов и потайных входов (back doors). Применение средства защиты не должно оказывать существенного влияния на производительность систем и пользователей. Порог срабатывания системы оповещения персонала об инцидентах безопасности должен быть настраиваемым, типы сообщений должны быть приемлемыми. Средства защиты не должны оказывать неблагоприятного воздействия на активы. Защитные средства могут также иметь сдерживающие атрибуты, говорящие потенциальному злоумышленнику, что здесь внедрена надежная защита и ему лучше поискать другую, более легкую цель. Однако здесь также следует соблюдать определенную степень осторожности и не предоставлять потенциальному злоумышленнику излишней информации о применяемых средствах защиты и методах их работы, так как это может позволить ему обойти их. Если пользователи знают, как отключить антивирусную программу, чтобы повысить производительность своего компьютера, или как обойти прокси-сервер, чтобы получить неограниченный доступ в Интернет, они будут делать это. 5.10. Обобщение Для проведения анализа рисков, компания сначала решает, какие активы нуждаются в защите и в какой степени. Указывается, какие суммы денежных средств могут быть потрачены на защиту данных активов. Далее, оценивается функциональность доступных средств защиты и определяются те, которые будут наиболее эффективны для компании. После этого, компания должна оценить и сопоставить расходы на защитные меры. Эти шаги позволят руководству принять разумное и осознанное решение о выборе и покупке контрмер. Необходимо учитывать, что только переоценивая риски на периодической основе можно обеспечить постоянную эффективность защитных мер и поддерживать уровень 38 рисков информационной безопасности на приемлемом уровне. Если риск не изменился и защитные меры внедрены и хорошо работают, значит риски снижены достаточно. Продолжение анализа уязвимостей и выявления нуждающихся в защите активов также является важной задачей управления рисками. 5.11. Общий риск и Остаточный риск Общий риск (total risk)- это риск, перед лицом которого стоит компания, не внедрившая никаких защитных мер. Если его уровень не приемлем для компании (вероятный ущерб от реализации риска превышает стоимость защитных мер), она внедряет защитные меры чтобы снизить общий риск до приемлемого уровня. Однако систем или сред, защищенных на 100%, не существует - всегда есть некоторый остаточный риск (residual risk). Необходимо обеспечить, чтобы уровень остаточного риска был приемлем для компании. Общий риск = угроза х уязвимость х ценность актива Остаточный риск = (угроза х уязвимость х ценность актива) х недостаток контроля Необходимо учитывать, что только переоценивая риски на периодической основе можно обеспечить постоянную эффективность защитных мер и поддерживать уровень рисков информационной безопасности на приемлемом уровне. Если риск не изменился и защитные меры внедрены и хорошо работают, значит, риски снижены достаточно. Продолжение анализа уязвимостей и выявления, нуждающихся в защите активов также является важной задачей управления рисками. 5.12. Обработка риска Когда компания рассчитала величину общего и остаточного риска, она должна принять решение о дальнейших действиях. Существует 4 варианта действий, которые можно предпринять в отношении риска: перенести, избежать, уменьшить или принять риск. Если общий или остаточный риск слишком высок для компании, она может купить страховку, чтобы перенести риск на страховую компанию. Если компания решает прекратить деятельность, которая вызывает риск, это называется исключением риска. Например, компания может запретить использование сотрудниками программ передачи мгновенных сообщений (IM – Instant Messenger), вместо того, чтобы бороться с множеством рисков, связанных с этой технологией. Другим подходом является снижение риска до уровня, считающегося приемлемым для компании. Примером может быть внедрение межсетевого экрана, проведение обучения сотрудников и т. д. И последний подход заключается в осознанном принятии риска компанией, которая осознает его уровень, размеры потенциального ущерба, и, тем не менее, решает жить с этим риском и не внедрять контрмеры. Для компании целесообразно принять риск, когда анализ затрат / выгоды показывает, что расходы на контрмеры превышают размеры потенциальных потерь. Ключевым вопросом при принятии риска является понимание того, почему это является наилучшим выходом из конкретной ситуации. К сожалению, в наше время многие ответственные лица в компаниях принимают риски, не понимая в полной мере, что они принимают. Обычно это связано с относительной новизной процессов управления рисками в области безопасности, недостаточным уровнем образования и опытом работы этих людей. Когда руководителям бизнес-подразделений вменяются обязанности по борьбе с рисками в их подразделениях, чаще всего они принимают любые риски, т.к. их реальные 39 цели связаны с производством компанией готовой продукции и выводом ее на рынок, а вовсе не с рисками. Они не хотят увязать в этой глупой, непонятной и раздражающей безопасности... Принятие риска должно быть основано на нескольких факторах. В частности, нужно ответить на следующие вопросы. Потенциальные потери меньше стоимости контрмер? Сможет ли компания жить с теми потерями, которые причинит ей принятие этого риска? Второй вопрос имеет отношение, в том числе и к бесплатным решениям. Например, если компания примет этот риск, она должна будет добавить еще три шага в свой производственный процесс. Имеет ли это смысл для нее? В другом случае, принятие риска может привести к возрастанию количества инцидентов безопасности – готовы ли компания справиться с этим? Человек или группа, принимающая риск, должны понимать потенциальные последствия этого решения. Предположим, было установлено, что компания не нуждается в защите имен клиентов, но она должна защищать другие сведения, такие как номера социального страхования, номера счетов и т.д. При этом ее деятельность останется в рамках действующего законодательства. Но что будет, если ее клиенты узнают что компания не защищает должным образом их имена? Ведь они из-за отсутствия знаний по этому вопросу могут подумать, что это может стать причиной «кражи личности», что приведет к серьезному удару по репутации компании, с которым она может и не справиться. Восприятие клиентов часто не обосновано, и всегда существует вероятность, что они перенесут свой бизнес в другую компанию, и вам нужно считаться с этой потенциальной возможностью. Рис. 8 показывает, как может быть создана программа управления рисками, которая объединяет все понятия, описанные в настоящем разделе. 40 Рис. 8. - Вариант программы управления рисками 6. Персонал Многие обязанности персонала имеют прямое отношение к безопасности компании. Хотя общество стало чрезвычайно зависимым от технологий, люди остаются ключевым фактором успеха компании. В безопасности чаще всего именно человек является слабейшим звеном. Это является следствием человеческих ошибок, недостатков в обучении и приводит к мошенничеству, несанкционированным или небезопасным действиям. Человек во многих случаях является причиной успеха хакерских атак, шпионажа, повреждения оборудования. Хотя будущие действия людей нельзя предсказать, можно внедрить определенные превентивные меры, которые помогут минимизировать риски. Такими превентивными мерами могут быть следующие: прием на работу только квалифицированного персонала, контрольные мероприятия, детальные должностные инструкции, обучение персонала, строгий контроль доступа, обеспечение безопасности при увольнении сотрудников. 6.1. Структура Если компания хочет иметь эффективную безопасность на уровне персонала, руководство должно внедрить четкую структуру и следовать ей. Эта структура включает в себя четкое 41 описание обязанностей, разграничение полномочий, ответственность (например, объявление выговоров) за определенные действия. Четкая структура исключает непонимание, кто и что должен делать в различных ситуациях. Есть несколько аспектов, которые должны быть внедрены для снижения возможностей для мошенничества, саботажа, краж, неправильного использования информации, а также уменьшения вероятности возникновения других проблем безопасности. Одним из таких аспектов является разделение обязанностей (separation of duties), которое гарантирует, что один человек не сможет самостоятельно выполнить критичную задачу. Разделение обязанностей также снижает вероятность ошибок – если один человек ошибся, другой, скорее всего, увидит ее и исправит. Разделение обязанностей снижает риски мошенничества, так как сотрудник не может выполнить самостоятельно критичную операцию и ему необходимо вступить в сговор с другим сотрудником, а вероятность сговора двух и более людей существенно ниже вероятности действий отдельного человека. При разработке программного обеспечения должно быть явное разделение между средой разработки, средой тестирования, библиотекой программного обеспечения и производственной средой. Программистам должна быть доступна только среда разработки, в которой они могут разрабатывать программное обеспечение и производить его предварительное тестирование. После разработки исходные тексты передаются другому человеку, который проводит контроль качества кода и тестирование его работы в отдельной среде, являющейся копией производственной среды. Только когда код прошел все необходимые тесты, он размещается в библиотеке программного обеспечения. Для внедрения в производственную среду, программное обеспечение берется только из библиотеки. Код ни в коем случае не должен попадать напрямую от программиста в производственную среду без тестирования и сохранения в библиотеке! Тестовая среда должна быть полностью отделена от производственной, чтобы непроверенное еще программное обеспечение не нанесло вреда данным и системам, находящимся в реальной работе. Программист не должен «латать» свои программы непосредственно в процессе их эксплуатации! Должны быть внедрены простые и эффективные методы, не позволяющие вносить изменения в программное обеспечение компании небезопасными способами. 7. Выводы Программа безопасности должна учитывать вопросы со стратегической, тактической и оперативной точки зрения, как показано на рис. 9. Управление безопасностью включает в себя административные и процедурные мероприятия, необходимые для поддержки и защиты информации, а также активов в рамках компании в целом. Кроме того, управление безопасностью включает в себя разработку и внедрение политик безопасности и их вспомогательных механизмов: процедур, стандартов, базисов и руководств. Также, оно включает в себя управление рисками, обучение по вопросам безопасности, выбор и внедрение эффективных контрмер. Деятельность, связанная с персоналом (прием на работу, увольнение, обучение и структура управления) и его функциями (ротация и разделение обязанностей), должна проводиться надлежащим образом в целях создания безопасных условий. Руководство должно уважать и соблюдать необходимые правовые и этические нормы. Безопасность – это задача бизнеса, она должна рассматриваться именно в этом качестве. Она должна быть интегрирована в бизнес-цели и задачи компании, так как вопросы безопасности могут негативно сказаться на тех ресурсах, от которых зависит компания. Все большее и большее количество компаний, не уделявших должного внимания, поддержки и финансирования безопасности, несут колоссальные убытки. Хотя мы живем в прекрасном и удивительном мире, в нем может случиться всякое. Те, кто понимает это, могут не только выживать, но и процветать. 42 Рис. 9 – Компоненты программы безопасности. 43 8. Основы обеспечения информационной безопасности компьютерных систем. Программные и аппаратные механизмы защиты Многие механизмы защиты могут быть реализованы как на программном, так и на аппаратном уровне, однако более стойкими считаются аппаратные реализации. Это связано со следующими причинами: Целостность программной защиты легко нарушить, это дает возможность злоумышленнику изменить алгоритм функционирования защиты необходимым образом, например, заставить процедуру контроля электронно-цифровой подписи всегда выдавать верные результаты. Нарушить целостность аппаратных реализаций зачастую невозможно в принципе в силу технологии их производства. Стоимость аппаратных средств защиты во многом повышается благодаря сокрытию защитных механизмов на аппаратном уровне, злоумышленник при этом не может их исследовать в отличие от программной защиты. 9. Защита от изменения и контроль целостности программного обеспечения 9.1. Защита программного обеспечения от несанкционированного использования Включает в себя: 1. Организационно-правовые меры. 2. Правовые меры (распространение на программное обеспечение авторского права). 3. Технические меры. 9.2. Модульная архитектура технических средств защиты ПО от несанкционированного копирования Особенностью всех технических мер защиты является то, xто их реализация построена на выделении, либо принудительном введении каких – либо идентифицирующих элементов в среде функционирования программы, на которые настраивается система защиты. В качестве таких характеристик среды может быть использованы серийный номер, ключевой файл, информация в реестре, в конфигурации файлов, конфигурация аппаратуры, физический дефект носителей информации. Основные требования к системе защиты ПО от несанкционированного копирования: 1. такая система должна достоверно выявлять факт несанкционированного использования программы 2. реагировать на факт несанкционированного использования 3. противодействовать возможным атакам, направленным на нейтрализацию защитных механизмов 44 Рис. 10 – Структура системы защиты ПО Система защиты ПО от несанкционированного копирования работает по следующему алгоритму: 1. разработчик ПО разрабатывает и внедряет защитные механизмы в исполнительную программу 2. в эти защитные механизмы закладываются эталонные характеристики среды, которые идентифицируют конкретную копию программы и относительно которой будет проверяться легальность запуска 3. при каждом запуске программы выполняются следующие действия: снимают текущие характеристики среды, они сравниваются с эталонными. Если сравнение дало положительный результат, то запуск программы считается санкционированным. Программа запуска продолжает работать. Если сравнение дало отрицательный результат, то запускается блок ответной реакции. За установку текущих характеристик среды отвечает блок ответной реакции. Выход этого блока поступает на блок сравнения характеристик среды, который сравнивает текущие характеристики среды с эталонными. По способу внедрения защитного кода в защищаемую программу различают встроенную и пристыковочную защиты. Встроенные механизмы защиты основываются на том, что система как самостоятельный программный модуль отсутствует. Эти механизмы защиты внедряет сам разработчик в исходный текст программы, используя, например набор готовых APIфункций защиты. Преимущества: 1. Простота. С помощью библиотек и функций, поставляется совместно с ПА средствами защиты, от ПА средства можно добиться максимальной эффективности 2. при реализации встроенной защиты, разработчик может запрограммировать любую ответную реакцию программы на несовпадение характеристик с эталонными, что в свою очередь позволяет более хорошо реализовать маркетинговые функции. Например, 45 при отсутствии электронного ключа, может запускать программу в демонстрационном режиме. 3. защита производится не по детерминированному алгоритму. Разработчик сам определяет, когда и каким образом будут вызываться API-функции с ПА устройствами защиты, как будут обрабатываться возвращаемые ими результаты. Недостаток: сложная реализация. Модуль противодействия нейтрализации защитных механизмов затрудняет анализ злоумышленником защитного кода, противодействует вмешательству в его работу и выполняется по 2 направлениям: 1) статическое 2) динамическое При статической нейтрализации злоумышленник дизассемблирует программу с помощью таких средств, как Ida Pro, по полученному коду, разбирается с работой механизмов, как их грамотно отключить. При динамической нейтрализации вмешательство в работу программы производится в момент работы в реальном времени с помощью существующих средств отладки, например, Soft Ice. Пристыковочные механизмы защиты внедряются непосредственно в исполнительный код, реализуется непосредственно некого автоматического обработчика исполнительных файлов. Эти обработчики заключают исполнительный код программы в некую защитную оболочку, которой при старте программы передается управление. При старте программы запускается защитная оболочка, реализующая все защитные функции, проверки, по результатам которых принимается решение о запуске/незапуске программы. Они поставляются в виде неких wizad-ов. При использовании подобных wizard-ов от пользователя требуется минимум действий, например, указать программу, требующую защиту и способ защиты. 9.3. Защита программного обеспечения от исследования Исследование исполняемого кода программы позволяет злоумышленнику разобраться с логикой работы защитных механизмов, что дает возможность отключить их либо обойти. При работе с аппаратными средствами защиты в исполняемом коде программы достаточно часто хранится конфиденциальная информация, например, коды доступа к электронному ключу, который не должен знать злоумышленник. Иначе говоря, возможность исследования кода является необходимым условием взлома программных продуктов. В связи с этим исполняемый код необходимо защищать от исследования. Для защиты ПО от исследования необходимо обеспечить защиту от статического и динамического анализа. В первом случае злоумышленник пытается получить листинг программы на какомлибо языке для возможности дальнейшего изучения и исследования логики защитных механизмов с использованием таких средств как Ida Pro, Soucer. Большая часть средств защиты от отладки основывается на обнаружении отладчиков в оперативной памяти с целью дальнейшего противодействия отладке, либо на включенных в исполняемый код механизмов, которые не могут быть корректно выполнены под отладкой в режиме трассировки. 9.4. Классификация средств атаки на средства защиты программного обеспечения 46 Программы-каталогизаторы Программы поиска данных и файлов Мониторы файловой системы Мониторы портов ввода/вывода, сетевой активности Мониторы активных окон и задач Программы-распаковщики и дешифраторы Средства дизассемблирования Декомпиляторы Отладчики Средства эмуляции процессора Программы копирования областей оперативной памяти на внешние устройства Средства поиска и замены данных Средства редактирования ресурсов Средства динамической модификации Симуляторы аппаратных средств Средства модификации контекстных процессов Средства криптоанализа Средства перехвата клавиатурного ввода Средства восстановления удаленных файлов Программы побайтового копирования дисков Эмуляторы ОС (виртуальные машины) Средства пакетной обработки команд Средства генерации паролей и ключей Программы-каталогизаторы – оболочки файловых систем, например, Far, Total Commander. С помощью данных средств возможно: - выполнить сравнение дат создания файлов в каталоге, в котором установлено приложение. Если средства защиты используют какие-то файлы для хранения, например, информации об оставшемся количестве запусков, то ее дата будет отличаться от остальных. Программы поиска файлов и текстовых последовательностей: HIEW, позволяющие искать в прикладных программах и файлах данных требуемые последовательности. Злоумышленник, таким образом, может локализовать участки кода, ответственные за выполнение функций по безопасности. Мониторы файловых операций (FileMon, RegMon, PortMon). Данные средства позволяют злоумышленнику проанализировать активность программы, «общение» программы с файлами, реестром, устройствами через порты ввода/вывода. 47 Мониторы вызова подпрограмм и системных функций (Spy++). С помощью данных средств можно определить, какие API-функции используются разработчиком для вызова решения определенных задач. Программы копирования областей устройства (Advanced Memory Dumper). оперативной памяти на внешние Средства декомпиляции (Cordon swf) представляют собой средства статического анализа исполняемого кода для изучения исходных текстов программ. Хорошо работают для Basic, Flash. Средства редактирования ресурсов (Passolo, Resource Hacker). Средства программы эмуляции аппаратных средств (Virtual CD). Средства эмуляции ЦП и ОС (VM Wave) 9.5. Сертификация программного обеспечения по уровню контроля отсутствия НДВ Программное обеспечение, системы защиты, которые работают с конфиденциальной информацией, либо с информацией, составляющей государственную тайну, должно пройти проверки на наличие в них НДВ. Под НДВ понимается функциональная возможность ПО, не описанная в документации, либо не соответствующая описанным в документации., которая может привести к нарушению конфиденциальности, целостности, доступности информации. Проверка ПО на наличие НДВ осуществляется согласно РД ФСТЭК 1998 г. «Защита от НСД. Часть 1. ПО средств защиты. Классификация по уровню контроля отсутствия НДВ». Согласно этому РД выделяется 4 уровня контроля, 1-высокий, 4 – низкий. 1 – системы, обрабатывающее информацию «Особой Важности» 2 - системы, обрабатывающее информацию «Совершенно Секретно» 3- системы, обрабатывающее информацию «Секретно» 4 - системы, обрабатывающее конфиденциальную информацию. № 1 1.1 1.2 1.3 1.4 1.5 2 3 3.1 3.2 4 Уровень контроля 3 2 1 + + + + = = = + = = = = = = = = = = = + = = = + + + = + = = + Наименование требования Требования к документации Контроль состава и содержания документации Спецификация (ГОСТ 19.202-78) Описание программы (ГОСТ 19.402-78) Описание применения (ГОСТ 19.502-78) Пояснительная записка (ГОСТ 19.404-79) Тексты программ, входящих в состав ПО (ГОСТ 19.401-78) Требования к содержанию испытаний Контроль исходного состояния ПО Статический анализ исходных текстов программ Контроль полноты и отсутствия избыточности исходных текстов Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду 48 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4.1 4.2 5 Контроль связей функциональных объектов по управлению Контроль связей функциональных объектов по информации Контроль информационных объектов Контроль наличия заданных конструкций в исходных текстах Формирование перечня маршрутов выполнения функциональных объектов Анализ критических маршрутов выполнения функциональных объектов Анализ алгоритма работы функциональных объектов на основе блок-схем, диаграмм и т.п., построенных по исходным текстам контролируемого ПО Динамический анализ исходных текстов программ Контроль выполнения функциональных объектов Сопоставление фактических маршрутов выполнения функциональных объектов и маршрутов, построенных в процессе проведения статического анализа Отчётность - + = = - + = = - + - = + = + - + + = - - + = - - + = - + + + + = = + + + + Для программного обеспечения импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям, указанных в ГОСТ. Контроль состава документации проводится группой экспертов путем сравнения перечня представленных документов с требованиями руководящего документа для заявленного уровня контроля. При этом проверяется наличие обязательных (в соответствии с ГОСТ) разделов в представленных документах (полное соответствие ГОСТам не обязательно, однако, содержание должно им соответствовать. В частности, это имеет смысл для ПО импортного производства, где понятие ГОСТов не так осмысленно. Эти проверки не автоматизируются). Контроль содержания документации осуществляется, как по соответствию формальным требованиям ГОСТ к содержанию составных частей документов, так и по соответствию реальным возможностям программного обеспечения. На основании проведенного контроля делается вывод о соответствии документации требованиям руководящего документа и о возможности ее использования в процессе эксплуатации программного обеспечения. Контроль исходного состояния программного обеспечения. Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведёнными в документации. Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО. Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО. Проверенное программное обеспечение фиксируется – т.е. со всех модулей снимаются контрольные суммы. 49 Для представленных загрузочных модулей исходных текстов контрольное суммирование должно осуществляться с использованием программного обеспечения фиксации и контроля исходного состояния. Результаты контрольного суммирования оформляются в виде отчетов, являющихся приложением к протоколу испытаний. Статический анализ исходных текстов программ Статический анализ исходных текстов программ должен включать следующие технологические операции:  контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;  контроль соответствия исходных текстов ПО его объектному (загрузочному) коду. 1. Контроль полноты и отсутствия избыточности Полнота представленных исходных текстов ПО подтверждается фактом успешной компиляции и сборки исследуемого программного обеспечения с учетом результатов контроля соответствия исходных текстов загрузочному коду. Для проверки полноты специальных средств автоматизации не требуется – достаточно факта успешной компиляции. Для контроля избыточности исходных текстов на уровне файлов, с помощью анализатора исходных текстов определить список файлов, составляющих ПО и на основе анализа полученных исходных данных определить избыточные файлы, проанализировать их назначение и обоснованность включения в состав программного обеспечения. 2. Контроль соответствия исходных текстов программного обеспечения Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду осуществляется методом создания загрузочных модулей из представленных исходных текстов ПО, и их сравнением полученных модулей с модулями, входящими в состав дистрибутива. Берутся предоставленные исходные тексты (*) и производится их контрольная сборка – т.е. они компилируется и полученные модули сравниваются по контрольным суммам с модулями зафиксированного ПО (см. пункт 2) В случае отсутствия исходных текстов используются два подхода: 1. С восстановлением исходных текстов:  дизассемблирование;  статический анализ;  динамический анализ;  с использованием отладчиков;  с использованием датчиков (датчики встраиваются в исходный текст, из которого потом заново собирается программный продукт, который подвергается тестированию). При использовании данного подхода, возможно, потребуется итеративное дизассемблирование – с постепенными уточнениями. 2. Без восстановления исходных текстов – использование эмуляторов Для контрольной сборки, помимо собственно исходных файлов, желательно иметь и среду сборки (т.е. все компиляторы и компоновщики, которые использовал разработчик – иначе, при полностью самостоятельной сборке в лаборатории, расхождения по контрольным суммам почти гарантированно (т.е. собранные модули будут отличаться от модулей зафиксированного ПО). Наилучший вариант – когда контрольная сборка 50 производится либо на стенде разработчика (один или несколько компьютеров необходимых для cборки ПО, предоставляемые разработчиком и полностью готовые к сборке ПО), либо непосредственно у разработчика. Последовательность действий при выполнении трансляции исходных текстов, версия транслятора, а также исходные данные (директивы) для транслятора должны соответствовать приведённым в сопроводительной документации. Автоматизация здесь подразумевается на уровне командных файлов для сборки или автоматизации, предусмотренной в самих средствах сборки. 3.2.4. Отчётность По окончании испытаний оформляется отчёт (протокол), содержащий результаты:  контроля исходного состояния программного обеспечения;  контроля полноты и отсутствия избыточности исходных контролируемого программного обеспечения на уровне файлов; текстов  контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду. 3.3. Требования к третьему уровню контроля 3.3.1. Контроль состава и содержания документации Требования полностью включают в себя аналогичные требования к четвертому уровню контроля. Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.40479), содержащая основные сведения о назначении компонентов, входящих в состав программного обеспечения, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п. 3.3.2. Контроль исходного состояния программного обеспечения Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля. 3.3.3. Статический анализ исходных текстов программ Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:  контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);  контроль связей функциональных объектов (модулей, процедур, функций) по управлению;  контроль связей функциональных объектов (модулей, процедур, функций) по информации;  контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);  формирование перечня маршрутов выполнения функциональных объектов (процедур, функций). Перечень типовых дефектов программного обеспечения Рассмотрим перечень типовых дефектов программного обеспечения. 1. Неполная проверка параметров и разброса переменных; нестрогий контроль границ их изменений. 51 2. Скрытое использование приоритетных данных. 3. Асинхронное изменение интервала между временем проверки и временем использования. 4. Неправильное преобразование в последовательную форму. 5. Неправильные идентификация, верификация, аутентификация и санкционирование задач. 6. Отказ предотвращения перехода за установленные в программе пределы доступа и полномочий. 7. Логические ошибки (например, больше логических выражений или результатов, чем операций перехода). 8. Незавершённые разработка и описание. 9. Недокументированные передачи управления. 10. Обход контроля или неправильные точки контроля. 11. Неправильное присвоение имен, использование псевдонимов. 12. Неполная инкапсуляция или неполное скрытие описания реализации объекта. 13. Подменяемые контрольные журналы. 14. Передача управления в середине процесса. 15. Скрытые и недокументированные вызовы из прикладных программ, команд ОС и аппаратных команд. 16. Не устранение остаточных данных или отсутствие их адекватной защиты. 17. Неправильное освобождение ресурсов. 18. Игнорирование отключения внешних приборов. 19. Неполное прерывание выполнения программ. 20. Использование параметров ОС в прикладном пространстве памяти. 21. Не удаление средств отладки до начала эксплуатации. Формы проявления программных дефектов. (Вариант 1) 1. Выполнение арифметических операций и стандартных функций:  деление на 0;  переполнение разрядной сетки;  отличие результатов арифметических операций от ожидаемых;  обращение к стандартным функциям с недопустимыми значениями параметров. 2. Ошибки, связанные с затиранием команд и переменных. 3. Ошибки управления:  зацикливание – бесконечное повторение одной и той же части программы;  последовательность прохождения участков программы не соответствует ожидаемому;  потеря управления, приводящая к ошибкам разного рода (обращение к запрещенной области памяти, попытка выполнить запрещенную программу или «не команду». 4. Ошибки ввода-вывода:  «странный» вывод (на печать, на монитор и т.д.);  сообщения об ошибках от системных программ ввода-вывода. (Вариант 2) 1. Ошибки, приводящие к прекращению выполнения основных или части функций управляющей системы на длительное и или неопределенное время:  зацикливание, то есть последовательная повторяющаяся реализация определенной группы команд, не прекращающаяся без внешнего вмешательства;  останов и прекращение решения функциональных задач; 52  значительное искажение или потеря накопленной информации о текущем состоянии управляемого процесса;  прекращение или значительное снижение темпа решения некоторых задач вследствие перегрузки ЭВМ по пропускной способности;  искажение процессов взаимного прерывания подпрограмм, приводящее к блокировке возможности некоторых типов прерываний. 2. Ошибки, кратковременно, но значительно искажающие отдельные результаты, выдаваемые управляющим алгоритмом:  пропуск подпрограмм или их существенных частей;  выход на подпрограммы или их части, резко искажающиеся результаты;  обработка ложных или сильно искаженных сообщений. 3. Ошибки, мало и кратковременно влияющие на результаты, выдаваемые управляющим алгоритмом. Этот тип ошибок характерен, в основном, для квазинепрерывных величин, в которых возможны небольшие отклонения результатов за счёт ошибок. Эти ошибки в среднем мало искажают общие результаты, однако отдельные выбросы могут сильно влиять на процесс управления и требуется достаточно эффективная защита от таких редких значительных выбросов. Системные вопросы защиты программ и данных. 9.6. Защита сетей от программных закладок. Воздействие программных закладок на компьютеры. Закладкой (или программной закладкой) в информационной безопасности называют скрытно внедренную в защищенную систему программу, либо намеренно измененный фрагмент программы, которая позволяет злоумышленнику осуществить несанкционированный доступ к ресурсам системы на основе изменения свойств системы защиты. Часто программные закладки выполняют роль перехватчиков паролей, трафика, а также служат в качестве проводников для компьютерных вирусов. Программные закладки невозможно обнаружить при помощи стандартных антивирусных средств, их выявление возможно только специальными тестовыми программами. Данные программы доступны в специализированных компаниях, которые занимаются сертификацией и стандартизацией компьютерного программного обеспечения. Защита от программных закладок осуществляется в следующих вариантах:  защита от внедрения закладки в систему; Защита от внедрения программных закладок в большинстве случаев осуществляется путем создания изолированного персонального компьютера, защищенного от проникновения программных закладок извне. Для того, чтобы считаться изолированным, компьютер должен удовлетворять следующим условиям: - BIOS не должен содержать программных закладок; - установленная операционная система должна быть проверена на наличие программных закладок; - должна быть установлена неизменность BIOS и операционной системы; - на персональном компьютере не должны были запускаться и не запускаются программы, которые не прошли проверку на наличие в них программных закладок; - должен быть исключен запуск проверенных программ вне персонального компьютера.  выявление внедренной закладки; Выявление внедренных программных закладок осуществляется путем обнаружения признаков их присутствия в системе, которые делятся на: - качественные и визуальные; - обнаруживаемые средствами диагностики. 53 К качественным и визуальным относят признаки, которые могут быть идентифицированы пользователем во время работы с системой. Это могут быть как отклонения от привычной работы системы, так и изменения в пользовательских и системных файлах. Наличие данных признаков свидетельствует о необходимости проведения проверки на наличие программных закладок в системе. Признаки, обнаруживаемые средствами диагностики, идентифицируются специальным тестовым программным обеспечением, сигнализирующим о наличии вредоносного программного кода в системе.  удаление внедренной закладки. Модели воздействия программных закладок на компьютеры: Метод удаления внедренных программных закладок зависит от метода их внедрения в систему. При обнаружении программно-аппаратной закладки необходимо перепрограммировать ПЗУ компьютера. При обнаружении загрузочной, драйверной, прикладной, замаскированной закладки или закладки-имитатора необходимо произвести их замену на соответствующее программное обеспечение от доверенных источников. При обнаружении исполняемой закладки следует убрать текст закладки из исходного текста программного модуля и откомпилировать модуль заново. Перехват. В модели перехват программная закладка внедряется в ПЗУ, системное или прикладное программное обеспечение и сохраняет всю или выбранную информацию, вводимую с внешних устройств компьютерной системы или выводимую на эти устройства, в скрытой области памяти локальной или удаленной компьютерной системы. Объектом сохранения, например, могут служить символы, введенные с клавиатуры (все повторяемые два раза последовательности символов), или электронные документы, распечатываемые на принтере. Данная модель может быть двухступенчатой. На первом этапе сохраняются только, например, имена или начала файлов. На втором накопленные данные анализируются злоумышленником с целью принятия решения о конкретных объектах дальнейшей атаки. Искажение. В модели искажение программная закладка изменяет информацию, которая записывается в память компьютерной системы в результате работы программ, либо подавляет/инициирует возникновение ошибочных ситуаций в компьютерной системе. Можно выделить статическое и динамическое искажение. Статическое искажение происходит всего один раз. При этом модифицируются параметры программной среды компьютерной системы, чтобы впоследствии в ней выполнялись нужные злоумышленнику действия. Динамическое искажение заключается в изменении каких-либо параметров системных или прикладных процессов при помощи заранее активизированных закладок. Динамическое искажение можно условно разделить так: искажение на входе (когда на обработку попадает уже искаженный документ) и искажение на выходе (когда искажается информация, отображаемая для восприятия человеком, или предназначенная для работы других программ). В рамках модели "искажение" также реализуются программные закладки, действие которых основывается на инициировании или подавлении сигнала о возникновении ошибочных ситуаций в компьютерной системе, т. е. тех, которые приводят к отличному от нормального завершению исполняемой программы (предписанного соответствующей документацией). Уборка мусора. Как известно, при хранении компьютерных данных на внешних носителях прямого доступа выделяется несколько уровней иерархии: сектора, кластеры и файлы. Сектора являются единицами хранения информации на аппаратном i уровне. Кластеры состоят из одного или нескольких подряд идущих секторов. Файл — это множество кластеров, связанных по определенному закону. 54 Работа с конфиденциальными электронными документами обычно сводится к последовательности следующих манипуляций с файлами:  создание;  хранение;  коррекция;  уничтожение. Для защиты конфиденциальной информации обычно используется шифрование. Основная угроза исходит отнюдь не от использования нестойких алгоритмов шифрования и "плохих" криптографических ключей (как это может показаться на первый взгляд), а от обыкновенных текстовых редакторов и баз данных, применяемых для создания и коррекции конфиденциальных документов. Дело в том, что подобные программные средства, как правило, в процессе функционирования создают в оперативной или внешней памяти компьютерной системы временные копии документов, с которыми они работают Естественно, все эти временные файлы выпадают из поля зрения любых программ шифрования и могут быть использованы злоумышленником для того, чтобы составить представление о содержании хранимых в зашифрованном виде конфиденциальных документов. Важно помнить и о том, что при записи отредактированной информации меньшего объема в тот же файл, где хранилась исходная информация до начала сеанса ее редактирования, образуются так называемые "хвостовые" кластеры, в которых эта исходная информация полностью сохраняется. И тогда "хвостовые" кластеры не только не подвергаются воздействию программ шифрования, но и остаются незатронутыми даже средствами гарантированного стирания информации. Конечно, рано или поздно информация и: "хвостовых" кластеров затирается данными из других файлов, однако по оценкам специалистов из "хвостовых" кластеров через сутки можно извлечь до 85%, а через десять суток — до 25—40% исходной информации. Наблюдение и компрометация. Помимо перечисленных, существуют и другие модели воздействия программных закладок на компьютеры. В частности, при использовании модели типа наблюдение программная закладка встраивается в сетевое или телекоммуникационное программное обеспечение. Пользуясь тем, что подобное программное обеспечение всегда находится в состоянии активности, внедренная в него программная закладка может следить за всеми процессами обработки информации в компьютерной системе, а также осуществлять установку и удаление других программных закладок. Модель типа компрометация позволяет получать доступ к информации, перехваченной другими программными закладками. Например, инициируется постоянное обращение к такой информации, приводящее к росту соотношения сигнал/шум. А это, в свою очередь, значительно облегчает перехват побочных излучений данной компьютерной системы и позволяет эффективно выделять сигналы, сгенерированные закладкой типа "компрометация", из общего фона излучения, исходящего от оборудования. 55 10. Парольные подсистемы аутентификации Реализуются в открытых компьютерных системах. Являются наиболее распространенными. В качестве идентификации используется Login (имя пользователя), в качестве аутентификации – секретный пароль. Преимущества: дешевизна, возможность использовать во всех компьютерных системах. Недостаток: самые уязвимые ко взлому: - перебор пароля в интерактивном режиме; - подсмотр, кража из общедоступного места; - возможность преднамеренной передачи пароля другому лицу; - кража БД учетных записей из общедоступного места; - перехват вводимого пароля путем внедрения в КС программных закладок; - перехват паролей передаваемых по сети; - возможность применения социального инжиниринга. Большинство минусов, свойственных парольным системам, связано с наличием человеческого фактора, который проявляется в том, что пользователи склонны выбирать легкозапоминаемые пароли, а сложнозапоминаемые стараются где-то записать. Для уменьшения влияния человеческого фактора требуется реализовать ряд требований к подсистеме парольной аутентификации. Требования: 1. задавание минимальной длины пароля для затруднения перебора паролей в лоб; 2. использование для составления пароля различных групп символов для усложнения перебора; 3. проверка и отбраковка паролей по словарю; 4. установка максимальных и минимальных сроков действия паролей; 5. применения эвристических алгоритмов, бракующих нехорошие пароли; 6. определение попыток ввода паролей; 7. использование задержек при вводе неправильных паролей; 8. поддержка режима принудительной смены пароля; 9. запрет на выбор паролей самим пользователем и назначение паролей администратором, формирование паролей с помощью автоматических генераторов стойких паролей. Количественная оценка стойкости парольной защиты А – мощность алфавита символов, из которых состоит пароль; L – длина пароля; V – скорость перебора паролей злоумышленником; T – срок действия паролей; P – вероятность подбора паролей злоумышленником за время t, меньшее срока действия паролей 10.1. Хранение аутентифицирующей информации в открытых компьютерных системах. При работе с открытыми КС необходимо обеспечить защиту аутентифицирующей информации, хранимой в КС. В открытых КС часто отсутствуют внешние максимально защищенные от НСД устройства, хранящие аутентифицирующую информацию, и данную информацию, используемую для аутентификации, приходится хранить в реальном объекте файловой системы – базе данных аутентификации (БДА). 56 Эту информацию необходимо защищать от 2 основных видов угроз: - угроза непосредственного доступа злоумышленника к БД аутентификации с целью ее копирования, модификации, удаления; - угроза несанкционированного изучения БД аутентификации. Защита от первого вида угрозы реализуется, как правило, на уровне ядра ОС путем ограничения доступа к той БД аутентификации всех субъектов, за исключением привилегированных. Либо защита от данного вида угроз реализуется путем определения дискреционной политики безопасности. Однако, как правило, способы защиты от угроз первого вида не работают корректно и их можно обойти, используя существующие уязвимости. Поэтому при защите БДА большее внимание уделяется защите от несанкционированного исследования их содержимого. Методы: 1). Шифрование Такой подход к закрытию содержимого БД аутентификации не является стойким, так как: 1. Шифрование должно быть на ключах, которые необходимо хранить. Хранение в операционной системе недопустимо. 2. При аутентификации пользователя необходимо расшифровать пароль, тем самым нарушить его секретность. Такой способ также уязвим к атакам, например, к атакам, заключенным в пошаговом исследовании процесса аутентификации с помощью известных отладчиков. 2). Хэширование. 11. Программно-аппаратные средства шифрования. 11.1 Основные термины и классификация средств криптографической защиты информации К средствам криптографической защиты информации (СКЗИ), относятся аппаратные, программно-аппаратные и программные средства, реализующие криптографические алгоритмы преобразования информации. Предполагается, что СКЗИ используются в некоторой компьютерной системе (в ряде источников - информационно-телекоммуникационной системе или сети связи), совместно с механизмами реализации и гарантирования некоторой политики безопасности. Наряду с термином "средство криптографической защиты информации" часто используется термин шифратор - аппарат или программа, реализующая алгоритм шифрования. Введенное понятие СКЗИ включает в себя шифратор, но в целом является более широким. Первые операционные системы (ОС) для персональных компьютеров (MS-DOS и Windows версий до 3.1 включительно) вовсе не имели собственных средств защиты, что и породило проблему создания дополнительных средств защиты. Актуальность этой проблемы практически не уменьшилась с появлением более мощных ОС с развитыми подсистемами защиты. Это обусловлено тем, что большинство систем не способны защитить данные, находящиеся за ее пределами, например, при использовании сетевого информационного обмена. Средства криптографической защиты информации, обеспечивающие повышенный уровень защиты можно разбить на пять основных групп. 57 Первую группу образуют системы идентификации и аутентификации пользователей. Такие системы применяются для ограничения доступа случайных и незаконных пользователей к ресурсам компьютерной системы. Общий алгоритм работы этих систем заключается в том, чтобы получить от пользователя информацию, удостоверяющую его личность, проверить ее подлинность и затем предоставить (или не предоставить) этому пользователю возможность работы с системой. Вторую группу средств, обеспечивающих повышенный уровень защиты, составляют системы шифрования дисковых данных. Основная задача, решаемая такими системами, состоит в защите от несанкционированного использования данных, расположенных на дисковых носителях. Обеспечение конфиденциальности данных, располагаемых на дисковых носителях, обычно осуществляется путем их шифрования с использованием симметричных алгоритмов шифрования. Основным классификационным признаком для комплексов шифрования служит уровень их встраивания в компьютерную систему. Системы шифрования данных могут осуществлять криптографические преобразования данных:   на уровне файлов (защищаются отдельные файлы); на уровне дисков (защищаются диски целиком). Другим классификационным признаком систем шифрования дисковых данных является способ их функционирования. По способу функционирования системы шифрования дисковых данных делят на два класса:   системы “прозрачного” шифрования; системы, специально вызываемые для осуществления шифрования. Системы второго класса обычно представляют собой утилиты, которые необходимо специально вызывать для выполнения шифрования. К ним относятся, например, архиваторы со встроенными средствами парольной защиты. К третьей группе средств, обеспечивающих повышенный уровень защиты, относятся системы шифрования данных, передаваемых по компьютерным сетям. Различают два основных способа шифрования:  канальное шифрование;  оконечное (абонентское) шифрование. В случае канального шифрования защищается вся передаваемая по каналу связи информация, включая служебную. Этот способ шифрования обладает следующим достоинством - встраивание процедур шифрования на канальный уровень позволяет использовать аппаратные средства, что способствует повышению производительности системы. Однако, у данного подхода имеются существенные недостатки, в частности, шифрование служебной информации, неизбежное на данном уровне, может привести к появлению статистических закономерностей в шифрованных данных; это влияет на надежность защиты и накладывает ограничения на использование криптографических алгоритмов. Оконечное (абонентское) шифрование позволяет обеспечить конфиденциальность данных, передаваемых между двумя прикладными объектами (абонентами). Оконечное шифрование реализуется с помощью протокола прикладного или представительного уровня. В этом случае защищенным оказывается только содержание сообщения, вся 58 служебная информация остается открытой. Данный способ позволяет избежать проблем, связанных с шифрованием служебной информации, но при этом возникают другие проблемы. В частности, злоумышленник, имеющий доступ к каналам связи компьютерной сети, получает возможность анализировать информацию о структуре обмена сообщениями, например, об отправителе и получателе, о времени и условиях передачи данных, а также об объеме передаваемых данных. Четвертую группу средств защиты составляют системы аутентификации электронных данных. При обмене электронными данными по сетям связи возникает проблема аутентификации автора документа и самого документа, т.е. установление подлинности автора и проверка отсутствия изменений в полученном документе. Для аутентификации электронных данных применяют код аутентификации сообщения (имитовставку) или электронную цифровую подпись. При формировании кода аутентификации сообщения и электронной цифровой подписи используются разные типы систем шифрования. Пятую группу средств, обеспечивающих повышенный уровень защиты, образуют средства управления ключевой информацией. Под ключевой информацией понимается совокупность всех используемых в компьютерной системе или сети криптографических ключей. Как известно, безопасность любого криптографического алгоритма определяется используемыми криптографическими ключами. В случае ненадежного управления ключами злоумышленник может завладеть ключевой информацией и получить полный доступ ко всей информации в компьютерной системе или сети. Основным классификационным признаком средств управления ключевой информацией является вид функции управления ключами. Различают следующие основные виды функций управления ключами: генерация ключей, хранение ключей и распределение ключей. Способы генерации ключей различаются для симметричных и асимметричных криптосистем. Для генерации ключей симметричных криптосистем используются аппаратные и программные средства генерации случайных чисел. Генерация ключей для асимметричных криптосистем представляет существенно более сложную задачу в связи с необходимостью получения ключей с определенными математическими свойствами. Функция хранения ключей предполагает организацию безопасного хранения, учета и удаления ключей. Для обеспечения безопасного хранения и передачи ключей применяют их шифрование с помощью других ключей. Такой подход приводит к концепции иерархии ключей. В иерархию ключей обычно входят главный ключ (мастер-ключ), ключ шифрования ключей и ключ шифрования данных. Следует отметить, что генерация и хранение мастер-ключей являются критическими вопросами криптографической защиты. Распределение ключей является самым ответственным процессом в управлении ключами. Этот процесс должен гарантировать скрытность распределяемых ключей, а также оперативность и точность их распределения. Различают два основных способа распределения ключей между пользователями компьютерной сети:  применение одного или нескольких центров распределения ключей;  прямой обмен сеансовыми ключами между пользователями. 59