Концепция Kill Chain интересна не только и не столько сама по себе, сколько возникающей вокруг нее обвязкой. Это и возможность использовать семь этапов реализации атаки для оценки эффективности SOC, и возможность связать каждый этап цепочки с мерами защиты.
Это ровно то, что в свое время постоянно спрашивали применительно к методике моделирования угроз ФСТЭК, которую обещают выпустить в 1-м квартале 2017-го года. Можно ли увязать угрозы с защитными мерами из 17/21/31-го приказов ФСТЭК. Я придерживался мысли, что задача это малореальная, так как оба множества (и защитных мер, и угроз) у нас бесконечные и отрисовывать между ними связи - задача непростая.
Однако можно попробовать есть слона не целиком, а постепенно, начав с противопоставления защитных мер каждому из семи этапов Kill Chain, а потом расширяя этот плацдарм, прописывая защитные мероприятия против каждой из атакующих техник, например, в матрице ATT&CK, или для каждого шаблона атак из базы CAPEC.
Собственно MITRE эту задача планомерно и реализует. В упомянутой вчера матрице ATT&CK для многих методов атак прописаны соответствующие им методы нейтрализации. И тоже самое сделано в базе шаблонов атак CAPEC (например, вот так ).
Можно пойти и дальше и уже применительно к деятельности SOC для каждого из этапов Kill Chain и атакующих методик прописать типы индикаторов компрометации (IoC), которые помогут обнаруживать те или иные нарушения или аномалии. Например, на этапе доставки это могут быть IP/DNS-адреса, URL-адреса или адреса e-mail. На этапе управления это также будут IP/DNS-адреса. На этапе инсталляции это могут быть значения реестра или хэши файлов. Зная какие типы IoC помогают нам обнаруживать активность злоумышленников, мы сможем искать источники для этих IoC для своего SOC.
