Перестройка GRC с нуля: подход Build-First Engineering с Эмре и Чадом из Docker.

Чтобы получить доступ к подробной стенограмме, подпишитесь на рассылку GRC Engineer: grcengineer.com/subscribe Как построить современную программу GRC, если вы унаследовали процессы, разработанные для команды в три раза большего размера, в организации, где «системы соответствия контролировали нас, а не мы их»? В этом эпизоде ​​Эмре Угурлу и Чад Фрайер из Docker делятся своим опытом трансформации функций соответствия, управления рисками и доверия клиентов за последние шесть месяцев с помощью неустанной автоматизации, разработки с использованием ИИ и бескомпромиссного внимания к пользовательскому опыту. Эмре ранее 3,5 года проработал в Plaid, занимаясь принципами GRC-инженерии, а Чад обладает сильным инженерным опытом и специализируется на UX. Вместе с небольшой командой в Docker они доказывают, что для быстрого обеспечения соответствия корпоративному уровню не обязательно иметь огромную организацию GRC. Основные обсуждаемые темы: Философия «разработка собственными силами или покупка готовых решений» Почему Docker по умолчанию использует внутреннюю разработку, и как они перестроили всю свою платформу обучения безопасности за пару недель, достигнув 100% завершения обучения благодаря геймификации и автоматизации. План действий «с нуля» Первые недели: глубокий анализ пробелов, стресс-тестирование средств контроля, совместная оценка эффективности работы команд и создание каналов связи до разработки решений. Модель самоуправляемой команды Три инженера, один аналитик, нет выделенного менеджера GRC. Как автономия и доверие со стороны руководства обеспечивают скорость и инновации. Непрерывное соответствие требованиям в масштабе Переход к полной автоматизации в рамках SOC 2 и ISO 27001, включая разработку пользовательских API с помощью AWS Lambda и EventBridge. Искусственный интеллект как ускоритель разработки Активное использование Claude AI для быстрого прототипирования, дисциплина, необходимая для его эффективного использования (60% правильных ответов), и почему опыт программирования до внедрения ИИ делает вас в 10 раз лучше в его использовании. Пользовательский опыт в GRC Почему, если никто не использует ваше решение, неважно, насколько оно хорошо. Создание решений для внедрения, а не для совершенства. Трансформация TPRM «Мы обещали Стивену, что автоматизируем это до предела» — планы по комплексной автоматизации управления рисками третьих сторон. Инновации в модели затрат Как команда GRC в Docker становится прибыльной функцией, экономя средства и предлагая решения другим внутренним командам. Необходимые навыки Что действительно нужно начинающим инженерам GRC: чтение документации API, принятие неудач, правильная документация и понимание кода на разных языках. 12-месячная стратегия Выпуск инструментов с открытым исходным кодом, контейнеризированные решения для сообщества и цель «превратить GRC в нечто невиданное ранее». Обучение по кибербезопасности с использованием открытого исходного кода уже доступно: https://emreugurlu.github.io/open-sec... Ключевые цитаты: «Вместо того чтобы из кожи вон лезть, мы должны адаптировать это под организацию. Docker действительно уникален по своему принципу работы, и нам приходится соответствующим образом корректировать требования соответствия». — Эмре «Если мы создадим самую крутую вещь на планете, но никто ею не будет пользоваться, это не имеет значения. Во всем, что я делаю, я думаю об удобстве использования». — Чад «В шести случаях из десяти мне приходится поправлять Клода. Способность читать код и понимать ошибочную логику никогда не исчезает». — Эмре «С инструментами, которые у нас есть сегодня, нет оправдания тому, почему кто-то не может создавать вещи самостоятельно». — Эмре «Мы будем командой, приносящей доход». - Чад Временные метки: 00:00 - Введение и информация о гостях 02:39 - Что они унаследовали: Системы обеспечения соответствия требованиям, управляющие организацией 07:50 - Первые недели: Глубокий анализ пробелов и стресс-тестирование средств контроля 11:08 - Структура команды: Самоуправляемые инженеры без руководства GRC 16:07 - Разработка или покупка: Философия Docker, ориентированная на разработчиков 21:22 - Перестройка обучения безопасности: Быстрая разработка до 100% завершения 28:20 - Борьба с JIRA: Преодоление ограничений инструментов 35:07 - Инфраструктура непрерывного соответствия: Переход к полной автоматизации 40:15 - Программа управления рисками: Самообслуживание и минимальное взаимодействие с GRC 45:30 - Интеграция ИИ: Клод как акселератор разработки с надлежащей дисциплиной 50:45 - Фокус на пользовательском опыте: Почему показатели внедрения важнее функций 55:12 - Автоматизация TPRM: «Мы обещали Стивену, что сделаем это» "Автоматизируйте это до предела!" 60:30 - Инновации в модели затрат: GRC как функция, приносящая доход 65:20 - Навыки для начинающих инженеров: API, документация, принятие неудач 70:15 - Видение на 12 месяцев: Инструменты с открытым исходным кодом и трансформация отрасли 🌐 Посетите: grcengineer.com 💼 Св...