Моніторинг безпеки ERP Oracle E-Business Suite

Незважаючи на постійний розвиток інформаційних технологій, практика забезпечення інформаційної безпеки в російських компаніях насичена прикладами інцидентів в цій області. Більше того, число інцидентів неухильно зростає і починає викликати певне занепокоєння у начальників служб автоматизації (CIO) і служб інформаційної безпеки (CISO), відповідальних за організацію інформаційної безпеки ERP-систем у вітчизняних компаніях. Давайте подивимося, які можливості існують для моніторингу безпеки ERP Oracle E-Business Suite.


Наведемо класичний варіант побудови ERP Oracle E-Business Suite за схемою "база даних – сервер додатків -" тонкий "клієнт". Три основних компоненти цієї системи з'єднані між собою за допомогою мережі передачі даних на основі TCP / IP (рис. 1). У цьому випадку браузер або будь-яка інша програма, що виконує роль "тонкого" клієнта, візуалізує так звані марковані дані (мови маркування: HTML або XML) для користувачів ERP Oracle E-Business Suite. Введені користувачем запити і команди передаються за допомогою протоколу HTTP через мережу передачі даних сервера додатків. Додатки ERP Oracle E-Business Suite виконуються як деякі обчислювальні процеси на сервері додатків і при необхідності здійснюють взаємодію із сервером баз даних (у загальному випадку – розподіленим). При цьому процес обміну даними між додатками і БД ERP Oracle E-Business Suite зачіпає компоненти доступу до реляційної бази даних мови високого рівня, протокол прикладного рівня SQL * Net і стек протоколів TCP / IP. Так як СУБД ERP Oracle E-Business Suite побудована по розподіленому принципом, введемо в схему (рис. 1) кластер паралельно функціонують серверів баз даних, пов'язаних між собою за протоколом SQL * Net.


Аналіз представленої схеми обробки даних ERP Oracle E-Business Suite (рис. 1) дозволяє виділити сліду ющіе компоненти, відповідальні за перетворення, зберігання та передачу даних:


• програму-браузер, що виконує візуалізацію маркованих даних (перетворення "графічне представлення – HTML / XML-документ");


• підсистему передачі та кешування маркованих даних;


• прикладну програму на сервері додатків;


• підсистему передачі даних в реляційному поданні;


• підсистему фізичного зберігання даних в рамках СУБД.


Отже, для моніторингу безпеки ERP Oracle E-Business Suite необхідно побудувати деякі контрольні точки або інваріанти обробки даних, а також створити адекватні методи контролю цих інварінтов для наступних процесів:


• візуалізації маркованих даних та інтерфейсу з користувачем;


• протоколу прикладного рівня HTTP;


• протоколу прикладного рівня SQL * Net;


• стека протоколів транспортного, мережевого і канального рівнів TCP / IP;


• прикладної програми (логіки додатка);


• підсистеми фізичного представлення реляційних даних в СУБД.


Давайте розглянемо перераховані процеси обробки даних ERP Oracle E-Business Suite докладніше.


     Візуалізація маркованих даних


Керуючий граф програми "тонкого" клієнта представлений на рис. 2. Тут вхідним параметром процесу є строкова величина StartURI – унікальний ідентифікатор ресурсу (URI – unique resource identifier), инициализирующая сеанс роботи з користувачем ERP Oracle E-Business Suite. Цей параметр може бути однозначно визначено на етапі розробки ERP-системи, якщо процес ідентифікації і аутентифікації користувача реалізований засобами самого додатка, або величину StartURI повинен надати зовнішній процес ідентифікації в системі.


У загальному випадку розгалуження, пов'язане з можливістю відображення копії документа, яка перебуває в кеші браузера, може залежати від наступних факторів:


• логіки роботи з кешовані документами;


• позначки часу кешованої копії;


• наявності в ідентифікаторі ресурсу змінної складової (запиту) і т. п.


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


• вихід з програми;


• редагування змінюваних величин;


• виклик команди до сервера додатків.


При спробі користувача виконати операцію редагування браузері мають перевірити доступність величини на зміну. При запиті команди для сервера додатків браузер повинен:


• визначити неизменяемую частину унікального ідентифікатора;


• визначити набір величин, пов'язаних з даним запитом (командою);


• сформувати список пар "назва величини – значення величини";


• сформувати конкатенацією повний ідентифікатор ресурсу URI.


Внутрішню структуру представлення даних у програмі-браузері можна представити у вигляді двох наборів даних:


• записів про команди, доступних користувачеві при роботі з даним документом (в мові HTML з командами пов'язані елементи управління "посилання" і "форма"):


• URL1, URL2, … , URLCC – постійними складовими ідентифікаторів ресурсів, пов'язаних з даною командою (тип даних – рядковий);


• CM1, CM2, … , CMCC – інформації про правила відображення керуючого елемента, пов'язаного з даною командою (тип даних – структура);


• записів про величини (в мові HTML з постійними величинами пов'язаний елемент управління "текст", зі змінними – елемент управління "input"):

• VN1, VN2, … , VNVС – імен величин (тип даних – рядковий);


• VV1, VV2, … , VVVС – значень величин (тип даних – рядковий, або в залежності від величини – рядковий, цілочисельний, речовий, логічний);


• VW1, VW2, … VWVС – логічних ознак можливості редагування значення величини в програмі-браузері (тип даних – логічний);


• VR1, VR2, … , VRVС – порядкових номерів команди, з якою пов'язана дана величина (в мовах маркованого подання даних HTML та XML дотримується строга ієрархічна структура елементів управління і візуалізації, внаслідок цього кожна конкретна величина може бути пов'язана тільки з однією командою (тип даних – цілочисельний, діапазон допустимих значень – [1 .. CC]));


• VM1, VM2, … , VMVC – інформації про правила відображення керуючого елемента, пов'язаного з даною величиною (тип даних – структура).


Зазначені два набори даних (State) разом з поточним унікальним ідентифікатором ресурсу (URI) і маркованим документом у двійковому поданні (Doc) повністю описують поточний стан програми-браузера. У цьому випадку інформаційний граф моделі обробки даних представлений на рис. 3.


Тут процес Cache виробляє вибірку з кеша документа за його унікальному ідентифікатору, процес Load виконує завантаження документа з допомогою протоколу HTTP, процес Parse виконує розбір маркованого документа і на його основі заповнює набір даних State. Процес Request виробляє збирання нового унікального ідентифікатора на основі наступних даних:


• значення URLj, пов'язаного з обраної користувачем командою (вважаємо, що її індекс – j);


• імен VNki і поточних значень VVki величин, пов'язаних з обраною користувачем командою (тобто тих, для яких виконується умова VRki = j).


Відзначимо, що для мови HTML правила побудови унікального ідентифікатора мають такий вигляд:


URI ” = URLj + “?” + VNk1 + “=” + VVk1 + “&” + VNk2 + “=” + VVk2 + “&” + … + VNkn + “=” + VVkn.


Протоколи прикладного рівня HTTP і SQL * Net


Протоколи прикладного рівня HTTP (Hyper Text Transfer Protocol) і SQL * Net досить схожі (знаходяться на одному рівні класичної моделі OSI). Спільними функціями цих протоколів є:


• узгодження параметрів транспортного кодування (у тому числі компресії) даних;


• узгодження параметрів кодування алфавіту національної мови;


• дозвіл імен прикладного рівня в ідентифікаторах ресурсів.


Відмінності проявляються в схемах кодування переданої на нижні рівні інформації, а також у характері повертається від сервера метаінформації.


Процес HTTP-клієнт ініціалізується шляхом завдання параметра URI – унікального ідентифікатора запитуваного ресурсу. При цьому процес виконує розбір код на три параметри:


• ім'я хоста;


• TCP-порт HTTP-сервера;


• відносний URI.


При необхідності ім'я хоста представляється відповідною IP-адресою. У цьому випадку використовуються:


• служба розв'язання доменних імен (DNS);


• служба розпізнавання імен Windows (WINS);


• локальний довідник.


Далі процес визначає список допустимих для нього параметрів HTTP-з'єднання, таких, як транспортний кодування (стиск) і кодування національного алфавіту. У HTTP-запиті вказується весь список для того, щоб HTTP-сервер мав можливість вибрати загальні для клієнта і сервера параметри з'єднання. У разі присутності документа з аналогічною унікальним ідентифікатором у локальному кеші в HTTP-заголовок додається поле "Час створення наявного в кеші документа". Сформований текст HTTP-запиту (із зазначенням типу – "GET", версії протоколу "HTTP/1.1", відносного URI, імені хоста і параметрів з'єднання) передається на нижележащий рівень стека мережевих протоколів.


Після отримання запиту HTTP-сервером процес перевіряє наявність на сервері ресурсу з запитаним ідентифікатором. При відсутності запитуваної ресурсу на клієнтську сторону передається повідомлення з кодом помилки "404" – "Документ не знайдено". У разі наявності ресурсу можливі три варіанти.


Якщо HTTP-запит містив полі "Час створення наявного в кеші документа", яка вказана в ньому час збігається з часом створення зберігається на серверній стороні ресурсу, то на клієнтську сторону передається повідомлення з кодом "304" – "Документ не змінювався". В іншому випадку на підставі свого списку можливих параметрів HTTP-з'єднання та списку, отриманого в HTTP-запиті, сервер вибирає активні параметри з'єднання. Якщо не вдається узгодити параметри з'єднання, то на клієнтську сторону відправляється повідомлення про помилку з кодом "406" – "Несогласуемие параметри". При успішному погодження параметрів формується HTTP-відповідь, що включає код "200" ("Ресурс передається"), вміст (при необхідності перетворене згідно активним параметрами), записи про активні параметрах з'єднання, а також інформацію про дату і часу створення документа для занесення в кеш на стороні клієнта.


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


Відзначимо, що протокол SQL * Net об'єднує кілька подпротоколов, що відповідають за різні функції в організації взаємодії "клієнт – сервер" і "сервер – сервер".


Подпротокол-інтерфейс UPI / OPI / NPI надає можливість у об'єднанні "клієнт – сервер" (UPI / OPI) і "сервер – сервер" (NPI / OPI) виконувати команди прикладного рівня:


• підключення до сервера;


• попередня перевірка сервером синтаксису SQL-запиту;


• виконання SQL-запиту;


• відкриття курсору реляційного представлення даних;


• передача реляційних даних від сервера до клієнта;


• типізація переданих даних на основі записів про типи даних на стороні сервера;


• закриття курсору;


• відключення від сервера.


При цьому відмінність схем підключення "клієнт – сервер" і "сервер – сервер" проявляється тільки на цьому рівні, тоді як на більш низьких рівнях подпротоколов відмінності відсутні. Сервер, що відповідає на SQL-запит, в обох випадках використовує інтерфейс OPI – аналог процесу HTTP-сервера. Викликають інтерфейси UPI (клієнтський) і NPI (серверний при з'єднанні "сервер – сервер") відрізняються незначно. З боку клієнта уніфіковані драйвери доступу до реляційних даних (такі, як, наприклад, ODBC – Open DataBase Connection) виробляють відображення своїх інтерфейсів до інтерфейсу UPI.


Подпротокол Two-Task Common (TTC) відповідає за вибір єдиного уявлення типів даних і схем кодування національного алфавіту. У разі необхідності як клієнтська, так і серверна сторона TTC може виробляти перетворення переданих даних в рамках відомих їй схем кодування. На відміну від схеми, використовуваної протоколом HTTP, Two-Task Common робить вибір загальних параметрів SQL * Net-з'єднання, одноразово в момент його відкриття і при виконанні всіх подальших команд користується вже узгодженими (актуальними) параметрами.


Подпротокол Transparent Network Substrate (TNS) реалізує не залежить від нижчого стека мережевих протоколів інтерфейс з чотирма командами:


• підключитися до віддаленого об'єкту;


• передати дані;


• отримати дані;


• відключитися від віддаленого об'єкта.


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


• Oracle Names;


• локальний довідник;


• програмні адаптери від Oracle для популярних протоколів дозволу імен (NetWare Directory Service, StreetTalk, NIS і т. п.).


У зв'язку з однотипністю функцій, виконуваних протоколами, опишемо для них єдину модель функціонування процесу, поширивши на весь протокол SQL * Net можливості кешування результатів (можливістю кешування результатів володіє тільки стик інтерфейсів NPI / OPI). До HTML-документа і даними в реляційному поданні далі будемо застосовувати термін "ресурс".


Нехай стан системи "клієнт – сервер" описується таким набором величин:


• RN – ім'я запитуваної у клієнтського інтерфейсу ресурсу (тип даних – рядковий);


• RS – необхідна кодування національного алфавіту запитуваного ресурсу (тип даних – цілочисельний);


• CS – список кодувань національного алфавіту, підтримуваних клієнтом (тип даних – список цілочисельних величин);


• CT – список транспортних кодувань, підтримуваних клієнтом (тип даних – список цілочисельних величин);


• CC – вміст ресурсу на клієнтській стороні (вихідний результат процесу) (тип даних – рядковий);


• CD – дата і час створення ресурсу (тип даних – позначка часу);


• CACHE_CNT – кількість ресурсів, розміщених в кеші (тип даних – цілочисельний);


• CACHE_NAMES – імена ресурсів, розміщених в кеші (тип даних – список строкових величин);


• CACHE_DATES – дата і час створення ресурсів, розміщених в кеші (тип даних – список відміток часу);


• CACHE_VALUES – вміст ресурсів, розміщених в кеші (тип даних – список строкових величин);


• CACHE_CHARSETS – кодування національної мови ресурсів, розміщених в кеші (тип даних – список цілочисельних величин);


• CI – номер знайденого в кеші ресурсу (тип даних – цілочисельний);


• CB – буфер клієнтської сторони (тип даних – рядковий);


• SB – буфер серверної сторони (тип даних – рядковий);


• TN – ім'я запитуваного ресурсу на серверній стороні (тип даних – рядковий);


• TS – список кодувань національного алфавіту, підтримуваних клієнтом, на серверній стороні (тип даних – список цілочисельних величин);


• TT – список транспортних кодувань, підтримуваних клієнтом, на серверній стороні (тип даних – список цілочисельних величин);


• TDATE – дата і час створення ресурсу, знайденого в кеші (тип даних – позначка часу);


• SS – список кодувань національного алфавіту, підтримуваних сервером (тип даних – список цілочисельних величин);


• ST – список транспортних кодувань, підтримуваних сервером (тип даних – список цілочисельних величин);


• VALUE_CNT – кількість ресурсів, розміщених на сервері (тип даних – цілочисельний);


• VALUE_NAMES – імена ресурсів, розміщених на сервері (тип даних – список строкових величин);


• VALUE_DATES – дата і час створення ресурсів, розміщених на сервері (тип даних – список відміток часу);


• VALUE_VALUES – вміст ресурсів, розміщених на сервері (тип даних – список строкових величин);


• VALUE_CHARSETS – кодування національної мови ресурсів, розміщених на сервері (тип даних – список цілочисельних величин);


• SI – номер знайденого на сервері ресурсу (тип даних – цілочисельний);


• AS – кодування національного алфавіту, обрана сервером як активна протягом поточної сесії (тип даних – цілочисельний);


• AT – транспортна кодування, обрана сервером як активна протягом поточної сесії (тип даних – цілочисельний);


• DS – кодування національного алфавіту, обрана сервером як активна протягом поточної сесії, на стороні клієнта (тип даних – цілочисельний);


• DT – транспортна кодування, обрана сервером як активна протягом поточної сесії, на стороні клієнта (тип даних – цілочисельний);


• CM – буфер на клієнтській стороні для вмісту ресурсу в ході перекодіровок (тип даних – рядковий);


• SM – буфер на серверній стороні для вмісту ресурсу в ході перекодіровок (тип даних – рядковий);


• CE – код відповіді сервера на стороні клієнта (тип даних – цілочисельний).


Додатково введемо константи:


• С202 – код відповіді, відповідний успішну відправку ресурсу сервером;


• С304 – код відповіді, відповідний незмінності ресурсу з моменту останнього завантаження його клієнтом;


• С404 – код відповіді, відповідний відсутності ресурсу;


• С406 – код відповіді, відповідний несогласуемості параметрів клієнтської і серверної сторони.


Інформаційний граф протоколів у рамках даної моделі представлений на рис. 4.


Іменні процедури в моделі мають наступні функції:


• ENC_REQ – кодування запиту;


• DEC_REQ – декодування запиту;


• ENC_RESP – кодування відповіді;


• DEC_RESP – декодування відповіді;


• CHARSET – зміна схеми кодування алфавіту національної мови;


• ENC_TRANS – транспортне кодування;


• DEC_TRANS – транспортне декодування.


Операції присвоювання SB = CB і CB = SB представляють собою передачу повідомлень по мережі TCP / IP.


Протокол транспортного рівня TCP


Розрізняють дві основні функції протоколу TCP (transmission control protocol):


• підтвердження доставки повідомлення від відправника одержувачу;


• управління швидкістю обміну даними.


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


Крім того, для гарантованої доставки повідомлень між клієнтської і серверної стороною на час передачі повідомлення встановлюється унікальний сеанс, в рамках якого пересилаються пакети квитирования – Підтвердження доставки. Початок сеансу запитується клієнтської стороною службовим пакетом SYN з вмістом нульової довжини, а підтверджується з боку сервера пакетом SYN_ACK також з вмістом нульової довжини. Закінчення сеансу запитується службовим пакетом FIN і підтверджується пакетом FIN у зворотному напрямку.


Виходячи з симетричності протоколу TCP, для цілей, поставлених у цій роботі, досить побудувати модель TCP-з'єднання, що передає дані в одному напрямку (скажімо, від зухвалої сторони до викликається).


Опишемо стан системи "TCP-клієнт – TCP-сервер" такими величинами:


• кількістю вікон N, на які буде розбито передане повідомлення (тип даних – цілочисельний);


• значенням вікон S1, S2, … SN на передавальній стороні (розмір вікон у бітах може бути непостійний, але для даного завдання це не грає ролі) (тип даних – список строкових величин);


• буфером передавальної сторони SB розміром в одне вікно (тип даних – рядковий);


• порядковим номером поточного переданого вікна SI (тип даних – цілочисельний);


• значенням вікон R1, R2, … RN на приймаючій стороні (тип даних – список строкових величин);


• буфером приймаючої сторони RB розміром в одне вікно (тип даних – рядковий);


• порядковим номером поточного прийнятого вікна RI (тип даних – цілочисельний).


Крім того, введемо службові значення буферів прийому і передачі, що відповідають за початок і закінчення сеансу:


• SYN – запит на встановлення з'єднання;


• SYN_ACK – підтвердження встановлення з'єднання;


• ACK – підтвердження прийому вікна повідомлення;


• FIN – сигнал закінчення повідомлення.


Інформаційний граф протоколу TCP в рамках введених позначень представлений на рис. 5. Операції присвоєння SB = RB та RB = SB представляють собою передачу вікон по мережі за допомогою протоколу IP.


Протокол мережного рівня IP


Протоколи мережевого рівня відповідають за відносно незалежну для вищих рівнів моделі OSI передачу повідомлень по мережах з гетерогенною структурою протоколів канального рівня (Ethernet, FrameRealy, ATM, PPP і т. д.). Як наслідок, у їхні функції входить маршрутизація пакетів в просторі імен мережевого рівня, а також фрагментація та збирання пакетів (у зв'язку з варійованими максимально можливої довжини пакета в різних протоколах канального рівня).


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


Стан системи "відправник – одержувач" при передачі одного пакета протоколу IP опишемо такими величинами:


• кількістю фрагментів N, на які буде розбито передане повідомлення (тип даних – цілочисельний);


• значенням пакетів-фрагментів S1, S2, … SN на передавальній стороні (тип даних – список строкових величин);


• порядковим номером поточного переданого фрагмента SI (тип даних – цілочисельний);


• мережевим буфером B розміром, рівним максимально можливої довжині IP-повідомлення (тип даних – список строкових величин);


• значенням пакетів-фрагментів R1, R2, … RN на приймаючій стороні (тип даних – список строкових величин);


• значенням буфера RB на приймальній стороні розміром в один фрагмент (тип даних – рядковий);


• значенням номера прийнятого пакету на приймальній стороні PI (тип даних – цілочисельний).


У цьому випадку інформаційний граф протоколу IP має такий вигляд (рис. 6). Операції присвоювання та читання з буфера B являють собою передачу вікон по мережі за допомогою протоколу нижчого рівня. Для операції читання з буфера B існують обмеження: не можна вважати j-ий елемент буфера B, якщо лічильник SI менше j.


Відзначимо, що іменні процедури в моделі мають наступні функції:


• FRAG – фрагментованість повідомлення на елементи Si;


• DEFRAG – складання повідомлення з елементів Ri, перевірка повного прийому на основі порядкових номерів фрагментів;


• ENC_IP – кодування IP-фрагмента;


• DEC_IP – декодування IP-фрагмента.


Характерною особливістю інформаційного графа протоколу IP є недетермінірованності його поведінки при рівних початкових умовах. Приклад графа станів системи для кількості фрагментів, рівного двом, наведено на рис. 7.


Трохи теорії моніторингу безпеки ERP-систем


Проведемо аналіз отриманих моделей обробки даних за допомогою методів аналізу розмірностей і подоби. Дані методи були спочатку розроблені авторами для аналітичної верифікації додатків і грунтуються на перевірці спільної системи розмірностей моделі обробки даних ERP Oracle E-Business Suite.


Коротко суть пропонованих методів полягає в тому, що для інформаційного графа моделі обробки даних ERP Oracle E-Business Suite будується система взаємозв'язків між розмірностями змінних і констант наступним чином. Кожен оператор моделі, що містить обчислювальні операції та / або оператор присвоювання і має однорідний вигляд щодо своїх аргументів, представляється у вигляді суми функціоналів ?:


Крім цього, приведення умови розгалуження циклу (SI <N) до канонічного вигляду (T *= SI – N; T * <0, де T * – допоміжна величина) додає рівняння розмірності


[ N ] = [ SI ].


Матрична форма AL 5 запису системи (8) для даного протоколу наведена в таблиці 7. У заголовках стовпців вказані відповідні змінні xj.


Матриця має розмірність 11×13. Ранг матриці дорівнює 10, що відповідає одній лінійно залежною рядку (у даному випадку рядок 4 є інверсією рядки 2). Шляхом еквівалентних перетворень наведемо матрицю до вигляду BL 5, що складається з базисних стовпців і залежних стовпців, що містять по одному одиничному елементу (табл. 8).


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


Моніторинг безпеки протоколу IP .


Представницька вибірка реалізацій для протоколу IP містить наступні взаємозв'язки між розмірностями величин в явному вигляді:


[S]=[RB] [PI]=[SI] [RI]=[1**]


[RB]=[R] [SI]=[1*]


Крім того, оператори умови містять ще два обмеження на розмірність:


[ SI ]=[ N ] и [ RI ]=[ N ].


Матрична форма запису AL 3 системи рівнянь (8) для даної моделі наведена в таблиці 9, формат запису відповідає формату попереднього пункту.


Матриця має розмірність 7×9, ранг матриці – 7. Шляхом еквівалентних перетворень наведемо матрицю до спеціального виду BL 3 (таблиця 10).


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


Таким чином, стає можливим здійснювати моніторинг безпеки моделей мережевої взаємодії в ERP Oracle E – Business Suite на основі TCP / IP. Істотним достоїнством пропонованого методу є вироблення необхідних критеріїв семантичної коректності моделі обробки даних в ERP Oracle E – Business Suite.


Висновок


Відомо, що своєчасність та правильність моніторингу безпеки ERP Oracle E – Business Suite багато в чому визначає ефективність управління технологіями та організаційно-технічними засобами захисту інформації. Вивчення специфіки такого завдання вказує на необхідність виділення і контролю інваріантів коректною (правильної з точки зору безпеки) обробки даних в ERP Oracle E – Business Suite. У пропонованому методі моніторингу безпеки узагальнено, систематизовано і розвинені практичні результати моніторингу стану захищеності типової системи ERP Oracle E – Business Suite у вітчизняних підприємствах. Важливим моментом цього методу є розвиток стандартних технологій і засобів захисту ERP Oracle E – Business Suite, що надають можливість контролю стану захищеності на основі інваріантів безпечної обробки даних корпоративної системи в реальному масштабі часу, що враховують бізнес-логіку конкретного підприємства. Узагальнюючи сказане вище, слід зауважити, що всі викладені результати служать єдиної мети – створення нового, більш ефективного та обгрунтованого практично підходу до моніторингу безпеки ERP Oracle


E – Business Suite. Пропонований підхід може бути корисний керівникам, їх заступникам з розвитку, автоматизації та безпеки, начальникам служб автоматизації та інформаційної безпеки, а також всім особам, відповідальним за організацію інформаційної безпеки ERP Oracle


E – Business Suite на підприємстві при виконанні рекомендацій та вимог керівних і нормативних документів Гостехкомиссии Росії, ФАПСИ, а також міжнародних стандартів, головним чином, ISO 17799 ( BS 7799), ISO 15408, ISO 9001:9002, BSI .

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*