bga68comp | Entries tagged with dlp

ORM (Object-Relational Mapping / Об’єктно-реляційне відображення) — це програмна технологія, яка дозволяє працювати з базою даних не напряму через SQL-запити, а через об’єкти мови програмування.

Простими словами:

Без ORM: ви пишете SELECT * FROM users WHERE id=1;
З ORM: ви пишете User.find(1) і отримуєте об’єкт User, з яким можна працювати у коді.

Де застосовується

ORM є проміжним шаром (layer) між додатком і БД.
Він транслює методи й властивості об’єктів у SQL-запити і назад.
Це робить код простішим, зручнішим у підтримці та менш залежним від конкретної СУБД.

Приклади ORM

Java: Hibernate, EclipseLink
.NET: Entity Framework
Python: SQLAlchemy, Django ORM
Ruby: ActiveRecord
PHP: Doctrine, Eloquent (Laravel)

🪟 На стартову сторінку

У ISO/IEC/IEEE 42010 (Systems and Software Engineering — Architecture Description) є два близькі, але різні поняття:

Viewpoint (точка зору)

Визначення: це "шаблон" або правило, яке пояснює як і для кого треба створювати архітектурне подання.
Він відповідає на питання: які інтереси стейкхолдера ми показуємо, яку інформацію включаємо, якими засобами (діаграми, таблиці, текст) описуємо.
Простими словами: viewpoint — це інструкція або рецепт для створення подання.

View (подання)

Визначення: це конкретний результат застосування viewpoint до вашої системи.
Тобто це вже готова діаграма, таблиця чи текст, що показує систему під певним кутом зору.
Простими словами: view — це фото системи, зроблене за тим рецептом.

Приклад

Уявімо, що будуємо архітектуру для хмарної платформи:

Stakeholder (зацікавлена сторона)
- CIO (Chief Information Officer, директор з ІТ)
- Його concern (потреба): чи масштабована система і як забезпечено інтеграцію між додатками?
Viewpoint (точка зору на інтеграцію додатків)
- Назва: Application Communication Viewpoint
- Призначення: показати, як взаємодіють модулі та сервіси
- Мова: UML Component Diagram або ArchiMate Application Collaboration
- Яку інформацію включати: сервіси, API, протоколи, залежності
View (конкретне подання)
- Діаграма з Azure AD, веб-додатком на Ubuntu, RDS MySQL, інтеграцією з O365.
- Тут видно, що користувачі логіняться через Entra ID, доступ йде через API-шлюз, БД інтегрується через ORM-шар.
- Це вже готова картинка, яку CIO може подивитися.

🔹 Отже:

Viewpoint = каже: "покажи архітектуру додатків через компоненти і протоколи"
View = конкретна діаграма з вашим Entra ID, API Gateway і MySQL

🪟 На стартову сторінку

В чому незручність, коли використовують тільки одну методологію для опису архітектурних рівнів?

TOGAF дає методологію (ADM-фази, артефакти, каталоги, матриці), але іноді в ньому бракує гнучкості у формальному представленні результатів.
ISO/IEC/IEEE 42010 дає рамку опису архітектури: хто стейкхолдери, які їхні потреби (concerns), через які viewpoints ці потреби відображати, і у вигляді яких views це презентувати.
Якщо користуватися лише TOGAF — є ризик, що опис буде “каталог + текст”, але не зовсім зрозумілий різним групам зацікавлених сторін.
Якщо користуватися лише ISO 42010 — буде гарна структура “хто/що/для чого”, але без готових методичних кроків і артефактів (каталогів, матриць).

Комбінація TOGAF і ISO/IEC/IEEE 42010 методично сильніша, ніж використання кожного окремо: TOGAF забезпечує процес і набір артефактів, а ISO 42010 — формалізований спосіб представлення архітектури через стейкхолдерів, concerns і viewpoints. Разом вони дозволяють зробити опис не лише повним, а й зрозумілим для різних аудиторій.

Критерій	TOGAF	ISO/IEC/IEEE 42010	Разом (TOGAF + ISO 42010)
Призначення	Методологія розробки архітектури (ADM, фази, артефакти)	Рамка для опису архітектури (stakeholders, concerns, viewpoints, views)	Повний цикл: розробка + формалізований опис
Сильна сторона	Дає покроковий процес (ADM) і набір артефактів (каталоги, матриці)	Дає чітку структуру для комунікації з різними стейкхолдерами	Виходить і методика роботи, і методика подачі результатів
Слабка сторона	Може вийти занадто “всередину ІТ”, важко донести до нефахівців	Немає власної методики створення артефактів, лише правила їх опису	Компенсують слабкі сторони один одного
Фокус	Що і як робити (Data, Application, Technology, Business Architectures)	Як показати і пояснити (concerns, viewpoints, views)	І процес, і представлення зрозумілі й прозорі
Приклад результату	Каталоги даних, матриці застосунків, моделі потоків	Logical Data View, Security View, паспорти viewpoints	Каталоги + матриці (TOGAF), оформлені у views для різних стейкхолдерів (ISO 42010)

Таким чином, можна сказати так — разом вони дають повну картину:

TOGAF = як і що робити (ADM, каталоги, матриці).

ISO 42010 = як правильно це описати й донести (stakeholders, concerns, viewpoints, views).

Див. також:
⋄ Приклад опису архітектури системи згідно TOGAF → https://bga68comp.dreamwidth.org/787432.html

🪟 На стартову сторінку

Продовжуємо розбирати шаблони рівнів архітектури ІТ-систем. Це доповнення до опису архітектури за посиланнями:
• Приклад опису архітектури системи згідно TOGAF
• Побудова віртуальної інфраструктури на базі Microsoft Azure

✅ Опис інформаційної архітектури компанії
🖼️ Згідно з наданою схемою (RDS, Files, IIS Web Front/Back, AD DC1/DC2, VPN)

🧾 Інформаційна архітектура ІТ-системи компанії

🔹 1. Методологія

TOGAF 9.2, ADM, фаза C (Data Architecture): побудова інформаційного рівня архітектури.
ISO/IEC/IEEE 42010:2011: опис архітектури через зацікавлені сторони, погляди (views), моделі та відповідності.

🔹 2. Архітектурний контекст

Усі серверні ресурси компанії розміщені в тенанті Azure.
Користувачі підключаються до корпоративної мережі через захищені канали (VPN або Azure Bastion).
Робоче середовище реалізоване через RDS-сервер (DevSRV).
Веб-додатки розділені на фронт- (IIS Web Front) та бекенд (IIS Web Back).
Ідентифікація та авторизація забезпечуються двома доменними контролерами (AD DC1, DC2).

🔹 3. Архітектурні погляди (Views)

3.1 📡 Deployment View

DevSRV – RDS сервер для користувачів.
Files – файловий сервер зі спільними каталогами.
IIS Web Srv Front / Back – розподілення логіки веб-додатку.
AD DC1 / DC2 – розподілена автентифікація, DNS, GPO.
Всі ресурси ізольовані через NSG, Firewall, розміщені у VNet з Subnet-сегментацією.
Користувачі підключаються через захищений шлюз (VPN/Bastion).

3.2 🧩 Data Architecture View

Сутність даних	Опис
User Profile	Профілі користувачів, зберігаються в AD та RDS
File Object	Файли користувача на файловому сервері
DNS-записи	Зони та записи, керуються AD DC1/DC2
Web Session	Дані сесій на IIS Front
GPO Configuration	Групові політики, що застосовуються через AD
RDP Logs	Логи входів і дій у RDS

3.3 🔐 Access & Security View

RBAC на основі груп у AD.
GPO-політики: заборона USB, блокування локального диска, перенаправлення папок.
Шифрування: RDP over TLS, SMB over TLS.
Аудит: централізоване логування входів, дій на RDS.
Двофакторна автентифікація (MFA) через Azure AD / Conditional Access.
Firewall + NSG: розмежування Frontend, Backend, Infra.

3.4 🔄 Information Flow View

Звідки → Куди	Протокол	Захист
Користувач → RDS	RDP over TLS	VPN / MFA / GPO
RDS → Files	SMB 3.0	ACL + GPO + TLS
RDS → AD	LDAP/Kerberos	Шифрування, автентифікація
RDS → IIS Front/Back	HTTP/HTTPS	ACL, WAF, сегментація
RDS → DNS	DNS	ACL-захист зони

🔹 4. Зацікавлені сторони (Stakeholders)

Сторона	Інтерес
Користувачі	Стабільний і безпечний доступ до робочого середовища
Системні адміністратори	Централізоване управління політиками та файлами
Відділ ІБ	Впровадження GPO, аудит, захист інформації
Бізнес	Доступність сервісів, віддалена робота

🔹 5. Цільова модель та вдосконалення

Компонент	Поточна реалізація	Рекомендоване покращення
RDS	DevSRV на VM	Перехід до RDS Farm + Load Balancer
Files	Windows FS	Azure Files + Private Endpoint
MFA	Часткове	Універсальне MFA через Azure AD
AD	DC1 + DC2	Гібрид із Azure AD DS
IIS Front/Back	На VM	Azure App Service або контейнеризація

🔹 6. Узгодженість із ISO/IEC/IEEE 42010

Компонент	Відповідність
Stakeholders	Визначено
Architectural Views	Згруповано (Deployment, Security, Data)
Вимоги	Ураховані: доступність, безпека, контроль
Traceability	Показано зв’язок між цілями й рішеннями

✅ На останок:

Інформаційна архітектура побудована згідно з TOGAF ADM (фаза C) та структурована за стандартом ISO 42010.
Враховано як функціональні, так і нефункціональні вимоги: доступність, безпека, масштабованість.
Усі основні компоненти (RDS, Files, AD, IIS) інтегровані через захищені канали й управляються централізовано.

Annex:
🟠 Фази ADM (Architecture Development Method)

Preliminary Phase
Phase A: Architecture Vision
Phase B: Business Architecture
Phase C: Information Systems Architectures
Phase D: Technology Architecture
Phase E: Opportunities and Solutions
Phase F: Migration Planning
Phase G: Implementation Governance
Phase H: Architecture Change Management
Requirements Management

🪟 На стартову сторінку

Requirements and Testing Procedures. Guidelines

Вимоги та процедури тестування		Настанови
Визначені процедури тестування підходу	Визначені вимоги підходу	Мета Переміщення PAN на несанкціоновані носії є поширеним способом отримання цих даних і їх шахрайського використання. Методи, що гарантують, що лише особи з явним авторизованим правом і законною діловою необхідністю можуть копіювати або переміщувати PAN, знижують ризик доступу до PAN сторонніх осіб. Найкраща практика Копіювання та переміщення PAN повинно виконуватися лише на дозволені носії, які дозволені та санкціоновані для використання цією особою. Визначення Віртуальний робочий стіл є прикладом технології віддаленого доступу. Такі технології часто містять інструменти для блокування можливості копіювання та/або переміщення даних. Пристрої для збереження даних включають, але не обмежуються: - локальні жорсткі диски, - віртуальні диски, - знімні електронні носії, - мережеві накопичувачі та хмарне сховище. Додаткова інформація Документація постачальника для технологій віддаленого доступу може містити інформацію про налаштування системи, необхідні для виконання цієї вимоги.
3.4.2 При використанні технологій віддаленого доступу технічні засоби контролю повинні запобігати копіюванню та/або переміщенню PAN для всього персоналу, за винятком тих, хто має документоване, явне авторизоване право і законну, визначену ділову необхідність.	3.4.2.a Перевірити документовані політики та процедури та отримати докази наявності технічних засобів контролю, що запобігають копіюванню та/або переміщенню PAN за допомогою технологій віддаленого доступу на локальні жорсткі диски або знімні електронні носії, щоб підтвердити наступне: Технічні засоби контролю запобігають копіюванню та/або переміщенню PAN усім особам, які не мають спеціально наданого дозволу. Ведеться список персоналу, якому дозволено копіювати та/або переміщувати PAN, разом із документованим, явним дозволом і законною, визначеною діловою необхідністю.
Ціль налаштованого підходу
PAN не може бути скопійований або переміщений неавторизованими особами за допомогою технологій віддаленого доступу.
Примітки щодо застосування	3.4.2.b Перевірити конфігурацію налаштувань для технологій віддаленого доступу, щоб підтвердити наявність технічних засобів контролю, які блокують можливість копіювання та/або переміщення PAN для всього персоналу, крім тих, хто має дозвіл. 3.4.2.c Спостерігати за діями персоналу та перевірити, чи вони відповідають документованим політикам і вимогам, щоб підтвердити, що лише особи з дозволом мають можливість копіювати та/або переміщувати PAN за допомогою технологій віддаленого доступу.
Збереження або переміщення PAN на локальні жорсткі диски, знімні електронні носії та інші пристрої виводить ці пристрої в сферу дії PCI DSS. Ця вимога є найкращою практикою до 31 березня 2025 року, після чого вона стане обов’язковою і повинна бути повністю врахована під час оцінки PCI DSS.

🪟 На стартову сторінку

функціональні вимоги до системи DLP (Data Loss Prevention):

Контроль і моніторинг всіх каналів передачі даних:
- Система повинна підтримувати різні канали передачі даних, такі як електронна пошта, веб-браузери, месенджери, знімні носії, принтери, хмарні сервіси та мобільні пристрої.
- Необхідно забезпечити контроль даних як у спокої (в системах зберігання), так і в русі (під час передачі через мережу або перенесення на зовнішні пристрої).
Аналіз вмісту і контексту:
- Система повинна вміти аналізувати вміст файлів, повідомлень і даних на предмет конфіденційної інформації, такої як особисті дані (PII), фінансові дані та інтелектуальна власність.
- Контекстний аналіз має враховувати інформацію про те, хто, коли і як взаємодіє з даними, включаючи місце розташування та пристрій.
Класифікація і маркування даних:
- Дані повинні класифікуватися як автоматично, так і вручну на основі їх вмісту, контексту та політик.
- Необхідна інтеграція з системами класифікації та маркування даних, такими як Microsoft Information Protection.
Створення і управління політиками безпеки:
- Можливість створювати гнучкі політики безпеки для різних категорій даних і користувачів.
- Підтримка шаблонів політик і управління ними через централізовану консоль, включаючи автоматичне застосування змін у реальному часі.
Ідентифікація і блокування витоків даних:
- Система повинна виявляти спроби витоку даних і мати можливість автоматичної блокування або обмеження доступу.
- Реакція на інциденти може включати сповіщення адміністратора, попередження користувача, ведення журналу подій, тимчасове або постійне блокування операції.
Журналювання і звітність:
- Ведення журналів усіх подій, пов'язаних із доступом, передачею та зміною даних.
- Створення звітів по інцидентах, дотриманню політик та активності користувачів.
- Можливість налаштування звітів під конкретні вимоги організації або нормативів.
Інтеграція з іншими системами безпеки:
- Підтримка інтеграції з SIEM-системами, антивірусами, рішеннями по управлінню правами доступу (IAM), системами виявлення загроз та іншими інструментами безпеки.
- Можливість взаємодії з існуючими системами управління інцидентами та реагування на них.
Аналіз поведінки користувачів (UBA):
- Аналіз поведінки користувачів і виявлення аномалій, які можуть свідчити про потенційні загрози (наприклад, незвичайні обсяги переданих даних або нетипові дії користувача).
- Інтеграція з системами машинного навчання для прогнозування і запобігання загрозам на основі історичних даних.
Управління доступом і авторизація:
- Підтримка багатофакторної автентифікації і ролей на основі прав доступу для управління тим, хто і як може взаємодіяти з системою DLP та захищеними даними.
- Гнучкість налаштування рівнів доступу залежно від ролі користувача і контексту.
Підтримка роботи з зашифрованими даними:
- Можливість аналізу і контролю даних, зашифрованих з використанням різних алгоритмів і протоколів.
- Інтеграція з системами управління ключами для дешифрування і аналізу даних.
Оновлення і адаптація до нових загроз:
- Регулярні оновлення системи для захисту від нових типів загроз і уразливостей.
- Можливість додавання і оновлення політик, шаблонів і правил у відповідь на зміни в нормативних вимогах і бізнес-середовищі.
Управління інцидентами і реагування:
- Наявність інструментів для управління інцидентами, включаючи створення інцидентних карт, автоматичне сповіщення і можливість швидкого реагування.
- Інтеграція з системами реагування на інциденти для координації і автоматизації дій по усуненню загроз.

Ці функціональні вимоги допомагають забезпечити всебічний захист даних в організації, мінімізуючи ризики витоків і забезпечуючи відповідність нормативним вимогам.

💻 На головну сторінку

Документи, які потрібно розглянути та прийняти організації перед впровадженням системи DLP з юридичної точки зору, відповідно до стандарту ISO 27001 і законів України:

1. Документи, пов'язані з законодавством України

1.1. Положення про захист персональних даних

Зміст: Документ, що описує, як організація збирає, обробляє, зберігає та захищає персональні дані, включаючи права суб'єктів даних та обов'язки організації.
Законодавство: Закон України "Про захист персональних даних".

1.2. Політика інформаційної безпеки

Зміст: Документ, що визначає загальні підходи та заходи для захисту інформації в організації, включаючи вимоги до системи DLP.
Законодавство: Закон України "Про основи забезпечення кібербезпеки України".

1.3. Регламент обробки персональних даних

Зміст: Документ, що деталізує процеси обробки персональних даних відповідно до національного законодавства.
Законодавство: Закон України "Про захист персональних даних".

1.4. Політика конфіденційності

Зміст: Документ, що інформує суб'єктів даних про те, як їх персональні дані збираються, використовуються та захищаються, а також про права суб'єктів даних.
Законодавство: Закон України "Про захист персональних даних".

1.5. Угода про конфіденційність (NDA)

Зміст: Документ, що встановлює зобов'язання співробітників та контрагентів щодо нерозголошення конфіденційної інформації та персональних даних.
Законодавство: Закон України "Про захист персональних даних", Закон України "Про комерційну таємницю".

1.6. Порядок реагування на інциденти безпеки

Зміст: Документ, що регламентує дії співробітників і керівництва при виявленні інцидентів інформаційної безпеки, включаючи витоки даних.
Законодавство: Закон України "Про основи забезпечення кібербезпеки України".

2. Документи, пов'язані з ISO 27001

2.1. Політика інформаційної безпеки (Information Security Policy)

Зміст: Основоположний документ, що описує зобов'язання керівництва щодо забезпечення інформаційної безпеки, цілі безпеки, обсяги застосування та основні принципи захисту інформації.
Стандарти: Пункт 5.2 "Політика інформаційної безпеки".

2.2. Оцінка ризиків (Risk Assessment)

Зміст: Документ, що описує процес ідентифікації, аналізу та оцінки ризиків для інформаційної безпеки, включаючи ризики, пов'язані з витоками даних.
Стандарти: Пункти 6.1.2 "Оцінка ризиків в області інформаційної безпеки" та 6.1.3 "Обробка ризиків в області інформаційної безпеки".

2.3. Методика управління ризиками (Risk Treatment Plan)

Зміст: Документ, що визначає заходи щодо зниження, передачі, уникнення або прийняття ризиків, пов'язаних з інформаційною безпекою, і описує, як система DLP може допомогти в управлінні цими ризиками.
Стандарти: Пункт 6.1.3 "Обробка ризиків в області інформаційної безпеки".

2.4. Декларація застосовності (Statement of Applicability, SoA)

Зміст: Документ, що підтверджує, які з рекомендованих контролів інформаційної безпеки ISO 27001 організація впровадила і чому.
Стандарти: Пункт 6.1.3 "Обробка ризиків в області інформаційної безпеки".

2.5. План неперервності бізнесу (Business Continuity Plan)

Зміст: Документ, що описує процедури для забезпечення неперервності бізнес-процесів у випадку інцидентів, включаючи витоки даних.
Стандарти: Пункт 17 "Аспекти інформаційної безпеки в управлінні неперервністю бізнесу".

2.6. Політика управління доступом (Access Control Policy)

Зміст: Документ, що описує правила та процедури для управління доступом до інформаційних активів, включаючи налаштування та управління доступом у системі DLP.
Стандарти: Пункт 9.4 "Управління доступом".

2.7. Журнали та контрольні журнали (Logging and Monitoring)

Зміст: Документ, що описує процедури ведення та аналізу журналів, а також моніторингу подій інформаційної безпеки, включаючи використання системи DLP для відстеження витоків даних.
Стандарти: Пункт 12.4 "Логування та моніторинг".

3. Документи, пов'язані з внутрішніми процесами та регламентами

3.1. Інструкції по роботі з системою DLP

Зміст: Оперативні інструкції для адміністраторів та користувачів, що описують правила роботи з системою DLP, включаючи процеси моніторингу, звітності та реагування на інциденти.

3.2. Технічні політики та процедури

Зміст: Документи, що описують технічні заходи безпеки, такі як конфігурації серверів, мереж, робочих станцій та впровадження системи DLP.

3.3. Положення про захист комерційної таємниці

Зміст: Документ, що регулює правила звернення з конфіденційною інформацією та комерційною таємницею, включаючи використання системи DLP для захисту цих даних.

4. Додаткові документи

4.1. Угоди з підрядниками та партнерами

Зміст: Угоди, що містять положення про захист даних, зобов'язання щодо використання системи DLP та відповідальність за витік даних.

4.2. Документовані докази відповідності

Зміст: Журнали аудитів, результати оцінки ризиків та інші документи, що підтверджують, що організація дотримується вимог законодавства та стандарту ISO 27001.

Цей перелік документів допоможе організації не тільки дотримуватись законодавства України, але й впровадити ефективну систему інформаційної безпеки відповідно до міжнародних стандартів.

💻 На головну сторінку

Open Source Security Controls

Перейти на начальную страницу https://bga68.livejournal.com

NIST Cyber Security Framework

NIST

Перейти на начальную страницу https://bga68.livejournal.com

http://blogs.klerk.ru/company/41304/post169781/

Их называют по-разному: письма счастья, спам, нигерийские письма. Такую рассылку получал, пожалуй, каждый пользователь. Цель у нее одна – поймать наивного адресата на «крючок» фишинга и выманить информацию, деньги, заразить вирусом или навредить как-то иначе. И если технологии обмануть все сложнее, то слабые места человеческой натуры неизменны. Приемы социальных инженеров отшлифованы опытом тысяч жертв – компаний и частных лиц. Как не дать ввести себя в заблуждение? Есть только один способ – знать, как именно киберпреступник действует. Итак, вам пришло письмо.

Не думайте, что когда мы говорим о фишинге, речь идет только о детях и бабушках, которые доверяют всему и вся в Сети. Речь о каждом из нас. Высокий статус, хорошая должность и высшее образование не гарантия того, что вы не клюнете на уловки фишеров. На одном IT-ресурсе даже появилась статья со списком организаций и должностей, где сотрудники особенно легко попадаются на фишинговые письма. Среди них и ведущие специалисты, и руководители отделов.
( Read more... )

Выводим короткий чек-лист «Что делать с письмами от подозрительных/неизвестных отправителей?»:

Подвергайте все сомнению. Адрес отправителя можно подделать. Не договаривались о письме с адресатом? Это повод посмотреть на него с долей скептицизма и параноидальностью специалиста по безопасности.

Проверяйте текст, если письмо на иностранном языке. Фишинг – явление интернациональное, но далеко не всем мошенникам доступны услуги профессиональных переводчиков. Если такой текст перевести, то он будет выглядеть как надпись на этикетке китайских носков: «Уважаемый мистер, хороший день, хотим вам поздравил».

Обращайте внимание на отправителя. Знакомая компания? Реально ли она существует? Соответствует ли подпись реальности: телефоны, физический адрес, форма собственности и т.д.

Не стесняйтесь перепроверить. Позвоните в компанию, от которой получили письмо, по публичным телефонам с официального сайта (а не указанным в письме!) и уточните, действительно ли вам писали. Не стесняйтесь быть мнительными, особенно если в письме есть сомнительные ссылки и вложения.

Не переходите по подозрительной ссылке. Скорее всего, это атака. Наведите курсор на ссылку, чтобы увидеть реальный адрес, куда она ведет. Бывает, что местами переставлены всего две буквы в адресе и это не сразу заметно для человеческого глаза. Например, вместо searchinform может быть написано saerchinform.

Не открывайте сомнительные вложения. Для проверки вложений есть бесплатные сервисы, например, virustotal.com. Он прогонит вложенный файл сразу через несколько десятков антивирусов.

Не пренебрегайте антивирусной защитой. Многие популярные антивирусы проверяют не только ваш ПК, но и почту – не отключайте эту опцию и внимательно относитесь к предупреждениям антивируса.

( Read more... )

Дыра как инструмент безопасности или как ловить APT «на живца» | LinkedIn

Alex Lozikoff
Business Development Manager at Softprom by ERC
https://www.linkedin.com/pulse/дыра-как-инструмент-безопасности-или-ловить-apt-на-живца-lozikoff/

(за идею заголовка спасибо Sergey G. Brester @sebres)

Коллеги, целью данной статьи желание поделиться опытом годичной эксплуатации нового класса IDS-решений на основе Deception-технологий.

Чтобы сохранить логическую связность этого опуса, считаю нужным начать с предпосылок. Итак, проблематика, которая сподвигла нас смотреть в эту сторону:

Направленные атаки – наиболее опасный вид атак, несмотря на то, что в общем количестве угроз их удельный вес невелик. Почему? Потому что каждая направленная атака - это бизнес-проект, который осуществляется хорошо подготовленными и мотивированными специалистами, которые очень хорошо знают, как монетизировать захваченные ресурсы. Именно поэтому ущерб от одной такой успешной атаки может на порядки превышать совокупную стоимость всех остальных кибер-угроз.

Какого-то на 100% гарантированно эффективного средства защиты периметра (или комплекса таких средств) пока еще не придумано.

Как правило, направленные атаки проходят в несколько стадий. Преодоление периметра - это только одна из начальных стадий, которая (можете закидать меня камнями) большого ущерба для «жертвы» не несет, если это, конечно не DEoS (Destruction of service) атаки (шифровальщики и т.п.). По-настоящему больно начинается позже, когда захваченные активы начинают использовать для пивотинга и развития атаки «в глубину», а мы этого не заметили.

( Read more... )

Алексей Лукацкий

17 Января, 2018

Об утечках через DNS, которые не ловит ни одна DLP

Наверное то есть, кто давно занимается информационной безопасностью помнят, что в 1996-м году была очень популярная вредоносная программа Loki, которая позволяла организовывать туннели внутри ICMP-протокола, обычно не контролируемого распространенными на тот момент межсетевыми экранами. Идея Loki была проста - путем обмена командами ECHO REQUEST и ECHO REPLY (то есть обычный Ping) в поле данных пакета ICMP можно было засунуть все, что угодно. Детектировать такие атаки на МСЭ почти невозможно и помогали их обнаруживать только IDS, для которых писались правила, отслеживающие длину запросов и ответов ICMP (она должна быть равна 42 байтам), а также смотрящие за тем, чтобы поле данных ICMP-пакета было пустым (с нулевой длиной). С разной эффективностью схожий метод использовался некоторыми другими вредоносными программами, которые появлялись уже позже, в 2000-х годах, и в 2010-х.
( Read more... )

https://ria.ru/infografika/20170926/1505083370.html

https://searchinform.ru/research/2017/

Исследование уровня информационной безопасности в российских компаниях

Эксперты «СёрчИнформ» оценили уровень ИБ в российских компаниях. Данные были получены в ходе серии конференций Road Show SearchInform 2017 «DLP будущего», в которой приняли участие 1806 ИБ-специалистов и экспертов. Ещё 885 участников следили за онлайн-трансляцией мероприятия из 12 стран мира. Часть данных была собрана в ходе онлайн-опроса сотрудников отделов информационной безопасности.

( Read more... )

Сколько нужно администраторов для обслуживания систем предотвращения утечек информации (DLP)

Количество обязанностей, которые постепенно возлагают на одного администратора, имеет свойства снежной лавины, если руководитель ИТ-отдела не понимает сути глубинных процессов по настройке и администрированию как аппаратной части, так и программной некоей системы автоматизации.

Особенно это хорошо видно, когда прямой руководитель "с компьютерами на ты"

Для таких ситуаций я когда-то нарисовал такую схемку:

Авось доберусь и нарисую красиво :-)

Кстати, есть официальный best practice Cisco ASA Administrators: Cisco ASA 1000V Cloud Firewall. Administrators

Анализ рынка систем защиты от утечек конфиденциальных данных (DLP) в России 2013-2016

Илья Шабанов
Генеральный директор Anti-Malware.ru
https://www.anti-malware.ru/russian_dlp_market_2013_2016

Информационно-аналитический центр Anti-Malware.ru представляет очередной анализ рынка средств защиты от утечек конфиденциальных данных в России. В отчете приводятся данные объемов продаж и долей рынка основных игроков в 2013-2015 годах, а также делается прогноз развития рынка на текущий 2016 год.

1. Введение
2. Методология
3. Объемы продаж в 2013-2015 годах
4. Доли рынка в 2013-2015 годах
5. Объем продаж в 2014-2015 годах по сегментам рынка
6. Прогноз развития рынка на 2016 год
7. Комментарии партнеров Anti-Malware.ru

Отчет представляет собой ежегодное независимое исследование состояния рынка систем защиты от утечек конфиденциальной информации (DLP — Data Leak Prevention, или ILD&P — Information Leak Detection & Prevention) в России по итогам 2013-2015 годов.

Это шестое по счету подобное исследование, проведенное информационно-аналитическим центром Anti-Malware.ru (предыдущее было опубликовано в декабре 2014 года — Расширенный анализ рынка систем защиты от утечек конфиденциальных данных (DLP) в России 2012-2014).

Рынок DLP рассматривается Anti-Malware.ru в широком понимании этого термина, куда помимо классического DLP входят и другие продукты — так называемые DLP-Lite (неполнофункциональные DLP), а также продукты, изначально ориентированные не на предотвращение утечки, а на последующий анализ событий.

В исследовании освещается текущая ситуация на рынке DLP в России, рассматривается положение основных игроков-производителей, их объемы продаж и занимаемые доли рынка, а также делается прогноз развития на 2016 год.

Рисунок 1. Объемы продаж основных игроков DLP-рынка в России за 2013-2015 годы (млн руб.)

( Read more... )

Как рассчитать окупаемость инвестиций для DLP-системы. Часть 2

Часть 1-я

Такая документация в каждой компании своя. Её состав и содержание «на совести» компании. В предельном случае можно внедрить систему неофициально, без внесения соответствующих пунктов в трудовой договор и прочего. Вот только использование такой системы будет незаконно.
( Read more... )

Как рассчитать окупаемость инвестиций для DLP-системы

Часто возникает необходимость в создании технико-экономического обоснования внедрения различных систем. Интересную методику предлагает Александр Астахов для расчета ROI DLP. Привожу без изменений.

Автор: Александр Астахов — опубликовано: 09-06-2016 — последнее изменение: 14-06-2016

Источник: http://iso27000.ru/blogi/aleksandr-astahov/kak-rasschitat-okupaemost-investicii-dlya-dlp-sistemy

Покажем, как при помощи методов анализ информационных рисков и статистических сведений об утечках информации, которыми мы располагаем, оценить окупаемость DLP-систем. (Презентация на совместном вебинаре с компанией SearchInform 08.06.2016).

Смотрите что происходит. Несмотря на кризис, доходы разработчиков DLP-систем в основном растут. Во многих компаниях уже либо используются DLP-системы, либо их предварительно тестируют, либо собираются тестировать в ближайшее время. И это несмотря на дороговизну с одной стороны и отсутствием каких-либо представлений об экономическом эффекте от их использования с другой. Если бы речь шла только о гос. организациях, то это еще можно понять, так там надо осваивать бюджеты, а значит чем дороже системе, тем лучше. Но коммерческие структуры тоже подвержены этой моде. Про эффективность, важность информации и губительных последствиях утечек нам уже все рассказали маркетинговые службы разработчиков этих систем. Но пора уже поговорить об экономике вопроса.
( Read more... )Часть 2.

SearchInfrom: основные возможности КИБ и SIEM

17 Ноября 2015, 08:24

Александр Панасенко

Главный-редактор Anti-Malware.ru

http://www.anti-malware.ru/reviews/SearchInfrom_dlp_SIEM

SearchInform Event Manager

DLP или DLD. Что выбрать?

Сначала что - каждое из них?

wiki:

DLP (англ. Data Leak Prevention, DLP) - Предотвращение утечек - технологии предотвращения утечек конфиденциальной информации из информационной системы вовне, а также технические устройства (программные или программно-аппаратные) для такого предотвращения утечек.

( Read more... )