Комментарии 17
Информационная безопасность, это когда начальство просит тебя добыть информацию о количестве пользователей продукта, тебе сначала нужно отыскать всех лгунов, которые до тебя предоставляли эту информацию, согласовать с ними цифры, чтобы не произошла рассинхронизация брехни. Потому что делать рассинхронизацию брехни невероятно опасно.
А почему вот так сложилось? В чём препятствие к получению реальных чисел в данном случае?
Смею ответить несколько с философских позиций...
Потому что в системах основанных на лжи, "неучастие во лжи" делает из тебя диссидента, поскольку несет угрозу общей системе. Например, на основании брехни уже были выданы премии и посчитан KPI... Тогда твои данные вскроют манипуляции и что делать? Есть два варианта и оба не без греха: "отрицание" и "принятие".
Если система изберет "отрицание", правдивую информацию примут, как есть. Но интерпретировать будут с позиций предыдущей лжи. И, получается, в этом отчетном периоде количество пользователей снизилось. А значит коллектив плохо сработал. А далее вступает принцип коллективной ответственности. И: "Кто виноват?" - "Правдолюб!" - "Ату его..."
Если система "примет" правдивую информацию, то будет назначен "стрелочник", который ранее подал не верные сведения. Хорошо если это уволенный сотрудник, но можно поискать козлищ и среди работников. Система учтет новую информацию, но не разуверится в своей непогрешимости. А далее вступает принцип коллективной ответственности. И: "Кто виноват?" - "Правдолюб!" - "Ату его..."
Не надо думать что "Архипелаг" это про частный случай определенного периода. Это про общие закономерности ситуации, когда авторитарная власть играет в тимбилдинг. И от времени, страны и масштаба корпорации это не зависит.
Курсы по фишингу и безопасности данных бесполезны, больше для галочки.
В реальности чаще встречается корпоративный шпионаж, чем взлом и несанкционированная рассылка фишинговых писем. В компаниях, занимающихся помимо софта ещё разработкой своего желаза, периодически утекают чертежи. Это прям реальная проблема. На знаю, насколько подобное критично в чисто софтовых компаниях.
Очень зависит от рода деятельности компании. Например, на складском терминале куда выше угроза парализовать работу, открыв менеджером склада фишинговый "Акт о расхождениях", нежели пострадать от утечки схемы перемещения контейнеров и паллет. Тут как раз курсы/инструктаж персонала сильно помогает.
Всякое обучение требует экзаменов. Если кто-то будет разика два за год пытаться задурить менеджера (всё изобретательнее и изобретательнее), и менеджер будет ИБшникам этого «учебного хакера» сдавать за премию, вместо того, чтобы открывать его «акт о…», прилагая камменты типа «директор отродясь с этого адреса не писал» — через две-три премии менеджер будет уже сам мыслить как противник :-D даже если там копейки.
Инфобез это когда ты вводишь 3 пароля, входишь в впн по пину. Чтобы скопировать любой файл идёт логирование, а потом тебе спокойно ставят гит на компьютер и ты с помощью git push сливаешь всю папку "контракты" абсолютно незаметно для всех анальных зондов.
Из своего опыта (к счастью, ошибки не мои, я наоборот, дартаньян, который их нашел, но были бы и моими, если бы я был на другом месте). Разработка системы либо поручается на сторону, либо своему отделу разработки. Естественно, ведется без учета требований по защите кроме очевидных. То есть, никто, конечно, не говорит - "будем намеренно делать систему как можно более уязвимой", и даже не признает "безопасность у нас лишь второй приоритет". Скорее декларируется, что система должна быть безопасной, защищенной, но за этими словами нет ничего, никакого контроля или мотивации. В то время как в противоположную сторону работают дедлайны и вполне конкретные фичи, которые надо сделать. В итоге
- Капча на логине висит, но не проверяется вообще
- Пароли хранятся в хешах (спасибо, что хоть так), но не соленые
- Никаких там CSRF токенов (если фреймворк сам их жестко не прописывает по дефолту)
- cross origin? про это не думают, а если (с современными браузерами) упираются, то '*'наше все.
- все дебажные методы остаются в продакшне
- пароли вроде test/test или имя-компании/имя-компании на удивление часто работают!
- проверки на стороне клиента. То есть, какой-то важный метод API открыт всем, просто веб-морда его не показывает. Обычный broken authentication.
В общем, описывать конкретные проблемы нет большого смысла, есть общая организационная:- чтобы сделать систему быстро - есть мотивация, чтобы реализовать в ней все нужные меры безопасности - нету.
Зачастую проблемы всем известны. А вот решения - нет. А если и известны, то на них нет денег. А если есть, то результат оказывается что лучше засекретить.
Часто хочется увидеть скорее наборы решений, их метрики, какие решения оказались проблемными и как это решать. Зачастую это требует совсем другого уровня от специалистов (не только ИБ), а этого нет.
Какой прелестный тест.
Некоторые вопросы напоминают вопросы детям: "хочешь ли ты съесть гречку, или эту замечательную цветную капустку", хотя понятно, что ребёнок ненавидит и то и другое, и хочет мороженку. О чём это я... Какой-то из вопросов звучит как "что нужно доработать в защите?". И варианты: "ничего" и "улучшить защиту". Почему нет логичного варианта "ослабить защиту" совершенно не понятно. А он должен быть, ибо часто случается так, что половина рабочего времени уходит не на работу, а на то, чтобы обойти защиту, которая тупо не даёт работать. (блокирует работу отладчиков, жрёт скорость компиляции, сносит исходники с криком "ай-яй-яй, это вирус", блокирует доступ к вполне легальным сайтам, теряет свои собственные логи, что мешает понять, а что ж произошло то, и т.д. и т.п.)
И где вообще вариант "обучить экспертов ИБ... программированию"? ;) Кажется, что они ни разу в жизни не запускали хотя бы студию, и в принципе не в курсе, что для этого нужно.
Зачастую проблемы всем известны. А вот решения - нет. А если и известны, то на них нет денег. А если есть, то результат оказывается что лучше засекретить.
Часто хочется увидеть скорее наборы решений, их метрики, какие решения оказались проблемными и как это решать. Зачастую это требует совсем другого уровня от специалистов (не только ИБ), а этого нет.
Я бы добавил, что специалистам по ИБ не хватает понимания в следующих направлениях:
Управление процессам - часто создаваемые ИБ процесс не зрелые
Управление рисками - сотрудники ИБ плохо понимаю про риски в целом, что с ними можно делать, кто ими управляет, как происходит их анализ и оценка
Что такое ИБ - мне кажется, что специалисты по ИБ не знают или часто забывают самое базовое, что ИБ это не только защищённость, но еще и доступность и целостность. От этого у ребят происходит когнитивное искажение.
Работа с требованиями. Что требования ИБ должны быть реализуемыми и обоснованными, соответствующими принятым в компании стандартам.
Архитектура - хочется чтобы ребята понимали, какие в целом подходы архитектурные есть, чтоб то ПО, которое они заказывают, можно было потом использовать.
Отдельно курс корпоративного общения
Я разработчик. Периодически возникают ситуации когда дают доступ к тому что мне не нужно (после кучи согласований и ожидания), а потом пытаются не дать мне это украсть. Запрещают делать скриншоты, неужели они не догадываются что можно относительно легко сделать копию экрана при помощи телефона? Или заставляют ходить куда-то через кучу VPN с одновременным вырубанием инета, зато для крутости - с хардварным токеном. А ведь проще не дать доступ к критичным данным, чем блокировать попытки их украсть.
Вот и начинается концерт: что-то надо спросить у коллеги - выключай VPN, спросил - включай обратно. Что-то надо где-то почитать - опять выключай. Тестовые сервера зачем-то тоже в критической подсети живут. Заблокировали гугл-диск, а яндекс - работает. В Фигме работать запретили, внешний же ресурс, а замену не дали. В итоге большие затраты времени и нервов.
Хотелось бы получить фидбэк по одной мысли по поводу утечек баз данных ( к ИБ не имею отношения, так вопрос делитанта)
Предположим у нас есть некая база с данными пользователей. И к ней имеют разного уровня доступ разного уровня N сотрудников, что если мы добавим в нее N микромассивов ложных ловушек, и каждому сотруднику будет доступна база, с только ему доступным ложным микромассивом (например из 10^6 комбинацией ФИО, телефонов и иной информацией, штук 10 ложных данных в данной версии), и когда происходит утечка, по ложному микромассиву можно было бы определить откуда утечка. Да на практике реализация не так тривиальна, но в теории... Случаев утечки данных тысячи слышал, а про такой инструмент нет.
Разумеется это актуально когда руководство компании мотивировано в отсутствии утечек
Например к каждому сотруднику прикрепить в базе одного ложного пользователя, с ложным виртуальным мобильным номером, и любой спам звонок на этот номер, либо запрос в базу по данному ложному пользователю, это уже признак (не 100%) утечки от такого сотрудника, и можно дальше брать в разработку
Даже утечка исходной базы без ложных данных это тоже признак, и утечка о конкретного сотрудника это не 100% что он сам сотрудничает с злоумышленниками, это может быть и социальная инженерия, или злоумышленники в курсе про инструмент, и специально так подстроили, но это маловероятные сценарии, а вот банальная продажа сотрудником базы вполне бы могла вычисляется таким методом
Не так давно мне, аутсорснику, дали полный доступ на сервер. Где вообще всё, включая бухгалтерию. Вот и вся безопасность — тащи что хочешь, редактируй что хочешь. Нет слов.
Инфобез в компаниях: обучать или не обучать?
Привет, Хабр! Нас давно занимает вопрос, как в компаниях обстоят дела с информационной безопасностью в IT. Так что мы решили спросить у пользователей Хабра: что там у вас с ИБ?