С начала 2018 я собрираю отчеты о взломах в криптопроектах. За это время поступила информация о кражах почти на миллиард долларов. Одна лишь биржа coincheck проспонсировала кого-то на ~500 миллионов. При этом на некоторых биржах до сих пор нет двухфакторной авторизации. Сайты финансовых компаний используют сторонние скрипты без проверки подлинности. Браузерный кошелек MetaMask светит адрес вашего кошелька всем сайтам без разбора. А самым популярным приемом остается security through obscurity. Но, возможно, все еще хуже и сегодня повсеместно распространена имитация безопасности и летний доклад NIST частично это подтверждает.
Сегодняшний подход к безопасности не учитывает особенностей человека, о чем собственно и говорится в отчете NIST (статья на тему). Вот основные проблемы, которые наблюдаются сегодня:
- Отсутствие ответственности за результат.
- Излишняя строгость правил.
Обе причины демонстрируют инверсию логики. Давайте рассмотрим их подробнее.
Отсутствие ответственности
Производитель продукта не отвечает за последствия взлома, максимальные нежелательные последствия для него – выплата компенсации или банкротство. Руководство компании никак не заинтересовано в повышении требований безопасности. При этом любой пользователь, который обнаружит дыру и сообщит об этом, рискует угодить на скамью подсудимых. Теперь вопрос, что мешает сотрудникам такой компании ограбить самих себя?
Пример компании Дюпон.
Основанная в 1802 году в городе Уилмингтон, штат Делавэр, США, компания Du Pont начала свою деятельность с производства оружейного пороха. Несколько взрывов, произошедших на заре ее деятельности, заставили руководство фирмы осознать важность техники безопасности для успеха предприятия. Руководство компании разработало новую философию безопасности: с одной стороны, на высший руководящий состав предприятия возлагалась особая ответственность за несчастные случаи, а с другой – все работники были обязаны проживать на производственной территории. Таким образом, безопасность труда стала делом личной заботы каждого.
Из статьи с сайта ИНЭС
Излишняя строгость правил
В докладе NIST говорится о том, что люди не склонны запоминать сложные и часто меняющиеся пароли. А правила использования сложных парольных фраз из цифр, букв, спецсимволов, математических формул и расчета числа Пи в уме приводит к появлению стикеров с паролями на мониторах. Парадокс выжившего говорит о том, что причина выживания в опасных ситуациях, ничего не сообщает о причине гибели, а следовательно не помогает эту гибель предотвратить. Другими словами взломостойкость сильных паролей, не является способом построить надежную систему.
Разработчики подходят к задаче слишком формально и перекладывают задачу обеспечения безопасности на не слишком-то надежный элемент – человека. В итоге, внедряя более сильные методы защиты, мы ослабляем безопасность в целом.
Недавно я столкнулся с тем, что сайт загруженый по HTTPS не может взаимодействовать с HTTP-протоколом, при этом браузер не спрашивает моего разрешения на осуществление такого действия, а просто отказывается выполнять запрос. В итоге я переключился на HTTP-протокол, после чего уже два ресурса грузятся в небезопасном режиме.
Заключение
Когда я выстраиваю в голове систему безопасности, то безоговорочно проигрываю злоумышленнику – количество элементов требующих настройки, отключения или дополнительной разработки слишком высоко. О работе некоторых компонентов операционной системы я не имею ни малейшего представления и не знаю как определить: работают ли они корректно, кто их произвел, были ли они подменены и т.п. Из-за этого иногда у меня возникает синдром самозванца. Действительно ли я настроил все правильно!?
Я скачал CIS Distribution Independent Linux. Это сборник рекомендаций по настройке linux. В нем 317 страниц, более сотни потенциальных уязвимостей. В процессе чтения у меня всплыл вопрос: как много разработчиков вообще знают о таком документе?
Хаб Информационная Безопасность на втором месте на Хабре (популярнее Программирования в два раза!). Это следствие заботы о безопасности или вариант оберега? Чувствуете ли вы себя уверенно в сфере ИБ?
Комментарии (38)
ildarz
16.02.2018 22:30+1Хаб Информационная Безопасность на втором месте на Хабре (популярнее Программирования в два раза!). Это следствие заботы о безопасности или вариант оберега?
Это, к сожалению, всего лишь индикатор популярности у аудитории статей вида "как я со своего мака ломанул соседский вайфай".
SirEdvin
16.02.2018 22:31Я думаю, вы читали довольно экспрессивную статью про то, что все сломано. На самом деле, внедрения наказаний и прочего за взломы не особы бы помогло, потому что грамотных ИБ специалистов просто капля в море и на все компании их не разорвать, а безумно увеличивающиеся количество интегрируемых компонентов в современных системах (новые базы данных, протоколы, библиотеки и прочее) не позволяют большинству людей возможности оценить потенциальные угрозы.
И наказания тут не помогут, максимум, безумно взвинтят стоимость разработки.TrllServ
16.02.2018 22:43Возможно ошибаюсь, но мне кажется, что реальное наказание простимулирует рост кол-ва специалистов. Например через создание площадок обмена опытом, меньше соблазна найти крайнего в виде сообщившего об уязвимости(при условии что оператор+начальник будут наказаны всё равно) и тд
SirEdvin
16.02.2018 22:48Ну вот рост профессиональных программистов почему-то не стимулирует ничего, хотя надо их хоть лопатой греби. Вместо этого у нас куча средних. Так же будет и с специалистами по ИБ. Они будут применять базовые инструкции, будут мучать всех заменой удобных инструментов на "безопасные" ну и так далее, но реального профита это принесет разве что в стартапы, которые теперь будут вынуждены нанимать специалиста по ИБ и не торчать портами баз без паролей наружу, но проблема то не в них.
TrllServ
16.02.2018 23:10Я изначально дал ситуацию с идеальными исходными, само собой ни отстранять не будут ни вкладываться в развитие отрасли на федеральном уровне. Потому как для этого нужен хороший руководитель-организатор, которых так же мало как и хороших програмеров или безопасников.
questor
17.02.2018 16:17После того как 20 миллионов паролей утекли в сеть — Испания разорилась м бала продана за символический рубль тем, кто разбирается в защите? Так если компании не разоряются после подобных инцидентов они должны увольнять свое руководство? Нет никого, кто был бы заинтересован в этой самой безопасности. Вы например уходите с сайтов, где прошел взлом на другой, более стойкий? Ну вот и причина, почему это не особо кому-то нужно.
AlexTOPMAN
17.02.2018 16:34Ошибаетесь только лишь в случае, когда на предприятии/в компании «автоматизируется бардак». Но, такая ситуация не всем очевидна. Для многих руководителей допущения вроде «называть бледно красное иногда ярко-розовым или т.п.» могут по понятиям бардаком далеко и не являться. Но, это не так. И именно с этого для службы ИТ, а впоследствии и для ИБ может начаться «сущий ад» и, как следствие, следующая за этим выдача желаемых результатов своей работы за действительные. И наказания тут проблему действительно не исправят.
SantaCluster
19.02.2018 09:09"мне кажется, что реальное наказание простимулирует рост кол-ва специалистов"
а мне кажется, что как раз наоборот. лично я 10 раз подумаю, а надо ли мне лезть в такое болото, если надо-мной будет висеть угроза сильного наказания. вот если при этом увеличить количество "плюшек", которые получат оставшиеся храбрецы… спецов будет немного, но они будут реально крутые
DonArmaturo
19.02.2018 10:16Хорошо, если будет больше специалистов, разбирающихся в ИБ. Боюсь, что просто начнут "готовить специалистов по ИБ".
Как дурной пример подобного подхода, прежняя работа: в службе безопасности было больше админских учёток с правами на все филиалы, чем собственно админов в этих филиалах. Безопасность, все-ж таки, создаётся админами и программистами. Тупое наращивание "контролеров и охранников" не даст эффекта.
zenkz
16.02.2018 23:51+1Безопасных систем не бывает. Если кто-то очень хочет взломать систему, то это обязательно случится. В то же время во всех организациях где я работал были проблемы с безопасностью (где-то больше, где-то меньше). Но просто закрутить гайки или ввести наказания не получится, т.к. безопасность важна пока она не начинает мешать основному бизнесу, а наказания вообще ничего не решают — обучение и проверки (без наказания) намного полезнее…
А вообще даже если создать идеальную систему безопасности, то уязвимость найдётся в людях (социальная инженерия, взлом домашних аккаунтов в надежде, что на работе используется такой же пароль и т.д.)geher
17.02.2018 11:10А вообще даже если создать идеальную систему безопасности, то уязвимость найдётся в людях
Отож. Многие взломы осуществлялись без единой строчки кода, только болтовня с сервисом.
khim
17.02.2018 18:35а наказания вообще ничего не решают — обучение и проверки (без наказания) намного полезнее…
Не надо только в крайности вдаваться. Обучение и проверки без наказания работают очень недолго. И наказывать надо и поощрять — но в меру. Выкидывать «на мороз» специалиста, который один раз накосячил глупо: вероятность что человек без опыта накосячит больше, чем вероятность что кто-то, кого один раз наказали такое повторит…SantaCluster
19.02.2018 09:17да. я вот однажды дропнул боевую базу (перепутал с тестовой). восстановили, конечно, из бэкапа. но с потерей данных за несколько часов (около 10). лично мне было ужасно стыдно перед всеми и без дополнительного наказания. а если бы за это меня вышвырнули на мороз, то ещё неизвестно, кому в итоге стало бы хуже ;) А так, были сделаны выводы и предприняты определённые меры по предупреждению-недопущению подобных инцидентов
TrllServ
19.02.2018 10:12Вы правда не понимаете разницы?
Может всё же есть разница в ответственности и главное последствиях когда утекают данные реальных людей, большую часть которых поменять проблематично или невозможно т.е. необратимыми последствиями, и дропнул базу и восстановил за 10 часов?
А то, что написано "+наказание начальства" совсем не заметно?
Давайте на вашем примере поясню, что имелось ввиду:
«Дропнуть базу» случайно, в том или ином виде случалось у многих специалистов по причинам от не опытности до авралов.
Но это давно пройденный и известный этап уже десяток лет минимум, и от него можно защититься заранее, т.е. то что вы сделали «после», можно было сделать «до».
И тут, я лично так считаю, вина вашего начальства заметно больше, чем ваша.
PS:
Выгонять на мороз и прочие репрессивные методы — зло.
В первом сообщении написано «запрет занимать должность», это подразумевается, но не всем очевидно раз такая ветка получилась. Уточню:
Запрет занимать должность — начальству допустившему халатное отношение, а уже длительность в зависимости от серьёзности утечки и уровнем пофигизма(отсутствие исправлений безопасности, отсутствие файрвола, отсутствие простой «защиты от дурака» и тд).
При этом не было ни слова про запрет продолжать проф. деятельностью оператору/админу.netch80
19.02.2018 11:40Может всё же есть разница в ответственности и главное последствиях когда утекают данные реальных людей, большую часть которых поменять проблематично или невозможно т.е. необратимыми последствиями, и дропнул базу и восстановил за 10 часов?
В ответственности и последствиях — есть разница. Но чтобы она от этого появилась в принятых мерах по отношению к виновнику — надо думать в концепции мести, а не поиска и устранения причины. Месть предполагает, что 1) совершивший проступок не меняется и будет его совершать и дальше, 2) другие, видя это, будут осторожнее.
Да, наше общество и цивилизация пропитаны концепцией мести — уголовный и административный кодекс просто от и до и насквозь. Да, в общем случае нет разумной работающей альтернативы, когда всепрощение приводит к тому, что кто-то тут же садится на голову. Но это не значит, что в конкретных случаях нельзя разобраться, что же именно произошло и, даже если вина кого-то, что его заменять будет безусловно лучше.
Извините, тут многовато философии. Но без этого сложно объяснить, почему же не изгоняют за малейший косяк.
А вот на более высоком уровне — важные данные стоило бы защищать получше. Может, даже нанять трёх спецов вместо одного, но чтобы действия одного в принципе не могли сломать/продырявить всё. (Это тоже давно известный и проверенный метод.)
1A1A1
19.02.2018 10:16"безопасность важна пока она не начинает мешать основному бизнесу"
Пожалуй единственная весомая фраза во всём обсуждении, говорящая почему оно так как есть, и почему так и будет.netch80
19.02.2018 11:41+100. Занесу это в свой цитатник :) Отличное дополнение для всяких "хотели как лучше, а получилось как всегда".
Vkuvaev
17.02.2018 12:54Ждем инклюзии (без злой иронии) спецов по безопасности в понятие команда разработки.
Удивлен, что до сих пор нет в гибких методиках секьюрити стори, ну и если будет необходимо хакер стори.
Как в статье сказано, нет целостного взгляда на безопасность, и оказывается, пользователь, чтобы что-то осмысленное и вовремя сделать вынужден снижать общую безопасность( стикеры с паролями ), или, часто меняющийся пароль, но с одной цифрой счетчиком внутри, по-сути не меняющийся и легко подбираемый в случае компрометации «старого» пароля.
И так далее, тема только сейчас стала осознаваться индустрией.
AlexTOPMAN
17.02.2018 16:13Цитата: «правила использования сложных парольных фраз из цифр, букв, спецсимволов, математических формул и расчета числа Пи в уме приводит к появлению стикеров с паролями на мониторах».
А что, таким пользователям никто не может подсказать простой бесстикерный способ доработки своего «любимого простого пароля» до относительно безопасного? Добавьте ему алгоритм лёгкого изменения. Пример для женщин: берём имя мужа + дату свадьбы, в имени переставляем местами вторую букву с третьей и вставляем между ними разрешённый системой паролей спецсимвол ($ например), а от даты оставляем просто сумму числа месяца и года. Готово. После нескольких повторений ввода — пароль запоминается очень легко. И даже если по выходу из отпуска таки его забыла, то легко «на коленке» вспомнить алгоритм и пароль восстановить. И стикер не нужен совсем (случай, когда он на время отпуска оставляется специально «для МарьИванны» — отдельный и здесь сейчас не рассматривается).VolCh
18.02.2018 15:39+2Этот алгоритм ещё сложнее запомнить, чем набор случайных символов, а безопасность снижает ещё больше: знаешь алгоритм, в котором практически нет случайных данных — знаешь пароли всех женщин в системе.
AlexTOPMAN
19.02.2018 18:36Два действия: символьное и простое математическое. Что там запоминать?
А насчёт знаешь пароли всех женщин — тут вы зря лукавите. Вы прекрасно увидели, что алгоритм этот — с адаптируемыми настройками. У одной первая и вторая буква. У другой — первая и последняя. Как угадать у кого какая меняется? То же и с математикой. Вариативность со вполне достаточной избыточностью, чтобы понять, что подбор получится чистым гаданием на кофейной гуще.VolCh
19.02.2018 20:09С большой вероятностью, если вы дадите пользователям организации эту инструкцию для составления паролей, то даже спецсимвол будет именно $ у большинства, не смотря на то, что явно указано "например".
OlvinKSA
18.02.2018 16:18И даже если по выходу из отпуска таки его забыла, то легко «на коленке» вспомнить алгоритм и пароль восстановить.
Это вы, наверное, по выходу из отпуска никогда не забывали детали такого алгоритма. Напрочь.AlexTOPMAN
19.02.2018 18:42Пользуюсь лет 20 уже (как додумался до такого). Конкретный набор букв и цифр в паролях — да, забывал бывало. А вот сам алгоритм и свои настройки к нему — не забывал ни разу. :)
netch80
18.02.2018 22:25И что делать, когда пароль надо сменить — например, сайт взломали и пароли утекли?
Специфичный алгоритм для каждого сайта? Это ещё сложнее для запоминания.AlexTOPMAN
19.02.2018 18:53Зачем всё так усложнять? Нда, похоже, без пояснения всей концепции не обойтись.
«Для каждого сайта» можно использовать набор из двух алгоритмов:
1. безопасного (с регулярной сменой исходного набора данных для пароля или же изменением параметров алгоритма, т.к. тут по другому никак — безопасность требует телодвижений. этот подход для данных, которые опасно терять).
2. расходного (один взломали или утёк в чужие руки — тупо меняем на другой, но не боимся снова «потерять» его — это для большинства сайтов, где пароли просят для обычной приватности)
sumanai
18.02.2018 22:28Что люди только не делают, лишь бы менеджеры паролей не использовать.
TrllServ
18.02.2018 22:54Разве менеджер паролей не компромисс между проблемой выбрать правильно+запомнить и безопасностью подразумевающей знание пароля только владельцем, без посредников в виде особого ПО?
sumanai
19.02.2018 08:33Я больше доверяю программе с открытым кодом, которая синхронизирует пароли с моим личным сервером, чем своей памяти. И не вижу тут никаких компромиссов — менеджер паролей выдаёт и запоминает сложнейшие пароли, уникальные для каждого сайта, и в итоге нужно запомнить только пароль на менеджер, и вот он может быть весьма сложный, такой, который вводить на сайты просто будет лень.
AlexTOPMAN
19.02.2018 19:38Я так понимаю, если что, то вместе с менеджером — теряем сразу всё? Да и для ввода «суперпаролей» явно же потребуются телодвижения по переносу их на ПК с которого осуществляется вход (где не всегда могут иметься подходящие тебе способы подключения твоего менеджера).
sumanai
19.02.2018 20:36Я так понимаю, если что, то вместе с менеджером — теряем сразу всё?
Поэтому у меня копия хранится на трёх устройствах и своём сервере.
Да и для ввода «суперпаролей» явно же потребуются телодвижения по переносу их на ПК с которого осуществляется вход
В смысле? KeePass стоит на конечном устройстве, и сам вводит пароли. На ПК конечно удобнее всего- для браузера есть дополнение, и ввод пароля ничем не отличается от родного менеджера паролей браузера, на мобильном чуть посложнее, лично у меня стоит типа специальной клавиатуры, которая даёт выбирать аккаунты и вводит пароль. Но решений полно, софт гибкий, настраивайте как вам угодно, балансируя между удобством и паранойей.
TrllServ
Отсутствие ответственности это повсеместная проблема, иначе бы не было регулярных тем о том, как кто-то легко взломал или случайно отправил 100500 данных пользователей «не туда». Думаю введение ответственности в виде запрета занимать должность, с наказанием всех по цепочке включая начальство — быстро бы начало исправлять ситуацию.
khim
Как крайняя мера в случае если проблемы не исправлены — да, конечно.
TrllServ
Там имелось ввиду наказание операторов(которые слили данные) и начальство этих операторов:
которым плевать на безопасность
которые могут вообще не иметь сотрудников по ИБ
которые не хотят тратить на тех.оснащение по безопасности
которые не хотят повышать квалификацию сотрудников ИБ
PS:
в этом случае всегда надо смотреть на умысел и сложность взлома/утечки. Если там всё дыряво изначально — не вижу смысла давать «второй шанс».
khim
Сейчас её вообще нет, так что выставлять её на 4 или 5 метров — глупо.
TrllServ
Не ставить планку вообще тоже не вариант.
khim
К сожалению это то, что реализовано сейчас. Поставьте её там, где вы предлагаете — и получите обратный эффект: 99% предприятий не смогут соответствовать этим требованиям и бо?льшая часть «откупится»… а если деньги уже уплочены, то зачем их тратить ещё и на то, чтобы реально что-то там налаживать?
navion
Есть 152-ФЗ по которому пилят деньги на макулатуре и говножелезках местного производства, только к реальной защите ПНд это отношения не имеет.