Федор Дбар, менеджер по продаже услуг компании «Информзащита»
Преимущественно в подобных статьях приведены рекомендации о том, на что обратить внимание, чем руководствоваться, что спрашивать на переговорах, чтобы при минимальном привлечении как человеческих, так и финансовых ресурсов, достигнуть поставленной цели. Все это привело к формированию определенного взгляда аудитории на компании поставщиков услуг по достижению PCI DSS Compliance и последующему аудиту. Но думаю, будет интересным и полезным попытаться осветить и противоположный взгляд, иными словами, постараться очертить портрет покупателей услуг в рамках достижения PCI DSS Compliance. Причина, по которой потенциальный покупатель решил воспользоваться услугами сторонней организации, колеблется в неких рамках – от «дало указание начальство» до«мы получили письмо от МПС с указанием конкретных сроков и результатов». Казалось бы, в последнем, крайнем, варианте проект по достижению этих конкретных результатов в конкретные сроки не должен создавать проблем. И, тем не менее, они случаются. Даже если уровень осведомленности и компетенции покупателя высокий, что является крайней редкостью, то все равно возникает ряд «неожиданных» трудностей.
Первое – это, конечно, финансовый аспект. Мало кто понимает реальный уровень затрат на проект подобного рода, при этом, возможно, и переоценивает. Указать наперед точную стоимость приведения в соответствие и получения сертификата не может никто. Это невозможно. Стандарт не навязывает конкретных вендоров оборудования и программного обеспечения, не навязывает конкретных способов реализации требований, будь то автоматизированная реализация или реализация через построенный процесс, пусть и через человеческий ресурс. Стандарт лишь требует выполнения ряда задач, направленных на реализацию поставленной цели, – установления высокого уровня информационной безопасности в целом. Как бы неопределенно и неконкретно это ни звучало, но это именно так. И как раз для этого существуют аккредитованные организации, компетенция которых позволяет принимать решение – достигнута общая цель или нет. Вот поэтому заранее нельзя оценить стоимость проекта по приведению в соответствие с требованиями PCI DSS. Очень часто выполнение требований (а их около 270) подразумевает два и более вариантов или компенсационные меры, эти трудозатраты и варианты невозможно предусмотреть до начала внедрения проекта, что в свою очередь приводит к невозможности точной оценки стоимости всего проекта. И еще раз подчеркну: неизвестно, будет ли эта стоимость выше или ниже, чем ожидаешь.
Безусловно, это предполагает определенные риски в планировании бюджета на подобные работы. Естественно, неприемлема ситуация, когда на вопрос о стоимости проекта, ответом являются нечеткие границы. Люди, формирующие бюджет на будущие периоды, не примут такой ответ и не запланируют средства на реализацию проекта. Другое дело, вопрос, чем тут может помочь продавец. Зная текущий уровень информационной безопасности заказчика, продавец может весьма достоверно предположить перспективы развития в этой области и, как следствие, в сфере выполнения требований PCI DSS. Иными словами, зная, к примеру, что контроль целостности ключевых файлов никак не выполнятся, есть все основания предполагать, что такой процесс будет налажен и заодно будет выполнено одно из требований PCI DSS. Конечно, для первого аудита и первого сертификата данное требование может быть выполнено, скажем, средствами ОС и антивируса, хотя это и не вполне эффективно. Таким образом, по этому и другим требованиям продавец может помочь – не сформировать, а именно создать бюджет на проект по PCI DSS.
Но отсюда вытекает еще одна проблема. Это честность продавца. Понимая всю неопределенность ситуации, продавец нередко сталкивается с соблазном слегка ввести в заблуждение покупателя. Хотя бы указав, что, к примеру, требование по процессу сбора и анализа событий может быть закрыто не иначе, чем через конкретное программно-аппаратное средство, которое, как потом выясняется, может быть приобретено по приемлемым ценам как раз через этого продавца. Сделать так, чтобы какой-то продукт приобретен через тебя, и при этом у тебя сохраняется весьма высокий уровень маржинальности – не составляет труда. А в таком случае, не так уж важно, сколько стоят услуги по, ну предположим, аудиту, если я все смогу «отбить» деньги на поставке?
Третья проблема – это сроки: практически никогда не получается заранее назвать реальные сроки выполнения проекта. Причина кроется в неопределенности состава работ. Иными словами, не получается заранее, до начала работ, предугадать, что же потребуется реализовать в рамках проекта. Логично, что при написании или доработке политики информационной безопасности возникает желание предусмотреть в ней все до мельчайших подробностей. Но есть и другая сторона реализации требований. Предположим, требования по безопасной настройке ресурсов фактически сформулированы, осталось их внедрить и убедиться в исполнении. Если это один-два ресурса, то трудностей не возникнет. А если 100–150?
Или еще одна распространенная проблема. Бизнес идет своей дорогой, стараясь развиваться и продуцировать новые каналы поступления прибыли. И бизнес не может на 6–8 месяцев впасть в спячку, для того чтобы отдел ИБ и ИТ реализовали проект по PCI DSS. С их стороны (стороны бизнеса) постоянно приходят новые задачи о реструктуризации или о масштабировании инфраструктуры, а это, безусловно, влияет на область применения требований стандарта и на объем работ. Зачастую это даже перечеркивает все то, что уже было сделано. Осознавая все вышесказанное, мы приходим к тому, что проект по PCI DSS – это проект команды заказчика, следовательно, заказчику более уместно прогнозировать временные затраты на проект, разумеется, не без помощи продавца. И тут снова возвращаемся к вопросу порядочности продавца. Велик соблазн в обтекаемых определениях выдавать сроки своих конкретных работ за сроки выполнения всего проекта. А весь проект для покупателя – это получение сертификата соответствия требованиям PCI DSS, а не документ по настройке, скажем, Juniper, не так ли?
Или еще вариант, сканирование уязвимостей. Мало кто помнит, что сертификационному аудиту должно предшествовать не менее четырех ежеквартальных сканирований, ведь без них одно требование стандарта не будет выполнено, и, соответственно, не будет получен сертификат. Говоря иначе, за год до даты предполагаемого аудита, покупатель должен был озаботиться вопросом проведения сканирований, не забывая при этом проводить их раз в квартал, вплоть до самого аудита. И что характерно, данные сканирования соблазнительно дешевы, чтобы уделять им мало внимания и не соблюсти указанный интервал.
Таким образом, был рассмотрен вопрос стоимости работ и сроков их проведения для категории покупателей, которые точно знают, зачем и когда им нужен PCI DSS. Это, безусловно, выделяет их как категорию людей, разбирающихся в нюансах стандарта и методах его реализации. И раз в данной категории распространены заблуждения, то можно представить, какие ошибки допускаются людьми, которым было спущено сверху «разобраться с соответствием PCI DSS». А таких людей и компаний, к сожалению, немало.
