В этом прогнозном эссе описывается вероятность внедрения вредоносного пакета NPM в среду разработки JavaScript.

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

Риск, который мы хотели бы измерить, связан с пакетами NPM. Из-за громких инцидентов, связанных с этой экосистемой, может показаться, что проблемы с захватом пакетов очень распространены. Этот прогноз был специально вдохновлен ноябрьским инцидентом 2018 года с пакетом event-stream. Также была проблема с eslint несколько месяцев назад.

Сначала мы обсудим несколько сценариев, которые вы можете обсудить (или спрогнозировать!), как команда безопасности.

Во-вторых, с помощью панели мы измерим измеримый сценарий.

Полезные сценарии

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

"Пакет, который мы поддерживаем, был скомпрометирован."

Если вы публикуете NPM, вы, вероятно, обеспокоены тем, что он может быть скомпрометирован и опубликован для атаки на тех, кто от него зависит. Это очень похоже на инцидент event-stream, учитывая, что вы являетесь сопровождающим.

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

Например, сравните:

  • 100 разработчиков, не являющихся участниками MFA, используют просочившиеся учетные данные Github с открытым сервером jenkins для публикации обновлений пакетов, от которых зависят сотни тысяч важных приложений.
  • Одинокий разработчик с дипломом MFA, публикующий из защищенной среды CI/CD, тщательно публикующий пакеты, от которых зависят немногие, для приложений с низким уровнем воздействия.

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

«Пакет, от которого мы зависим, был скомпрометирован».

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

«Мы представили скомпрометированный пакет».

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

Прогноз

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

Сколько «вредоносных» бюллетеней опубликует NPM в декабре 2018 года?

Это были грубые принципы, которым следовал судья (я):

С достоверностью 90 % комиссия оценила следующий интервал общих предупреждений, касающихся угнанных пакетов, которые появятся в декабре, между 0–2.777:

Вывод

Мы были правы, всего в декабре было шесть рекомендаций по НПМ, и ни одна из них не соответствовала этому критерию. Ноль находится в пределах диапазона 0-2.777 рекомендаций, и наша результирующая оценка Брайера для правильной панели составляет 0.01.

Это полезно для любой текущей оценки навыка прогнозирования в измерении риска.

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

Но и то, и другое — риски. Простота и частота попадания пакета с опечаткой в ​​заданную среду сборки кажутся строго более важными, чем опасность компрометации существующего пакета. Это, очевидно, может колебаться, учитывая условия конкретной среды (вашей компании). Но они оба опасны.

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

Райан МакГихан пишет о безопасности на Medium.