PCI DSS PA-DSS Статьи Блог Форум О Сообществе PCI DSS Russia Семинар


PCI DSS
Новые статьи в RSSНовые статьи

Хакеры заинтересовались POS-терминалами

 4 августа 2016   0 комментариев
 Алина Оприско  
Кражи через такие терминалы распространены на Западе, предупредил банкиров Центробанк

В Digital Security подготовили обзор по безопасности высокоскоростных поездов

 2 августа 2016   0 комментариев
 Алина Оприско  
Компания Digital Security открывает цикл аналитических обзоров, посвященных безопасности транспорта и промышленных объектов. Первый обзор серии подготовлен Егором Литвиновым, ведущим специалистом по безопасности АСУ ТП Digital Security, который сосредоточил свое внимание на ИБ высокоскоростных поездов на основе информации из открытых источников. Специалист Digital Security описал инфраструктуру современного поезда, а также представил возможные векторы атак, которые в потенциале имеются в распоряжении злоумышленников. Обзор полностью можно почитать в нашем блоге на Хабре.

ЦБ потребовал киберзащиты

 2 августа 2016   0 комментариев
 Алина Оприско  
От рекомендаций банкам по информационной безопасности ЦБ перешел к однозначным требованиям. Регулятор разработал четкий и обязательный для всех банков регламент кибербезопасности, призванный защитить кредитные организации от хакерских атак. В документе, в частности, вводится обязанность банка в течение трех часов сообщать о готовящейся или свершившейся атаке.

Опросы
Где расположена ваша информационная инфраструктура?

В собственной серверной комнате
На арендованной площадке в дата-центре
В арендованной у дата-центра виртуальной среде

 
FAQ:
PCI DSS & PA-DSS


Что такое PCI DSS и PA-DSS? Ответы на главные вопросы.
Путь к соответствию PCI DSS

Выполнение требований стандарта и разработка компенсирующих мер.
Проверка
соответствия


Правила проверки соответствия компании требованиям стандартов и контакты тех, кто проверяет.
Копилка
полезностей


Здесь можно скачать стандарты PCI DSS и PA-DSS на русском языке и другие полезные материалы.
Главная Блог Статьи

С чего начинается безопасность?

21 сентября 2009
  
  pdf-версия

Сергей Шустиков - руководитель направления менеджмента ИБ компании 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 сам говорит о том, что не претендует на истину в последней инстанции в вопросе расстановки приоритетов требований, и приветствует использование собственных методик анализа информационных рисков.

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

КомментарииКомментарии

Добавьте комментарий!
Представьтесь, пожалуйста
Укажите адрес вашей почты
Опубликован не будет
Следить за дискуссией по почте
 











Партнеры