Профілактика зараження вірусами КС.

Головною умовою безпечної роботи в комп'ютерних системах є дотримання правил, які апробовані на практиці і показали свою високу ефективність.

Правило перше. Обов'язкове використання програмних продуктів, отриманих законним шляхом. Оскільки в піратських копіях вірогідність наявності вірусів у багато разів вище, ніж в офіційно отриманому програмному забезпеченні.

Правило друге. Дублювання інформації, тобто створювати копії робочих файлів на знімних носіях інформації(дискети, компакт-диски і інші) із захистом від запису.

Правило третє. Регулярно використати антивірусні засоби, тобто перед початком роботи виконувати програми-сканери і програми-ревізори(Aidstest і Adinf). Ці антивірусні засоби необхідно регулярно оновлювати.

Правило четверте. Проявляти особливу обережність при використанні нових знімних носіїв інформації і нових файлів. Нові дискети і компакт-диски необхідно перевіряти на відсутність завантажувальних і файлових вірусів, а отримані

нових знімних носіїв інформації і нових файлів. Нові дискети і компакт-диски необхідно перевіряти на відсутність завантажувальних і файлових вірусів, а отримані файли - на наявність файлових вірусів. Перевірка здійснюється програмами-сканерами і програмами, що здійснюють евристичний аналіз(Aidstest, Doctor Web, AntiVirus). При першому виконанні виконуваного файлу використовуються резидентні вартуючи. При роботі з отриманими документами і таблицями треба заборонити виконання макрокоманд вбудованими засобами текстових і табличних редакторів(MS Word, MS Excel) до завершення повної перевірки цих файлів на наявність вірусів.

Правило п'яте. При роботі в системах колективного користування необхідно нові змінні носії інформації і файли, що вводяться в систему, перевіряти на спеціально виділених для цієї мети ЕОМ. Це повинні виконувати адміністратор системи або особа, що відповідає за безпеку інформації. Тільки після усебічної антивірусної перевірки дисків і файлів вони можуть передаватися користувачам системи.

Правило шосте. Якщо не передбачається здійснювати запис інформації на носій, то необхідно заблокувати виконання цієї операції. Постійне виконання викладених правил дозволяє значно зменшити вірогідність зараження програмними вірусами і забезпечити захист користувача від безповоротних втрат інформації.

У особливо відповідальних системах для боротьби з вірусами використовуються апаратно-програмні засоби(наприклад, Sheriff).

 

 

Особливості захисту інформації в БД.

Бази даних розглядаються як надійне сховище структурованих даних, забезпечене спеціальним механізмом для їх ефективного використання в інтересах користувачів(процесів). Таким механізмом є система управління базами даних(СУБД). Під системою управління базами даних розуміється програмні або апаратно-програмні засоби, що реалізовують функції управління даними, такі як: перегляд, сортування, вибірка, модифікація, виконання операцій визначення статистичних характеристик і інші.

Бази даних розміщуються:

- на комп'ютерній системі користувача;

- на спеціально виділеній ЕОМ(сервері).

На комп'ютерній системі користувача, як правило, розміщуються особисті або персональні бази даних, які обслуговують процеси одного користувача. На серверах бази даних розміщуються в локальних і корпоративних комп'ютерних мережах, які використовуються, як правило, централізований. Загальнодоступні глобальні комп'ютерні мережі мають розподілені бази даних. У таких мережах сервери розміщуються на різних об'єктах мережі. Сервери - це спеціалізовані ЕОМ, пристосовані до зберігання великих об'ємів даних і збереження, що забезпечують, і доступність інформації, а також оперативність обробки запитів, що поступають. У централізованих базах даних вирішуються простіше за проблему захисту інформації від умисних загроз, підтримки актуальності і несуперечності даних. Гідністю розподілених баз даних є їх висока захищеність від стихійних лих, аварій, збоїв технічних засобів і диверсій, якщо здійснюється дублювання цих даних.

Особливості захисту інформації у базах даних:

- необхідність обліку функціонування СУБД при виборі механізмів захисту;

- розмежування доступу до інформації реалізується не на рівні файлів, а на рівні частин баз даних.

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

 

Моделювання загроз.

Термін "моделювання загроз" має безліч значень. Для відповіді на питання "що таке моделювання загроз"? я скористаюся дескриптивним підходом і опишу, як може використовуватися цей термін, замість того, щоб намагатися підібрати для нього одне строге визначення. Отже, розглянемо найбільш поширені значення: термін " загроза" використовується для позначення як зловмисників, тобто людей, що атакують систему, так і ризиків, тобто тих небажаних подій, які можуть статися. Моделювання загроз може відноситися як до методики встановлення вимог до системи("яка прийнята Вами модель загроз"?), так і до методики конструкторського аналізу("дозвольте поглянути на Ваш аналіз моделі загроз"?). Крім того, моделювання загроз може будуватися на розгляді ресурсів, зловмисників або програмного забезпечення. Моделювання загроз, орієнтоване на ресурси, часто включає різні рівні оцінки, апроксимації або ранжирування ризиків. Моделювання загроз з акцентом на зловмисниках іноді включає ранжирування ризиків або оцінку ресурсів, можливостей і мотивацій(виконання таких оцінок представляє украй складне завдання для розробників пакетів програм широкого застосування, оскільки різноманітність варіантів використання тягне і різноманітність загроз, пов'язаних з кожним конкретним застосуванням). Кожен підхід до моделювання загроз має свої сильні і слабкі сторони, на яких я при необхідності зупинятимуся, пояснюючи деякі інші аспекти або описуючи отриманий досвід. Крім того, про моделювання загроз можна говорити стосовно аналізу програмних продуктів, організаційних мереж, систем або навіть промислових секторів. Моделювання протоколів часто виконується з використанням різноманітних формальних методів, іноді званих моделями мережевих загроз. Термін "моделювання мережевих загроз" також використовується при аналізі розгорнутої мережі. Нарешті, моделювання загроз може виконуватися експертами по безпеці з подальшою передачею результатів інженерам, спільно експертами і інженерами або одними інженерами без участі експертів. Фахівці з безпеки можуть засумніватися в цінності останнього підходу. Проте, існує, принаймні, дві причини, по яких варто проводити моделювання загроз без експертів. По-перше, експерти можуть бути просто відсутніми в організації по фінансових або іншим причинам. По-друге, залучення до процесу моделювання людей, які розроблятимуть систему, але які не є фахівцями з безпеки, дозволяє їм відчути свою причетність до захисту системи і набути розуміння моделі безпеки. Моделювання загроз включає безліч різних процедур по виявленню вимог до безпеки системи і по аналізу різних схем захисту. Не існує одного " кращого" або " правильнішого" методу моделювання загроз, навпаки, необхідно поєднувати і комбінувати різні альтернативи для того, щоб досягти явно заданих або прихованих цілей.

Сучасна методологія SDL. Сучасна методологія моделювання загроз в SDL є процесом, що складається з чотирьох етапів, розроблений для того, щоб скоротити об'єм експертних оцінок безпеки, які потрібні інженерам для побудови моделі загроз і упевненості в тому, що усі серйозні загрози дійсно були визначені. Цілями цієї процедури є підвищення рівня безпеки розробок, документування подій, пов'язаних із захистом продуктів, і навчання працівників питанням захисту системи в процесі розробки. Метод включає чотири основні етапи: побудову діаграм, перерахування загроз, зниження ризиків і перевірку.

Моделювання загроз як tabula rasa. Багато фахівців, маючи своє уявлення про те, як повинне виглядати моделювання загроз(термін, що має, як я вже відмітив в розділі 1.1, безліч значень), утілили ці представлення у своїх методологіях і доповненнях до існуючих методів. Найчастіше такі доповнення створюються без урахування і усвідомлення того, які витрати знадобляться на їх впровадження, які приношувані ними вигоди і витрати. Приклад - впровадження методики оцінки ризиків DREAD. Для деяких систем ця методика працює, але при моделюванні загроз з акцентом на програмному забезпеченні методика DREAD починає вводити числові змінні, не задаючи їх області визначення, що призводить до небезпеки прийняти оцінку ризиків за алгоритмічну, тоді як вона такий не являється. Проте, SDL- моделювання загроз в Microsoft явно потребує методики управління рисками, і тому DREAD була впроваджена.

Кількісна оцінка моделей загроз. Сьогодні нами створюється величезна кількість моделей загроз. Існує декілька тривіальних параметрів, які ми МОЖЕМО виміряти кількісно(число елементів, різні заходи повноти і словесного наповнення). Набагато складнішими є питання про те, які параметри ми ПОВИННІ вимірювати і ЧОМУ. Які властивості моделі загроз найточніше показують, чи досягнуті поставлені нами цілі аналізу, забезпечення безпеки і навчання? Говорячи інакше, які параметри системи відповідають певній меті і як вони з цими цілями пов'язані? Які витрати знадобляться для виміру таких параметрів? (Невеликий приклад: в одну з наших груп по обговоренню проблем забезпечення безпеки поступив електронний лист з питанням про те, як розв'язати певну проблему. Декілька чоловік відповіло на нього; після короткого обговорення група вибрала один із запропонованих варіантів. Навряд чи якесь з цих рішень було коли-небудь формальне описано і зафіксовано. Зроблений вибір повністю виправдав себе: ми змогли з невеликими витратами підвищити рівень безпеки. Таким чином, документування рішень, що повторюються, не має особливого сенсу.) Чи існує можливість проаналізувати модель і визначити вірогідність, з якою вона повторюється? Які ще підходи до виміру параметрів можуть бути корисні для розробників і фахівців, що займаються ухваленням рішень?

 

 

Зниження ризиків.

Зниження ризиків. На семінарах і в роботах по SDL- моделюванню загроз обговорюються чотири підходи до зниження ризиків, а саме(в порядку зростання переваги): перепроектувало; використання стандартних методів зниження ризиків, таких як списки управління доступом(Access Control List, ACL); використання(з обережністю) унікальних методів; робота з рисками відповідно до політиків безпеки. З точки зору інженера-практика, співвідношення моделі з практичними етапами вирішення проблеми дуже важливе. По-перше, метою моделювання є підвищення безпеки системи, а зв'язування виявленої проблеми з методом її рішення спрощує це завдання. По-друге, тут існує і психологічний аспект. Інженер, проінформований про існування проблеми, але що не отримав її точного визначення або оцінки, у більшості випадків просто розгубиться (Знайдуться і такі інженери, які з ентузіазмом приймуть цей виклик. Проте досвід показує, що прості і очевидні методи у сфері інформаційної безпеки рідко спрацьовують, тому справа, швидше за все, все одно закінчиться розчаруванням.