Что такое soc. Самый безопасный SOC. Из чего состоит решение на базе MaxPatrol

Мы продолжаем рассказывать о буднях Security Operations Center – о , у заказчиков и , позволяющих нам детектировать атаки на заказчиков и пр.

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

Начнем с самой популярной задачи, без которого сложно представить SOC, – мониторинга инцидентов.

Security monitoring – реальная задача или новая маркетинговая реальность?

Любой опытный безопасник за свою карьеру пережил немало трендов на новые красивые аббревиатуры. Очередные NG-технологии, искусственные интеллектуальные системы, «золотые» и «серебряные» пули защиты от хакеров и таргетированных атак и т.д. Сейчас одним из таких популярных направлений стал мониторинг инцидентов информационной безопасности. При этом эксперты иногда высказываются, что безопасность не требует мониторинга, а требует только активного блокирования. Однако мы считаем иначе – по двум причинам.

Причина первая: динамика развития компаний

«Мир изменился, я чувствую это в воздухе, я чувствую это в воде».
Галадриэль, CSO Лотлориэна

Существуют два глобальных изменения, которые все агрессивнее входят в жизнь каждой компании, обладающих хоть какой-то ИТ-инфраструктурой:

• Инфраструктура изменяется бешеными темпами. В среднем за месяц в компании может появиться 2-3 новых публичных сервиса. За неделю может быть создано до 40-50 новых серверных виртуальных ресурсов, которые в течение пары дней могут из состояния test development без критических данных обрасти ПДн, карточками и коммерческой тайной и отправиться в расширение кластеров mission critical приложений.
• Пользователи все меньше готовы мириться с такими ограничениями, как заблокированные флешки, закрытый доступ в интернет, запрет на собственные устройства в офисе и т. д. И руководство обычно становится на сторону именно таких пользователей, а не безопасника.

Поэтому подход «тащить и не пущать» уже не просто кажется устаревшим, он не применим. Соответственно, остается только попытаться «возглавить процесс»: контролировать подключения к системе и выполняемые на ней действия, фиксировать аномалии и инциденты.

Причина вторая: интеллектуальность атак и средств защиты

«Погоди, Гретель, вот скоро луна взойдет, и станут видны хлебные крошки».
Гензель, 1 level Security Analyst

Попытка взлома, отбитая или заблокированная средством защиты, сегодня уже не является поводом для успокоения, поскольку инструментарий злоумышленников, а следовательно, и сами атаки, непрерывно эволюционируют.

Приведем два простых примера.

1. В компании используется NGFW. Такие системы могут детектировать не только внешние атаки, но и потенциально вредоносную активность внутри сети (например, активность бота). И вот в один прекрасный день NGFW заблокировал попытку одного из хостов подключиться к центру управления бот-сетями вредоносного семейства / отправки информации на сервера, подконтрольные злоумышленникам.

Можно ли утверждать, что на этом инцидент исчерпан? На первый взгляд, да. Наша защита успешно заблокировала подключение, бот не связался с центром управления, и в итоге вредоносная активность в сети не началась. Но давайте копнем глубже: 90% процентов сотрудников компании уже давно пользуются ноутбуками. И если сотрудник решит поработать из дома или из кафе, бот успешно достучится до центра управления, ведь там, за пределами сети предприятия, нет ни NGFW, ни бдительного безопасника. К чему это приведет? На первом этапе – к компрометации всех данных этого ноутбука. На втором – к обновлению протоколов или адресов центра управления бота, что не позволит NGFW успешно блокировать атаку.

2. Уже достаточно давно антивирусные агенты научились выявлять и блокировать хакерские утилиты, например, печально известный mimikatz. И вот мы настроили соответствующую политику в нашей компании и зафиксировали блокировку. На одном из хостов ИТ-администраторов был запущен и заблокирован mimikatz.

Этот пример аналогичен предыдущему – с одной стороны, компрометации учетных записей не произошло, инцидент исчерпан. Но, даже если оставить в стороне ненормальность самой ситуации и желание в ней разобраться (сам ли ИТ-администратор запускал утилиту и для чего), ничто не помешает злоумышленнику еще раз попытаться получить доступ. Он попытается «прибить» процесс антивируса, использует версию, которая антивирусом не определяется, например, при применении powershell-аналогов. В конце концов, просто найдет хост без антивируса и получит интересующую его информацию там.

В итоге, проигнорировав анализ и разбор заблокированной атаки, мы оставляем действия злоумышленников без контроля . И вместо того, чтобы купировать их попытки захватить нашу инфраструктуру, мы оставляем их с развязанными руками, позволяя придумать новый способ атаки и вернуться к ней с ранее захваченных позиций.

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

Говорим мониторинг – подразумеваем SIEM?

Некоторое время назад между темой SOC и мониторинга ставился знак равенства, а дальше он же возникал между понятиями «мониторинг» и «SIEM». И, хотя вокруг этой темы сломано много копий, хочется вернуться к этому вопросу, чтобы он не смущал нас в дальнейшем.

В мировой практике и даже на территории России известны подходы к решению задач мониторинга и построения SOC вообще без применения SIEM. Один из крупнейших и самых успешных SOC прошлого десятилетия был целиком построен на оперативной регулярной работе сотрудников: на высокорегулярной основе дежурная смена анализировала журналы антивируса, прокси, IPS и других средств защиты – где руками, где базовыми скриптами, где умными отчетами. Этот подход позволял закрывать 80% задач baseline мониторинга (к примерам базовых задач и начального подхода я подойду детальнее в следующем разделе).

Так зачем же на самом деле нужна платформа SIEM/Log Management в плоскости задач мониторинга? Попробуем разобрать на примерах.

Use case 1. Собрать все инциденты «в одну кучу».

На первый взгляд эта задача может показаться бесполезной, но, на самом деле, трудно переоценить потребность заказчиков в ее решении. Особенно когда их цель –не обработка каждого детекта со средства защиты, а поиск определенных закономерностей. Например, выявление повторяющихся событий/инцидентов (когда проблема методически не устранена), фиксация странных активностей с одного хоста/на один хост (первые робкие шаги к модному слову kill chain), анализ частотности срабатываний.

Безусловно, для решения столь утилитарной задачи SIEM, по-честному, не нужен. Вполне приемлемым вариантом здесь может стать service desk с учетом заявок и правильная работа с отчетами из него (анализ закономерностей глазами).

Но, тем не менее, когда компания запускает у себя SIEM, ее, как правило мотивирует именно желание собрать все инциденты в едином окне, поэтому включаем этот use case в наш список.

Use case 2. Склеить однотипные инциденты.

Когда речь идет о развивающейся и длительной активности злоумышленника, при неправильной настройке сценария можно столкнуться с явлением под названием «incident storm». Например:

• Сценарий по попытке подбора пароля (более 100 неудачных входов). При попытке ввести пароль 900 раз SIEM создаст, в лучшем случае, 9 инцидентов/кейсов в системе учета (или 9 писем в почте/смс на телефоне – нужное подчеркнуть).
• Сценарий по сканированию сети (не менее 10 хостов по 5 различным портам) – при работе внутреннего сканера будет создано несколько сотен кейсов/писем/смс.

И в этом потоке событий очень легко пропустить инцидент, отличный от указанных активностей. Поэтому правильный SIEM всегда позволит склеить эти активности по ключевым полям, чтобы разбирать их как один общий инцидент.

Use Case 3. Обогатить расследование информацией из дополнительных систем.

После выявления инцидента аналитику обычно предстоит очень большой объем работы по поиску его причин и последствий. Рассмотрим следующий пример: одним из базовых правил мониторинга и контроля во многих международных стандартах является запрет на использование системных неперсонифированных учетных записей в инфраструктуре. И вот перед нами встала задача контролировать вход под учетной записью root на операционной системе Unix. Нужен ли для решения такой задачи SIEM? Безусловно, нет; любой администратор, владеющий основами написания скриптов, с легкостью создаст двухстрочный скрипт, который позволит выявлять такую активность.

Но теперь давайте посмотрим, что нам, как оператору SOC, нужно дальше сделать с этим событием.

Чем отличаются эти два события? Какое из подключений легитимно, а какое нет? Сейчас у нас есть только ip-адрес, с которого выполнялось подключение. Это, безусловно, не позволяет нам локализовать пользователя. Вот как действовали бы мы:

Только получив всю эту информацию, мы можем считать, что в первом приближении определили виновного.

После этого необходимо оценить воздействие на систему, оказанное после входа под системной записью root. При правильно настроенном аудите нам, в принципе, будет достаточно журналов сервера, но есть одно «но»: сам злоумышленник с этими правами мог с легкостью их модифицировать. Что приводит нас к задаче хранения журналов в независимом источнике (одной из задач, которые часто ставят под SIEM). В итоге, анализ этих журналов позволяет оценить проблему и ее критичность.

Безусловно, большую часть этой работы можно выполнить и без SIEM, но тогда на нее уйдет гораздо больше времени, а аналитик столкнется с серьезными ограничениями. Поэтому хотя SIEM и не строго необходим, при проведении расследований он имеет серьезные преимущества.

Use Case 4. Простая и сложная корреляция.

На эту тему написаны уже сотни статей и презентаций, поэтому надолго останавливаться на данном примере не хочется. Скажу еще раз главное: сегодня, чтобы эффективно выявлять и отражать атаки, нужно уметь выявлять корреляции между событиями ИБ. Будет ли это создание и удаление учетной записи в Active Directory в течение подозрительно короткого интервала или выявление продолжительных vpn-сессий (длиннее 8 часов) на межсетевом экране – не важно. Так или иначе, базовыми скриптами или инструментами самого средства защиты эта задача не решается из-за огромного объема проходящих через него событий безопасности. Для решения таких задач и предназначены платформы SIEM.

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

Мониторинг – с чего начать?

Отвечая на вопрос в заглавии этого раздела, большинство заказчиков впадает в одно из двух заблуждений.

Единственной задачей SOC и вообще информационной безопасности является борьба с APT или таргетированными атаками . Наша практика показывает, что до выстраивания базовых процессов мониторинга, наведения порядка в инфраструктуре и «причесывания» процессов реагирования ставить столь амбициозную задачу перед собой не стоит.

О мониторинге можно думать только после того, как вся инфраструктура будет накрыта плотным колпаком из средств защиты и самых современных систем ИБ . По нашим наблюдениям, хороший первый результат по повышению уровня ИБ можно получить, обладая минимальным набором средств защиты. Это подтверждает и , которую мы собираем на регулярной основе: например, в первом полугодии 2017 около 67% событий у заказчиков были зафиксированы при помощи основных сервисов ИТ-инфраструктуры и средств обеспечения базовой безопасности – межсетевых экранов и сетевого оборудования, VPN-шлюзов, контроллеров доменов, почтовых серверов, антивирусов, прокси-серверов и систем обнаружения вторжений.

Итак, процесс мониторинга событий и инцидентов можно начать с достаточно базовых вещей:

• Мониторинг периметра – появляющиеся новые хосты на периметре, эксплуатация критичных уязвимостей, подключения к личным кабинетам и административным интерфейсам с неизвестных адресов.
• Контроль доступа в интернет – попытки использования RAT, посещение вредоносных/фишинговых ресурсов и обращение к центрам управления бот-сетями (как правило, информация о них есть в категориях прокси-сервера).
• Антивирусная защита – заражение серверного сегмента или критичных машин пользовательского сегмента, множественные заражения машин, вирусные эпидемии и т.д.
• Использование хакерского и вредоносного ПО (зачастую информация о нем есть в логах антивирусного ПО и выгружается простым отчетом или запросом к базе данных).
• Анализ подключений в рамках удаленного доступа – одновременное подключение из нескольких точек, подключение с иностранных ip и т.д.
• Контроль учетных записей на Active Directory – создание/удаление, повышение привилегий для ранее существовавших учетных записей, создание новых административных групп и т.д.

Как видите, никакой магии, и даже SIEM-система не нужна. Но выполнение хотя бы этих простых правил и запуск базового мониторинга может стать одним из первых достаточно несложных шагов к вашему движению в экспертные задачи мониторинга и построению собственного Security Operations Center.

Теги:

• solar jsoc
• soc
• кибератаки
• мониторинг инцидентов

Добавить метки

В социальных сетях и блогах не прекращаются обсуждения SOC Forum, состоявшегося в Москве в середине ноября. Модератор пленарной секции Олег Седов попросил спикеров не спорить о терминах и определениях, оставив это для дальнейших обсуждений. Хотелось бы вернуться к отложенной теме, поговорив о терминах, а точнее – о существовании SIEM без SOC и SOC без SIEM.

Что значит «O»?

Участники SOC Forum давали самые разные ответы на вопрос, что такое SOC. Некоторые определения навеки вошли в копилку афоризмов мероприятия и достойны упоминания: «SOC и служба ИБ – одно и то же», «SOC – это подзорная труба», «В "обертку" SOC можно завернуть что угодно, даже регуляторов сверху бантиком привязать». Особенно порадовал ответ «в SOC буква «O» – лишняя, а так все понятно».

И если с Security Center действительно все понятно, то что же означает емкая буква «О» в аббревиатуре? В широком смысле слова под Operations понимают операционную деятельность, что, в свою очередь, является «функцией, направленной на непрерывное выполнение действий по производству одного и того же продукта или предоставление повторяющейся услуги». Получается, что в нашем контексте Operations – это непрерывная реализация процесса обеспечения ИБ или непрерывное сохранение состояния защищенности информационных активов. И ключевое слово здесь – «непрерывное».

Создала ли свой SOC служба ИБ, внедрившая десяток классов средств защиты информации? Выполняет ли функции SOC служба ИБ, которая по запросу рассматривает заявки и согласует/отзывает права доступа, выдает ЭЦП, прописывает правила на межсетевых экранах? Правильно ли назвать SOC-ом процесс латания дыр после очередного нанесения ущерба? Очевидно, что нет.

Кстати, и для западных коллег не все очевидно с терминологией. «Специальная команда, обозначенная здесь как SOC, может в различных организациях именоваться по-разному: CSIRT (Computer Security Incident Response Team – команда реагирования на инциденты компьютерной безопасности), CIRC (Computer Incident Response Center – центр реагирования на компьютерные инциденты), CERT (Computer Emergency Response Team – команда экстренного компьютерного реагирования) или многими другими вариациями с использованием слов «сеть», «компьютерный», «кибер», «инцидент», «операционный», «защита» или «корпоративный» (C. Zimmerman. Ten Strategies of a World-Class Cybersecurity Operations Center, 2014). Но – почувствуйте разницу: пока российское профессиональное сообщество рассуждает о том, что такое SOC, западные коллеги называют целые поколения SOC.

Например, аналитики Ernst&Young насчитали три поколения. Первые SOC полагались на оповещения о срабатывании известных сигнатур вирусов и вторжений, позволяя организациям выявлять хорошо известные профили атак. SOC второго поколения вышли на осознание необходимости функционирования в режиме 24х7 и внедрения активных средств защиты информации для сокращения временного окна между детектированием известной атаки и ее блокировкой. Третье поколение SOC дополнено процессами информационного обмена, аналитики трендов атак и используемого инструментария, наделено функциями поиска аномалий в больших объемах данных – все это для реализации проактивного мониторинга и защиты.

Более детальное разделение, на пять поколений, провели консультанты компании HP Security Intelligence and Operations Consulting (SIOC). Они проанализировали развитие темы SOC с 1975 по 2014 гг., начиная с обособления задачи регулярного рутинного просмотра журналов аудита событий ИБ и заканчивая поколением проактивных подходов к поиску еще не реализованных в отношении компании векторов атак.

SIEM есть, а SOC так и не появился

Недавно в одном из блогов была затронута интересная тема: является ли SIEM продуктом или процессом? Прежде всего, Security Information and Event Management (SIEM) – продукт с заложенной производителем логикой сбора, агрегации и фильтрации, унификации, хранения и поиска, корреляции, оповещения и реагирования, визуализации, разбора/расследования событий ИБ. Но вместе с продуктом пользователь обычно получает описание функций и инструкции, а это – уже процессы. Для некоторых служб ИБ покупка такого продукта станет стартовой точкой в реализации SIEM-процессов, а кому-то, наоборот, потребуется гибкий SIEM-продукт, кастомизируемый под сложившиеся SIEM-процессы компании. Да, бывает, что некоторые SIEM-процессы уже есть, а SIEM-продукта еще нет.

Можно подробнее рассмотреть процессы, выстраиваемые вокруг SIEM-продукта. На этот счет есть много зарубежных рекомендаций, например предлагается разделить процессы на три группы (A. Chuvakin. SIEM analytics: Process matters more than products).

1. Базовые (опорные) процессы описывают следующие процедуры:
   • сбора и настройки аудита на источниках событий ИБ;
   • оценки качества работы SIEM и его развития;
   • настройки контента SIEM (правил, отчетов, дэшбордов и т.п.).
2. Процессы, обеспечивающие соответствие нормативным требованиям, описывают такие процедуры:
   • регулярного просмотра отчетов о событиях ИБ;
   • реагирования на выявленные несоответствия нормативным требованиям
3. Процессы, которые связаны с непрерывным мониторингом в режиме реального времени и проведением расследований (они представляют собой наибольший практический интерес), описывают следующие процедуры:
   • определения очередности обработки оповещений об инцидентах;
   • профилирования поведения пользователей и систем для отсечения ложных оповещений;
   • анализа приходящих извне IoC (indicators of compromise) и оценки их релевантности к инфраструктуре и источникам событий в SIEM;
   • реагирования на выявленные инциденты ИБ;
   • снижения вероятности повторного появления обработанных инцидентов.

Каждая процедура содержит ряд регламентов и инструкций. Команда ИБ-консультантов может составить несколько десятков документов разных уровней, опираясь на ряд рекомендаций, например NIST SP 800-92 «Guide to Computer Security Log Management» и SP 800-61 R2 «Computer Security Incident Handling Guide». Однако общее направление этих документов, думаю, понятно.

Что же такое SOC?

В последние годы интеграторы и производители SIEM активно внедряли в массы представление о том, что SOC – это «SIEM-платформа + SIEM-процессы + персонал». Насколько корректна эта формула, не забыто ли что-то важное?

Чего удалось добиться за рубежом – так это обобщения мнений и наполнения понятия SOC теми идеями и функциями, с которыми согласны большинство специалистов. «SOC – это централизованная корпоративная команда мониторинга безопасности, созданная в целях снижения рисков организации путем использования технологий и процессов для обнаружения инцидентов, их локализации, анализа и снижения ущерба» (Creating an SOC, SANS, 2015). Обратите внимание на ключевой момент «в целях снижения рисков организации», свидетельствующий, во-первых, о понимании рисков, а во-вторых, о целенаправленном продвижении бизнеса в сторону их снижения.

Получается, что SOC начинается не с людей и технологий, а, прежде всего, с понимания миссии и верхнеуровневых задач такой деятельности в компании. Затем для строительства SOC требуется определить ключевые метрики успешности и KPI для их достижения. Отсутствие бизнес-цели при покупке SIEM превратит весь SIEM-процесс в безыдейный мониторинг, который, по статистике Solar Security, перестанет быть интересным для 80% компаний уже через год.

Для создания SOC могут быть использованы такие идеи:

• предотвращение киберпреступлений, нацеленных на быстрый вывод денег из компании;
• сохранение защищенности информационных активов компании в периоды слияний и поглощений;
• предотвращение мошенничества со счетами клиентов и краж денег;
• предотвращение компрометации критически важной клиентской информации, полученной на обработку;
• выявление нарушений режима коммерческой тайны или обращения с другими видами конфиденциальной информации.

Окончательно «прочувствовать» SOC поможет перечень документов, которые, согласно «Ten Strategies of a World-Class Cybersecurity Operations Center», необходимо разработать для организации такой деятельности в компании:

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

Итак, SIEM-продукт внутри SOC – это одна из технологий автоматизации рутинных задач, связанных с обработкой логов. В принципе, SOC без SIEM высокоуровневых целей достигать может – вопрос состоит лишь в эффективности и зрелости применяемых методов. Однако по статистике HP SIOC, которая провела более 110 аудитов 87 SOC, ни один SOC без SIEM не соответствовал даже минимальному уровню зрелости.

Наиболее полное понимание того, как должен быть организован SOC, дает отчет Ernst&Young «SOC against cybercrime». Можно утверждать, что SOC начинается с поддержки высшего руководства, определения миссии, инвестиций и выработки стратегии, продолжается набором персонала, выстраиванием методологии, задействованием необходимых технологий и окружения для минимизации рисков ИБ, анализа трендов и периодической отчетности, а завершается процессами непрерывного совершенствования.

Большую часть задач SOC (прежде всего, обработку событий ИБ в SIEM, аналитику трендов атак, агрегацию информации об угрозах, расследование инцидентов) можно передать на аутсорсинг MSSP-провайдеру. Но, согласитесь, сложно передать на аутсорсинг идею и миссию запуска SOC в компании, ответственность за инциденты и убытки. А об ответственности MSSP-провайдера стоить поговорить отдельно в ближайшем будущем.

Встретил сокращения: SiP и SoC. Что это?

Технология SiP (System-in-Package, «система-в-упаковке») постепенно становится всё более популярной как альтернатива SoC (System-on-Chip, «система-в-чипе»), по крайней мере, для беспроводных решений.

Отличие этих двух подходов заключается в том, что в первом случае в одном корпусе объединяется несколько кристаллов интегральных схем (чипов), а во втором - все узлы будущего готового решения выполняются на одном.

При этом, при использовании технологии SoC дизайнерам приходится тратить больше времени на разработку соединений, оптимизацию расположения элементов и т.п.

Выбор между SoC и SiP всегда очень труден.
Однако, так как многие производственные проблемы и дизайнерские трудности решены или близки к решению, SiP становится более привлекательной технологией, когда времени на создание готового продукта отводится немного.

Особенно это актуально для тех случаев, когда в системе присутствуют узлы для разных стандартов (например, процессор базовой логики для сотовой связи, Wi-Fi и Bluetooth), или когда производитель стремится «воплотить в кремнии» технологию, не прошедшую процесса стандартизации.

Стоимость и время разработки SoC с увеличением сложности дизайна растет экспоненциально, а SiP – практически линейно.

Если же в дизайне присутствуют аналоговые узлы, для их оптимальной работы зачастую требуется использование производственных норм отнюдь не минимальной величины.

Поэтому, если производство логических ИС сейчас проходит этап 65 нм, двигаясь в сторону уменьшения норм, то уже одно только наличие в дизайне аналоговых компонент может заставить производителя выбрать SiP.

К тому же эта технология позволяет разместить достаточное количество пассивных элементов прямо внутри корпуса.

Вполне вероятно, что для полностью логических дизайнов SoC, предоставляющие большое удобство производителям конечных продуктов, еще будут привлекательными долгое время.

SiP обычно используются в небольших электронных устройствах, таких как смартфоны и носимые устройства.
SoC может помочь разработчикам ускорить принятие новых протоколов, таких как Bluetooth 5 SoC, которые облегчают интеграцию Bluetooth 5 в новые продукты.

Драйвер AMD Radeon Software Adrenalin Edition 19.9.2 Optional

Новая версия драйвера AMD Radeon Software Adrenalin Edition 19.9.2 Optional повышает производительность в игре «Borderlands 3» и добавляет поддержку технологии коррекции изображения Radeon Image Sharpening.

Накопительное обновление Windows 10 1903 KB4515384 (добавлено)

10 сентября 2019 г. Microsoft выпустила накопительное обновление для Windows 10 версии 1903 - KB4515384 с рядом улучшений безопасности и исправлением ошибки, которая нарушила работу Windows Search и вызвала высокую загрузку ЦП.

Драйвер Game Ready GeForce 436.30 WHQL

Компания NVIDIA выпустила пакет драйверов Game Ready GeForce 436.30 WHQL, который предназначен для оптимизации в играх: «Gears 5», «Borderlands 3» и «Call of Duty: Modern Warfare», «FIFA 20», «The Surge 2» и «Code Vein», исправляет ряд ошибок, замеченных в предыдущих релизах, и расширяет перечень дисплеев категории G-Sync Compatible.