Auditor keamanan untuk server kami telah menuntut hal berikut dalam waktu dua minggu:

• Daftar nama pengguna saat ini dan kata sandi teks biasa untuk semua akun pengguna di semua server
• Daftar semua perubahan kata sandi selama enam bulan terakhir, sekali lagi dalam teks biasa
• Daftar "setiap file yang ditambahkan ke server dari perangkat jarak jauh" dalam enam bulan terakhir
• Kunci publik dan pribadi dari kunci SSH
• Email yang dikirimkan kepadanya setiap kali pengguna mengubah kata sandi mereka, berisi kata sandi teks biasa

Kami menjalankan kotak Red Hat Linux 5/6 dan CentOS 5 dengan otentikasi LDAP.

Sejauh yang saya ketahui, semua yang ada dalam daftar itu tidak mungkin atau sangat sulit diperoleh, tetapi jika saya tidak memberikan informasi ini, kita akan menghadapi kehilangan akses ke platform pembayaran dan kehilangan pendapatan selama masa transisi saat kita beralih ke layanan baru. Adakah saran untuk bagaimana saya dapat memecahkan atau memalsukan informasi ini?

Satu-satunya cara saya bisa memikirkan untuk mendapatkan semua kata sandi teks biasa, adalah membuat semua orang untuk mereset kata sandi mereka dan membuat catatan tentang apa yang mereka setel. Itu tidak menyelesaikan masalah perubahan kata sandi selama enam bulan terakhir, karena saya tidak bisa secara surut mencatat hal-hal semacam itu, hal yang sama berlaku untuk mencatat semua file jarak jauh.

Mendapatkan semua kunci SSH publik dan pribadi dimungkinkan (meskipun menjengkelkan), karena kami hanya memiliki beberapa pengguna dan komputer. Kecuali saya melewatkan cara yang lebih mudah untuk melakukan ini?

Saya telah menjelaskan kepadanya berkali-kali bahwa hal-hal yang dia minta tidak mungkin. Menanggapi kekhawatiran saya, dia menjawab dengan email berikut:

Saya memiliki lebih dari 10 tahun pengalaman dalam audit keamanan dan pemahaman penuh tentang metode keamanan redhat, jadi saya sarankan Anda memeriksa fakta tentang apa yang mungkin dan tidak mungkin. Anda mengatakan tidak ada perusahaan yang mungkin memiliki informasi ini tetapi saya telah melakukan ratusan audit di mana informasi ini sudah tersedia. Semua klien [penyedia pemrosesan kartu kredit umum] diharuskan untuk mematuhi kebijakan keamanan baru kami dan audit ini dimaksudkan untuk memastikan kebijakan tersebut telah diterapkan * dengan benar.

* "Kebijakan keamanan baru" diperkenalkan dua minggu sebelum audit kami, dan pencatatan historis enam bulan tidak diperlukan sebelum perubahan kebijakan.

Singkatnya, saya perlu;

• Cara untuk "memalsukan" perubahan kata sandi selama enam bulan dan membuatnya terlihat valid
• Cara untuk "memalsukan" enam bulan transfer file masuk
• Cara mudah untuk mengumpulkan semua kunci publik dan pribadi SSH yang digunakan

Jika kami gagal audit keamanan, kami kehilangan akses ke platform pemrosesan kartu kami (bagian penting dari sistem kami) dan itu akan memakan waktu dua minggu untuk pindah ke tempat lain. Bagaimana saya kacau?

Pembaruan 1 (Sabtu 23)

Terima kasih atas semua tanggapan Anda, Saya merasa lega mengetahui ini bukan praktik standar.

Saat ini saya sedang merencanakan tanggapan email saya kepadanya untuk menjelaskan situasinya. Seperti yang ditunjukkan oleh banyak dari Anda, kami harus mematuhi PCI yang secara eksplisit menyatakan bahwa kami seharusnya tidak memiliki cara untuk mengakses kata sandi teks biasa. Saya akan memposting email setelah saya selesai menulisnya. Sayangnya saya tidak berpikir dia hanya menguji kita; semua ini ada dalam kebijakan keamanan resmi perusahaan sekarang. Namun, saya telah mengatur roda untuk pindah dari mereka dan ke PayPal untuk saat ini.

Pembaruan 2 (Sabtu 23)

Ini adalah email yang saya konsepkan, ada saran untuk hal-hal untuk ditambahkan / dihapus / ubah?

Hai [nama],

Sayangnya tidak ada cara bagi kami untuk memberi Anda beberapa informasi yang diminta, terutama kata sandi teks biasa, riwayat kata sandi, kunci SSH dan log file jarak jauh. Tidak hanya hal-hal ini secara teknis tidak mungkin, tetapi juga dapat memberikan informasi ini akan bertentangan dengan Standar PCI, dan pelanggaran tindakan perlindungan data.
Mengutip persyaratan PCI,

8.4 Jadikan semua kata sandi tidak dapat dibaca selama transmisi dan penyimpanan pada semua komponen sistem menggunakan kriptografi yang kuat.

Saya dapat memberi Anda daftar nama pengguna dan kata sandi hash yang digunakan pada sistem kami, salinan kunci publik SSH dan file host resmi (Ini akan memberi Anda informasi yang cukup untuk menentukan jumlah pengguna unik yang dapat terhubung ke server kami, dan enkripsi metode yang digunakan), informasi tentang persyaratan keamanan kata sandi kami dan server LDAP kami tetapi informasi ini mungkin tidak diambil dari situs. Saya sangat menyarankan Anda meninjau persyaratan audit Anda karena saat ini tidak ada cara bagi kami untuk lulus audit ini sambil tetap mematuhi PCI dan tindakan Perlindungan Data.

Salam,
[saya]

Saya akan CC'ing dalam CTO perusahaan dan manajer akun kami, dan saya berharap CTO dapat mengkonfirmasi informasi ini tidak tersedia. Saya juga akan menghubungi Dewan Standar Keamanan PCI untuk menjelaskan apa yang dia butuhkan dari kami.

Perbarui 3 (26)

Berikut beberapa email yang kami tukarkan;

RE: email pertama saya;

Sebagaimana dijelaskan, informasi ini harus mudah tersedia pada sistem yang dikelola dengan baik oleh administrator yang kompeten. Kegagalan Anda untuk dapat memberikan informasi ini membuat saya percaya bahwa Anda mengetahui kelemahan keamanan dalam sistem Anda dan tidak siap untuk mengungkapkannya. Permintaan kami sejalan dengan pedoman PCI dan keduanya dapat dipenuhi. Kriptografi yang kuat hanya berarti kata sandi harus dienkripsi ketika pengguna memasukkannya tetapi kemudian harus dipindahkan ke format yang dapat dipulihkan untuk digunakan nanti.

Saya melihat tidak ada masalah perlindungan data untuk permintaan ini, perlindungan data hanya berlaku untuk konsumen bukan bisnis sehingga tidak boleh ada masalah dengan informasi ini.

Hanya, apa, aku, tidak bisa, bahkan ...

"Kriptografi yang kuat hanya berarti kata sandi harus dienkripsi saat pengguna memasukkannya tetapi kemudian harus dipindahkan ke format yang dapat dipulihkan untuk digunakan nanti."

Saya akan membingkai itu dan meletakkannya di dinding saya.

Saya muak menjadi diplomatik dan mengarahkannya ke utas ini untuk menunjukkan kepadanya tanggapan yang saya dapatkan:

Memberikan informasi ini secara LANGSUNG bertentangan dengan beberapa persyaratan pedoman PCI. Bagian yang saya kutip bahkan mengatakan storage (Menyiratkan di mana kita menyimpan data pada disk). Saya memulai diskusi di ServerFault.com (Komunitas on-line untuk profesional sys-admin) yang telah menciptakan respons yang sangat besar, semuanya menunjukkan bahwa informasi ini tidak dapat disediakan. Jangan ragu untuk membaca sendiri

https://serverfault.com/questions/293217/

Kami telah selesai pindah sistem kami ke platform baru dan akan membatalkan akun kami dengan Anda dalam beberapa hari ke depan, tetapi saya ingin Anda menyadari betapa konyolnya permintaan ini, dan tidak ada perusahaan yang menerapkan pedoman PCI dengan benar, atau harus, dapat memberikan informasi ini. Saya sangat menyarankan Anda memikirkan kembali persyaratan keamanan Anda karena tidak ada pelanggan Anda yang dapat memenuhi ini.

(Aku benar-benar lupa aku memanggilnya idiot dalam judul, tetapi seperti yang disebutkan kita sudah pindah dari platform mereka sehingga tidak ada kerugian nyata.)

Dan dalam tanggapannya, ia menyatakan bahwa tampaknya tidak ada di antara Anda yang tahu apa yang Anda bicarakan:

Saya membaca secara terperinci melalui tanggapan-tanggapan itu dan pos orisinal Anda, para penanggap semua perlu mendapatkan fakta-fakta mereka dengan benar. Saya telah berada di industri ini lebih lama daripada siapa pun di situs itu, mendapatkan daftar kata sandi akun pengguna adalah sangat mendasar, itu harus menjadi salah satu hal pertama yang Anda lakukan ketika mempelajari cara mengamankan sistem Anda dan sangat penting untuk pengoperasian keamanan apa pun server. Jika Anda benar-benar tidak memiliki keterampilan untuk melakukan sesuatu yang sederhana ini, saya akan menganggap Anda tidak memiliki PCI yang diinstal pada server Anda karena dapat memulihkan informasi ini adalah persyaratan dasar dari perangkat lunak. Ketika berhadapan dengan sesuatu seperti keamanan Anda tidak seharusnya menanyakan pertanyaan-pertanyaan ini di forum publik jika Anda tidak memiliki pengetahuan dasar tentang cara kerjanya.

Saya juga ingin menyarankan agar setiap upaya untuk mengungkapkan saya, atau [nama perusahaan] akan dianggap fitnah dan tindakan hukum yang sesuai akan diambil

Poin idiot kunci jika Anda melewatkannya:

• Dia telah menjadi auditor keamanan lebih lama daripada orang lain di sini (Dia menebak, atau menguntit Anda)
• Mampu mendapatkan daftar kata sandi pada sistem UNIX adalah 'dasar'
• PCI sekarang adalah perangkat lunak
• Orang tidak boleh menggunakan forum ketika mereka tidak yakin dengan keamanan
• Posing informasi faktual (yang saya punya bukti email) online adalah fitnah

Luar biasa.

PCI SSC telah merespons dan sedang menyelidiki dia dan perusahaan. Perangkat lunak kami sekarang telah pindah ke PayPal sehingga kami tahu itu aman. Saya akan menunggu PCI untuk kembali kepada saya terlebih dahulu tetapi saya agak khawatir bahwa mereka mungkin telah menggunakan praktik keamanan ini secara internal. Jika demikian, saya pikir ini adalah masalah utama bagi kami karena semua pemrosesan kartu kami berjalan melalui mereka. Jika mereka melakukan ini secara internal saya pikir satu-satunya hal yang bertanggung jawab untuk dilakukan adalah memberi tahu pelanggan kami.

Saya berharap ketika PCI menyadari betapa buruknya mereka akan menyelidiki seluruh perusahaan dan sistem tetapi saya tidak yakin.

Jadi sekarang kita sudah pindah dari platform mereka, dan dengan asumsi itu akan memakan waktu setidaknya beberapa hari sebelum PCI kembali kepada saya, ada saran inventif untuk bagaimana cara menjebaknya sedikit? =)

Setelah saya mendapat izin dari petugas hukum saya (saya sangat meragukan semua ini benar-benar fitnah tetapi saya ingin memeriksa ulang) saya akan mempublikasikan nama perusahaan, namanya dan email, dan jika Anda mau, Anda dapat menghubungi dia dan menjelaskan mengapa Anda tidak memahami dasar-dasar keamanan Linux seperti cara mendapatkan daftar semua kata sandi pengguna LDAP.

Sedikit pembaruan:

"Orang hukum" saya telah menyatakan bahwa perusahaan mungkin akan menyebabkan lebih banyak masalah daripada yang dibutuhkan. Saya dapat mengatakan, ini bukan penyedia utama, mereka memiliki kurang dari 100 klien yang menggunakan layanan ini. Kami awalnya mulai menggunakannya ketika situs itu kecil dan berjalan di VPS kecil, dan kami tidak ingin melalui semua upaya untuk mendapatkan PCI (Kami dulu mengarahkan ke frontend mereka, seperti PayPal Standard). Tetapi ketika kami pindah ke pemrosesan kartu secara langsung (termasuk mendapatkan PCI, dan akal sehat), para pengembang memutuskan untuk tetap menggunakan perusahaan yang sama hanya dengan API yang berbeda. Perusahaan ini berbasis di daerah Birmingham, Inggris, jadi saya sangat ragu ada orang di sini yang akan terpengaruh.

Pertama, JANGAN menyerah. Dia tidak hanya idiot tetapi juga BERBAHAYA salah. Bahkan, melepaskan informasi ini akan melanggar standar PCI (yang saya anggap diaudit audit karena merupakan prosesor pembayaran) bersama dengan setiap standar lain di luar sana dan hanya akal sehat. Itu juga akan memaparkan perusahaan Anda pada segala macam kewajiban.

Hal berikutnya yang akan saya lakukan adalah mengirim email kepada atasan Anda yang mengatakan bahwa ia perlu melibatkan penasihat perusahaan untuk menentukan paparan hukum yang akan dihadapi perusahaan dengan melanjutkan tindakan ini.

Bit terakhir ini terserah Anda, tetapi saya akan menghubungi VISA dengan informasi ini dan menarik status auditor PCI-nya.

Sebagai seseorang yang telah melalui prosedur audit dengan Price Waterhouse Coopers untuk kontrak pemerintah rahasia, saya dapat meyakinkan Anda, ini benar-benar keluar dari pertanyaan dan orang ini gila.

Ketika PwC ingin memeriksa kekuatan kata sandi kami, mereka:

• Diminta untuk melihat algoritma kekuatan kata sandi kami
• Menjalankan unit uji terhadap algoritme kami untuk memeriksa apakah mereka akan menolak kata sandi yang buruk
• Diminta untuk melihat algoritma enkripsi kami untuk memastikan bahwa mereka tidak dapat dibalik atau tidak dienkripsi (bahkan oleh tabel pelangi), bahkan oleh seseorang yang memiliki akses penuh ke setiap aspek sistem
• Diperiksa untuk melihat bahwa kata sandi sebelumnya di-cache untuk memastikan bahwa kata sandi tersebut tidak dapat digunakan kembali
• Minta izin kepada kami (yang kami berikan) agar mereka mencoba masuk ke jaringan dan sistem terkait menggunakan teknik rekayasa non-sosial (hal-hal seperti eksploitasi xss dan non-0 hari)

Jika saya bahkan mengisyaratkan bahwa saya bisa menunjukkan kepada mereka apa kata sandi pengguna selama 6 bulan terakhir, mereka akan segera menutup kami dari kontrak.

Jika memungkinkan untuk memberikan persyaratan ini, Anda akan langsung gagal setiap audit tunggal yang layak dimiliki.

Pembaruan: Email respons Anda terlihat bagus. Jauh lebih profesional daripada apa pun yang saya tulis.

Jujur, sepertinya orang ini (auditor) menjebak Anda. Jika Anda memberinya informasi yang ia minta, Anda baru saja membuktikan kepadanya bahwa Anda dapat direkayasa secara sosial untuk menyerahkan informasi internal yang kritis. Gagal.

Saya baru saja melihat Anda berada di Inggris, yang artinya apa yang dia minta Anda lakukan adalah melanggar hukum (Undang-Undang Perlindungan Data). Saya di Inggris juga, bekerja untuk perusahaan besar yang diaudit dan tahu hukum dan praktik umum di daerah ini. Saya juga pekerjaan yang sangat jahat yang akan dengan senang hati mengekang orang ini untuk Anda jika Anda suka hanya untuk bersenang-senang, beri tahu saya jika Anda ingin membantu ok.

Anda direkayasa secara sosial. Entah itu untuk 'menguji Anda' atau peretas yang menyamar sebagai auditor untuk mendapatkan beberapa data yang sangat berguna.

Saya sangat prihatin dengan kurangnya keterampilan pemecahan masalah etika OP dan komunitas kesalahan server mengabaikan pelanggaran perilaku etis yang mencolok ini.

Singkatnya, saya perlu;

• Cara 'palsu' untuk perubahan kata sandi selama enam bulan dan membuatnya terlihat valid
• Cara untuk 'memalsukan' enam bulan transfer file masuk

Izinkan saya menjelaskan dua hal:

1. Tidak pernah tepat untuk memalsukan data selama bisnis normal.
2. Anda tidak boleh membocorkan informasi semacam ini kepada siapa pun. Pernah.

Bukan tugas Anda untuk memalsukan catatan. Adalah tugas Anda untuk memastikan bahwa semua catatan yang diperlukan tersedia, akurat, dan aman.

Komunitas di sini di Server Fault harus memperlakukan jenis pertanyaan ini karena situs stackoverflow menangani pertanyaan "pekerjaan rumah". Anda tidak dapat mengatasi masalah ini hanya dengan respons teknis atau mengabaikan pelanggaran tanggung jawab etis.

Melihat begitu banyak pengguna tingkat tinggi menjawab di sini di utas ini dan tidak menyebutkan implikasi etis dari pertanyaan itu membuat saya sedih.

Saya akan mendorong semua orang untuk membaca Kode Etik Administrator Sistem SAGE .

BTW, auditor keamanan Anda bodoh, tetapi itu tidak berarti Anda perlu merasakan tekanan untuk menjadi tidak etis dalam pekerjaan Anda.

Sunting: Pembaruan Anda sangat berharga. Turunkan kepala Anda, bedak kering, dan jangan mengambil (atau memberikan) uang receh kayu.

Anda tidak dapat memberinya apa yang Anda inginkan, dan upaya untuk "memalsukan" itu kemungkinan akan kembali menggigit Anda (mungkin dengan cara hukum). Anda juga perlu naik banding atas rantai komandonya (mungkin saja auditor ini hilang, meskipun audit keamanan terkenal bodoh - tanyakan kepada saya tentang auditor yang ingin dapat mengakses AS / 400 melalui SMB), atau dapatkan keluar dari bawah persyaratan keras ini.

Mereka bahkan bukan keamanan yang baik - daftar semua kata sandi plaintext adalah hal yang sangat berbahaya yang pernah dihasilkan, terlepas dari metode yang digunakan untuk melindungi mereka, dan saya bertaruh pria ini akan ingin mereka mengirim e-mail dalam bentuk teks biasa . (Saya yakin Anda sudah tahu ini, saya hanya perlu curhat sedikit).

Untuk omong kosong dan cekikikan, tanyakan langsung padanya bagaimana menjalankan persyaratannya - akui Anda tidak tahu caranya, dan ingin memanfaatkan pengalamannya. Setelah Anda keluar dan pergi, respons terhadap "Saya memiliki lebih dari 10 tahun pengalaman dalam audit keamanan" akan menjadi "tidak, Anda memiliki pengalaman 5 menit berulang ratusan kali".

Tidak ada auditor yang akan mengecewakan Anda jika mereka menemukan masalah historis yang sekarang telah Anda perbaiki. Padahal, itu bukti perilaku yang baik. Dengan mengingat hal itu, saya menyarankan dua hal:

a) Jangan berbohong atau mengada-ada. b) Baca kebijakan Anda.

Pernyataan kunci untuk saya adalah ini:

Semua klien [penyedia pemrosesan kartu kredit umum] diharuskan untuk mematuhi kebijakan keamanan baru kami

Saya bertaruh bahwa ada pernyataan dalam kebijakan tersebut yang mengatakan kata sandi tidak dapat ditulis dan tidak dapat disampaikan kepada orang lain selain pengguna. Jika ada, maka terapkan kebijakan itu untuk permintaannya. Saya sarankan menanganinya seperti ini:

• Daftar nama pengguna saat ini dan kata sandi teks biasa untuk semua akun pengguna di semua server

Tunjukkan padanya daftar nama pengguna, tetapi jangan biarkan mereka diambil. Jelaskan bahwa memberikan kata sandi teks biasa adalah a) tidak mungkin karena itu satu arah, dan b) melanggar kebijakan, yang diaudit untuk Anda lawan, sehingga Anda tidak akan mematuhinya.

• Daftar semua perubahan kata sandi selama enam bulan terakhir, sekali lagi dalam teks biasa

Jelaskan bahwa ini tidak tersedia secara historis. Beri dia daftar waktu perubahan kata sandi baru-baru ini untuk menunjukkan bahwa ini sedang dilakukan. Jelaskan, seperti di atas, bahwa kata sandi tidak akan diberikan.

• Daftar "setiap file yang ditambahkan ke server dari perangkat jarak jauh" dalam enam bulan terakhir

Jelaskan apa yang sedang dan tidak sedang dicatat. Berikan apa yang kamu bisa. Jangan memberikan sesuatu yang rahasia, dan jelaskan dengan kebijakan mengapa tidak. Tanyakan apakah logging Anda perlu ditingkatkan.

• Kunci publik dan pribadi dari kunci SSH

Lihatlah kebijakan manajemen utama Anda. Seharusnya menyatakan bahwa kunci pribadi tidak diperbolehkan keluar dari wadah mereka dan memiliki kondisi akses yang ketat. Terapkan kebijakan itu, dan jangan izinkan akses. Kunci publik sangat terbuka untuk umum dan dapat dibagikan.

• Email yang dikirimkan kepadanya setiap kali pengguna mengubah kata sandi mereka, berisi kata sandi teks biasa

Katakan saja tidak. Jika Anda memiliki server log aman lokal, izinkan dia untuk melihat bahwa ini sedang log in situ.

Pada dasarnya, dan saya minta maaf untuk mengatakan ini, tetapi Anda harus bermain keras dengan orang ini. Ikuti kebijakan Anda dengan tepat, jangan menyimpang. Jangan berbohong. Dan jika dia mengecewakan Anda karena hal-hal yang tidak ada dalam kebijakan, mengeluh kepada seniornya di perusahaan yang mengirimnya. Kumpulkan jejak kertas dari semua ini untuk membuktikan bahwa Anda telah masuk akal. Jika Anda melanggar kebijakan Anda, Anda berada di rahmatnya. Jika Anda mengikuti mereka ke surat itu, ia akan berakhir dipecat.

Ya, auditor itu idiot. Namun, seperti yang Anda tahu, kadang-kadang orang idiot ditempatkan di posisi kekuasaan. Ini merupakan salah satu dari kasus-kasus itu.

Informasi yang dia minta tidak ada kaitannya dengan keamanan sistem saat ini. Jelaskan kepada auditor bahwa Anda menggunakan LDAP untuk autentikasi dan bahwa kata sandi disimpan menggunakan hash satu arah. Singkat melakukan skrip kasar terhadap hash kata sandi (yang bisa memakan waktu berminggu-minggu (atau bertahun-tahun), Anda tidak akan dapat memberikan kata sandi.

Demikian juga file jarak jauh - Saya ingin mendengar, mungkin, bagaimana menurutnya Anda harus dapat membedakan antara file yang dibuat langsung di server dan file yang SCPed ke server.

Seperti @ womble katakan, jangan memalsukan apa pun. Itu tidak akan ada gunanya. Entah mengabaikan audit ini dan mendenda broker lain, atau menemukan cara untuk meyakinkan "profesional" ini bahwa kejunya telah terlepas dari biskuitnya.

Mintalah "auditor keamanan" Anda menunjuk ke teks apa pun dari dokumen-dokumen ini yang memiliki persyaratannya dan saksikan ketika ia berjuang untuk mengajukan alasan dan akhirnya memaafkan dirinya sendiri untuk tidak pernah didengar lagi.

WTF! Maaf tapi itu satu-satunya reaksi saya terhadap ini. Tidak ada persyaratan audit yang pernah saya dengar yang membutuhkan kata sandi plaintext, apalagi memberi mereka kata sandi saat mereka berubah.

Pertama, minta dia menunjukkan kepada Anda persyaratan yang Anda berikan itu.

Kedua, jika ini untuk PCI (yang kita asumsikan karena ini adalah pertanyaan sistem pembayaran) buka di sini: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php dan dapatkan auditor baru.

Ketiga, ikuti apa yang mereka katakan di atas, hubungi manajemen Anda dan minta mereka menghubungi perusahaan QSA yang bekerja dengannya. Maka segera dapatkan auditor lain.

Auditor menyatakan sistem audit, standar, proses, dll. Mereka tidak perlu memiliki informasi yang memberikan mereka akses ke sistem.

Jika Anda menginginkan auditor yang direkomendasikan atau colo pengganti yang bekerja sama dengan auditor, hubungi saya dan saya akan dengan senang hati memberikan referensi.

Semoga berhasil! Percayalah pada naluri Anda, jika ada sesuatu yang salah, itu mungkin.

Tidak ada alasan yang sah baginya untuk mengetahui kata sandi dan memiliki akses ke kunci pribadi. Apa yang dia minta akan memberinya kemampuan untuk menyamar sebagai klien Anda kapan saja dan menyedot uang sebanyak yang dia inginkan, tanpa ada cara untuk mendeteksinya sebagai kemungkinan transaksi curang. Ini akan menjadi jenis ancaman keamanan yang seharusnya diaudit untukmu.

Beri tahu manajemen bahwa Auditor telah meminta Anda melanggar kebijakan keamanan Anda, dan bahwa permintaan itu ilegal. Sarankan agar mereka ingin membuang perusahaan audit yang sekarang dan mencari yang sah. Hubungi polisi dan balikkan auditor untuk meminta informasi ilegal (di Inggris). Kemudian panggil PCI dan balikkan Auditor untuk permintaan mereka.

Permintaannya mirip dengan meminta Anda pergi membunuh seseorang secara acak dan menyerahkan tubuh. Apakah kamu akan melakukan itu? atau apakah Anda akan memanggil polisi dan menyerahkannya?

Menanggapi dengan gugatan . Jika auditor meminta kata sandi teks biasa (ayolah sekarang, tidak sulit untuk bruteforce atau memecahkan hash kata sandi yang lemah), mereka mungkin berbohong kepada Anda tentang kredensial mereka.

Hanya sebuah tip tentang bagaimana Anda mengucapkan respons Anda:

Sayangnya tidak ada cara bagi kami untuk memberi Anda beberapa informasi yang diminta, terutama kata sandi teks biasa, riwayat kata sandi, kunci SSH dan log file jarak jauh. Tidak hanya hal-hal ini secara teknis tidak mungkin ...

Saya akan ulangi hal ini untuk menghindari diskusi tentang kelayakan teknis. Membaca surel awal yang mengerikan yang dikirim oleh auditor, sepertinya ini adalah seseorang yang dapat memilih perincian yang tidak terkait dengan masalah utama, dan ia mungkin berpendapat bahwa Anda dapat menyimpan kata sandi, login, dll. :

... Karena kebijakan keamanan kami yang ketat, kami tidak pernah login kata sandi dalam teks biasa. Oleh karena itu, secara teknis tidak mungkin menyediakan data ini.

Atau

... Tidak hanya kami akan secara signifikan menurunkan tingkat keamanan internal kami dengan mematuhi permintaan Anda, ...

Selamat mencoba, dan tetap beri tahu kami bagaimana ini berakhir!

Dengan risiko melanjutkan serbuan pengguna bereputasi tinggi yang menjawab pertanyaan ini, inilah pikiran saya.

Saya agak bisa melihat mengapa dia menginginkan kata sandi plaintext, dan itu untuk menilai kualitas kata sandi yang digunakan. Ini adalah cara omong kosong untuk melakukan itu, sebagian besar auditor yang saya tahu akan menerima hash crypted dan menjalankan cracker untuk melihat buah rendah seperti apa yang bisa mereka tarik. Semua dari mereka akan membahas kebijakan kompleksitas kata sandi dan meninjau perlindungan apa yang ada untuk menegakkan itu.

Tetapi Anda harus mengirimkan beberapa kata sandi. Saya menyarankan (meskipun saya pikir Anda mungkin sudah melakukan ini) bertanya kepadanya apa tujuan pengiriman kata sandi plaintext. Dia mengatakan itu untuk memvalidasi kepatuhan Anda terhadap kebijakan keamanan, jadi mintalah dia memberi Anda kebijakan itu. Tanyakan padanya apakah dia akan menerima bahwa rezim kompleksitas kata sandi Anda cukup kuat untuk mencegah pengguna menetapkan kata sandi mereka P@55w0rddan terbukti telah ada selama 6 bulan yang bersangkutan.

Jika dia memaksakannya, Anda mungkin harus mengakui bahwa Anda tidak dapat mengirimkan kata sandi plaintext karena Anda tidak siap untuk merekamnya (apa dengan itu menjadi keamanan utama gagal), tetapi dapat berusaha untuk melakukannya di masa depan jika ia membutuhkan verifikasi langsung bahwa kebijakan kata sandi Anda berfungsi. Dan jika dia ingin membuktikannya, Anda akan dengan senang hati menyediakan basis data kata sandi yang dienkripsi untuknya (atau Anda! Tunjukkan keinginan! Ini membantu!) Untuk menjalankan cracking pass.

"File jarak jauh" kemungkinan bisa ditarik dari log SSH untuk sesi SFTP, yang saya curigai sedang dibicarakannya. Jika Anda tidak memiliki syslogging selama 6 bulan, ini akan sulit untuk diproduksi. Apakah menggunakan wget untuk menarik file dari server jauh saat login melalui SSH dianggap sebagai 'transfer file jarak jauh'? Apakah PUT HTTP? File dibuat dari teks clipboard di jendela terminal pengguna jarak jauh? Jika ada, Anda dapat mengganggunya dengan kasus-kasus tepi ini untuk mendapatkan perasaan yang lebih baik untuk keprihatinannya di bidang ini dan mungkin menanamkan perasaan "Saya tahu lebih banyak tentang ini daripada Anda", serta teknologi spesifik apa yang ia pikirkan. Kemudian ekstrak apa yang Anda bisa dari log dan log diarsipkan pada cadangan.

Saya tidak mendapatkan apa pun pada kunci SSH. Satu-satunya hal yang dapat saya pikirkan adalah bahwa dia memeriksa kunci tanpa kata sandi untuk beberapa alasan, dan mungkin kekuatan kripto. Kalau tidak, saya tidak mendapat apa-apa.

Sedangkan untuk mendapatkan kunci-kunci itu, memanen setidaknya kunci publik cukup mudah; cukup troll folder .ssh yang mencarinya. Mendapatkan kunci pribadi akan melibatkan mengenakan topi BOFH Anda dan menyerang pengguna Anda, "Kirimi saya pasangan kunci SSH publik dan pribadi Anda. Apa pun yang saya tidak dapatkan akan dihapus dari server dalam 13 hari," dan jika ada yang mengomel (saya akan) menunjukkannya pada audit keamanan. Scripting adalah teman Anda di sini. Minimal itu akan menyebabkan sekelompok keypairs tanpa password untuk mendapatkan password.

Jika dia masih bersikeras "kata sandi teks biasa dalam email" setidaknya kenakan email itu dengan enkripsi GPG / PGP dengan kuncinya sendiri. Auditor sekuriti mana pun yang bernilai garamnya harus mampu menangani hal seperti itu. Dengan begitu jika kata sandi bocor, itu karena dia membiarkannya, bukan Anda. Namun tes lakmus lain untuk kompetensi.

Saya harus setuju dengan Zypher dan Womble untuk yang satu ini. Idiot berbahaya dengan konsekuensi berbahaya.

Dia mungkin menguji Anda untuk melihat apakah Anda memiliki risiko keamanan. Jika Anda memberikan detail ini kepadanya maka Anda mungkin akan langsung diberhentikan. Bawa ini ke atasan langsung Anda dan berikan tanggung jawab. Biarkan atasan Anda tahu bahwa Anda akan melibatkan pihak berwenang yang relevan jika keledai ini mendekati Anda lagi.

Itulah yang dibayar bos.

Saya memiliki visi tentang selembar kertas yang tersisa di belakang taksi yang memiliki daftar kata sandi, kunci SSH dan nama pengguna di atasnya! Hhhmmm! Dapat melihat berita utama surat kabar sekarang!

Memperbarui

Menanggapi 2 komentar di bawah ini saya kira Anda berdua memiliki poin bagus untuk dibuat. Tidak ada cara untuk benar-benar menemukan kebenaran dan fakta pertanyaan yang diposting sama sekali menunjukkan sedikit kenaifan pada bagian poster serta keberanian untuk menghadapi situasi yang buruk dengan konsekuensi karir potensial di mana orang lain akan menempel kepala mereka di pasir dan lari.

Kesimpulan saya untuk apa nilainya adalah bahwa ini adalah perdebatan yang sangat menarik yang mungkin membuat sebagian besar pembaca bertanya-tanya apa yang akan mereka lakukan dalam situasi ini terlepas dari apakah kebijakan auditor atau auditor tersebut kompeten atau tidak. Kebanyakan orang akan menghadapi dilema semacam ini dalam beberapa bentuk atau bentuk dalam kehidupan kerja mereka dan ini sebenarnya bukan jenis tanggung jawab yang harus didorong ke bahu satu orang. Ini adalah keputusan bisnis dan bukan keputusan individu tentang bagaimana menghadapi hal ini.

Jelas ada banyak info bagus di sini, tetapi izinkan saya untuk menambahkan 2c saya, sebagai seseorang yang menulis perangkat lunak yang dijual di seluruh dunia oleh majikan saya ke perusahaan besar terutama untuk membantu orang dalam mematuhi kebijakan keamanan manajemen akun dan lulus audit; untuk apa itu layak.

Pertama, ini terdengar sangat mencurigakan, seperti yang Anda (dan lainnya) catat. Entah auditor hanya mengikuti prosedur yang tidak dia mengerti (mungkin), atau menguji Anda untuk kerentanan sehingga rekayasa sosial (tidak mungkin setelah pertukaran tindak lanjut), atau penipuan rekayasa sosial Anda (juga mungkin), atau hanya idiot generik (mungkin yang paling disukai). Sejauh saran, saya akan menawarkan bahwa Anda harus berbicara dengan manajemen Anda, dan / atau menemukan perusahaan audit baru, dan / atau melaporkan ini ke agen pengawas yang sesuai.

Adapun catatan, beberapa hal:

• Hal ini mungkin (dalam kondisi tertentu) untuk memberikan informasi yang diminta, jika sistem Anda sudah diatur untuk memungkinkan. Akan tetapi, ini sama sekali bukan "praktik terbaik" untuk keamanan, juga sama sekali tidak umum.
• Secara umum, audit berkaitan dengan praktik validasi, tidak memeriksa informasi aman aktual. Saya akan sangat curiga terhadap siapa pun yang meminta kata sandi atau sertifikat teks biasa, daripada metode yang digunakan untuk memastikan mereka "baik" dan diamankan dengan benar.

Harapan itu membantu, bahkan jika itu kebanyakan mengulangi apa yang telah disarankan orang lain. Seperti Anda, saya tidak akan menyebutkan nama perusahaan saya, dalam kasus saya karena saya tidak berbicara untuk mereka (akun / pendapat pribadi dan semua); permintaan maaf jika itu mengurangi kredibilitas, tapi biarkan saja. Semoga berhasil.

Ini bisa dan harus diposting ke Keamanan IT - Stack Exchange .

Saya bukan ahli dalam audit keamanan, tetapi hal pertama yang saya pelajari tentang kebijakan keamanan adalah "NEVER GIVE PASSWORDS AWAY". Orang ini mungkin sudah berkecimpung dalam bisnis ini selama 10 tahun, tetapi seperti yang dikatakan Womble"no, you have 5 minutes of experience repeated hundreds of times"

Saya telah bekerja dengan orang-orang IT perbankan untuk beberapa waktu, dan ketika saya melihat Anda memposting, saya menunjukkannya kepada mereka ... Mereka tertawa sangat keras. Mereka mengatakan kepada saya bahwa pria itu terlihat seperti penipuan. Mereka terbiasa berurusan dengan hal semacam ini demi keamanan nasabah bank.

Meminta kata sandi yang jelas, kunci SSH, log kata sandi, jelas merupakan pelanggaran profesional yang serius. Orang ini berbahaya.

Saya harap semuanya baik-baik saja sekarang, dan bahwa Anda tidak memiliki masalah dengan fakta bahwa mereka dapat menyimpan catatan transaksi Anda sebelumnya dengan mereka.

Jika Anda dapat memberikan informasi apa pun (kecuali kemungkinan kunci publik) yang diminta dalam poin 1,2,4, dan 5 Anda harus berharap untuk gagal dalam audit.

Tanggapi poin 1,2 dan 5 secara formal dengan mengatakan Anda tidak dapat mematuhinya karena kebijakan keamanan Anda mengharuskan Anda tidak menyimpan kata sandi teks biasa dan kata sandi dienkripsi menggunakan algoritma yang tidak dapat dibalik. Ke poin 4, sekali lagi, Anda tidak dapat menyediakan kunci privat karena itu akan melanggar kebijakan keamanan Anda.

As to point 3. Jika Anda memiliki data, berikan itu. Jika Anda tidak melakukannya karena Anda tidak harus mengumpulkannya maka katakan demikian dan tunjukkan bagaimana Anda sekarang (bekerja menuju) memenuhi persyaratan baru.

Auditor keamanan untuk server kami telah menuntut hal berikut dalam waktu dua minggu :

...

Jika kami gagal dalam audit keamanan, kami kehilangan akses ke platform pemrosesan kartu kami (bagian penting dari sistem kami) dan itu akan memakan waktu dua minggu untuk pindah ke tempat lain . Bagaimana aku kacau?

Tampaknya Anda telah menjawab pertanyaan Anda sendiri. (Lihat teks tebal untuk petunjuk.)

Hanya satu solusi yang terlintas dalam pikiran: suruh semua orang menuliskan kata sandi terakhir dan saat ini, lalu segera ubah ke yang baru. Jika dia ingin menguji kualitas kata sandi (dan kualitas transisi dari kata sandi ke kata sandi, mis. Untuk memastikan tidak ada yang menggunakan rfvujn125 dan kemudian rfvujn126 sebagai kata sandi berikutnya,) daftar kata sandi lama itu sudah cukup.

Jika itu dianggap tidak dapat diterima, maka saya curiga pria itu adalah anggota Anonymous / LulzSec ... pada titik mana Anda harus bertanya kepadanya apa pegangannya dan menyuruhnya untuk berhenti menjadi scrub seperti itu!

Seperti yang dikatakan oli: orang yang dimaksud berusaha membuat Anda melanggar hukum (Perlindungan Data / arahan kerahasiaan UE) / peraturan internal / standar PCI. Anda tidak hanya harus memberi tahu manajemen (seperti yang sudah saya pikirkan), tetapi Anda dapat memanggil polisi seperti yang disarankan.

Jika orang tersebut memiliki akreditasi / sertifikasi, misalnya CISA (Auditor Sistem Informasi Bersertifikat), atau setara dengan CPA AS (penunjukan akuntan publik) di Inggris, Anda juga dapat memberi tahu organisasi akreditasi untuk menyelidiki hal ini. Tidak hanya orang yang berusaha membuat Anda melanggar hukum, itu juga "audit" yang sangat tidak kompeten dan mungkin bertentangan dengan setiap standar audit etis yang dengannya auditor terakreditasi harus menanggung kesakitan karena kehilangan akreditasi.

Selain itu, jika orang tersebut adalah anggota dari sebuah perusahaan yang lebih besar, organisasi audit yang diramalkan sering memerlukan semacam departemen QA yang mengawasi kualitas audit dan pengarsipan audit serta menyelidiki keluhan. Jadi, Anda mungkin juga harus mengeluh kepada perusahaan audit yang bersangkutan.

Saya masih belajar dan hal pertama yang saya pelajari ketika mengatur server adalah bahwa jika Anda memungkinkan untuk login kata sandi plaintext, Anda sudah membahayakan diri Anda sendiri karena pelanggaran besar. Kata sandi tidak boleh diketahui kecuali untuk pengguna yang menggunakannya.

Jika orang ini adalah auditor yang serius, dia seharusnya tidak menanyakan hal-hal ini kepada Anda. Bagi saya dia agak kedengaran seperti penyesat . Saya akan memeriksa dengan organ pengatur karena orang ini terdengar seperti orang idiot.

Memperbarui

Tunggu dulu, dia percaya Anda harus menggunakan enkripsi simetris hanya untuk mengirimkan kata sandi, tetapi kemudian menyimpannya plaintext di database Anda, atau memberikan cara untuk mendekripsi mereka. Jadi pada dasarnya, setelah semua serangan anonim pada database, di mana mereka menunjukkan kata sandi pengguna teks biasa, ia MASIH percaya ini adalah cara yang baik untuk "mengamankan" suatu lingkungan.

Dia adalah dinosaurus terjebak pada 1960-an ...

• Daftar nama pengguna saat ini dan kata sandi teks biasa untuk semua akun pengguna di semua server
  • Nama pengguna saat ini MUNGKIN berada dalam ruang lingkup "kami dapat merilis ini" dan harus dalam ruang lingkup "kami dapat menunjukkan ini kepada Anda, tetapi Anda mungkin tidak membawanya keluar-situs".
  • Kata sandi teks biasa seharusnya tidak ada lebih lama dari yang dibutuhkan untuk hash satu arah dan kata sandi tersebut seharusnya tidak pernah meninggalkan memori (bahkan untuk menyeberang kabel), jadi keberadaannya dalam penyimpanan permanen adalah tidak boleh.
• Daftar semua perubahan kata sandi selama enam bulan terakhir, sekali lagi dalam teks biasa
  • Lihat "penyimpanan permanen adalah larangan".
• Daftar "setiap file yang ditambahkan ke server dari perangkat jarak jauh" dalam enam bulan terakhir
  • Ini mungkin untuk memastikan bahwa Anda mencatat transfer file ke / dari server pemrosesan pembayaran, jika Anda memiliki log, itu boleh saja untuk diteruskan. Jika Anda tidak memiliki log, periksa apa yang dikatakan kebijakan keamanan terkait tentang pendataan info itu.
• Kunci publik dan pribadi dari kunci SSH
  • Mungkin upaya untuk memeriksa bahwa 'kunci SSH harus memiliki frasa sandi' ada dalam kebijakan dan diikuti. Anda memang ingin pass-phrase pada semua kunci pribadi.
• Email yang dikirimkan kepadanya setiap kali pengguna mengubah kata sandi mereka, berisi kata sandi teks biasa
  • Ini jelas tidak-tidak.

Saya akan merespons dengan jawaban saya, didukung oleh kepatuhan PCI, SOX_compliance dan dokumen kebijakan keamanan internal sesuai kebutuhan.

Permintaan orang-orang ini berbau surga, dan saya setuju bahwa korespondensi mulai dari sini harus melalui CTO. Entah dia mencoba membuatmu orang yang jatuh karena tidak dapat memenuhi permintaan tersebut, untuk melepaskan informasi rahasia, atau sangat tidak kompeten. Semoga CTO / manajer Anda akan melakukan dua kali lipat permintaan orang ini dan tindakan positif akan dilakukan, dan jika mereka berada di balik tindakan orang ini .... well, admin sistem yang baik selalu diminati di iklan baris, karena Saya kedengarannya sudah waktunya untuk mulai mencari tempat lain jika itu terjadi.

Saya akan memberitahunya bahwa butuh waktu, tenaga dan uang untuk membangun infrastruktur cracking untuk kata sandi, tetapi karena Anda menggunakan hashing yang kuat seperti SHA256 atau apa pun, mungkin tidak dapat memberikan kata sandi dalam waktu 2 minggu. Selain itu, saya akan mengatakan bahwa saya menghubungi departemen hukum untuk mengonfirmasi apakah sah untuk berbagi data ini dengan siapa pun. PCI DSS juga merupakan ide bagus untuk disebutkan seperti yang Anda lakukan. :)

Rekan-rekan saya terkejut dengan membaca posting ini.

Saya akan sangat tergoda untuk memberinya daftar nama pengguna / kata sandi / kunci pribadi untuk akun honeypot kemudian jika dia pernah menguji login untuk akun-akun ini lakukan padanya untuk akses tidak sah ke sistem komputer. Meskipun demikian, sayangnya ini mungkin membuat Anda setidaknya memiliki semacam gugatan perdata karena membuat perwakilan yang curang.

Cukup tolak mengungkapkan informasi, dengan menyatakan bahwa Anda tidak dapat meneruskan kata sandi karena Anda tidak memiliki akses ke sana. Sebagai seorang auditor sendiri, ia harus mewakili beberapa institusi. Lembaga-lembaga semacam itu umumnya menerbitkan pedoman untuk audit semacam itu. Lihat apakah permintaan seperti itu sesuai dengan pedoman itu. Anda bahkan dapat mengeluh kepada asosiasi semacam itu. Juga jelaskan kepada auditor bahwa jika terjadi kesalahan, kesalahan dapat kembali kepadanya (auditor) karena ia memiliki semua kata sandi.

Saya akan mengatakan bahwa tidak ada cara bagi Anda untuk memberikan informasi apa pun yang diminta kepadanya.

• Nama pengguna memberinya wawasan tentang akun yang memiliki akses ke sistem Anda, risiko keamanan
• Kata sandi sejarah akan memberikan wawasan tentang pola kata sandi yang digunakan memberinya kemungkinan serangan dengan menebak kata sandi berikutnya dalam rantai
• File yang ditransfer ke sistem dapat berisi informasi rahasia yang dapat digunakan dalam serangan terhadap sistem Anda, serta memberi mereka wawasan tentang struktur sistem file Anda
• Kunci publik dan pribadi, apa gunanya memilikinya jika Anda memberikannya kepada orang lain selain pengguna yang dituju?
• Email yang dikirim setiap kali pengguna mengubah kata sandi akan memberinya kata sandi terkini untuk setiap akun pengguna.

Orang ini sedang menarik pasangan plonker Anda! Anda perlu menghubungi manajernya atau auditor lain di perusahaan untuk mengkonfirmasi permintaannya yang keterlaluan. Dan menjauh ASAP.

Masalah dipecahkan sekarang, tetapi untuk kepentingan pembaca masa depan ...

Mengingat bahwa:

• Anda tampaknya telah menghabiskan lebih dari satu jam untuk ini.

• Anda harus berkonsultasi dengan penasihat hukum perusahaan.

• Mereka meminta banyak pekerjaan setelah mengubah perjanjian Anda.

• Anda akan keluar uang dan lebih banyak waktu beralih.

Anda harus menjelaskan bahwa Anda akan membutuhkan banyak uang di muka dan ada minimum empat jam.

Beberapa kali terakhir saya memberi tahu seseorang bahwa mereka tiba-tiba tidak begitu membutuhkan.

Anda masih dapat menagih mereka untuk setiap kerugian yang terjadi selama peralihan dan untuk waktu yang diambil, karena mereka mengubah perjanjian Anda. Saya tidak mengatakan bahwa mereka akan membayar dalam waktu dua minggu, sebanyak yang mereka pikir akan Anda patuhi dalam waktu itu - mereka akan sepihak, saya tidak ragu.

Ini akan menggetarkan mereka jika kantor pengacara Anda mengirimkan pemberitahuan penagihan. Ini harus menarik perhatian pemilik perusahaan auditor.

Saya akan menyarankan agar tidak berurusan lebih lanjut dengan mereka, hanya untuk membahas lebih lanjut masalah ini akan memerlukan setoran untuk pekerjaan yang diperlukan. Maka Anda dapat dibayar karena menyuruh mereka pergi.

Sungguh aneh bahwa Anda memiliki perjanjian yang berlaku dan kemudian seseorang di ujung lain akan keluar jalur - jika itu bukan ujian keamanan atau kecerdasan, itu pasti ujian kesabaran Anda.