А какой именно пункт стандарта PCI DSS требует оповещения клиентов?
Оповещение клиентов осуществляется по правилам МПС, не являющихся частью стандарта, и по требованиям местного законодательства, которое также не является частью стандарта.
Мне кажется я не помню ни одной истории, когда имярек звонил в любой банк, просил соединить с СБ, и его соединяли.
Одну я помню. Лет семь или восемь назад я как раз работал в СБ банка, и однажды колл-центр на меня перевёл какого-то городского сумасшедшего, который утверждал, что владеет серьёзной инсайдерской информацией про одно предприятие, которое принадлежало тому же владельцу, что и банк. И если он этот инсайд раскроет, то предприятие потеряет какие-то серьёзные контракты. И чего-то требовал. Почему данного персонажа перевели на меня (простого технаря), почему он звонил на входящий номер банка, а не на то самое предприятие — тайна великая есть.
Я всё записал и доложил выше. История никакого развития не получила, кроме того, что я получил выговор от своего непосредственного, потому что не был уполномочен вести разговоры на такие темы.
А про уязвимости там или ещё что-то конструктивное — ни разу не было.
Есть ещё метод, который я использовал в своём дипломе — использование CVE, а если быть точнее, то CVSS.
…
Кажется, идеально: смотрим какие уязвимости эксплуатирует хакер, ищем их в базе и присваиваем хакеру оценку опасности. Так что же мне и тут не нравится?
А расскажите, пожалуйста, как вы видели этот метод, когда писали диплом?
Потому что сейчас я не нахожу метод идеальным. Вижу два варианта его применения:
1. Чистый post-mortem: нас поломали через 0-day, потом, когда уязвимость была исследована, мы смотрим, насколько крут был хакер. Это может быть вполне полезно в контексте оценки рисков, чтобы понять на будущее, нарушителям какого уровня наша организация может быть интересна, но не очень полезно для заявленной вами цели автоматизированной классификации нарушителя в реальном времени.
2. Мы держим зоопарк ханипотов с уязвимостями разного уровня сложности и даём нарушителям без регистрации и смс поиграть в ctf в обмен на сбор данных об их опасности. Дорого и малоприменимо в большей части ситуаций.
Тема параметризации атак (частным случаем которой является классификация нарушителя) вообще классная и перспективная, но, имхо, чтобы ей всерьёз заниматься, нужно сидеть на огромной куче биг даты. Т.е. если вы не работаете в mandiant или cisco talos, то максимально можно получить разве что диссертацию, которую после защиты положат на полку и забудут.
Наоборот — при взятии королём королевы они целовались, она пыталась пырнуть его ножом, а он замечал и бил её скипетром по голове. После чего она и падала в, хм, пикантную позу.
Королева убивала короля каким-то заклинанием, после которого от него оставались только корона, мантия и лужица на полу.
В битлокере есть функция suspend protection — при её активации мастер-ключ раздела записывается в метаданные раздела открытым текстом. При следующей перезагрузке системы этот ключ затирается, создаётся новый, которым перешифруются ключ шифрования данных и пароль восстановления.
Насколько мне известно, если какой-то апдейт не даст битлокеру загрузиться нормальным образом, система сама сделает suspend protection. Пользователь ничего не заметит и останется в неведении относительно того, что его данные до окончания апдейта являются незашифрованными.
Оповещение клиентов осуществляется по правилам МПС, не являющихся частью стандарта, и по требованиям местного законодательства, которое также не является частью стандарта.
Одну я помню. Лет семь или восемь назад я как раз работал в СБ банка, и однажды колл-центр на меня перевёл какого-то городского сумасшедшего, который утверждал, что владеет серьёзной инсайдерской информацией про одно предприятие, которое принадлежало тому же владельцу, что и банк. И если он этот инсайд раскроет, то предприятие потеряет какие-то серьёзные контракты. И чего-то требовал. Почему данного персонажа перевели на меня (простого технаря), почему он звонил на входящий номер банка, а не на то самое предприятие — тайна великая есть.
Я всё записал и доложил выше. История никакого развития не получила, кроме того, что я получил выговор от своего непосредственного, потому что не был уполномочен вести разговоры на такие темы.
А про уязвимости там или ещё что-то конструктивное — ни разу не было.
А расскажите, пожалуйста, как вы видели этот метод, когда писали диплом?
Потому что сейчас я не нахожу метод идеальным. Вижу два варианта его применения:
1. Чистый post-mortem: нас поломали через 0-day, потом, когда уязвимость была исследована, мы смотрим, насколько крут был хакер. Это может быть вполне полезно в контексте оценки рисков, чтобы понять на будущее, нарушителям какого уровня наша организация может быть интересна, но не очень полезно для заявленной вами цели автоматизированной классификации нарушителя в реальном времени.
2. Мы держим зоопарк ханипотов с уязвимостями разного уровня сложности и даём нарушителям без регистрации и смс поиграть в ctf в обмен на сбор данных об их опасности. Дорого и малоприменимо в большей части ситуаций.
Тема параметризации атак (частным случаем которой является классификация нарушителя) вообще классная и перспективная, но, имхо, чтобы ей всерьёз заниматься, нужно сидеть на огромной куче биг даты. Т.е. если вы не работаете в mandiant или cisco talos, то максимально можно получить разве что диссертацию, которую после защиты положат на полку и забудут.
Королева убивала короля каким-то заклинанием, после которого от него оставались только корона, мантия и лужица на полу.
Насколько мне известно, если какой-то апдейт не даст битлокеру загрузиться нормальным образом, система сама сделает suspend protection. Пользователь ничего не заметит и останется в неведении относительно того, что его данные до окончания апдейта являются незашифрованными.