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
https://www.nccoe.nist.gov/get-involved/attend-events/nccoe-learning-series-trusted-cloud-and-hardware-enabled-security
NCCoE Learning Series: Trusted Cloud and Hardware Enabled Security
Вебинар July 28, 2022 по вышедшим в апреле документам NIST по аппаратной безопасности облаков.
NCCoE Learning Series: Trusted Cloud and Hardware Enabled Security
Вебинар July 28, 2022 по вышедшим в апреле документам NIST по аппаратной безопасности облаков.
https://cloudsecurityalliance.org/artifacts/sensitive-data-in-the-cloud/
Результаты опроса CSA 450 человек по размещению конфиденциальной информации в облаке.
Результаты опроса CSA 450 человек по размещению конфиденциальной информации в облаке.
cloudsecurityalliance.org
Sensitive Data in the Cloud | CSA
The goal of this survey was to understand the following: Cloud use and data security needs, Security priorities and challenges for the next year, Approach to hosting sensitive data and workloads in the cloud, Familiarity with cloud and data security technologies.