Drew McCombs, CTO и CISO в Cylerity, объясняет, как он совмещает обе должности. Вопросы безопасности включены в каждый спринт разработки, а проблемы, затрагивающие данные пациентов или движение средств, рассматриваются в первую очередь.

Когда дорожные карты конкурируют

McCombs не разделяет CTO и CISO-задачи на независимые очереди. Безопасность встраивается в каждый спринт как основная функция продукта. Её обсуждают все члены инженерной команды — это держит вопросы защиты в фокусе с самого начала разработки, а не добавляет их в конце.

Полные сканы безопасности входят в требования SDLC для всех версий. Инвестиции в фундамент позволяют быстро доставлять функции без новых рисков.

Когда выбора не избежать: проблема с данными пациентов или с движением средств победит любой feature. Всё остальное балансируется между доставкой функций и равномерным продвижением по основным проектам безопасности.

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

HIPAA и банковские требования: точки конфликта

Cylerity не банк и не скупает дебиторскую задолженность. Компания финансирует организации здравоохранения через кредитную линию банка-партнёра, работает только с учреждениями, не с физическими лицами. Это значит, что многие банковские регуляции её не касаются напрямую — они приходят через условия кредитных соглашений и проверки партнёра.

С HIPAA это сочетается хорошо, но усложняется при обсуждении залога. Компания выдаёт займы под медицинские требования, а в требованиях содержится информация пациентов (PHI). Банку может потребоваться детализация по строкам при расчёте обеспечения займа — и здесь Cylerity принимает специальные меры, чтобы PHI не попала к банку.

Подход: использовать минимум необходимых данных. Обычно это обобщённые цифры на уровне пейера или клиента, без деталей по отдельным требованиям. Если нужна детализация, не передаются идентификаторы требований — создаются собственные уникальные коды. PHI физически отделена от данных для финансирования.

Одно правило для моделей, работающих с деньгами или данными

Модель не принимает решения. AI может рекомендовать, резюмировать, помечать — но человек всегда в цепи между выводом модели и любым действием, высвобождающим средства или открывающим доступ к данным пациентов. Рекомендации помогают работникам принимать обоснованные решения, но решение остаётся за ними.

Объяснимость моделей важна, но это не сам контроль. Рецензент не может одобрить то, что не понимает. Когда модель делает рекомендацию, она показывает источник данных, на которых та основана — и команда проверяет источник, а не объяснение модели. Описание собственной логики моделью — не доказательство.

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

Главная уязвимость малой клиники и дешёвое решение

Главная слабость не уникальна для малых практик. Это обычное дело везде: MFA остаётся одним из важнейших контролей и всё еще недостаточно используется. Для организаций, работающих с Cylerity, это критично. Они созданы для оказания услуг здравоохранения, не для IT, и впервые имеют дело с данными пациентов и платежами.

Дешёвый и действенный fix: включить MFA, начиная с почты. Обычно это уже в цене почтового сервиса. Это закрывает самый частый путь к взлому аккаунта и мошенничеству с платежами.

Cylerity идёт дальше рекомендаций. Компания видит требования и финансирование клиентов в реальном времени, замечает нетипичную активность быстрее, чем небольшая команда. Когда поступает запрос на смену счёта для переводов, Cylerity подтверждает его звонком на номер, уже записанный в системе, а не на номер из самого запроса.

Три вопроса для CISO и ответ, при котором нужно уходить

Первый вопрос: «Назовите каждую сторону, которая касается наших данных, включая субподрядчиков, AI-сервисы, партнёров-кредиторов и их аудиторов». Если поставщик не может быстро выдать список — он не знает, куда идут данные. Важно помнить: кредиторы fintech могут иметь право проверять записи, содержащие информацию ваших пациентов. Об этом нужно узнать до подписания контракта.

Второй вопрос: «Как вы проверяете изменение счёта для переводов средств?» Для fintech переадресация платежей — атака с реальными потерями. Ответ должен описывать внешний канал подтверждения, который нельзя пропустить. Фраза вроде «мы внимательно проверяем запросы» — не подходит.

Третий вопрос: «Опишите первые 24 часа после обнаружения взлома с вовлечением наших данных. Кто кому звонит и когда?» Нужны имена, должности, сроки — не политика на бумаге. Ответ, который должен закончить разговор: «Мы HIPAA certified». Официальной HIPAA-сертификации не существует. Такой ответ говорит, что поставщик либо не понимает правило, либо рассчитывает на вашу неосведомлённость.