Аналитические кейсы
Кейс 1 - Описание логики для бизнеса
Вы обнаруживаете админскую консоль веб-сайта Компании, зарегистрированной в Евросоюзе, которая доступна неограниченному кругу лиц в сети Интернет. С помощью её интерфейса доступны на просмотр записи с запросами о приобретении продукции, которые содержат персональные данные лиц, запрашивающих продукцию, а также их коммерческие предложения (что хотят купить, в каком объёме и за сколько). Также в данном интерфейсе доступны логи, в которых видны ip-адреса администраторов Компании, обращавшихся к данной странице.
- a) Как вы презентуете топ-менеджеру без бэкграунда в ИТ/ИБ данную ситуацию в части обнаруженных вами недостатков, присущих ей рисков и рекомендаций? Кто будет указан ответственными сторонами по обозначенным рекомендациям?
Ответ можно предложить в формате, который вы считаете наиболее оптимальным (слайды, текст, …) и с той степенью детализации, которую вы считаете необходимой.
- b) Какие меры по митигации рисков вы предложите и как их приоритизируете по двум группам (срочные мерыи несрочные меры) для специалистов и менеджеров ИТ и ИБ?
Ответ нужно предложить в текстовом формате.
Скрытый ответ
a) Обнаружена уязвимость доступности панели администратора сайта из вне корпоративной сети, которая позволяет реализовать утечку информацию являющей коммерческой тайной организацией, персональным данным пользователей, отношениям между организациям, специальным предложения и иной чувствительной информации, что может повлечь за собой коммерческие, финансовые, страховые риски, которые могут вылиться в непосильные убытки, атаку на инфраструктуру организации, ее шифрованию, вымогательству.
Эта уязвимость реализуется из-за возможности доступа с любого удаленного соединения путем перебора пароля и недостаточной аутентификации/верификации пользователя, путем использования специальных векторов атак через код и инъекции в коде, позволяет сделать закладки вредоносного кода и прослеживать информацию внутри организации, раскрыть торговую и экономическую информацию и многое другое. То есть возможен критичный риск компрометации данных сделок и последующее понесение ущерба компании, упущения экономической выгоды и недополученной прибыли, штрафов со стороны регуляторов и действующего законодательства, в том числе репутационных.
Это влечет за собой высокую степень риска и ответственности. В данном случае также раскрываются процессы по социальной инженерии и получении компрометирующей информации для организации, вплоть до орг штатной структуры. В данном случае в блоке digital и отделом ИБ не был проведен аудит и идентификация проблем.
Рекомендуется перенести публикацию панели администратора внутри сети и после этого использовать рекомендации в процессах по следующим методическим указаниям: классификатор рисков с рекомендациями и примерами по критическим угрозам безопасности (OWASP TOP 10), основного стандарта подтверждения безопасности приложения (ASVS), использовать модель обеспечения безопасности программного обеспечения, методику оценки рисков (OWASP Risk Assessment Framework), использовать безопасные библиотеки при разработке (NVD), также исключить критичность по уязвимостям (СWE-564, 77, 287, 384, 327, 319, 611, 79, 502) со смежными рекомендациями, также использовать технический набор средств и мер, которые переданы ответственной команде с детализацией технической составляющей.
b) В первую очередь нельзя передавать риск со стороны бизнеса на хостинг провайдера или иное лицо, а следует принять возможные риски описанные в пункте a), по факту уже достигнутых результатов. В данной ситуации следует произвести управление последствиями, чтобы нивелировать воздействие на инфраструктуру и произвести рекомендованные работы по их устранению - самым первым действием устранить публикацию в сети интернет.
Кейс 2 - Описание с упором для развития знаний в PMI
Какие вы видите риски в процессе управления изменениями информационных систем (от постановки задачи от бизнес-заказчика до установки модификации на продакшен) и какими мерами можно предотвратить и/или снизить эти риски?
Скрытый ответ
Выявление – оценка – планирование мероприятий по предотвращению – предусмотренные действия при наступлении – мониторинг. В процессном подходе использую методологию ориентированной на T-профиль команды по DASA DevOps. Применяю Agile-Lean концепции для минимизации потерь и максимизации конвейера потока ценности продукта на базе micro-services. Выстраиванию процессы в зависимости от проектов методики scrummerfall, scrum через transparency, freguent inspection, adaptation. Шаги: CASH - FLOW - COST - SECURITY - LEADTIME - QUALITY. Использую в работе метод Копнена-Трего, аналитику по событию Kaizen (принцип DMAIC) или Kaikaku (радикал) в зависимости от критериев срочности проекта и выходных метрик. Приоритизация осуществляю по KANO, либо MoSCoW. Оценка по RICE. Для более мелких фич используется доставка по JiT.
Просчет работы в процессе спринта по закону Литтла. Основное взаимодействие с командой: Product Vision - Соглашение со стейкхолдерами - Impact Mapping - Product Roadmap to Value и из него вытекающее по процессу SCRUM - вплоть до ретроспективы и аналитики по принципу 5 reasons of why. Ключевое передается заказчику по DoD, в процессе работы для эффективности проектов через DoR (принцип INVEST). Стараюсь придерживаться фокуса на ценности продукта и поставки в спринтах максимально полезного продукта и сверху фич, иногда используется features toggle как триггеры в разработке с проблемными зонами и если необходимо переключение по поставке на не критичны ключах. Не использую gold plating или «марш смерти». Это эффективно по best practise и критерии оцениваются относительно ретроспективы, которая показывает результативности команды от спринта. Оценка проходит согласно с DT по категорированию product backlog в sprint backlog и расписанным ценностям INVEST.
Также риски базируются на основании ожиданий и эмперического контроля. Риски вытекают от начальных этапов построения диалога между командами в формате эпика, для чего требуется детализация на уровне таксономии, придерживаясь бизнес-правил: политики, модели данных, принимание решение пользователем и владельцем исходя из возможных угроз, события, решения системы, жизненные циклы обьектов, вычисления, нормативные документы. Это все выливается в факты, ограничения, активаторы операций, выводы, вычисления.
Далее используется метод Кепнера-Крего через определение проблемы, описание, времени, размеров и затрагиваемых составных частей, установок возможных решений. После чего категорируется в формате классификации предоставленной информации: бизнес-требования, пользовательские требования, бизнес-правила, функциональные требования, атрибуты качества, требования к интерфейсам, ограничения, требования к данным, идеи решений. Впоследствии проходит аналитика по типу задач: описание принципа реализации, установление границ, поиск базовой платформы и альтернатив, разделение пользователей на группы, привлечение влиятельных пользователей. Процесс: роль – требование – обоснование. Все это выявляет и представляет из себя совокупные риски на каждом этапе следования, включая обратрной связи, понятности дадачи, ее полноты и сложности и именно поэтому все вытекает в service relationship management (ITIL, ITSM, XLA/SLA, SMART) с принципами Lean Canvas.
Виды потерь: человеческие, перепроизводство, ожидания, запасы, излишняя обработка, аналитический паралич, лишние движения. В последствии чего получается: kaizen event – value stream mapping – visual management – retrospective – daily standup – five times why. Занимался также планирование по Lean на базе Kanban: BUILD - MEASURE - LEARN - MVP по принципу Fail-Fast. Для команд кроссфункциональных - SCRUM. Ориентация принципа на конечном результате и ответственности за микросервис.
| Группа риска | Примеры рисков |
|---|---|
| Организационные |
|
| Человеческого фактора |
|
| Технические |
|
| Внешние |
|
Кейс 3 - типовая парольная политика контейнеров AD
Если вы проверяете требования к парольной защите, установленные в корпоративном стандарте, какие минимально необходимые параметры вы ожидаете увидеть в этом стандарте и с какими присвоенными им значениями?
Скрытый ответ
Длина пароля должна быть не менее 8 символов, в числе символов пароля обязательно должны присутствовать буквы в верхнем и нижнем регистрах, цифры и специальные символы (@, #, $, &, *, % и т.п.), пароль не должен включать в себя легко вычисляемые сочетания символов - имена, фамилии, номера телефонов и т.д., а также общепринятые сокращения, не должны использоваться автогенераторы, при смене пароля новое значение должно отличаться от предыдущего не менее чем в 8 позициях, личный пароль пользователь не имеет права сообщать никому, не должен быть закреплен на личных пк или записных книжек, кеширован внутри архитектуры active directory, должны быть словари по проверкам пароля и проверка по ним, есть ли коннекторы и как, где хранятся пароли, закешированы ли они и так далее.Кейс 4 - развитие знаний PMI и Compliance
Компания использует решения Oracle в качестве средства автоматизации бизнес-процессов. Решения установлены как на физических, так и на виртуальных машинах. Вам известно, что в Компании отсутствует формализованный процесс управления ИТ активами (и hardware, и software). ИТ-директор сообщает вам о факте недолицензирования продуктов Oracle и затрудняется озвучить детали. Также вам известно, что в последние годы Oracle периодически заказывает аудиты на предмет соблюдения лицензионных требований у конкурентов рассматриваемой Компании в стране её присутствия. Опишите, пожалуйста:
- a) Какие риски вы видите в этой ситуации?
- b) Какие минимальные процедуры вы проведёте, чтобы количественно измерить риски, указанные вами выше? (для тех из них, где возможна количественная оценка)
- c) Какие рекомендации предложите в данной ситуации?
Скрытый ответ
а) штрафные санкции со стороны лицензионной политики; не возможность выхода на IPO и провал аудиторской проверки; эксплуатируемость уязвимостей не пропатченных версий, доступности в инфраструктуру, утечки инфомрации; размножение версий внутри инфраструктуры и на доменных контролерах; отсутствие механизмом контроля, взаимодействия между C-level и подчиненными; отсутствие владельцев ИР, их обслуживания, отказа в обслуживании и SLA/XLA; нарушение ДИ; не контролируемые доступы и отсутствие понимания архитектуры организации, информационных потоков, связей и контроля в ней.
б) построение карты архитектуры инфраструктуры, сетевые шары, сервера; идентификация пользователей; вид информация обрабатываемой на серверах, где крутится решение; версионность решения; интеграционные стыки с не пропатченными решениями; регламенты доступа к ИР; кто имеет доступ и кто ставил версии без лицензии; разбор инцидента и его фиксация.
в) внесение изменений в ОРД типа ПИБО, ДИ; открыть доменную учетку и проверить машины на которых стоят версии oracle через обновление по GPO и в ручном режиме по процессам на стороне терминала дерева процессов – отключить, если не критические узлы, в другом случае – перенести лицензионные версии и восполнить потерю; устранить не лицензионное ПО и обновить имеющиеся узлы; прогнать САВЗ на поиск установщиков и произвести жесткое удаление; проверить доступны на установку машины и учетные данные, которые их ставили, по правам пользования; вынести на help-desk разбор заявок на установку, обновление нелицензионного ПО; произвести внутренние проверки по правам пользователей, не идентифицированным аккаунтам и устранить процесс.
Кейс 5 - акцент на рисках ИБ из внешнего контура
Компания использует терминальные сервера во внешнем сегменте сети для подключения к ним сотрудников при удалённой работе. Сотрудники имеют возможность подключиться к терминальному серверу по rdp с личных устройств. При подключении сотруднику необходимо ввести доменные логин и пароль. Какие риски вы видите в подобной конфигурации и какие меры предложите?
Скрытый ответ
риски НСД ; утечки информации; теневого копирования информации; отказа в обслуживании (если разработчик или доверенное лицо); терминалы требуется перезагружать и несохраненная информация может быть утеряна; возможность подключения к инфраструктуре с любых сторон; отсутствие Паркеровской гексады; нет идентификации пользователя; нет журналирования действий пользователя; свободный доступ к ИС внутри инфраструктуры и т.д. Решение классическое через использования выдачи корпоративного оборудования и его шеринга среди персонала, включая однозначной перепривязки через ТП при выдаче устройства в конечном виде; представить ноутбук как тонкий клиент и на уровне BIOS зашифровать паролем, где при не правильном вводе пароля – он превращается в нерабочее устройство; СДЗ (крайний случай на топ менеджменте ключевого направления, проще выдать арм внутри офиса); СЗИ от НСД типа SNS; DLP; IPS; самое главное отключить возможность rdp из вне и закрыть только на внутреннюю структуру при авторизации под учетной записью MS AD; Cisco AnyConnect и далее VMWare Horizen со сферой внутри инфраструктуры.