Не храните больше информации, чем вам действительно нужно.
На многих веб-сайтах есть сложные формы, которые нужно заполнить, прежде чем клиент сможет сделать даже самые простые покупки. Часто эти формы запрашивают всю информацию, которая не имеет отношения к продаже. Обычно это ошибка отдела маркетинга, пытающегося получить избыточные демографические или Информация о CRM, Проблема в том, что предварительная продажа обычно не является правильным местом для запроса таких данных.
Юридически вы несете ответственность за защиту данных, которые вы храните о своих клиентах. Существуют даже определенные типы данных, которые вам юридически запрещено хранить (например, номера CVS). Несмотря на это, многие веб-сайты хранят эту информацию, которую они не должны хранить.
Вам гораздо лучше не делать этого. На этапе предварительной продажи вы можете фактически потерять клиентов, запросив слишком много информации. Они отправятся в какое-то место, где покупка проще и где они не чувствуют, что они сталкиваются с Великой инквизицией.
Люди все больше обеспокоены информацией, которую они используют в Интернете, поэтому ваша цель должна заключаться всегда в сборе минимального объема информации, поскольку это помогает создать доверие. Если вы используете PayPal или аналогичную услугу для обработки ваших платежей, вам, вероятно, не нужно собирать какую-либо информацию от вашего клиента, потому что PayPal предоставляет вам все, что вам нужно знать для завершения заказа.
Чем больше информации вы храните, тем больше потенциально доступно для кого-то, чтобы украсть и использовать. Если их кража будет обнаружена и прослежена до вас, в дальнейшем будет возникать гораздо больше проблем.
Если вы собираете конфиденциальную информацию, вам нужен SSL
В идеале каждый сайт должен иметь SSL по умолчанию, но, к сожалению, довольно сложно перебрать SSL, и есть даже крупные интернет-компании, которые ошибаются (ради них мы их не будем называть).
SSL дает вам шифрование, которое затрудняет (но не делает невозможным) взлом или другие действия. wise вмешиваться в сделку. Он также в некоторой степени защищает передаваемую информацию.
Самая важная особенность SSL — возможно, даже более важная, чем шифрование — заключается в том, что она позитивно идентифицирует ваш сайт. Даже это не идеально, но это лучше, чем ничего.
Перед отправкой продуктов проверьте все сведения о транзакции
Для некоторых предприятий это может быть немного сложным. Например, если вы продаете цифровые продукты, например, электронные книги, клиенты обычно ожидают, что они получат свой продукт почти мгновенно. Если вы продаете физические товары, у вас есть еще немного времени, чтобы проверить все, и вы должны его использовать.
Убедитесь, что количество, цены и описания продуктов соответствуют тому, что они должны соответствовать. Также проверьте, действуют ли какие-либо скидочные коды или коды купонов.
Как вы можете видеть, оставаться в безопасности не требует больших усилий или затрат. Это в основном означает снижение привычек крупных корпораций. Другими словами:
• Не следите за своими клиентами
• Не собирайте информацию, которая вам не нужна строго
• Защитите информацию, которую вы собираете
• Делегировать ответственность за соблюдение, если это возможно, с помощью обработки транзакций третьей стороной
• просматривать заказы перед отправкой продукции
Еще одна вещь, которую вы должны всегда делать, — проверить, что запросы на возврат совпадают с суммой первоначальной транзакции. Известно, что люди покупают по цене продажи и возмещению по полной цене, а персонал не всегда замечает.
Изображение изображения curtsey of Студия Fireart
Решения кибербезопасности для ритейла
• Регулярные ИБ тренинги — для повышения осведомленности персонала в вопроссах информационной безопасности;
• Аудит информационной безопасности и инструменты сканирования сети для обнаружения и предотвращения эксплуатации уязвимостей, своевременного патчинга;
• Корректная сегментация сети — для лучшего контроля сетевого трафика и повышения эффективности систем кибербезопасности;
• NTA (Network Traffic Analysis) — для обнаружение аномалий в трафике и выявление кибератак на ранних этапах;
• Межсетевые экраны и системы обнаружения и предотвращения вторжений (IDS/IPS) — для защита периметра сети, блокировка несанкционированного доступа и обнаружения потенциально вредоносного трафика;
• WAF (Web Application Firewall) — для защиты веб-ресурсов с помощью межсетевых экранов приложений от таких атак, как межсайтовая подделка запроса (CSRF), межсайтовый скриптинг (XSS), SQL-инъекция и других угроз;
• Защита конечных точек для снижения риска заражения программами и вирусами, шифрования информации, соблюдения соответствия политикам и регламентам ИБ;
• Организация безопасного удаленного доступа к сети и создания зашифрованного канала связи с помощью средств криптографической защита информации (СКЗИ) и VPN;
• СЗИ от НСД — для защиты стационарных и мобильных устройств от несанкционированного доступа, а также обеспечения соответствия требованиям регуляторов;
• DLP системы — для предотвращения утечки конфиденциальных материалов, а именно анализа и блокировки данных, передаваемых с помощью электронной почты, мессенджеров, интернет-ресурсов и других источников;
• Системы управления доступом (IDM, PIM) — для контроля жизненного цикла учетных записей и разграничения прав доступа к сегментам сети;
• Решения для управления сетевым доступом (NAC) — для инвентаризации устройств, обеспечения видимости и контроля подключений к корпоративной сети;
• Системы классификации данных — для повышения безопасности конфиденциальной информации путем классификации, определения пользователей, взаимодействовавших с документами, упрощения доступа, поиска и отслеживания данных, а также устранения дублирований;
• Использование интерактивных ловушек для эффективного обнаружения APT-атак;
• SIEM системы — для централизованного мониторинга информационной безопасности, сбора и анализа данных от инструментов кибербезопасности;
• Threat Intelligence — для система исследования и атрибуции кибератак, охоты за угрозами и защиты сетевой инфраструктуры на основании данных о тактиках, инструментах и активности злоумышленников
• Антифрод решения — для проактивной защиты цифровой личности, предотвращения мошенничества и бот-атак на всех устройствах, платформах и сессиях пользователя в режиме реального времени.
Платежные системы. Соревнование брони и снаряда
Начинаем серию статей о безопасности в платежных технологиях. Тема большая, эта статья будет первой, вводной. О безопасности мы решили поговорить с Игорем Голдовским, главным архитектором и директором департамента, человеком, знающим все о платежных системах и их защите.
Вопросы безопасности в карточных платежных технологиях играют ключевую роль. Сама по себе банковская карта — средство, обеспечивающее удаленную аутентификацию ее держателя при совершении операции безналичной покупки или получения наличных. От надежности используемых методов аутентификации держателя карты в существенной степени зависит безопасность карточных операций в целом, а, следовательно, и доверие пользователей к картам как средству платежей.
С другой стороны, платежные технологии слепо не следуют за лозунгом «Безопасности много не бывает». Технологии, обеспечивающие высокий уровень безопасности, но при этом неудобные для использования и/или требующие значительных расходов/усилий на внедрение, оказываются на практике невостребованными.
В платежных технологиях всегда ищется баланс между уровнем обеспечиваемой безопасности, удобством пользователя и стоимостью внедрения
Одним из примеров, иллюстрирующих этот тезис, является неудачная попытка внедрения протокола Secure Electronic Transaction (SET), практически безупречного с точки зрения обеспечиваемой им безопасности обработки операций электронной коммерции. Стандарт появился в 1998 г. и начал использоваться банками, но уже к 2001 г. стало понятно, что его массовое быстрое внедрение невозможно из-за высокой стоимости предлагаемых на рынке решений, а также из-за проблем на стороне держателей карт, связанных с необходимостью удаленной установки и настройки клиентского ПО на их персональных компьютерах. В результате, платежные системы постепенно отказались от использования SET и начали внедрять значительно более простой в использовании и дешевый для банков/магазинов протокол 3-D Secure.
Ранее на рынке реализовывалась модель «брони и снаряда» — в ответ на очередной снаряд, полученный от мошенников, устанавливается броня нужной для этого снаряда толщины. Но карточные платежи – коммерческий бизнес, в котором меры противодействия должны быть достаточными с точки зрения безопасности, а также максимально необременительными и удобными для банков и пользователей.
Приведу один пример такого соревнования брони и снаряда. К концу 90-х ведущие платежные системы пришли к выводу о том, несмотря на все предпринятые ими усилия, для эффективной борьбы с поддельными картами необходимо переходить на совершенно новую технологию микропроцессорных карт. Микропроцессорные карты позволили радикальным образом повысить безопасность так называемых Card Present- транзакций, в которых карта находится в точке совершения операции, за счет обеспечения 2-х факторной динамической аутентификации держателя карты ее эмитентом. С их внедрением уровень мошенничества по поддельным картам снизился практически до нуля, но начал расти уровень мошенничества для CNP (Card Not Present)-операций, то есть тех, где в точке выполнения операции карты нет. В первую очередь речь об операциях электронной коммерции, рекуррентных платежах, Card-on-File операциях и пр. В настоящее время появились технологии, позволяющие обеспечить уровень безопасности CNP-операций, соизмеримый с операциями по микропроцессорным картам. Это и новая версия протокола 3-D Secure 2. 0, и in-app платежи в телефонах, и токенизация карт, и операции удаленных платежей с использованием систем Secure Remote Commerce.
Поговорим о Secure Remote Commerce
Используемый вот уже два десятилетия платежными системами (ПС) протокол безопасной электронной коммерции 3D-Secure (v. 0 и v. 0) обеспечивает эмитенту возможность аутентификации держателя его карты в самом начале процедуры оплаты онлайновой покупки, до начала авторизации платежа эмитентом в платежной системе. Внедрение первой версии протокола позволило существенно повысить безопасность покупок в онлайновых магазинах. Новая версия протокола 3-D- Secure v. 0 расширила возможности первой версии, позволяя совершать покупки из мобильного приложения магазина на смартфоне покупателя, а также обеспечивая выполнение операции без непосредственной аутентификации клиента его банком (в т. моде frictionless mode). В последнем случае платформа 3-D Secure v. 0 производит оценку рисков для выполняемой операции и от лица эмитента принимает решение о возможности выполнить авторизацию транзакции без непосредственной аутентификации покупателя его банком. При принятии решения учитываются параметры покупки, а также информация об устройстве, с которого совершается операция, и о покупателе.
В то же время протокол 3-D Secure оставляет за скобками процедуры удобного для покупателя выбора платежного инструмента и оформления покупки, а также организации (при необходимости) процедуры аутентификации покупателя его банком. Определенные попытки заполнить пробел ранее предпринимались ведущими ПС, создавшими свои кошельки для выполнения удаленных платежей. Но сегодня уже можно признать — эти попытки оказались недостаточно удачными для того, чтобы завоевать сердца держателей карт. Протокол Secure Remote Commerce (SRC) — это новая попытка решить проблему создания удобного и безопасного для покупателя кошелька, предназначенного для удаленных платежей.
SRC представляет собой универсальный для держателей карт и торгово-сервисных предприятий (ТСП) механизм оплаты операций электронной коммерции.
Механизм оформлен в виде стандарта ассоциации EMVCo и оперативно взят на вооружение ведущими ПС. Некоторые международные платежные системы уже создали свои платформы SRC и в конце прошлого года запустили их в пилотном проекте на территории США. Механизм SRC реализуется на базе технической платформы, обеспечивающей для пользователя оформление оплаты покупки по принципу «нажатия одной кнопки» (one-click checkout). Кроме того, SRC повышает безопасность онлайновых операций за счет отсутствия необходимости ввода реквизитов карты (точнее, минимального использования этой процедуры) и токенизации инструментов оплаты.
SRC позволяет держателю карты при выполнении операции ЭК использовать на сайте ТСП «единую кнопку» для совершения платежа с помощью любого его платежного инструмента, зарегистрированного на платформе. Для этого SRC сама идентифицирует пользователя, отбирает платёжные инструменты пользователя, подходящие для оплаты покупки в данном ТСП, и дает возможность покупателю выбрать один из них. После регистрации в SRC при выполнении операции пользователю не нужно вводить информацию о себе, платежном инструменте и адресе доставки товаров. Все эти данные вводятся один раз при регистрации и потом хранятся на платформе SRC.
Ниже в очень упрощенном виде описана процедура выполнения покупки через систему SRC.
- ТСП (торговая площадка, поставщик платежного сервиса) после выбора покупателем кнопки SRC Triger отправляет в систему SRC данные о покупателе (например, биометрические данные покупателя, идентификатор мобильного приложения, из которого выполняется платеж), его устройстве (например, MAC-адрес устройства, версия ОС, идентификатор ОС и другие параметры, в общем случае до нескольких десятков характеристик) и самом ТСП (например, имя ТСП, код категории ТСП и т.п.). Следует заметить, что каждая платежная система имеет собственную систему SRC. Поэтому ТСП отправляет запросы во все системы SRC, принадлежащие ПС, карты которых принимает ТСП.
- Все SRC, получившие запрос ТСП, осуществляют распознавание (идентификацию) держателя карты и определяют его идентификатор. Если однозначную идентификацию выполнить не получается, покупателю будут заданы дополнительные вопросы для его окончательной идентификации (например, покупателя попросят ввести адрес его электронной почты)
- SRC выполняет поиск участников платформы, которые хранят сведения о всех зарегистрированных в SRC платежных инструментах (картах) идентифицированного покупателя. Такие участники SRC называются DCF (Digital Card Facilitator). В состав сведений о платежном инструменте входит информация об алиасе платежного инструмента, области его действия (в каких магазинах он может использоваться), а также инструкциях по выполнению процедуры аутентификации покупателя. Сегодня роль DCF выполняют сами платежные системы.
- ТСП получает из системы SRC список всех доступных покупателю для оплаты в данном ТСП платежных инструментов, отображает этот список покупателю, который выбирает один из них
- ТСП отправляет в систему SRC запрос, содержащий данные платежа и выбранного покупателем платежного инструмента
- Система SRC отправляет запрос DCF, представляющему выбранный пользователем платежный инструмент
- DCF отображает пользователю цифровую карту для выбранного платежного инструмента и в соответствии с инструкциями эмитента организует аутентификацию покупателя
- DCF отвечает системе SRC сообщением с результатом аутентификации покупателя, и система готовит данные для авторизационного запроса. Эти данные могут включать динамические данные транзакции, вычисленные с использованием криптографических алгоритмов
- Система SRC сообщает ТСП данные, необходимые для формирования авторизационного запроса, и ТСП инициирует процедуру авторизацию транзакции
- После получения ТСП ответа по результату авторизации, ТСП этот результат возвращает системе SRC, и система далее использует его в процедурах управления рисками при обработке будущих операций покупателя.
Очевидны преимущества внедрения системы SRC для покупателя:
- реализуется так желаемая им модель выполнения покупки «нажатием одной кнопки» (One click purchase): покупатель идентифицируется системой SRC по своему устройству и/или платежному приложению, ему дают возможность выбора карты, не нужно вводить реквизиты платежного инструмента и адреса доставки
- некоторые транзакции выполняются без аутентификации покупателя его банком с использованием процедур управления рисками, поддерживаемыми SRC
- обеспечивается универсальный способ совершения покупки и его аутентификации (одни и те же знакомые экраны, одни и те же действия)
- широкий выбор платежных инструментов (в будущем не только карты).
Для ТСП плюс от внедрения SRC в том, что за них комплексно и универсально решаются вопросы организации безопасных безналичных платежей. От магазина требуется всего лишь интегрировать в свой софт некоторое клиентское ПО системы SRC, обеспечивающее его интеграцию с SRC. Как пример, решения проблем магазина- использование токенизированных Card-on-File платежей, предлагаемых магазину платформой SRC. Также на стороне ТСП ожидается сокращение количества отказов покупателей от онлайновых покупок (abandonment rates) из-за недоверия покупателя к предлагаемому ему способу оплаты.
Очевидны преимущества SRC и для эмитентов карт. К ним относятся повышение безопасности операций (все операции токенизированы и выполняются на уровне безопасности EMV Chip, реквизиты карты вводятся на стороне ТСП только однажды при регистрации платежного инструмента), а также снижение abandonment rates.
Одним словом, платежные системы и их участники возлагают на внедрение SRC большие надежды, справедливо предполагая, что этот новый механизм удаленных платежей окажется максимально удобным для покупателя.
Начните с перехода на платформу Ecommmerce, которую вы знаете,
Ничто не является полностью безопасным в Интернете, но вы можете получить довольно чертовски близко. Мы говорили о элементы безопасности электронной торговли, но откуда вы знаете, защищает ли ваша текущая платформа как вас, так и ваших клиентов?
Короче говоря, платформа электронной коммерции, с которой вы идете, должна иметь все перечисленное ниже, что делает ее намного проще для вас, поскольку вам не нужно выходить и получать их самостоятельно:
- Безопасный онлайн-контроль
- Безопасность на уровне предприятия, многоуровневая безопасность
- Шифрование для всех данных клиента, включая инструменты, которые не хранят информацию о кредитной карте
- Постоянный мониторинг мошенничества
- Совместимость PCI и сканирование
- Card Verification Value
- Система проверки адреса
Некоторые слова в системе проверки адресов (AVS) и значение подтверждения карты (CVV)
Мы все столкнулись с CVV. Это маленький трехзначный код на обратной стороне вашей кредитной карты. С уважаемыми платформами электронной коммерции с надежными проверками вы собираетесь настроить эту систему. Если нет, вам, возможно, придется выйти и найти приложение или услугу для этого. Тем не менее, это прекрасный способ предотвратить мошенничество со стороны людей, которые только украли номера кредитных карт, а не CVV.
AVS немного отличается. Клиенты не видят этого на интерфейсе сайта, но еще раз, большинство уважаемых платформ предоставляют эту услугу. В основном, он проверяет, соответствует ли адрес в поле адреса биллинга адресу адреса для файла кредитной карты. Например, мошеннический пользователь может захотеть отправить продукт по их адресу, но украденная кредитная карта будет иметь адрес другого человека в файле, вызывая предупреждение для вас.
Чаще всего AVS обрабатывается через ваш процессор платежей, поэтому вам придется с ними проверить.
Имейте план резервного копирования
Мошенничество, как правило, не вызывает проблем с вашим контентом, но хакерство делает. Даже при всей вашей безопасности вы можете получить взломанные. В этом случае есть возможность переустановить ваш сайт или вернуть его из мертвых.
Игровой автомат Перезапустить приложение из Shopify является примером того, как защитить ваш сайт и обеспечить безопасность для потенциальных атак.
Предотвращение возвратов с отслеживающими номерами и контроль за людьми всех заказов
Номера отслеживания дают вам четкое представление о том, сколько инвентаря у вас есть и что происходит с пакетом после его отправки со своего склада. На большинстве платформ для электронной коммерции не требуются номера для отслеживания, и вы можете пропустить все отслеживание UPS / USPS / FedEx, но я рекомендую против этого. Это единственное доказательство, которое вы имеете против того, кто утверждает, что они никогда не получали свой пакет.
Настроить оповещения системы о том, когда возникает подозрительная активность
Вы должны знать об этом каждый раз, когда подозрительный пользователь находится на вашем сайте. Вы должны знать об этом каждый раз, когда человек совершает покупку с подозрительным адресом. Это уведомление не следует отправлять в случайную папку, которую вы создали в своем почтовом ящике, потому что это важные новости, к которым следует немедленно обращаться.
Заставляйте себя и всех сотрудников иметь сильные пароли
Не записывайте пароли и не пытайтесь их менять каждый месяц. Там действительно нет причин запоминать пароли с такими инструментами, как Dashlane и Roboform, Эти администраторы паролей составляют сложные пароли для борьбы с грубыми атаками, и вам не нужно думать о том, что вы сделали в последний раз.
Установить лимиты на покупки по счетам в определенный день
Давайте посмотрим правде в глаза. Иногда вы не сможете взглянуть на каждую продажу, которая проходит через ваш сайт. Поэтому случайная мошенническая покупка может проскользнуть через трещины и пройти. Однако многие платформы электронной коммерции позволяют устанавливать ограничения на покупки в определенный день или в другие временные рамки. Например, вы можете установить предел $ 1,000 в день на одного клиента.
Таким образом, если кто-то приходит на ваш сайт и пытается купить товар стоимостью $ 5,000, ваш сайт останавливает транзакцию и уведомляет вас. Вам дается немного дополнительного времени, чтобы дышать и посмотреть на транзакцию, и вы даже можете отпугнуть преступника.
Знаете ли вы, как защитить интернет-магазин от мошенничества и других атак?
Защита вашего интернет-магазина от мошенничества и другой преступной деятельности всегда начинается с вашего хостинга и платформы электронной коммерции. На вашей платформе должна быть страница безопасности, где описываются все принятые меры. Если нет, пропустите платформу полностью. Например, Shopify имеет целую страницу, объясняющую его PCI соответствия.
Bigcommerce имеет аккуратную безопасность раздел в том числе.
Если у вас есть какие-либо вопросы или мысли о защите вашего магазина от мошенничества, сообщите нам в комментариях ниже.
изображение заголовка любезно предоставлено Евгения Хо
Хостинг
В первую очередь необходимо выбрать надежного хостинг-провайдера. Многие ведущие игроки рынка имеют специализированные предложения для интернет-магазинов. Важно чтобы ваш хостинг-провайдер поддерживал регулярное резервное копирование; вел всесторонние журналы действий; выполнял мониторинг сетевой активности. Также одним из важных факторов является система уведомлений об аномальных действиях на аккаунте, возможном заражении сайта и т. Техническая поддержка (обычно в рамках тарифа) должна уведомить о нарушении и снабдить хотя бы минимальными инструкциями (или ссылкой на базу знаний) о методах решения возникшей проблемы и содействовать в ее решении. Оптимальным решением будет использование VPS/VDS-хостинга.
CMS
По возможности используйте безопасную e-commerce платформу. Она должна поддерживать сложную систему аутентификации (2F, OTP и т. ), возможность ограничения административной зоны и т.
Сама CMS, ее плагины, модули и т. должны быть актуальных версий. Оптимальный вариант CMS — возможность автообновления (особенно это касается критичных уязвимостей). Немаловажным фактором должно стать нативное использование WAF/детектора аномалий/блокировщика атак из коробки, либо дополнительным модулем или плагином.
Дополнительным плюсом будет использование в CMS разного рода механизмов проверки и санитайзинга данных, фреймворков или библиотек типа HTML Purifier.
SSL/TLS
Используйте защищенное соединение — шифруйте канал связи между сайтом и браузером клиента для передачи информации. В наше время актуальным является использование TLS (Transport Layer Security — безопасность транспортного уровня), который по привычке многие до сих пор называют SSL (Secure Sockets Layer — уровень защищённых сокетов).
Важно использовать последние (актуальные) версии криптографических протоколов для надлежащей защиты данных.
Данные
Не храните критичные данные. Никаких CVV кодов, сейчас не начало нулевых. Более того, стандарт PCI DSS это прямо запрещает: такие элементы как CVV2 (Card Verification Value 2 — код проверки подлинности карты платёжной системы Visa) и CVC2 (аналогичный код платежной системы MasterCard) относятся к критичным аутентификационным данным, а значит не подлежат хранению.
Если что-то приходится хранить — минимизируйте объем хранимых данных и по возможности применяйте шифрование. Это касается, в основном, обработки ПДн общей категории — ФИО, адрес, заказ и т.
Парольная политика
Требуйте использование надежных паролей — цифро-буквенные комбинации различного регистра, использование спецсимволов, ограничение минимальной длины пароля. Таким образом и клиент будет более надежно защищен от действий злоумышленников. Зачастую вопрос юзабилити (конверсии, отказов) ставится во главу угла и позволяет пользователям использовать любые пароли — это является плохой практикой, необходимо использовать сложные комбинации для защиты пользовательских данных.
Парольная политика технического персонала (администраторы сайта) должна быть еще строже — помимо более суровых требований к генерации пароля необходимо проводить регламентные процедуры по смене паролей, например, раз в месяц.
После проведения подрядных работ необходимо удалять неиспользуемые учетные записи. Также необходимо менять пароли после увольнения ключевых сотрудников.
Антифрод
Использование системы предупреждений и оповещений о подозрительной активности — множество операций с одного IP, смена реквизитов доставки и множество других факторов, обычно узкоспециализированных в той или иной сфере онлайн торговли. Здесь же может применяться холд/проверка чистоты сделки и прочее.
Хорошей практикой будет использование 3-D Secure, MasterCard SecureCode, J/Secure и SafeKey. За рубежом зачастую иcпользуется система AVS (Address Verification System).
Защитные механизмы
Хорошим решением будет превентивное использование AntiDDoS, IDS, IPS и WAF механизмов для защиты от использования уязвимостей сетевой архитектуры, сервисов и приложений.
Эти системы способны выявить и предотвратить большинство детектируемых (сигнатурных) атак, но панацеей не являются. Необходим комплекс мер и аналитическая работа по анализу аномалий/детекту вредоносной активности.
Немаловажным фактом является грамотная и кастомизированная настройка этих систем.
PCI DSS
Следование требованиям стандарта PCI DSS и регламентные проверки.
PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных индустрии платежных карт. Стандарт разработан международными платежными системами Visa и MasterCard. Любая организация, планирующая принимать и обрабатывать данные банковских карт на своем сайте, должна соответствовать требованиям PCI DSS
Стандарт представляет собой совокупность 12 детализированных требований по обеспечению безопасности данных о держателях платёжных карт, которые передаются, хранятся и обрабатываются в информационных инфраструктурах организаций. Принятие соответствующих мер по обеспечению соответствия требованиям стандарта подразумевает комплексный подход к обеспечению информационной безопасности данных платёжных карт.
Аудит безопасности
Интернет-магазин, как основной инструмент торговли, должен стабильно и бесперебойно работать. Обеспечить данные условия возможно только уделяя надлежащее внимание безопасности ресурса, а именно такой процедуре, как аудит безопасности сайта.
Регламентная процедура (например, раз в квартал) проведения аудита безопасности информационной системы позволяет оценить зрелость системы управления ИБ и выявить уязвимости для их оперативного устранения. Один из основных этапов — проведение внешнего Blackbox тестирования на проникновение.
Комплексный аудит безопасности сайта необходим для выполнения требований 6. 3, 6. 5, 6. 6, 11. 2 стандарта PCI DSS.
К компаниям, работающим только с платёжным шлюзом и не принимающих на своем данных банковских карт клиентов, относятся только требования департамента рисков платежного шлюза (ПЦ) и требования к проведению аудита не такие жесткие, как в стандарте PCI DSS, но и в этом случае необходимо проводить работы по выявлению возможных уязвимостей e-commerce сайта.
Патч менеджмент
Необходимо поддерживать актуальность используемых компонентов информационной системы — как версии CMS и ее составляющих, так и всего остального — версии серверной ОС и модулей и т.
Важность обновлений и их своевременной установки очевидна для поддержания надлежащего уровня информационной безопасности.
Хорошей практикой будет тестирование обновлений в dev-среде, перед обновлением продакшена, некоторые обновления могут содержать или вносить ошибки, в том числе содержащие критичные уязвимости.
Резервное копирование
Важными параметрами являются схема резервного копирования и планирование. Необходимо проводить регулярное резервное копирование, как инкрементного, так и дифференциального типа. Периодически проверять актуальность и работоспособность текущих резервных копий, обеспечивать их надежное и безопасное хранение, вне контура резервируемого объекта.