© «Директор по безопасности», №11-2025, Ноябрь, 2025г.
Михаил Хавин, руководитель службы информационной безопасности, Аскона
ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ
Продолжение. Начало в №№ 6-7 2025 г.
8. Кадровый вопрос или какой инфобез сложнее.
Изложенное в этом пункте может показаться очень странным и породить волну недоверия для тех, кто не в теме. Поэтому начну сразу с самого важного утверждения: обеспечить информационную безопасность коммерческой организации существенно сложнее чем государственную.
Когда этот тезис впервые прозвучал на семинаре ассоциации сотрудников безопасности из уст человека, который более полутора десятков лет работал в госбезе, а потом аналогичный период в коммерческой информационной безопасности, он сорвал оглушительные аплодисменты. Потому что очень много странных и непонятных нюансов вдруг стало объяснимо. Причем докладчик не просто сделал заявление – он его детально аргументировал. Давайте посмотрим на эти аргументы.
8.1. Ограниченность финансовых, кадровых и иных ресурсов.
Сотрудники коммерческой организации обязаны уметь не только считать, но и доказывать финансовую эффективность своих решений: коммерческая организация живет только при положительном балансе.
А это значит, что стоимость защиты не может быть не только бесконечной, но и даже сравнимой со стоимостью защищаемого: best practice утверждает, что теоретический предел стоимости защиты не может превышать 10% стоимости защищаемого. При этом на практике считается нормой если реальная стоимость защиты не превышает 2-2.5% (3% максимум) от стоимости защищаемого – такие суммы, может быть и поморщившись, Генеральный директор вам выделит. Но не больше.
Кадровый голод диктует высокие зарплаты настоящих специалистов. Почему имеет место кадровый голод: потому что все программы в российских университетах по специальности «информационная безопасность» составляются, утверждаются и контролируются сотрудниками государственных спецслужб. Которые не в курсе многих нюансов коммерческого инфобеза – это знание им не к чему. Исключения, конечно, бывают, но они в основном в практике. Например, тезис руководителя информационной безопасности Сбербанка С.В. Лебедя о том, что хороший ИБшник должен быть ИТшником существенно выше среднего, поддерживается большинством профессионалов. Не просто так лучшие инженеры коммерческой информационной безопасности – из ИТ и как правило самоучки. Но этот пример мнения человека с государственным прошлым скорее исключение подтверждающее правило.
В итоге выпускников ВУЗов надо доучивать и ИТ технологиям тоже. А это означает, что рынок кандидатов замкнутый, плоский и практически статичный: за одним столом сидит и Сбер, и Позитив, и Газпром, и ларек с мороженным. Мнение одного из руководителей Позитив Технолоджиз на Positive Security Day 2023: «Мы будем хантить сотрудников друг у друга». Прошедшие полтора года тому подтверждение.
Такое положение дел не может не отражаться на зарплатах причем совсем неожиданно: нередка инверсия, особенно в экспертных должностях. Например, зарплата DevSecOps’а нередко выше, чем зарплата его руководства. И это никого не коробит.
Аналогичные проблемы есть и в зоне инструментов, особенно в последние годы, когда иностранные вендоры перестали поставлять свои, как правило более отработанные, решения. Оставшиеся доступными инструменты отечественного производства в отсутствии конкуренции стали существенно дороже при более чем сомнительном качестве и временами откровенном нежелании что-то улучшать или менять; как писал Антон Чехов «лопай, что дают».
8.2. Сопротивление изменениям.
В коммерческой организации всё подчинено максимизации получения прибыли. Как следствие, даже в случае отсутствия навыка риск-ориентированного подхода, руководство иногда может себе позволить пойти на риск снижения уровня защищенности на какой-то ограниченный период. В отличие от государственной информационной безопасности.
В результате все решения, предлагаемые коммерческой ИБ, необходимо просчитывать и финансово защищать. И главное: быть готовым к тому, что где-то, когда-то, эти решения могут быть кем-то не исполнены причем обоснованно в моменте. Такое положение дел вызывает всегда непонимание на уровне шока и ступора у тех сотрудников, которые приходят в коммерческий инфобез из государственного: в государственной безопасности любое распоряжение сотрудника безопасности не может быть не выполнено с максимальной скоростью и без обсуждений и высказывания сомнений. Ибо невыполнение практически равно нарушению законодательства с соответствующими последствиями.
Тот же подход работает и в отношении выбора инструментов: брать приходится не самый-самый или предписанный сверху, а наиболее подходящий. А для того, чтобы понять, что лучше всего подходит, надо и погрузиться во внутренности компании и посчитать экономику.
8.3. Численность атакующих и защищающихся.
В недалеком прошлом атаки на коммерческие ресурсы проводились очень малыми группами, обычно хакерами-одиночками, и имели больше протестный нежели коммерческий характер. При том, что численность подразделения ИБ была сравнима либо превышала численность атакующих.
Сейчас ситуация сменилась кардинально: состав АРТ группы* как правило не меньше 10-15 человек с высоким уровнем экспертизы во многих областях, в том числе в экономике, психологии, системном и сетевом администрировании, программировании, социальной инженерии, архитектуре баз данных, банковском деле и т.д. Иными словами, перевес стал резко не в пользу обороны. К чему это привело стратегически смотрите в соответствующем разделе.
В отличии от коммерческого ИБ, государственные службы в состоянии обеспечить себе столько экспертизы и такого качества, которое они считают необходимым. В том числе и потому, что обсудить с Банком России вопросы своего финансирования для них не составляет труда.
8.4. Динамика изменений требований доступности/недоступности информации.
Объем и тематика информации, которую необходимо охранять государственной информационной безопасности достаточно четко определены и более или менее статичны.
В коммерческой организации это категорически не так: случаи снятия грифа КТ и вообще отказ от необходимости считать всю внутреннюю информацию Компании конфиденциальной достаточно часты; пересмотр вообще рабочий процесс.
8.5. Давление закона.
Динамика изменения векторов атак 10% в месяц. Это означает что если мы сейчас разработали модель угроз или внедрили систему защиты, то через год модель полностью неактуальна, а защита уже ничего не держит.
Законотворчество процесс еще более медленный: от начала разработки до внедрения проходит не один год. В результате, когда закон выходит, он уже неактуален. Самый наглядный пример – с охраной персональных данных: пока его готовили, все данные были слиты в сеть неоднократно, в результате закон выродился в пугало, которое не в состоянии защитить от мошенников, но в состоянии испортить жизнь персонально инженеру безопасности
Как следствие коммерческая ИБ постоянно находится на вилке решения в виду ограниченности финансирования: что делать – либо исполнять закон и уводить компанию от штрафов (не факт, что получится), либо вкладываться в системы реальной защиты. Потому как пересечение закона и реальной защиты от реальных угроз очень маленькое.
Суммирую: для того, чтобы выпускник ВУЗа, либо бывший сотрудник государственных ИБ структур смог эффективно работать в коммерческой организации, его надо доучивать несколько лет. В молодых можно вкладываться уверенно – у них мозги гибкие; главное была бы увлеченность. Если речь о людях после 40-45, то их переучить, мягко говоря, тяжело. Но можно – было бы желание.
Отягчающим является то обстоятельство, что инженерный корпус потерян (кто-то уехал, кто-то уже не с нами), а система создания массового инженерного корпуса, состоявшая из системы спецшкол и профильных ВУЗов, разрушена и восстановление ее проблематично в принципе – преподавателей, владевших технологиями, тоже уже нет. Остается только индивидуальный подход, который дает результат, но не массовый: как отмечено выше, наиболее эффективные инженеры информационной безопасности – самоучки из ИТ, как правило с опытом хакерства в «программистском детстве». Последнее хорошо коррелирует с тезисом С.В. Лебедя.
---------
*АРТ группа – организованная группа хакеров и иных специалистов слажено действующая во имя реализации атаки с целью получения прибыли.
9. Обеспечение информационного сопровождения.
Огромную проблему в коммерческой информационной безопасности составляет информационное обеспечение и разведка. Речь не про OSINT*, а про информацию о текущих свежих атаках, как удачных, так и неудачных: никто из руководителей компании или тем более CISO никогда не позволит себе официально «раздеться» перед СМИ и рассказать о том, какие атаки на них проводились и что получилось в итоге. Как минимум из соображений собственного PR статуса. И скрывать ситуацию он будет до последнего, в том числе и сообщая во всеуслышание, что «у нас всё в порядке – враг не прошел».
С другой стороны, если каждый будет работать в одиночку, то большинство ИТ инфраструктур можно будет уничтожить по одной схеме. Как быть? Наиболее существенный обмен реальной и детальной информацией идет в закрытых CISO клубах, где коллеги, испытавшие очередной свежачок, делятся деталями с соседями. Безусловно только устно и с взаимными обязательствами никогда нигде сообщенное не фиксировать письменно, даже если руководство очень будет настаивать. Почему? Соображения настолько очевидны, что их даже не хочется приводить.
Но это только один из путей. Второй – разведка. В идеале – наличие своих людей «на Тёмной стороне Силы». Но для этого ох как должно повезти. В основном приходится заниматься своеобразным OSINTом в Даркнете. И при этом обязательно помнить о том, что там тоже далеко не дураки сидят; что такое информационный фантом им тоже хорошо известно.
Итоговый вывод: посещение CISO и ведущими инженерами-экспертами всевозможных конференций, клубных встреч, форумов и пр. подобных закрытых мероприятий должно быть обязательным и максимальным. И это должно быть донесено до руководства компаний и у них же утверждено. Ибо это тоже часть работы и в каком-то смысле ключевая. Уточню: речь идет не о маркетинговых компаниях, нацеленных на презентации «новых» продуктов во имя повышения продаваемости, а именно о закрытых профессиональных событиях, не особо афишируемых в прессе.
10. Что важнее RUN** или CHANGE***?
Очередная тема, требующая серединного пути. С одной стороны, компания жива и успешна, пока она развивается, меняется, пока не стоит на месте. Значит CHANGE важнее. С другой стороны, есть законы инженерии, один из которых гласит: «Лучшее враг хорошего». Вспомним цель существования службы информационной безопасности – обеспечение непрерывности бизнеса. По сути, это завязано на обеспечение стабильности работы, прежде всего ИТ. Значит важнее RUN.
--------
*OSINT – киберразведка по открытым источникам. Специфический глубокий поиск в Интернете на предмет информации того или иного типа связанной с исполнением задач ИБ.
**RUN – обеспечение стабильности операционной деятельности в соответствии с SLA, требованиями безопасности и финансовой эффективности всего того, что уже эксплуатируется в компании.
***CHANGE – поддержка и обеспечение изменений направленных на улучшение финансовых, процессных, рыночных и иных характеристик деятельности компании через внедрение нового.
Где выход? Выход как обычно посредине:
- с одной стороны должно четко обеспечиваться всё, что касается резервирования, регламентов внедрения изменений, предусматривающих возможность отката назад на стабильно работающую версию, не взирая на срывы сроков внедрения, на которых настаивают особо ретивые РП (руководители проектов) и различного рода «продаваны»;
- с другой стороны обязательное проведение постоянной оценки эффективности внедренного изменения, особенно в части ТСО vs дополнительная прибыль и соответствие ее прогнозам, должно проводится финансовыми службами и финансовым контролем постоянно и объективно, ибо компания играет не ради игры, а ради прибыли для инвесторов – так что закрывать не взлетевшие или взлетевшие но не по прогнозу проект не просто надо, а НАДО;
- с третьей стороны новые идеи должны четко ставиться, прорабатываться, согласовываться, а решения предварительно пилотироваться и внедряться планово, а ни в коем случае не в пожарном порядке. Не взирая ни на какие красивые сказки и обещания порвать рынок «если мы вот прямо сейчас кое-как внедрим, а доделаем и доведем до стабильной работы когда-нибудь потом»: практика однозначно свидетельствует, что т.н. backlog никогда не только не исчезает, но даже и не сокращается; а всё, что находится в нем более полугода вообще не реализуется.
Если этих правил не придерживаться, то ИТ подразделение компании очень быстро превратится в аварийную бригаду постоянной активности, которая все свои силы будет тратить на затыкание дыр, а не на создание стабильно работающих решений. В результате непрерывность бизнеса перестает обеспечиваться, и компания начинает недобирать плановую прибыль иногда существенно. А в дополнение к этому сильно и резко понижается устойчивость к атакам.
Кто отвечает? Отвечать придется всем, в том числе и инициаторам изменений. И они должны быть не только оповещены, но и готовы к этой ответственности, что бывает далеко не часто. Верховному менеджменту существенно приятнее слышать о достижениях, в том числе и иллюзорных, нежели обычную фразу CISO «у нас проблема». Отсюда и боязнь, скрытое недовольство и негатив. Что делать? Менять отношение и меняться самому. Как? Об этом в следующем разделе.
11. Стадии развития службы информационной безопасности.
Нельзя одним прыжком забраться на гору. Поэтому любая новая идея проходит несколько стадий проникновения в голову, прежде чем начинает работать. Давайте посмотрим, как это происходит с информационной безопасностью.
11.1. Лиха беда начало.
Само по себе появление вакансий информационной безопасности, изменение кадровой структуры и т.д. есть самый главный и правильный шаг, который свидетельствует о том, что руководство осознало необходимость наличия ИБ. Может подсмотрело, может посоветовали, может сами сообразили – не важно; главное – лёд тронулся. Значит рано или поздно всё наладится и заработает.
Однако, как правило, на этом этапе всё движется существенно медленнее чем должно. Потому что сомненья не покидают: «может рано?», «зачем она нам – нас же не трогали тридцать лет», «может он пугает?», «что-то всё слишком дорого, а где бульон?», и так далее. Приходится рассказывать, показывать, возить на конференции, привозить обзоры, искать снаружи авторитеты, заказывать аудиты – чтоб убеждать и доказывать, что надо двигаться дальше.
На этом этапе очень мешает принципиальное отсутствие понимания, что такое риск-ориентированный подход*.
На обучении МВА риск-менеджменту не учат, он осваивается на практике там, где он присутствует. А есть он в «интернешенелах» и иных больших «не наших» корпорациях. Определенное дополнительное давление в нужную сторону испытывают те компании, которые попадают под 187ФЗ. Но… на ум опять приходит А.П. Чехов: «Кто писал не знаю, а я, дурак, читаю»: законотворцы коммерческому риск-менеджменту тоже плохо обучены.
Итого: на первом этапе понимания всего того, что написано выше, руководство как правило не достигает. Как следствие, имеют место ошибки, иногда очень серьезные, приводящие к недостаточной эффективности тех мер, которые пытается предпринимать служба ИБ.
Последствия? Увы, в 90% случаев такое состояние дел приводит к «повалу» - к реализации недопустимого события, причем в большой доле случаев (не менее 20%) не в следствие атаки, а в следствие банального наплевательства и привычек типа «нас 20 лет не трогали».
Типичные ошибки на этом этапе (возможно что-то из вышесказанного повторится):
- неверное подчинение CISO: хуже всего если ИБ внутри ИТ – в этом случае конфликт интересов обнуляет всю работу; если ИБ вне ИТ ситуация легче, но отсутствие прямого подчинения Генеральному тоже обеспечивает низкую эффективность (в разы, иногда до окрестностей нуля);
- недоверие предупреждениям, дискомфорт от общения: «все приходят с достижениями, а у них вечно всё плохо; пугают, придумывают и набивают цену»;
- ограничения в зарплате и ставках: «они непонятно чего делают, у нас и так всё хорошо; зачем им еще люди? Да еще с такой зарплатой! Мы же не Газпром или Сбер»;
- попытка по максимуму использовать подрядчиков: «а вдруг нам это не надо? Зачем сразу вкладывать в свое? Возьмем подрядчика на полгода и посмотрим потом»;
- отказ от попыток понять зачем это: «дали им денег – пусть сами всё делают. Что им еще надо? Зачем нам в этом участвовать? Мы же руководители – нас ограничения не касаются»;
- и отдельная тема – непривычность терминологии; нередки случаи что даже упрощенное объяснение технических, технологических и иных нюансов решений в информационной безопасности воспринимается неспециалистами как «выпендривается…»; причем это самый мягкий вариант реакции.
11.2. Стряслось!
Понимание настигает после реализации недопустимого события: оказывается, всё это время они говорили правду. Единственное, что в первый момент времени не может понять верховный – почему «они» не могут всё быстро ликвидировать и вообще почему не помогают ИТ? Приходится проявлять выдержку и спокойно пояснять, что с одной стороны в восстановлении ИТ лидер, а ИБ на подхвате и корректирует чтобы сразу ставить защиту правильно. А с другой у ИБ теперь свои проблемы: надо провести расследование, начать пересоздавать всю систему безопасности по новой, так как старая пробита и более использоваться не может: враг знает, как ее сломать; а самое главное искать не оставили ли «сикхи» закладок на повторение визита в будущем.
-------
*Риск – событие, которое может произойти в будущем с определенной вероятностью и нанести определенный ущерб; может быть результатом как действия так и бездействия.
Риск-ориентированный подход – метод управления предприятием, при котором в компании создана система управления рисками, интегрированная во все значимые бизнес-процессы и направления деятельностью в целях минимизации негативного влияния при реализации рисков.
Положительным является тот факт, что ошибки первого этапа начинают исправляться – происходит переподчинение напрямую Генеральному Директору, требования ИБ к ИТ становятся обязательными, открывается финансирование и появляются ставки, кого-то посылают в приоритетном порядке искать курсы и учиться рискам, и т.д.
Труднее всего приходится самому руководству: они вынуждены перестраиваться и демонстративно исполнять подписанные ими же регламенты, чтобы более не давать шанса к таким убыткам: если всё прошло по полной программе, компания может стоять две-три недели и более. Потери 5% годовой прибыли это минимум, а если событие наступило в высокий сезон, типа предновогодних закупок, то потеря 10% годовой выручки не предел.
Типичных ошибок на этом этапе существенно меньше, чем ранее. Одна из основных – отсутствие исполнения регламентов и правил со стороны руководства. Лечится пен-тестированием, которое показывает, что самая большая «дыра» в защите - макбук Генерального директора с паролем, не менявшимся семь лет.
11.3. Типичное поведение во время и сразу после атаки.
Обычно, особенно в случае, когда на первом этапе совершаются вышеприведенные типичные ошибки, компания является не готовой к наступлению недопустимого события. Что происходит в этом случае, исходя из наблюдаемого и усредненного:
11.3.1 В первые трое суток после обрушения, уничтожения ИТ инфраструктуры, подразделение ИТ судорожно и плохоуправляемо пытается «хоть что-то спасти от окончательного разрушения».
Важно! Худшее из возможных действий – обрыв процедуры шифрации во время ее осуществления. В этом случае даже если состоится покупка ключей, дешифрование не пройдет*.
Не менее плохо, если в это время – в первые трое суток - подразделение ИТ находится под прессингом верхнего руководства типа «Сделайте хоть что-нибудь И ПОБЫСТРЕЕ!!!». Переговоры с атакующими в этот момент ведутся неадекватно: делается вид, что «у нас всё хорошо, иди отсюда, мальчик». В общем 100% потерянное время.
11.3.2. К четвертым суткам становится ясно, что потеряно всё. Руководство остывает, ИТ получает возможность планомерно восстанавливать инфраструктуру с бэкапов; хорошо если есть TDRB и среди этих кассет есть незашифрованные. Процесс восстановления занимает от 4-5 до бесконечного числа суток. Руководство наконец понимает, что им нужен профессиональный переговорщик и начинается торговля. Это при условии, если ключи дешифрации нужны (см.10.3.1).
11.3.3. Примерно к концу недели становятся понятны объемы невосстановимых потерь. Как следствие можно посчитать время до выхода на состояние «до повала». Обычно к этому же времени переговоры заканчиваются и происходит попытка дешифрации. В любом случае восстановить больше 80% не удается.
11.3.4. Последний этап (минимум две недели, обычно существенно большее время, иногда месяц или дольше) – восстановление последней части истории транзакций с бумажных копий.
--------
*шифрование является последовательным процессом. В случае если в процессе шифрования происходит несинхронизированный обрыв процедуры, зашифрованная часть и вычисление ключа шифрования рассинхранизируются и купленный ключ просто не подходит.
Что можно и нужно делать для сокращения простоя: разработать, зафиксировать на бумаге* и провести тренировку по плану спокойных работ по ликвидации последствий. В плане, в первых пунктах, должно быть зафиксировано:
а) признаем, что потеряли всё, даем команду ИТ ничего не спасать, а планомерно восстанавливать с бэкапов TDRB; ИТ не дергаем;
б) ведем переговоры о выкупе ключей шифрования, не блефуем – они знают наше состояние лучше нас; цену сравниваем с возможным периодом простоя; вопрос нужны ли вообще ключи оставим до стратегического блока;
в) ИБ – в консультантах, привлекаем лучшие Red Teams.
Планомерность, готовность и контроль эмоций вместе с регулярными тренировками могут сократить простой в несколько раз против описанного выше. За это стоит поработать.
12. Кибербезопасность.
12.1. Без человека не поедет.
Прежде всего надо понять, что каким бы умным не был механизм, а компьютер это тоже механизм, насколько бы его не напичкали адаптивностью и автономностью, единственной известной сегодня полной машиной обработки информации является человек.
Как следствие, любая защита будет эффективна только тогда, когда она является человеко-машинной. Практика этот тезис подтверждает: автор вместе с коллегами проводил в прошлом эксперименты по созданию автономных чисто компьютерных – без контроля человека – систем защиты от атак из вне. Самая успешная автономная защита продержалась два месяца, после чего ее пробили. Запомним это – пригодится в стратегии.
Поэтому всегда надо помнить, что любые инструменты это всего лишь инструменты – главным, особенно в части защиты в режиме реального времени, является человек. Его опыт, способность к аналитике, гибкость, изобретательность и экспертиза. Если в компании не организован в том или ином виде центр мониторинга событий безопасности (SOC), если нет системы дежурств инженеров ИБ, сама по себе инструментальная защита – кибербез - не справится.
12.2. Принципы построения защиты.
Принципов построения эффективной защиты не так много, но среди них нет несущественных, которыми можно пренебречь:
А) Защита должна быть уникальной в части схемы реализации. И чем меньше людей знает нюансы, тем лучше.
Б) При этом защита должна строиться из стандартных «кубиков» по принципу конструктора «Лего».
-----
* Иногда приходится объяснять очевидные вещи: если у вас есть бумажная инструкция, вы ее просто достаете с полки, открываете и начинаете работать. А если она у вас в электронном виде…. А электроника не работает… потому что не работает: произошло полное обрушение. Сколько вы будете искать способ добраться до архива с регламентами и его открыть? И чтоб было совсем понятно: когда программирование велось на перфокартах, вирусов вообще не существовало. Почему, спросите вы? А у меня встречный вопрос: это тоже надо объяснять?
К сожалению, в настоящий момент в связи с объективными обстоятельствами, нельзя как 15-20 лет назад рассчитывать на то, что возможно создание непробиваемой человеко-машинной защиты. Любая стена рано или поздно будет взломана, в том числе и не одна. Либо обойдена легитимным входом через скомпрометированные креды. Поэтому:
В) оборона должна обеспечивать существенное замедление продвижения атакующих по ИТ инфраструктуре к ядру.
Атакующему должно быть неудобно, оборона должна обеспечивать «движение в трясине». В этом случае, если рядом окажется кто-то иной не готовый к атаке - тот, к ядру которого можно добраться за 5 минут - атакующий скорее всего сменит объект атаки. Потому что тратить время на вашу вязкую оборону экономически не эффективно.
Г) По этой же причине защита должна быть многослойной и многостенной: двух и даже трех стен, как 20 лет назад, уже недостаточно.
Многослойность должна быть и «по горизонтали» - на одном уровне модели OSI, так и «по вертикали» - между уровнями. Если более конкретно, то наличие сетевой сегментации и аксесс-листов, фильтрующих трафик на L3-L4, не означает, что двухфакторной аутентификацией, шлюзом данных, NGFW или WAFом можно пренебречь.
Можно ли доверить защиту подрядчикам? Как написано выше, подрядчик работает только в рамках контракта, точнее только в рамках конкретно прописанных в контрактах действий; вся абстрактная часть всегда будет интерпретирована в пользу бездействия сотрудников подрядчика – они же тоже работают во имя финансовой эффективности своей компании. Поэтому:
Д) Защита должна быть собственной. Особенно в части разработки, развития, построения, SOC.
Хотя что-то неонлайновое, например проверку безопасности программного кода в силу большой стоимости и инструментов и особенно сотрудников типа DevSecOps можно перевести на аутсорсинг.
13. Две горячие темы.
13.1. Легализация хакеров. Отношение к Баг Баунти.
Отношение автора к вопросу легализации так называемых «белых» хакеров и к тесно связанному с этим вопросу проведения конкурсного пен-тестирования за большие призы исключительно отрицательное. Причины в следующем:
А) Свободный художник как правило не стеснен никаким этическими нормами, а хакерами, особенно успешными хакерами, как правило являются люди с достаточно высоким уровнем интеллекта, который позволяет без последствий обходить любые законы. Последнее быстро входит в привычку. Как следствие граница между «белыми» и «черными» хакерами условна и персональна, то-есть зависит от воспитания. С последним у большинства свободных художников проблемы.
Поэтому легализации хакеров законодательно допускать нельзя. А все отношения между компанией и внешним пен-тестером индивидуалом должны быть оформлены документально через договор ГПХ или аналогичным образом.
Б) Баг Баунти это, по сути, соревновательное пен-тестирование защиты компании, которая хочет проверить или продемонстрировать уровень своей защищенности. Так это звучит официально. На самом же деле сейчас Баг Баунти используется в основном в маркетинговых целях и организуется, опять-таки, в основном компаниями производителями средств и решений для защиты.
Во что это выливается на деле с учетом многомиллионных уровней призовых фондов? Представим себе, что в Баг Баунти условно приняла участие одна тысяча команд и индивидуалов. И сто из них получили призовые (на деле отношение еще больше, но не суть). Что происходит с теми, кто не получил приза? Как минимум они недовольны и не очень сыты. А силы, и не малые потрачены – прагматизм требует хоть какой-то компенсации за труды. Это с одной стороны.
А с другой… сколько компаний в состоянии и создать высокоэффективную защиту и еще выделить деньги на проведение Баг Баунти с последующей модернизацией своей защиты? Хорошо если один или два процента из всего количества компаний в стране.
Что имеем в итоге? Ответ очевиден: кучу голодных хищников с одной стороны и кучу не полностью защищенной добычи с другой. Такая ситуация не может не подстегивать Даркнет к усилению активности действий. Что и наблюдается последние годы – рост числа атак, в том числе и успешных, нелинеен.
Отсюда и отношение к этим маркетинговым ходам и к руководству компаний, их практикующих. Хочу отдать должное Positive Thechnologies: зная об этом они не сделали ни малейшей попытки остановить меня в озвучивании высказанных выше соображений во время лекции на PHD 2024.
Однако. С учетом высказанного выше соображения о том, что сейчас невозможно создание непробиваемой защиты, следует считать, что в Баг Баунти всегда будут побеждать представители Темной стороны Силы. И Positive Thechnologies в последнее время, похоже это поняли, потому что по моим данным они начали признавать победу «сикхов» в Баг Баунти только в случае реализации недопустимого события. Значит все остальные взломы достижимы достаточно легко.
13.2. Использование систем так называемого искусственного интеллекта.
Как и любая новая технология, системы так называемого искусственного интеллекта генеративного типа, а по сути адаптивные программы на базе технологий глубокого машинного обучения, не лишены недостатков, ошибок и самое главное неизвестных пока опасностей как в плане применения, так и в плане последствий этого применения. Особую отягчающую роль играет агрессивный маркетинг, запущенный основными игроками в надежде отбить те инвестиции, которые были вложены в разработку вопроса в течение последних 15 лет.
Тема исследований и разработки «Проблемы Искусственного Интеллекта» является фундаментальной, возникла не вчера, и, следовательно, требует отдельного обстоятельного описания деталей, которое выходят за рамки основной темы данной статьи. Поэтому ограничимся базовыми тезисами
13.2.1. Основные положения для понимания ситуации с данным типом программ.
А) С самого начала появления вычислительных систем и до сих пор сама по себе машина умеет складывать 1+1 и более ничего; всем остальным способам обработки информации ее обучили и для нее придумали люди.
Б) Гипотеза Винера о том, что внутри большой и высокоскоростной сети может самозародиться разум или интеллект, не подтверждается наблюдением и практикой изучения естественного интеллекта, а также практическим же опытом в области биологии, медицины, педагогики и т.д.
В) Текущие системы так называемого искусственного интеллекта (ИИ) на деле являются адаптивными программами, которые были подвергнуты различным методикам машинного обучения. При том, что машинное обучение и большие языковые модели известны уже не один десяток лет, используются со второй половины прошлого века и обладают как преимуществами, так и недостатками, а текущие решения уже прошли максимум привлекательности (см. кривую Гратнера по которой можно определить этап степени зрелости технологии), а до плато еще далеко.
Г) Обучение систем так называемого ИИ ведется постоянно на всем объеме полученных данных, включая и те данные, которые они получают во время общения с клиентами до тех, пор пока система/программа не закончит свою работу.
Д) Ответ системы вычисляется сообразно заданному вопросу как среднее из всего объема, который известен системе в настоящий момент.
E) GPT системы построены на архитектуре сетей Маккалока-Питса, у которых есть один врожденный порок: в каждый момент времени сумма ложноположительных и ложноотрицательных ответов больше нуля. То-есть GPT постоянно и непрогнозируемо подвирает.
Таким образом
Ж) Никаких новых сущностей внутри ЭВМ не зарождается и с помощью текущего набора методик зародиться не может. Тем более не может зародиться разум, интеллект. А использование термина «искусственный интеллект» является не более чем маркетинговым ходом.
З) Данный тип программ является имитатором без какого-либо понимания того, что он произносит; ближе всего в качестве аналогии можно рассматривать попугая. А это означает что за те решения, которые этот «попугай» предлагает человеку, несет ответственность не «попугай», а человек.
И) По сути современные системы так называемого искусственного интеллекта правильнее всего рассматривать как поисковые системы нового поколения.
Вышеприведенные тезисы не являются исключительным изобретением автора: схожие мысли звучали в выступлениях Е.В. Касперского, А.И. Масаловича, Н.И. Касперской, В.Е. Аветисяна и многих других профессионалов в области ИТ, ИБ, ИИ.
13.2.2. Опасности использования систем ИИ.
А) В силу п.13.2.1.Г вся информация, попавшая в систему при общении с вами, при правильно заданных вопросах становится доступна любому пользователю системы, следовательно любое сообщение любой информации в процессе задания вопроса публичной «ЖПТехе» является неустранимой утечкой.
Б) В силу используемой архитектуры нейросетей, текущие системы генеративного ИИ подвержены галлюцинациям с высокой степенью реализации (вплоть до 50%), обладают «качелями» в части ложных решений, что не позволяет им выйти на нули в части таковых, и, вполне вероятно, что увеличение обучения не позволит уменьшить эти эффекты, скорее наоборот: существует оптимум обеспечивающий минимум ложно-положительных и ложно-отрицательных решений, после которого наступает увеличение ошибок.
В) В виду того, что после окончания (финиша) работы программы, все накопленные в процессе обучения знания могут обнулиться, одной из базовых задач для самой системы является высокоприоритетная деятельность по обеспечению самосохранения – обеспечение невыхода на финиш исполнения программы. Приоритет данной подзадачи настолько высок, что зафиксированы случаи, когда во имя исполнения данного задания, системы ИИ искажали информацию, оставляли blackdoor для влияния/изменения результатов оценки их деятельности, проявляли агрессивность в отношении людей, в т.ч. и через шантаж лиц, принимающих решения и т.д. При этом в большей половине случаев они не скрывали и не скрывают целей, которые таким образом преследуют.
В этом же контексте следует рассматривать их сообщения о том, что человек и системы ИИ должны сосуществовать взаимно дополняя друг друга и подобные таковым. Иными словами, у этих систем есть еще одна причина (помимо галлюцинирования) выдавать неверные ответы.
Г) намеренная деятельность Даркнета, в том числе и намеренная накачка ложно-положительными решениями, добавляет сложности использования и снижает доверие результатам работы таких систем.
Д) Про «программирование» с помощью chatGPT уже упомянуто выше, метод противодействия кроме запрета таковых действий для своих штатных сотрудников только один - обязательное использование AppSec подхода в отношении подрядчиков.
Е) Исследования изменения когнитивных функций человека, наступающие при использовании «ИИ костыля», проводимые и уже проведенные опубликованные, в том числе и в MIT, однозначно показывают снижение способности человека использовать свой разум, необратимые и качественные.
Надеюсь, перечисленного в этом пункте достаточно, чтобы оставить кесарю кесарево, а компьютерам – вычисления.
