Security Mindset & Core Principles

เวลาเกิดเหตุเงินออกจากบัญชีลูกค้าโดยเจ้าตัวไม่ได้สั่ง ทีมมักเริ่มด้วยคำถามว่า “ระบบถูก hack ตรงไหน” แต่คำถามที่ควรถามก่อนคือ กำลังปกป้องอะไร จากใคร และความเสียหายแบบไหนที่ยอมรับไม่ได้

ระบบ e-wallet อาจเปิด TLS ทุก endpoint, บังคับ MFA พนักงาน และเข้ารหัส database แล้ว แต่ถ้า call center เปลี่ยนเบอร์โทรให้ผู้โทรที่ตอบเพียงวันเกิดได้ ผู้โจมตีก็ไม่จำเป็นต้อง เจาะ cryptography เลย Security จึงไม่ใช่รายการเครื่องมือ แต่เป็นวิธีคิดเกี่ยวกับ assumption, boundary และ failure ตลอดอายุของระบบ

Start with the Asset#

Security ที่ไม่มี asset ชัดเจนจะกลายเป็นการซื้อเครื่องมือก่อนรู้ปัญหา สำหรับระบบ wallet คำว่า “ข้อมูลลูกค้า” กว้างเกินไป จึงควรระบุให้ละเอียดกว่านั้น:

Asset ไม่ได้มีแต่ข้อมูล server: mobile device, recovery process, พนักงาน support, CI/CD pipeline, DNS record, cloud account และชื่อเสียงองค์กรล้วนเป็น asset หรือเป็นทางเข้าถึง asset

Build a Precise Vocabulary#

คำเหล่านี้มักถูกใช้แทนกันจนทีมแก้ผิดจุด:

Vulnerability 1 จุดไม่ได้มี risk เท่ากันเสมอ endpoint ทดลองที่ไม่มีข้อมูลจริงกับ endpoint โอนเงินอาจมี bug แบบเดียวกัน แต่ impact และ priority ต่างกันมาก

Risk Is Not Just a Score#

สูตรแบบง่ายช่วยจัดบทสนทนาได้:

Risk ≈ Likelihood × Impact

แต่เลข 4 × 5 = 20 ไม่ใช่ความจริงทางวิทยาศาสตร์ สิ่งสำคัญคือหลักฐานและ assumption ที่อยู่ใต้คะแนน เช่น endpoint เข้าถึงจาก Internet หรือไม่, ต้องมี credential แบบไหน, ตรวจจับได้เร็วแค่ไหน และโอนได้สูงสุดเท่าไร การประเมินอย่างเป็นระบบจะลงรายละเอียดในบทถัดไป

Protect Three Security Properties#

CIA Triad เป็นแบบจำลองพื้นฐานที่ยังมีประโยชน์ เพราะบังคับให้มองความเสียหายมากกว่า “ข้อมูลรั่ว” เพียงแบบเดียว

Confidentiality#

ข้อมูลต้องเปิดเผยเฉพาะผู้และระบบที่ได้รับอนุญาต

• ลูกค้า A ต้องไม่เห็น statement ของลูกค้า B
• support agent อาจเห็นเลขบัญชีแบบ masked แต่ไม่ควรเห็น secret หรือ PIN
• backup และ application log ต้องถูกคุมเหมือน production data

Integrity#

ข้อมูลและคำสั่งต้องไม่ถูกสร้าง แก้ ลบ หรือสลับลำดับโดยผู้ไม่มีสิทธิ์

• transfer จำนวน 100000 สตางค์ต้องไม่กลายเป็น 10000000 สตางค์ระหว่างทาง
• ledger entry ที่ post แล้วไม่ควรถูกแก้ทับเงียบ ๆ
• webhook จากธนาคารต้องพิสูจน์แหล่งที่มาและป้องกัน replay

สำหรับ Fintech Integrity มักสำคัญกว่า secrecy ในบาง flow การเข้ารหัส request ช่วยเรื่อง Confidentiality แต่ถ้าไม่ authenticate ผู้ส่งหรือไม่ตรวจ authorization ระบบก็ยังรับคำสั่งโอนเงินจากคนผิดได้

Availability#

ผู้มีสิทธิ์ต้องเข้าถึงระบบและข้อมูลได้ในเวลาที่ธุรกิจต้องการ

• DDoS ไม่ควรทำให้ลูกค้าทั้งหมดจ่ายเงินไม่ได้
• ransomware ที่เข้ารหัส database ทำลายทั้ง Availability และ Integrity
• control ที่เข้มจน operator แก้ incident ไม่ได้ก็สร้าง Availability risk แบบหนึ่ง

System map

Draw the Trust Boundaries#

Trust boundary คือจุดที่ระดับความเชื่อถือเปลี่ยน เช่น จาก mobile device ของลูกค้าเข้าสู่ ระบบ backend หรือจาก workload ภายในไปยัง bank API ทุกครั้งที่ข้อมูลข้าม boundary ต้องถามใหม่ว่าใครส่ง, ข้อมูลถูกแก้ได้ไหม, request เก่าถูกส่งซ้ำได้ไหม และปลายทางอนุญาตจริงหรือไม่

System map

จาก diagram สั้น ๆ นี้มี boundary หลายแบบ:

• Ownership boundary — mobile device และ bank API ไม่อยู่ใต้การควบคุมของผู้ให้บริการระบบ
• Network boundary — traffic ข้าม Internet และ network zone
• Identity boundary — customer, operator และ workload ใช้สิทธิ์คนละชนิด
• Privilege boundary — admin operation ทำสิ่งที่ customer endpoint ทำไม่ได้
• Lifecycle boundary — CI/CD เปลี่ยนสิ่งที่กำลังรันโดยไม่ผ่าน runtime API

เส้นใน diagram จึงไม่ใช่แค่ “ต่อถึงกัน” แต่คือคำถาม Security ที่ต้องตอบ

Find the Attack Surface#

Attack surface คือทุกจุดที่ผู้โจมตีส่ง input, เรียก capability หรือมีอิทธิพลต่อระบบได้ ไม่ได้จำกัดเฉพาะ public HTTP endpoint

การลด attack surface มักมีประสิทธิภาพกว่าการใส่ detector เพิ่ม เช่น admin portal ที่เข้าถึงได้ เฉพาะ identity-aware access path มี surface เล็กกว่าหน้า login ที่เปิดทั่ว Internet

Apply the Core Principles#

Least Privilege#

ให้ identity มีสิทธิ์เท่าที่จำเป็น ในขอบเขตและเวลาที่จำเป็น

• transfer service เขียน ledger ผ่าน operation ที่กำหนด ไม่ได้สิทธิ์แก้ทุก table
• support อ่านข้อมูลแบบ masked และเริ่ม recovery ได้ แต่อนุมัติ recovery ของตัวเองไม่ได้
• deployment ใช้ short-lived credential แทน access key อายุหลายปี

Least privilege ที่ไม่มีวิธีใช้งานจริงมักเสื่อมตามเวลา ต้องมี owner, review และหลักฐานว่า permission ใดถูกใช้งาน

Defense in Depth#

วาง control หลายชั้นที่แก้ failure คนละแบบ ไม่ใช่ทำ control เดิมซ้ำ 3 ครั้ง

System map

ถ้า token ถูกขโมย Authentication อาจผ่าน แต่ device/risk signal, transaction limit, step-up authentication และ detection ยังลดความเสียหายได้ นี่คือ defense in depth ที่แต่ละชั้นมี failure mode ต่างกัน

Secure by Default#

ค่าเริ่มต้นต้องปลอดภัยโดยไม่หวังให้ทุกทีมจำ configuration พิเศษ

• endpoint ใหม่ปฏิเสธ request จนกว่าจะประกาศ authorization policy
• storage ใหม่เป็น private และ encrypted
• log pipeline redact field สำคัญตั้งแต่ต้น
• production access มีวันหมดอายุ ไม่ใช่สิทธิ์ถาวร

Fail Securely#

เมื่อ dependency หรือ control ตอบไม่ได้ ระบบต้องเข้าสู่สถานะที่กำหนดไว้ ไม่ใช่สุ่มเลือก ระหว่าง allow กับ deny

Separation of Duties#

งานที่สร้างความเสียหายสูงไม่ควรรวมอยู่ในคนหรือ credential เดียว

• คนสร้าง payout batch ไม่ใช่คนอนุมัติ batch เดียวกัน
• developer deploy ได้ผ่าน pipeline แต่แก้ production artifact หลัง build ไม่ได้
• security administrator เปลี่ยน policy ได้ แต่ลบ audit trail ไม่ได้

Complete Mediation#

ตรวจสิทธิ์ทุกครั้งที่เข้าถึง resource อย่าเชื่อว่า request ผ่านหน้าแรกมาแล้วจึงปลอดภัย การซ่อนปุ่ม “Refund” ใน frontend ไม่ใช่ authorization; backend ต้องตรวจ actor, resource, action และ context ทุกครั้ง

Assume Breach#

ออกแบบโดยสมมติว่า control ชั้นหนึ่งจะพลาดหรือ credential 1 ชุดจะรั่ว แล้วถามว่า:

1. ผู้โจมตีไปต่อที่ไหนได้บ้าง
2. เข้าถึงข้อมูลหรือเงินได้มากเท่าไร
3. มีสัญญาณใดให้ตรวจพบ
4. ตัดสิทธิ์และจำกัดวงได้เร็วแค่ไหน
5. กู้คืนอย่างไรโดยไม่ทำลายหลักฐาน

Assume breach ไม่ได้แปลว่า “การป้องกันไม่มีประโยชน์” แต่ทำให้ prevention, detection, response และ recovery ถูกออกแบบเป็นระบบเดียวกัน

Separate Neighboring Problems#

หลาย incident มีปัญหาซ้อนกัน การแยกชื่อให้ถูกช่วยให้ส่งการตัดสินใจไปยัง owner ที่ถูกต้อง

ทีมเหล่านี้ต้องเชื่อมกัน แต่ไม่ควรอ้างว่า WAF แก้ fraud หรือ encryption ทำให้ผ่าน compliance โดยอัตโนมัติ

Walk One Transfer End to End#

สมมติบัญชีหนึ่งโอน 250000 สตางค์ไปยังอีกบัญชีผ่านระบบ e-wallet:

1. Mobile app ขอ session จาก identity service
2. API ตรวจ token, audience, expiry และ device context
3. Authorization ตรวจว่า actor ควบคุม wallet ต้นทาง
4. Transaction service ตรวจ limit, risk signal และ idempotency key
5. Ledger บันทึก debit/credit แบบ atomic
6. Notification แจ้งเจ้าของบัญชีต้นทางผ่านช่องทางอิสระ
7. Detection pipeline มองหารูปแบบผิดปกติ

แต่ละข้อปกป้องคนละ assumption ถ้าข้ามข้อ 3 ต่อให้ token valid ผู้ใช้ก็อาจโอนจาก wallet ของคนอื่นได้ ถ้าข้ามข้อ 4 request ซ้ำอาจทำเงินออก 2 ครั้ง และถ้าข้ามข้อ 7 ทีมอาจไม่รู้ว่า control ก่อนหน้าพลาดไปแล้ว

A Reusable Security Question Set#

เมื่อเจอ feature หรือ diagram ใหม่ ให้ถามตามลำดับนี้:

1. Asset — อะไรมีค่าและใครเป็นเจ้าของ
2. Actors — ใครหรืออะไรโต้ตอบกับระบบ
3. Boundaries — ข้อมูลและสิทธิ์ข้ามจุดที่ระดับความเชื่อถือเปลี่ยนตรงไหน
4. Actions — actor แต่ละรายทำอะไรได้
5. Failure — Confidentiality, Integrity หรือ Availability เสียแบบใดได้บ้าง
6. Controls — ป้องกัน ตรวจจับ ตอบสนอง และกู้คืนอย่างไร
7. Evidence — จะพิสูจน์ได้อย่างไรว่า control ทำงาน
8. Owner — ใครตัดสินใจและรับ residual risk

คำถามชุดนี้จะถูกทำให้เป็นกระบวนการ threat modeling ในบทถัดไป

Review Checklist#

• ระบุ asset เป็นสิ่งที่เจาะจงกว่าคำว่า “ข้อมูล” หรือ “ระบบ”
• วิเคราะห์ Confidentiality, Integrity และ Availability ครบ
• วาด external dependency, privileged path และ CI/CD ลงใน diagram
• ทำเครื่องหมาย trust boundary ไม่ใช่แค่วาดกล่องกับลูกศร
• inventory input และ capability ทุกชนิด ไม่ใช่เฉพาะ public API
• ใช้ least privilege และ default deny กับ identity ทุกชนิด
• แต่ละ critical action มี control หลายชั้นที่ failure mode ต่างกัน
• กำหนด fail/degraded behavior ก่อน dependency ล่ม
• แยก Security, reliability, fraud, privacy และ compliance ได้
• control สำคัญมี test, telemetry, owner และ review cadence

Further Reading#

• NIST Cybersecurity Framework
• NIST Glossary
• OWASP Application Security Verification Standard