Три вопроса об ответственности за программное обеспечение

Ответственность за программное обеспечение снова витает в воздухе. В Европе Закон о киберустойчивости (CRA) предлагает форму ответственности за цифровые товары посредством подтверждения базовых методов обеспечения безопасности. В процессе это вызвало законный гнев сторонников открытого исходного кода, которые интерпретируют предложение как плохое представление о природе разработки с открытым исходным кодом и сообществах, которые его поддерживают. В Соединенных Штатах Национальная стратегия кибербезопасности Белого дома на 2023 год (NCS) предложила реформировать ответственность за программное обеспечение, чтобы разобраться с тем, как “рынки налагают неадекватные издержки” на отсутствие безопасности и как сегодняшних стимулов “оказалось недостаточно для широкого внедрения передовой практики в области кибербезопасности”.

NCS, CRA и более широкие политические дискуссии не открывают новую банку с червями, а откупоривают знакомую бутылку. Это далеко не первая эпоха дебатов об ответственности за программное обеспечение, и была проведена обширная работа над целями и механизмами юридической ответственности в кибербезопасности и других областях. Ответственность является привлекательным рычагом для достижения лучших результатов в области безопасности или, по крайней мере, более эффективных методов обеспечения безопасности. Условной целью любого режима ответственности за программное обеспечение является либо восстановление пострадавших сторон, либо стимулирование улучшения методов и результатов обеспечения безопасности, либо и то, и другое. В зависимости от ее формулировки ответственность может действовать путем формирования стимулов, а не требовать от регулирующих органов выдавать один инструмент, метод или продукт за серебряную пулю кибербезопасности. Ответственность также может сместить контроль с перегруженных регулирующих органов и позволить пострадавшим сторонам напрямую привлекать компании к ответственности за невыполнение обязательств, как бы это ни было определено.

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

1. Насколько достаточен уровень безопасности? 

Один из способов ориентироваться в лабиринте ответственности за программное обеспечение – взглянуть на проблему, которую оно пытается решить: упрямо сохраняющуюся незащищенность. Дела обстоят хуже, чем нам хотелось бы. Если проблема лежит в основе неэффективного рынка, ответственность может быть просто инструментом для этой работы или, по крайней мере, важным элементом в наборе инструментов. Но этот ход рассуждений пропускает особенности, которыми должна руководствоваться политика ответственности. Например, насколько велики должны быть стимулы для стимулирования улучшений? Рынок программного обеспечения огромен. По оценкам Gartner, в 2021 году только для корпоративных приложений объем рынка составлял 535 миллиардов долларов. Если мы недовольны текущим состоянием безопасности, напрашиваются три объяснения:

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

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

На удивление мало консенсуса в отношении оценки базовых вопросов кибербезопасности. Если предположить, что дела обстоят хуже, чем хотелось бы, то, по крайней мере, лучше ли они были в прошлом году? Некоторые журналисты сообщают, что с каждым годом происходит больше инцидентов. По этим показателям ситуация становится все хуже. Некоторые ученые утверждают, что с каждым годом становится все больше компьютеров, больше людей, больше кода, больше уязвимостей, больше киберпространства и все больше потоков через него — контроль за некоторыми или всеми из них может показать, что со временем ситуация стабильна или даже улучшается, например, количество цифровых данных на душу населения. Другие утверждают, что серьезность инцидентов имеет первостепенное значение — распределение инцидентов имеет неопределенную вариативность, поэтому редкие, но катастрофические случаи, безусловно, наиболее важны, и постоянно растущий потенциал этого класса склоняет чашу весов в сторону ухудшения, поскольку цифровая инфраструктура с каждым днем поддерживает все более важные функции. К сожалению, данных недостаточно. Конгресс только что ввел требования к отчетности для критической инфраструктуры, и для отрасли в целом не существует надежной системы публичного информирования об инцидентах (хотя недавнее принятие правил Комиссией по ценным бумагам и биржам могло бы помочь). Узнать, сколько инцидентов было предотвращено благодаря хорошей безопасности, еще сложнее, если не невозможно.

Если целью предлагаемых рамок ответственности является улучшение результатов в области безопасности, крайне важно понять, как распознать “лучше”, когда мы это видим, и какие методы, инвестиции или стимулы привели к этим улучшениям. Как подчеркивали другие киберэксперты, “объективные эмпирические доказательства того, что представляет собой разумную меру безопасности” в разных контекстах, необходимы для обеспечения того, чтобы режим ответственности стимулировал поведение, которое действительно улучшает результаты. Понимание общей экономической полезности программного обеспечения также помогло бы откалибровать режим ответственности, позволив директивным органам оценить ущерб, связанный с потерей этого преимущества, или оценить потенциальные затраты, связанные с более длительными циклами разработки или более окольными путями сертификации и развертывания.

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

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

Поскольку весь код будет содержать некоторый процент недостатков, которые могут быть использованы, будущее режима ответственности заключается не в создании программного обеспечения, свободного от уязвимостей. Всегда будут компромиссы и всегда будет определенный уровень зрелости компаний в области безопасности — так что, если текущее положение дел является оптимальной точкой или ближе, чем мы думаем? Этот вопрос не подразумевает, что кибербезопасность не может улучшиться, но подчеркивает, что у нас действительно нет способа узнать наше текущее положение относительно этого момента. Возьмем, к примеру, “другую” цель ответственности — примирение потерпевших сторон. Что означает возмещение ущерба в контексте того, что утечка информации навсегда доступна в dark web? При обсуждении ответственности за программное обеспечение укоренилось всеобъемлющее предположение, что стоимость предотвращения инцидентов сопоставима или меньше стоимости устранения последствий инцидента — стоимость первого, включая утраченные инновации, и стоимость второго, включая затяжную катастрофу.

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

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

2. Что мы имеем в виду, когда говорим об ответственности за программное обеспечение на этот раз?

Без конкретики любое обсуждение ответственности за программное обеспечение может стать жертвой нарастающего количества вопросов и дебатов об определениях. Ответственность за программное обеспечение может быть такой же широкой, как и ответственность за весь вред, причиненный программным обеспечением, включая резонансные результаты систем искусственного интеллекта (ИИ) (см. предложенную Европейским Союзом директиву об ответственности за продукцию ИИ и претензии по ответственности за продукцию в отношении алгоритмов рекомендаций в США). В контексте NCS ответственность за программное обеспечение на самом деле означает ответственность за кибербезопасность программного обеспечения — ответственность за ущерб, причиненный уязвимостями кибербезопасности. Тогда возникает еще один естественный вопрос: чья уязвимость? Создатель небезопасного программного обеспечения? Или организации, которые используют небезопасное программное обеспечение в определенном контексте, например, обрабатывают данные клиентов при неправильной настройке? Предложение администрации Байдена, похоже, возлагает ответственность на создателей или поставщиков программного обеспечения — тех «актеров с лучшим положением», которые, по мнению NCS, перекладывают слишком большую ответственность за безопасность на своих клиентов.

Даже если ограничиться кибербезопасностью, среди судов, ученых, аналитических центров и даже промышленности все еще много споров о том, какие формы может принимать ответственность. “Строгая ответственность” возлагает на производителей ответственность за любой плохой результат в области кибербезопасности, вызванный их продуктом, в то время как ответственность по стандарту халатности возлагает на производителей ответственность только тогда, когда плохой результат возникает из-за невыполнения ими “обязанности проявлять осторожность” при создании продукта. Модель “безопасной гавани”, принятая NCS, обеспечила бы общий иммунитет от ответственности производителям, которые следуют определенному набору методов безопасной разработки, независимо от плохих результатов, но во многом упускает из виду контекст, в котором эти методы используются.

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

Еще больше усложняя, программное обеспечение часто предоставляет пользователям гораздо больший выбор — и ответственность за — безопасность продуктов, которые они используют. Операторы должны принимать решения о конфигурации продуктов и способах управления задачами безопасности, такими как исправление и обновление, которые необходимы для безопасности продукта, иногда даже без параметров или конфигураций по умолчанию от поставщиков. С помощью таких практик, как принципы обеспечения безопасности при разработке и развертывании, поставщики могут облегчить пользователям принятие правильных решений и избежать ошибочных, но они по-прежнему не могут гарантировать безопасность систем. Как недавно было включено в сборник афоризмов по безопасности, собранный экспертом по кибербезопасности Хелен Паттон, ты не должен “предлагать технические решения проблем управления”. Любой подход к ответственности за программное обеспечение должен устанавливать ограничения в отношении того, за что должен нести ответственность любой поставщик программного обеспечения, что может быстро усложниться.

Некоторые проблемы, связанные с программным обеспечением, в дискуссиях об ответственности не поддаются четким аналогиям с физическими продуктами: неизбежные факты, что все программное обеспечение уязвимо во все времена, что все программное обеспечение создано на основе чужого программного обеспечения, что многие программные компоненты имеют открытый исходный код и по закону предлагаются “как есть”, что большая часть программного обеспечения классифицируется как услуга, а не продукт, и многое другое. Неточность в отношении этих рисков создает неэффективный, контрпродуктивный режим или затягивает ответственность в бесконечный цикл отсрочек, который проходит через межведомственное управление и Конгресс без разрешения или отсрочки для потребителя.

3. Что пошло не так с существующими стимулами и как нам добиться большего?

Закон об ответственности за продукт – это существующая судебная практика, на которой основывается ответственность за программное обеспечение. Его часто рассматривают как решение для рынков “продуктов, которые обладают заметной полезностью и скрытыми рисками”. Теоретически такие продукты должны иметь тенденцию к сбоям на рынке, поскольку потребители не смогут оценить риск во время покупки, что не даст производителям стимула инвестировать в снижение риска. Поскольку наблюдаемая полезность и скрытые риски описывают проблему безопасности программного обеспечения для всех, абстрактный аргумент в пользу более строгой и ясной ответственности за программные продукты является убедительным — вы часто не знаете, что часть программного обеспечения небезопасна, пока она не была скомпрометирована, и немногие потребители могут самостоятельно провести достаточный аудит кода или производственных процессов. Разумная схема привлекла бы производителя к ответственности, если бы он продавал небрежно собранное программное обеспечение, которое в конечном итоге причинило вред одному или многим пользователям. Если бы потребители могли взыскивать издержки с поставщиков, которые продают более небезопасное программное обеспечение, эти издержки побудили бы компании вкладывать больше средств в создание безопасных продуктов или, по крайней мере, создавать продукты настолько безопасные, насколько это разумно возможно.

Почему регулирующие органы или рынок не могут с самого начала предоставить потребителям более качественную информацию о кибербезопасности? Эта задача — определение набора требуемых показателей отчетности по кибербезопасности или стандартизированных наборов инструментов для ее оценки — сталкивается с той же проблемой, с которой, вероятно, столкнутся попытки определить безопасную гавань ответственности: трудноразрешимость. Просто существует слишком большое разнообразие потребностей в области безопасности, угроз и практик, чтобы объединить их в едином, но удобоваримом формате отчетности, и все это меняется слишком быстро при загрузке, не говоря уже о сомнительной целесообразности ожидать, что конечные потребители сохранят опыт, необходимый для проверки всей этой информации. И здесь недостаточный выбор продуктов во многих технологических вертикалях, вероятно, усугубляет проблему, оставляя пользователей привязанными к определенному программному решению или формату данных и неспособными переключаться в ответ на что-либо, кроме насущной проблемы безопасности. Таким образом, режим ответственности представляется удобным способом создания более сильных стимулов для обеспечения безопасности при одновременном перекладывании значительного бремени оценки риска с потребителей на производителей.

Здесь, однако, возникает другая проблема: уже существуют различные степени ответственности за киберинциденты. Почему этих стимулов недостаточно? Суды налагали значительные штрафы на компании, которые не смогли защитить данные потребителей в соответствии с нормативными обязательствами или их собственными маркетинговыми претензиями. Все 50 штатов имеют ту или иную версию требований к отчетности о нарушениях данных, некоторые из которых требуют от фирм соблюдения стандартов безопасности при защите данных, таких как Центр критического контроля безопасности Интернета или Национальный институт стандартов и технологий Cybersecurity Framework. Это отражает некоторые модели физической ответственности, которые обеспечивают поэтапную проверку в зависимости от потенциального вреда — например, рассмотрите разницу в регулирующем надзоре за вашим местным McDonald’s и вашим местным ядерным реактором. Коллективные иски, иски инвесторов и действия Федеральной торговой комиссии и других киберрегуляторов — все это создает дополнительные карательные стимулы, однако состояние кибербезопасности не удовлетворяет политиков.

Возьмем, к примеру, T-Mobile. Нарушение в 2021 году, затронувшее 76,6 миллиона клиентов T-Mobile, привело к урегулированию коллективного иска, оштрафовав фирму на 350 миллионов долларов и обязав ее потратить дополнительные 150 миллионов долларов на улучшение кибербезопасности – наказание, стимул к улучшению процесса и бюджет на это — все это в совокупности составило второй по величине штраф такого рода, только меньший, чем последствия нарушения Equifax. Тем не менее, менее чем в середине 2023 года T-Mobile столкнулась с еще двумя утечками данных, одна из которых раскрыла информацию о 37 миллионах учетных записей фирмы, что сопоставимо с инцидентом 2021 года. Разработчики режима потенциальной ответственности должны ответить на некоторые важные вопросы здесь. Были ли инвестиции в обеспечение безопасности, предписанные судом, недостаточными или распределялись неэффективно? Был ли штраф — менее половины процента от годового дохода T-Mobile — настолько незначительным, чтобы его игнорировать? Или компания столкнулась с более глубоко укоренившимися системными проблемами, и являются ли эти проблемы уникальными для T-Mobile или широко распространены?

В более грубой формулировке можно просто спросить, существует ли сбой рынка в области кибербезопасности и, если да, то как лучше всего его исправить. Теоретический аргумент прост. Если компания хочет приобрести программное решение у поставщика, способность компании проверять этот продукт на предмет безопасности ограничена, что создает информационную асимметрию — провал рынка. Соображения интеллектуальной собственности, касающиеся продукта, могут разумно ограничить то, насколько его внутренняя работа видна потенциальному потребителю, а экспертный анализ является дорогостоящим. Более того, доступ поставщика к компонентам сторонних производителей в продукте аналогично ограничен. Традиционные рынки продуктов предусматривают ответственность выше по течению, чтобы помочь справиться с этим — иск против поставщика конечных товаров (FGP) может привести к тому, что FGP подаст в суд на поставщиков, которых они считают ответственными, и так далее. Однако, что важно для программного обеспечения, вопрос о том, может ли ответственность в руках конечных потребителей устранить информационную асимметрию на всем пути вверх по цепочке компонентов, не решен. Более того, всегда трудно получить количественные доказательства провала рынка, особенно здесь, учитывая вышеупомянутые проблемы количественной оценки ущерба кибербезопасности и возврата инвестиций в процессы обеспечения безопасности.

Это трудные вопросы, но ответы на них будут информативными. Недостаточность нынешнего лоскутного одеяла кибер-ответственности может быть вызвана сочетанием пробелов в юрисдикциях, ограниченных в ресурсах правоприменителей, недостаточных штрафов, непоследовательных стандартов, неоптимального проникновения вверх по течению и упрямых организационных и отраслевых норм. В частности, поставщики технологий — благодаря соглашениям об условиях предоставления услуг clickwrap, которые часто отказываются от той небольшой ответственности, с которой они сталкиваются, — вероятно, еще более защищены от потенциальных издержек, связанных с утечкой данных и связанными с этим судебными исками, а это означает, что создание даже базовой ответственности за результаты безопасности, возложенной на них, могло бы стать поэтапным изменением. Тем не менее, новый режим ответственности должен, по крайней мере, изучить и понять причины, по которым существующие стимулы для компаний, ориентированных на потребителя, не привели к желаемому улучшению кибербезопасности.

Заключение

Ответственность за программное обеспечение обсуждалась урывками на протяжении десятилетий. Принятие администрацией Байдена концепции в NCS предполагает, что это важный момент для “окна Овертона” по предложениям политики кибербезопасности, но его реализация останется проблемой в нынешнем, фрагментированном политическом ландшафте. Варианты этих трех вопросов будут появляться на протяжении всей дискуссии. Мы предлагаем их в качестве точильного камня для сторонников ответственности, чтобы повысить эффективность любого будущего режима ответственности. И, черт возьми, нам тоже любопытно.

Author: admin