Speaker A
С. Привет. Меня зовут Андрей. Я технический лидер в одном достаточно крупном банке. Вот. А хотел с тобой, собственно, что мы собрались проговорить по собеседованию нашему техническому на позицию Application Security специалиста.
Техническое интервью на позицию Senior Application Security с реальными вопросами и обсуждением практических кейсов.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Раннее вовлечение в архитектуру и процессы безопасности снижает риски и затраты на исправление.
- Legacy-системы часто содержат критичные уязвимости, требующие особого внимания.
- Бизнес-логика играет ключевую роль в защите данных и предотвращении утечек.
- DevSecOps важен, но рутинные задачи лучше делегировать специализированным специалистам.
- Безопасность в быстрорастущих компаниях требует баланса между автоматизацией и архитектурным контролем.
What the video covers
- Интервью с техническим лидером Андреем на позицию Application Security специалиста.
- Кандидат рассказывает о своем опыте в банковской сфере и продуктовой компании доставки.
- Обсуждаются различные аспекты application security: поиск уязвимостей, архитектурная безопасность, DevSecOps.
- Подчеркивается важность раннего вовлечения в процесс разработки для предотвращения уязвимостей.
- Приводится пример критичной уязвимости с утечкой персональных данных в сервисе доставки.
- Обсуждается роль бизнес-логики в обеспечении безопасности и сложности с legacy-системами.
- Кандидат выражает предпочтение архитектурной и процессной безопасности над рутинным DevSecOps.
- Рассматриваются вопросы автоматизации, тестирования и поддержки безопасности в быстрорастущих компаниях.
- Обсуждаются вызовы при работе с микросервисной архитектурой и масштабированием безопасности.
- Видео содержит реальные технические вопросы и практические советы для senior специалистов по безопасности приложений.
Chapters
- 00:00Введение и знакомство с кандидатом
- 05:15Обсуждение опыта и предпочтений в application security
- 09:44Пример критичной уязвимости с утечкой персональных данных
- 19:27Роль бизнес-логики и архитектурные решения
- 29:11Вопросы автоматизации и DevSecOps
- 37:09Проблемы масштабирования безопасности в микросервисах
- 43:17Заключение и советы для senior специалистов
Full Transcript — Download SRT & Markdown
Speaker A
Вот. Э, видел резюме, всё весьма сильно заинтересовало. Э, очень такой богатый, офшорный опыт. Думаю, получится нам пройтись какую-нибудь достаточно там высокую позицию, но будем, естественно, отталкиваться от результатов собеседования.
Speaker A
Расскажи, пожалуйста, о себе. А расскажи, пожалуйста, о себе. Меня зовут Нес. Да, я обсек уже долго, уже больше 5 лет. Начинал обсечить таким Яном и зелёным женом в одном маленьком, но гордом республиканском банке. Получил весь свой основной опыт и все копсил, и
Speaker A
обсечил, и пантестил. Очень много чего интересного происходило. Делал безопасность онлайн-банкинга. Потом один большой жёлтый банк посмотрел на мой опыт, такой: "Мы тоже такое хотим".
Speaker A
Перехватили к себе и тоже там какое-то время поварился, делал классные проекты, связанные с безопасностью онлайн-банкинга, там QYC подтверждение по видео и в целом безопасность самого онлайн-банкинга, анализ мобильных приложений. Тогда смог пощупать первые JRPC как протокол. Такие классные технические задачки были, но в какой-то
Speaker A
момент устал от банковских там тематик. Вот это постоянно госты новые, новые там приказы ЦБ. И в какой-то момент решил перейти в компанию более продуктовую, более такую народную и пришёл в компанию, которая осуществляет доставку продуктов очень быстро на самокатах. Э, ну сейчас этим
Speaker A
занимаюсь, активно провлекаю безопасность приложений, помогаю всекопсам тестировать новое приложения, новые сканеры и активно строим безопасность в разных вертикалях и горизонтали, в том числе.
Speaker A
Вот интересно такой шибно достаточно опыт. Скажи, вот ты говорил, что достаточно много там разных областей вот точки зрения там такой application security пробовал и с самим непосредственно процесс и с десякопсом чуть-чуть тест скажи, что вот больше всего вот этого как задравило больше
Speaker A
всего нравилось сделать. Ну, наверное, всё зависит от задачи, от контекста, в котором варимся. То есть в некоторых компаниях сильно интереснее искать уязвимости, потому что они в целом там не тривиальные. Есть какой-нибудь старые legacy, как, не знаю, сервисы, которые написали лет 10 назад на старом
Speaker A
фреймворке, которые очень боятся обновлять. И ты приходишь, смотришь, и там с первого пинка находишь очень интересные уязвимости. Мм, если мы говорим там больше про продуктовые, когда компания очень быстро растёт, сервисов становится всё больше и больше.
Speaker A
Условно на последнем месяце там, когда приходил, сервисов было 200, ну, микросервисов, но сейчас их уже там больше 400. И понятно, что фокус теряется, очень сложная архитектура.
Speaker A
И тут уже уходишь больше в созидательную сторону. Ты стараешься обеспечить безопасность на уровне архитектуры, на уровне идеи. То есть изначально ты идёшь как shift, смотришь всё, что находится на краю, какие есть уязвимости, какие есть проблемы, то, что прям висит низко
Speaker A
и как бы возьми, да, потрош. А в дальнейшем, чем старше становишься, тем больше понимаешь, что лучше делать left-ф, надо приходить сильно раньше, искать уязвимости на ранних этапах, ещё на уровне идеи. Мы хотим передавать данные партнёрам. Такие: "Подождите, куда, зачем, почему? Зачем вы хотите
Speaker A
передавать? А если на это какие-то обоснования? А это не нарушает закон и так далее и тому подобное." И уже с опытом понимать, что такие решения, которые приходят раньше, они дешевле, намного дешевле для разработки в целом для компании и позволяют очень классно
Speaker A
и грамотно выстраивать процессы, особенно если компания растёт быстро и не хочется наломать дров, чтобы потом их очень долго и больно переделывать.
Speaker A
Поэтому в целом интересна, наверное, именно такая созидательная сторона, как, ну, обсечная это архитектура, это поиск каких-то логических проблем, которые могут быть в процессах. Это очень классно отслеживать ещё на уровне архитектуры, на уровне адрок. Ну и в целом тестировать какие-то коробочные
Speaker A
решения, потому что они всё равно возникают. Компания не всегда пишет что-то новое, иногда покупает что-то готовое. И там тоже бывают очень интересные моментики, которые можно выявить. Вот поэтому в целом интересна вся сторона обсека. Она очень широкая.
Speaker A
Девс копсить не очень люблю, потому что вся эта автоматизация, пайплайны, это очень много, это очень рутинно.
Speaker A
Лучше заиметь классного дификопса отдельного, чем самому сидеть, копаться во всех этих пайплайнах, поддерживать весь этот заопарк инструментов, а вообще потом писать свой собственный осок. Судя по опыту большинству, многие в эту сторону идут.
Speaker A
База. База, да. Проще написать своё очко и готова иногда. Здорово. А давай вот как раз из того, что ты говорил, сейчас у меня как несколько таких уже выводящих вопросов появилось. Давай, наверное, начнём с каких-то уязвимостей. Я не
Speaker A
буду спрашивать по там какие-то мелочи там типа, что такое ССС там что такое? Нет, уверенно, ты прекрасно знаешь. Вот.
Speaker A
Ну вот расскажи про какую-нибудь свою как раз любимую такую критичную уязвимость, которую вот в поте находил.
Speaker A
Да, там говорил, что бывали там попадались какие-нибудь legacy там системы старенькие, где можно было что-то крутое найти. Вот можете поделиться чем-то. Ну, естественно, там без имён, без конкретики. Ну, вот так вот отдохнём узнаем.
Speaker A
Ну, наверное, самый любимый кейс — это утечка персональных данных ещё до изменения ФЗ-12. Кейс очень похожий на Яндекс EED, когда огромное количество заказов были доступны всем, то есть отдельно слитая база, в которой можно было найти свои заказы, номера телефонов, адреса. Тогда
Speaker A
Яндекс отделался очень маленьким штрафом, и им повезло. Ну вот ровно такую же уязвимость находил Друмасервиса, которая в целом содержала не менее интересную информацию. Там тоже было очень много. Причём это не только доставка с конкретного магазина, это доставка с разных магазинов, с разных
Speaker A
ритейлеров. И штука была доступна курьерам. В этом была и интересность фишки, что обычно пользователь вряд ли мог бы её достать.
Speaker A
Но если у тебя есть приложение курьера, если у тебя есть базовый доступ просто до каких-то там заказов, то раскрутив само приложение, которое было написано Rтиative, можно было попартить опишку и найти очень классический простой айдор, который можно было бы защитить юидами,
Speaker A
на самом-то деле. Но там архитектурных юидов по сути уже и не было. Там сами заказы были итеративными. Не все, конечно, были там, условно не было такого, что заказ там 0,1 был заказ там 23-35.
Speaker A
И понятно, что перебором, впрочем, очень медленно можно было скатать всю информацию и получить всю базу там всех заказов за сколько? 6-7 лет.
Speaker A
Естественно, там не было никакой проверки бизнес-логики, что заказ уже завершён, что заказу там больше одного года. На самом-то деле проблема была очень глубокая. Она отражалась и в от Минске. Ну, в админке, которая доступна в достаточно большом количестве людей.
Speaker A
То есть логисты, там, руководители магазинов, они видели все эти заказы. И понятно, что это была большая дыра и с ФЗ-152. Понятно, что имена пользователей, их адреса, номера телефонов, имейлы, это, ну, очень часто информация. Поэтому всё это пришлось закрывать
Speaker A
большими-большими шагами, в том числе архитектурными. Понятно, потому что мы юидами не закрыли, но на бизнес-логике мы закрыли все заказы, которые уже прошли. То есть, если заказ ещё только создан, он в драфте. Понятно, что к нему доступ будет иметь больше людей, потому
Speaker A
что это всякие сборщики, доставщики, курьеры. И поэтому это как бы логично, что они имеют доступ, они даже понимают, что собрать. Но как только заказ уже там в доставке или уже доставлен, понятно, что мы ограничим доступ. Почему бизнес-логика такая важная? У нас курьер,
Speaker A
например, мог поменяться. Например, доехал до какой-то крайней точки, потом передал заказ. Если ограничивать ровно по рбаку плюс по атрибуту, то можно сказать, у нас в какой-то момент заказ может потеряться, что он может не передаться новому курьеру. А если
Speaker A
курьеров несколько, если они у нас там обе...
Speaker A
сам сами курьеры могли иметь доступ к более свежим, более вкусным заказам, просто перебирая новые заказы, может быть, что-то интересное или там попытаться его даже угнать. То есть там сама логика, она выстраилась ещё дальше множестве микросервисов и их связанность
Speaker A
была очень низкая. Поэтому потенциально дыра была интересная. И вот как бы её очень легко и красиво закрыли множеством множеством доработок. А вторая очень интересная увидимость - это сли такая критичная история. В многих нескольких компаниях трогал корпоративные порталы, где можно купить себе мерч за
Speaker A
какой-нибудь там условный а коин, ну, назовём абстрактный коin. Ну и там находился пару раз моменты, что можно бесплатно себе заказать любую футболку, потому что там не было чекаута нормального. И в целом логику очень легко было поломать, там поменять
Speaker A
буквально пару параметров, которые вроде как, ну, типа свои же внутренние процессы делат их там на питончике, на чём-нибудь очень простом. И нет, вот это стоит машины, которая проверяет, что заказ прошёл перед обработку, что там точно совпадают баланс и тому подобное,
Speaker A
потому что в конце как бы у тебя машина просто выдаёт заказ на email условному ДВрлу. Он такой: "Ага, мне нужно отправить вдумку". И всё, что внутри этой машинки творится, оно очень слабоконтролируемо. То есть такая бизнес-лойка, она, конечно, не сильно
Speaker A
рисковая, не сильно критичная, но в целом всё равно неприятная, потому что если корпорация большая, то бюджеты большие, а вдруг у нас там в магазине коинов есть условный MacBook. Такое я тоже видел в своей практике. Поэтому это тоже очень такой интересный кейс Фрода.
Speaker A
То есть в целом у меня в в опыте был э такой период работы с антифродами, с фродом под ЦБ, когда чёрные списки появились по номерам карт, номерам телефонов. Это, наверное, самый критичный, чувствительный вектор для бизнеса, потому что потеря денег
Speaker A
напрямую. Поэтому такие уявимости, они наиболее интересные и более важные. Да, конечно, есть всякие RCE, когда можно поломать систему и уронить, но они стремляются в разы реже. Больше, наверное, в компонентом анализ, чем руками.
Speaker A
Это правда, да? И вот тоже такой показательный пример первый той был, где казалось бы типа простор, что там навесить нотификацию и всё, что там фиксить. Вот.
Speaker A
А на деле оказывается, что там фикс на полгода, а то и дольше. Вот. Так, если не секрет, за сколько времени удалось закрыть полностью эту уязви?
Speaker A
Ну, тут вопрос, конечно, что такое полностью. То есть, если говорить там по прямому назначению, мы закрыли за 3 дня.
Speaker A
То есть вслы уместились. То есть вот эти прямые ссылки мне были закрыты очень быстро, но вот эти все сайт квесты, которые возникали там то в админке, то ещё где там исторические данные и тому подобное, они уже закрывались в течение,
Speaker A
по-моему, дву-трёх месяцев, потому что действительно множество сервиса дотронуло и условно мы уже вроде всё закрыли, а потом оказалось, что у таксистов всё ещё раз есть доступ, потому что таксисты - это вообще отдельная категория, и для них там отдельно немножко логика ломалась.
Speaker A
Да, всё-таки есть вот тоже, да, развитие этого вопроса. У меня там один родился буквально сейчас осталось только его вспомнить, потому что он родился и задулся моментально практически. Ну, куда без этого? А сейчас я постараюсь это вспомнить.
Speaker A
Ладно, не вспомню, потом спрашивал. Объясн не такой супервальный крутой вопрос был. Большой трак, но поболтать. Так, ладно, давай тогда пойдём дальше к следующему, может, вопросу. О, кстати, да, тоже достаточно неплохо вытекает из предыдущего. Вот ты упоминал как раз вот тоже про уязимость
Speaker A
его там РЦЕ, там пройдуры, про утечки. А вот какие вот по твоему мнению наиболее вот популярные уязвимости на то и какие наиболее критичные из них?
Speaker A
Ну, наиболее критичное, конечно, то, что ФЗ 152 покрывает, это утечка персональных данных. Это очень частая и большая проблема, тем более, что ФЗТ52 сейчас очень сильно ориентирова на GTBR и всякие куки такие, ну, вроде как непрямые данные, но тоже они относятся к
Speaker A
присухи. Поэтому это очень важный момент. Особенно было интересно пару лет назад наблюдать, как люди находили публичные лк стейки, где по сути хранились логи. А в логах у нас никогда ничего не закрывается. И действительно, это было очень больно. Понятно, что в
Speaker A
банках, когда только пришёл работать, был классный момент с всес. Он очень высоко принимает уровень безопасности, поэтому утечки данных они были, но не такими сильными. Но если говорить про общие компании, особенно все эти стартапы, то это прямо крит крит.
Speaker A
Второй, наверное, по важности вид уязимости - это новые технологии яишки. Прямо очень часто сейчас сталкиваюсь с этой историей, что кто-то интегрирует яишку.
Speaker A
А там оказывается какая-нибуд внутри промтоинъекция, возможность вынести какую-то лишнюю информацию, либо ещё хуже там получить чужую информацию. Там интересный пример. Есть какой-нибудь маркетплейс условно, в котором есть и помощник для селлеров.
Speaker A
Ну и если сильно там постараться, можно Ишку убедить получить данные не свои, потому что Ишка работает по таким очень простым агентом с общей привилегированной учёткой, а не каждое агентство даёт учётку с новым такем.
Speaker A
Такая архитектурная проблема. Сейчас, конечно, это просто развивается очень быстро, и такие видимости ловить не так легко, но они тоже достаточно критичны, потому что всё это настраивать, это закрывать, это огромное количество ресурсов. Там те же самые гартрейлы, плюс самите технологии развиваются
Speaker A
быстро. Иногда бывают очень такие м неприятные моменты, если говорить про такие не бакбаути скоп, а больше про инфраструктурные, про стабильность системы ну это конечно цвеешки их сейчас становится всё больше и больше.
Speaker A
Спасибо там ЛМКАМ. Тот же самый Клод Мифас, который может за день найти 30 новых уязимостей. И ты понимаешь, что это все криты с оценка выше девяти, нужно что-то с этим делать. А на второй как бы чаше весов у нас появляется
Speaker A
малиша с пакета, когда у тебя вроде новый свежий пакет, но он у тебя всё как бы заражён и скорее всего тебе обновляться на самой последней версии нельзя. Получается, ты должен ловить такой баланс. Либо ты сидишь на старых версиях, но всегда микропатчишь, чтобы
Speaker A
не было проблем с цвешками. Либо ты сидишь на latest, но всегда можешь поймать какую-нибудь там багованную тире удимую компоненту, которая специально заложит како-ним или там штуку, которая по сути тырит у тебя все креды, там саш ключи и тому подобное. Такой уже было
Speaker A
несколько раз с очень полезными eBинструментами. И там тот же самый Триви и чекмарк сломали. И это очень больно. Получается, что такие уязимости они, ну, всё ещё в скопию секако, будем честны. И вот с ними бороться всё ещё сложно. То есть нужно этот процесс
Speaker A
построить, чтобы разработчики не были от того, что у них слишком много обновлений прилетает, и чтобы не ловить такие беркейсы, когда у тебя популярная библиотека, её взломали, и ты такой: "Ой, извините, мы мы взломаны". Поэтому очень много проблем. И он вот этот класс
Speaker A
проблем несёт с собой огромное количество разных моментов, которые выпираются и в Runime Security, и доступность внешнего интернета, и, по сути, слежение за активностью самих приложений. Поэтому их закрывать становится всё больнее и дороже. Это, наверное, самая большая проблема. Нам
Speaker A
под текущий пласт, текущие пару лет. Вот. Ну, а так, если говорить там про типовуюзимость, понятно, что эксски всё ещё встречаются, к сожалению. Плюс, как бы, вайпкодинг рождает новые прикольные продукты без какой-то там обоснованной логики. Очень печальные там, не знаю,
Speaker A
правила доступа внутри систем, которые тоже очень легко ломается. Поэтому в целом мы всегда закрываем то, что в фокусе, то, что влияет на бизнес, либо на его доступность, либо на его там заработок денег. Мы, естественно, смотрим за полем информационным, вдруг
Speaker A
там репутации пострадает, вдруг ещё что-то. То есть всё это очень комплексно. И вот популярность уявимости, она, наверное, очень легко отслеживается на бакбаунте. Чем больше репортит разных интересных кейсов, тем всё интереснее, интереснее, потому что всякие там базовые ксэские сколиксы, они
Speaker A
уже давно были, наверное, закрыты. А когда достаточно сложная с каким-то необычным вектором, загрузил файл, он там тебе вернулся в таком-то формате, загрузил файлые какие-то истории, да, вот так, да, поэтому сложные вектора становятся более популярными и более интересными. Поэтому компании зрелые
Speaker A
идут на ббшку, чтобы такие штуки ловить, потому что иначе их целом, наверное, вряд ли может быть найти своими силами.
Speaker A
Ну это да, компания не на не на бакбаунте найти такое тяжело. Либо нанимать очень дорогой пинтест, либо нанимать очень дорогого пинтеслера, либо кормить всё и у нас уже есть интерес позитивный опыт.
Speaker A
Ну это да. Нет, на самом деле насчёт недёшево вопрос такой актуальный. Недавно только сравнивал историю, сколько будет стоить провести полноценный санализ с помощью Ишки на всю кодовую базу. И вышло что-то примерно 8 там 10 млн руб. Это проверить
Speaker A
все там сколько 600 тире 700 микросервисов с помощью клода энтерпрайзного, то есть нуфасла система, но это один прогон. Это ещё нужно отряжить. Это ещё сколько времени тряжи?
Speaker A
Один прогон надо отряжить ещё надо задвиски вот эти вот. Это же не наша система. Оно же там, как же ж оно там всё это всё мы утекли, всё храна, капец.
Speaker A
Да, всё так эти все приколы ещё туда же. Да. Вот, кстати, про сторону промейки как раз вот тоже, да, ты говорит про вот этот мифос вездесущий, он же Fable 5, он же там что ещё. Вот как раз вот по
Speaker A
последним новостям там запретили его использовать, типа пока не устранить все уязвимости. Как ты считаешь, возможно ли вообще устранить все уязвимости в иишке как минимум хотя бы потоекци? Вот принципе в целом-то, да, в целом, наверное, какие-то базовые истории легко найти, но
Speaker A
так как сами нейронки становятся очень сложными, там триллионы параметров, то возникают очень необычные кейсы.
Speaker A
Буквально недавно только читал в одном из канальчиков, что нейросеть начала выдавать очень странный контекст с помощью эмози, то есть там стрелки, всякие черепушки и так далее. То есть нейросель по сути выдумывает свой некий метаязык для того, чтобы ускорить и
Speaker A
сжать все свои данные. То есть эта векторизация, она работает немножко в другую сторону. И по факту-то можно все пайлоуды попытаться сформировать в таком же формате. Не читаем для человека, но читаем для яишки. И вот эти картрейлы, они легко обходятся. То есть мифас
Speaker A
почему закрыли, точнее Fable? Потому что, по-моему, сколько через день, через два появился дilбak, даже как будто меньше, чем день. Да.
Speaker A
Да-дада. То есть очень быстро появился дilбрейк, потому что есть системный промт и на его основе можно было понять, как это развести.
Speaker A
Поэтому, но если мы говорим про продуктовую сторону, про промнъекции, про там, не знаю, подходы агентных систем, когда у тебя есть доступ до файлов, можно построить хорошую систему.
Speaker A
Вопрос только цены, потому что хорошая обвязка. То есть как защититься промтонъекции? Дать другую яишку, маленькую, короткую, которая будет проверять на промт инъекции. Но это тоже же деньги, это тоже поддержка, это тоже нужно каким-то образом держать. Плюс создание санбоксов, которые ограничивают
Speaker A
доступ и ресурсы, но это всё стоит денег. Поэтому тут всегда вопрос: готов ли ты потратить столько денег, что это будет уже прибыльно, неприбыльно и насколько это вообще оправдано?
Speaker A
Да, здесь всё в целом. Так, слышу ещё такое тоже мнение, что вот из-за самой техники вот этой эксплуатации полных инъекций, что тебе надо как бы уболтать яишку, потом тебе что-то раскрыть, от неё защититься полностью невозможно вообще никак, потому что, ну, ты просто
Speaker A
можешь у тебя типа вот в Эксске там, допустим, у тебя просто есть технический язык, которому вот ты можешь писать только так и никак иначе. Вот. Ну и там ещё там пять каких-то условных вариантов. А здесь у тебя все варианты
Speaker A
мира, которые бесчисленное множество, можешь половину по букве его словно писать на разных языках. И главное, что себе яишку поняла.
Speaker A
Ну да, к сожалению. Вот поэтому от этого защищаться сильно сложнее. О'кей, давай пойдём тогда дальше.
Speaker A
Дальше, дальше, дальше. Вот тоже вот почтик себе нашёл про то, что тоже уже чуть-чуть подмечали.
Speaker A
ты упоминал такой подход к обеспечению безопасти, как уже сказав, что это мы сдвигаемся проверки, собственно, влево.
Speaker A
Ещё рассказывал про такой а подход, как Shift Drive, который тоже имеет место быть в начальных этапах. Так, думаю, вот какие ты ещё знаешь подходы к обеспечению безопасности LPSDC?
Speaker A
Ну, есть понятие как Shift everywhere, когда мы безопасность включаем ZS так называемый SSDLC. То есть, если мы говорим про Shift Left, это означает, что разработчики ещё при написании кода и ID и проверяют его через eb. А Shift, когда мы просто сканируем пентестом и
Speaker A
пытаемся соответствовать определённому уровнем например там или тамSS какой-нибудь SК. А, то есть, э, уровень самой безопасности может строиться как справа, так и слева.
Speaker A
Но вот есть Shift everyw, когда мы безопасность встраиваем на всех этапах. Для чего это нам нужно? для того, чтобы мы достаточно глубоко понимали контекст и могли среагировать в нужный момент. То есть, если мы говорим про подход SSDLC, это у нас цикличный, это тот же самый
Speaker A
Agile, который вешан уже безопасности и тот же самый DFC кос. И очень важно, что многие забывают, что вот весь вот этот SSDLC ещё в конце имеет такую историю, как поддержку, как Нтай, то есть реагирование на инциденты, это работа с
Speaker A
логами, это, ну, безопасность самой работающей машины в виде всяких ВАВ или какие-нибудь НГФв, которые по сути тоже защищают от части атак. Поэтому в целом вот Shift Left, Shift, Shift Everywhere, Shift Every - это, наверное, самый универсальный подход. Каких других там
Speaker A
понятий, честно говоря, не очень слышал. Вот. Но это опять же больше комплексный подход, когда у тебя есть и анализ идей, аз там, не знаю, общих векторовых атак и уже защита с помощью разных кейсов, нтеста, backбаунти, рантай защита, вафы
Speaker A
и там подобное. Всё это, когда синергично работает, то у тебя получается полноценный цикл, причём даже несколько. У те есть цикл поиск уязвимости их исправления, у тебя есть цикл анализ идей, соответственно, комплайнсу, выдачи их в прот и там общий
Speaker A
цикл улучшения самой безопасности с точки зрения инструментов, подходов, метрик. Угу. Красно. А вот если пойти в сторону, допустим, уже чуть больше к архитектуре, подойти там в сторону политик, каких-то принципов построения вот этих вот систем, здесь что нужно?
Speaker A
Ну, с точки зрения архитектур у нас есть подходы в целом-то по безопасности, это полноизоляции. У нас есть возможность там разделение дмзшек, то есть когда мы имеем некие буферные зоны или там полностью закрыты от интернета зоны, такая больше банковская история. То есть
Speaker A
приложение, понятно, что оно не должно чать всей своей внутринкой наружу. И тут как бы вопрос, наверное, про обеспечение самой безопасности. Там понятно, что мы архитектуру меняем, но с точки зрения там покрытия безопасности у нас есть же самый дезеротраст, когда мы не доверяем
Speaker A
никому. У нас в целом нет там доверенных зон. А есть вот история у нас есть там несколько слоёв. Слои максимально доверенные с максимальным привилегиями. Есть там менее доверенные, есть там конечные точки, которые не являются доверенными. Яркий пример банковская сфера. Мы приходим в
Speaker A
отделение банка, у нас есть там компьютер любого какоператора, но даже там, так как эта система достаточно чувствительная, есть двухфакторка.
Speaker A
которая, причём, работает не в виде эсэмэски, а виде какого-нибуд железного ключа, там Onewire или како, да, получается безопасно, но неудобно.
Speaker A
Это такой вот подход, когда мы обеспечиваем даже конечные точки, потому что у нас в целом по принципам мы должны также подтвердить там аутентичность самого запроса, там логирование этого запроса и там не повторяемся этого запроса. То есть мы расширяем наш CA на
Speaker A
условно подтверждение, фиксацию и верификацию. Таким образом мы как бы улучшаем систему. Но опять же тут больше про то, что есть там последняя вот эта точка, конечная точка. Понятно, что это заротраст. Но если мы говорим про первичную точку, про сервер, там ещё всё
Speaker A
хуже. У нас там доступ через три каких-нибудь гейта. Сервер доступен только там по определённым условиям, только внутрь можно зайти к дискам, получить доступ там, не знаю, через 100 500 согласований и так далее. То есть всё очень сильно зависит, наверное, от
Speaker A
уровня требований и плюс от критичности самих рисков. Вот тоже развитие вот этой истории про зеротраст есть ничего не будет. Как раз вот одним из вот это всего компонентов вот этой такого как прекрасного зеротраста будущего можно назвать какие-нибудь password ls системы, где у нас нет
Speaker A
паролей вообще как явление. Что думаешь про это? Насколько это будущее вообще в EB? С одной стороны тема неплохая, но есть свои минусы. ты начинаешь зависеть от само устройства. То есть, если мы говорим про последние вот эти подходы Фида 2, UBK, которые сейчас вышли в web,
Speaker A
то ты начинаешь зависеть от того устройства, на которое ты ставишь вот эту, по сути, passwordless историю.
Speaker A
И, наверное, самая большая беда, что при внедрении всех этих моментов ты всегда понимаешь, что вот у тебя есть либо биометрия, либо какое-то физическое устройство, которое является, по сути, тем самым фактором для входа. физическое устройство можно потерять. А с
Speaker A
биометрией тоже есть свои приколы. Например, мы у себя в банке решали историю, что женщина подала там заявку, ой, уже у мужа украли деньги. Такие: "Да как так? Начали решать фрод вопрос".
Speaker A
Оказалось, что он где-то в баре выпил, и кто-то с помощью Face ID разблокировал его телефон и отправил деньги к себе.
Speaker A
Почему? Потому что он, ну, словно спал, его там глаза открыли, Face ID сработал, всё. То есть даже биометрия не является полноценным суперклассным фактором. Плюс опять же есть куча фильмов про шпионов, где там и отпечатки пальцев копируют, и сейчас ЛАЗ
Speaker A
можно скопировать. Плюс куча историй, когда телефон имеет одну камеру, имеет Face ID, а он работает ужасно плохо.
Speaker A
Можно показать картинку, но сработает. Поэтому, если мы говорим про общие подходы с там то же самое пон, это всё должно обмазываться огромным количеством анализа. То есть по опыту больших игроков, потому что жёлтого банка, антифрот строится на огромное количество параметров. То есть это
Speaker A
большой прям это big datта, это ДВХ, это анализ поведений в том числе. То есть да, например, устройство ты открыл с помощью там Face ID, допустим, или там через TTCH ID.
Speaker A
Даже если твои действия не соответствут какому-то определённому поттежну, то, скорее всего, ты словишь какую-то дополнительную проверку, там слова и так далее. То есть сами пароли, если мы говорим про какие явления, они уже устарели. То есть сейчас пароли ломаются
Speaker A
только раз два, тем более хэши. У нас есть огромное количество видеокарт, которые ломают это достаточно быстро. И раньше вот эти подходы, пароль из восьми символов, спецсимволы плюс там большой малый регистр уже не работает. В идеальном случае нужно исполь
Speaker A
Никто не хочет делать идти, никто не хочет делать сложные пароли. Да, да, да. Все стремятся на то, чтобы просто удовлетворить политику.
Speaker A
Да, да, и это большая проблема. То есть passwordless в этом плане утопная штука, что человек не запаривается про пароль.
Speaker A
У него есть пароль в виде какого-нибудь ключа, в виде шат 256, ээ, там как минимум шот 1056, может быть, что-то подлиннее. Но сразу стаёт вопрос, что если он устройство потерял, если ему нужно переехать на другое устройство, это не всегда удобно.
Speaker A
Там ездить устройство вообще не работает. То есть у меня, например, напи стоит второй фактор в виде там тайматп.
Speaker A
Эсмэски не работают, у нас связь там вырубают, к сожалению, не получается. А если телефон сел, что делать? И сидишь и думаешь: "Ну как бы да, один пароль я знаю, вот второй фактор уже не придумаешь".
Speaker A
Это да, есть такое. Везде свои нюансы, да. Давай тогда такой вот как бы э такой кейс разберу. гипотенический.
Speaker A
Вот даже два целых. Что вот ты, допустим, он пришёл в команду, те вот знакомили её с командой, говорят: "Вот это ваш теперь новый обсек, а он будет у вас строить безопасную разработку".
Speaker A
Команда хопает глазами, спрашивает: "А что такое SDC?" Э, даже не SS, просто S. Вот ты им рассказываешь, они говорят: "А это вот это, но мы просто типа диплом в прот мастер со всех устройств. Нам вообще всё хорошо".
Speaker A
Вот как будешь жить с такой прекрасной командой? Ну, вопрос хороший, потому что, наверное, сейчас тяжело будет встретить команду, которая вообще не понимает про безопасность, ну, за исключением вайпкойров.
Speaker A
Всё равно хоть немножко должны понимать. Но если мы говорим про гиптическую вот эту историю, что команда не занималась безопасностью, а зарабатывала деньги, потому что это такой там активно расщиртап, то понятно, что самый важный фактор - этотменеджмент.
Speaker A
То есть нам нужно понять, что в общем у нас есть, какие ресурсы, что нужно сохранять. А то есть можно пойти нам с инвентаризации какой- Да, инвентаризация. То есть у нас Java система, которая эту инвентаризацию хранит. И почему она очень важна? Ну
Speaker A
только, наверное, последние пару лет очень сильно замечал, что Google таблички не работают, они не обновляются. Желательно иметь систему, которая будет автоматно собирать всю информацию, что торчит наружу, какую информацию оно хранит, там PDН, не PDН, все DSС. То есть это, по крайней мере,
Speaker A
позволяет понимать весь пул проблем и ширину тех самых атак, которые могут произойти. Ну и плюс мы сразу делаем фокус на критичные системы, которые нужно сохранить, и уже для них выстраиваем сначала вот этот первый шолом безопасности. Если мы говорим про
Speaker A
саму разработку, то, конечно же, нужно понять, какой к технологии, как мы работаем, насколько это всё автоматизировано, потому что если нет автоматизации, всё происходит вручную, то защищать хотя бы нужно как shift, хотя бы на конце. подпишите, пожалуйста, своим личным там ключом прежде чем
Speaker A
положительный сервер. Если у нас там автоматизации есть или какой-то C, хотя бы C уже можно навесить определённые чеки безопасности. SAS SCA, там Secret Detection, она бывает очень нужно. Если мы говорим про там CD, что у нас уже даже Coin stage есть, то можно накинуть
Speaker A
какой-нибудь динамический анализ, хотя бы базовый, на поиск типичных типовых уязимостей, тех же самых айдоров, экссесэсок или отказ обслуживании. Ну и всё это потом каким-то образом оркестрировать. Поэтому с точки зрения бизнеса понятно, что у нас есть фокусная зона, которую мы должны обязательно
Speaker A
защитить прямо срочно, важно, быстро. М те же самые логин, например, могут быть или бизнес-функционал провести там условный бн-тест. А с точки зрения разработки - это, конечно же, посмотреть, что у нас есть и что с этим можем сделать. Если как бы говорим, что
Speaker A
у людей нет желания что-то автозировать и так далее, есть очень неплохой подход. Покупаем нормальный САСК, который может сам скачивать там гиты. Тот же самый скриннер это делает, кстати, вполне себе неплохо. Он скачивает условный репозиторий, делает полный анализ. У
Speaker A
него, кстати, да тоже появился на основе запа. Секрет он тоже находит, конечно, фалсит безбожно. И, по крайней мере, с помощью такого анализа первичного без взаимодействия с разработчиками уже можно понять, насколько много проблем.
Speaker A
Сами результаты растряжить хотя бы на уровне, там, не знаю, общего подхода. Ну, конечно же, лучше проанализировать сами правила, адаптировать правила, чтобы они меньше всего в пласили, и найти самые вот эти критичные проблемы в виде там небезопасных подключений. То же
Speaker A
самое сертификат какой-нибудь прокши, торчащие креды от базс данных, которые везде одинаковые и так далее, и так далее. Всё это закинуть уже в команду разработки в виде определённого технического долга, который будет выполняться на определённый срок.
Speaker A
Естественно, договориться с бизнесом, что команда выделяет 20% времени на исправление проблем, потому что просто так взять и вклиниться в работу. Всё, у нас месяц безопасности, субботник, делаем быстрее. Такой же ответ, если всё было так просто.
Speaker A
О'кей. А если не про технические меры, что можно тоже поделать? Ну, нетехнические меры это, конечно же, про, если мы говорим формальну, неформальную часть, не сталкиваться с такой и другой. А-э, если не формально, конечно, провести обучение, то есть попытаться найти людей, которые понимают
Speaker A
безопасность и вычинить тех самых сере чемпионов, которые помогут выстроить процесс. Эта штука очень важная и полезная. По крайне мере, на своём опыте мы себе вырастили примерно процентов 30 людей из всей компании, которая является секи чемпионами из разработки, уточню.
Speaker A
И действительно, это помогает решить проблему, что у ИБ никогда не хватает ресурсов на всё. покрыть все там цели, все асеты. Поэтому SEчемпа - это очень важно провести курс. Есть разные платформы, есть там Коonda, по-моему, можно использовать авасковское решение.
Speaker A
SPS, кстати, неплохие курсы делает. И курсами, во-первых, несколько уровней можно выстроить. Первое - это бесс, что вот у нас есть ава, у нас есть типа уязимости. Пожалуйста, понимаете, если я приду к вам скажу: "У вас увезимость XS". По крайней мере люди не будут
Speaker A
думать: "А что это такое?" Они, по крайней мере, поймут, что это. и для чего оно нужно. А второй уровень тоже больше про то, как искать узимости, как их не допускать, настроить условно себе ID, чтобы она посвечила проблемы. На
Speaker A
третий уровень, как искать уязимости, типа для автотесты, юнит-тесты плюс там QA. И таким образом мы возвращиваем безопасность уже в умах разработчиков, потому что безопасность - это часть качества, а качество - это, по сути, метрика, которая поддерживает любой разработчика. Он же не должен делать
Speaker A
говнокод, он должен делать хороший, качественный продукт. И поэтому безопасность должна идти вместе с общим качеством и её можно хорошо продать. Вот это очень важный момент, что безопасность - это не просто хотелка или там, не знаю, требование какого-нибудь закона. Это, ну, классическая обёртка
Speaker A
для любого бизнеса. То есть у вас сервер упал на час, может из-за качества, а может из-за безопасности. По сути, это одно и то же. Вот. А если мы говорим про формальности, то, конечно, у нас есть история с документами. Это общая
Speaker A
политика информационной безопасности, это стандарт безопасной разработки и в целом унификация всех подходов. То есть мы можем выставить некий стандарт, понятно, что многие люди используют стандарт стандарт кодинг. Мы используем Python, там кепке casйс, всё вворачиваем в классы и так далее. Здесь же можем
Speaker A
описать подход для безопасности, что используем обязательно такие подходы для безопасности БТЭшек. Обязательно там накидываем рейтлимиты и так далее и тому подобное. То есть мы это закрепляем на уровне документов. Это очень хорошо работает для Гасухи. Это очень хорошо работает для компании, у которых хорошие
Speaker A
процессы не на уровень стартапа. И благодаря этим документам можно как раз ссылаться, говорить: "Ребята, вы подписали политику? У нас по политике быть не должно. Наоборот, пускать креты нельзя. Раз у нас такая политика есть, значит это очень важно, это акцентно, и
Speaker A
мы на это делаем большой-большой там э ресурс, ну, фокус то, чтобы вот у нас работал. Поэтому не везде, конечно, работать. может быть и налегче руками самим попинать. Поэтому очень важный момент, что обучать как эucational составляющая организационная составляющая, то есть для авас это вся
Speaker A
вот эта левая ветка, которая посвящена политикам, подходам и в целом образованию внутри компании. А вот туда проиг, что мы сделали там регламенты, сделали политику инфционной безопасности, где говорим о том, что с кретами плот нельзя. А если прямо надо, вот в каких случаях можно с критом
Speaker A
поехать в Лод или там с хао, например, где-нибудь? Тут, наверное, вопрос, как построен процесс и для чего вообще такой срочный релиз нужен. То есть, если мы говорим про то, что в компании и так всё плохо, мы просто внедрили процесс, что с
Speaker A
критами больше напрот нельзя, это огромное количество хейта и волна негодования. Но если мы говорим про более адекватный подход, что мы не пускаем там хаи, криты в прот, понятно, что должен пройти какой-то грейс период, что мы внедрили инструменты, мы дали
Speaker A
временно исправление уязимостей, мы пришли к какому-то состоянии систем, когда этих уязимости больше нет. То есть это личный опыт. Мы внедрили множество инструментов.
Speaker A
Прошёл почти год, и мы видим, что у нас там 80% сервисов криты и хаи не имеют на данный момент. И возникает только кейсы, когда у нас там появился вот сегодня, вот прямо сейчас, и мы тут как бы сразу
Speaker A
ловим два эффекта. Либо мы относимся как к инциденту, либо мы относимся как общему процессу там заведения, исправления визимости. Если что, это крит, понятно, что у него есть свой собственный с и команда может словить блок на релиз. Это действительно очень
Speaker A
плохо. И тут сразу возникает огромное там количество веток, что если это ход фикс, какой-то другой баги, который теряет деньги, то да, мы пропускаем. То есть SL, например, на исправно зимости прошёл, то всё это там точно блок и только по согласованию безопасности плюс
Speaker A
там техersршип, плюс там, не знаю, чего может быть запровет, что вот вот этот фикс надо сделать. То есть в хорошем, правильном процессе у нас есть вот эти уберкейсы, когда мы можем гладить углы и разрешить релиз в прот. Но это работает,
Speaker A
наверное, для компаний, в которых хорошо построены процессы. Если мы говорим про там более лояльный подход, то всегда есть вопросы: "А что это за крит?
Speaker A
Насколько он подтверждён и какие риски он несёт?" И тут возникает вот эта ветка про оценку рисков. То есть мы там нашли уязимость, она действительно работает, а 100% подтверждённо. И по там ЦВСУ это, например, оценка восемь, но по цвеешке.
Speaker A
А мы можем, например, посмотреть там, посчитать и понять, что наша настройка Кубера сime Security не позволяет эксплуатировать эту историю. То есть у нас нет там сетевых доступов, у нас там всё это ограничено. Получается, что мы можем своим там этой оценкой снизить это
Speaker A
скрита до хотя бы нормалу и провести по оценке рисков, что да, о'кей, мы можем это испрать в течение двух недель, потому что не эксплуатируется. А второй момент, что если это даже суперкрит, то риск мы понимаем, мы осознаём, что вот
Speaker A
сейчас это срочно пофиксить не можем. И там бизнес говорит: "Мы не можем терять деньги. Это очень важный сервис. Если что, у нас там инцидент респонс сработает". О'кей, мы принимаем риск, идём дальше в релиз. И опять же важный момент, а вдруг эта уязимость вообще не
Speaker A
воспроизводится? То есть всегда могут быть кейсы, что уязимость как будто бы найдена, особенно какой-нибуд SAS, но по факту это false positive, и мы можем просто его закрыть. Поэтому как бы тут два кейса. Если бизнес построен хорошо, у нас есть риск асessмент,
Speaker A
риск-менеджмент, и мы оцениваем, насколько всё это важно, критично и точно нам это нужно или не нужно. Если всё о'кей, то идём по процессу согласования, что о'кей, это или у нас идёт. Если же у нас тут дело даже не в
Speaker A
риск-менеджменте, а скорее про там соответствие определённым политикам, надо смотреть уже на сам кейс, насколько это правдивые, насколько это критичные, может быть, стоит переоценить и так далее. Ну и сам байпас может быть на уровне того, что а вдруг у нас фикса
Speaker A
нет. Вот у нас библиотека узимы, цвешка появилась, но фикса-то нет. Ну как, что делать дальше? Поэтому релизить дальше можем, но обязательно ждём. Вот как только появится фикс, мы его обкатим, посмотрим настже протестируем и тогда сразу краем уязимость. Понятно, что
Speaker A
возможно в слени влезет из-за того, что фиксато нету, что с ним делать, но по крайней мере для там основных рисков это самый, наверное, правильный подход.
Speaker A
Ну, может, какие-то компенсирующие меры там хотело прикрыть. Пока компенсирующие меры опять же не везде работают, не у всех есть вав. Где работают? Где работать? Конечно, понятно, что где нету там другой вопрос.
Speaker A
Прекрасно. Так, мы тут поговорили про вот такую вот мифическую компанию, в которой вообще ничего нет. А вот что делают компании, которые есть? То есть, когда вот вышли в зрелую компанию какую-то и там вот тоже нас спросят, говорит: "Вот вот мада, вот вам обсек,
Speaker A
увлекайте". Вот они уже смотрят, говорит, что да, у нас тут в целом уже тут что-то есть, мы там исканемся, у нас там носок, все дела, э, всё у нас вроде хорошо, типа, зачем ты нам так сильно нужен?
Speaker A
Вот. А ты, ну, типа, нужен или тебе прямо сказали там большие злые дяди сверху, что ты тут нужен. Вот.
Speaker A
Что делать в такой компании, вот в этой уже взрелой? С чем вот отличается такое вот внедрение взрелой и незревой компании?
Speaker A
Ну, тут очень зависит, наверное, от самой зрелости. Можно же и как-то оценить. У нас для этого есть разные фреборки. Можно по Васпу Самовскому оценить, можно по ДСОМУ, по Бсиму, наверное, не очень актуально. Есть российский DAF, который тоже неплохо,
Speaker A
кстати, оценива тот же самый Table Top. И, по крайней мере, оценив всю зрелость, можем понять, что есть вот эти там ступеньки четвёртые пятые которые являются там оверхедом, но они являются очень крутыми и полезными, которые могут позволить найти что-то уникальное.
Speaker A
Например, пару лет назад был очень там классный подход с фазингом. Многие крупные компании, которые имели ресурсы, пошли в Фазинг. И они говорят: "Да, это стоит это стоит там миллион рублей в месяц". Но мы находим таким образом очень необычные, нетипичные
Speaker A
увезимости, которые могут выстрелить. что у нас там не вся инфраструктура поляжет, потому что самфазинг - это очень такой интересный подход, когда у тебя данные неструктурированы, необычные, мутирующие, и они просто не дают понятного там выхода. У тебя просто приложение падает, а в чём оно падает, а
Speaker A
кто его знает. И получается, что мы можем вот достичь вот этого потолка, что у нас там подходы станотся ещё более интересными, ещё более прикольными. Ну и плюс во время самого аудита, оценки зрелости можете найти какие-то проседающие места, например,
Speaker A
образование, обучение, может быть, там эффективность сканеров, время, которое затрачивается на триаж. То есть мы должны, во-первых, промазать всё метриками, понять, насколько у нас эффективно работает компания. Если мы видим, что у нас метрики есть, что у нас, не знаю, метрики покрытия, метрики
Speaker A
там закрытия удимости в SL срок, количество секрет чемпионов, количество ревью архитектуров, вот если все эти метрики есть, то я скажу: "Вау, это уровень угла". Но в целом сейчас на российском рынке мало компаний, которые действительно полностью покрыты метриками, которые полностью понимают,
Speaker A
что творится у них в бизнесе. И, например, самая вот эта мифическая метрика, которую я очень люблю- это сколько денег мы тратим на обсег и сколько денег обсек сохраняет с помощью уязимости, рисков и вообще всей своей активности. Это супер сложно посчитать.
Speaker A
Это, наверное, какая-то задача мехмат последнего курса, плюс там столько данных бигдаты. Но если даже такое можно будет реализовать, это супер классно, потому что для бизнеса очень важно понимать, что вот у нас есть во всех команда, она стоит столько-то денег, ну
Speaker A
там от неё импакта настолько больше. Поэтому важный момент вот с точки зрения оценки даже зрелой команды, нужно понять, мы точно ли на этом уровне находимся или это обманчивое ощущение. И для подтверждения нужны метрики. Метрики никогда не врут. Они показывают, ну
Speaker A
опять же, смотрим, как их посчитать. Но если метрики есть и они показывают, что у нас вот есть классные там процессы, они работают, то тут уже просто идти в сторону ресер, в сторону, возможно, даже продажи своих решений. Но это опять же
Speaker A
на такие скорее исключительные кейсы. Да, я сильно будуще, но про вот это, про то, что метрики не врут, это вспоминается вот этот, ну, не знаю, вряд ли это анекдото можно назвать просто как некая шутейка про то, что если у тебя на графике точки не
Speaker A
совпадают, то рисуй точки пожирнее и всё нормально будет. Вот, вот эта схема. Вот, кстати, по метрике тоже вопрос параллельно робился. Ээ а как вообще посчитать безопасность в метриках? То есть, ну, мы же не как разработанным, типа, нас не посчитаешь там строчками
Speaker A
кода, там, не знаю, там временем доступности, там системы. То есть как вот тут посчитать, чтобы как-то доказать то, что вот после того, как внедрили обсека в эту команду, им стало офигенно жить, и он красавчик. Вот. А вот здесь
Speaker A
другой какой-то обсек похуже, он что-то дорабатывает. Вот как вот это посчитать? Ну, эффективность самих обсек инженеров посчитать немножко сложно. Всегда есть такая, скажем, неравномерно нагрузки, очень разная сложность самих проектов, но есть как бы косвенные метрики, которые показывают а работу с командами
Speaker A
и б безопасность самих продуктов. То есть, если мы говорим про метрики там общие для компании, они очень базовые.
Speaker A
Это количество уязимости, которое найдены, насколько эти уязимости закрыты в срок. То есть уместились они в с не уместились в с. Сколько у нас вышло из этого с это количество метрика? Сколько критичных уязвимости было найдено, сколько там нормалов, сколько low? И в
Speaker A
целом сходимость этого самого бэклога, то есть насколько у нас там быстро закрывается бэклог с уязимостями. Это такая общекомпонетская, её можно потом разделить на бизнес-юниты, ну и, соответственно, на обсеков. Но это больше про то, насколько хорошо работает Backбаo работает хорошо сам обсек, если
Speaker A
он там занимает secюurриity review и так далее. Вот. Но если этих метрик сильно меньше, вот у нас набауте условно торчит только там фронт общий, у нас ещё есть бfice система, которая на ББЭшке не соответственно, её там нет. Ну укоofice
Speaker A
же тоже много количест большое количество зимости, их же тоже как надо искать. И тут всегда вот этот небольшое неравенство, оно будет, оно будет чувствоваться. И понятно, что там мерить по количествумости - это не ок. Это скорее про здоровье самой компании, про
Speaker A
то, насколько часто находится узимости. Ну и опять же там с точки зрения состави, социай и тому подобное.
Speaker A
А другая метрика - это здоровье самих сервисов. Если у нас есть инструментальный анализ SAS, SCI, Secret Management, то мы можем хотя бы условно из количества сработок понимать, насколько в сервисах всё плохо. То есть у нас там 100500 микросервисов, из которых
Speaker A
половина на Го, половина на Питоне. Если у нас правила относительные правильно написаны, если они там уже каким-то образом откалиброваны, то мы можем понимать, что вот у сервисов на Гошке участием прямо больше сработок. Почему?
Speaker A
Потому что они находятся в определённой команде. Для нас это уже тоже хорошая метрика и фактор. Плюс скорость стриажа, потому что если мы имеем полноценный процесс стриажа и мы это не дали ишке этим занимаются джун мидлы или сами разработчики, нас тоже очень важные
Speaker A
факторы. Насколько мы быстро отряжем и сколько этот тряж соответствует тому, что он вообще существует. Например, уязимости у нас там две штуки, а триаже было там 10.000 сработок. Это хорошая метрика и показатель команды, что она работает над безопасности, что она сама
Speaker A
трежит, если, конечно, такой процесс существует. То есть мы для себя выстроили вот эту историю с метрикой безопасности самого сервиса. Сколько сработок есть, все ли они отряжены, насколько они были хорошо сработаны. И для обсека бизнес-партнёра в конкретном направлении это хорошая метрика для
Speaker A
того, чтобы понять и для самого там техледательного до этого направления хорошая метрика, что команда занимается безопасностью.
Speaker A
Ну и плюс уже такая боковая метрика - это зрелость команды с точки зрения безопасности. Приходит ли она там на ревью безопасности? Есть ли свой штатный чемпион? Были какие-то проблемы, инциденты, кейсы из безопасности, там прошли ли они все курс по безопасной
Speaker A
разработке, по сере чемпионства? И вот оценив вот эту зрелость, мы выставляем какую-то оценку, что вот уровень там два. Вот уровень три означает, что ребята там в команде все являются секи чемпионами, они приходят на CF и выигрывают. То есть у нас такая метрика
Speaker A
была, что команда суперзрелая, они на сите участвуют, все имеют мерчик чемпионов, приносят внутренние баги. Ты понимаешь, ребята очень там сильная, хорошая команда, хотя это их разработчики, но они там по скилам вообще не сильно хуже, чем всекмидл. И это очень здорово, понимаешь, что такая
Speaker A
команда имеется. хороший показатель наш боты да. Ну и в целом там, если мы говорим про метрики, можно вообще считать очень странные истории, типа количество багов на миллион строк кода, количество багов, которые закрыто в течение там релизного окна. То есть есть огромное количество
Speaker A
метрик. Знаю, что там Авито делали на эту тему исследований и вообще внедрялись метрики. Но тут, наверное, всё зависит от того, что важно и что в фокусе. То есть можно, конечно, упарываться в качество кода, можно идти больше сторон безопасности,
Speaker A
увезимости, которая находится на ББ, на внешних пентестах. Ну либо уже больше про самоотношение к безопасности разработчиков, триаж, обучение и так далее.
Speaker A
Угу. Супер. А, о'кей, давай пойдём. Другой кейс уже вот. А в целом тут уже очень подбные ответы даёшь на вопросы, поэтому у меня просто вопросы некоторые пачками закрываются сразу. Вот это скорее хорошо, я думаю, даже вот давай вот
Speaker A
такой вот понят рассуждаю тоже разные уязвимости там по там уязвимости на стороне кода там от са какие-нибудь уязвимости от пентеста на компоненты вот се поговорить такую сторону вот такой возможно немножко скользкой темы самое понятное это про уязвимости вот базовых
Speaker A
образов есть у нас там какой-нибуд тривии который сканит докеры а и такой вот кейс что есть, допустим, какой-то сервис, какой-то репозиторий, его разрабатывает там команда, а, она его пилит активно, исправляет там уязвимости посадству, по СЦА, какие-то компоненты, какие они
Speaker A
используют, там, повышают вот на основе вот этого всего счастья у них там собирается их образ с их сервисом и катится там в артефакторе, там куда-то там ещё. Вот. А в основе их образа лежит какой-то базовый образ. То есть какая-нибудь там
Speaker A
какой-нибудь там, не знаю, там ирика джавовая, какой-нибудь питон какой-нибудь там, ещё что-то смотрят, что за сервис. И вот этот вот базовый образ, он не их, его поддерживают не они, его поддерживает там какая-нибудь сторонняя команда, которая аэ его-то обновляет там, ну, не знаю,
Speaker A
там, ну, раз в полгода, там, раз в 10 где, так просто так обновление. А, и вот есть процесс, допустим, какой-то где а, ну, ещё то, что этот образ, он используется вообще всей компании. Вот.
Speaker A
И есть там сканеры в этих на этих вот сервисах, которые сканят их образ и вывешивают какое-то количество уязвимости там, ну, как правило, каких-то са истории, там, какие компоненты этого образа, что-нибудь такое. Вот. Аэ, и из-за того, что этот
Speaker A
образ используется командой, которая, собственно, запустила там сканирование, чей этот сервис, который мы сканили, аэ из-за того, что их у язык повесились, соответственно, на них автоматом. Вот какие ты здесь видишь проблемы в этом подходе и как думаешь, стоит исправлять
Speaker A
от уязвимости в таких базовых образах? Такой комплексный вопрос и сталкивался с ним уже не один раз.
Speaker A
Тут есть вот как раз уровни абстракции, что у нас есть конечный application образ, который используется там для рантайма и есть образ для сборки. И условно есть какой-нибуд супербазовый образ, который является там gold имиджем.
Speaker A
И тут сразу возникает множество вот этих факторов, что разные ответственность за разные слои. То есть всё-таки докер - это слои файловой системы. И что в них содержится? Отвечают разные люди.
Speaker A
Понятно, что для CD, точнее, для CI очень важно делать мультистайдж сборку. То есть у нас может быть очень жирный образ для сборки. Там уet, ужасы есть отдельно прямо хорошие дефсборки, которые используются там с кучей метрик, с кучей инструментов. Они позволят
Speaker A
собрать образ, но для рантайма используете минимальный образ. То есть мы взяли готовый артефакт, усунули его в рантай образ. Самым минимальным образом на там мой взгляд, конечно, distrol. То есть у нас там просто Linuxro и больше ничего. Ни нано, ни VГта, ни колы,
Speaker A
ничего. Причём это полезно и важно, что у тебя там касаются только приложения в своей изолированной среде с поддержкой того самого языка программирования, то там GDK, и так далее. Но есть сразу куча минусов такого подхода, что мы не сможем
Speaker A
дебажить, мы не сможем собирать некоторые метрики. Там есть подход с конезами и контейнерами, но это очень удобно и не всегда девопсы готовы это поддерживать.
Speaker A
Но в целом один из вариантов, ну или хотя бы переходить на очень минимальные образы типа Алпайна, которые минимальные. своей сути и содержит очень малое количество, потому что у них очень мало компонентов, потому что часто треви в образах находит именно проблем в
Speaker A
компонентах какой-нибудь там библиотеки какой-нибудь системной, которая в целом не является суперважной и скорее всего даже её эксплуатация может быть возможна только при доступности самого шела.
Speaker A
Пример. Если мы говорим про сакейс, что вот нашли уязимости, она находится на уровне компоненты, которая является платформенной. Ну, допустим, мы назовём платформенной. нас платформа поддерживает DNET девятый там версии Core и понятно, что вот проблема именно в Core 9. Вот значит, соответственно,
Speaker A
это несёт команда, которая находится на уровне платформы, а не конечной команды. Эти сработки должны искаться как отдельным процессом. То есть понятно, что у нас есть сработка внутри конечного образа, есть сработка, которая есть на платформенных образах. Это два разных
Speaker A
процесса. И мы можем в теории осоки делать корреляцию. То есть понимать, это транзитивная уязимость, это уязимость внутри компонента, который несёт с собой там условный базовый образ или это то, что было собрано в конце. То есть мы там для этого соберём отдельный звон чисто
Speaker A
для приложения, не затрагивая системную сторону, только то, что написал разработчик, то, что он сам подтянул. И мы всегда можем увидеть, что вот есть компоненты, которые идёт как корбиблиотека и понимаеш, что разработчику вопросов не будет, а вот поддерживателям там корбиблиотеки
Speaker A
вопросы будут. И, естественно, создаётся задачи на поддержку вот этих библиотек. Ну и получается, что у нас там сразу несколько потоков, что у нас есть общие там golden иджи, которые мы должны постоянно обновлять, чтобы они были актуальными правильными безопасными.
Speaker A
Блокировать загрузку небезопасных версий, то есть это можно делать на уровне registry. Это обновление системы библиотек, которая идёт конкретно на платформе, на команду. И уже всё остальное, всё, что осталось после всех вычеток, остаётся на команду разработки.
Speaker A
То есть мы их не беспокоим теми самыми там проблемами и цвешками, которые нашлись там на более низких уровнях. Да, как бы часто мы приходим к этой истории, что ой, у нас тут уявимость, мы не можем её никак исправить, ну, что что-то будем
Speaker A
делать. Но в любом случае эти процессы, они настраиваются. Мы можем сказать, что да, заводить уязимость там у себя на своей библиотеке, обновите там какой-нибудь пилоу, всё у вас будет о'кей. А вот система библиотека у вас будет там общая проблема уже в конце
Speaker A
решена. у вас будет общий релиз и потом просто обновите свой базовый образ. Единственный большой, наверное, для меня такой болючий момент, что есть сервисы, которые не обновляются, они уже в рантайме, они уже лежат давно, и они могут себе содержать огромное количество
Speaker A
проблем, потому что их тупо никто не обновляет. Ну вот работает, не трогай, там нет ресурса на этот сервис. И тут всегда стоит вопрос: что с ними делать?
Speaker A
Потому что, да, базовые образова будет обновляться, там уже 10 версий плюсом, но в рантайме она всё ещё будет сидеть уязимо. Е, и всегда стоит вопрос, что с этим делать. Тут нужен реестр того, что у нас есть в антайме. Нужен вот этот
Speaker A
сбом registry, чтобы понимать, где какие библиотеки торчат, насколько они актуальны и нужно литы обновлять. Ну и в дальнейшем уже идёт такой компонентный анализ тире там анализ странной безопасности. Вот мы видим криты, смотрим, насколько они у вас достижим.
Speaker A
Есть ли для них пок. Если есть пок, создаём какой-нибудь шаблон для нуклеи или там для несуса несуса. Сканируем внутреню инфраструктуру хотят же и смотрим, достижимо это или нет. Если достижимо, то мы уже там эскалируем инцидент, закрываем сервис, пока
Speaker A
кто-нибудь его не закроет, пока кто-нибуд его не исправит. Ну либо мы там закрываем, изолируем сервис от внешней сети. А если он чисто внутренне, его никто не трогает, то принимаем риск, заводим л, что он insecure и там заводим какой-нибудь технический клок, что надо
Speaker A
вот этот сервис либо вывести с эксплуатации, либо его обновить до последней версии. Вот эти сервисы потеряшки - это, наверное, самая большая боль как для бизнеса, так и для безопасности, потому что с ними что-то нужно делать.
Speaker A
Ну, в общем, да, подход такой, что условно разделяй васту вот это вот, что какая команда чупили, то за то и отвечает по собственно.
Speaker A
Да, всё так вот. А как вот думаешь, воевать здесь с таким подходом, что вот, допустим, о'кей, мы разбили вот эту вот ответственность, что у нас команда, которая пилит сервис, она отвечает за уязвимости, которую вот, ну, условно, она порождает. Вот, то есть там
Speaker A
какие-то версии компонентов, которые она написала, код, который она написала и так далее. А заязимости в базовом образе отвечает команда, которая его сопровождает.
Speaker A
А что делать, если язык базовообрази появляются там часто, э у команды тупо нету времени на это дело исправлять? Ээ стом там начать стопить релизы у долгих сер множество команд, организаций, которые используют этот базовый образ.
Speaker A
Они-то причём бы они не виноваты, они были рады. Вот. А вот эти плохие, а вы-то что? Что делать?
Speaker A
Ну, короче говорил, до конечно команды войдёт только то, что они отвечают. А базовый образ всё-таки отдельный процесс, потому что, как я уже говорил, иногда уявимости в базовом образе являются эксплуатированы только на уровне. Там не являются компонентом самого бп-сервера, например, или там
Speaker A
бывают проблемы с какой-нибудь утечка памяти - это крит. Ну вот такое бывает. Поэтому тут важно построить процесс некого релизного цикла, релизного окна, потому что действительно бывает, что база образом не обновляет долго или там обновление уже идёт большое мажорное и
Speaker A
оно затрагивает множество сервисов. И тут нужно форсировать историю, что вот у нас есть минимальная там версия образа, минимальная версия библиотек, для корбиблиотек, которые вроде разработчики сами себе скачивают даже дела не зависимости от от образов, они могут просто скачать условно
Speaker A
библиотеку, которая лица общее для всех, но вот они не обновляют. Вот с помощью runнтай инструментов, которые смотрят, какие у нас версии включены, можем форсировать использование обновлений.
Speaker A
Плюс, если мы говорим про продуктивные, про такие более быстрые способы решения вопросов, ну, есть яиш. У нас есть какой-нибудь там ДПНДбот, который может обновить базовый образ, проверить его совместимость и, если что, там зафиксить и дать его там на тестирование в
Speaker A
определённой команде. То есть, если мы говорим про распределённую ответственность, то вот команда, например, нашла уязимость, вот у неё там новый сервис, они такие: "О'кей, можем помочь, можем просто ставить заявку на команду, которая ответственна за базовый образ, а можем сами её исправить и,
Speaker A
например, закинуть её в режистри". Это такой расширенный подход, он не везде работает. Опять же, не всегда хотят люди брать ответственность за такие моменты, но часто, если говорить про ЦВешки, можно обойтись минорным обновлением. И тут всегда ставит вопрос, кто регулирует
Speaker A
голодонные образы, кто за них отвечает и можно ли что-то с ними сделать. Потом очень много вопросов уже к сырье, к индивоопсам, как мы построили процесс. И поэтому блокировка релизов, она в основном будет на продуктовой составляющей, то, что написали сами
Speaker A
разработчики. А вот эти базовые критичные моменты уже надо думать над тем, кто отвечает, насколько сейчас можем выправлять и для них принимается риск, не принимается. То есть мы вот прямо сильно завязаны на процессы.
Speaker A
Ну да, то есть понимает, насколько это вообще эксплуатируемая история просто тряжеть разгоняться ради крита, который низкий на самом деле.
Speaker A
Ну это, знаешь, наверное, небольшая проти информация. На текущем месяце мы прям подход обновлять всё. На предыдущем месяце мы это реально отряжили. У нас там реестр исключений был, ну, прямо большой. Там несколько тысяч разных звешек, которые мы проверяли руками и смотрели,
Speaker A
насколько это окне ок. Для базовых образов это суперважная вещь. Там для прикладных не всегда прикладные любовить, но бывали вот эти моменты с кор, скажем так, библиотеками, которые обновлять на мажорную не хочется, это слишком больно. И например, есть уявимость, нет фикса и вообще никто эту
Speaker A
библиотеку больше не трогает, никогда и не использует. И тут сразу как бы вопрос, это эксплуатируем, неэксплуатируемо. Даже если это эксплуатируемо это возможно стоит поставить большую задачу на следующий портал, найти замену этой библиотеки, прежде чем её там что-то с ней делать.
Speaker A
Так что да, это комплексный вопрос. Просто сейчас я больше привык обновлять и просто разработчик задачу. Пожалуйста, сделайте. Ну да, в целом подход с триажом тоже хороший, если есть инструмент для этого. Ну благо, когда есть возможность обновить. Вот потому
Speaker A
что тоже может быть такая история, что там типа мы бы рады обновить, но мы сейчас обновимся и там пять команд начнут выть, что у нихто всё отворилось.
Speaker A
Вот. Потому что а они свои компоненты обновить не могут, потому что там Legси какое-то бешеное. И вот так вот одно за другим. И приходится как-то решать эти моменты. О'кей, супер. Давай, наверное, будем к последней, наверное, теме подходить, которую я хотел обсудить ещё. Это про,
Speaker A
ну, про моделирование угроз немного. Как ты вот вообще в целом понимаешь этот процесс? И как бы вот ты его выполнял, тебе поставить такую задачу вот тоже подбно, как ты любишь, да?
Speaker A
Ну, моделирование гроз я начинал делать ещё в далёком там 2018 ещё только после облечения, как нас учили подходы, когда у тебя есть условно кусок системы, ты его моделируешь с точки зрения там компонент. Ещё даже я не понимал, что такое C4, не понимал,
Speaker A
что такое DFD. Просто для нас было важно нарисовать компоненты, что вот есть там веб-сервер, вот есть приложение, вот есть BD. Вот эту цепочку надо защитить.
Speaker A
И начинается вот эта история, что у нас есть возможные проблемы. То есть с точки зрения сего треугольника контенциально стала доступность, какие у нас есть потенциальные проблемы, к чему можем прийти. Затем мы рисуем дерево, какие вообще способы могут к этому привести.
Speaker A
Естественно, это очень трудоёмкий процесс, когда ты должен оценить все возможные функциональности, но поэтому как раз берётся кусок системы. То есть вот у нас есть система нофикации, авторизации, даже чистого нотификации уже достаточно. там вход по эсэмэске уже всё там сразу такое дерево,
Speaker A
что это спам, это сразу там, не знаю, подмена, взлом провайдера и кучу, куча куча всего. Полезно особенно для понимания самой системы на первом этапе как часть инвентаризации. Полезно, классно. То есть авадра предлагает всё ещё эту историю, нарисовать кружочки
Speaker A
самому и накидать туда эти самые угрозы и в дальнейшем уже меры митигации, если не нужны. Там с точки зрения финансовых сервисов суперполезно понимать, что вот у тебя есть функционал, который точно покрыты или вот здесь ещё ничего не покрыто, нужно что-то туда сделать. Если
Speaker A
мы говорим про там более комплексный подход, когда у тебя слишком много сервисов, слишком много функциональности, то работа подход, когда у тебя есть общая модель кросс, то есть она относится к бизнесу. Вот у нас бизнес, у нас есть покупатель, у нас
Speaker A
есть там доставщик, у нас есть там продукты, вот у нас есть веб-приложение, там офис система и там партнёры. Вот на эту всю систему мы рисуем общую модель.
Speaker A
У нас есть внутренний нарушитель, внешний нарушитель, внешние факторы, там supply chain, например. И вот эти все там четыре основных момента мы расписываем с точки зрения того, что может пойти не так. Там сервис упал, сервис взломали, деньги украли, не знаю,
Speaker A
бухгалтер взломали. То есть вот это общая такая сетка, общая модель угроз. Она важна для понимания, от чего мы защищаемся. Это очень важно для компаний, которые не работают прямо с финансами.
Speaker A
там те же самые игровые студии, какие-нибудь там маркетплейсы, не всегда тоже могут участвовать в истории, что вот у нас модель бизнес, она простая, она чёткая, мы на неё рисуем модель кросс, а затем, когда у нас появляется какая-то новая сложная фича, новая
Speaker A
интеграция, мы на неё уже можем нарисовать частную модуль кросс для того, чтобы понять вообще, что делать с ним. Скрет как пладарно для того, чтобы понять, а что сделать для того, чтобы нас не взломали, чтобы у нас там ничего
Speaker A
не утекло, чтобы у нас ничего не упало. Поэтому модель гроз - это вот именно про то, что что может пойти не так с точки зрения безопасности и что мы должны сделать для того, чтобы этого не было.
Speaker A
Конечно же, расписывать все варианты очень сложно и очень больно, но это действительно такой старый достаточно подход. А он стал, по-моему, обновляться. Появилась такая же штука, как, э, сейчас скажу agile, вот с тяжело выговариваем название. Это утилита, в которой ты рисуешь текущую архитектуру.
Speaker A
Она тебе сама рисует в целом общее состояние системы и примерно можно кидать, какие есть общие угрозы и риски.
Speaker A
Полезно, удобно, классно, но оно не учитывает бизнес-контекст. И вот для того, чтобы бизнес-конконтекст получить, у нас есть яишки. Это очень реально большая плюшка, где ты скармливаешь там документацию, описание confluence и сам код системы. И, например, тот же самый
Speaker A
кодек Security очень классно накидывает модель прос чисто на основе того, чтобы он проанализировал код. То есть вот у нас там документация авторизации, документация отминки. Мы тут взяли контекст, контекст, контекст и сам встроенный скилл уже тебе рисует модель грос изряда, что вот акцентная система,
Speaker A
вот это, вот это, вот это у тебя, то есть вот эти ручки, которые точно надо защитить. И скорее всего даже проведёт анализ безопасности и скажет: "А вот здесь тебе не хватает проверки безопасности, пожалуйста, это сделай".
Speaker A
То есть вот сейчас, наверное, это такой край технологии. где-то работает. То есть мы сейчас уже се в компании эту историю продвигаем, и штука реально ускоряет работу. То есть вместо того, чтобы просто формально нарисовать наликрос для то чтобы показать там
Speaker A
регулятором, то вот прямо делаешь нормальное рабочие решение. Интересно, вот, кстати, тоже для такой маленьки вопрос возник короткий. А использовать вот как кодекс, да, вот использовать подобные истории для, ну, типа корпоративных систем каких-то можно.
Speaker A
Ну, так да. лишние шумы. А на самом деле с вот внешними системами ишками там тоже самый клод кодекс очень важный момент - это тоже моделирование кросс. Что же будет, если твой код утечёт? Вот это, наверное, самая большая проблема. То есть мы уже
Speaker A
решали ративно такую историю ещё до там вот этих агентных подходов, когда у тебя весь код супер классный, супер клёвый, когда у тебя есть там сонный ассистент, копит, там, не знаю, source, gigacча и так далее.
Speaker A
Что будет с твоим кодом, если он утечёт? И что будет, если утечёт тот envirймент, который у тебя обеспечивает этот код?
Speaker A
Впеременные какие-нибудь строки, не знаю, кусочки бдшки для стейджа. для локальных тестов. Нужно понимать, насколько это важно, насколько это критично, и в идеале это всё вычислить, чтобы у тебя все секреты лежали в там каком-нибудь локальномчейне или, не знаю, хранилище в бдшном.
Speaker A
Угу. Чтобы у тебя был волт и так далее. То есть минимизировать риски утечки самой информации, вывести в политику, что ноу-хау и какие-то очень сложные алгоритмы, не выносить. Вот если возьмём Яндекс, у них есть система штизации, там вот револьверная есть, там поиск ширину, а,
Speaker A
звёздочка, ну, там разные есть алгоритмы, то есть как маршрутизировать разные маршруты, вот это ноу-хау, вот они этим делиться не будут. Понятно, что выишку это складывать не стоит. Это уже прямо хороший, правильный подход. Но если мы говорим про большую часть
Speaker A
микросервисов, 80% микросервисов, они типа, как шутит Jon перекладчики, когда у тебя Jonлетел, Jon переложил.
Speaker A
Вот для таких систем, где нету супер сложной логики, где у тебя там риск можно принять, что вот яишку можно это скормить, оно это там проанализирует, посмотрит и тебе выдаст какой-то результат. Поэтому, как мне кажется, это, наверное, просто более свежий опыт,
Speaker A
который у меня сейчас есть. М лучше очень грамотно подойти к подготовке. То есть любая работа с ишкой - это всё-таки контекст. Чем большой, чем больше контекста, тем лучше. Всякие МЦП-сервера, документации и так далее.
Speaker A
Это супер полезно, суперважно. И в самом коде не держать ничего чувствительного. Ключишрование, сертификаты и тому подобное не надо хранить. В целом нетушный подход держать ключи ковани в коде. Да.
Speaker A
Да, но опять же всё равно иногда бывает, особенно если там компания вайкодерская, они об этом просто не слышали и не знали. Какие-нибудь комментом типа это ключ шифрований.
Speaker A
Красота. Вот вспомнил я вопрос, который хотел мне там начале задать, который у меня вылетел.
Speaker A
Это вот как ты думаешь, ээ мы вот сейчас с тобой обсуждали много таких всяких технологий и тому подобного. Вот как и там в том числе языков. Ты думаешь, надо ли синьорам Секу быть синьором в том языке, который он защищает в Джаве там,
Speaker A
например, внете там ещё что? 5 минут микрофон выключил. Аэ так. Ну, вообще вопрос такой интересный с подвохом, мм, из-за того, что языков много, плюс там втором приходится менять работу. Э явный кейс.
Speaker A
Вот приходя там на первое место, у меня был там DNET, немножко питона, немножко джеса. Переходя на новое место, я встречаюсь со скалой. Сложный язык, дико неудобный.
Speaker A
И он что-то старое капец скала. Или я или я с чем-то путаю. Я, скорее всего, с чем-то путаю. Что-то подобное. Есть что-то очень сильно leg, да? То есть есть такие языки, которые действительно очень сложные прочитание, и надо хотя бы просто уметь его читать.
Speaker A
То есть не надо быть синьором в языке программиро. В идеале надо знать хотя бы один язык, хорошо, чтобы ты мог его там, условно для автоматизации использовать.
Speaker A
Поэтому такой стандартный базовой э требование - это Python, да, есть ребята, которые уже перешли на Goлайк. Я сам тоже надо читаю код относительно там поинтереснее поудобнее чем классический питом со в фостапе. Но опять же можно упороться в баш, можно
Speaker A
упороться всё, что угодно. Главное, чтобы у тебя был какой-то язык и ты понимал, как работает хотя бы ООП. Там функционально программирование всёдается тяжело, и это уже отдельная история. Ну, плюс там системные вызовы, как работает.
Speaker A
То есть хорошая база языковая должна быть хотя бы одна. Но быть сеньором там на уровне языко программирования вопрос хороший. Стоит ли? То есть я никогда не сталкивался с тем, что, не знаю, ты сеньоришь дотнете и всё вот там всё
Speaker A
прекрасно, всё хорошо. То есть ты можешь быть там на уровне Jun ПИМ. Ты читаешь хорошо код, ориентируешься, как он работает. И да, иногда желательно знать глубокие моменты, там как работает стерилизация, как работать какие-то интересные моменты. Очень классно иметь
Speaker A
таких специалистов, но, как мне кажется, легче это переложить на Lidfв, которые в компании так есть. У нас по-любому есть какой- Senior Plus, который шарт в технологиях. Если ты его склонишь на сторону безопасности, он будет решать эти самые вопросы намного быстрее, чем
Speaker A
ты. Тем более, что если там язык языков много, соопарк целый, знать их все очень сложно. Из таких новых кейсов прикольных, я ещё про это никому особо не рассказывал, но есть язык программирования 1S, любимый, классный 1S, который есть почти в каждой
Speaker A
компании. Сколько существует состов для 1С? Один. Насколько он эффективный? Ну, не очень. И понятно, что вот быть гуру 1S для безопасности обеспечения 1S-сервисов, блин, это сложно. То есть ещё найти такого человека надо, который будет шарить безопасности ещё самом 1С.
Speaker A
На удивление кодекс справился с анализом безопасности очень даже хорошо. То есть HTPS-сервис написан 1S как расширение.
Speaker A
И он прямо показал уязимость, им показал какие-то проблемы, которые выявились внутри кода. Интересно, да?
Speaker A
Такой: "Вау, прикольно". На самом деле, я не знаю, как он работает. Может быть, он просто перевёл все там слова на английский. Получился аля питон код. Но именно сам подход.
Speaker A
Я не исключаю. Возможно, он кассы сработал. как вот ээ тот самый адекватный обсек, который просто видит какие-то паттерны и говорит, что типа ну тут по ходу скуля тут похоже насску, здесь у вас, наверное, какая-то проблема с бизнес-логикой будет. Вот что-нибудь
Speaker A
такое. Да, да, да, это действительно ближе к этому сторону. Да, конечно, нужно отряжить. Есть вот эти моменты, где он нашёл там ой, вот тут у вас пустая строка может привести там к общему доступу ко всем данным. Ты смотришь вот
Speaker A
эту SQL-конструкцию, понимаешь, что это маленький логический кусок, но именно как сработка, как САСТ, это сработало.
Speaker A
На удивление неплохо. Поэтому любой обсек должен именно понимать саму структуру, как кот работает, какие есть подводные камни и как митирують самые проблемы. А вот как гуру ориентироваться на 100%, мне кажется, это уже излишне.
Speaker A
Классно, если такое есть. Есть кейсы, когда люди переходят из разработки безопасности. Это очень здорово. Но опять же, что разные технологии, не всегда получается быть там гу. Но есть исключение. Мы обильчики. Вот лично для меня, если ты тестишь мобилки,
Speaker A
ориентируешься в козе мобилок, ну, надо прямо хорошо разбираться. Всё-таки свой особый вот этот флёр, целый мир свой, да, есть. Это это нишего сейчас, что там и у тебя и веб, и инфра, считай в кавычках, там всё в одном месте,
Speaker A
вместе вообще. Вот ещё это две платформы самые популярные. Вот и везде свои какие-то приколы.
Speaker A
Да, это правда, да. А вот, да, ну, про синьора самый такой адекватный и правильный подход - это просто взять синьора из команды и сделать его чемпом и пускай он тебе помогает. Вот так.
Speaker A
Круто. Супер. Что у меня вопросов в целом больше нет? Может, у тебя есть какие-то вопросы?
Speaker A
Да, вроде так. Больших вопросов-то и нет. когда компания большая, процессы всегда в ней хорошие, но там опять же там самое опыту, перед трудоустройством самый важный вопрос для себя понять, это какие задачи будут стоять, это в какую сторону я буду двигаться. То есть
Speaker A
условно вот там я синьор на всех понятия сильные стороны видите архитектуры, но вот мобилки у меня проседают, смогу ли я их прокачать или там смогу ли я больше уйти в сторону иишек или там безопасности элек. То есть вот эти штуки
Speaker A
желательно, конечно, сразу узнать, потому что пару раз сталкивался с тем, что вроде ты развиваешься, огромное количество веток для развития внутри обсека, но, например, задач нет. Или, например, там есть уже другие люди, которые этим занимаются слишком давно, но тебе просто в эту сторону не дадут
Speaker A
развиваться. И это, наверное, самая большая боль, потому что действительно всех широкий, и ты можешь быть гуру, условно, в мобилках, но, скорее все ты в этом скоро выгорешь, встанешь и захочется что-то другое новое. Поэтому очень важно сразу понимать весь скоп
Speaker A
задач и понимать, в какую сторону ты двигаешься. Уже проходил через момент, когда всё классно, всё здорово, всё классно работает и понимать, что хочется ещё круче, ещё интереснее. Такого в целом на рынке нет. Приходится там немножко даунграйднуться и строить
Speaker A
что-то заново. Поэтому очень важно момент всё это узнавать ранее на тех этапах знакомства и собеседований.
Speaker A
Поэтому, ну, конечно, да. Вот и есть такого тоже, что можно добавить, когда такой есть, ну, большой какой-то бэкграунд. э-э разные там разные крупный активный опыт, то это может быть ещё такое интересное, что тебя осо взяли на одни задачи, вот,
Speaker A
а ты пришёл и смотришь, говоришь, типа, давайте я лучше вот это сделаю. И они такие: "А что, так можно делать, что ли?" Такой вообще да такой: "Вау, давай". Вот.
Speaker A
Да, классный поход, когда есть, да, когда можешь что-то новое привнести. Для синьорского уровня действительно очень важно, что есть какая-то свобода вот такая. Ши шире мыслишь, видишь проблемные моменты и начинаешь их справлять уже сам.
Speaker A
Да, без пинков. На синьорского уни кажется должна какая-то такая свобода вот в этих, а чтобы типа условно самому себе какие-то задачи придумать. Вряд ли ты себе там на таком уровне придумаешь там задачу, типа, да, я просто буду сидеть рашить
Speaker A
тебя зачем. Вот они такие: "Ну ладно, всё, ну зачем ты нам тогда будешь?" Вот в общем, как-то так.
Speaker A
Ну круто, здорово пообщались. по тихой закруглять наше великое собеседование. Согласен. Да, здорово пообщались. Спасибо.
Speaker A
Да, спасибо.
Topics:Application Securityтехническое интервьюуязвимостибезопасность приложенийDevSecOpsархитектура безопасностиlegacy-системыутечка данныхбанковская безопасностьмикросервисы
