13.

1 THE BELL-LAPADULA MODEL FOR COMPUTER SECURITY

Model Keamanan komputer
Dua fakta sejarah menyoroti masalah mendasar yang perlu ditangani dibidang
keamanan komputer. Pertama, semua sistem software yang kompleks nantinya memiliki
kelemahan mengungkapkan atau bug yang kemudian perlu diperbaiki. Sebuah diskusi
yang baik dari ini dapat ditemukan di dalam klasik The Mythical Man-Month
[BROO95]. Kedua, sangat sulit, atau bahkan tidak mungkin, untuk membangun sebuah
perangkat keras komputer / system software yang tidak rentan terhadap berbagai
serangan keamanan. Kesulitan ilustrasi ini adalah sistem operasi Windows NT, yang
diperkenalkan oleh Microsoft pada awal 1990-an. Windows NT dijanjikan memiliki
tingkat keamanan yang tinggi dan menjadi jauh lebih unggul dari OS sebelumnya,
termasuk Microsoft Windows 3.0 dan masih banyak personal komputer lainnya,
workstation, dan server OS. Sayangnya, Windows NT tidak memberikan janji ini. OS
ini dan penerusnya versi Windows-nya secara kronis terkendala dengan berbagai
kerentanan keamanan. Masalah yang dilakukan dengan menyediakan keamanan
komputer yang kuat melibatkan desain dan implementasi. Memang sulit, dalam
merancang perangkat keras atau modul perangkat lunak, harus yakin bahwa desain tidak
sebenarnya memberikan tingkat keamanan yang dimaksudkan. Menghasilkan Kesulitan
di banyak kerentanan keamanan yang tak terduga. bahkan jika desain dalam arti tepat,
sulit, atau bahkan tidak mungkin, untuk menerapkan desain tanpa ada kesalahan atau
bug, menyediakan host lain dari kelemahan. Masalah tersebut telah memunculkan suatu
keinginan untuk mengembangkan metode untuk membuktikan, secara logis atau
matematis, bahwa desain tertentu memenuhi serangkaian kebutuhan keamanan dan
implementasi desain yang tepat sesuai dengan spesifikasi desain. Untuk tujuan ini,
peneliti keamanan telah berusaha untuk mengembangkan model formal keamanan
komputer yang dapat digunakan untuk memverifikasi desain keamanan dan
implementasi. Awalnya, penelitian di bidang ini didanai oleh Departemen Pertahanan
AS dan kemajuan besar dibuat dalam mengembangkan model dan menerapkannya pada
prototipe sistem. Pendanaan yang banyak berkurang sebagaimana memiliki upaya untuk
membangun model formal sistem yang kompleks. Kendati demikian, model tersebut

memiliki nilai dalam menyediakan disiplin dan keseragaman dalam mendefinisikan

pendekatan desain untuk kebutuhan keamanan [BELL05]. Pada bagian ini, kita akan
melihat kemungkinan yang berpengaruh di Model keamanan komputer, Bell-LaPadula
(BLP) Model [BELL73, BELL75]. Ada beberapa macam model lainnya yang dikaji
pada Bagian 13.2.
General Description
Model BLP dikembangkan pada 1970-an sebagai model formal untuk akses kontrol.
Model mengandalkan konsep kontrol akses yang dijelaskan dalam Bab 4 (misalnya,
Gambar 4.4). Dalam model, masing-masing subjek dan setiap objek ditugaskan pada
kelas keamanan. Dalam perumusan sederhana, kelas keamanan membentuk hierarki
yang ketat dan disebut sebagai tingkat keamanan. Salah satu contoh adalah klasifikasi
skema militer AS :
top secret > secret > confidential > restricted > unclassified
Hal ini mungkin juga untuk menambahkan seperangkat kategori atau kompartemen
untuk setiap tingkat keamanan, sehingga subjek harus ditentukan baik tingkat yang
sesuai maupun kategori untuk mengakses objek. Kita mengabaikan perbaikan ini dalam
pembahasan berikut. Konsep ini juga berlaku di daerah lain, di mana informasi dapat
disusun dalam tingkatan kotor serta kategori dan pengguna bisa diberikan izin untuk
mengakses kategori tertentu dari data. Sebagai contoh, tingkat keamanan tertinggi
mungkin bagi strategis dokumen perencanaan perusahaan dan data, dapat diakses oleh
pejabat perusahaan dan staf mereka saja; berikutnya mungkin sensitif keuangan dan
data personil, hanya dapat diakses oleh personil administrasi, pejabat perusahaan, dan
sebagainya. Ini menunjukkan skema klasifikasi seperti,
strategic > sensitive > confidential > public
Subjek dikatakan memiliki akses keamanan dari tingkat tertentu; objek dikatakan
memiliki klasifikasi keamanan tingkat tertentu. Kelas keamanan mengontrol cara
dimana subjek dapat mengakses objek. Model ini didefinisikan empat mode akses,
meskipun penulis menunjukkan bahwa dalam lingkungan implementasi spesifik, sebuah
mode yang berbeda dapat digunakan. Mode adalah sebagai berikut:
baca: Subjek diperbolehkan hanya membaca akses ke objek.
append: Subjek hanya diperbolehkan menuliskan akses ke objek.

 menulis: Subjek diperbolehkan kedua-duanya membaca dan menulis akses ke objek.

mengeksekusi: Subjek diperbolehkan membaca maupun menulis akses ke objek tapi
bisa meminta objek untuk eksekusi.
Ketika beberapa kategori atau tingkat data didefinisikan, kebutuhannya disebut
keamanan multilevel. Pernyataan umum kebutuhan bagi kerahasiaan yang berpusat pada
keamanan multilevel adalah bahwa subjek pada tingkat tinggi mungkin tidak
menyampaikan informasi kepada subjek pada tingkat yang lebih rendah kecuali aliran
yang secara akurat mencerminkan kehendak pengguna yang berwenang sebagaimana
dinyatakan oleh deklasifikasi berwenang. Untuk tujuan implementasi persyaratan ini
dibagi dalam dua bagian dan hanya dinyatakan. Sebuah sistem yang aman multilevel
bagi kerahasiaan harus menegakkan berikut :
No read up : Sebuah subjek hanya dapat membaca sebuah objek dari tingkat keamanan
yang kurang atau sama. Hal ini disebut dalam literatur sebagai properti keamanan
sederhana (ss-properti).
No write down : subjek hanya bisa menulis ke obyek yang lebih besar atau sama
tingkat keamanan. Hal ini disebut dalam literatur sebagai * -property1 (diucapkan
bintang Properti).
Gambar 13.1 menggambarkan kebutuhan untuk *-properti. Di sini, subjek yang
berbahaya melewati informasi rahasia bersama dengan memasukkannya ke dalam
sebuah wadah informasi, label pada klasifikasi keamanan lebih rendah dari informasi itu
sendiri. Ini akan memungkinkan akses baca selanjutnya informasi ini oleh subjek pada
tingkat clearance lebih rendah. Kedua sifat memberikan bentuk kerahasiaan yang
dikenal dengan kendali akses mandatory (MAC). Berdasarkan MAC ini, tidak ada akses
diperbolehkan yang tidak memenuhi dua sifat ini. Selain itu, model BLP membuat
ketentuan untuk kontrol akses discretionary (DAC).
ds-properti: Seorang individu (atau peran) bisa memberikan kepada individu lain (role)
akses ke dokumen berdasarkan kebijakan pemilik, dibatasi oleh aturan MAC. Dengan
demikian, subjek dapat berlatih hanya mengakses untuk yang memiliki kebutuhan
otorisasi dan yang memenuhi aturan MAC. Ide dasarnya adalah bahwa kebijakan situs
menimpa setiap kontrol akses discretionary. Artinya, pengguna tidak dapat memberikan
data ke orang yang tidak berwenang.

Formal Description of Model

Kami menggunakan notasi yang disajikan dalam [BELL75]. Model ini didasarkan pada
konsep keadaan sistem saat ini. State dijelaskan oleh 4-tuple (b, M, f, H), didefinisikan
sebagai berikut :
Saat akses set b: Ini adalah sekumpulan tiga kali lipat dari bentuk (subjek, objek,
AccessMode). A (s, o, a) tiga kali lipat berarti bahwa subjek memiliki akses saat ini
untuk o di akses mode. Catatan bahwa ini tidak hanya sekedar memiliki hak akses untuk
o. tiga kali lipat berarti bahwa s saat melaksanakan akses yang tepat; s saat ini
mengakses o oleh mode.
1 "*" tidak berdiri untuk apa pun. Tidak ada orang bisa memikirkan nama yang sesuai
untuk properti selama penulisan laporan pertama pada model. Tanda bintang itu
karakter palsu dimasukkan dalam draft sehingga editor teks dengan cepat bisa mencari
dan mengganti semua instance dari penggunaannya sekali properti dinamakan. Nama
tidak pernah disusun, dan laporan itu dipublikasikan dengan "*" utuh.

 Akses matriks M: Akses matriks memiliki struktur yang ditunjukkan dalam Bab 4.
Elemen matriks M ij mencatat mode akses di mana subjek S i diizinkan untuk
mengakses objek O j.
Fungsi Tingkat f: Fungsi ini memberikan tingkat keamanan untuk setiap mata
pelajaran dan obyek. Ini terdiri dari tiga pemetaan: fo (O j) adalah tingkat klasifikasi
objek O j; fs (S i) adalah izin keamanan dari subjek S i; f c (S i) adalah keamanan saat
tingkat subjek S i. Clearance keamanan subjek adalah keamanan maksimum tingkat
subjek. Subjek dapat beroperasi pada tingkat ini atau pada tingkat yang lebih rendah.
Dengan demikian, pengguna dapat login ke sistem pada tingkat lebih rendah dari
keamanan izin pengguna. Hal ini sangat berguna dalam sistem kontrol akses berbasis
peran.
Hirarki H: Ini adalah pohon berakar diarahkan yang node sesuai dengan objek dalam
sistem. Model ini mensyaratkan bahwa tingkat keamanan dari sebuah objek harus
mendominasi tingkat keamanan induknya. Untuk diskusi kita, kita dapat menyamakan
ini dengan kondisi bahwa tingkat keamanan dari sebuah objek harus lebih besar dari
atau sama dengan induknya.
Kita sekarang dapat mendefinisikan tiga sifat BLP lebih formal. Untuk setiap subjek Si
dan setiap objek Oj, persyaratan dapat dinyatakan sebagai berikut:
ss-properti: Setiap tiga kali lipat bentuk ( Si , Oj , read) di saat akses set b memiliki fc
properti fc(Si) fo(Oj) .
*-properti: Setiap tiga kali lipat bentuk ( Si, Oj , append) di saat akses set b memiliki
properti fc(Si) fo(Oj). Setiap tiga kali lipat bentuk ( Si , Oj , write) disaat ini akses set
b memiliki properti fc ( Si ) _ fo ( Oj ).
ds-properti: Jika ( Si , Oj , Ax ) adalah akses saat ini (is in b ), maka mode akses Ax
dicatat dalam ( Si , Oj ) unsur M. Artinya, ( Si , Oj , Ax ) menyiratkan bahwa Ax _
M[Si,Oj] .
Ketiga sifat dapat digunakan untuk menentukan sistem yang aman kerahasiaan yang.
Pada dasarnya, sistem yang aman ditandai dengan berikut:
1. Keadaan keamanan saat sistem (b, M, f, H) adalah aman jika dan hanya jika setiap
elemen b memenuhi tiga sifat.
2. Keadaan keamanan sistem diubah oleh operasi yang menyebabkan mengubah salah
satu dari empat komponen sistem, (b, M, f, H).
3. Sebuah sistem yang aman tetap aman selama perubahan state tidak melanggar tiga
sifat.

Abstract Operations
Model BLP mencakup seperangkat aturan berdasarkan operasi abstrak yang mengubah
keadaan dari sistem. Aturan adalah sebagai berikut:
1. Dapatkan akses: Tambahkan triple (subjek, objek, akses-mode) untuk saat ini
akses set b. Digunakan oleh subjek untuk memulai akses ke suatu objek dalam
modus diminta.
2. Akses Rilis: Hapus triple (subjek, objek, akses-mode) dari saat ini Akses mengatur
b. Digunakan untuk melepaskan akses diprakarsai sebelumnya.
3. Ganti tingkat objek: Ubah nilai fo (Oj) untuk beberapa objek Oj. Digunakan oleh
subjek untuk mengubah tingkat keamanan dari sebuah objek.
4. Ubah tingkat saat: Ubah nilai fc (Si) untuk beberapa subjek Si. Digunakan oleh
subjek untuk mengubah tingkat keamanan subjek.
5. Berikan izin akses: Tambahkan mode akses ke beberapa masuknya akses izin
matriks M. Digunakan oleh subjek untuk memberikan modus akses pada ditentukan
keberatan dengan topik lain.
6. membatalkan izin akses: Hapus mode akses dari beberapa masuknya M.
Digunakan oleh subjek untuk mencabut akses yang diberikan sebelumnya.
7. Membuat obyek : Lampirkan objek untuk saat ini struktur pohon H sebagai daun.
Digunakan untuk membuat objek baru atau mengaktifkan objek sebelumnya yang
telah didefinisikan tetapi tidak aktif karena belum dimasukkan ke H.
8. Menghapus sekelompok objek : Lepaskan dari H objek dan semua objek lainnya
bawahnya dalam hirarki. Hal ini membuat kelompok benda tidak aktif. Operasi ini
juga dapat mengubah arus akses set b karena semua akses ke objek dilepaskan.
Aturan 1 dan 2 mengubah akses saat ini; aturan 3 dan 4 mengubah fungsi tingkat; aturan
5 dan 6 izin akses alter; dan aturan 7 dan 8 mengubah hirarki. setiap aturan diatur oleh
aplikasi dari tiga sifat. Misalnya, untuk mendapatkan akses untuk membaca, kita harus
memiliki fc(Si) fo(Oj) and Ax _ M[Si,Oj] .
Example of BLP Use
Contoh, dari [WEIP06] menggambarkan pengoperasian model BLP dan juga menyoroti
masalah praktis yang harus diatasi. Kami berasumsi akses berbasis peran sistem

pengaturan. Carla dan Dirk adalah pengguna sistem. Carla adalah mahasiswa (s) di
kursus c1. Dirk adalah seorang guru (t) dalam kursus c1 tetapi juga dapat mengakses
sistem sebagai mahasiswa; sehingga dua peran yang ditugaskan untuk Dirk :
Carla: (c1-s)
Dirk: (c1-t), (c1-s)
Peran mahasiswa diberi akses keamanan yang lebih rendah dan peran guru akses
keamanan yang lebih tinggi. Mari kita lihat beberapa tindakan yang mungkin:
1. Dirk menciptakan f1 file baru sebagai c1-t; Carla menciptakan f2 file sebagai c1-s
(Gambar 13.2a). Carla bisa membaca dan menulis ke f2, tapi tidak bisa membaca f1,
karena pada yang lebih tinggi tingkat klasifikasi (tingkat guru). Dalam peran c1-t, Dirk
dapat membaca dan menulis f1 dan dapat membaca f2 jika Carla memberikan akses ke
f2. Namun, dalam peran ini, Dirk tidak bisa menulis f2 karena *-properti; tidak Dirk
atau kuda Trojan pada nya nama dapat menurunkan data dari tingkat guru untuk tingkat
mahasiswa. Hanya jika Dirk log in sebagai mahasiswa dapat ia membuat c1-s file atau
menulis ke yang ada c1-s berkas, seperti f2. Dalam peran mahasiswa, Dirk juga dapat
membaca f2.
2. Dirk membaca f2 dan ingin membuat file baru dengan komentar untuk Carla sebagai
umpan balik. Dirk harus masuk peran mahasiswa c1-s untuk membuat f3 sehingga dapat
diakses oleh Carla (Gambar 13.2b). Dalam peran guru, Dirk tidak dapat membuat
sebuah file di mahasiswa tingkat klasifikasi.
3. Dirk menciptakan ujian berdasarkan sebuah toko file template yang ada di tingkat c1t.Dirk harus login sebagai c1-t untuk membaca template dan file ia menciptakan (f4)
harus juga berada pada tingkat guru (Gambar 13.2c).
4. Dirk ingin Carla untuk mengambil ujian dan harus memberikan dia dengan akses
baca. Namun, akses tersebut akan melanggar ss-properti. Dirk harus downgrade
klasifikasi f4 dari c1-t untuk c1-s. Dirk tidak bisa melakukan ini dalam peran c1-t
karena ini akan melanggar *-properti. Oleh karena itu, administrator keamanan
(mungkin Dirk dalam peran ini) harus memiliki otoritas downgrade dan harus mampu
melakukan downgrade luar model BLP. Garis putus-putus di Gambar 13.2d
menghubungkan f4 dengan c1-s-read menunjukkan bahwa hubungan ini memiliki
belum dihasilkan oleh aturan BLP default, tetapi oleh sistem operasi.

5. Carla menulis jawaban atas ujian ke dalam f5 berkas. Dia menciptakan file pada
tingkat c1-t sehingga hanya Dirk dapat membaca file. Ini adalah contoh dari penulisan,
yang tidak dilarang oleh aturan BLP. Carla masih bisa melihat jawabannya padanya
workstation tetapi tidak dapat mengakses f5 untuk membaca.

Diskusi ini menggambarkan beberapa keterbatasan praktis kritis terhadap BLP model.
Pertama, seperti yang tercantum dalam langkah 4, model BLP tidak memiliki ketentuan
untuk mengelola "Downgrade" dari objek, meskipun persyaratan untuk keamanan
bertingkat mengakui bahwa aliran seperti informasi dari yang lebih tinggi ke tingkat
yang lebih rendah mungkin diperlukan, asalkan mencerminkan kehendak pengguna
yang berwenang. Oleh karena itu, setiap praktis implementasi sistem multilevel harus
mendukung proses tersebut dalam dikontrol dan dimonitor secara. Terkait dengan ini
adalah kekhawatiran lain. Sebuah subjek dibatasi oleh model BLP hanya bisa "editing"
(membaca dan menulis) file di salah satu keamanan tingkat sementara juga melihat file
pada tingkat yang sama atau lebih rendah. Jika dokumen baru mengkonsolidasikan
informasi dari berbagai sumber dan tingkat, beberapa informasi yang sekarang
diklasifikasikan pada tingkat yang lebih tinggi dari itu awalnya. Hal ini dikenal sebagai
klasifikasi merayap dan merupakan keprihatinan terkenal ketika mengelola informasi
multilevel. Sekali lagi, beberapa proses merendahkan dikelola informasi yang
dibutuhkan untuk memulihkan tingkat klasifikasi yang wajar.

Implementation ExampleMultics
[BELL75] menguraikan implementasi dari MLS pada sistem operasi Multics.
Kami memulai dengan penjelasan singkat tentang aspek yang relevan dari Multics.
Multics adalah sistem operasi time-sharing yang dikembangkan oleh kelompok MIT
dikenal sebagai Project MAC (komputer multiple-akses) pada tahun 1960. Multics
bukan hanya tahun tapi puluhan tahun dari waktu ke depan. Bahkan pada pertengahan
1980-an, hamper 20 tahun setelah menjadi operasional, Multics memiliki fitur
keamanan yang unggul dan kecanggihan yang lebih besar dalam antarmuka pengguna
dan daerah selain kontemporer lainnya sistem operasi mainframe.
Kedua manajemen memori dan sistem file di Multics didasarkan pada konsep
segmen. Virtual memory tersegmentasi. Bagi kebanyakan platform perangkat keras,
paging juga digunakan. Dalam kasus apapun, ruang kerja dari suatu proses ditugaskan
untuk segmen dan proses bisa membuat satu atau lebih data yang segmen untuk
digunakan selama eksekusi. Setiap file dalam sistem file didefinisikan sebagai segmen.
Dengan demikian, OS menggunakan mekanisme yang sama untuk memuat segmen data
dari memori virtual ke memori utama dan memuat file dari memori virtual ke memori
utama. Segmen disusun secara hirarki, dari direktori root ke segmen individu.
Multics mengelola ruang alamat virtual dengan cara segmen descriptor, yang
berhubungan dengan proses dan yang memiliki satu entri untuk setiap segmen di virtual
memori dapat diakses oleh proses ini. Segmen basis poin menjadi deskriptor daftar awal
segmen descriptor untuk proses yang saat ini mengeksekusi. Itu entri deskriptor
termasuk pointer ke awal dari segmen di memori virtual ditambah informasi
perlindungan, dalam bentuk membaca, menuliskan, dan mengeksekusi bit, yang
mungkin secara individual diatur ke ON atau OFF. Informasi perlindungan ditemukan
dalam segmen deskripsi berasal dari daftar kontrol akses untuk segmen tersebut. Untuk
MLS, dua fitur tambahan yang diperlukan. Sebuah meja tingkat proses mencakup entri
dari setiap proses aktif, dan entri menunjukkan akses keamanan dari proses. Terkait
dengan setiap segmen tingkat keamanan, yang disimpan dalam segmen direktori induk
dari segmen yang bersangkutan.

Sesuai dengan keadaan keamanan model BLP (b, M, f, H) adalah sekumpulan

Struktur data Multics (Gambar 13.3). Korespondensi adalah sebagai berikut:
B : Segmen kata descriptor. Segmen descriptor mengidentifikasi subjek (proses).
Segmen pointer di mengidentifikasi kata segmen descriptor objek (segmen data). Bit
kontrol tiga akses di segmen kata descriptor mengidentifikasi mode akses.
M : daftar Akses kontrol.
F: Informasi di segmen direktori dan pada tabel proses-tingkat.
H: struktur hirarkis segmen.
Dengan struktur data ini, Multics dapat menegakkan diskresioner dan wajib
kontrol akses. Ketika proses mencoba akses ke segmen, itu harus memiliki izin akses
yang diinginkan sebagaimana ditentukan oleh daftar kontrol akses. Juga, izin keamanan
dibandingkan dengan klasifikasi keamanan segmen untuk diakses untuk menentukan
apakah aturan keamanan sederhana dan * aturan keamanan-properti terpenuhi.

Limitations to the BLP model

Sementara model BLP menurut teori meletakkan dasar untuk komputasi aman
dalam lingkungan administrasi wilayah tunggal, ada beberapa keterbatasan penting
untuk kegunaan dan kesulitan untuk pelaksanaannya. Pertama, ada ketidakcocokan
kerahasiaan yang dan integritas dalam satu Sistem MLS. Secara umum, MLS dapat

bekerja baik untuk kekuatan atau rahasia, tapi tidak mudah untuk keduanya. Mutual
exclusion ini tidak termasuk beberapa kekuatan yang menarik dan integritas teknologi
berpusat dari yang digunakan secara efektif dalam gaya BLP MLS lingkungan.
Sebuah keterbatasan kedua yang penting untuk kegunaan adalah disebut bekerja
sama konspirator masalah di hadapan saluran rahasia. Dengan adanya sumber daya
berbagi*-properti dapat menjadi tidak dapat dilaksanakan. Hal ini terutama masalah di
hadapan konten aktif yang lazim di pengolah kata saat ini dan dokumen lainnya format.
Sebuah dokumen yang berbahaya bisa membawa di dalamnya subjek yang akan
dieksekusi ketika disiarkan dokumen rahasia menggunakan bersama-sumber daya
saluran rahasia. Pada dasarnya, Model BLP efektif memecah ketika (dipercaya) Data
executable rahasia rendah diizinkan untuk dieksekusi oleh clearance tinggi (terpercaya)
subjek.
13.2 OTHER FORMAL MODELS FOR COMPUTER SECURITY
Hal ini penting untuk dicatat bahwa model yang dijelaskan dalam bab ini baik
fokus pada kerahasiaan yang atau integritas, dengan pengecualian dari Chinese Wall
Model. Itu ketidakcocokan kerahasiaan dan integritas kekhawatiran diakui menjadi
besar batasan untuk kegunaan dari MLS pada umumnya, dan untuk kerahasiaan yang
fokus MLS di spesifik. Bagian ini membahas beberapa model penting keamanan
komputer lainnya.
Biba Integrity Model
Penawaran Model BLP dengan kerahasiaannya dan berkaitan dengan tidak sah
pengungkapan informasi. Biba [BIBA77] model berkaitan dengan integritas dan yang
bersangkutan dengan modifikasi yang tidak sah dari data. Model Biba dimaksudkan
untuk berurusan dengan kasus di mana ada data yang harus dilihat oleh pengguna di
beberapa atau semua tingkatan keamanan, tetapi hanya harus diubah dengan cara
dikendalikan oleh agen resmi. Unsur-unsur dasar dari model Biba memiliki struktur
yang sama seperti BLP model. Seperti BLP, model Biba berkaitan dengan subjek dan
objek. setiap subjek dan objek ditugaskan tingkat integritas, dinotasikan sebagai I (S)

dan I (O) untuk subjek S dan object o, masing-masing. Sebuah klasifikasi hirarkis
sederhana dapat digunakan, di mana ada memesan ketat dari tingkatan dari terendah ke
tertinggi. Seperti pada model BLP, juga mungkin untuk menambahkan satu set kategori
untuk skema klasifikasi; ini kita mengabaikan sini. Model menganggap mode akses
berikut :
Modifikasi

: Untuk menulis atau memperbarui informasi dalam suatu objek

Observasi

: Untuk membaca informasi dalam suatu objek

Execute

: Untuk mengeksekusi sebuah objek

Invoke

: Komunikasi dari satu hal ke yang lain

Pertama tiga mode analog dengan mode akses BLP. Modus meminta adalah baru.
Biba kemudian mengusulkan sejumlah kebijakan alternatif yang dapat dikenakan pada
ini model. Yang paling relevan adalah kebijakan integritas yang ketat, berdasarkan
aturan berikut:
integritas Sederhana: Sebuah subjek dapat memodifikasi sebuah objek hanya jika
tingkat integritas subjek mendominasi tingkat integritas dari objek : I( S ) _ I( O ).
Integritas kurungan: Sebuah subjek dapat membaca sebuah objek hanya jika tingkat
integritas subjek didominasi oleh tingkat integritas dari objek : I( S ) _ I( O ).
properti Doa: Sebuah subjek dapat meminta topik lain hanya jika integritas tingkat
subjek pertama mendominasi tingkat integritas subjek kedua: I(S1 ) _ I( S2 ).
Pertama kedua aturan analog dengan model BLP tapi bersangkutan dengan
integritas dan membalikkan pentingnya membaca dan menulis. Aturan integritas
sederhana adalah pembatasan write-up logis yang mencegah kontaminasi data-integritas
tinggi. Gambar 13.4 mengilustrasikan perlunya aturan integritas kurungan. Sebuah
proses integritas rendah dapat membaca data-integritas rendah tetapi dicegah
mengkontaminasi highintegrity sebuah file dengan data dengan aturan integritas
sederhana. Kalau saja aturan ini berlaku, sebuah Proses-integritas tinggi dibayangkan
bisa menyalin data-integritas rendah ke dalam integritas tinggi mengajukan. Biasanya,
orang akan percaya proses-integritas tinggi untuk tidak mengotori highintegrity sebuah
file, namun terjadi kesalahan dalam kode proses atau Trojan horse dapat mengakibatkan
kontaminasi tersebut; maka kebutuhan untuk aturan integritas kurungan.

Clark-Wilson Integrity Model

Sebuah model integritas yang lebih rumit dan mungkin lebih praktis diusulkan oleh
Clark dan Wilson [CLAR87]. Clark-Wilson Model (CWM) ditujukan untuk komersial
daripada aplikasi militer dan erat model operasi komersial yang nyata. Itu Model ini
didasarkan pada dua konsep yang secara tradisional digunakan untuk menegakkan
komersial kebijakan keamanan:
transaksi Terletak dibentuk: Seorang pengguna tidak harus memanipulasi data
sewenang-wenang, tetapi hanya dengan cara dibatasi yang melestarikan atau menjamin
integritas data.
Pemisahan tugas antara pengguna: Setiap orang diizinkan untuk membuat atau
mengesahkan suatu transaksi baik terbentuk mungkin tidak diizinkan untuk
melaksanakannya (setidaknya terhadap data produksi).
Model ini menyebabkan banyaknya kontrol integritas data dan transaksi yang
memanipulasi data. Komponen utama dari model adalah sebagai berikut:
item data Dibatasi (CDIS): Sesuai dengan kontrol integritas yang ketat.
item Yang tanpa data (UDIs): item data dicentang. Contohnya adalah file teks
sederhana.
prosedur verifikasi Integritas (IVP): Dimaksudkan untuk memastikan bahwa
semua CDIS sesuai dengan beberapa model aplikasi spesifik integritas dan
konsistensi.
Prosedur Transformasi (TPS): transaksi Sistem yang mengubah set CDIS dari
satu negara yang konsisten yang lain.

CWM memaksa integritas melalui sertifikasi dan penegakan aturan di TPS.

Aturan sertifikasi pembatasan kebijakan keamanan pada perilaku IVP dan TPS. Aturan
penegakan mekanisme sistem keamanan built-in yang mencapai
tujuan dari aturan sertifikasi. Aturan adalah sebagai berikut:
Cl: Semua IVP benar harus memastikan bahwa semua CDIS berada dalam keadaan
yang valid pada saat itu IVP dijalankan.
C2: Semua TPS harus disertifikasi untuk menjadi valid. Artinya, mereka harus
mengambil CDI untuk yang valid keadaan akhir, mengingat bahwa itu adalah dalam
keadaan yang valid untuk memulai. Untuk setiap TP, dan setiap rangkaian CDIS bahwa
mungkin memanipulasi, petugas keamanan harus menentukan hubungan, yang
mendefinisikan eksekusi itu. Suatu relasi demikian dalam bentuk (TPI,(CDIA, CDIb,
CDIC...)), Di mana daftar CDIS mendefinisikan satu set tertentu argumen yang TP telah
disertifikasi.
El: Sistem harus menjaga daftar hubungan yang ditentukan dalam aturan C2 dan harus
memastikan bahwa hanya manipulasi setiap CDI adalah dengan TP, di mana TP
beroperasi pada CDI sebagaimana ditentukan dalam beberapa hubungan.
E2: Sistem harus mempertahankan daftar hubungan dalam bentuk (UserID, TPI, (CDIA,
CDIb, CDIC,...)), Yang berhubungan pengguna, TP, dan objek data TP yang mungkin
referensi atas nama pengguna tersebut. Ini harus memastikan bahwa hanya eksekusi
yang dijelaskan dalam salah satu hubungan yang dilakukan.
C3: Daftar hubungan di E2 harus disertifikasi untuk memenuhi pemisahan tugas
kebutuhan.
E3: Sistem harus mengotentikasi identitas setiap pengguna mencoba untuk
mengeksekusi TP.
C4: Semua TPS harus disertifikasi untuk menulis ke append-satunya CDI (log) semua
informasi diperlukan untuk memungkinkan sifat operasi yang akan direkonstruksi.
C5: Setiap TP yang mengambil UDI sebagai nilai masukan harus disertifikasi untuk
melakukan transformasi hanya berlaku, atau yang lain tidak ada transformasi, untuk
kemungkinan nilai UDI. Transformasi harus mengambil input dari UDI ke CDI, atau
UDI ditolak. Biasanya, ini adalah program edit.

E4: Hanya agen diijinkan untuk mengesahkan entitas dapat mengubah daftar tersebut
entitas yang terkait dengan entitas lain: khusus, daftar TPS terkait dengan CDI dan
daftar pengguna yang terkait dengan TP. Agen yang dapat mengesahkan suatu entitas
mungkin tidak memiliki mengeksekusi hak sehubungan dengan entitas yang. Gambar
13.5 mengilustrasikan aturan. Aturan bergabung membentuk integritas dua bagian
fasilitas jaminan, di mana sertifikasi dilakukan oleh petugas keamanan sehubungan
dengan kebijakan integritas, dan penegakan dilakukan oleh sistem.

Chinese Wall Model

Cina Wall Model (CWM) mengambil pendekatan yang berbeda untuk menentukan
cukup integritas dan kerahasiaan dari salah satu pendekatan yang kita telah diperiksa
sejauh ini. Model ini dikembangkan untuk aplikasi komersial di mana konflik
kepentingan bisa timbul. Model ini menggunakan kedua konsep akses discretionary dan
wajib. Ide utama di balik CWM adalah konsep yang umum dalam keuangan dan profesi
hukum, yang adalah dengan menggunakan apa yang disebut sebagai dinding Cina untuk
mencegah konflik kepentingan. Contoh dari dunia keuangan adalah bahwa dari analis
pasar bekerja untuk sebuah lembaga keuangan yang menyediakan layanan bisnis

perusahaan. Seorang analis tidak bisa dibiarkan untuk memberikan saran kepada salah
satu perusahaan ketika analis memiliki rahasia Informasi (insider pengetahuan) tentang
rencana atau status pesaing. Namun, analis bebas untuk menyarankan beberapa
perusahaan yang tidak bersaing dengan satu sama lain dan untuk menarik informasi
pasar yang terbuka untuk umum. Unsur-unsur dari model adalah sebagai berikut:
Subyek: entitas aktif yang mungkin ingin mengakses objek yang dilindungi; termasuk
pengguna dan proses
Informasi: Informasi Perusahaan diatur dalam hirarki dengan tiga tingkat:
- Objek: item Individu informasi, masing-masing mengenai satu perusahaan
- Dataset (DS): Semua benda yang menyangkut perusahaan yang sama
- Konflik kepentingan (CI) kelas: Semua dataset yang berada di perusahaan
kompetisi
aturan Access: Aturan untuk membaca dan menulis akses.
Gambar 13.6a memberi contoh. Ada dataset yang mewakili bank, minyak
perusahaan, dan perusahaan gas. Semua dataset Bank berada dalam satu CI, semua
perusahaan minyak dataset di CI lain, dan sebagainya. Berbeda dengan model kami
memiliki studi sejauh ini, CWM tidak menetapkan keamanan tingkatan untuk subjek
dan objek dan dengan demikian tidak model aman benar bertingkat. Sebaliknya, sejarah
akses subjek sebelumnya menentukan kontrol akses. Dasar dari Cina Kebijakan dinding
adalah bahwa subjek hanya diperbolehkan akses ke informasi yang tidak diadakan
konflik dengan informasi lain yang sudah mereka miliki. Setelah subjek mengakses
informasi dari satu dataset, dinding diatur untuk melindungi informasi dalam dataset
lainnya di CI yang sama. Subjek dapat mengakses informasi pada satu sisi dinding
tetapi tidak sisi lain. Lebih lanjut, Informasi di CI lainnya awalnya tidak dianggap di
satu sisi atau yang lain dari dinding tapi di tempat terbuka. Ketika akses tambahan
dibuat di CI lain dengan subjek sama, bentuk perubahan dinding untuk menjaga
perlindungan yang diinginkan. Selanjutnya, masing-masing subjek dikendalikan oleh
sendiri dinding-dinding untuk mata pelajaran yang berbeda berbeda.
Untuk menegakkan kebijakan dinding Cina, dua aturan yang diperlukan. Untuk
menunjukkan kesamaan dengan dua aturan BLP, penulis memberi mereka nama yang
sama. Aturan pertama adalah aturan keamanan sederhana:

Aturan keamanan sederhana: A S subjek dapat membaca pada objek O hanya jika
O adalah di DS yang sama sebagai objek yang sudah diakses oleh S, OR
O milik CI dari yang S masih belum diakses informasi

Figur 13.6b dan c menggambarkan pengoperasian aturan ini. Asumsikan bahwa di

beberapa titik, John telah membuat permintaan membaca pertamanya ke objek apapun
dalam set ini untuk sebuah objek di Bank A DS. Karena John sebelumnya tidak diakses
obyek di lain DS di CI 1, akses sudah diberikan. Selanjutnya, sistem harus ingat bahwa
akses telah diberikan sehingga setiap permintaan berikutnya untuk akses ke obyek di
Bank DS B akan ditolak. Setiap permintaan untuk akses ke objek lain di Bank A DS
adalah diberikan. Pada lain waktu, John meminta akses ke sebuah objek dalam Minyak
A DS. Karena tidak ada konflik, akses ini diberikan, tapi dinding diatur untuk melarang
akses berikutnya ke Oil B DS. Demikian pula, Gambar 13.6c menggambarkan sejarah
akses Jane.

13.3 THE CONCEPT OF TRUSTED SYSTEMS

Model dijelaskan dalam sebelumnya dua bagian yang semua bertujuan untuk
meningkatkan kepercayaan bahwa pengguna dan administrator memiliki dalam
keamanan computer sistem. Konsep kepercayaan dalam konteks keamanan komputer
kembali ke awal 1970-an, didorong oleh US Department of Defense dan inisiatif
Pendanaan di daerah ini. Upaya awal yang bertujuan untuk mengembangkan model
keamanan dan kemudian merancang dan menerapkan platform hardware / software

untuk mencapai kepercayaan. Karena masalah biaya dan kinerja, sistem terpercaya tidak
mendapatkan pijakan serius di pasar komersial. Baru-baru ini, minat kepercayaan telah
muncul kembali, dengan bekerja pada platform komputer terpercaya, topik kita
mengeksplorasi dalam Bagian 13.5. Pada bagian ini, kita memeriksa beberapa konsep
dasar dan implikasi dari sistem terpercaya. Beberapa terminologi yang berguna terkait
dengan sistem terpercaya tercantum dalam Tabel 13.1.

Reference Monitors
Pekerjaan awal pada komputer terpercaya dan sistem operasi terpercaya
didasarkan pada konsep referensi memantau, digambarkan pada Gambar 13.7. Referensi
monitor elemen pengendali perangkat keras dan sistem operasi dari komputer yang
mengatur akses subyek ke obyek atas dasar parameter keamanan subjek dan objek.
Referensi Monitor memiliki akses ke file, yang dikenal sebagai Database kernel
keamanan, yang berisi daftar hak akses (keamanan clearance) dari setiap mata pelajaran
dan atribut perlindungan (tingkat klasifikasi) dari setiap objek. Itu referensi memantau
memberlakukan aturan keamanan (tidak ada membaca, tidak ada menuliskan) dan
memiliki sifat sebagai berikut:

 mediasi Lengkap: Aturan keamanan ditegakkan pada setiap akses, bukan hanya,
misalnya, ketika file dibuka.
Isolasi: Monitor referensi dan database dilindungi dari yang tidak sah
modifikasi.
Pemastian: ketepatan referensi monitor harus dapat dibuktikan. Bahwa adalah,
itu harus mungkin untuk menunjukkan secara matematis bahwa referensi Monitor
memberlakukan aturan keamanan dan memberikan mediasi lengkap dan isolasi.

Trojan Horse Defense

Salah satu cara untuk mengamankan terhadap serangan Trojan horse adalah
penggunaan sistem operasi yang aman, terpercaya. Gambar 13.8 mengilustrasikan
sebuah contoh. Dalam hal ini, kuda Trojan digunakan untuk berkeliling mekanisme
keamanan standar yang digunakan oleh sebagian besar manajemen file daftar kontrol
akses: dan sistem operasi. Dalam contoh ini, user bernama Bob berinteraksi melalui
program dengan file data yang berisi kritis sensitive karakter string "CPE170KS."
Pengguna Bob telah menciptakan file dengan membaca / menulis izin disediakan hanya
untuk program mengeksekusi atas nama sendiri: yaitu, hanya proses yang dimiliki oleh
Bob dapat mengakses file. Serangan Trojan horse dimulai ketika pengguna bermusuhan,

bernama Alice, keuntungan akses yang sah ke sistem dan menginstal baik program kuda
Trojan dan swasta file yang akan digunakan dalam serangan sebagai "saku belakang."
Alice memberi baca / tulis izin untuk dirinya sendiri untuk file ini dan memberikan Bob
write-satunya izin (Gambar 13.8a). Alice sekarang menginduksi Bob menyebut program
kuda Trojan, mungkin dengan iklan itu sebagai utilitas berguna. Ketika program
mendeteksi bahwa itu sedang dijalankan oleh Bob, itu membaca karakter string sensitif
dari file dan salinan itu Bob ke backpocket Alice file (Gambar 13.8b). Baik membaca
dan menulis operasi memenuhi kendala dikenakan oleh daftar kontrol akses. Alice
kemudian hanya untuk mengakses file yang Bob di kemudian waktu untuk mempelajari
nilai string.
Sekarang mempertimbangkan penggunaan sistem operasi yang aman dalam
skenario ini (Gambar 13.8c). Tingkat keamanan yang ditugaskan untuk mata pelajaran
pada logon atas dasar kriteria seperti terminal dari mana komputer sedang diakses dan
pengguna yang terlibat, seperti yang diidentifikasi dengan password / ID. Dalam contoh
ini, ada dua tingkat keamanan, sensitif dan masyarakat, memerintahkan agar sensitif
lebih tinggi dari publik. Proses dimiliki oleh data yang Bob dan Bob File ditugaskan
tingkat keamanan sensitif. File dan proses Alice dibatasi untuk umum. Jika Bob
memanggil program Trojan horse (Gambar 13.8d), program yang mengakuisisi Tingkat
keamanan Bob. Oleh karena itu dapat, di bawah properti keamanan sederhana, untuk
mengamati string karakter sensitif. Ketika program mencoba untuk menyimpan string
dalam File publik (file back-saku), namun, *-properti dilanggar dan usaha dilarang oleh
monitor referensi. Dengan demikian, upaya untuk menulis ke belakang-saku File ditolak
meskipun daftar kontrol akses memungkinkan itu: Kebijakan keamanan mengambil hak
lebih atas mekanisme daftar kontrol akses.

13.4 APPLICATION OF MULTILEVEL SECURITY

RFC 2828 mendefinisikan keamanan multilevel sebagai berikut:
Multilevel Aman (MLS): Sebuah kelas sistem yang memiliki sumber daya system
(terutama disimpan informasi) di lebih dari satu tingkat keamanan (yaitu, memiliki
berbagai jenis sumber daya sensitif) dan yang memungkinkan akses bersamaan oleh
pengguna yang berbeda dalam akses keamanan dan kebutuhan-untuk-tahu, tetapi
mampu mencegah setiap pengguna dari sumber daya mengakses yang pengguna tidak
memiliki otorisasi.

Multilevel Security for Role-Based Access Control 3

[OSBO00] menunjukkan bagaimana kontrol akses berbasis aturan (RBAC) sistem dapat
digunakan untuk melaksanakan BLP aturan keamanan multilevel. Ingat bahwa standar
RBAC ANSI spesifikasi termasuk konsep fungsi administrasi, yang menyediakan
kemampuan untuk membuat, menghapus, dan memelihara elemen RBAC dan

hubungan. Ini berguna di sini untuk memberikan peran administratif khusus untuk
fungsi-fungsi ini. Dengan di ini pikiran, Tabel 13.2 merangkum komponen dari RBAC.
Berikut ini spesifikasi formal menunjukkan bagaimana sebuah sistem RBAC dapat
digunakan untuk menerapkan akses MLS:
Kendala pada pengguna: Untuk setiap pengguna u di set pengguna U, izin keamanan
L (u) ditugaskan. Secara formal, 5u _ U[L(u) is given] .
Kendala perizinan: Setiap izin memberikan membaca atau write izin
ke objek o, dan setiap objek memiliki satu membaca dan satu izin menulis. Semua
benda memiliki klasifikasi keamanan. Secara formal, P = {(o, r), (o, w) | ois obyek
dalam sistem}; 5o _ P[L(o) is given] .
Definisi: baca-Tingkat dari r peran, dinotasikan r-tingkat (r), adalah yang paling atas
terikat dari tingkat keamanan dari objek yang (o, r) adalah dalam izin
r. W-tingkat peran r (dilambangkan w-tingkat (r)) adalah yang terbesar lebih rendah
terikat (glb) dari tingkat keamanan obyek o yang (o, w) adalah di
izin dari r, jika glb seperti itu ada. Jika glb tidak ada, w-level
terdefinisi.
Kendala pada UA: Setiap peran r memiliki write-tingkat didefinisikan, dinotasikan
w-tingkat (r). Untuk setiap tugas pengguna, pembersihan pengguna harus mendominasi
yang -tingkat r peran dan didominasi oleh -tingkat w peran.
Secara formal, 5r _ UA [w-level(r) is defined] ; 5(u,r) _ UA [L(u) _ r-level(r)] ;
5(u,r) _ UA [L(u) _ w-level(r)] .
Database Security And Multilevel Security
Penambahan keamanan bertingkat untuk sistem database meningkatkan kompleksitas
fungsi kontrol akses dan desain database itu sendiri. Salah satu isu kunci adalah
granularity klasifikasi. Berikut ini adalah metode yang mungkin memaksakan keamanan
bertingkat pada database relasional, dalam hal rincian klasifikasi (Gambar 13.10):
Seluruh Database: Pendekatan sederhana ini mudah dicapai pada MLS peron. Seluruh
database, seperti database keuangan atau personil, dapat diklasifikasikan sebagai rahasia
atau terbatas dan dipelihara pada server dengan file lainnya.

 tabel Individu (hubungan): Untuk beberapa aplikasi, adalah tepat untuk menetapkan
klasifikasi pada tingkat meja. Pada contoh Gambar 13.10a, dua tingkat klasifikasi
didefinisikan: tak terbatas (U) dan dibatasi (R). Pekerja tabel berisi informasi gaji
sensitif dan diklasifikasikan dibatasi, sementara tabel Departemen tidak dibatasi.
Tingkat granularity relatif mudah untuk penerapan dan menegakkan.
kolom Individu (atribut): Seorang administrator keamanan dapat memilih untuk
menentukan klasifikasi atas dasar atribut, sehingga kolom yang dipilih diklasifikasikan.
Pada contoh Gambar 13.10b, administrator menentukan bahwa informasi gaji dan
identitas manajer departemen dibatasi informasi.
baris Individu (tupel): Dalam keadaan lain, mungkin masuk akal untuk menetapkan
tingkatan klasifikasi atas dasar baris individu yang sesuai sifat tertentu. Pada contoh
Gambar 13.10c, semua baris dalam tabel Departemen yang berisi informasi yang
berkaitan dengan Departemen Account (Dept ID 4?), dan semua baris dalam tabel
Karyawan yang Gaji lebih besar dari 50K dibatasi.
elemen individu: Skema yang paling sulit untuk menerapkan dan mengelola adalah
satu di mana unsur-unsur individu dapat selektif diklasifikasikan. Dalam contoh
Gambar 13.10d, informasi gaji dan identitas manajer Departemen rekening dibatasi.

Granularity dari skema klasifikasi mempengaruhi cara di mana akses kontrol

diberlakukan. Secara khusus, upaya untuk mencegah kesimpulan tergantung pada
granularity dari klasifikasi. READ ACCESS Untuk akses baca, sistem database perlu
untuk menegakkan sederhana Aturan keamanan (tidak ada membaca). Ini sangat mudah
jika rincian klasifikasi adalah seluruh database atau pada tingkat meja. Pertimbangkan

sekarang database diklasifikasikan oleh kolom (atribut). Misalnya, di Figure13.10b,

misalkan pengguna dengan saja izin terbatas mengeluarkan SQL query berikut:

Query ini mengembalikan data yang hanya terbatas tetapi mengungkapkan

informasi terbatas, yaitu apakah karyawan memiliki lebih besar gaji dari 50K dan, jika
demikian, yang karyawan. Jenis pelanggaran keamanan dapat diatasi dengan
mempertimbangkan tidak hanya data kembali ke pengguna, tetapi juga data yang harus
diakses untuk memenuhi permintaan. Dalam hal ini, query membutuhkan akses ke
atribut Gaji, yang tidak sah untuk pengguna ini; Oleh karena itu, permintaan tersebut
ditolak. Jika klasifikasi adalah dengan baris (tuple) daripada kolom, maka permintaan
sebelumnya tidak menimbulkan masalah inferensi. Gambar 13.10c menunjukkan bahwa
dalam tabel Karyawan, semua baris yang sesuai dengan gaji yang lebih besar dari 50K
dibatasi. Karena semua seperti catatan akan dihapus dari respon terhadap permintaan
sebelumnya, kesimpulan hanya dibahas tidak bisa terjadi. Namun, beberapa informasi
dapat disimpulkan, karena Tanggapan nol menunjukkan baik bahwa gaji di atas 50
dibatasi, atau ada karyawan memiliki gaji lebih besar dari 50K.
Penggunaan klasifikasi oleh baris bukan kolom menciptakan inferensi
lainnyamasalah. Sebagai contoh, misalkan kita tambahkan meja Proyek baru ke
database Figure13.10c terdiri dari atribut Idul Fitri, ProjectID, dan ProjectName, di
mana Bidang Idul Fitri di Karyawan dan Proyek tabel dapat bergabung. Misalkan semua
catatan dalam tabel Proyek yang tidak dibatasi kecuali untuk proyek dengan ProjectID
500 melalui 599. Pertimbangkan permintaan berikut :

Permintaan ini, apabila diberikan, mengembalikan informasi dari tabel Karyawan,

yang terbatas, meskipun mengungkapkan informasi terbatas, yaitu bahwa yang dipilih
karyawan ditugaskan untuk proyek 500. Seperti sebelumnya, sistem database harus

mempertimbangkan bukan hanya data kembali ke pengguna tetapi setiap data yang
harus diakses untuk memenuhi query. Klasifikasi oleh elemen tidak memperkenalkan
pertimbangan baru. Itu Sistem harus mencegah tidak hanya membaca tetapi juga
permintaan yang harus mengakses higherlevel elemen dalam rangka untuk memenuhi
permintaan.
WRITE ACCESS Untuk akses tulis, sistem database perlu untuk memberlakukan
* - Aturan Keamanan (no write down). Tapi ini tidak sesederhana kelihatannya.
Pertimbangkan hal berikut situasi. Misalkan rincian klasifikasi lebih halus dari tingkat
tabel (yaitu, oleh kolom, dengan baris, atau elemen) dan bahwa pengguna dengan izin
rendah (terbatas) meminta penyisipan baris dengan primary key yang sama sebagai
baris yang sudah ada di mana baris atau satu elemen yang berada pada tingkat yang
lebih tinggi. DBMS memiliki dasarnya tiga pilihan :
1. Beritahukan pengguna bahwa baris dengan kunci primer yang sama sudah ada
dan menolak insersi. Hal ini tidak diinginkan karena menginformasikan pengguna
dari keberadaan dari baris-tingkat yang lebih tinggi dengan nilai kunci primer
yang ditentukan.
2. Ganti baris yang ada dengan baris baru diklasifikasikan pada tingkat yang lebih
rendah. ini adalah tidak diinginkan karena akan memungkinkan pengguna untuk
menimpa data tidak terlihat dengan pengguna, sehingga mengorbankan integritas
data.
3. Masukkan baris baru pada tingkat yang lebih rendah tanpa memodifikasi baris
yang ada di tingkat lebih tinggi. Hal ini dikenal sebagai polyinstantiation. Hal ini
untuk menghindari kesimpulan dan masalah integritas data tetapi menciptakan
database dengan entri yang bertentangan. Alternatif yang sama berlaku ketika
pengguna mencoba untuk memperbarui baris daripada menyisipkan baris. Untuk
menggambarkan

pengaruh

polyinstantiation,

pertimbangkan

hal

berikut

permintaan diterapkan Gambar 13.10c oleh pengguna dengan izin rendah (U).

Tabel sudah berisi baris untuk James dengan tingkat gaji yang lebih tinggi, yang
mengharuskan mengelompokkan baris sebagai dibatasi. Tuple baru ini akan memiliki
terbatas klasifikasi. Efek yang sama akan diproduksi oleh update:

Hasilnya adalah meresahkan (Gambar 13.11). Jelas, James hanya dapat memiliki satu
gaji dan karena itu salah satu dari dua baris adalah palsu. Motivasi untuk ini adalah
untuk mencegah kesimpulan. Jika pengguna tak terbatas query gaji James dalam
database asli, permintaan pengguna ditolak dan pengguna bisa menyimpulkan bahwa
gaji lebih besar dari 50K. Dimasukkannya "false" berturut-turut menyediakan bentuk
penutup untuk gaji sebenarnya dari James. Meskipun pendekatan yang mungkin muncul
tidak memuaskan, telah ada sejumlah desain dan implementasi dari polyinstantiation
[BERT95]. Masalah dapat dihindari dengan menggunakan granularity klasifikasi
database atau meja, dan dalam banyak aplikasi, rincian tersebut adalah semua yang
diperlukan.

13.5 TRUSTED COMPUTING AND THE TRUSTED

PLATFORM MODULE
Modul platform terpercaya (TPM) adalah sebuah konsep yang distandarisasi oleh
sebuah industry konsorsium, Trusted Computing Group. TPM adalah modul hardware
yang adalah jantung dari pendekatan hardware / software untuk komputasi yang
terpercaya. Memang, jangka dipercaya komputasi (TC) sekarang digunakan dalam
industri untuk merujuk jenis hardware pendekatan / software. Pendekatan TC
mempekerjakan chip TPM di motherboard komputer pribadi atau kartu pintar atau
terintegrasi ke dalam prosesor utama, bersama-sama dengan hardware dan perangkat
lunak yang dalam arti tertentu telah disetujui atau disertifikasi untuk bekerja dengan
TPM. Kita bisa menjelaskan secara singkat pendekatan TC sebagai berikut. TPM
menghasilkan kunci yang berbagi dengan komponen rentan yang melewatkan data di
sekitar sistem, seperti perangkat penyimpanan, komponen memori, dan audio /
hardware visual. Tombol dapat digunakan untuk mengenkripsi data yang mengalir ke
seluruh mesin. TPM juga bekerja dengan TC-enabled software, termasuk OS dan
aplikasi. Perangkat lunak ini dapat yakin bahwa data yang diterima dapat dipercaya, dan
sistem dapat yakin bahwa perangkat lunak itu sendiri adalah dapat dipercaya. Untuk
mencapai fitur ini, TC menyediakan tiga layanan dasar: dikonfirmasi boot, sertifikasi,
dan enkripsi.
Authenticated Boot Service
Layanan boot dikonfirmasi bertanggung jawab untuk booting seluruh operasi
sistem secara bertahap dan meyakinkan bahwa setiap bagian dari OS, seperti yang
dimuat, adalah Versi yang telah disetujui untuk digunakan. Biasanya, boot OS dimulai
dengan sepotong kecil kode di Boot ROM. Karya ini membawa kode lebih dari Blok
Boot pada hard drive dan transfer eksekusi untuk kode tersebut. Proses ini terus
berlanjut dengan lebih dan lebih besar blok dari kode OS yang dibawa sampai seluruh
OS prosedur boot selesai dan OS penduduk boot. Pada setiap tahap, yang Cek hardware
TC bahwa perangkat lunak yang sah telah dibawa. Hal ini dapat dilakukan dengan

memverifikasi tanda tangan digital yang berhubungan dengan perangkat lunak. TPM
menyimpan tamper-jelas log dari proses loading, menggunakan fungsi hash kriptografi
untuk mendeteksi gangguan dengan log.
Certification Service
Setelah konfigurasi dicapai dan dicatat oleh TPM, TPM dapat mengesahkan konfigurasi
kepada pihak lain. TPM dapat menghasilkan sertifikat digital dengan penandatanganan
deskripsi diformat dari informasi konfigurasi menggunakan TPM itu pribadi kunci.
Dengan demikian, pengguna lain, baik pengguna lokal atau sistem remote, dapat
memiliki keyakinanbahwa konfigurasi tidak berubah sedang digunakan karena,
1. TPM ini dianggap dapat dipercaya. Kita tidak perlu sertifikasi lebih lanjut dari TPM
sendiri.
2. Hanya TPM memiliki kunci pribadi ini TPM ini. Sebuah penerima konfigurasi dapat
menggunakan kunci publik TPM untuk memverifikasi tanda tangan (Gambar 2.7b).
Encryption Service
Layanan enkripsi memungkinkan enkripsi data sedemikian rupa bahwa data yang
dapat didekripsi hanya berdasarkan sebuah mesin tertentu dan hanya jika mesin yang
ada di beberapa konfigurasi. Ada beberapa aspek layanan ini. Pertama, TPM
mempertahankan master kunci rahasia unik untuk mesin ini. Dari kunci ini, TPM
menghasilkan kunci enkripsi rahasia untuk setiap konfigurasi yang mungkin dari mesin
itu. Jika data yang dienkripsi saat mesin dalam satu konfigurasi, Data hanya dapat
didekripsi menggunakan konfigurasi yang sama. Jika konfigurasi yang berbeda dibuat
pada mesin, konfigurasi baru tidak akan dapat mendekripsi Data dienkripsi dengan
konfigurasi yang berbeda. Skema ini dapat diperpanjang ke atas, seperti yang dilakukan
dengan sertifikasi. Oleh karena itu, mungkin untuk menyediakan kunci enkripsi untuk
aplikasi agar aplikasi bisa Data mengenkripsi, dan dekripsi hanya dapat dilakukan oleh
versi yang diinginkan dari yang diinginkan aplikasi yang berjalan pada versi yang
diinginkan dari OS yang diinginkan.

TPM Functions
Gambar 13.12, berdasarkan spesifikasi TPM terbaru, adalah diagram blok dari
komponen fungsional dari TPM. Ini adalah sebagai berikut:
I / O: Semua perintah masuk dan keluar melalui I / O komponen, yang menyediakan
komunikasi dengan komponen TPM lainnya.
Cryptographic co-processor: Termasuk prosesor yang khusus untuk enkripsi dan
pengolahan terkait. Algoritma kriptografi tertentu dilaksanakan oleh komponen ini
termasuk RSA enkripsi / dekripsi, RSA berbasis tanda tangan digital, dan enkripsi
simetris.
Generasi Key: Menciptakan RSA publik / pasangan kunci pribadi dan kunci simetris.
mesin HMAC: Algoritma ini digunakan dalam berbagai protokol otentikasi.
Nomor Acak Generator (RNG): Komponen ini menghasilkan angka acak digunakan
dalam berbagai algoritma kriptografi, termasuk pembangkitan kunci, acak nilai dalam
tanda tangan digital, dan nonces. Sebuah Nonce adalah nomor acak digunakan sekali,
seperti dalam protokol tantangan. Ping menggunakan sumber hardware keacakan
(produsen tertentu) dan tidak bergantung pada algoritma perangkat lunak yang
menghasilkan nomor acak semu.

Protected Storage
Untuk memberikan beberapa firasat untuk pengoperasian sistem TC / TPM, kita melihat
fungsi penyimpanan dilindungi. TPM menghasilkan dan menyimpan sejumlah enkripsi
kunci dalam hirarki kepercayaan. Pada akar hirarki adalah kunci root penyimpanan yang
dihasilkan oleh TPM dan dapat diakses hanya untuk penggunaan TPM ini. Dari ini
kunci lain kunci dapat dihasilkan dan dilindungi oleh enkripsi dengan kunci lebih dekat
dengan akar hirarki. Sebuah fitur penting dari Platform Terpercaya adalah bahwa objek
yang dilindungi TPM dapat akan "disegel" ke keadaan software tertentu dalam platform.
Ketika TPM dilindungi objek dibuat, pencipta menunjukkan status perangkat lunak
yang harus ada jika rahasia adalah untuk diungkapkan. Ketika TPM unwraps objek yang
dilindungi TPM (dalam TPM dan tersembunyi dari pandangan), TPM memeriksa bahwa
negara perangkat lunak saat ini sesuai dengan negara perangkat lunak yang ditunjukkan.
Jika mereka cocok, izin TPM akses ke rahasia. Jika mereka tidak cocok, TPM menolak
akses ke rahasia.
1. Kunci simetris yang digunakan untuk mengenkripsi file tersebut disimpan dengan file
tersebut. Kunci itu sendiri dienkripsi dengan kunci lain yang TPM memiliki akses. Itu
kunci dilindungi disampaikan kepada TPM dengan permintaan untuk mengungkapkan
kunci aplikasi.
2. Terkait dengan kunci dilindungi adalah spesifikasi perangkat keras / lunak
konfigurasi yang mungkin memiliki akses ke kunci. TPM memverifikasi bahwa
konfigurasi saat sesuai dengan konfigurasi yang diperlukan untuk mengungkapkan
kunci. Selain itu, aplikasi yang meminta harus khusus berwenang untuk mengakses
kunci. TPM menggunakan protokol otorisasi untuk memverifikasi otorisasi.
3. Jika konfigurasi saat diperbolehkan akses ke kunci dilindungi, maka TPM
mendekripsi kunci dan dibagikan pada aplikasi.
4. Aplikasi ini menggunakan kunci untuk mendekripsi file. Aplikasi ini dipercaya untuk
maka aman membuang kuncinya.

Enkripsi file berlangsung dalam hitungan analog. Dalam kasus terakhir ini, proses
meminta kunci simetrik untuk mengenkripsi file. TPM kemudian memberikan versi
terenkripsi kunci untuk disimpan dengan file tersebut.
13.6 COMMON CRITERIA FOR INFORMATION TECHNOLOGY
SECURITY EVALUATION
Usaha yang dilakukan oleh Badan Keamanan Nasional dan instansi pemerintah
AS untuk mengembangkan persyaratan dan kriteria evaluasi untuk sistem dipercaya
menghasilkan dalam publikasi Kriteria Evaluasi Sistem Komputer Trusted (TCSEC),
informal dikenal sebagai Kitab Orange, pada awal tahun 1980. Ini difokuskan terutama
pada melindungi kerahasiaan informasi. Selanjutnya, negara-negara lain mulai bekerja
untuk mengembangkan kriteria berdasarkan TCSEC tapi yang lebih fleksibel dan
mudah beradaptasi sifat berkembang dari IT. Proses penggabungan, memperluas, dan
mengkonsolidasikan berbagai upaya akhirnya menghasilkan pengembangan Common
Kriteria di akhir 1990-an. Common Criteria (CC) untuk Teknologi Informasi dan
Evaluasi Keamanan adalah standar ISO untuk menentukan persyaratan keamanan dan
mendefinisikan kriteria evaluasi. Tujuan dari standar ini adalah untuk memberikan lebih

besar kepercayaan dalam keamanan produk IT sebagai akibat dari tindakan resmi yang
diambil selama proses pengembangan, evaluasi, dan operasi produk ini.
Requirements
CC mendefinisikan seperangkat persyaratan keamanan potensial untuk digunakan dalam
evaluasi. Target jangka evaluasi (TOE) mengacu pada bagian produk atau sistem yang
tunduk pada evaluasi. Persyaratan terbagi dalam dua kategori:
persyaratan Fungsional: Tentukan perilaku keamanan yang diinginkan. dokumen CC
membangun satu set komponen fungsional keamanan yang menyediakan cara standar
mengungkapkan persyaratan keamanan fungsional untuk TOE a.
persyaratan Jaminan: Dasar memperoleh keyakinan bahwa keamanan diklaim
langkah-langkah yang efektif dan diterapkan dengan benar. Dokumen CC membangun
seperangkat komponen jaminan yang menyediakan cara standar mengekspresikan
persyaratan jaminan untuk TOE a.

Profiles and Targets

CC juga mendefinisikan dua jenis dokumen yang dapat dihasilkan dengan
menggunakan Kebutuhan CC-dimaksud.
profil Perlindungan (PP): Tentukan set implementasi-independen persyaratan
keamanan dan tujuan untuk kategori produk atau sistem yang memenuhi kebutuhan
konsumen yang sama untuk keamanan IT. Sebuah PP dimaksudkan untuk dapat
digunakan kembali dan mendefinisikan persyaratan yang diketahui berguna dan efektif
dalam mencapai tujuan diidentifikasi. PP Konsep telah dikembangkan untuk
mendukung definisi standar fungsional dan sebagai bantuan untuk merumuskan
spesifikasi pengadaan. PP mencerminkan keamanan pengguna persyaratan.

Security targets (STs): Contain the IT security objectives and requirements of a

specific identified TOE and defines the functional and assurance measures offered by
that TOE to meet stated requirements. The ST may claim conformance to one or more
PPs and forms the basis for an evaluation. The ST is supplied by a vendor or developer.

Gambar 13.15 menunjukkan apa yang disebut dalam dokumen CC sebagai

keamanan Kebutuhan paradigma fungsional. Pada dasarnya, ilustrasi ini didasarkan
pada Monitor konsep referensi tetapi memanfaatkan terminologi dan desain filosofi CC.
Example of a Protection Profile
Profil perlindungan bagi kartu pintar, yang dikembangkan oleh Smart Card Keamanan
Kelompok pengguna, memberikan contoh sederhana PP a. PP ini menjelaskan
keamanan TI persyaratan untuk kartu cerdas untuk digunakan sehubungan dengan
aplikasi sensitif, seperti industri perbankan sistem pembayaran keuangan. Tingkat
jaminan untuk ini PP adalah EAL 4, yang dijelaskan dalam ayat berikut. PP daftar
ancaman yang harus ditangani oleh produk yang mengklaim untuk mematuhi PP ini.
Ancaman meliputi:
Fisik probing: Semoga memerlukan membaca data dari TOE melalui teknik umumnya
digunakan dalam analisis kegagalan IC dan IC upaya reverse engineering.
masukan tidak valid: masukan tidak valid dapat berupa operasi yang tidak diformat
benar, permintaan informasi di luar batas daftar, atau upaya untuk menemukan dan
menjalankan perintah yang tidak berdokumen. Hasil serangan tersebut mungkin
kompromi dalam fungsi keamanan, generasi kesalahan dieksploitasi dalam operasi, atau
rilis data dilindungi.

 Linkage dari beberapa operasi: Seorang penyerang dapat mengamati beberapa

penggunaan sumber daya atau layanan dan, dengan menghubungkan pengamatan ini,
menyimpulkan informasi bahwa yang mungkin mengungkapkan data fungsi keamanan.

Audit: Sistem harus menyediakan sarana rekaman yang dipilih securityrelevant

peristiwa, sehingga dapat membantu administrator dalam mendeteksi potensi serangan
atau misconfiguration fitur sistem keamanan yang akan meninggalkannya rentan
terhadap serangan.
Kesalahan penyisipan: Sistem harus tahan terhadap diulang menyelidik melalui
penyisipan data yang salah.
Informasi kebocoran: Sistem harus menyediakan sarana pengendalian dan membatasi
kebocoran informasi dalam sistem sehingga tidak ada informasi yang berguna terungkap
selama kekuasaan, tanah, jam, reset, atau I / O baris. Persyaratan keamanan disediakan
untuk menggagalkan ancaman spesifik dan untuk mendukung kebijakan khusus di
bawah asumsi tertentu. PP mencantumkan persyaratan tertentu dalam tiga bidang
umum: Kebutuhan fungsional keamanan TOE, jaminan keamanan TOE Kebutuhan, dan
persyaratan keamanan untuk lingkungan TI.
PP mendefinisikan 24 Kebutuhan jaminan keamanan dari kelas yang tersedia
persyaratan jaminan keamanan (Tabel 13.4). Persyaratan ini dipilih untuk menunjukkan
Kualitas desain produk dan konfigurasi

 Bahwa perlindungan yang memadai disediakan selama desain dan implementasi

produk
Bahwa pengujian vendor produk memenuhi parameter tertentu
Bahwa fungsi keamanan tidak terganggu selama pengiriman produk
Bahwa bimbingan pengguna, termasuk manual produk yang berkaitan dengan
instalasi, pemeliharaan dan penggunaan, yang berkualitas tertentu dan kesesuaian
PP juga mencantumkan persyaratan keamanan lingkungan TI. Ini mencakup topik
berikut:
distribusi kunci kriptografi
kehancuran kunci kriptografi
peran Keamanan
Bagian akhir dari PP (termasuk lampiran) adalah pemikiran yang panjang untuk semua
pilihan dan definisi dalam PP. PP merupakan upaya industri-lebar dirancang untuk
menjadi realistis dalam kemampuannya yang harus dipenuhi oleh berbagai produk
dengan varietas mekanisme internal dan pendekatan implementasi.
13.7 ASSURANCE AND EVALUATION
Keamanan NIST Komputer Handbook [NIST95] mencirikan jaminan dalam cara
sebagai berikut: "jaminan keamanan adalah tingkat kepercayaan seseorang bahwa
kontrol keamanan beroperasi dengan benar dan melindungi sistem sebagaimana
dimaksud. Jaminan tidak, bagaimanapun, jaminan mutlak bahwa tindakan bekerja
sebagaimana mestinya. "Sebagai dengan aspek lain dari keamanan komputer, sumber
daya yang ditujukan untuk jaminan harus mengalami semacam analisis biaya-manfaat
untuk menentukan apa jumlah usaha adalah wajar untuk tingkat jaminan yang
diinginkan.
Target Audience
Desain tindakan jaminan bergantung sebagian pada target audiens untuk langkahlangkah ini. Artinya, dalam mengembangkan tingkat kepercayaan dalam langkahlangkah keamanan , kita perlu menentukan apa yang individu atau kelompok memiliki

derajat yang kepercayaan. Dokumen CC pada jaminan [CCPS09c] daftar target berikut
penonton:
Konsumen: Pilih fitur keamanan dan fungsi untuk sistem dan menentukan
tingkat diperlukan jaminan keamanan.
Pengembang: Menanggapi persyaratan keamanan konsumen aktual atau yang
dirasakan; menginterpretasikan laporan dari persyaratan jaminan; dan
menentukan jaminan pendekatan dan tingkat usaha.
Evaluator: Gunakan kebutuhan jaminan sebagai pernyataan wajib kriteria
evaluasi ketika mengevaluasi fitur keamanan dan kontrol.
Scope of Assurance
Penawaran jaminan dengan fitur keamanan produk IT, seperti komputer, basis data
sistem manajemen, sistem operasi, dan sistem lengkap. jaminan berlaku untuk aspekaspek berikut sistem:

Persyaratan: Kategori ini mengacu pada persyaratan keamanan untuk produk

Kebijakan Keamanan: Berdasarkan kebutuhan, kebijakan keamanan dapat

didefinisikan

Desain produk: Berdasarkan Kebutuhan dan kebijakan keamanan

pelaksanaan Produk: Berdasarkan desain

Sistem operasi: Termasuk penggunaan biasa ditambah pemeliharaan

Sesuatu yang agak berbeda pada unsur-unsur jaminan disediakan di

[CHOK92]. Laporan ini didasarkan pada pengalaman dengan Orange Book evaluasi
tetapi relevan dengan upaya pengembangan produk yang terpercaya saat ini. Jaminan
penulis views sebagai meliputi persyaratan sebagai berikut:
Arsitektur Sistem: Alamat baik tahap pengembangan sistem dan fase operasi sistem.
Contoh teknik untuk meningkatkan tingkat jaminan selama fase pengembangan meliputi
desain software modular, layering, dan abstraksi data / informasi bersembunyi. Contoh
operasi fase isolasi bagian dipercaya sistem dari proses pengguna.
Integritas Sistem: Alamat operasi yang benar dari perangkat keras sistem dan firmware
dan biasanya puas dengan menggunakan periodik perangkat lunak diagnostik.

 pengujian Sistem: Memastikan bahwa fitur keamanan telah diuji secara menyeluruh.
Ini termasuk pengujian operasi fungsional, pengujian persyaratan keamanan, dan
pengujian mungkin penetrasi.
Desain spesifikasi dan verifikasi: Alamat kebenaran system desain dan implementasi
sehubungan dengan kebijakan sistem keamanan. Idealnya,
metode formal verifikasi dapat digunakan.
analisis saluran Terselubung: Jenis analisis mencoba untuk mengidentifikasi setiap
potensi berarti untuk melewati kebijakan keamanan dan cara-cara untuk mengurangi
atau menghilangkan seperti kemungkinan.
manajemen fasilitas Terpercaya: Penawaran dengan sistem administrasi. Salah satu
pendekatan adalah memisahkan peran operator sistem dan administrator keamanan.
Lain Pendekatan adalah spesifikasi rinci dari kebijakan dan prosedur dengan mekanisme
untuk diteliti kembali.
pemulihan Terpercaya: Menyediakan untuk operasi yang benar dari fitur keamanan
setela Sistem pulih dari kegagalan, crash, atau insiden keamanan.
distribusi Terpercaya: Memastikan bahwa dilindungi hardware, firmware, dan
perangkat lunak tidak pergi melalui modifikasi yang tidak sah selama transit dari
vendor untuk pelanggan.
manajemen konfigurasi: Persyaratan disertakan untuk konfigurasi kontrol, audit,
manajemen, dan akuntansi. Jadi kita melihat bahwa penawaran jaminan dengan desain,
implementasi, dan operasi
sumber daya yang dilindungi dan fungsi keamanan mereka dan prosedur. Itu penting
untuk dicatat jaminan bahwa adalah proses, bukan suatu pencapaian. Artinya, jaminan
harus menjadi kegiatan yang sedang berlangsung, termasuk pengujian, audit, dan
ulasan.
Common Criteria Evaluation Assurance Levels

Konsep jaminan evaluasi adalah satu sulit untuk dijabarkan. Selanjutnya, gelar
jaminan yang diperlukan bervariasi dari satu konteks dan satu fungsi yang lain. Untuk
struktur kebutuhan untuk jaminan, CC mendefinisikan skala untuk jaminan Peringkat

terdiri dari tujuh tingkat jaminan evaluasi (eals) mulai dari yang paling kekakuan dan
lingkup bukti jaminan (EAL 1) sampai yang paling (EAL 7). Tingkat adalah sebagai
berikut:
EAL 1: fungsional diuji: Untuk lingkungan di mana ancaman keamanan tidak
dianggap serius. Ini melibatkan pengujian produk independen tanpa masukan dari
pengembang produk. Tujuannya adalah untuk memberikan tingkat kepercayaan operasi
yang benar.
EAL 2: struktural diuji: Termasuk review dari desain tingkat tinggi yang disediakan
oleh pengembang produk. Juga, pengembang harus melakukan kerentanan analisis
untuk kekurangan terkenal. Tujuannya adalah untuk memberikan tingkat rendah hingga
sedang dari independen terjamin keamanan.
EAL 3: metodis diuji dan diperiksa: Membutuhkan fokus pada keamanan fitur. Ini
termasuk persyaratan bahwa desain terpisah-terkait keamanan komponen dari orangorang yang tidak; bahwa desain menentukan bagaimana keamanan adalah ditegakkan;
dan pengujian yang didasarkan baik pada interface dan highlevel desain, daripada
pengujian kotak hitam hanya didasarkan pada antarmuka. Saya t berlaku di mana
kebutuhannya adalah untuk tingkat moderat independen keamanan terjamin, dengan
penyelidikan menyeluruh dari TOE dan perkembangannya tanpa menimbulkan biaya
rekayasa ulang substansial.
EAL 4: metodis dirancang, diuji, dan Ulasan: Membutuhkan tingkat rendah sebagai
serta spesifikasi desain tingkat tinggi. Mensyaratkan bahwa spesifikasi antarmuka
lengkap. Membutuhkan model abstrak yang secara eksplisit mendefinisikan keamanan
untuk produk. Membutuhkan analisis kerentanan independen. Hal ini berlaku
pada mereka keadaan di mana pengembang atau pengguna memerlukan moderat
untuk tingkat keamanan yang tinggi secara independen terjamin di komoditas
konvensional
Jari-jari kaki, dan ada kemauan untuk dikenakan beberapa keamanan khusus tambahan
biaya rekayasa
EAL 5: semiformally dirancang dan diuji: Menyediakan analisis yang mencakup
semua pelaksanaan. Jaminan ini dilengkapi dengan model formal dan
presentasi semiformal dari fungsional spesifikasi dan tingkat tinggi desain

dan demonstrasi semiformal korespondensi. Pencarian untuk kerentanan

harus memastikan ketahanan terhadap penyerang penetrasi dengan serangan moderat
potensi. Analisis saluran rahasia dan desain modular juga diperlukan.
EAL 6: desain semiformally diverifikasi dan diuji: Izin pengembang untuk
mendapatkan jaminan yang tinggi dari penerapan teknik rekayasa keamanan khusus
dalam lingkungan pengembangan yang ketat, dan untuk menghasilkan TOE premium
untuk melindungi aset bernilai tinggi terhadap risiko yang signifikan. Pencarian
independen untuk kerentanan harus memastikan ketahanan terhadap penyerang
penetrasi dengan tinggi potensi serangan.
EAL 7: desain secara formal diverifikasi dan diuji: Model formal ditambah oleh
presentasi resmi dari spesifikasi fungsional dan tingkat tinggi desain, menunjukkan
korespondensi. Bukti pengembang "kotak putih" pengujian dari internal dan konfirmasi
independen lengkap hasil uji pengembang dibutuhkan. Kerumitan desain harus
diminimalkan.
Evaluation Process
Tujuan dari evaluasi produk IT, TOE sebuah, terhadap standar komputasi
terpercaya adalah untuk memastikan bahwa fitur keamanan dalam pekerjaan TOE benar
dan efektif, dan yang tidak menunjukkan kerentanan dieksploitasi. Proses evaluasi
dilakukan baik di sejajar dengan, atau setelah, pengembangan TOE, tergantung pada
tingkat jaminan wajib. Semakin tinggi tingkat, semakin besar kekakuan yang
dibutuhkan oleh proses dan semakin banyak waktu dan biaya yang akan dikenakan.
Input prinsip untuk evaluasi adalah target keamanan, satu set bukti tentang TOE, dan
TOE yang sebenarnya. yang diinginkan Hasil dari proses evaluasi adalah untuk
mengkonfirmasi bahwa target keamanan puas untuk TOE, dikonfirmasi oleh bukti yang
terdokumentasi dalam laporan evaluasi teknis.
Evaluasi melibatkan sejumlah pihak:
Sponsor: Biasanya baik pelanggan atau vendor produk yang Evaluasi diperlukan.
Sponsor menentukan target keamanan yang produk harus memenuhi.

 Pengembang: Memiliki untuk memberikan bukti yang sesuai pada proses yang
digunakan untuk merancang, menerapkan, dan menguji produk untuk memungkinkan
evaluasi.
Evaluator: Melakukan pekerjaan evaluasi teknis, menggunakan bukti yang diberikan
oleh pengembang, dan pengujian tambahan produk, untuk mengkonfirmasi bahwa itu
memenuhi persyaratan fungsional dan jaminan yang ditetapkan dalam target keamanan.
Di banyak negara, tugas mengevaluasi produk terhadap komputasi terpercaya standar
didelegasikan kepada satu atau lebih didukung pemasok komersial.
Sertifikasi: Instansi pemerintah yang memonitor proses evaluasi dan kemudian
menyatakan bahwa produk sebagai berhasil dievaluasi. Sertifikasi umumnya mengelola
daftar produk dievaluasi, yang dapat dikonsultasikan dengan pelanggan.
Proses evaluasi memiliki tiga fase besar:
1. Persiapan: Melibatkan kontak awal antara sponsor dan pengembang produk, dan
evaluator yang akan menilai itu. Ini akan mengkonfirmasi bahwa sponsor dan
pengembang cukup siap untuk melakukan evaluasi dan akan termasuk review dari target
keamanan dan kiriman evaluasi kemungkinan lainnya. Ini menyimpulkan dengan daftar
kiriman evaluasi dan penerimaan costing proyek secara keseluruhan dan jadwal.
2. Melakukan evaluasi: Sebuah proses terstruktur dan formal di mana evaluator
melakukan serangkaian kegiatan yang ditentukan oleh CC. Ini termasuk meninjau
kiriman yang disediakan oleh sponsor dan pengembang, dan tes lainnya produk, untuk
mengkonfirmasi memenuhi target keamanan. Selama proses ini, masalah dapat
diidentifikasi dalam produk, yang dilaporkan kembali ke pengembang untuk koreksi.
3. Kesimpulan: evaluator memberikan laporan teknis evaluasi akhir untuk
lembaga sertifikasi untuk penerimaan. The sertifikasi menggunakan laporan ini, yang
mungkin berisi informasi rahasia, untuk memvalidasi proses evaluasi dan menyiapkan
Laporan sertifikasi publik. Laporan sertifikasi kemudian terdaftar di relevan daftar
produk dievaluasi.

13.8 RECOMMENDED READING AND WEB SITES

Rekomendasi situs Web:

Trusted Computing Grup: kelompok Penjual terlibat dalam mengembangkan da
mempromosikan dipercaya standar komputer. Situs termasuk kertas putih, spesifikasi,
dan link penjual.
Kriteria umum Portal: Web site resmi dari proyek kriteria umum.