61
Целостность - характеристика информации, с помощью которой она
разрешается только уполномоченным лицам или системам.
Доступность - характеристика информации, с помощью которой к ней
могут обращаться уполномоченные лица, когда это необходимо.
Информационная безопасность - сохранение конфиденциальности,
целостности и доступности информации.
Система управления информационной безопасностью (СУИБ) - часть общих
процессов управления, которая занимается планированием, внедрением,
обслуживанием, проверкой и улучшением информационной безопасности.
Личная информация (PII)- любые данные, которые потенциально могут
идентифицировать конкретного человека. Любая информация, которая может
использоваться для различения одного человека от другого и может
использоваться для деанонимизации анонимных данных, может считаться PII.
PII Data Environment (PDE) - компьютерная система или сетевая группа
ИТ-систем, которая обрабатывает, хранит и / или передает любые данные
PII . CDE также включает в себя любой компонент, который напрямую
подключается к этой сети или поддерживает ее.
Среда данных держателя карты (CDE) - компьютерная система или
сетевая группа ИТ-систем, которая обрабатывает, хранит и / или передает
данные держателя карты или конфиденциальные данные аутентификации
платежа. CDE также включает в себя любой компонент, который напрямую
подключается к этой сети или поддерживает ее.
Общие задачи системы управления информационной безопасностью
следующие:
• создание лучшего имиджа на рынке и снижение ущерба от
возможных инцидентов
• соответствие действующему законодательству.
Цели соответствуют бизнес-целям организации, стратегии и бизнес-
планам. COO отвечает за рассмотрение этих общих целей СМИБ и определение
новых.
62
ISM предлагает задачи для отдельных элементов управления
безопасностью или групп элементов управления.
Все цели должны быть пересмотрены в случае необходимости каждого
отдельного случая.
Все операции по обработке карт и связанные с ними технологии должны
полностью соответствовать Стандарту безопасности данных индустрии
платежных карт (PCI-DSS). Действия по обработке карты должны проводиться,
как описано в настоящем документе, и в соответствии со стандартами и
процедурами, перечисленными в разделе «Связанные документы» настоящей
Политики. Никакая деятельность не может быть осуществлена, и никакие
используемые технологии не могут препятствовать соблюдению какой-либо
части PCI-DSS.
Настоящая Политика и вся СМИБ должны соответствовать юридическим
и нормативным требованиям, предъявляемым к организации в области
информационной безопасности, а также договорным обязательствам Компании.
Обязанности
1. Ответственность за управление безопасностью распределена между
несколькими членами команды в Data Travel, чтобы гарантировать
наличие сдержек и противовесов. Делегирование обязанностей по
управлению безопасностью заключается в следующем:
• ISM отвечает за обеспечение того, чтобы СУИБ была внедрена и
поддерживалась в соответствии с настоящей Политикой, а также за
обеспечение доступности всех необходимых ресурсов.
• ISM отвечает за оперативную координацию СМИБ, а также за
отчетность о работе СМИБ.
• Высшее руководство должно пересматривать СМИБ каждый раз,
когда происходит значительное изменение. Целью анализа со
стороны руководства является определение пригодности,
адекватности и эффективности СМИБ.
63
• COO будет реализовывать программы обучения информационной
безопасности и информирования подрядчиков
• Защита целостности, доступности и конфиденциальности активов
является обязанностью владельца каждого актива.
• ISM несет ответственность за принятие и внедрение обучения и
осведомленности для всех лиц, которые играют роль в управлении
информационной безопасностью
• COO отвечает за системы, политики, процедуры, события в формате
diarized
• ISM отвечает за безопасность, хостинг, среду, данные и платформу
продукта.
• CTO отвечает за доступ пользователей, учетные записи, добавления,
удаления и модификации
2. Ответственность за мониторинг и анализ всех предупреждений и
информации о безопасности, а также за распространение среди
соответствующего персонала лежит на ISM. ISM отвечает за обеспечение
безопасности платформы и среды, а также за мониторинг любых рисков
или атак на среду, которые могут нарушить соответствие PCI или
подвергнуть риску данные держателя карты.
3. В дополнение к мониторингу всех предупреждений и информации о
безопасности, ISM также несет ответственность за распространение
этой информации среди всех заинтересованных сторон, включая,
среди прочего, CTO, COO, CEO и Team Development Team. Это делается
для того, чтобы каждый отдел знал о том, что происходит на платформе,
и может предоставить необходимые средства связи и процедуры для
снижения риска.
4. Ответственность за создание, документирование, распространение и
обзор политики и процедур безопасности лежит на COO. Генеральный
директор несет ответственность за обеспечение защиты всех данных PII
и держателей карт с точки зрения политики, а также за обеспечение того,
64
чтобы в компании применялись процедуры для соблюдения на всех
уровнях.
5. Создание всех политик и процедур безопасности осуществляется исходя
из потребностей и в упреждающей манере, чтобы подготовить и
настроить компанию на успех и масштаб.
6. Документация по всем политикам и процедурам безопасности доступна в
Confluence.
7. Распространение политик и процедур безопасности осуществляется через
электронную почту, Confluence и лично, с контрольным списком и
подтверждением, требуемым каждым сотрудником, которого вводят в
должность.
8. Любые изменения в корпоративной структуре или новые роли,
которые не могут быть четко определены или делегированы, по
умолчанию будут обязанностью CTO.
Управление сетью
Ответственность за управление сетевыми компонентами лежит на ISM.
Стандартное управление соответствует процедуре контроля изменений.
Системы PDE и CDE должны быть защищены перед развертыванием с
использованием контрольного списка и приведены в соответствие со
стандартами Центра интернет-безопасности (CIS) [29].
Стандарты конфигурации системы PDE и CDE должны обновляться по
мере выявления новых уязвимостей.
При развертывании новых систем необходимо выполнить следующие
шаги, чтобы обеспечить безопасность PDE и CDE:
• Изменять все поставляемые поставщиком значения по умолчанию
и отключите ненужные учетные записи по умолчанию
• Реализовывать только одну основную функцию на сервер, когда это
возможно
65
• Включать только необходимые службы, протоколы, демоны и т. д.,
необходимые для работы системы.
• Реализовать дополнительные функции безопасности для любых
необходимых сервисов, протоколов или демонов, которые
считаются небезопасными
• Настроить параметры безопасности системы, чтобы предотвратить
вмешательство
• Удалить все ненужные функции, такие как скрипты, драйверы,
функции, подсистемы, файловые системы и ненужные веб-серверы.
• Вести перечень компонентов системы, которые входят в сферу
требований конфиденциальности PCI DSS и PII
Передача данных
Data Travel использует TLS 1.2 для всей передачи данных, где это
возможно. Версии SSL не должны использоваться ни при каких обстоятельствах.
В случае использования версии 1.0 TLS будет разработан план по снижению
рисков. Хотя TLS 1.1 является приемлемым, клиент будет поощряться к
использованию TLS 1.2, где это практически возможно.
Все передачи данных держателя карты и PII через Интернет должны быть
защищены с использованием TLS 1.1 или более поздней версии.
Сертификаты X509, подписанные доверенным центром сертификации
(CA), должны использоваться для аутентификации на стороне сервера TLS.
Данные о держателях карт (например, PAN) нельзя отправлять по
электронной почте или с помощью сообщений (Messenger, WhatsApp или
аналогичных инструментов).
Управление уязвимостями
Data Travel принимает следующие меры для снижения вероятности
появления уязвимостей в среде данных PII и держателей карт:
66
• Подписка на отраслевые форумы, чтобы быть в курсе
распространенных уязвимостей, включая AT & T Cybersecurity-AlienVault Open
Threat Exchange.
• Обеспечение того, чтобы все разработчики точно знали о 10
уязвимостях OWASP.
• Обеспечение актуальности всех систем, которые считаются
областями для развертывания антивируса, регулярного сканирования и ведения
журналов.
• Ежегодно оценивать любые новые угрозы вредоносных программ,
которые могут оправдать установку антивирусного программного обеспечения
на серверах API производства.
• Установка всех критических исправлений для приложений и
операционной системы в течение 30 дней и других некритических исправлений
в течение 90 дней.
• Обеспечение проверки всего кода на наличие уязвимостей перед
развертыванием.
• Развертывание инструментов мониторинга для обеспечения
регистрации и мониторинга любых изменений файла или кода.
• Регулярное тестирование сети, включая ежеквартальное
сканирование на уязвимости и ежегодное тестирование на проникновение
• Повторное сканирование должно быть выполнено, чтобы
гарантировать, что любые идентифицированные проблемы решены.
• Веб-приложения подлежат оценке безопасности на основе
следующих критериев:
• Новая или основная версия приложения - будет подвергнута полной
оценке до утверждения документации по управлению изменениями и / или
выпуска в живую среду.
• Стороннее или приобретенное веб-приложение - будет подвергнуто
полной оценке, после чего оно будет связано с требованиями политики.
67
• Незначительные или точечные релизы - будут подвергаться
соответствующему уровню оценки в зависимости от риска изменений в
функциональности и / или архитектуре приложения.
• Патч-релизы - будут подвергаться соответствующему уровню
оценки, основанному на риске изменений в функциональности и / или
архитектуре приложения.
• Экстренные выпуски - экстренному выпуску будет разрешено
отказаться от оценок безопасности и нести предполагаемый риск до тех пор, пока
не будет проведена надлежащая оценка. Аварийные выпуски будут назначаться
в качестве таковых главным техническим директором или соответствующим
руководителем, которому были делегированы эти полномочия.
Все проблемы безопасности, обнаруженные во время оценки, должны
быть смягчены на основе следующих уровней риска. Уровни риска основаны на
методологии оценки рисков OWASP. Для подтверждения правильности
стратегий исправления и / или смягчения для любых обнаруженных проблем со
средним уровнем риска или выше потребуется тестирование с целью
исправления:
• Критические. Любые критические проблемы должны быть устранены
немедленно, либо должны быть внедрены другие стратегии смягчения, чтобы
ограничить воздействие до развертывания. Приложения с критическими
проблемами могут быть переведены в автономный режим или отклонены в
живую среду.
• Высокий риск - следует рассмотреть проблемы высокого риска, чтобы
определить, что требуется для смягчения, и запланировать их соответствующим
образом. Приложения с проблемами высокого риска могут быть переведены в
автономный режим или им может быть отказано в выпуске в живую среду в
зависимости от количества проблем и, если множественные проблемы
увеличивают риск до неприемлемого уровня. Проблемы должны быть
исправлены в патче / выпуске, если другие стратегии смягчения не ограничат
воздействие.
68
• Средняя / Низкая - проблема должна быть рассмотрена, чтобы
определить, что требуется для устранения проблемы, и запланирована
соответствующим образом.
Следующие уровни оценки безопасности должны быть установлены
назначенной организацией, которая будет выполнять оценки:
• Полная - Полная оценка состоит из тестов на все известные уязвимости
веб-приложений с использованием как автоматических, так и ручных
инструментов, основанных на Руководстве по тестированию OWASP. Полная
оценка будет использовать методы тестирования на проникновение вручную для
проверки обнаруженных уязвимостей, чтобы определить общий риск любого и
всех обнаруженных.
• Быстрая - быстрая оценка будет состоять из (как правило)
автоматического сканирования приложения на предмет минимальных рисков
безопасности веб-приложений OWASP.
• Целевой - целевая оценка выполняется для проверки изменений в
исправлении уязвимостей или новых функциональных возможностей
приложения.
В настоящее время используются утвержденные инструменты оценки
безопасности, которые будут использоваться для тестирования:
• Wazuh
• SonarQube
• trivy
• Amazon Security Hub
Другие инструменты и / или методы могут использоваться в зависимости
от того, что найдено в оценке по умолчанию, а также от необходимости
определения достоверности и риска, по усмотрению команды разработчиков
безопасности.
69
Контроль доступа
Доступ к CDE и PDE будет ограничен теми, кто имеет законную деловую
потребность.
В соответствии с ролями, определенными в соответствующем разделе
Политики информационной безопасности, перед предоставлением доступа к
PDE или CDE должно быть предоставлено и задокументировано согласие CTO
или делегата.
Документация об утверждении должна определять и перечислять
конкретные предоставленные привилегии.
Политика паролей и удостоверений личности
Всем пользователям будет присвоен собственный уникальный
идентификатор, независимо от доступа к среде данных держателя карты. В
соответствии с политикой Data Travel ни один поставщик не требует доступа к
PDE или CDE, кроме как для тестирования, такого как сканирование или
тестирование на проникновение. Доступ к PDE или CDE будет авторизован ISM
и заблокирован немедленно, когда доступ больше не требуется.
Пользователи должны устанавливать надежные пароли, которые трудно
угадать.Пароли не могут быть словарными словами и должны содержать не
менее 8 символов, состоящих как из цифровых, так и буквенных символов.
Четыре ранее установленных пароля не должны использоваться
повторно, новый пароль должен быть выбран в случае запланированного
изменения, сброса пароля или компрометации учетных данных.
Пароль следует менять как минимум каждые 90 дней для любого доступа
пользователя к PDE или CDE.
Если есть какие-либо признаки того, что пароль пользователя стал
известен третьей стороне, этот пароль должен быть немедленно изменен.
Весь удаленный доступ к PDE или CDE требует многофакторной
аутентификации.
70
Все учетные записи поставщиков по умолчанию должны быть отключены
до развертывания любых систем в рамках VPC Data Travel Production.
Все учетные записи пользователей должны проверяться не реже одного
раза в 90 дней, а все учетные записи, которые были признаны неактивными,
должны быть отключены.
Учетные записи пользователей должны быть заблокированы после не
более шести неудачных попыток входа в систему и оставаться
заблокированными не менее 30 минут или до тех пор, пока администратор не
включит учетную запись вручную.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Разработка и подходы к разработке программного обеспечения в
компании происходят в соответствии с ГОСТ Р ИСО/МЭК 12207 2010 [30],
ISO/IEC 27001, ISO/IEC/IEEE 90003 [31], ГОСТ Р 57102—2016/ ISO/IEC TR
24748-2:2011 [32] . В частности, в команде применяются гибкие методологии
разработки Agile и Scrum, подходы к взаимодействию и автоматизации DevOps.
Итак, нам необходимо максимально автоматизировать весь процесс
доставки кода в различные среды и окружения, чтобы код достигал конечных
пользователей в самые короткие сроки, для уменьшения срока Time to market,
для сокращения количества ошибок, связанных с ручным трудом.