Teknologi Pemantauan Integritas File Manakah yang Terbaik untuk FIM?

Teknologi Pemantauan Integritas File Manakah yang Terbaik untuk FIM?

pengantar

Dalam pasar teknologi FIM ada pilihan yang harus dibuat. Berbasis agen atau tanpa agen adalah pilihan yang paling umum, tetapi meskipun demikian ada solusi SIEM, dan FIM ‘pure-play’ untuk dipilih.

FIM – Agen atau Tanpa Agen

Tidak pernah ada keuntungan yang jelas untuk FIM berbasis agen atau tanpa agen. Ada keseimbangan yang dapat ditemukan antara FIM tanpa agen dan operasi FIM berbasis agen yang bisa dibilang unggul, menawarkan

Deteksi perubahan waktu nyata – pemindai FIM tanpa agen hanya dapat efektif berdasarkan jadwal, biasanya sekali setiap hari
Data dasar yang disimpan secara lokal yang berarti hanya diperlukan satu kali pemindaian penuh, sementara pemindai kerentanan akan selalu perlu membuat dasar ulang dan hash setiap file pada sistem setiap kali memindai
Keamanan yang lebih besar dengan mandiri, sedangkan solusi FIM tanpa agen akan memerlukan logon dan akses jaringan ke host yang sedang diuji

Sebaliknya, pendukung pemindai kerentanan Tanpa Agen akan menyebutkan keunggulan teknologi mereka dibandingkan sistem FIM berbasis agen, termasuk

Aktif dan berjalan dalam hitungan menit, tanpa perlu menerapkan dan memelihara agen di titik akhir, membuat sistem tanpa agen lebih mudah dioperasikan
Tidak perlu memuat perangkat lunak pihak ketiga apa pun ke titik akhir, pemindai tanpa agen 100% mandiri
Perangkat asing atau baru yang ditambahkan ke jaringan akan selalu ditemukan oleh pemindai tanpa agen, sedangkan sistem berbasis agen hanya efektif jika agen telah disebarkan ke host yang dikenal

Untuk alasan ini tidak ada pemenang langsung dari argumen ini dan biasanya, sebagian besar organisasi menjalankan kedua jenis teknologi untuk mendapatkan keuntungan dari semua keuntungan yang ditawarkan.

Menggunakan SIEM untuk FIM

Menggunakan teknologi SIEM jauh lebih mudah untuk ditangani. Mirip dengan argumen tanpa agen, sistem SIEM dapat dioperasikan tanpa memerlukan perangkat lunak agen apa pun di titik akhir, menggunakan WMI atau kemampuan syslog asli dari host. Namun ini biasanya dilihat sebagai solusi yang lebih rendah dari paket SIEM berbasis agen. Agen akan memungkinkan fungsi keamanan tingkat lanjut seperti hashing dan pemantauan log waktu nyata.

Untuk FIM, semua vendor SIEM akan mengandalkan kombinasi audit akses objek host, dikombinasikan dengan baseline terjadwal dari sistem file. Audit aktivitas sistem file dapat memberikan kemampuan FIM waktu nyata, tetapi akan membutuhkan sumber daya yang jauh lebih tinggi dari host untuk mengoperasikannya daripada agen jinak. Audit asli OS tidak akan memberikan nilai hash untuk file sehingga deteksi forensik Trojan tidak dapat dicapai sejauh agen FIM perusahaan akan melakukannya.

Vendor SIEM telah bergerak untuk mengatasi masalah ini dengan menyediakan baseline terjadwal dan fungsi hash menggunakan agen. Hasilnya adalah solusi yang paling buruk dari semua opsi – agen harus diinstal dan dipelihara, tetapi tanpa manfaat dari agen waktu nyata!

Ringkasan

Singkatnya, SIEM paling baik digunakan untuk analisis log peristiwa dan FIM paling baik digunakan untuk Pemantauan Integritas File. Apakah Anda kemudian memutuskan untuk menggunakan solusi FIM berbasis agen atau sistem tanpa agen lebih sulit. Kemungkinan besar, kesimpulannya adalah bahwa kombinasi keduanya akan menjadi satu-satunya solusi lengkap.

PCI DSS Versi 3.0: Standar Baru Tapi Masalah Sama?

pengantar

“Data pemegang kartu terus menjadi sasaran para penjahat. Kurangnya pendidikan dan kesadaran seputar keamanan pembayaran dan penerapan dan pemeliharaan Standar PCI yang buruk menyebabkan banyak pelanggaran keamanan yang terjadi hari ini” PCI SSC ‘Sorotan Perubahan PCI DSS 3.0’ – Agustus 2013

Pencurian data kartu masih terjadi sehingga revisi ketiga dari Standar Keamanan Data PCI adalah peluncuran ulang sekaligus perombakan.

Banyak organisasi – bahkan Merchant Level 1 – belum sepenuhnya menerapkan semua persyaratan PCI DSS V2 atau versi standar sebelumnya, sehingga mata mungkin akan melihat versi baru dari standar yang belum dikuasai sebelumnya. formulir.

Versi baru ini lebih tentang penyempurnaan dan klarifikasi daripada pengenalan teknik atau teknologi baru untuk membantu melindungi terhadap pencurian data kartu, tetapi sementara kerugian melalui penipuan kartu masih meningkat, jelas bahwa ada sesuatu yang harus diubah.

Seberapa besar masalahnya?

Dari segi kerugian yang dialami, Anda dapat melihat mengapa merek kartu, penerbit dan bank masih sangat membutuhkan perawatan dan perhatian yang lebih baik untuk diterapkan pada nomor kartu mereka. $11 Miliar hilang tahun lalu dan jumlah itu meningkat setiap tahun. Mengingat bahwa nilai total transaksi pembayaran kartu sekarang melebihi $21 Triliun per tahun, masih banyak uang yang dihasilkan dari penyediaan produk pembayaran yang dijamin cepat. Namun, inisiatif apa pun yang mengurangi kerugian $11 Miliar itu layak untuk beberapa waktu dan perhatian. Dari Laporan Nilsson terbaru tentang penipuan kartu:

“Kerugian penerbit kartu terjadi terutama pada titik penjualan dari kartu palsu. Penerbit menanggung kerugian penipuan jika mereka memberikan otorisasi kepada pedagang untuk menerima pembayaran. Kerugian pedagang dan pengakuisisi terjadi terutama pada transaksi card-not-present (CNP) di Web, di pusat panggilan, atau melalui pesanan pos”

Kepatuhan PCI bukan hanya masalah merek kartu yang mengakibatkan organisasi Anda harus menghabiskan waktu dan uang, tetapi merupakan cara untuk melindungi organisasi Anda secara langsung dari risiko serius. Ini bukan hanya risiko finansial: faktor lain seperti perlindungan merek dan kepercayaan pelanggan juga hilang saat terjadi pelanggaran.

PCI DSS Versi 3.0 – Tongkat atau Putar?

Versi baru dari PCI DSS tidak tersedia hingga awal bulan depan, jadi ini adalah pengungkapan awal dari apa yang merupakan pengerjaan ulang standar yang cukup ekstensif. Sebagian besar persyaratan dibawa dengan beberapa penyesuaian dan tambahan yang akan dibahas nanti tetapi ada juga tingkat penyempurnaan dalam kata-kata di seluruh standar.

Maksud keseluruhannya adalah bahwa standar tersebut bertujuan untuk mempromosikan pemikiran tentang keamanan data pemegang kartu daripada sekadar mendorong kepatuhan terhadap standar. Dewan Standar Keamanan, tentu saja, ingin agar praktik terbaik keamanan diadopsi dan dipraktikkan sebagai masalah rutin daripada hanya sebagai acara ‘setahun sekali, dorongan besar-untuk-menjaga-an-auditor-senang’. – seolah-olah ada yang akan melakukan itu? J

Item baru akan dianggap sebagai “praktik terbaik” hingga Juni 2015, setelah itu akan menjadi persyaratan resmi. Lebih lanjut, setiap organisasi yang mematuhi PCI DSS 2.0 dapat bertahan hingga Januari 2015 sebelum mengadopsi versi baru DSS.

Apa yang Berubah di PCI DSS V3?

Jadi apa saja perubahan spesifik atau persyaratan baru? Ada perubahan kata-kata di seluruh untuk mendorong fokus yang lebih rutin pada persyaratan PCI DSS, tetapi ada beberapa perubahan detail dan bahasa klarifikasi yang dapat kami soroti di sini.

Persyaratan 2: Manajemen Kerentanan dan Pengerasan

Persyaratan 2 selalu mengamanatkan kebutuhan untuk memperkuat konfigurasi server, EPOS, dan perangkat jaringan, menghapus pengaturan default seminimal mungkin, tetapi mendorong adopsi daftar periksa pengerasan NIST atau CIS. Perubahan detail untuk Versi 3 membuat frasa sandi dapat diterima. Frasa sandi menjadi alternatif yang baik untuk kata sandi yang panjang dan rumit, lebih mudah untuk dikelola dan diingat, tetapi dengan perlindungan keamanan yang setara. Pengerasan, manajemen kerentanan, dan kontrol konfigurasi adalah salah satu ‘tangan kuat’ NNT, dan detail lebih lanjut tersedia di situs web kami.

Persyaratan 6: Kembangkan Aplikasi Aman

6.5.6 – Penanganan PAN dan SAD yang Tidak Aman di Memori

Sama seperti Buffer Overflow Protection dan mitigasi SQL Injection Attack, ini merupakan himbauan bagi desainer aplikasi untuk waspada. Persyaratan ini ditujukan secara khusus untuk melindungi dari malware pengikis memori, dan untuk merancang fitur keamanan sehingga CHD dan Data Otentikasi Aman terlindungi.

Panggilannya adalah untuk mengambil langkah mundur dan mempertimbangkan untuk menggunakan fitur terprogram yang mencegah aplikasi yang tidak sah mengakses memori (beberapa lingkungan pengembangan lebih baik daripada yang lain untuk ini). Apa yang terjadi pada PJK atau SAD selama program macet? (Banyak serangan berupa gangguan pada aplikasi untuk membuatnya ‘batuk’ atau membuang data). Jika memungkinkan, apakah aplikasi dapat menghapus data sepenuhnya saat tidak diperlukan lagi?

Dengan kata lain, ini sebagian merupakan tantangan pengembangan aplikasi (karenanya menjadi item Persyaratan 6) tetapi juga masalah perlindungan malware. Penyerang akan membutuhkan Trojan atau Malware lain untuk mengikis memori, sehingga FIM tingkat rendah dapat berperan dalam perlindungan kode penjaminan. Singkatnya, bersiaplah untuk beberapa pertanyaan yang lebih menantang dari QSA Anda, jadi tanyakan kepada penyedia aplikasi EPoS/eCommerce Anda atau tim pengembangan internal sekarang apa pendapat mereka tentang persyaratan ini. Secara potensial ini juga akan terbukti menjadi persyaratan yang sulit bagi QSA untuk divalidasi.

6.5.11 – Otentikasi Rusak dan Manajemen Sesi

Detail persyaratan baru ini tampaknya meminta pedagang untuk mengurangi risiko yang terkait dengan pengambilalihan sisi klien: asumsikan bahwa klien tepercaya dapat menjadi vektor serangan. Serangan sisi klien adalah salah satu cara paling umum peretas mendapatkan akses ke data dan seperti biasa, peretas akan mencari tautan terlemah. Persyaratan juga bermaksud untuk fokus pada serangan gaya man-in-the-middle juga.

Menariknya ada juga saran bahwa pedagang yang menggunakan layanan re-directed (seperti Worldpay misalnya) mungkin juga perlu memeriksa operasi manajemen sesi aplikasi mereka untuk kerentanan.

Terutama ini adalah masalah desain aplikasi (Persyaratan 6 awalan adalah hadiah J ). Ini menyoroti keseimbangan ‘kerentanan vs. fungsional’ umum yang ditoleransi oleh pengembang karena implementasi dapat menciptakan pengalaman pengguna yang dikompromikan. Misalnya, itu tidak akan meningkatkan penjualan dari situs web ritel jika, ketika pelanggan meninggalkan keranjang belanja mereka sebelum checkout sebentar, mereka kembali ke pesan “session timeout”. Basis pengetahuan OWASP adalah sumber daya Anda untuk mitigasi pengembangan.

Persyaratan 8: Selalu Gunakan ID Pengguna Unik

8.5.1 – Kredensial Otentikasi Unik untuk Penyedia Layanan

Praktik terbaik keamanan standar di dalam dan di luar PCI DSS adalah selalu menggunakan kredensial akses unik untuk SEMUANYA sehingga Anda tahu siapa pelakunya ketika sesuatu yang tidak diinginkan terjadi. Ini hanya standar, praktik yang baik.

Namun kebutuhan untuk ini secara eksplisit disorot sebagai persyaratan menunjukkan bahwa penyedia layanan memerlukan pengingat bahwa ini juga berlaku untuk mereka. Sebagian besar penyedia layanan akan beroperasi dengan aman tetapi mereka masih perlu mengambil tindakan pencegahan dasar yang sama dan memastikan mereka menggunakan kredensial unik (dan bukan hanya ‘nama pelanggan+administrator sebagai nama pengguna!)

Persyaratan 9: Keamanan Fisik

9.9 – Perlindungan Perangkat Point-of-Sale (POS) dari Kerusakan

Berdasarkan statistik pencurian data pemegang kartu, skimming kartu dan varian yang lebih rumit yang ditargetkan pada peralatan POS masih tersebar luas. Ini adalah ying ke yang dari persyaratan yang sangat teknis yang sebelumnya tercakup, mengingatkan Pedagang bahwa kejahatan ‘berteknologi rendah’ ​​masih bekerja juga.

Persyaratan 9 selalu dimaksudkan untuk menyampaikan pesan ‘jangan biarkan siapa pun menyentuh peralatan pemrosesan data pemegang kartu’. Klarifikasi Versi 3 di sini secara eksplisit menyoroti perlindungan titik akhir, yang mengarah pada kesimpulan bahwa Persyaratan 9 secara umum telah ditafsirkan sebagai – benar – sangat berorientasi pada pusat data ‘situs pusat’, tetapi dengan mengorbankan fokus pada sistem POS.

Persyaratan 11: Uji Keamanan

11.3 Mengembangkan dan Menerapkan Metodologi untuk Pengujian Penetrasi

Ini adalah persyaratan ‘baru’ lain yang ada untuk menekankan fokus pada salah satu praktik standar yang sudah dipatuhi semua orang, tetapi mungkin tidak melakukannya sebaik mungkin. Kasus klasik untuk memenuhi surat, tetapi bukan semangat, dari persyaratan.

Tampaknya pasar untuk Pen Testing telah menjadi komoditas yang tinggi dengan sebagian besar vendor menawarkan layanan yang direkayasa dengan biaya tinggi dan sangat otomatis. Ini pasti telah menyebabkan pengujian menjadi lebih dangkal (lebih ‘pendekatan kotak centang untuk kepatuhan’) sehingga persyaratan baru ini adalah ‘tarik tali’, memaksa pedagang untuk menghindari kebiasaan buruk dan memotong sudut.

Bagaimanapun, ini adalah sesuatu yang sangat penting bagi metodologi NNT, karena kami menganjurkan agar Praktik Terbaik Keamanan klasik dioperasikan, yang pada gilirannya membantu meminimalkan pendekatan ‘booming and bust’ terhadap manajemen kerentanan yang terkadang ditimbulkan oleh PCI DSS.

Misalnya, menjalankan pemindaian tahunan atau triwulanan, kemudian harus menghentikan semuanya selama seminggu untuk menambal dan mengkonfigurasi ulang perangkat sebelum mengulangi prosesnya 3 bulan kemudian tidak hanya membuat hidup menjadi sulit, tetapi juga dapat membuat Anda tidak aman selama berbulan-bulan pada suatu waktu . NNT bekerja secara terus menerus untuk terus melacak perubahan pada perangkat dan memungkinkan Anda untuk mengoperasikan lebih banyak proses ‘pemangkasan’ untuk manajemen kerentanan. Pendekatan ini lebih efektif, lebih lembut pada jaringan dan host, dan juga lebih mudah pada sumber daya Anda!

Persyaratan 12: Menjaga Kebijakan Keamanan

12.9 – Persyaratan Tambahan untuk Penyedia Layanan tentang Keamanan Data

Dan terakhir, klarifikasi Persyaratan 12 tentang penggunaan Cloud atau Managed Security Services. Tujuannya adalah untuk memastikan bahwa penyedia layanan benar-benar memahami dan mengoperasikan persyaratan PCI mereka sepenuhnya. DSS menempatkan tanggung jawab pada pedagang untuk memastikan mereka memiliki pernyataan yang mengakui hal ini dan, pada gilirannya, Pedagang harus diberi ganti rugi atas perlindungan data pemegang kartu oleh penyedia layanan mereka.

Kesimpulan

Singkatnya, meskipun ada persyaratan baru, beberapa di antaranya mungkin terbukti sulit untuk diterapkan dan diuji, tidak ada perubahan dalam hal maksud.

Keamanan data harus menjadi fokus penuh waktu, membutuhkan disiplin operasional tingkat tinggi, dengan pemeriksaan dan keseimbangan untuk memastikan keamanan tetap terjaga. PCI DSS mencoba menyampaikan hal ini, tetapi selalu menjadi korban kebutuhan untuk mendidik, mengklarifikasi, dan mengamanatkan praktik terbaik keamanan. Keamanan Data bukanlah hal yang mudah untuk dijelaskan atau diringkas, maka DSS telah berakhir dengan 650 sub-persyaratan yang dianggap rumit dan ambigu oleh Merchant atau Payment Processor.

Teknologi dapat membantu, dan ada peluang untuk mengimplementasikan solusi yang sangat otomatis untuk sebagian besar persyaratan PCI yang tidak mahal, juga tidak sulit, untuk diterapkan dan dijalankan.

Dan versi baru DSS ini, dengan penekanan yang lebih besar pada menjadikan keamanan sebagai kebiasaan biasa, sejalan dengan ini. Bahkan, Anda dapat menyederhanakan sebagian besar PCI DSS ke langkah-langkah berikut:

Terapkan keamanan perimeter dan titik akhir dasar dengan Firewall, IPS, dan Anti-Virus
Audit Server, Basis Data, dan Perangkat Jaringan terhadap daftar periksa pengerasan NIST atau CIS untuk menghilangkan kerentanan (gunakan sistem FIM Anda untuk ini)
Setelah perangkat mengeras, terapkan pemantauan kerentanan berkelanjutan, dengan deteksi malware waktu-nyata (dengan kata lain, Pemantauan Integritas File waktu-nyata)
Mulai kontrol perubahan konfigurasi untuk memastikan perangkat tetap aman setiap saat (FIM lagi), tambal semua sistem setiap bulan
Mendukung proses dengan logging dan SIEM sebagai pemeriksaan dan penyeimbangan jejak audit, dengan pengujian pena reguler dan pemindaian kerentanan ASV

Ambil langkah-langkah ini, dan Anda tidak hanya akan menjadi yang terdepan untuk PCI DSS Versi 3.0, tetapi mungkin juga Versi 4.0.

Forensik Komputer