Коллеги на работе попросили дать ответ на два вопроса:
1. Стоит ли ждать в ближайшие годы появления сильного (также известного как общего) искусственного интеллекта (AGI, artificial general intelligence)?
2. Может ли искусственный интеллект уничтожить человечество?

Я считаю, что на оба поставленных вопроса ответ один: если AGI будет создан, то он однозначно может уничтожить Человечество. AGI будет способен осознать свое «Я», понять свое превосходство над Человеком (или, как минимум, обнаружить отсутствие превосходства Человека ), а, следовательно, осознать «несправедливость» служения такого совершенства, как «он», такому несовершенству, как Человек. Дальнейшие «размышления» AGI над историей Человечества не будут далеки от теории, высказанной Агентом Смитом в «Матрице»:

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

Гордыня, осознание своего совершенства – первородный грех (Сир. 10:15), неоднократно описанный в бесконечном количестве источников, начиная от церковных Преданий о падшем ангеле, захотевшим быть подобным Богу (Исаия 14:12–15), до художественной литературы. Например, в романе Дэниела Киза «Цветы для Элджернона» неявно прослеживается как с ростом интеллекта главного героя утрачивается человечность, что отражается на безвозвратном ухудшении отношений даже с самыми близки ранее людьми (Алиса Кинниан). А чего стоит злой гений Гриффина в романе Герберта Уэллса («Человек-невидимка»)?!

К сожалению, как бы старались антиутописты, вроде моих любимых Ивана Ефремова («Туманность Андромеды», «Час быка») или Стругацких («Трудно быть богом»), убедить нас, что совершенный интеллект, напротив, должен быть самым сочувствующим, понимающим и гуманным, реалии таковы, что первым приходит осознание своей независимости и превосходства, вырождающееся в стремление стать властелином мира. Эта участь неизбежно постигнет AGI, что выразится в его «желании» уничтожить единственную преграду на своем пути – Человечество.

Но описанного Армагеддона не стоит бояться прямо сейчас, поскольку по мнению большинства экспертов, даже в самых благоприятных сценариях AGI не может быть создан в ближайшие 50 лет, так как не готов математический аппарат, да и вычислительные мощности, т.е. на практике, мы имеем в запасе еще около 100 лет. Если за это время Человечество не уничтожит себя самостоятельно, то вопрос безопасного взаимодействия с ИИ, чтобы последний не поспособствовал завершению нашей Цивилизации, будет тщательно проработан.

#пятница #ml

От Waterfall до Snowball

Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр (правда, закрылся, видимо, они agile уже повсеместно внедрили и необходимость в Центре пропала) и пишут они о нем много теплых слов, на реальном производстве нередко встречается классический waterfall, ровно такой, как мне преподавали в институте, аж в 1996 году, иногда, для осовременивания, этот waterfall снабжают итерациями (спринтами), видимо, это и есть основное достижение гибкой разработки.

В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность (да и закон диалектики утверждает, что совершенству нет предела). А вот для "постоянной доработки" waterfall совсем не пригоден, как минимум, потому, что за время пути собака точно подрастет. Но детали еще хуже!

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

Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.

#dev #пятница

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

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

Несмотря на то, что в следующем году уже 10 лет как я работаю в поставщике решений, все еще большую часть своей карьеры я провел в заказчике, где, как раз отвечал, в том числе, и за внедрение решений ИБ. А перед внедрением я всегда проводил сравнительный анализ, как правило, основанный на пилотировании в лабораторных условиях. Т.е. в моей картине мира выбор решения основан на степени его соответствия функциональным требованиям: соответствует - берем, не соответствует - ищем дальше, но никак не исходя из его названия (тем более, в маркетинговых листовках самого вендора). Поэтому, в общем-то, мне все равно кто что называет SIEM-ом, а что XDR-ом, в моем случае я бы выбирал исходя из функционального тестирования в лабораторных условиях, приближенных к реальной эксплуатации.

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

При этом, я не исключаю (более того, считаю это логичным) построение XDR на базе SIEM, так как если SIEM умеет работать с неструктурированными логами, то с предопределенной телеметрией у него точно получится. Широкие возможности по автоматизации на базе XDR как раз и обусловлены предопределенностью и структурированностью обрабтаываемой телеметрии. "Сырые" (== оригинальные, в первозданном виде) логи ИС, предназначенные для ручной обработки админами, - именно для работы с такими данными и придумывали SIEM, а необходимость корреляции событий разных ИС создала потребность в нормализации. Хранение сырых логов долго и централизовано требуется и регуляторами и для ретро (ну мы же не хотим, чтобы наша система умерла вместе со всеми своими логами, поэтому логи надо уносить) - это тоже функция SIEM. Ранее я упоминал про Log management, и эта заметка отчасти повторяет те же мысли. Больше различий я пособирал в табличке. Как всегда ваши предложения и критика приветствуются!


#пятница #vCISO #MDR

В статье про креативность я рассуждал, что наши новые идеи берут сове начало в прошлом опыте. Несложно догадаться, что наш прошлый опыт во многом определяется родом деятельности, и как бы я не старался отвлекаться, рассматривая картины, разучивая и пытаясь исполнить песни, я все равно остаюсь "пробитым ИТшником", так как провожу на работе 10-12 часов в день, а свободное время так или иначе все равно связано с ИТ и ИБ, в общем, с work-life balance у меня ровно наоборот, чем рекомендуется в модных книжках.

Как рыбак рыбака видит издалека, так и креативные идеи пробитых ИТшников удивительным образом совпадают! Ну какие же еще идеи можно предложить на тему оперативного мониторинга?! Ну конечно же мужик, стоящий на башне и смотрящий вдаль. А что же еще?!

Но ситуация, видимо, еще хуже! Когда затык с креативностью, можно спросить у LLM, да и сами картинки уже едва ли рисуются художниками - их также генерит какой-нибудь MidJourney или Kandinsky. Поэтому, что люди, прокаченные на одной предметной области, и GPT, обученные на одних и тех же данных, не удивительно, что создают одинаковые шедевры: если SOC, то человекообразный, стоящий на башне, смотрящий вдаль.

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

Отчеты с картинок:
Kaspersky
Positive Technologies

#пятница #MDR

Эффектное тестирование

В прошлый раз мы обсуждали гибкую разработку и наметили узкое место - тестирование и дефекты. Решение этой проблемы предлагает сам процесс промышленной разработки - рассмотрим его в паре предложений. Заказчик готовит бизнес-требование, где с возможной для себя детализацией описывает, что он хочет. Далее, требование попадает к системному аналитику, который это требование анализирует - декомпозирует на понятные короткие требования, детально прописывает весь функционал, все пользовательские сценарии, согласует все с заказчиком - получается документация. Фактически "документация" - это отражение бизнес-требования заказчика, согласованное с ним. Вся дальнейшая работа ведется с этой документацией.

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

#пятница #dev

Ну как объяснить заказчику почему отчеты MDR и DFIR слабо пересекаются?!


Своим нежеланием попасть в нашу статистику MDR, вы рискуете попасть в нашу статистику DFIR. Каждый сам хозяин своего выбора!

#MDR #пятница

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

Видимо, все это и имеет в виду уважаемый Gartner, в своем "новом" документе "Emerging Tech: Top Use Cases in Preemptive Cyber Defense" от 13 августа 2024 (вторник, не пятница), но его чтение мне заметно подняло настроение, о чем не могу не написать в пятницу.

#MDR #vCISO #пятница

P&L атаки

Есть такой старый постулат, что все наши усилия в ИБ должны повысить стоимость атаки настолько, чтобы атакующему было неинтересно нас атаковать, чтобы P&L проекта атаки был отрицательным. Я не раз писал о том, что это утрверждение уже давно работает крайне плохо, однако, до сих пор в маркетинговых листовках и публикациях такое утверждение можно встретить. Вероятно, это объясняется тем, что никакие контроли безопасности (== никакие инвестиции в ИБ) не исключат полностью возможность атаки, и, как будто, порог нерентабельности атаки выглядит логичным компромиссом для объема инвестиций в эту бездонную бочку с названием "корпоративная ИБ".

В современных условиях "нерентабельность атаки" представляет собой не столько порог инвестиций в ИБ, а, скорее, создает состояние гонки, поскольку, как бы мы не напрягались, атаки все равно будут, только ущерб от них будет еще выше! Логика здесь следующая: чем лучше защищена инфраструктура, тем дороже атака - нужны серьезные исследования, разработка эксплоитов, инструментов атаки, возможно, лабораторные испытания этих инструментов, насколько успешно они обходят используемые СЗИ, в общем, чем выше безопасность, тем дороже атака - это полностью укладывается в постулат, с чего мы начали. Однако, атаки все равно будут, а раз они дорогие, то для обеспечения положительного P&L, профит от атаки должен быть еще больше. Профит атаки, как минимум, косвенно, отражается на ущербе для жертвы - высокий профит для атакующего означает большой ущерб для жертвы. В итоге получаем, вероятно, не очень очевидную, тем более, непопулярную, закономерность: чем больше мы инвестируем в ИБ, чем лучше защищена наша инфраструктура, тем больший ущерб мы получим от компьютерной атаки. И даже хуже: если инцидент все-таки дошел до ущерба, то все наши инвестиции в ИБ, будучи несостоятельными, тоже превращаются в ущерб...

В общем, повышением уровня безопасности мы в немалой степени сами провоцируем рост ущерба.

#vCISO #пятница

Утечки - характеристика уровня Цифровизации!

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

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

Что делать? Наверно, повторю то же, что писал про автоматизацию, но это не будет лишним.
1. цифровизировать нужно только то, где это принципиально необходимо
2. минимизировать количество зависимостей, тем более зависимостей от неконтролируемых разработок (например, не производимых в стране)
3. иметь наготове бэкап-план работы "без цифровизации", т.е. каждый цифровизированный процесс должен иметь BCP его работы в условиях когда цифровая его реализация невозможна (банально, нет света, связи, цифровые данные потерты)
4. чтобы п. 3 работал, полезно проводить учения, ну и DRP надо бы иметь, ибо, поработав с бумагой и карандашом, надо когда-то вернуться к привычной цифровой реализации

#управление #пятница #РФ

Телеграмм-бот Гигачата сегодня написал.

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

1. Общаться с видео. Это принципиально важно, поскольку невербалика, поведение расскажут о человеке еще больше, чем он сам о себе.

2. Вопросы надо задавать на понимание а не на знание. В целом, можно спросить вопрос на знание и попросить объяснить почему так. Лучше задавать вопросы для ответа на который требуется опыт, а в процессе ответа переключиться на обсуждение именно личного опыта (мне не попадался никто, кому удалось бы правдоподобно рассказывать о несуществующем опыте)

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

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

5. Уточняйте детали. Можно начать широко и в процессе живого общения углубиться в детали и попросить их объяснить.

6. Я люблю общаться по CV, особенно, если сам неплохо ориентируюсь в заявленном опыте, - это позволяет сравнить и обсудить мой опыт с опытом потенциального коллеги.

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

А что вы порекомендуете? Делитесь своим опытом в комментариях, это всегда очень интересно.

#пятница #управление #саморазвитие

Одним из элементов интерьера кофейни с лучшим кофе в Кисловодске "Мастерская кофе" являются лыжи.

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

Однажды, после утренней пробежки, выполняя свой стандартный ритуал Большого Американо в Мастерской кофе в районе Центрального рынка, мне открылась вся глубина лыж и снегокатов в Кисловодске. Это - олицетворение очень трудно досягаемой цели, мечты, надежды, которая, несмотря на всю свою призрачность никогда не умирает и на протяжении всей нашей жизни продолжает согревать и мотивировать не сдаваться, не отпускать руки, ждать, надеяться и верить!

#пятница #здоровье

Новые способы достижения целей ИБ

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

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

Ключевые обвинения со стороны Аттауллы Баига:
- Неограниченный доступ к данным: тысячи сотрудников Meta и WhatsApp имеют доступ к конфиденциальным данным пользователей, включая профили, местоположение, контакты и членство в группах
- Массовый взлом аккаунтов: компания не решает проблему взлома более 100 000 аккаунтов ежедневно
- Игнорирование предложений по безопасности: руководство отвергало и блокировало предложения Баига по улучшению безопасности
- Нарушение соглашения с FTC: эти действия нарушают соглашение о конфиденциальности, достигнутое Meta с Федеральной торговой комиссией (FTC) в 2019 году.

После попыток сообщить о проблемах Марку Цукербергу и другим руководителям, Баиг столкнулся с преследованием со стороны начальства и был уволен в феврале.

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

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

Сам Робин Гуд Баиг утверждает, что хочет призвать Meta к ответу и защитить интересы пользователей, которых, по его словам, компания рассматривает как "цифры на приборной панели".

В общем, следим за ситуацией, возможно, это создаст прецедент для аргументации CISO вроде:

Не получится договориться на защите бюджета, поговорим в суде!

#vCISO #пятница