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

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

Инфобез это когда ты вводишь 3 пароля, входишь в впн по пину. Чтобы скопировать любой файл идёт логирование, а потом тебе спокойно ставят гит на компьютер и ты с помощью git push сливаешь всю папку "контракты" абсолютно незаметно для всех анальных зондов.

Из своего опыта (к счастью, ошибки не мои, я наоборот, дартаньян, который их нашел, но были бы и моими, если бы я был на другом месте). Разработка системы либо поручается на сторону, либо своему отделу разработки. Естественно, ведется без учета требований по защите кроме очевидных. То есть, никто, конечно, не говорит - "будем намеренно делать систему как можно более уязвимой", и даже не признает "безопасность у нас лишь второй приоритет". Скорее декларируется, что система должна быть безопасной, защищенной, но за этими словами нет ничего, никакого контроля или мотивации. В то время как в противоположную сторону работают дедлайны и вполне конкретные фичи, которые надо сделать. В итоге
- Капча на логине висит, но не проверяется вообще
- Пароли хранятся в хешах (спасибо, что хоть так), но не соленые
- Никаких там CSRF токенов (если фреймворк сам их жестко не прописывает по дефолту)
- cross origin? про это не думают, а если (с современными браузерами) упираются, то '*'наше все.
- все дебажные методы остаются в продакшне
- пароли вроде test/test или имя-компании/имя-компании на удивление часто работают!
- проверки на стороне клиента. То есть, какой-то важный метод API открыт всем, просто веб-морда его не показывает. Обычный broken authentication.

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

Зачастую проблемы всем известны. А вот решения - нет. А если и известны, то на них нет денег. А если есть, то результат оказывается что лучше засекретить.

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

Какой прелестный тест.

Некоторые вопросы напоминают вопросы детям: "хочешь ли ты съесть гречку, или эту замечательную цветную капустку", хотя понятно, что ребёнок ненавидит и то и другое, и хочет мороженку. О чём это я... Какой-то из вопросов звучит как "что нужно доработать в защите?". И варианты: "ничего" и "улучшить защиту". Почему нет логичного варианта "ослабить защиту" совершенно не понятно. А он должен быть, ибо часто случается так, что половина рабочего времени уходит не на работу, а на то, чтобы обойти защиту, которая тупо не даёт работать. (блокирует работу отладчиков, жрёт скорость компиляции, сносит исходники с криком "ай-яй-яй, это вирус", блокирует доступ к вполне легальным сайтам, теряет свои собственные логи, что мешает понять, а что ж произошло то, и т.д. и т.п.)

И где вообще вариант "обучить экспертов ИБ... программированию"? ;) Кажется, что они ни разу в жизни не запускали хотя бы студию, и в принципе не в курсе, что для этого нужно.

Зачастую проблемы всем известны. А вот решения - нет. А если и известны, то на них нет денег. А если есть, то результат оказывается что лучше засекретить.

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

Я бы добавил, что специалистам по ИБ не хватает понимания в следующих направлениях:

1. Управление процессам - часто создаваемые ИБ процесс не зрелые

2. Управление рисками - сотрудники ИБ плохо понимаю про риски в целом, что с ними можно делать, кто ими управляет, как происходит их анализ и оценка

3. Что такое ИБ - мне кажется, что специалисты по ИБ не знают или часто забывают самое базовое, что ИБ это не только защищённость, но еще и доступность и целостность. От этого у ребят происходит когнитивное искажение.

4. Работа с требованиями. Что требования ИБ должны быть реализуемыми и обоснованными, соответствующими принятым в компании стандартам.

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

6. Отдельно курс корпоративного общения
   

Я разработчик. Периодически возникают ситуации когда дают доступ к тому что мне не нужно (после кучи согласований и ожидания), а потом пытаются не дать мне это украсть. Запрещают делать скриншоты, неужели они не догадываются что можно относительно легко сделать копию экрана при помощи телефона? Или заставляют ходить куда-то через кучу VPN с одновременным вырубанием инета, зато для крутости - с хардварным токеном. А ведь проще не дать доступ к критичным данным, чем блокировать попытки их украсть.
Вот и начинается концерт: что-то надо спросить у коллеги - выключай VPN, спросил - включай обратно. Что-то надо где-то почитать - опять выключай. Тестовые сервера зачем-то тоже в критической подсети живут. Заблокировали гугл-диск, а яндекс - работает. В Фигме работать запретили, внешний же ресурс, а замену не дали. В итоге большие затраты времени и нервов.

Хотелось бы получить фидбэк по одной мысли по поводу утечек баз данных ( к ИБ не имею отношения, так вопрос делитанта)

Предположим у нас есть некая база с данными пользователей. И к ней имеют разного уровня доступ разного уровня N сотрудников, что если мы добавим в нее N микромассивов ложных ловушек, и каждому сотруднику будет доступна база, с только ему доступным ложным микромассивом (например из 10^6 комбинацией ФИО, телефонов и иной информацией, штук 10 ложных данных в данной версии), и когда происходит утечка, по ложному микромассиву можно было бы определить откуда утечка. Да на практике реализация не так тривиальна, но в теории... Случаев утечки данных тысячи слышал, а про такой инструмент нет.

Разумеется это актуально когда руководство компании мотивировано в отсутствии утечек

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