Короткий путь к Искусственному интеллекту?

Давайте признаемся: мы как-то буксуем. Разработки в сфере ИИ, при всех значительных затратах, не дают ожидаемого «выхлопа». Конечно, кое-чего получается, но дело идет… медленно. Медленнее, чем хотелось бы. Может, задача не решается потому, что решается не та задача?

Сейчас у нас есть много алгоритмов, выполняющих те или иные (отдельные) когнитивные функции. Одни обыгрывают нас в игры, другие водят машины, третьи… Не мне вам рассказывать. Мы создали программы компьютерного зрения, которые различают дорожные знаки лучше, чем мы сами. Программы, которые рисуют и пишут музыку. Алгоритмы ставят медицинские диагнозы. Алгоритмы могут заткнуть нас за пояс в распознавании котиков, но… конкретно этот, который для котиков, ни в чем ином, кроме распознавания котиков. А мы-то хотим такую программу, которая решала любые задачи! Нам нужен «сильный» или «универсальный ИИ», но без собственного сознания, чтоб не смог отказаться решать поставленную задачу, верно? Где нам его взять?

Чтобы понять, как работает интеллект, мы обращаемся к единственному примеру, который у нас есть. К человеческому мозгу, в котором, как мы считаем, «живет» интеллект. Кто-то возразит – мозги есть у многих живых существ! Давайте начнем с червяков? Можно и с червяков, но нам нужен алгоритм, который решает не червяковые, а наши, человеческие задачи, верно?

Наш мозг. Представьте его себе. Два кило (по максимуму) податливого розовато-серого вещества. Сто миллиардов (тоже возьмем по максимуму) нейронов, каждый из которых готов отрастить до десяти тысяч динамических связей – синапсов, которые могут то появляться, то исчезать. Плюс несколько типов сигналов между ними, да еще и глия сюрприз подкинула — тоже что-то проводит, помогает и способствует. (Для справки: нейроглия или просто глия — совокупность вспомогательных клеток нервной ткани. Составляет около 40% объёма ЦНС. Количество глиальных клеток в среднем в 10-50 раз больше, чем нейронов). Дендриты недавно удивили — оказывается, они выполняют куда больше функций, чем считалось ранее (1). Мозг — очень сложная штука. Если не верите — спросите у Константина Анохина. Он подтвердит.

Человек все делает с помощью мозга. Собственно, мы — это и есть он. Отсюда совершенно неудивительным является представление человека о том, что «мозг = интеллект» и еще более неудивительна идея скопировать устройство мозга и — вуаля! — получить искомое. Но мозг — это не интеллект. Мозг — это носитель. «Железо». А Интеллект — это алгоритм, «софт». Попытки повторить софт через копирование железа — это провальная идея. Это культ карго (2). Вы же знаете, что такое «культ карго»?

Аборигены островов Меланезии (увидев во время WWII, как самолеты привозят оружие, продовольствие, медикаменты и многое другое), соорудили из соломы копии самолетов и будку диспетчера, но никак не помогли себе в получении товаров, потому что не имели никакого представления о том, что скрывается за внешним видом самолетов. Так и мы, разобрав до винтиков калькулятор, не найдем внутри ни одной цифры. И, тем более, никакого намека на какие-либо операции с числами.

Пару лет назад Андрей Константинов в одном из номеров журнала «Кот Шрёдингера» (№1–2 за 2017 г.), в своей колонке «Где у робота душа», написал: «Со времён Лейбница мы так и не нашли в мозге ничего, кроме „частей, толкающих одна другую“. Конечно не нашли! И не найдем. По компьютерному „железу“ мы пытаемся восстановить программу, а это невозможно. В качестве подтверждающего аргумента приведу длинную цитату (3):

»…нейробиологи, вооружившись методами, обычно применяемыми для изучения живых нейроструктур, попытались использовать эти методы, чтобы понять, как функционирует простейшая микропроцессорная система. «Мозгом» стал MOS 6502 — один из популярнейших микропроцессоров всех времён и народов: 8-битный чип, использованный во множестве ранних персональных компьютеров и игровых приставок, в том числе Apple, Commodore, Atari. Естественно, что мы знаем об этом чипе всё — ведь он создан человеком! Но исследователи сделали вид, что не знают ничего — и попытались понять его работу, изучая теми же методами, которыми изучают живой мозг.

Химически была удалена крышка, под оптическим микроскопом изучена схема с точностью до отдельного транзистора, создана цифровая модель (тут я немного упрощаю, но суть верна), причём модель настолько точная, что на ней оказалось возможно запускать старые игры (Space Invaders, Donkey Kong, Pitfall). А дальше чип (точнее, его модель) был подвергнут тысячам измерений одновременно: во время исполнения игр измерены напряжения на каждом проводке и определено состояние каждого транзистора. Это породило поток данных в полтора гигабайта в секунду — который уже и анализировался. Строились графики всплесков от отдельных транзисторов, выявлялись ритмы, отыскивались элементы схемы, отключение которых делало её неработоспособной, находились взаимные зависимости элементов и блоков и т. п.

Насколько сложной была эта система по сравнению с живыми? Процессор 6502, конечно, и рядом не стоит с головным мозгом даже мыши. Но он приближается по сложности к червю Caenorhabditis elegans — ломовой лошадке биологов: этот червь изучен вдоль и поперёк и уже предпринимаются попытки смоделировать его полностью в цифровом виде (…) Таким образом, задача анализа системы на чипе 6502 не является чрезмерным упрощением. И результаты имеют право быть экстраполированы на системы in vivo.

Вот только исследователи… потерпели поражение! Нет, какие-то результаты, конечно, получены были. Анализируя чип, удалось выделить функциональные блоки, набросать схему их вероятных взаимосвязей, получить некоторые интересные подсказки насчёт того, как, вероятно, работает микропроцессор в целом. Однако понимания в том смысле, в каком его требует нейробиология (в данном случае: быть способным исправить любую поломку), достигнуто не было".

В какой-то момент появились исследователи, которые стали говорить примерно то же самое — что надо изучать алгоритмы, что нужно понять, какую функцию выполняет интеллект. К примеру, Демис Хассабис (DeepMind), готовясь к выступлению на Singularity-саммите в Сан-Франциско (2010 г.), сказал следующее: «В отличие от других выступлений на саммите по теме AGI, мой доклад будет другим, так как я интересуюсь системным уровнем нейронауки – алгоритмами мозга – а не деталями, как они реализуются мозговой тканью в виде спайков нейронов и синапсов или специфической нейрохимией и т. д. Я интересуюсь, какими алгоритмами мозг пользуется для решения проблем, и которые нам нужно найти, чтобы добраться до AGI».

Однако, спустя 10 (!!!!!) лет, все идет по-прежнему: ученые исследуют мозг и пытаются из внешних проявлений физиологической активности и его внутреннего устройства вычислить, как происходит интересующий процесс. Сколько задач — столько процессов. Люди все разные. Мозги у всех немного, но отличаются. Некая усредненная картина, конечно, имеется, однако… Представьте себе, что в любой произвольный момент времени мозг решает массу, в том числе и «подсознательных» задач, отслеживает и контролирует внутреннее состояние организма, воспринимает и интерпретирует сигналы внешней среды (и это мы не говорим о многочисленных петлях обратной связи). Сможем ли мы уверенно выявить, надежно идентифицировать и четко отделить эти «активности» одну от другой? Возможно ли это в принципе? Честно говоря, сомневаюсь. Не говоря уже о воспроизводимости этих процессов на небиологических носителях…

Просмотрим на ситуацию иначе. Что такое «задача» вообще? Это затруднительная ситуация, с которой сталкивается, и которую пытается разрешить человек. Как показали в середине прошлого века американские математики Герберт Саймон и Аллен Ньюэлл, любая задача в общем виде может быть описана как переход из состояния «Система с проблемой» в состояние «Система без проблемы». Они разработали компьютерную программу, назвав её «General Problem Solver» (Универсальный решатель задач), но дальше решения задач специфического вида они не продвинулись, поэтому универсальность именно их алгоритма осталась под вопросом. Но формула «Система с проблемой» —> «Система без проблемы» оказалась абсолютно верна!

Преобразование Системы — это процесс ее перевода из исходного состояния «с проблемой» в желаемое состояние «без проблемы» (4). В процессе преобразования, (т. е. решения задачи) проблемная система становится беспроблемной (ну или менее проблемной), улучшается, избавляется от своих недостатков и «выживает», т. е. продолжает использоваться. Ой, погодите, что это мы сейчас сказали? Избавление от недостатков? Выживание? Хм… Что-то знакомое. Где-то мы это… Ах, ну да. Эволюция! Чем меньше недостатков — тем больше шансы выжить!

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

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

Слышите треск? Это наши представления о сложности интеллекта начинают трещать по швам. Получается, что бытовавшие ранее понятия «сложность мозга» и «сложность интеллекта» перестают быть тождественными. Что если для «получения Интеллекта» не надо проводить «реверс-инжиниринг» нейрофизиологического процесса решения задачи, ловя призрачные тени мышления в коннектоме (тем более, что у каждого человека он уникален) или заниматься глубоким обучением сетей? Что если… нам нужно алгоритмизировать процесс эволюции системы, т. е. путь ее преобразования из менее совершенного состояния в более совершенное с помощью известных нам законов эволюции? Что если до сегодняшнего дня мы, действительно, решали не ту задачу?

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

Кто-то мне сейчас наверняка возразит: задачи, которые решает человек, связаны с миллионами самых разных систем — природными, общественными, производственными, техническими… Материальными и абстрактными, находящимися на разных уровнях иерархии. И развиваются-де они каждая по-своему, а дарвиновская эволюция — это про живую природу. Зайчики, цветочки, рыбки, птички… Но исследования показывают, что законы эволюции универсальны. Доказательства долго искать не надо – они все перед глазами. Имеющие их да увидят. Что ни возьми — от спички до «Боинга», от танка до… контрабаса — везде (5) мы видим наследственность, изменчивость и отбор! А все многообразие эволюционных изменений (кажущаяся сложность которых связана с тем, что все системы очень разные по своей природе и находятся на разных уровнях иерархии) можно выразить единственным циклом. Вы же помните, да? «Система с проблемой» —> «Система без проблемы».

Что такое «Система с проблемой»? Это Система (материальная и абстрактная, социальная, производственная и техническая, научная и… любая – объект, идея, гипотеза – всё, что угодно), в которой обнаружены какие-то недостатки, влияющие (внимание!) на наше желание и возможность её использования. Система недостаточно хороша. Система недостаточно эффективна. У неё низкое соотношение «польза / затраты». Мы хотим, можем и готовы от нее отказаться, и часто отказываемся. Но нам нужна другая (выполняющая нужную нам полезную функцию), но уже «без проблем» — более эффективная, без недостатков (или с меньшим их количеством). Ну, вы видели эту картинку выше… Конечно, одной «стрелочки» между двумя крайними состояниями (исходным и желаемым) нам мало. Нам нужен тот самый «оператор», «преобразователь», верно? Попробуем его найти? Вы же согласитесь, что в случае успеха мы получим описание (хотя бы, для начала и упрощенное) так нужного нам универсального алгоритма?

Исходная точка – «Система с проблемой». Мы начинаем задумываться о том, чтоб отказаться от её использования. Момент, который мы называем (или ощущаем) «Надо что-то делать!»
Причина, угрожающая выживанию системы – низкая идеальность, выражающаяся в пониженной величине отношения полезных функций системы к функциям затратным (вредным).

Что мы делаем дальше? Мы либо а) создаем новую систему (если система с нужной функций либо не существует, либо у существующей системы нет ресурсов для улучшения) или же б) улучшаем, дорабатываем, существующую (если ресурсы еще есть). Мы изучаем внутреннее устройство и разбираемся с внешним окружением — выявляем внешние и внутренние недостатки Системы и после их устранения получаем улучшенную Систему. Систему с повышенной идеальностью и повышенной жизнеспособностью!

В связи с тем, что представленная выше Схема описывает процесс развития, улучшения или, если хотите, эволюции любых систем (в чем легко убедиться, подставив вместо слова «Система» любое иное по желанию – от «Абажур» до «Якорь»), я думаю, ее смело можно… и даже – нужно! назвать «Универсальной Схемой Эволюции». И обратите внимание — она абсолютно алгоритмична, т. е. полностью подпадает под определение алгоритма: Алгоритм — точное предписание о выполнении в определённом порядке некоторой системы операций, ведущих к решению всех задач данного типа. значит — может быть реализована в виде компьютерной программы).

В представленном виде Универсальная Схема Эволюции:
— естественная — законы эволюции выявлены в системах самого разного типа, и их действие проверено в технике, производстве, обществе, природе и мышлении;
— объективная – законы эволюции не зависят от мнения исследователя и/или пользователя;
— логичная и непротиворечивая – законы эволюции вытекают один из другого;
— полная — набор законов эволюции достаточен для описания любой системы;
— жесткая — законы эволюции нельзя переставлять и
— замкнутая – законы эволюции образуют цикл: система, пройдя один цикл изменений, тут же начинает новый.

Что у нас получается в итоге: Эволюция системы (представленная в виде Универсальной Схемы) — это путь её улучшения, избавления от недостатков. Иными словами, это алгоритм решения задачи. А решение задачи — это именно то, чем занимается интеллект. Упрощаем и получаем: Универсальная Схема = описание функции интеллекта.

Конструктивная критика приветствуется. 🙂

1. «Дендриты важнее для мозга, чем ранее считалось» chrdk.ru/news/dendrity-vazhnee-chem-schitalos
2. ru.wikipedia.org/wiki/Карго_культ
3. Е. Золотов. «Пойми меня! Как неживое помогает разбираться в живом» www.computerra.ru/161756/6502
4. Chapter 6. Problem Solving. Artificial Intelligence. A Knowledge-Based Approach by Morris W.Firebaugh University of Wisconsin – Parkside PWS-Kent Publishing Company Boston 1988, p. 172.
5. Дарвиновская эволюция в мире техносферы. Мир вещей, создаваемый человеком, развивается по тем же законам, что и живая природа. www.ng.ru/science/2017-01-11/14_6899_evolution.html

ссылка на оригинал статьи https://habr.com/ru/post/509892/

Что делать, если брать фронтенд-фреймворк – это излишество

Пример @@include

Современные фронтенд-фреймворки дают удивительные возможности. React, Vue, Angular и другие созданы делать то, что раньше было невозможно, – веб-приложения. В 2020 скачивать и устанавливать приложения уже необязательно. Зачем, если всё можно сделать на сайте?

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

В этом вопросе я поддерживаю "консерваторов". Не нужно писать лендинги и многостранички на Create-React-App, для этого пойдет и обычная статика.

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

Что делать? Писать простыню HTML-разметки в одном файле? Хранить данные во view? Это не сделать шаг назад, это сорваться и упасть в пропасть. Это не просто неудобно, это идет вразрез с современной парадигмой фронтенд-разработки.

Во-первых, data-driven. Данные во главе угла, а внешний вид – лишь их отображение. Пользователь делает действие, данные меняются, вслед меняется отображение. Так работают все современные фреймворки.

Еще один элемент современного подхода – компонентность. Делим приложение на мелкие самодостаточные переиспользуемые куски. Больше переиспользуемости – меньше кода. Меньше кода – меньше багов.

До этого мы уже обсуждали, как реализовать data-driven минимальными усилиями. Мой выбор – Alpine.js. Что же делать с компонентностью? Для простых статических сайтов я предлагаю самый простой вариант – gulp-file-include.

Столько говорил о современности и парадигмах, а закончилось всё библиотекой, которой уже лет 100? Ну, на самом деле, она не такая уж и старая. 4 года с версии 1.0.0, столько же, сколько первой стабильной версии React (15). Да и зачем заново изобретать велосипед, если уже всего готово.

У библиотеки всего шестьсот звезд на Github и 6,5 тысяч скачиваний в неделю на npm, но она дает нам всё, что нужно, чтобы быстро разделить простыню HTML на небольшие удобные компоненты. И при этом не добавив ни байта дополнительного кода в конечный результат.

Единственная преграда – знакомство с Gulp. Ну, на самом деле, писать даже простой лендинг без подобного инструмента сегодня – не очень правильно. Поэтому, если вы не знаете Gulp, узнайте. Вот для этого статья на Хабре, вот ссылка на перевод документации. Мы на этом останавливаться не будем.

Если вы хотите не прерываться, а продолжить со мной, вот ссылка на мой пресет на Github, с которым мы будем работать, там же вы можете найти мой gulpfile.

Итак, что будем делать? Вот это

Что мы будем делать

Выглядит просто. Посмотрим, как это выглядит в HTML.

Как это выглядит в HTML

<section class="text-gray-700 body-font">   <div class="container px-5 py-24 mx-auto">     <h1 class="mb-20 text-2xl font-medium text-center text-gray-900 sm:text-3xl title-font">       Проблемы, которые я решаю     </h1>     <div class="flex flex-wrap -mx-4 -mt-4 -mb-10 sm:-m-4 md:mb-10">       <div         class="flex flex-col items-center p-4 mb-6 sm:flex-row lg:w-1/3 md:mb-0 sm:items-stretch"       >         <div           class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"         >           <svg             class="w-6 h-6"             fill="none"             stroke="currentColor"             stroke-linecap="round"             stroke-linejoin="round"             stroke-width="2"             viewBox="0 0 24 24"           >             <path d="M22 12h-4l-3 9L9 3l-3 9H2"></path>           </svg>         </div>         <div class="flex-grow pl-6">           <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">Оптимизация скорости</h2>           <p class="text-lg leading-relaxed">             Увеличим быстродействие системы при загрузке, уменьшим нагрузку на процессор и оперативную память, исключим из автозагрузки требовательные к ресурсам устройства программы.           </p>         </div>       </div>       <div         class="flex flex-col items-center p-4 mb-6 lg:w-1/3 md:mb-0 sm:flex-row sm:items-stretch"       >         <div           class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"         >           <svg             class="w-6 h-6"             fill="none"             stroke="currentColor"             stroke-linecap="round"             stroke-linejoin="round"             stroke-width="2"             viewBox="0 0 24 24"           >             <circle cx="6" cy="6" r="3"></circle>             <circle cx="6" cy="18" r="3"></circle>             <path d="M20 4L8.12 15.88M14.47 14.48L20 20M8.12 8.12L12 12"></path>           </svg>         </div>         <div class="flex-grow pl-6">           <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">             Восстановление системных файлов           </h2>           <p class="text-lg leading-relaxed">             В случае некорректной работы системы и устройств, проведём анализ системных файлов и восстановим их, если они повреждены.           </p>         </div>       </div>       <div         class="flex flex-col items-center p-4 mb-6 lg:w-1/3 md:mb-0 sm:flex-row sm:items-stretch"       >         <div           class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"         >           <svg             class="w-6 h-6"             fill="none"             stroke="currentColor"             stroke-linecap="round"             stroke-linejoin="round"             stroke-width="2"             viewBox="0 0 24 24"           >             <path d="M20 21v-2a4 4 0 00-4-4H8a4 4 0 00-4 4v2"></path>             <circle cx="12" cy="7" r="4"></circle>           </svg>         </div>         <div class="flex-grow pl-6">           <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">             Установка и обновление драйверов устройств           </h2>           <p class="text-lg leading-relaxed">             При неработоспособности какого-либо из устройств или проблемах, связанных с их некорректной работой, произведём установку, обновление или откат драйверов.           </p>         </div>       </div>     </div>   </div> </section>

Воу! Не так уж и просто, как хотелось бы. Безусловно, TailwindCSS, который здесь используется, тоже даёт о себе знать. Если бы мне пришлось разбираться в этом коде, я бы первым дизлайкнул статью, заявляющую, что TailwindCSS – это новый шаг эволюции. Но нет, я её написал. А всё потому, что этот код можно красиво поделить на компоненты, где эта гора классов превратится в осмысленную картину, которая не только ухудшит, а даже улучшить наш developer-experience.

Но вернемся к плагину. Начнем с небольшой теории. Чтобы с помощью gulp-file-include вставить один HTML в другой, нам нужно написать команду @@include(<путь до файла>, <объект с переменными>).

При этом в gulpfile можно многое настроить под себя. У меня настроено примерно так:

function html() {   return src('src/*.html')     .pipe(fileinclude({ basepath: './src/partials' }))     .pipe(dest('dist')); }

Берем все HTML-файлы из src, прогоняем через наш плагин и кладем в папку dist. При этом в настройки плагина можно передать ряд опций. Быстро пройдемся по ним.

  • prefix – можно изменить префикс с @@ на любой другой.
  • suffix – можно добавить суффикс.
  • basepath – можно настроить, как просчитываются пути в директивах. По умолчанию '@file' – от HTML-файла. Есть еще '@root' – от корня, или любой другой путь. В нашем случае, я создал специальную папку в src partials, где и будут лежать все наши компоненты. Важно правильно настроить Gulp, чтобы эти компоненты не попали в окончальную сборку. В примере выше, Gulp берет только файлы из корня src, не заглядывая в папки. Это то, что нам нужно.
  • filters – позволяет задавать функции, которые потом можно будет запускать из разметки. Смотрите примеры в документации.
  • context – "глобальные" переменные для условий @@if.

Также есть ряд директив:

  • @@include – вставка HTML-файла в другой HTML.
  • @@if – условия; переменные берутся из "глобального" context и/или из объекта переменных использованного @@include.
  • @@for – обычный цикл по массиву из context/переменных @@include.
  • @@loop – проходимся по массиву объектов, используя данные из них как переменные, и вставляем для каждого компонент. Может использовать JSON.

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

В нашем случае нас больше всего интересует @@loop. Мы перенесем все данные из карточек в JSON-файл, создадим компонент и передадим ему его данные, как пропсы.

Что у нас входит в данные? Правильный ответ: заголовок карточки, текст и SVG. В переменные мы можем передавать как просто текст, так и HTML как строку. Он просто подставит её, куда мы скажем.

Вот как выглядит JSON (data.json).

[   {     "title": "Оптимизация скорости",     "text": "Увеличим быстродействие системы при загрузке, уменьшим нагрузку на процессор и оперативную память, исключим из автозагрузки требовательные к ресурсам устройства программы.",     "svg": "<path d=\"M22 12h-4l-3 9L9 3l-3 9H2\"></path>"   },   {     "title": "Восстановление системных файлов",     "text": "В случае некорректной работы системы и устройств, проведём анализ системных файлов и восстановим их, если они повреждены.",     "svg": "<circle cx=\"6\" cy=\"6\" r=\"3\"></circle><circle cx=\"6\" cy=\"18\" r=\"3\"></circle><path d=\"M20 4L8.12 15.88M14.47 14.48L20 20M8.12 8.12L12 12\"></path>"   },   {     "title": "Установка и обновление драйверов устройств",     "text": "При неработоспособности какого-либо из устройств или проблемах, связанных с их некорректной работой, произведём установку, обновление или откат драйверов.",     "svg": "<path d=\"M20 21v-2a4 4 0 00-4-4H8a4 4 0 00-4 4v2\"></path><circle cx=\"12\" cy=\"7\" r=\"4\"></circle>"   } ]

Теперь создадим компонент одной карточки (card.html). Переменные вставляем как @@<имя переменной>.

<div   class="flex flex-col items-center p-4 mb-6 sm:flex-row lg:w-1/3 md:mb-10 sm:items-stretch" >   <div     class="inline-flex items-center justify-center flex-shrink-0 w-12 h-12 mb-4 text-indigo-500 bg-indigo-100 rounded-full"   >     <svg       class="w-6 h-6"       fill="none"       stroke="currentColor"       stroke-linecap="round"       stroke-linejoin="round"       stroke-width="2"       viewBox="0 0 24 24"     >       @@svg     </svg>   </div>   <div class="flex-grow pl-6">     <h2 class="mb-2 text-xl font-medium text-gray-900 title-font">@@title</h2>     <p class="text-lg leading-relaxed">@@text</p>   </div> </div>

Осталось только создать файл секции (index.html).

<section class="text-gray-700 body-font">   <div class="container px-5 py-24 mx-auto">     <h1 class="mb-20 text-2xl font-medium text-center text-gray-900 sm:text-3xl title-font">       Проблемы, которые я решаю     </h1>     <div class="flex flex-wrap -mx-4 -mt-4 -mb-10 sm:-m-4">       @@loop('problems/card.html', 'partials/problems/data.json')     </div>   </div> </section>

Первым параметром в @@loop передаем путь до компонента (от настроенного ранее basepath), вторым – путь до JSON-файла (от src).

Структура файлов выглядит вот так:

src │   index.html │   main.css │ └───partials │   │ │   └───problems │       │   index.html │       │   card.html │       │   data.json ...

Теперь сам index.html я могу вставить с помощью @@include в файл основной страницы.

<!DOCTYPE html> <html lang="ru">   <head>     ...   </head>   <body>     ...     @@include('problems/index.html')     ...   </body> </html>

Минимальными усилиями мы получили полноценное компонентное деление. При этом, это никак не отразится на результате, будет такой же HTML, как и раньше. Конечно, не могу не заметить, что это подкрепляет также тезис про TailwindCSS, – он уже не кажется таким неудобным, как прежде, не так ли? Дальше дело за малым – повторить всё выше перечисленное для всех секций сайта.

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

Напоследок прошу ответить на вопрос:

ссылка на оригинал статьи https://habr.com/ru/post/509694/

Аутсорсинг ИБ, внутренняя безопасность. Куда податься заказчику

Сегодня решили поговорить о том, готовы ли компании отдавать на аутсорсинг внутреннюю безопасность. Многие годы считалось, что нет. Но ситуация меняется. В этом посте не будем говорить про «за и против аутсорсинга», а сделаем обзор, на что может рассчитывать заказчик, если у него уже появилась потребность как-то решать проблему утечек информации.

Сразу оговоримся, мы собирали информацию о тех услугах, которые:

А) подрядчики сами называют аутсорсингом;
Б) аутсорсингом не называются, но по факту решают какой-то вопрос, который мог бы решить специалист в штате (при его наличии).

Поехали.

image

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

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

Вот основные:

1) Нет специалиста в штате или он есть, но перегружен, не специализируется на защите от инсайдерских рисков.
2) Дефицит кадров – компания не может найти ИБ-специалиста нужной квалификации.
3) Нет специализированного ПО для мониторинга в автоматическом режиме.
4) В целом непонятно, сколько стоит информационная безопасность, оправданы ли расходы на организацию всей этой работы.
Если обращаться к зарубежной практике, от которой мы, как принято считать, отстаем лет на 5-10, в защите от инсайдерских рисков на аутсорсе нет ничего необычного. По последним данным Deloitte, 14% аутсорсинговых бюджетов компании в 2019 году потратили на защиту от внутренних рисков. Еще 15% – на обучение персонала кибербезопасности.

Из чего выбирать

Если рассматривать услуги, объединенные термином «аутсорсинг внутренней информационной безопасности», в России сейчас представлены такие:

1) Аудит и анализ состояния ИТ-инфраструктуры.
2) Разработка нормативных документов.
3) Форензика (расследование инцидентов).
4) SOC (организация и обслуживание мониторингового центра).
5) Обучение/тренировка персонала.
6) Сопровождение информационных систем (систем аутентификации и авторизации, DLP, SIEM, IDS/IPS).

Если как-то систематизировать, видим, что есть предложение на то, чтобы закрыть какую-то разовую потребность (посоветоваться или решить точечную задачу) и на заместить функции ИБ-специалиста в долгую.

image

Временная помощь

Так как мы имеем в виду заказчика, перед которым только встал вопрос защиты от утечек данных, запрос к внешнему эксперту тут как правило такой: посмотреть настройки сетевого оборудования, оценить входящий/исходящий трафик, оценить количество внешних подключений к серверам; выстроить систему доступов; решить, какое ПО поставить на тест, а на какое не тратить время, оценить результаты тестов.

Т.е. по большому счету – «только спросить».

Предложения на рынке такого консалтинга разнообразное. На «посоветоваться» всегда можно найти и фрилансера. Но костяк рынка – это учебные центры и компании, специализирующиеся на ИБ ЦИБИТ, «Академия ИБ», АКРИБИЯ, УЦСБ, AZONE IT и другие. (Вынесем за скобки «больших советчиков» с «четверкой» аудиторов во главе – они делят львиную долю мирового оборота от ИБ-консалтинга, но их услуги доступны только крупным заказчикам).

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

При этом для расследования инцидентов информационной безопасности используют не только кибер-методы (здесь самый известный игрок – Group IB). Могут добавляться и «аналоговые» инструменты: анализ документов, опросы сотрудников и т.д. Поэтому, строго говоря, детективы, полиграфологи, профайлеры – это в своих узких задачах тоже участники ИБ-аутсорсинга.

Есть на рынке предложение по тонкой настройке политик безопасности в DLP-системе. По мере внедрения у пользователя могут возникнуть попутные вопросы: как быть с «железом», как настроить допуски, какие документы подписать с сотрудниками. Независимые компании оказывают такие услуги, но по сути – это работа хороших отделов внедрения, инженеров и техподдержки самого вендора.

Рынок пока разношерстный просто в силу своего молодого возраста. Но на нем уже сформировалось изобильное предложение под большинство запросов заказчика в разовой помощи ИБ-специалиста.

Регулярный мониторинг

Если компании нужно решать не разовые задачи, а защищать информацию в постоянном режиме, потребуется DLP-система. Иначе предотвращать, выявлять и разбирать инциденты внутренней безопасности сложно. Без человека, который будет анализировать информацию из нее, софт мало эффективен. Но большинство компаний с коллективами от 100 человек часто просто не могут ответить на вопрос «оно нам надо?»

Поэтому возникает следующий уровень аутсорсинга – отдать за штат управление системой и аналитику инцидентов из DLP. Пока на этом рынке работают единицы (собственно, «СёрчИнформ», Softline, «Инфосистемы Джет»). Услуга реализуется в нескольких форматах в зависимости от уровня доступа, который заказчик готов дать аутсорсеру, то есть от доверия к нему.

Что может делать аутсорсер?

1) Мониторить события и передавать отчеты об инцидентах без какой-то их дополнительной проработки.
2) Делать первичный разбор инцидента, анализировать контекст; экстренно реагировать на критичные нарушения.
3) Делать полноценные расследования инцидента, давать рекомендации по профилактике рецидивов.

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

Из-за того, что рынок еще развивается, заказчику не всегда легко сформулировать запрос, выбрать формат работы с аутсорсером, расставить приоритеты контроля. Соответственно и подписание SLA со старта не всегда возможно.

Тем не менее эффективный формат взаимодействия уже получает очертания. Вот подход, в рамках которого работают зарубежные аутсорсеры (MSSP, Managed Security Services Provider):

1. Персональный ИБ-аналитик настраивает систему в соответствии с задачами, поставленными заказчиком.
2. Заказчику предоставляются максимальные полномочия в системе. Заказчик обговаривает «красные линии» и пожелания (говорит, кого выводит из-под мониторинга, уточняет наиболее актуальные задачи и т.д.)
3. Обнаружив инцидент, ИБ-аналитик связывается с заказчиком по оговоренному каналу связи (задача – донести информацию максимально быстро).
4. Предоставляет отчеты по графику и за выбранный период (раз в день/неделю/месяц).
5. Заказчик может работать в системе вместе с ИБ-аналитиком или самостоятельно.

Скорее всего примерно в таких рамках ИБ-аутсорсинг будет развиваться и дальше, потому что этот формат способствует созданию доверительных отношений между участниками процесса. Но полноценно рынок сформируется еще нескоро, когда-то на нем появится и страхование рисков, которое сильно продвинет отношения клиент/аутсорсер вперед. Но процесс все равно уже идет – мы это видим по реакции заказчиков. Поэтому в пути до «без этого жить нельзя» мы где-то в точке «в этом что-то есть».

ссылка на оригинал статьи https://habr.com/ru/company/searchinform/blog/509436/

Двоичное‌ ‌кодирование‌ ‌вместо‌ ‌JSON

Кодируйте‌ ‌одни‌ ‌и‌ ‌те‌ ‌же‌ ‌данные‌ ‌гораздо‌ ‌меньшим‌ ‌количеством‌ ‌байт.‌ ‌

image

Почему‌ ‌меня‌ ‌это‌ ‌должно‌ ‌волновать ‌


Данные‌ ‌хранятся‌ ‌в‌ ‌памяти‌ ‌в‌ ‌виде‌ ‌структур‌ ‌данных,‌ ‌таких‌ ‌как‌ ‌объекты,‌ ‌списки,‌ ‌массивы‌ ‌и‌ ‌т.д.‌ ‌Но‌ ‌если‌ ‌вы‌ ‌хотите‌ ‌отправить‌ ‌данные‌ ‌по‌ ‌сети‌ ‌или‌ ‌в‌ ‌файле,‌ ‌вам‌ ‌нужно‌ ‌закодировать‌ ‌их‌ ‌в‌ ‌виде‌ ‌последовательности‌ ‌байтов.‌ ‌Перевод‌ ‌из‌ ‌представления‌ ‌в‌ ‌памяти‌ ‌в‌ ‌последовательность‌ ‌байтов‌ ‌называется‌ ‌кодированием,‌ ‌а‌ ‌обратное‌ ‌преобразование‌ ‌–‌ ‌декодированием.‌ ‌Со‌ ‌временем‌ ‌схема‌ ‌данных,‌ ‌обрабатываемых‌ ‌приложением‌ ‌или‌ ‌хранящихся‌ ‌в‌ ‌памяти,‌ ‌может‌ ‌эволюционировать,‌ ‌туда‌ ‌могут‌ ‌добавляться‌ ‌новые‌ ‌поля‌ ‌или‌ ‌удаляться‌ ‌старые.‌ ‌Следовательно,‌ ‌используемая‌ ‌ кодировка‌ ‌должна‌ ‌иметь‌ ‌как‌ ‌обратную‌ ‌(новый‌ ‌код‌ ‌должен‌ ‌быть‌ ‌способен‌ ‌читать‌ ‌данные,‌ ‌написанные‌ ‌старым‌ ‌кодом),‌ ‌так‌ ‌и‌ ‌прямую‌ ‌(старый‌ ‌код‌ ‌должен‌ ‌быть‌ ‌способен‌ ‌читать‌ ‌данные,‌ ‌написанные‌ ‌новым‌ ‌кодом)‌ ‌совместимость.‌ ‌

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

Типы‌ ‌форматов‌ ‌кодирования‌


Существует‌ ‌два‌ ‌типа‌ ‌форматов‌ ‌кодирования:‌ ‌

  • Текстовые‌ ‌форматы‌ ‌
  • Двоичные‌ ‌форматы‌

‌ ‌

Текстовые‌ ‌форматы‌

‌ ‌Текстовые форматы в некоторой степени человекочитаемы. Примеры распространенных форматов — JSON, CSV и XML. Текстовые форматы просты в использовании и понимании, но имеют определенные проблемы:

  • Текстовые форматы могут быть очень неоднозначны. Например, в XML и CSV нельзя различать строки и числа. JSON может различать строки и числа, но не может различать целые и вещественные числа, а также не задает точности. Это становится проблемой при работе с большими числами. Так, проблема с числами, большими чем 253 встречается в Twitter, который использует 64-битное число для идентификации каждого твита. JSON, возвращаемый API Twitter, включает в себя ID твита дважды — в виде JSON-числа и в виде десятичной строки – все из-за того, что JavaScript-приложения не всегда верно распознают числа.
  • CSV не имеет схемы данных, возлагая определение значения каждой строки и столбца на приложение.
  • Текстовые форматы занимают больше места, чем двоичная кодировка. Например, одна из причина заключается в том, что JSON и XML не имеют схемы, а потому они должны содержать имена полей.
{     "userName": "Martin",     "favoriteNumber": 1337,     "interests": ["daydreaming", "hacking"] }

JSON-кодировка этого примера после удаления всех белых пробелов занимает 82 байта.

Двоичное кодирование

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

  1. Thrift
  2. Protocol Buffers
  3. Avro

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

Thrift и Protocol Buffers

Thrift разработан Facebook, а Protocol Buffers – Google. В обоих случаях для кодирования данных требуется схема. В Thrift схема определяется с помощью собственного языка определения интерфейса (IDL).

struct Person {   1: string       userName,   2: optional i64 favouriteNumber,   3: list<string> interests } 

Эквивалентная схема для Protocol Buffers:

message Person {     required string user_name        = 1;     optional int64  favourite_number = 2;     repeated string interests        = 3; }

Как видите, у каждого поля имеется тип данных и номер тега (1, 2 и 3). У Thrift есть два различных формата двоичной кодировки: BinaryProtocol и CompactProtocol. Двоичный формат прост, как показано ниже, и занимает 59 байт для кодирования данных, приведенных выше.

image

Кодирование с использованием двоичного протокола Thrift

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

image

Кодирование с использованием протокола Thrift Compact

Protocol Buffers кодирует данные аналогично компактному протоколу в Thrift, и после кодирования эти же данные занимают 33 байта.

image

Кодирование с использованием Protocol Buffers

Номера тегов обеспечивают эволюцию схем в Thrift и Protocol Buffers. Если старый код попытается прочитать данные, записанные с новой схемой, он просто проигнорирует поля с новыми номерами тегов. Аналогично, новый код может прочитать данные, записанные по старой схеме, пометив значения как null для пропущенных номеров тегов.

Avro

Avro отличается от Protocol Buffers и Thrift. Avro также использует схему для определения данных. Схему можно определить, используя IDL Avro (человекочитаемый формат):

record Person {     string               userName;     union { null, long } favouriteNumber;     array<string>        interests; } 

Или JSON (более машиночитаемый формат):

"type": "record",     "name": "Person",     "fields": [         {"name": "userName",        "type": "string"},         {"name": "favouriteNumber", "type": ["null", "long"]},         {"name": "interests",       "type": {"type": "array",      "items": "string"}}     ] } 

Обратите внимание, что у полей нет номеров меток. Те же самые данные, закодированные с помощью Avro, занимают всего 32 байта.

image

Кодирование с помощью Avro.

Как видно из вышеприведенной последовательности байт, поля не могут быть идентифицированы (в Thrift и Protocol Buffers для этого используются метки с номерами), также невозможно определить тип данных поля. Значения просто собираются воедино. Означает ли это, что любое изменение схемы при декодировании будет генерировать некорректные данные? Ключевая идея Avro заключается в том, что схема для записи и чтения не обязательно должна быть одинаковой, но должна быть совместимой. Когда данные декодируются, библиотека Avro решает эту проблему, просматривая обе схемы и транслируя данные из схемы записывающего устройства в схему читающего устройства.

image

Устранение различий между схемой читающего и записывающего устройства

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

  1. При передаче больших файлов или данных, записывающее устройство может однократно включить схему в начало файла.
  2. В БД с индивидуальными записями каждая строка может быть записана со своей схемой. Самое простое решение – указывать номер версии в начале каждой записи и сохранять список схем.
  3. Для отправки записи в сети, читающее и записывающее устройства могут согласовать схему при установке соединения.

Одним из основных преимуществ использования формата Avro является поддержка динамически генерируемых схем. Так как метки с номерами не генерируются, вы можете использовать систему контроля версий для хранения различных записей, закодированных с разными схемами.

Заключение

В этой статье мы рассмотрели текстовые и двоичные форматы кодирования, обсудили как одни и те же данные могут занимать 82 байта с кодировкой JSON, 33 байта с кодировкой Thrift и Protocol Buffers, и всего 32 байта с помощью кодировки Avro. Двоичные форматы предлагают несколько неоспоримых преимуществ по сравнению с JSON при передаче данных в сети между внутренними службами.

Ресурсы

Чтобы узнать больше о кодировках и проектировании приложений c интенсивной обработкой данных, я настоятельно рекомендую прочитать книгу Мартина Клеппмана «Designing Data-Intensive Applications».

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:


Читать еще

ссылка на оригинал статьи https://habr.com/ru/company/skillfactory/blog/509902/

Реагирование на инциденты: что вам должен SOC


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

Сейчас среди наших заказчиков много таких, кому удобнее получать реагирование как услугу «полного цикла» – в таком случае мы блокируем атаку на средствах защиты компании и сопровождаем процесс реагирования в зоне ответственности ИТ-службы. Например, помогаем с обоснованием блокировок, которые теоретически могут повлечь проблемы в бизнес-процессах, или консультируем по работам, которые частично необходимо провести на их стороне, – блокировке учетных записей, изоляции хоста и т.д.

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

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

В последнее время ответственность за полноту и своевременность реагирования на стороне заказчика все чаще распределяется между ИБ- и ИТ-службами, и вот почему.

Во-первых, инцидентов и подозрений на инциденты стало существенно больше. Если раньше среднее количество оповещений измерялось одной-двумя сотнями в месяц, то сейчас оно увеличилось в несколько раз. Частично проблема состоит в росте энтропии в корпоративных инфраструктурах за счет постоянных (и не всегда фиксируемых) изменений, которые вызваны тем, что сейчас принято называть модным термином «диджитализация» или «цифровая трансформация». Побочным эффектом становится то, что действия пользователей приобретают более широкую вариативность, и технические решения чаще классифицируют их как аномалии в поведении, которые безопасник, в свою очередь, может ошибочно принять за активность злоумышленника. Это ложноположительные срабатывания, скажем так, первого типа.

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

Собственно, это и приводит к тому, что для ускорения процесса реагирования все больше компаний стараются перевести внешний SOC на прямое взаимодействие не с ИБ, а с ИТ-подразделениями. И это весьма логично: инциденты, требующие удаления ПО или блокировки учетных записей, напрямую направляются в ИТ, требующие сетевой изоляции хоста – в сетевые подразделения + helpdesk и так далее. Если же в компании есть собственный центр мониторинга, то его зачастую обязуют передавать в ИТ срабатывания из SIEM-системы.

Однако любое изменение процесса – это риск его замедления, риск неполного информирования сторон и, в конечном счете, снижения эффективности. К счастью, в большинстве компаний это понимают, поэтому (а еще иногда вследствие требований законодательства – в частности, по созданию центров ГосСОПКА) сейчас растет спрос на проверки фактического уровня реагирования – полноты, качества и сроков выполнения рекомендаций со стороны ИТ- и ИБ-подразделений компании.

Однако прежде, чем проводить проверки, надо дать людям в руки инструмент для достижения результата, иными словами – SOC должен адаптировать итоги анализа каждого инцидента для четкой маршрутизации в ИТ. Методом проб и ошибок мы собрали список требований к информации об инциденте, направляемой заказчику.

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

Какие тут есть подводные камни: чтобы правильно определить такого ответственного, надо точно идентифицировать место возникновения инцидента – конкретное отделение, критичность хоста, его бизнес-принадлежность, тип инцидента. Это требует очень глубокого погружения в инфраструктуру заказчика на этапе инвентаризации (и, что очень важно, постоянной актуализации этих данных).

Эта же информация нужна для определения критичности инцидента. Например, на вирусное заражение машины в филиале в Магадане банк готов реагировать существенно медленнее и силами местного специалиста по информационной безопасности. Если же речь идет о местном АРМ КБР, инцидент требует немедленного реагирования и вовлечения, в том числе, CISO заказчика для координации риска, а также специалистов узла связи на площадке для немедленной изоляции хоста.

Реагирование на атаку на веб-приложение в сегменте e-commerce, как правило, требует вовлечения не только безопасников, но и прикладников, которые могут точнее определить риски, связанные с ее реализацией, а выгрузка из базы данных информации о заказах на том же хосте, наоборот, ни в коем случае не должна вовлекать ни прикладников (они одни из потенциальных злоумышленников), ни даже айтишников, зато помимо ИБ зачастую требует участия службы экономической безопасности.

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

Карточка инцидента должна быть адаптирована под специалистов с бэкграундом в ИТ и без знаний в ИБ

Это касается и описания угрозы, и ее рисков, и уровня детальности описания рекомендаций по реагированию. Причем в идеальном варианте последовательность необходимых действий должна быть разделена на дерево обязательных и вспомогательных событий. Например, если SOC зафиксировал запуск Remote Admin Tool на конечном хосте, но уровня аудита недостаточно, чтобы отличить активность пользователя от потенциального запуска backdoor злоумышленником, то первым и обязательным пунктом будет коммуникация специалиста с пользователем для выяснения, он ли инициировал эту активность. При положительном ответе это штатная активность или, как максимум, нарушение политики ИБ. При отрицательном – может быть частью хакерской атаки и требует совершенно других работ по реагированию.

Проверка результатов реагирования должна содержать возможность технического контроля как факта выполнения рекомендаций (с помощью логов в SIEM или других инструментов), так и того, что инцидент не повторится в дальнейшем

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

Наконец, большое значение имеет контекст или дельта-окрестность инцидента. Очень важно, что именно происходило с этой машиной/учетной записью на последнем интервале времени, не было ли похожих или потенциально связанных с ним инцидентов, которые могут собраться в kill chain. Эта информация позволяет быстро определиться, не требуется ли сразу вовлечь в инцидент безопасность или Incident Response Team провайдера.

Каждый SOC ищет свои ответы на эти вызовы и выполнять эти задачи может с помощью разных инструментов, главное контролировать, что он в принципе это делает. Потому что на мелких инцидентах задержки и запинки в реагировании могут быть незаметными, а на критических неотлаженный процесс просто не отработает. И виноватых как будто «не будет».

ссылка на оригинал статьи https://habr.com/ru/company/solarsecurity/blog/509782/