1/ Ransomware tip: Never upload ransomware samples to VirusTotal.
Why not? Because in most cases, the ransomware creates a readme along the encrypted file, which includes information about how to enter the chat for negotiations with the attackers.
2/ The chat could leak the negotiations with the attackers (including sensitive information) or even the paid amount of ransom.
Sometimes, the chats are still online weeks after the attack. Again, just don't upload samples to VT, even weeks or months after a ransomware attack.
#Stephan_Berger
Why not? Because in most cases, the ransomware creates a readme along the encrypted file, which includes information about how to enter the chat for negotiations with the attackers.
2/ The chat could leak the negotiations with the attackers (including sensitive information) or even the paid amount of ransom.
Sometimes, the chats are still online weeks after the attack. Again, just don't upload samples to VT, even weeks or months after a ransomware attack.
#Stephan_Berger
Forwarded from WTF_HR
Пятничное - эпизод из цикла "бывает только в кино".
Есть такая популярная криптоигра - Axie Infinity. Популярна она так потому, что создана по принципу play-to-earn, то есть за определенные действия в игре можно заработать - и некоторые даже зарабатывают себе там на жизнь. Как иак вышло, нам, грустным занудам, неведомо, но нас никто из многих тысяч игроков, оставляющих и зарабатывающих там миллионы криптодолларов, не спросил.
Дело, впрочем не в этом. А в том что игру эту недавно взломали, и увели оттуда аж полмиллиарда долларов в криптоэквиваленте. Причём выводили деньги в полном соответствии с условиями платформы, по которым за вывод суммы через блокчейн должны проголосовать пятеро валидаторов - пользователей с правами подтверждения транзакций.
В ходе расследования очень быстро стало ясно, что доступ к кошельком этих самых валидаторов кто-то получил через внутренние системы компании, и осталось понять, как этот кто-то туда проник.
И, прошерстив переписку работников компании, расследователи выяснили, что вирус-троян, открывший злоумышленникам двери в системы компвнии, проник в них через... предложение о работе.
В общем, на одного из старших инженеров через LinkedIn вышли некие рекрутеры и предложили ему работу вот прямо по его специальности за очень приличные деньги.
Далее последовали интервью с "нанимающими менеджерами", фидбеки от рекрутеров, следующие интервью и весь приличествующий случаю бардак в стиле "у нас тут внезапно ещё начальник продуктового департамента хочет с вами поговорить, а то он на этой позиции основной смежник". В общем, социальная инженерия 80lvl, и бедный сеньор ничего не заподозрил.
Не заподозрил он ничего и тогда, когда ему прислали ПДФку с красивым во всех отношениях оффером. А зря, потому что в этой самой ПДФке и сидел троян, который позволил хакерам получить доступ к четырём из пяти валидаторов. К пятому доступ был получен через сообщество участников игровой экосистемы, и это тоже забавная история, но уже совсем не про HR.
А про HR ещё вот что. Расследователи пошли к LinkedIn, который, конечно же повёл себя в стиле "мы лишь информационный сервис, а за ваши сломанные в аварии ноги должен платить таксопарк". Но попутно выяснилось, что количество разных там хакерских групп и прочих злобных персонажей, которые орудуют на LinkedIn и притворяются рекрутерами, исчисляется в мире чуть ли не сотнями. И работают эти группы, конечно, на правительства разных там недемократических и нксвободных стран, а на правительства демократических и свободных - нет, потому что это низко.
И вот ей-богу, нам кажется, что как минимум некоторые из известных публичных рекрутеров тоже только притворяются, а на самом деле бог его знает, чем заняты. Остерегайтесь, в общем, товарищи инженеры, кто знает, чего вам в офферах могут теперь прислать.
Ну и да, этот отличный повод не общаться с рекрутерами с рабочего компа не тянет на полноценный сценарий фильма. Но на параллельный сюжетец в каком нибудь очередном "146 друзей Оушенв - вполне".
Хороших выходных!
Есть такая популярная криптоигра - Axie Infinity. Популярна она так потому, что создана по принципу play-to-earn, то есть за определенные действия в игре можно заработать - и некоторые даже зарабатывают себе там на жизнь. Как иак вышло, нам, грустным занудам, неведомо, но нас никто из многих тысяч игроков, оставляющих и зарабатывающих там миллионы криптодолларов, не спросил.
Дело, впрочем не в этом. А в том что игру эту недавно взломали, и увели оттуда аж полмиллиарда долларов в криптоэквиваленте. Причём выводили деньги в полном соответствии с условиями платформы, по которым за вывод суммы через блокчейн должны проголосовать пятеро валидаторов - пользователей с правами подтверждения транзакций.
В ходе расследования очень быстро стало ясно, что доступ к кошельком этих самых валидаторов кто-то получил через внутренние системы компании, и осталось понять, как этот кто-то туда проник.
И, прошерстив переписку работников компании, расследователи выяснили, что вирус-троян, открывший злоумышленникам двери в системы компвнии, проник в них через... предложение о работе.
В общем, на одного из старших инженеров через LinkedIn вышли некие рекрутеры и предложили ему работу вот прямо по его специальности за очень приличные деньги.
Далее последовали интервью с "нанимающими менеджерами", фидбеки от рекрутеров, следующие интервью и весь приличествующий случаю бардак в стиле "у нас тут внезапно ещё начальник продуктового департамента хочет с вами поговорить, а то он на этой позиции основной смежник". В общем, социальная инженерия 80lvl, и бедный сеньор ничего не заподозрил.
Не заподозрил он ничего и тогда, когда ему прислали ПДФку с красивым во всех отношениях оффером. А зря, потому что в этой самой ПДФке и сидел троян, который позволил хакерам получить доступ к четырём из пяти валидаторов. К пятому доступ был получен через сообщество участников игровой экосистемы, и это тоже забавная история, но уже совсем не про HR.
А про HR ещё вот что. Расследователи пошли к LinkedIn, который, конечно же повёл себя в стиле "мы лишь информационный сервис, а за ваши сломанные в аварии ноги должен платить таксопарк". Но попутно выяснилось, что количество разных там хакерских групп и прочих злобных персонажей, которые орудуют на LinkedIn и притворяются рекрутерами, исчисляется в мире чуть ли не сотнями. И работают эти группы, конечно, на правительства разных там недемократических и нксвободных стран, а на правительства демократических и свободных - нет, потому что это низко.
И вот ей-богу, нам кажется, что как минимум некоторые из известных публичных рекрутеров тоже только притворяются, а на самом деле бог его знает, чем заняты. Остерегайтесь, в общем, товарищи инженеры, кто знает, чего вам в офферах могут теперь прислать.
Ну и да, этот отличный повод не общаться с рекрутерами с рабочего компа не тянет на полноценный сценарий фильма. Но на параллельный сюжетец в каком нибудь очередном "146 друзей Оушенв - вполне".
Хороших выходных!
The Block
How a fake job offer took down the world’s most popular crypto game
An engineer’s interest in joining what turned out to be a fictitious company led to March’s $540 million Axie Infinity hack.
Forwarded from Пост Лукацкого
Сегодня выпущена MITRE ATT&CK 11.3, в которую официально включены техники для мобильных платформ
👍1
Forwarded from Пост Лукацкого
Проект национального стандарта ГОСТ Р "Защита информация. Идентификация и аутентификация. Уровни доверия аутентификации" от ТК362
fstec.ru
Проект национального стандарта ГОСТ Р - ФСТЭК России
Официальный сайт Федеральной службы по техническому и экспортному контролю (ФСТЭК России)
Forwarded from Пост Лукацкого
Проект национального стандарта ГОСТ Р "Защита информации. Разработка безопасного программного обеспечения. Руководство по проведению статического анализа программного обеспечения" от ТК362
👍1
Forwarded from k8s (in)security (Дмитрий Евдокимов)
Свежая серия постов на тему матрицы угроз для
1) MITRE ATT&CK Matrix for Kubernetes - вводная статья
2) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 1 - рассматриваются стадии
3) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 2 - рассматриваются стадии
4) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 3 - рассматриваются стадии
На самом деле авторы ошиблись, добавив в название MITRE ATT&CK, ведь само описание делают на базе матрицы от
P.S. Аккуратно - на картинке есть опечатки!
Kubernetes! Серия состоит из 4 частей:1) MITRE ATT&CK Matrix for Kubernetes - вводная статья
2) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 1 - рассматриваются стадии
initial access, execution, persistence и privilege escalation.3) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 2 - рассматриваются стадии
defense evasion, credential access и discovery.4) MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 3 - рассматриваются стадии
lateral movement, collection и impact.На самом деле авторы ошиблись, добавив в название MITRE ATT&CK, ведь само описание делают на базе матрицы от
Microsoft (которая по мне более правильная и полная).P.S. Аккуратно - на картинке есть опечатки!
Forwarded from Листок бюрократической защиты информации
Интересное мнение, которое, пожалуй, стоит учитывать и при разработке внутренних регламентирующих документов по ИБ.
Forwarded from Ivan Begtin (Ivan Begtin)
Те кто когда-либо читали законы, постановления, указы и приказы на регулярной основе, наверняка, замечали что удивительно что все они написаны текстами, а не наборами инструкций.
В мире есть какое-то число инициатив по систематизации нормативных документов, таких как gitLaws или Akomo Ntoso, но в целом прогресс невелик. Отчасти от того, что есть значительное число юристов которые в результате потеряют работу, отчасти от объективной сложности применения чётких правил к нечёткой области деятельности, а отчасти поскольку законы создаются в рамках государственной модели, а многие конституции написаны так что парламенты имеют право принимать любые законы (!).
Иначе говоря есть две противоположные позиции. Одна в том что все НПА поддаются декомпозиции в чёткие правила, а другая в том что нельзя лезть с автоматизацией туда где нужно помнить о гибкости.
Лично я считаю что истина где-то посередине и истина в том что если делать платформу по разработке НПА, она должна более напоминать nocode/low-code платформы чем git или программный код в чистом виде.
Дело в том что явной автоматизации поддаются до 95-99% всех нормативных документов. Какие-нибудь распоряжения о назначении или увольнении и многие типовые указы, распоряжения и тд. Законы, также, вполне чётко могут быть разделены на новеллы и изменения накладываемые автоматически.
При этом, при подготовке любого НПА технологически должно быть возможно:
а) Иметь возможность готовить НПА в режиме конструктора норм.
б) Включить режим ручного написания текста, а не конструктор норм.
в) Иметь сервис способный автоматически проверять корректность/четкость/понятность норм и восстанавливать структурированные нормы из вручную написанного текста.
При это важно помнить что написание правил и законов - это основная функция госаппарата. Лично мне неизвестны чиновники ни в одной стране кто с энтузиазмом воспринимал бы идеи по контролю за их работой. Поэтому никто и не финансирует такие проекты по настоящему, не применяет языковые модели вроде GPT-3 к анализу новых НПА и корпусов законов.
Тем не менее я придерживаюсь мнения что рано или поздно автоматизация в этой области произойдёт. Эволюция правовых систем в новом поколении будет применять обратную реконструкцию норм из текстов в утилитарных целях - лоббирование, судебные разбирательства и тому подобное.
#legaltech #government #laws
В мире есть какое-то число инициатив по систематизации нормативных документов, таких как gitLaws или Akomo Ntoso, но в целом прогресс невелик. Отчасти от того, что есть значительное число юристов которые в результате потеряют работу, отчасти от объективной сложности применения чётких правил к нечёткой области деятельности, а отчасти поскольку законы создаются в рамках государственной модели, а многие конституции написаны так что парламенты имеют право принимать любые законы (!).
Иначе говоря есть две противоположные позиции. Одна в том что все НПА поддаются декомпозиции в чёткие правила, а другая в том что нельзя лезть с автоматизацией туда где нужно помнить о гибкости.
Лично я считаю что истина где-то посередине и истина в том что если делать платформу по разработке НПА, она должна более напоминать nocode/low-code платформы чем git или программный код в чистом виде.
Дело в том что явной автоматизации поддаются до 95-99% всех нормативных документов. Какие-нибудь распоряжения о назначении или увольнении и многие типовые указы, распоряжения и тд. Законы, также, вполне чётко могут быть разделены на новеллы и изменения накладываемые автоматически.
При этом, при подготовке любого НПА технологически должно быть возможно:
а) Иметь возможность готовить НПА в режиме конструктора норм.
б) Включить режим ручного написания текста, а не конструктор норм.
в) Иметь сервис способный автоматически проверять корректность/четкость/понятность норм и восстанавливать структурированные нормы из вручную написанного текста.
При это важно помнить что написание правил и законов - это основная функция госаппарата. Лично мне неизвестны чиновники ни в одной стране кто с энтузиазмом воспринимал бы идеи по контролю за их работой. Поэтому никто и не финансирует такие проекты по настоящему, не применяет языковые модели вроде GPT-3 к анализу новых НПА и корпусов законов.
Тем не менее я придерживаюсь мнения что рано или поздно автоматизация в этой области произойдёт. Эволюция правовых систем в новом поколении будет применять обратную реконструкцию норм из текстов в утилитарных целях - лоббирование, судебные разбирательства и тому подобное.
#legaltech #government #laws
https://www.nccoe.nist.gov/news-insights/hybrid-satellite-networks-hsn-cybersecurity-draft-annotated-outline
Hybrid Satellite Networks (HSN) Cybersecurity Draft Annotated Outline
Hybrid Satellite Networks (HSN) Cybersecurity Draft Annotated Outline
Forwarded from SecAtor
Ученые из ETH Zurich опубликовали исследование Retbleed с подробностями новой атаки по побочным каналам, которая затрагивает современные процессоры Intel и AMD, влияющей на спекулятивное выполнение.
После обнаружения Meltdown и Spectre в 2018 году, изменивших взгляды всех крупных производителей микросхем на конструкцию ЦП и безопасность данных, была разработана защитная технология Reptoline, в основе которой реализована замена инструкций перехода и вызова в ЦП инструкциями возврата, которые считались более безопасными.
ETH Zurich удалось провести атаку по побочному каналу на AMD Zen 1, Zen 1+, Zen 2 и Intel Core поколения 6–8 с помощью инструкций возврата, вызвав утечку памяти ядра, содержащую хэши паролей из систем Linux.
При этом теоретически все семейства процессоров AMD 0x15–0x17 и Intel Core поколения 6–8 также уязвимы. Таким образом, можно полагать, что все процессоры Intel возрастом от 3 до 6 лет и процессоры AMD возрастом от 1 до 11 лет могут быть затронуты уязвимостью.
Хорошей новостью является то, что исправления для Retbleed уже выпущены в рамках ежемесячных обновлений как ОС, так и облачной инфраструктуры от всех основных поставщиков.
Повторные исправления для процессоров AMD отслеживаются как CVE-2022-29900, для Intel - CVE-2022-29901, а дополнительная информация по смягчению последствий также доступна в блоге производителя.
Исследователи ETH отметили, что установка исправлений повлияет на показатели производительности ЦП в диапазоне от 14% до 39%. При этом другая обнаруженная в процессорах AMD проблема под название Phantom JMP (CVE-2022-23825), может на 209% повлиять на производительность.
По мнению исследователей, перед пользователями встанет выбор: либо защищать свою систему от подобных «экзотических» атак, но жертвуя производительностью, либо игнорировать исправление, полагаясь на то, что подобные атаки не фиксировались в дикой природе и реальная угроза их совершения близка к нулю.
В любом случае, у производителя выбора нет - задача доработки современной архитектуры и решений по безопасности ЦП безальтернативна и как никогда актуальна.
После обнаружения Meltdown и Spectre в 2018 году, изменивших взгляды всех крупных производителей микросхем на конструкцию ЦП и безопасность данных, была разработана защитная технология Reptoline, в основе которой реализована замена инструкций перехода и вызова в ЦП инструкциями возврата, которые считались более безопасными.
ETH Zurich удалось провести атаку по побочному каналу на AMD Zen 1, Zen 1+, Zen 2 и Intel Core поколения 6–8 с помощью инструкций возврата, вызвав утечку памяти ядра, содержащую хэши паролей из систем Linux.
При этом теоретически все семейства процессоров AMD 0x15–0x17 и Intel Core поколения 6–8 также уязвимы. Таким образом, можно полагать, что все процессоры Intel возрастом от 3 до 6 лет и процессоры AMD возрастом от 1 до 11 лет могут быть затронуты уязвимостью.
Хорошей новостью является то, что исправления для Retbleed уже выпущены в рамках ежемесячных обновлений как ОС, так и облачной инфраструктуры от всех основных поставщиков.
Повторные исправления для процессоров AMD отслеживаются как CVE-2022-29900, для Intel - CVE-2022-29901, а дополнительная информация по смягчению последствий также доступна в блоге производителя.
Исследователи ETH отметили, что установка исправлений повлияет на показатели производительности ЦП в диапазоне от 14% до 39%. При этом другая обнаруженная в процессорах AMD проблема под название Phantom JMP (CVE-2022-23825), может на 209% повлиять на производительность.
По мнению исследователей, перед пользователями встанет выбор: либо защищать свою систему от подобных «экзотических» атак, но жертвуя производительностью, либо игнорировать исправление, полагаясь на то, что подобные атаки не фиксировались в дикой природе и реальная угроза их совершения близка к нулю.
В любом случае, у производителя выбора нет - задача доработки современной архитектуры и решений по безопасности ЦП безальтернативна и как никогда актуальна.
ETH Zurich
Speculative calculations open a backdoor to information theft
ETH Zurich researchers have discovered a serious security vulnerability in computer hardware. The vulnerability, called
👎1
Forwarded from Листок бюрократической защиты информации
⚡️Изменения в 152-ФЗ | Реформа
Официально опубликован Федеральный закон от 14.07.2022 № 266-ФЗ «О внесении изменений в Федеральный закон "О персональных данных", отдельные законодательные акты Российской Федерации и признании утратившей силу части четырнадцатой статьи 30 Федерального закона "О банках и банковской деятельности».
Какие нововведения нам приготовлены:
1. Экстерриториальность 152-ФЗ.
2. Обязательность согласования с РКН нормативных правовых актов, которые принимают государственные органы, Банк России, органы местного самоуправления и регулирующих отношения, связанные с осуществлением трансграничной передачи ПДн, обработкой специальных категорий ПДн, биометрических ПДн, ПДн несовершеннолетних, предоставлением, распространением ПДн, полученных в результате обезличивания.
3. Дополнительные особенности поручения обработки ПДн.
4. Вводится запрет операторам ПДн отказывать в обслуживании в случае несогласия субъекта ПДн предоставить свои ПДн (в т.ч. биометрические).
5. Обширные корректировки, касающиеся трансграничной передачи ПДн:
• уведомление РКН;
• взаимодействие с органами власти иностранного государства, иностранными физическими лицами, иностранными юридическими лицами, которым планируется трансграничная передача персональных данных;
• возможность запрета РКН трансграничной передачи ПДн.
6. Некоторые особенности по срокам и форме предоставлению субъекту ПДн информации, касающейся обработки его ПДн.
7. Прямой запрет операторам ПДн в своих локальных актах по выполнению 152-ФЗ отражать положения:
• ограничивающие права субъектов ПДн;
• направленные на осуществление оператором ПДн не предусмотренных законодательством Российской Федерации полномочий и обязанностей.
8. РКН должен будет установить требования по оценке вреда, который может быть причинен субъектам ПДн в случае нарушения 152-ФЗ.
9. Обязанность операторов ПДн взаимодействовать с ГосСОПКА в порядке, определённом ФСБ России.
10. Обязанность операторов ПДн информировать ФСБ России о компьютерных инцидентах, повлекших неправомерную передачу (предоставление, распространение, доступ) персональных данных.
11. Взаимная обязанность ФСБ России и РКН передавать друг другу информацию о компьютерных инцидентах, повлекших неправомерную передачу (предоставление, распространение, доступ) ПДн (ведомства определят соответствующий порядок взаимодействия).
12. РКН будет вести реестр учета инцидентов в области ПДн, а также определит порядок взаимодействия с операторами ПДн в рамках его ведения.
13. Установлена обязанность оператора ПДн по уведомлению РКН о факте(ах) неправомерной или случайной передачи (предоставления, распространения, доступа) ПДн, повлекшего(их) нарушение прав субъектов персональных данных, с момента выявления такого инцидента (24 часа - о самом инциденте, 72 часа - о результатах внутреннего расследования по такому инциденту).
14. Сокращены сроки отработки обращений субъектов ПДн.
15. Добавлены некоторые условия прекращения обработки ПДн при обращении субъекта ПДн.
16. РКН должен установить требования по подтверждению уничтожения ПДн.
17. Обрабатывать ПДн без уведомления РКН становится почти невозможно.
18. Изменяются требования к наполнению уведомления о намерении осуществлять обработку ПДн.
19. Появилось требование по отдельному указанию в уведомлении о намерении осуществлять обработку ПДн информации, для каждой цели обработки ПДн:
• категории ПДН;
• категории субъектов, ПДн которых обрабатываются;
• правовое основание обработки ПДн;
• перечень действий с ПДн;
• способы обработки ПДн.
20. Добавились сроки информирования РКН о корректировке данных, ранее полученных с уведомлением о намерении осуществлять обработку ПДн, и об исключении из реестра операторов ПДн.
21. Некоторые корректировки статуса РКН, направленные на:
• придание ему большей самостоятельности;
• обеспечение возможности вносить в Правительство Российской Федерации предложения не только о совершенствовании нормативного правового регулирования защиты прав субъектов ПДн, но и деятельности по обработке ПДн.
Официально опубликован Федеральный закон от 14.07.2022 № 266-ФЗ «О внесении изменений в Федеральный закон "О персональных данных", отдельные законодательные акты Российской Федерации и признании утратившей силу части четырнадцатой статьи 30 Федерального закона "О банках и банковской деятельности».
Какие нововведения нам приготовлены:
1. Экстерриториальность 152-ФЗ.
2. Обязательность согласования с РКН нормативных правовых актов, которые принимают государственные органы, Банк России, органы местного самоуправления и регулирующих отношения, связанные с осуществлением трансграничной передачи ПДн, обработкой специальных категорий ПДн, биометрических ПДн, ПДн несовершеннолетних, предоставлением, распространением ПДн, полученных в результате обезличивания.
3. Дополнительные особенности поручения обработки ПДн.
4. Вводится запрет операторам ПДн отказывать в обслуживании в случае несогласия субъекта ПДн предоставить свои ПДн (в т.ч. биометрические).
5. Обширные корректировки, касающиеся трансграничной передачи ПДн:
• уведомление РКН;
• взаимодействие с органами власти иностранного государства, иностранными физическими лицами, иностранными юридическими лицами, которым планируется трансграничная передача персональных данных;
• возможность запрета РКН трансграничной передачи ПДн.
6. Некоторые особенности по срокам и форме предоставлению субъекту ПДн информации, касающейся обработки его ПДн.
7. Прямой запрет операторам ПДн в своих локальных актах по выполнению 152-ФЗ отражать положения:
• ограничивающие права субъектов ПДн;
• направленные на осуществление оператором ПДн не предусмотренных законодательством Российской Федерации полномочий и обязанностей.
8. РКН должен будет установить требования по оценке вреда, который может быть причинен субъектам ПДн в случае нарушения 152-ФЗ.
9. Обязанность операторов ПДн взаимодействовать с ГосСОПКА в порядке, определённом ФСБ России.
10. Обязанность операторов ПДн информировать ФСБ России о компьютерных инцидентах, повлекших неправомерную передачу (предоставление, распространение, доступ) персональных данных.
11. Взаимная обязанность ФСБ России и РКН передавать друг другу информацию о компьютерных инцидентах, повлекших неправомерную передачу (предоставление, распространение, доступ) ПДн (ведомства определят соответствующий порядок взаимодействия).
12. РКН будет вести реестр учета инцидентов в области ПДн, а также определит порядок взаимодействия с операторами ПДн в рамках его ведения.
13. Установлена обязанность оператора ПДн по уведомлению РКН о факте(ах) неправомерной или случайной передачи (предоставления, распространения, доступа) ПДн, повлекшего(их) нарушение прав субъектов персональных данных, с момента выявления такого инцидента (24 часа - о самом инциденте, 72 часа - о результатах внутреннего расследования по такому инциденту).
14. Сокращены сроки отработки обращений субъектов ПДн.
15. Добавлены некоторые условия прекращения обработки ПДн при обращении субъекта ПДн.
16. РКН должен установить требования по подтверждению уничтожения ПДн.
17. Обрабатывать ПДн без уведомления РКН становится почти невозможно.
18. Изменяются требования к наполнению уведомления о намерении осуществлять обработку ПДн.
19. Появилось требование по отдельному указанию в уведомлении о намерении осуществлять обработку ПДн информации, для каждой цели обработки ПДн:
• категории ПДН;
• категории субъектов, ПДн которых обрабатываются;
• правовое основание обработки ПДн;
• перечень действий с ПДн;
• способы обработки ПДн.
20. Добавились сроки информирования РКН о корректировке данных, ранее полученных с уведомлением о намерении осуществлять обработку ПДн, и об исключении из реестра операторов ПДн.
21. Некоторые корректировки статуса РКН, направленные на:
• придание ему большей самостоятельности;
• обеспечение возможности вносить в Правительство Российской Федерации предложения не только о совершенствовании нормативного правового регулирования защиты прав субъектов ПДн, но и деятельности по обработке ПДн.
👍3