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

Сергей Шустиков, руководитель направления менеджмента ИБ компании Digital Security, QSA

О чем это вы?

Однажды моему другу – специалисту по защите информации на глаза попалась вакансия, опубликованная весьма крупным российским банком, которая гласила: «Требуется начальник управления информационной безопасности. Обязанности: настройка межсетевых экранов, установка антивирусного программного обеспечения на серверы и рабочие станции… опыт работы на аналогичной позиции от 5 лет». Автор этой вакансии сам того не осознавая поднял на поверхность одну из самых глубоких проблем, имеющих место в отрасли обеспечения информационной безопасности.

Давайте рассмотрим, что содержится в этих строках. Содержится в них весьма распространенное заблуждение, что обеспечение безопасности заключается в установке и настройке специализированных технических решений – межсетевых экранов, антивирусов, систем обнаружения вторжений и прочих, безусловно, необходимых средств. При этом организация хочет нанять для этой работы опытного CISO! «Конечно же, их ошибка очевидна!» - скажете вы. Меры обеспечения безопасности, как установка межсетевых экранов и антивирусов, так и управление доступом, инцидентами, непрерывностью, соответствием – это детали, из которых строится большая социотехническая система под названием «информационная безопасность», вверяемая в руки CISO, чтобы ей управлять.

Чтобы управлять чем-либо нужно для начала получить доступ к «органам управления». Этого можно добиться путем внедрения в организации системы менеджмента информационной безопасности (СМИБ), которая предполагает взгляд на вопросы защиты информации с позиций системного подхода. Необходимо объединение в согласованную структуру всех механизмов безопасности, подчас имеющих принципиально разную природу.

Зачем нам всё это?

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

Самыми болезненными, обычно, являются такие вопросы, как управление конфигурациями, управление изменениями, внедрение новой функциональности, расчет затрат на безопасность, которые можно объединить под термином «прозрачность инфраструктуры». В отсутствие СМИБ с прозрачностью инфраструктуры по объективным причинам наблюдаются большие проблемы, выражающиеся в следующем:

• отсутствует процесс документирования и учета конфигураций (CMDB), системные администраторы не помнят всех деталей и особенностей того или иного компонента информационной инфраструктуры, как следствие – при каждом изменении тратят значительное количество времени на их изучение;
• та же самая причина не даёт планировать мероприятия, системные администраторы «режут по живому» при внедрении новых проектов, которые в результате затягиваются из-за «непредвиденных» затруднений, кроме того, ситуация осложняется отсутствием выделенной тестовой среды;
• отсутствует процесс управления изменениями, даже на самом простом уровне – в виде их регистрации, типичный пример последствий - открытые для тестовых целей порты на межсетевом экране забываются и так и остаются открытыми (классическая схема появления уязвимостей, обнаруживаемая в ходе аудита);
• вышеперечисленное не даёт системным администраторам планировать время на свои задачи, которые неизбежно затягиваются, сотрудники вынуждены работать в перманентном аврале и как следствие – не решать проблемы, а «латать дыры» и «ставить подпорки», что само по себе добавляет трудностей в будущем;
• администраторы, погруженные в ощущение непрерывного аврала, вынуждены откладывать регламентные работы, деятельность сводится к формуле «не сломалось – не трогай», как следствие – усугубляются проблемы планирования;
• при непрозрачном управлении информационной инфраструктурой возникают трудности при попытке отдать те или иные задачи на аутсорсинг, в первую очередь из-за отсутствия четко определенных границ и измеримых показателей качества сервиса;
• анализ информационных рисков не применяется, вследствие чего средства защиты финансируются по остаточному принципу, а зачастую – не внедряются вовсе;
• желаемый эффект от внедренных систем безопасности не наступает из-за отсутствия полной картины информационных рисков;
• благодаря отсутствию процессов мониторинга информационной инфраструктуры создаётся иллюзия отсутствия инцидентов информационной безопасности, что приводит к опасному занижению значимости вопросов защиты информации;
• отсутствует работа с сотрудниками компании по вопросам повышения осведомленности в вопросах информационной безопасности;
• затрудняются процессы управления соответствием внешним требованиям, таким как стандарт PCI DSS, по причине «пробелов» в практических вопросах защиты данных о держателях карт, а также качества нормативной базы.

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

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

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

Что же с этим делать?

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

Если говорить о безопасности в рамках стандарта PCI DSS, областью применения которого являются системы, обрабатывающие данные о держателях платежных карт, то компании можно разделить на три категории:

• Крупные (банки, крупные дата-центры, процессинги, компании, обладающие большой платежной инфраструктурой, поддерживаемой коллективом специалистов от 10 человек, и штатом сотрудников, имеющих доступ к карточным данным от 50 человек);
• Средние (небольшие процессинги, поставщики услуг, крупные торгово-сервисные предприятия, компании, обладающие средней по размерам платежной инфраструктурой, поддерживаемой коллективом специалистов от 5 до 10 человек, и штатом сотрудников, имеющих доступ к карточным данным до 50 человек);
• Малые (платежные шлюзы, поставщики услуг, торгово-сервисные предприятия, интернет-магазины, компании, обладающие небольшой платежной инфраструктурой, поддерживаемой коллективом специалистов до 5 человек, и штатом сотрудников, имеющих доступ к карточным данным до 10 человек).

Крупным стоит задуматься над внедрением лучших практик, описанных в библиотеке ITIL, документах COBIT, стандарте ISO/IEC 27001. Лишним это точно не будет, внедренные методы помогут адекватно реагировать на изменение масштабов бизнеса и внедрение новых бизнес-процессов.

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

Как же можно формализовать и упорядочить управление безопасностью и при этом не зарыться в бумажках? В качестве исходной следует выбрать позицию, предполагающую, что управление информационной инфраструктурой и её безопасностью – это неотъемлемые друг от друга составляющие непрерывного процесса. Затем следует определить требования к этому процессу (очевидно, что таким требованием будет хрестоматийное «чтобы конфиденциальность, целостность и доступность не нарушались»), а потом разложить его на составляющие процессы (управление доступом, управление изменениями, физическая защита и т. д.).

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

Рис. 1. Трехуровневая структура нормативных документов

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

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

И, наконец, низкоуровневые процедуры. Это документы, определяющие порядок тех или иных действий. Каждый процесс может состоять из одной или нескольких процедур, например процесс управления доступом будет содержать в себе процедуры предоставления и отзыва привилегий пользователю, а также процедуру мониторинга и актуализации предоставленных прав. Процедуры должны соответствовать требованиям, описанным в документе второго уровня. Здесь тоже не следует увлекаться объемом текста, надо всегда помнить о том, что длинные инструкции утомляют. Если процедура занимает более десяти страниц, это значит что либо тут имеет место попытка запихнуть несколько процедур в одну, либо описание излишне подробно. И самый главный момент – документированная процедура должна максимально отражать то, что есть в реальной жизни, а не быть сферическим конем в вакууме. Если для достижения соответствия каким-либо требованиям (стандарту PCIDSS или ЦБ РФ) необходимо поменять существующий порядок вещей, то следует сделать это максимально безболезненно. На мой взгляд, очевидно, что скачанная в Интернете процедура тут только навредит, а никак не поможет. Автору нормативного документа всегда стоит помнить о том, что по этой процедуре будут жить люди.

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

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

Следует сказать пару слов об одной интересной особенности управления безопасностью в соответствии с PCI DSS. В основе любой системы менеджмента информационной безопасности лежит анализ рисков, кроме того, требование формального анализа рисков содержится в 12 разделе самого стандарта PCI DSS. Но при всём при этом абсолютно все требования стандарта являются обязательными. Кроме того, Совет PCI SSC выпустил документ под названием Приоритетный подход к достижению соответствия PCI, в котором определил приоритеты внедрения требований стандарта, то есть – выполнил анализ рисков, связанных с защитой карточных данных, чем сильно помог тем, кто находится на пути к соответствию. Стоит обратить внимание на то, что Совет PCI SSC сам говорит о том, что не претендует на истину в последней инстанции в вопросе расстановки приоритетов требований, и приветствует использование собственных методик анализа информационных рисков.

Следует сказать пару слов об одной интересной особенности управления безопасностью в соответствии с PCI DSS. В основе любой системы менеджмента информационной безопасности лежит анализ рисков, кроме того, требование формального анализа рисков содержится в 12 разделе самого стандарта PCI DSS. Но при всём при этом абсолютно все требования стандарта являются обязательными. Кроме того, Совет PCI SSC выпустил документ под названием Приоритетный подход к достижению соответствия PCI, в котором определил приоритеты внедрения требований стандарта, то есть – выполнил анализ рисков, связанных с защитой карточных данных, чем сильно помог тем, кто находится на пути к соответствию. Стоит обратить внимание на то, что Совет PCI SSC сам говорит о том, что не претендует на истину в последней инстанции в вопросе расстановки приоритетов требований, и приветствует использование собственных методик анализа информационных рисков.

Об авторе

Сергей Шустиков – руководитель направления менеджмента информационной безопасности компании Digital Security. Специализируется на управлении безопасностью. Область профессиональных интересов охватывает разработку систем менеджмента информационной безопасности в соответствии с международными стандартами и проведение аудитов на соответствие требованиям международных и национальных стандартов индустрии защиты информации (PCI DSS, ISO 27001, СТО БР-ИББС-1.0).

Занимается научно-исследовательской деятельностью в области системного анализа методов управления в сфере информационных технологий и информационной безопасности. Преподает ряд специальных дисциплин на кафедре Безопасных Информационных Технологий Санкт-Петербургского Государственного Университета Информационных Технологий Механики и Оптики.

О стандарте PCI DSS

Стандарт PCI DSS (Payment Card Industry Data Security Standard) предназначен для обеспечения безопасности обработки, хранения и передачи данных о держателях платежных карт в информационных системах компаний, работающих с международными платежными системами Visa, MasterCard и другими. Стандарт разработан сообществом PCI Security Standards Council, в которое входят мировые лидеры на рынке платежных карт, такие как American Express, Discover Financial Services, JCB, MasterCard Worldwide и Visa International.

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

Текущая версия стандарта 1.2.1 выпущена в июле 2009 года.

наверх