ผู้ตรวจสอบความปลอดภัยสำหรับเซิร์ฟเวอร์ของเราเรียกร้องสิ่งต่อไปนี้ภายในสองสัปดาห์:

  • รายการชื่อผู้ใช้ปัจจุบันและรหัสผ่านแบบข้อความธรรมดาสำหรับบัญชีผู้ใช้ทั้งหมดบนเซิร์ฟเวอร์ทั้งหมด
  • รายการการเปลี่ยนแปลงรหัสผ่านทั้งหมดในช่วง 6 เดือนที่ผ่านมา อีกครั้งในรูปแบบข้อความธรรมดา
  • รายการ "ทุกไฟล์ที่เพิ่มไปยังเซิร์ฟเวอร์จากอุปกรณ์ระยะไกล" ในช่วง 6 เดือนที่ผ่านมา
  • คีย์สาธารณะและคีย์ส่วนตัวของคีย์ SSH ใดๆ
  • อีเมลที่ส่งถึงเขาทุกครั้งที่ผู้ใช้เปลี่ยนรหัสผ่านซึ่งมีรหัสผ่านข้อความธรรมดา

เรากำลังใช้งานกล่อง Red Hat Linux 5/6 และ CentOS 5 พร้อมการตรวจสอบสิทธิ์ LDAP

เท่าที่ฉันทราบ ทุกอย่างในรายการนั้นเป็นไปไม่ได้หรือยากอย่างเหลือเชื่อ แต่ถ้าฉันไม่ให้ข้อมูลนี้ เราจะสูญเสียการเข้าถึงแพลตฟอร์มการชำระเงินของเราและสูญเสียรายได้ระหว่างช่วงการเปลี่ยนแปลงเมื่อเราย้ายไปที่ บริการใหม่ ข้อเสนอแนะใด ๆ สำหรับวิธีแก้ไขหรือปลอมข้อมูลนี้?

วิธีเดียวที่ฉันคิดว่าจะได้รหัสผ่านที่เป็นข้อความล้วนคือให้ทุกคนรีเซ็ตรหัสผ่านและจดบันทึกสิ่งที่พวกเขาตั้งไว้ นั่นไม่สามารถแก้ปัญหาของการเปลี่ยนรหัสผ่านในช่วง 6 เดือนที่ผ่านมาได้ เนื่องจากผมไม่สามารถบันทึกข้อมูลประเภทนั้นย้อนหลังได้ เช่นเดียวกับการบันทึกไฟล์ระยะไกลทั้งหมด

การรับคีย์ SSH สาธารณะและส่วนตัวทั้งหมดเป็นไปได้ (แต่น่ารำคาญ) เนื่องจากเรามีผู้ใช้และคอมพิวเตอร์เพียงไม่กี่คน เว้นแต่ว่าฉันพลาดวิธีที่ง่ายกว่าในการทำเช่นนี้?

ฉันได้อธิบายให้เขาฟังหลายครั้งแล้วว่าสิ่งที่เขาขอนั้นเป็นไปไม่ได้ เพื่อตอบสนองต่อข้อกังวลของฉัน เขาตอบกลับด้วยอีเมลต่อไปนี้:

I have over 10 years experience in security auditing and a full understanding of the redhat security methods, so I suggest you check your facts about what is and isn't possible. You say no company could possibly have this information but I have performed hundreds of audits where this information has been readily available. All [generic credit card processing provider] clients are required to conform with our new security policies and this audit is intended to ensure those policies have been implemented* correctly.

* "นโยบายความปลอดภัยใหม่" ถูกนำมาใช้สองสัปดาห์ก่อนการตรวจสอบของเรา และไม่จำเป็นต้องบันทึกประวัติหกเดือนก่อนการเปลี่ยนแปลงนโยบาย

ในระยะสั้นฉันต้องการ;

  • วิธี "ปลอม" มูลค่าการเปลี่ยนแปลงรหัสผ่านหกเดือนและทำให้ดูถูกต้อง
  • วิธี "ปลอม" หกเดือนของการถ่ายโอนไฟล์ขาเข้า
  • วิธีง่ายๆ ในการรวบรวมคีย์สาธารณะและคีย์ส่วนตัวของ SSH ทั้งหมดที่ใช้อยู่

หากเราไม่ผ่านการตรวจสอบความปลอดภัย เราจะสูญเสียการเข้าถึงแพลตฟอร์มการประมวลผลบัตรของเรา (ส่วนสำคัญของระบบของเรา) และจะใช้เวลาสองสัปดาห์ในการย้ายไปยังที่อื่น ฉันเมาแค่ไหน?

อัปเดต 1 (วันเสาร์ที่ 23)

ขอบคุณสำหรับคำตอบทั้งหมดของคุณ ฉันโล่งใจมากที่รู้ว่านี่ไม่ใช่วิธีปฏิบัติมาตรฐาน

ฉันกำลังวางแผนการตอบกลับทางอีเมลของเขาเพื่ออธิบายสถานการณ์นี้ อย่างที่หลายๆ คนชี้ให้เห็น เราต้องปฏิบัติตาม PCI ซึ่งระบุอย่างชัดเจนว่าเราไม่ควรมีวิธีใดในการเข้าถึงรหัสผ่านแบบข้อความธรรมดา ฉันจะโพสต์อีเมลเมื่อเขียนเสร็จแล้ว น่าเสียดายที่ฉันไม่คิดว่าเขาแค่ทดสอบเรา สิ่งเหล่านี้อยู่ในนโยบายความปลอดภัยอย่างเป็นทางการของบริษัทในขณะนี้ อย่างไรก็ตาม ฉันได้ตั้งวงล้อให้เคลื่อนออกจากพวกเขาและเข้าสู่ PayPal ในขณะนี้

อัปเดต 2 (วันเสาร์ที่ 23)

นี่คืออีเมลที่ฉันร่างไว้ มีข้อเสนอแนะอะไรให้เพิ่ม/ลบ/เปลี่ยนแปลงไหม

Hi [name],

Unfortunately there is no way for us to provide you with some of the information requested, mainly plain-text passwords, password history, SSH keys and remote file logs. Not only are these things technically impossible, but also being able to provide this information would be both a against PCI Standards, and a breach of the data protection act.
To quote the PCI requirements,

8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

I can provide you with a list of usernames and hashed passwords used on our system, copies of the SSH public keys and authorized hosts file (This will give you enough information to determine the number of unique users can connect to our servers, and the encryption methods used), information about our password security requirements and our LDAP server but this information may not be taken off site. I strongly suggest you review your audit requirements as there is currently no way for us to pass this audit while remaining in compliance of PCI and the Data Protection act.

Regards,
[me]

ฉันจะเป็น CC ใน CTO ของบริษัทและผู้จัดการบัญชีของเรา และฉันหวังว่า CTO จะยืนยันได้ว่าไม่มีข้อมูลนี้ ฉันจะติดต่อ PCI Security Standards Council เพื่ออธิบายสิ่งที่เขาต้องการจากเรา

อัปเดต 3 (26)

นี่คืออีเมลบางส่วนที่เราแลกเปลี่ยนกัน

RE: อีเมลฉบับแรกของฉัน;

As explained, this information should be easily available on any well maintained system to any competent administrator. Your failure to be able to provide this information leads me to believe you are aware of security flaws in your system and are not prepared to reveal them. Our requests line up with the PCI guidelines and both can be met. Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use.

I see no data protection issues for these requests, data protection only applies to consumers not businesses so there should be no issues with this information.

อะไรนะ ฉันทำไม่ได้ แม้แต่...

"Strong cryptography only means the passwords must be encrypted while the user is inputting them but then they should be moved to a recoverable format for later use."

ฉันจะใส่กรอบและวางไว้บนผนังของฉัน

ฉันเบื่อหน่ายกับการเจรจาต่อรองและแนะนำให้เขาไปที่กระทู้นี้เพื่อแสดงคำตอบที่ฉันได้รับ:

Providing this information DIRECTLY contradicts several requirements of the PCI guidelines. The section I quoted even says storage (Implying to where we store the data on the disk). I started a discussion on ServerFault.com (An on-line community for sys-admin professionals) which has created a huge response, all suggesting this information cannot be provided. Feel free to read through yourself

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

We have finished moving over our system to a new platform and will be cancelling our account with you within the next day or so but I want you to realize how ridiculous these requests are, and no company correctly implementing the PCI guidelines will, or should, be able to provide this information. I strongly suggest you re-think your security requirements as none of your customers should be able to conform to this.

(ฉันลืมไปจริงๆ ว่าฉันเคยเรียกเขาว่าไอ้งี่เง่าในชื่อเรื่อง แต่อย่างที่กล่าวไว้ เราได้ย้ายออกจากแพลตฟอร์มของพวกเขาแล้ว ดังนั้นจึงไม่มีการสูญเสียจริง ๆ )

และในคำตอบของเขา เขากล่าวว่าเห็นได้ชัดว่าไม่มีใครรู้ว่าคุณกำลังพูดถึงอะไร:

I read in detail through those responses and your original post, the responders all need to get their facts right. I have been in this industry longer than anyone on that site, getting a list of user account passwords is incredibly basic, it should be one of the first things you do when learning how to secure your system and is essential to the operation of any secure server. If you genuinely lack the skills to do something this simple I'm going to assume you do not have PCI installed on your servers as being able to recover this information is a basic requirement of the software. When dealing with something such as security you should not be asking these questions on a public forum if you have no basic knowledge of how it works.

I would also like to suggest that any attempt to reveal me, or [company name] will be considered libel and appropriate legal action will be taken

ประเด็นงี่เง่าที่สำคัญหากคุณพลาด:

  • เขาเป็นเจ้าหน้าที่ตรวจสอบความปลอดภัยมายาวนานกว่าใครๆ ในที่นี้ (เขากำลังเดาหรือสะกดรอยตามคุณ)
  • ความสามารถในการรับรายการรหัสผ่านบนระบบ UNIX นั้นเป็น 'พื้นฐาน'
  • PCI เป็นซอฟต์แวร์แล้ว
  • ผู้คนไม่ควรใช้ฟอรัมเมื่อไม่มั่นใจในความปลอดภัย
  • การวางข้อมูลข้อเท็จจริง (ซึ่งฉันมีหลักฐานอีเมล) ทางออนไลน์เป็นการหมิ่นประมาท

ยอดเยี่ยม.

PCI SSC ได้ตอบกลับและกำลังตรวจสอบเขาและบริษัท ซอฟต์แวร์ของเราได้ย้ายไปใช้ PayPal แล้ว เราจึงรู้ว่าปลอดภัย ฉันจะรอให้ PCI กลับมาหาฉันก่อน แต่ฉันกังวลเล็กน้อยว่าพวกเขาอาจใช้แนวทางปฏิบัติด้านความปลอดภัยเหล่านี้ภายใน ถ้าใช่ ฉันคิดว่ามันเป็นความกังวลหลักสำหรับเรา เนื่องจากการประมวลผลบัตรทั้งหมดของเราผ่านพ้นไป หากพวกเขาทำสิ่งนี้ภายใน ฉันคิดว่าสิ่งเดียวที่ต้องทำคือแจ้งให้ลูกค้าของเราทราบ

ฉันหวังว่าเมื่อ PCI รู้ว่ามันแย่แค่ไหน พวกเขาจะตรวจสอบทั้งบริษัทและระบบ แต่ฉันไม่แน่ใจ

ดังนั้นตอนนี้เราจึงได้ย้ายออกจากแพลตฟอร์มของพวกเขา และคาดว่าจะต้องใช้เวลาอย่างน้อยสองสามวันก่อนที่ PCI จะติดต่อกลับมาหาฉัน มีคำแนะนำที่สร้างสรรค์สำหรับวิธีที่จะหลอกล่อเขาสักหน่อยไหม? =)

เมื่อฉันได้รับใบอนุญาตจากทนายความของฉันแล้ว (ฉันสงสัยอย่างยิ่งว่าสิ่งนี้เป็นการหมิ่นประมาทจริงๆ แต่ฉันต้องการตรวจสอบอีกครั้ง) ฉันจะเผยแพร่ชื่อบริษัท ชื่อและอีเมลของเขา และหากคุณต้องการ คุณสามารถติดต่อเขาและอธิบายได้ เหตุใดคุณจึงไม่เข้าใจพื้นฐานของการรักษาความปลอดภัยของ Linux เช่น วิธีรับรายการรหัสผ่านผู้ใช้ LDAP ทั้งหมด

ปรับปรุงเล็กน้อย:

"นักกฎหมาย" ของฉันได้แนะนำให้เปิดเผยบริษัทอาจจะก่อให้เกิดปัญหามากกว่าที่จำเป็น ฉันสามารถพูดได้ว่านี่ไม่ใช่ผู้ให้บริการรายใหญ่ พวกเขามีลูกค้าน้อยกว่า 100 รายที่ใช้บริการนี้ เดิมทีเราเริ่มใช้งานเมื่อไซต์มีขนาดเล็กและใช้ VPS เพียงเล็กน้อย และเราไม่ต้องการใช้ความพยายามทั้งหมดเพื่อให้ได้ PCI (เราเคยเปลี่ยนเส้นทางไปยังส่วนหน้า เช่น PayPal Standard) แต่เมื่อเราเปลี่ยนไปใช้การ์ดประมวลผลโดยตรง (รวมถึงการรับ PCI และสามัญสำนึก) ผู้พัฒนาจึงตัดสินใจใช้บริษัทเดิมต่อไปเพียงแค่ใช้ API อื่น บริษัทตั้งอยู่ในเขตเบอร์มิงแฮม ประเทศอังกฤษ ดังนั้นฉันจึงสงสัยอย่างยิ่งว่าทุกคนที่นี่จะได้รับผลกระทบ

answer

ประการแรก อย่ายอมจำนน เขาไม่ได้เป็นเพียงคนงี่เง่า แต่ผิดอย่างมหันต์ อันที่จริง การเปิดเผยข้อมูลนี้จะละเมิดมาตรฐาน PCI (ซึ่งเป็นสิ่งที่ฉันคิดว่าการตรวจสอบนั้นใช้เนื่องจากเป็นตัวประมวลผลการชำระเงิน) ควบคู่ไปกับมาตรฐานอื่น ๆ ทั้งหมดที่มีอยู่และสามัญสำนึกธรรมดา นอกจากนี้ยังจะทำให้บริษัทของคุณต้องรับผิดทุกประเภทอีกด้วย

สิ่งต่อไปที่ฉันจะทำคือส่งอีเมลถึงเจ้านายของคุณโดยแจ้งว่าเขาต้องการปรึกษากับองค์กรที่เกี่ยวข้องเพื่อพิจารณาการเปิดเผยทางกฎหมายที่บริษัทจะต้องเผชิญโดยดำเนินการตามขั้นตอนนี้

บิตสุดท้ายนี้ขึ้นอยู่กับคุณ แต่ฉันจะติดต่อ VISA พร้อมข้อมูลนี้และดึงสถานะผู้ตรวจสอบ PCI ของเขา

ในฐานะที่เป็นคนที่เคยผ่านขั้นตอนการตรวจสอบกับPrice Waterhouse Coopersสำหรับสัญญาลับของรัฐบาล ฉันรับรองได้เลยว่าเรื่องนี้ไม่มีปัญหาและผู้ชายคนนี้บ้าไปแล้ว

เมื่อ PwC ต้องการตรวจสอบความเข้มงวดของรหัสผ่าน พวกเขา:

  • ขอให้ดูอัลกอริธึมความแรงของรหัสผ่านของเรา
  • เรียกใช้หน่วยทดสอบกับอัลกอริธึมของเราเพื่อตรวจสอบว่าพวกเขาจะปฏิเสธรหัสผ่านที่ไม่ดี
  • ขอให้ดูอัลกอริธึมการเข้ารหัสของเราเพื่อให้แน่ใจว่าไม่สามารถย้อนกลับหรือยกเลิกการเข้ารหัสได้ (แม้จะเป็นตารางสีรุ้ง) แม้แต่ผู้ที่มีสิทธิ์เข้าถึงทุกแง่มุมของระบบ
  • ตรวจสอบเพื่อดูว่ารหัสผ่านก่อนหน้านี้ถูกแคชเพื่อให้แน่ใจว่าไม่สามารถใช้ซ้ำได้
  • ขออนุญาตจากเรา (ซึ่งเราอนุญาต) เพื่อให้พวกเขาพยายามเจาะเข้าไปในเครือข่ายและระบบที่เกี่ยวข้องโดยใช้เทคนิคทางวิศวกรรมที่ไม่ใช่ทางสังคม (เช่น xss และการหาช่องโหว่ที่ไม่ใช่ 0 วัน)

หากฉันบอกเป็นนัยว่าฉันสามารถแสดงให้พวกเขาเห็นว่ารหัสผ่านของผู้ใช้คืออะไรในช่วง 6 เดือนที่ผ่านมา พวกเขาจะปิดเราออกจากสัญญาทันที

หากสามารถระบุข้อกำหนดเหล่านี้ได้ คุณจะล้มเหลวในทันทีทุกครั้งที่มีการตรวจสอบ


อัปเดต: อีเมลตอบกลับของคุณดูดี เป็นมืออาชีพมากกว่าสิ่งที่ฉันจะเขียน

พูดตามตรง ดูเหมือนว่าผู้ชายคนนี้ (ผู้ตรวจสอบบัญชี) กำลังตั้งคุณอยู่ หากคุณให้ข้อมูลที่เขาขอ แสดงว่าคุณเพิ่งพิสูจน์ให้เขาเห็นว่าคุณสามารถออกแบบทางโซเชียลเพื่อทิ้งข้อมูลภายในที่สำคัญได้ ล้มเหลว.

ฉันเพิ่งเห็นว่าคุณอยู่ในสหราชอาณาจักร ซึ่งหมายความว่าสิ่งที่เขาขอให้คุณทำคือฝ่าฝืนกฎหมาย (ตามจริงแล้วพระราชบัญญัติคุ้มครองข้อมูล) ฉันอยู่ในสหราชอาณาจักรด้วย ทำงานให้กับบริษัทขนาดใหญ่ที่ได้รับการตรวจสอบอย่างเข้มงวด และรู้กฎหมายและแนวปฏิบัติทั่วไปเกี่ยวกับเรื่องนี้ ฉันยังเป็นงานที่น่ารังเกียจมากที่จะควบคุมผู้ชายคนนี้ให้คุณถ้าคุณชอบเพียงเพื่อความสนุก แจ้งให้เราทราบหากคุณต้องการความช่วยเหลือ ตกลง

คุณกำลังถูกออกแบบเพื่อสังคม ไม่ว่าจะเป็นเพื่อ 'ทดสอบคุณ' หรือแฮ็กเกอร์ที่ปลอมตัวเป็นผู้สอบบัญชีเพื่อรับข้อมูลที่เป็นประโยชน์

ฉันกังวลอย่างจริงจังเกี่ยวกับ OPs ที่ขาดทักษะในการแก้ปัญหาด้านจริยธรรมและชุมชนความผิดพลาดของเซิร์ฟเวอร์ละเลยการฝ่าฝืนจรรยาบรรณอย่างโจ่งแจ้งนี้

In short, I need;

  • A way to 'fake' six months worth of password changes and make it look valid
  • A way to 'fake' six months of inbound file transfers

ให้ฉันชัดเจนในสองประเด็น:

  1. ไม่เหมาะสมที่จะปลอมแปลงข้อมูลในระหว่างการดำเนินธุรกิจตามปกติ
  2. คุณไม่ควรเปิดเผยข้อมูลประเภทนี้ให้ใครทราบ เคย.

ไม่ใช่หน้าที่ของคุณที่จะปลอมแปลงบันทึก เป็นหน้าที่ของคุณที่จะต้องตรวจสอบให้แน่ใจว่าบันทึกที่จำเป็นพร้อมใช้งาน ถูกต้อง และปลอดภัย

ชุมชนที่ Server Fault ต้องจัดการกับคำถามประเภทนี้ เนื่องจากไซต์ stackoverflow จัดการกับคำถาม "การบ้าน" คุณไม่สามารถแก้ไขปัญหาเหล่านี้ได้ด้วยการตอบสนองทางเทคนิคหรือเพิกเฉยต่อการละเมิดความรับผิดชอบทางจริยธรรม

การได้เห็นผู้ใช้ที่มีตัวแทนจำนวนมากตอบกลับมาในกระทู้นี้ และการไม่เอ่ยถึงความหมายทางจริยธรรมของคำถามทำให้ฉันเสียใจ

ฉันอยากจะแนะนำให้ทุกคนอ่านผู้ดูแลระบบ SAGE จรรยาบรรณ

BTW ผู้ตรวจสอบความปลอดภัยของคุณเป็นคนงี่เง่า แต่นั่นไม่ได้หมายความว่าคุณต้องรู้สึกกดดันให้ทำงานผิดจรรยาบรรณ

แก้ไข: การอัปเดตของคุณไม่มีค่า ก้มหน้าลง ผงแป้งแห้ง และอย่าหยิบ (หรือให้) เศษไม้ใดๆ

คุณไม่สามารถให้สิ่งที่คุณต้องการกับเขาได้ และพยายาม "ปลอมแปลง" มันมักจะกลับมากัดคุณที่ก้น (อาจเป็นในทางถูกกฎหมาย) คุณจำเป็นต้องอุทธรณ์สายการบังคับบัญชา (เป็นไปได้ว่าผู้ตรวจสอบรายนี้จะเป็นคนหลอกลวง แม้ว่าการตรวจสอบความปลอดภัยจะเป็นคนงี่เง่าอย่างฉาวโฉ่ - ถามฉันเกี่ยวกับผู้ตรวจสอบที่ต้องการเข้าถึง AS/400 ผ่าน SMB) หรือไปนรก ออกจากภายใต้ข้อกำหนดที่น่าสยดสยองเหล่านี้

พวกเขาไม่ได้แม้กระทั่งการรักษาความปลอดภัยที่ดี - รายการของรหัสผ่าน plaintext ทั้งหมดเป็นอย่างไม่น่าเชื่อสิ่งที่อันตรายจะเคยผลิตโดยไม่คำนึงถึงวิธีการที่ใช้เพื่อปกป้องพวกเขาและฉันจะเดิมพันเจ้าหมอนี้จะต้องการให้พวกเขาส่งอีเมลในข้อความธรรมดา . (ฉันแน่ใจว่าคุณรู้เรื่องนี้แล้ว ฉันแค่ต้องระบายนิดหน่อย)

สำหรับเรื่องไร้สาระและหัวเราะคิกคัก ให้ถามเขาตรงๆ ว่าจะทำตามข้อกำหนดของเขาอย่างไร ยอมรับว่าคุณไม่รู้วิธีและต้องการใช้ประสบการณ์ของเขาให้เกิดประโยชน์ เมื่อคุณออกไปข้างนอกแล้ว คำตอบของเขาคือ "ฉันมีประสบการณ์มากกว่า 10 ปีในการตรวจสอบความปลอดภัย" ก็คือ "ไม่ คุณมีประสบการณ์ 5 นาทีซ้ำแล้วซ้ำอีกหลายร้อยครั้ง"

ผู้ตรวจสอบบัญชีไม่ควรทำให้คุณผิดหวังหากพวกเขาพบปัญหาในอดีตที่คุณแก้ไขแล้ว อันที่จริง นั่นเป็นหลักฐานของพฤติกรรมที่ดี ด้วยเหตุนี้ฉันขอแนะนำสองสิ่ง:

ก) อย่าโกหกหรือแต่งเรื่อง ข) อ่านนโยบายของคุณ

ข้อความสำคัญสำหรับฉันคือสิ่งนี้:

All [generic credit card processing provider] clients are required to conform with our new security policies

ฉันพนันได้เลยว่ามีคำสั่งในนโยบายเหล่านั้นที่บอกว่ารหัสผ่านไม่สามารถเขียนลงไปได้และไม่สามารถส่งต่อให้ใครก็ได้นอกจากผู้ใช้ หากมี ให้ใช้นโยบายเหล่านั้นกับคำขอของเขา ฉันขอแนะนำให้จัดการแบบนี้:

  • A list of current usernames and plain-text passwords for all user accounts on all servers

แสดงรายการชื่อผู้ใช้ให้เขา แต่ไม่อนุญาตให้ลบออก อธิบายว่าการให้รหัสผ่านแบบข้อความธรรมดานั้น ก) เป็นไปไม่ได้เพราะเป็นแบบทางเดียว และ ข) ขัดต่อนโยบายที่เขาตรวจสอบคุณ ดังนั้นคุณจะไม่ปฏิบัติตาม

  • A list of all password changes for the past six months, again in plain-text

อธิบายว่าสิ่งนี้ไม่มีอยู่ในประวัติศาสตร์ แสดงรายการเวลาเปลี่ยนรหัสผ่านล่าสุดให้เขาเพื่อแสดงว่าขณะนี้กำลังดำเนินการเสร็จสิ้น อธิบายดังที่กล่าวข้างต้นว่าจะไม่มีการให้รหัสผ่าน

  • A list of "every file added to the server from remote devices" in the past six months

อธิบายว่าอะไรคืออะไรและไม่ถูกบันทึก ให้สิ่งที่คุณทำได้ อย่าให้ข้อมูลที่เป็นความลับและอธิบายตามนโยบายว่าเพราะเหตุใด ถามว่าจำเป็นต้องปรับปรุงการบันทึกของคุณหรือไม่

  • The public and private keys of any SSH keys

ดูนโยบายการจัดการหลักของคุณ ควรระบุว่าไม่อนุญาตให้ใช้คีย์ส่วนตัวออกจากคอนเทนเนอร์และมีเงื่อนไขการเข้าถึงที่เข้มงวด ใช้นโยบายนั้นและไม่อนุญาตให้เข้าถึง กุญแจสาธารณะเป็นสาธารณะอย่างมีความสุขและสามารถแชร์ได้

  • An email sent to him every time a user changes their password, containing the plain text password

แค่บอกว่าไม่ หากคุณมีเซิร์ฟเวอร์บันทึกการรักษาความปลอดภัยในเครื่อง อนุญาตให้เขาเห็นว่ากำลังเข้าสู่ระบบในแหล่งกำเนิด

โดยพื้นฐานแล้ว และฉันขอโทษที่ต้องพูดแบบนี้ แต่คุณต้องเล่นไม้แข็งกับผู้ชายคนนี้ ปฏิบัติตามนโยบายของคุณอย่างเคร่งครัดไม่เบี่ยงเบน อย่าโกหก. และถ้าเขาทำให้คุณผิดหวังในเรื่องที่ไม่อยู่ในนโยบาย ให้ไปร้องเรียนกับรุ่นพี่ของบริษัทที่ส่งเขามา รวบรวมเอกสารทั้งหมดนี้เพื่อพิสูจน์ว่าคุณมีเหตุผล หากคุณละเมิดนโยบายของคุณ แสดงว่าคุณอยู่ในความเมตตาของเขา ถ้าคุณทำตามจดหมาย เขาจะถูกไล่ออก

ใช่ ผู้ตรวจสอบบัญชีเป็นคนงี่เง่า อย่างไรก็ตาม อย่างที่คุณรู้ บางครั้งคนงี่เง่าก็อยู่ในตำแหน่งที่มีอำนาจ นี่เป็นหนึ่งในกรณีเหล่านั้น

ข้อมูลที่เขาขอไม่มีผลกับความปลอดภัยในปัจจุบันของระบบ อธิบายให้ผู้ตรวจสอบทราบว่าคุณใช้ LDAP สำหรับการตรวจสอบสิทธิ์ และรหัสผ่านถูกจัดเก็บโดยใช้แฮชทางเดียว หากไม่มีการทำสคริปต์บังคับกับแฮชรหัสผ่าน (ซึ่งอาจใช้เวลาหลายสัปดาห์ (หรือหลายปี) คุณจะไม่สามารถระบุรหัสผ่านได้

ในทำนองเดียวกัน ไฟล์ระยะไกล - ฉันอยากได้ยิน เป็นไปได้ว่าเขาคิดว่าคุณควรจะแยกความแตกต่างระหว่างไฟล์ที่สร้างโดยตรงบนเซิร์ฟเวอร์กับไฟล์ที่ SCP ไปที่เซิร์ฟเวอร์ได้อย่างไร

อย่างที่ @womble บอก อย่าเสแสร้ง สิ่งนั้นจะไม่เกิดผลดี ยกเลิกการตรวจสอบนี้และปรับนายหน้ารายอื่น หรือหาวิธีโน้มน้าวให้ "มืออาชีพ" คนนี้เชื่อว่าชีสของเขาหลุดออกจากแครกเกอร์ของเขา

Have your "security auditor" point to any text from any of these documents that have his requirements and watch as he struggles to come up with an excuse and eventually excuses himself to never be heard from again.

WTF! Sorry but that's my only reaction to this. There are no audit requirements I have ever heard of that require a plaintext password, let alone feeding them the passwords as they change.

1st, ask him to show you the requirement that you provide that.

2nd, if this is for PCI (which we all assume since it's a payment system question) go here: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php and get a new auditor.

3rd, follow what they said above, contact your management and have them contact the QSA company he is working with. Then immediately get another auditor.

Auditors audit system states, standards, processes, etc. They have no need to have any information that provides them access to systems.

If you would like any recommended auditors or alternate colo's that work closely with auditors contact me and I'd be happy to provide references.

Good luck! Trust your gut, if something seems wrong it probably is.

There is no legitimate reason for him to know the password and have access to the private keys. What he requested would give him the ability to impersonate any of your clients at any point in time and siphon as much money as he wants, without any way to detect it as a possible fraudulent transaction. It'll be exactly the type of security threats he's supposed to audit you for.

Notify management that the Auditor has requested that you breech your security policies, and that the request is illegal. Suggest that they may want to dump the present auditing firm and find a legitimate one. Call the police and turn the auditor in for requesting illegal information (in the UK). Then call the PCI and turn in the Auditor for their request.

The request is akin to asking you do go murder someone at random and hand over the body. Would you do that? or would you call the cops and turn them in?

ตอบโต้ด้วยคดีความ . หากผู้ตรวจสอบขอรหัสผ่านที่เป็นข้อความธรรมดา (เอาล่ะ ไม่ยากเลยที่จะแฮชรหัสผ่านที่คาดเดายาก) พวกเขาอาจโกหกคุณเกี่ยวกับข้อมูลประจำตัวของพวกเขา

เคล็ดลับเกี่ยวกับวิธีการใช้คำพูดของคุณ:

Unfortunately there is no way for us to provide you with some of the information requested, mainly plain-text passwords, password history, SSH keys and remote file logs. Not only are these things technically impossible...

I would rephrase this to avoid getting into a discussion about technical feasibility. Reading the awful initial e-mail sent by the auditor, it looks like this is someone who can pick on details that are not related to the main problem, and he might argue that you could save passwords, log logins, etc. So either say:

... Due to our strict security policies, we have never logged passwords in plain text. Therefore, it will be technically impossible to provide this data.

Or

... Not only would we be significantly lowering our internal security level by complying to your request, ...

Good luck, and keep us posted how this ends!

At the risk of continuing the rush of high-rep users jumping in on this question, here are my thoughts.

I can kind of vaguely see why he wants the plaintext passwords, and that's to judge the quality of the passwords in use. It's a crap way to go about that, most auditors I know will accept the crypted hashes and run a cracker to see what kind of low-hanging fruit they can pull out. All of 'em will go over the password-complexity policy and review what safeguards are in place to enforce that.

But you have to deliver some passwords. I suggest (though I think you may have already done this) asking him what the goal of the plaintext password delivery is. He said it is to validate your compliance versus security policy, so get him to give you that policy. Ask him if he'll accept that your password complexity regime is robust enough to prevent users from setting their password to [email protected] and have provably been in place for the 6 months in question.

If he pushes it, you may have to admit that you can't deliver plaintext passwords since you're not set up to record them (what with it being a major security failing), but can endeavor to so in the future if he requires direct verification that your password policies are working. And if he wants to prove it, you'll happily provide the crypted password database for him (or you! Show willing! It helps!) to run a cracking pass over.

The "remote files" can likely be pulled out of the SSH logs for SFTP sessions, which is what I suspect he's talking about. If you don't have 6 months worth of syslogging, this'll be hard to produce. Is using wget to pull a file from a remote server while logged in via SSH considered a 'remote file transfer'? Are HTTP PUTs? Files created from clipboard text in the remote-user's terminal window? If anything, you can pester him with these edge-cases to get a better feel for his concerns in this area and perhaps instil the "I know more about this than you do" feeling, as well as what specific technologies he's thinking about. Then extract what you can out of logs and archived logs on backups.

I got nothing on the SSH keys. The only thing I can think of is that he's checking for passwordless keys for some reason, and maybe crypto strength. Otherwise, I got nothing.

As for getting those keys, harvesting at least the public keys is easy enough; just troll the .ssh folders looking for them. Getting the private keys will involve donning your BOFH hat and harumping at your users to the tune of, "Send me your public and private SSH key-pairs. Anything I don't get will be purged from the servers in 13 days," and if anyone squawks (I would) point 'em at the security audit. Scripting is your friend here. At minimum it'll cause a bunch of password-less keypairs to get passwords.

If he still insists on "plain-text passwords in email" at least subject those emails to GPG/PGP encryption with his own key. Any security auditor worth his salt should be able to handle something like that. That way if the passwords leak, it'll be because he let 'em out, not you. Yet another litmus test for competence.


I have to agree with both Zypher and Womble on this one. Dangerous idiot with dangerous consequences.

He is probably testing you to see if you are a security risk. If you provide these details to him then you will probably be instantly dismissed. Take this to your immediate boss and pass the buck. Let your boss know that you will involve the relevant authorities if this arse comes anywhere near you again.

That's what bosses are paid for.

I have a vision of a piece of paper left in the back of a taxi cab that has a list of passwords, SSH keys and user names on it! Hhhmmm! Can see the newspaper headlines right now!

Update

In response to the 2 comments below I guess you both have good points to make. There is no way of really finding out the truth and the fact the question was posted at all shows a little naiveté on the part of the poster as well as courage to face an adverse situation with potential career consequences where others would stick their head in the sand and run away.

My conclusion for what it's worth is that this is a thoroughly interesting debate that has probably got most readers wondering what they would do in this situation regardless of whether or not the auditor or the auditors policies are competent. Most people will face this kind of dilemma in some shape or form in their working lives and this really isn't the kind of responsibility that should be shoved onto one single persons shoulders. It's a business decision rather than an individuals decision as to how to deal with this.

Clearly there is a lot of good info here, but allow me to add my 2c, as someone who writes software which is sold worldwide by my employer to large enterprises primarily to assist people in complying with account management security policies and passing audits; for what that is worth.

First, this sounds very suspicious, as you (and others) have noted. Either the auditor is just following a procedure he doesn't understand (possible), or testing you for vulnerability so social engineering (unlikely after followup exchanges), or a fraud social engineering you (also possible), or just a generic idiot (probably most likely). As far as advice, I'd offer that you should speak to your management, and/or find a new auditing company, and/or report this one to the appropriate oversight agency.

As for notes, a couple things:

  • It is possible (under specific conditions) to provide the information he requested, if your system is set up to allow it. It is not, however, in any sense a "best practice" for security, nor would it be at all common.
  • Generally, audits are concerned with validating practices, not examining actual secure information. I'd be highly suspicious of anyone asking for actual plain-text passwords or certificates, rather than the methods used to ensure they are "good" and secured properly.

Hope that helps, even if it's mostly reiterating what other people have advised. Like you, I'm not going to name my company, in my case because I'm not speaking for them (personal account/opinions and all); apologies if that detracts from credibility, but so be it. Good luck.

This could and should be posted to the IT Security - Stack Exchange.

I'm not an expert in security auditing, but the first thing I've learned about security policy is "NEVER GIVE PASSWORDS AWAY". This guy maybe has been in this business for 10 years, but like Womble said "no, you have 5 minutes of experience repeated hundreds of times"

I've been working with banking IT people for some time, and when I saw you post, I showed it to them... They were laughing so hard. They told me that guy looks like a scam. They used to deal with this kind of thing for the security of the bank customer.

Asking for clear password, SSH keys, password logs, is clearly a serious professional misconduct. This guy is dangerous.

I hope everything is alright now, and that you don't have any problem with the fact they can have kept log of your previous transaction with them.

If you can provide any of the information (with the possible exception of the public keys) requested in points 1,2,4, and 5 you should expect to fail the audit.

Formally respond to points 1,2 and 5 saying you cannot comply as your security policy requires that you do not keep plain text passwords and that passwords are encrypted using a non reversible algorithm. To point 4, again, you cannot supply the private keys as it would violate your security policy.

As to point 3. If you have the data provide it. If you don't because you didn't have to collect it then say so and demonstrate how you are now (working towards) meeting the new requirement.

A security auditor for our servers has demanded the following within two weeks:

...

If we fail the security audit we loose access to our card processing platform (a critical part of our system) and it would take a good two weeks to move somewhere else. How screwed am I?

It appears as though you have answered your own question. (See bolded text for hints.)

Only one solution comes to mind: get everyone to write down their last and current password and then immediately change it to a new one. If he's wanting to test password quality (and the quality of transitions from password to password, e.g. to make sure nobody uses rfvujn125 and then rfvujn126 as their next password,) that list of old passwords should be sufficient.

If that is not deemed acceptable, then I'd suspect the guy is a member of Anonymous/LulzSec... at which point you should ask him what his handle is and tell him to quit being such a scrub!

As oli said: the person in question is trying to get you to break the law (Data Protection/EU confidentiality directives)/internal regulations/PCI standards. Not only should you have to notify management (as you already did I think), but you can call the police as suggested.

If the person in question holds some kind of accreditation/certification, e.g. CISA (Certified Information Systems Auditor), or the UK equivalent of US CPA (a public accountant designation), you could also inform the accrediting organisations to investigate him for this. Not only is that person trying to get you to break the law, it's also extremely incompetent "auditing" and probably in contravention of every ethical audit standard by which accredited auditors must abide on pain of loss of accreditation.

Additionally, if the person in question is member of a larger company, forementioned auditing organisations often require some kind of QA department that oversees quality of audits and audit filing and investigates complaints. So you may also have a go at complaining to the audit company in question.

I'm still studying and the first thing I learned when setting up servers is that if you make it possible to log plaintext passwords, you already endanger yourself for a giant breach. No password should be known except to the user that employs it.

If this guy is a serious auditor he shouldn't be asking you these things. To me he kind of sounds like a misfeasor. I'd check with the regulating organ because this guy sounds like a complete idiot.

Update

Hold on, he believes you should use a symmetric encryption just to transmit the password, but then store them plaintext in your database, or provide a way to decrypt them. So basically, after all the anonymous attacks on databases, where they showed plain text user passwords, he STILL believes this is a good way of "securing" an environment.

He is a dinosaur stuck in the 1960s...

  • A list of current usernames and plain-text passwords for all user accounts on all servers
    • Current usernames MAY be within scope of "we can release this" and should be within scope of "we can show you this, but you may not take it off-site".
    • Plain-text passwords should not exist for longer than it takes to one-way hash them and they should certainly never leave memory (not even to go across wires), so their existence in permanent storage is a no-no.
  • A list of all password changes for the past six months, again in plain-text
    • See "permanent storage is a no-no".
  • A list of "every file added to the server from remote devices" in the past six months
    • This may be to ensure that you log file transfers to/from payment-processing server(s), if you have the logs it should be OK to pass on. If you don't have teh logs, check what the relevant security policies say about logging that info.
  • The public and private keys of any SSH keys
    • Maybe an attempt to check that 'SSH keys must have a pass-phrase' is in the policy and followed. You do want pass-phrases on all private keys.
  • An email sent to him every time a user changes their password, containing the plain text password
    • This is most definitely a no-no.

I'd respond with something along the lines of my answers, backed up by PCI-compliance, SOX_compliance and internal security policy documents as needed.

This guys request reeks to high heaven, and I'd agree that any correspondence from here on out should be going through the CTO. Either he's trying to make you the fall guy for not being able to meet said request, for releasing confidential information, or is grossly incompetent. Hopefully your CTO/manager will do a double take on this guys request and positive action will be done, and if they're gung ho behind this guy's actions....well, good sys admins are always in demand on the classifieds, as ti sounds like it's time to start looking for some place out if that happens.

I would tell him that it takes time, effort and money to build the cracking infrastructure for the passwords, but because you use strong hashing like SHA256 or whatever, it might not be possible to provide the passwords within 2 weeks. On the top of that, I would tell that I contacted legal department to confirm if it is lawful to share this data with anybody. PCI DSS also a good idea to mention as you did. :)

My colleagues are shocked by reading this post.

I would be strongly tempted to give him a list of username/passwords/private keys for honeypot accounts then if he ever tests the logins for these accounts do him for unauthorised access to a computer system. Though, unfortunately this probably exposes you to at a minimum some kind of civil tort for making a fraudulent representation.

Simply decline revealing the information, stating that you can not pass on the passwords as you do not have access to them. Being an auditor myself, he must be representing some institution. Such institutions generally publish guidelines for such an audit. See if such a request conforms to those guidelines. You can even complain to such associations. Also make it clear to the auditor that in case of any wrongdoings the blame may come back to him (the auditor) as he has all the passwords.

I would say that there is no way for you to provide him with ANY of the information requested.

  • Usernames provide him with an insight into the accounts that have access to your systems, a security risk
  • Password history would provide an insight into password patterns used giving him a possible avenue of attack by guessing the next password in the chain
  • Files transferred to the system may contain confidential information that could be used in an attack against your systems, as well as giving them an insight into your file system structure
  • Public and private keys, what the hell would be the point in having them if you were to give them out to someone other than the intended user?
  • An email sent every time a user changes a password would give him up to date passwords for every user account.

This guy is pulling your plonker mate! You need to get in touch with either his manager or some other auditor in the company to confirm his outrageous demands. And move away ASAP.

Problem solved by now, but for the benefit of future readers ...

Considering that:

  • You seem to have spent more than an hour on this.

  • You've had to consult the company's legal counsel.

  • They're asking for a lot of work after altering your agreement.

  • You'll be out money and more time switching over.

You should explain that you'll need a lot of money up front and there's a four hour minimum.

Last few times I told someone that they suddenly weren't so needy.

You can still bill them for any loss incurred during switchover and for the time taken, since they changed your agreement. I'm not saying that they'll pay within two weeks, much as they thought you would comply within that time - they'll be one-sided, I have no doubt.

It will rattle them if your lawyer's office sends the collection notice. It should attract the attention of the owner of the auditor's company.

I would advise against any further dealings with them, just to further discuss the matter will entail a deposit for the work required. Then you can be paid for telling them off.

It's odd that you have an agreement in effect and then someone at the other end would go off the rails - if it's not a test of security or intelligence it's certainly a test of your patience.