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

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



Связь с администрацией
@popepiusXIII
Download Telegram
Вакансии для старта карьеры в Минцифре.

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.
Forwarded from SecAtor
​​А мы знаем, как эти выходные пройдут у IT в крупном секторе экономики.

Немецкий гигант программного обеспечения для предприятий SAP выпустил внушительный патч исправлений, закрыв 9 критических и особо серьезных уязвимостей. Важные:

- CVE-2021-33698: проблема с неограниченной загрузкой файлов в SAP Business One. Злоумышленник может использовать уязвимость для загрузки файлов сценария, что предполагает возможность использования уязвимости для выполнения произвольного кода.

- CVE-2021-33690: подделка запросов на стороне сервера SSRF, влияющая на инфраструктуру разработки NetWeaver. Злоумышленник может использовать уязвимость для прокси-атак, отправляя специально созданные запросы, и если целевой экземпляр доступен в Интернете, может полностью скомпрометировать конфиденциальные данные, находящиеся на сервере, и повлиять на их доступность.

- CVE-2021-33701: SQL-инъекцию в сервисе SAP NZDT (Near Zero Downtime Technology), используемом S / 4HANA и мобильным плагином DMIS.

Другие (высокой степени серьезности):
- Ошибки межсайтового скриптинга (XSS): уязвимости XSS позволяют внедрять код JavaScript на сервлет-порталы и выполнять его в браузере жертвы.
- Бага в SSRF в NetWeaver Enterprise Portal: ошибка позволяет неаутентифицированному злоумышленнику делать запросы к внутренним или внешним серверам, заставляя целевого пользователя щелкнуть вредоносную ссылку.
- Проблема аутентификации, затрагивающую все системы SAP, доступ к которым осуществляется через Web Dispatcher.
- Ошибка перехвата задачи в мобильном приложении Fiori Client для Android.
- Ошибка аутентификации в SAP Business One.

По оценкам экспертов, текущие исправления SAP (считая исправления HotNews и High Priority) являются самыми масштабными в этом году.

Особое внимание к ним со стороны хакподполья потребует и особых усилий от IT. Ведь выстраивание вектора под уязвимости, как мы помним, занимает всего несколько дней после выпуска исправлений.