Physical Address

304 North Cardinal St.
Dorchester Center, MA 02124

Обзор перспективных исследований за 2024 год. Колонка Дениса Макрушина

Содержание статьи

  • Secure by Design: принципы построения защищенных систем от Google
  • Стратегия выявления угроз: на чем сосредоточить усилия при разработке методов обнаружения?
  • Анализ уязвимостей нулевого дня, которые применялись для атак в прошлом году
  • Повышение уровня наблюдаемости процессов DevSecOps
  • Уязвимости на GitHub: в библиотеке Ruby, которую скачали 250 тысяч раз, в модулях для электронных замков и в популярных играх
  • Подборка исследований с Black Hat 2024
  • RSA Conference 2024: анонсы перспективных технологий
  • Перспективные инструменты: средство для поиска вредоносных зависимостей PyPI и NPM
  • Перспективные инструменты: файл со списком самых популярных паролей
  • О чем может рассказать тень на фото?
  • Критическая уязвимость в сетевом стеке Windows

Се­год­ня погово­рим о самых клас­сных ресер­чах это­го года. Прин­ципы защищен­ного дизай­на от Google, ана­лиз зироде­ев, уяз­вимые пакеты в PyPI и NPM, луч­шие док­лады с кон­ферен­ций RSA и Black Hat.

Во­обще говоря, матери­ал не сов­сем за год: пре­дыду­щую под­борку я пуб­ликовал в апре­ле 2024-го. Но с того вре­мени иссле­дова­тели накопи­ли мно­го все­го инте­рес­ного. Давай прой­дем­ся по ресер­чам и пос­мотрим, что из это­го мож­но будет при­менять на прак­тике, а что прос­то сто­ит закинуть в голову.

 

Secure by Design: принципы построения защищенных систем от Google

Вес­ной это­го года в новых вер­сиях широко при­меня­емой биб­лиоте­ки liblzma наш­ли уме­ло спря­тан­ный бэк­дор, а я тог­да как раз изу­чал документ Secure by Design at Google. В нем инже­неры безопас­ности перес­мотре­ли прин­ципы пос­тро­ения сов­ремен­ных при­ложе­ний.

Цель матери­ала — сок­ратить раз­рыв меж­ду кон­цепту­аль­ными тре­бова­ниями Secure by Design и их прак­тичес­ким при­мене­нием.

Ин­женеры Google стол­кну­лись с вызовом: ско­рость изме­нений в прог­рам­мном обес­печении и в осо­бен­ности в облачном ПО нас­толь­ко высока (нес­коль­ко релизов в день), что не поз­воля­ет реали­зовать сущес­тву­ющие тре­бова­ния безопас­ности, которые акту­аль­ны ско­рее для физичес­ких сис­тем. Потому что в физичес­ких сис­темах пос­ле тща­тель­ного про­екти­рова­ния архи­тек­туры риск появ­ления дефек­тов на эта­пе про­изводс­тва низ­кий по срав­нению с рис­ком появ­ления дефек­тов в ежед­невных обновле­ниях ПО.

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

Еще один инте­рес­ный момент — дизайн‑мыш­ление в тер­минах инва­риан­тов. Инва­риант — свой­ство сис­темы, которое оста­ется неиз­менным при любых дей­стви­ях ее поль­зовате­ля или дей­стви­ях ата­кующе­го. В кон­тек­сте безопас­ности инва­риант озна­чает неиз­меня­емое сос­тояние сис­темы, нап­ример: весь сетевой тра­фик, про­ходя­щий через незащи­щен­ные каналы, всег­да защищен с исполь­зовани­ем надеж­ного про­токо­ла.

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

Кста­ти, ког­да‑то появи­лась кон­цепция «неиз­меня­емой инфраструк­туры» (Immutable Infrastructure), и теперь инва­риан­ты дают архи­тек­тору воз­можность реали­зовать эти прин­ципы на эта­пе раз­работ­ки.

 

Стратегия выявления угроз: на чем сосредоточить усилия при разработке методов обнаружения?

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

Security-инже­неры и ана­лити­ки SOC зна­ют, что клю­чевая цель при выяв­лении угроз — соз­дание механиз­мов для обна­руже­ния и пре­дот­вра­щения как мож­но боль­шего количес­тва методов, которые исполь­зует зло­умыш­ленник для прод­вижения.

Эта цель прев­раща­ется в решение задачи: не допус­тить, что­бы ата­кующий про­шел все эта­пы сво­его пути и остался незаме­чен­ным. С это­го момен­та начина­ется игра веро­ятностей: нас­коль­ко веро­ятно, что ата­кующий пой­дет по пути, который не заметит защища­ющий­ся?

Здесь помога­ет сле­дующая модель:

  • Пред­став­ляем каж­дую тех­нику мат­рицы MITRE ATT&CK в виде точ­ки.
  • Путь ата­кующе­го от получе­ния пер­вично­го дос­тупа до прод­вижения цели мож­но пред­ста­вить в виде опре­делен­ной пос­ледова­тель­нос­ти точек.
  • Тех­ники мат­рицы, у которых есть мно­жес­тво под­техник, мож­но так­же раз­ложить на груп­пы точек (раз­мер груп­пы уве­личи­вает веро­ятность успешно­го при­мене­ния кон­крет­ной тех­ники).
  • Каж­дую под­техни­ку мож­но при­менить с помощью раз­ных про­цедур и инс­тру­мен­тов — это добав­ляет еще боль­ше точек в груп­пы.
  • Так­тика выяв­ления: чем боль­ше про­цедур в рам­ках одной под­техни­ки охва­тыва­ет метод обна­руже­ния, тем луч­ше такой метод. Эффектив­ный метод обна­руже­ния — тот, который выяв­ляет про­цеду­ру с наиболь­шим количес­твом свя­зей с дру­гими про­цеду­рами.

    • И вот тут воз­ника­ет гипоте­за, которую мож­но про­верить в рам­ках иссле­дова­тель­ской работы: сос­тавить граф всех про­цедур MITRE ATT&CK и опре­делить узлы с наиболь­шим количес­твом свя­зей (при­мер на рисун­ке отме­чен жел­тым).

    Граф про­цедур MITRE ATT&CK

    Источник: xakep.ru

    Читайте также:

    Ответить

    Ваш адрес email не будет опубликован. Обязательные поля помечены *