ISACARuSec – Telegram
ISACARuSec
2.26K subscribers
1.78K photos
13 videos
308 files
5.67K links
Канал направления ИБ Московского отделения ISACA

Направление канала новости ISACA, новости в области управления ИБ в России и мире, обмен лучшими практиками.



Связь с администрацией
@popepiusXIII
Download Telegram
если нужно доступно объяснить что такое шифровальщик для англоязычного коллеги 🙂

еще раз дублируем, что похожего мы встречали

Хорошое соло, женский вокал
https://mobile.twitter.com/racheltobac/status/1352409636792492035

В стиле рэп
https://m.soundcloud.com/user-315163474/cyber-anthem

Если кто-то похожие песни или произведения видел - поделитесь в комментах. Видел ли кто-то подобное на русском?
Вакансии для старта карьеры в Минцифре.

https://job.gosuslugi.ru/
​​⚡️ Аттестация по-новому

Официально опубликован Порядок организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну, утверждённый приказом ФСТЭК России от 29 апреля 2021 г.
№ 77
.
Указанный Порядок будет применяться для аттестации объектов информатизации с 1 сентября 2021 г.

Из интересного:

1. Рассматриваемый Порядок применяется при аттестации:
- ГИС и МИС (приказ ФСТЭК № 17);
- информационных систем управления производством, используемых организациями ОПК (приказ ФСТЭК №31дсп), в том числе автоматизированных систем станков с ЧПУ;
- Защищаемых помещений.
2. В случае если было принято соответсвующее решение, то рассматриваемый Порядок применяется для аттестации:
- ЗОКИИ (приказ ФСТЭК № 239);
- ИСПДн (приказ ФСТЭК № 21);
- АСУ ТП на КВО, потенциально опасных объектах, объектах, представляющих повышенную опасность для жизни и здоровья людей и окружающей природной среды (приказ ФСТЭК № 31).
3. Порядок оперирует следующими сущностями: владелец ОИ, орган по аттестации, аттестационная комиссия, ФСТЭК России.
4. Определен минимальный состав аттестационной комиссии органа по аттестации: руководитель комиссии и менее двух компетентных экспертов.
5. Появилось прямое требование о дистанцировании, изоляции членов комиссии от влияния владельца аттестуемого ОИ.
6. Установлен срок направления владельцу ОИ заключения по результатам аттестационных испытаний и протоколов аттестационных испытаний - 5 рабочих дней с момента утверждения.
7. Описан порядок обжалования выявленных недостатков в ходе аттестации.
8. Установлена обязанность направления органом по аттестации в ФСТЭК России следующих документов: аттестата соответствия, ТП, акта классификации/акта категорирования, ПМИ, заключений и протоколов.
9. Постулируется, что аттестат соответствия будет выдаваться на весь срок эксплуатации ОИ, но периодический контроль аттестованных ОИ должен проводиться не реже 1 раза в два года. Документы по результатам контроля направляются владельцем ОИ в ФСТЭК России.
10. Описан порядок приостановления и возобновления действия аттестата соответствия ФСТЭК России.
11. Установлена обязанность представления органами по аттестации информации об аттестованных ОИ.

ФСТЭК России придумала, как заполучить акт категорирования объекта КИИ, который предоставлять регулятору ранее не требовалось. Интересно, эта информация будет использоваться для выявления правонарушений по ч. 1 ст. 19.7 прим 15 КОАП (Непредставление или нарушение сроков представления в ФСТЭК России, сведений о результатах присвоения объекту критической информационной инфраструктуры Российской Федерации одной из категорий значимости, предусмотренных законодательством в области обеспечения безопасности критической информационной инфраструктуры Российской Федерации, либо об отсутствии необходимости присвоения ему одной из таких категорий).

P.S.: а куда делся пункт 32 Порядка?
Forwarded from k8s (in)security (D1g1)
Не знаю как вы, а я люблю (и вижу это полезным) периодически возвращаться к статьям, которые уже читал - со временем и с новым опытом порой на одну и ту же информацию начинаешь смотреть и понимать по-другому.

Перечитывал "Service Discovery in Kubernetes - Combining the Best of Two Worlds" и знать это полезно не только для понимания как все устроено и повышения надежности работы системы, но и для повышения уровня безопасности (и там, где Kubernetes не используется вовсе).

Знаю, что в некоторых компаниях над service discovery много что надстраивают в плане безопасности. На пример, момент инвентаризации сервисов, может ли вообще service использоваться в данном окружении, с кем он и как может общаться и т.д. Сам Service Registry обогащается дополнительной информацией, контекстом и становиться немного умнее (но при этом не стоит забывать и об угрозах и атаках связанным с этим).

В разрезе Kubernetes, я бы это сформулировал как управление созданием ресурсов Service через policy engines, контроль применения NetworkPolicy.

P.S. Внутри этой статьи есть классные отсылки на замечательный сайт "Microservice Architecture", где отдельно отмечу раздел Patterns. Правильная безопасность, начинается с правильной архитектуры - иначе все может превратиться в латание дыр и набор костылей ...
ISACA website will be taken offline for about a week in September.

It is important to note that online/electronic exam preparation materials (e.g., online courses and ebooks) will not be accessible during the outage, which is planned for 8-14 September.