การพัฒนางานด้านบริการ (Continual Service Improvement)

Download Report

Transcript การพัฒนางานด้านบริการ (Continual Service Improvement)

Chapter 2
ระบบบริ หารความปลอดภัยสารสนเทศ
Company
LOGO
ในยุคที่ระบบ ICT ของทุกหน่วยงานต้องเชื่อมกันหมด ไม่ใช่เฉพาะในประเทศ
ไทยแต่กบั ทัว่ โลก องค์กรที่ประเทศไทยมีธุรกรรมด้วย ไม่วา่ จะเป็ นภาครัฐกับ
ภาครัฐ หรื อภาครัฐกับภาคเอกชน หรื อภาคเอกชนกับภาคเอกชนจะต้องมีการ
บริ หารจัดการความมัน่ คงปลอดภัยด้านสารสนเทศอย่างเป็ นระบบ จนถึงขั้นที่
จะต้องได้การรับรองจากองค์กรที่ให้วฒ
ุ ิบตั รว่าสามารถดาเนินการตามมาตรฐาน
ความมัน่ คงปลอดภัยตามที่กาหนดในการบริ หารความมัน่ คงปลอดภัย
(Information Security Management
System:ISMS) ได้กาหนดโดยมาตรฐานตระกูล ISO/IEC
27000 ซึ่ งประกอบด้วย 7 มาตรฐาน ดังนี้
มาตรฐานการรักษาความปลอดภัยของข้อมูล




มาตรฐาน
มาตรฐาน
มาตรฐาน
มาตรฐาน
ISO/IEC 27000
ISO/IEC 27001
ISO/IEC 27002
ITIL
มาตรฐาน ISO/IEC 27000
เป็ นชุดมาตรฐานสากลที่เกี่ยวข้องกับการรักษาความปลอดภัย
สารสนเทศ พัฒนาโดยประเทศอังกฤษ(British
Standard:BS) โดยเนื้อหาที่สาคัญของมาตรฐานนี้ประกอบด้วย




ความเสี่ ยงเกี่ยวกับความปลอดภัยของข้อมูลในองค์กร
การประเมิณความเสี่ ยง
วิธีปฏิบตั ิเพื่อลดความเสี่ ยง
การดาเนินกิจกรรมเกี่ยวกับการบริ หารความเสี่ ยง
มาตรฐาน ISO/IEC 27001
Information Security Management System:
ISMS
เป็ นมาตรฐานการจัดการข้อมูลที่มีความสาคัญเพื่อให้ธุรกิจดาเนินไปอย่างต่อเนื่ อง
ซึ่ งข้อกาหนดต่างๆกาหนดขึ้นโดยองค์กรที่มีชื่อเสี ยงและมีความน่าเชื่อถือระหว่าง
ประเทศ คือ ISO (The International Organization for
Standardization) และ IEC (The International
Electrotechnical Commission) การประยุกต์ใช้ ISMS จะ
ช่วยให้กิจกรรมทางธุ รกิจต่อเนื่ องไม่สะดุด, ช่วยป้ องกันกระวนการทางธุ รกิจจาก
ภัยร้ายแรงต่างๆเช่น แผ่นดินไหว, วาตภัย, อุทกภัย ฯลฯ และ ความเสี ยหายของ
ระบบข้อมูล โดยครอบคุม ทุกกลุ่มอุตสาหกรรมและทุกกลุ่มธุรกิจ
หลักการของการออกแบบโครงสร้างระบบ ISO/IEC27001 จะ
ใช้ อ้างอิง รู ปแบบ PDCA Model (Plan Do Check
Action)
มาตรฐาน ISO/IEC 27001
ระบบ ISMS เป็ นระบบ Dynamic system ที่ใช้โครงสร้าง
PDCA ดังนั้น ระบบจะมีการหมุนเพื่อปรับปรุ งอย่างต่อเนื่องอยู่
ตลอดเวลามี่ที่สิ้นสุ ด โดยโครงสร้างของข้อกาหนด จะถูกแบ่งตาม
PDCA ดังนี้
Plan
Establish ISMS
a) กำหนด scope และ ขอบเขตกำรจัดทำระบบ ISMS
b) กำหนด ISMS Policy
c) กำหนด รู ปแบบกำรประเมินควำมเสี่ ยง
d) กำหนดควำมเสี่ ยง
e) วิเครำะห์ และ ประเมินควำมเสี่ ยง
f) กำหนดและประเมิน วิธีกำรเพือ่ ลดควำมเสี่ ยง
g) เลือกกำรควบคุม เพือ่ ลดควำมเสี่ ยง
h) เห็นชอบควำมเสี่ ยงทีเ่ หลืออยู่โดย management
I) เห็นชอบและประยุกต์ ใช้ ระบบ โดย management
Do
ประยุกต์
ใช้ และ
ดำเนิน
กำร
ระบบ
ISMS
Implement and Operate the ISMS
a) กำหนดแผนกำรลดควำมเสี่ ยง
b) ดำเนินกำรตำมแผนลดควำมเสี่ ยง
c) ดำเนินกำร ตำมกำรควบคุมทีเ่ ลือกตำม 4.2.1g
d) กำหนดกำรวัดประสิ ทธิภำพของระบบกำรควบคุม
e) จัดทำรำยกำรฝึ กอบรม
f) จัดกำรกำรประยุกต์ ใช้ ระบบ
g) ประยุกต์ ใช้ ระเบียบปฎิบัตงิ ำน
Check
เฝ้ ำระวัง
และ
ตรวจสอบ
ระบบ
ISMS
Monitor and review ISMS
a) จัดทำ ระเบียบปฏิบัตกิ ำร เฝ้ ำระวังและตรวจสอบระบบ ISMS
b) ทบทวนประสิ ทธิภำพของ ระบบอย่ำงสมำ่ เสมอ
c) วัดประสิ ทธิภำพกำรควบคุมในกำรปฏิบัติตำมข้ อกำหนด
d) ทบทวน กำรประเมินควำมเสี่ ยงตำมแผน ควำมเสี่ ยงทีเ่ หลือ ระบบ
กำรประเมินควำมเสี่ ยง และกำรเปลีย่ นแปลงต่ ำงๆ ตำมรอบเวลำที่
กำหนด
e) ดำเนินกำร ตรวจติดตำมภำยในระบบISMS
f) ดำเนินกำร จัดทำ management review
g) ปรับปรุ ง security plan ให้ ทนั สมัย
h) บนทึกกำรกำรทำงำนและหลักฐำนทีม่ ีผลต่ อประสิ ทธิภำพและ
ประสิ ทธิผลของระบบ
Action
รักษำและ
ปรับปรุ ง
ระบบ
ISMS
Maintain and improve the ISMS
a) ดำเนินกำร corrective action และ preventive
action
b) สื่ อสำร วิธีกำรและกำรปรับปรุ งต่ ำงๆ ให้ กบั ผู้ทเี่ กีย่ ข้ องต่ ำงๆ
c) แน่ ใจว่ ำ วิธีกำรทีป่ รับปรุ งขึน้ บรรลุจุดประสงค์ ทวี่ ำงไว้
ISO 27002
ISO 27002 เป็ นชื่อเรี ยกใหม่ของ ISO 17799 ซึ่งเดิม
เรี ยกว่า "BS 7799 Part 1" เป็ นมาตรฐานแสดง หลักปฏิบตั ิ
สาหรับ ISM (Code of practice for Information
Security Management) ที่อธิบายวัตถุประสงค์ของ
ระเบียบวิธีการควบคุมด้าน IS ทั้งหลายอย่างละเอียด และแสดงรายการ
วิธีปฏิบตั ิที่ดีที่สุด ของการควบคุมความมัน่ คงปลอดภัย (Bestpractice security controls)
มาตรฐาน ITIL
 เมื่อปี ค.ศ.1980ภายใต้รัฐบาลของประเทศอังกฤษที่มีหน่ วยงานชื่ อว่าCCTA(Central
Computerand TelecommunicationsAgency)ได้จดั ทาวิธีการบริ หาร
จัด การด้านระบบสารสนเทศขึ้ นมาเพื่อ ใช้กับ หน่ ว ยงานระบบสารสนเทศของ รั ฐ บาลประเทศ
อังกฤษภายใต้ชื่อโครงการคือ Government Information Technology
Infrastructure Management Methodology" (GITMM)ซึ่ ง
วัตถุประสงค์ของโครงการคือเป็ นวิธีการบริ หารจัดการระบบสารสนเทศซึ่ งต่อมาก็ได้มีการเปลี่ยน
มือการพัฒนากันเรื่ อย มาจนเป็ นITILในปั จจุบนั ที่มีการพัฒนาไปจนถึงITILเวอร์ ชนั 3ซึ่ งเป็ น
เวอร์ ชนั ล่าสุ ดที่ มีการตี พิมพ์อย่างเป็ นทางการเมื่ อวันที่30 มิ ถุนายน2007ที่ ผ่านมานี่ เองโดย
เนื้ อหาของITILที่มีการพัฒนาจากเวอร์ ชนั 2มาเป็ นเวอร์ ชนั 3นั้นได้เน้นไปที่การผสมผสานของ
วงจร ชี วิตการให้บริ การด้วยระบบไอที (Integrated
service
lifecycle
approach) เพื่อให้เหมาะสมกับยุคสมัยของงานบริ การในปั จจุบนั โดยที่ไอทีตอ้ งทางาน
สอดคล้ อ งกั บ การด าเนิ น งานทางธุ ร กิ จ และสามารถสร้ า งคุ ณ ค่ า จากการใช้ ไ อที ไ ด้ ด้ ว ย
นอกเหนื อไปจากการทางาน ด้านขบวนการตามปกติแล้วซึ่ งผูบ้ ริ หารและนักลงทุนเองต่างมองถึง
ความคุม้ ค่าจากการลงทุนด้านไอที ROI (Return on Investment) ที่มีค่าใช้จ่าย
ค่อนข้างสูงมากในปัจจุบนั
เป็ นขบวนการของการบริ หารจัดการด้านการให้บริ การโดยใช้ระบบไอ
ที (IT Service Management) ซึ่งมีส่วนประกอบหลัก
อยู่ 5 ส่ วนคือ





กลยุทธ์ ด้ำนกำรบริกำร (Service Strategy)
กำรออกแบบงำนบริกำร (Service Design)
กำรส่ งมอบงำนบริกำร (Service Transition)
กำรปฏิบัติงำนบริกำร (Service Operation)
กำรพัฒนำงำนด้ ำนบริกำร (Continual Service
Improvement)
1. กลยุทธ์ ด้ำนกำรบริกำร (Service Strategy) จะครอบคุลมถึง
กลยุทธ์และการวางแผนที่สร้างคุณค่า หน้าที่และความรับผิดชอบ การวางแผนและ
พัฒนากลยุทธ์ แผนงานธุรกิจที่เชื่อมโยงกับระบบไอที ปั จจัยที่เป็ นโอกาสในการ
ประสบความสาเร็ จและความเสี่ ยงที่อาจจะเกิดขึ้น

2. กำรออกแบบงำนบริกำร (Service Design) จะครอบคลุมถึง
วงจรของการบริ การ หน้าที่และความรับผิดชอบ การออกแบบวัตถุประสงค์ของ
การบริ การและส่ วนประกอบต่างๆ การคัดเลือกและการจัดสรรรู ปแบบงานบริ การ
ค่าใช้จ่ายของงานบริ การ การวิเคราะห์ผลประโยชน์และความเสี่ ยง การพัฒนางาน
บริ การ การวัดผลและควบคุม รวมถึงปัจจัยการประสบความสาเร็ จและความเสี่ ยง
3. กำรส่ งมอบงำนบริกำร (Service Transition) จะ
ครอบคลุมถึงการจัดการความเปลี่ยนแปลงต่างๆ ที่จะเกิดขึ้นไม่วา่ จะเป็ น
รู ปแบบองค์กรหรื อวัฒนธรรมองค์กร การบริ หารจัดการความรู ้ การ
วิเคราะห์ความเสี่ ยง ข้อควรปฏิบตั ิในการบริ การ สถานการณ์การงาน
บริ การ แนวทาง การฝึ กฝน เครื่ องมือในการบริ การ การวัดผลและ
ควบคุม
4. กำรปฏิบัติงำนบริกำร (Service Operation) จะ
ครอบคลุมถึงแนวทางและสถานะของวงจรการบริ การ พื้นฐานและ
ขบวนการงานบริ การ การประยุกต์ใช้ การจัดการโครงสร้าง การจัดการ
ขบวนการ ปัจจัยความสาเร็ จและความเสี่ ยงในงานบริ การ
5.กำรพัฒนำงำนด้ ำนบริกำร (Continual Service
Improvement) จะครอบคลุมถึง การขับเคลื่อนหรื อการ
ผลักดันงานบริ การ หลักการงานพัฒนาด้านบริ การ หน้าที่และความ
รับผิดชอบ ผลประโยชน์ที่จะได้รับ การทาให้ประสบผลสาเร็จ แนวทาง
การฝึ กฝน เครื่ องมือในการพัฒนา การฝึ กฝน
หลักวิธีการของ วิศวกรรมซอฟต์ แวร์ (SoftwareEngineering)
ในรู ปแบบของ SDLC
ขั้นตอนที่ 1 กำรเริ่มต้ นและวำงแผนโครงกำร
การเก็บ requirement
ของผูใ้ ช้ระบบ
การระบุทางเลือกใน
การแก้ไขปัญหา
การเก็บข้อมูลความต้องการ
ความปลอดภัยของ user
การ วิเคราะห์ความเสี่ ยง
(Risk Analysis)
พัฒนาระบบ E-mail
การเลือกแนวทาง
การกาหนดกลยุทธ์ทางด้าน
ความปลอดภัย
หลักวิธีการของ วิศวกรรมซอฟต์ แวร์ (SoftwareEngineering)
ในรู ปแบบของ SDLC
ขั้นตอนที่ 2 กำรออกแบบ Function กำรทำงำน
สร้างแผนของ
โครงการ
กาหนดความ
ปลอดภัยแต่ละ
Function
จัดส่วนของการ
ทดสอบ
โปรแกรมมีงาน
เลือกขอบเขตของ
ทดสอบแต่ละ
ย่อยอะไรบ้างที่ตอ้ ง
ความปลอดภัย
function ที่
สร้างความ
ซับซ้อนขนาดไหน
สร้างขึ้นมา
ปลอดภัย
กาหนดกลยุทธ์
ทางความ
ปลอดภัย
พัฒนาความ
ต้องการขั้น
พื้นฐาน
ใส่ ความต้องการ
ทางความปลอดภัย
กาหนดกิจกรรม
ทางด้านความ
ปลอดภัย
หลักวิธีการของ วิศวกรรมซอฟต์ แวร์ (SoftwareEngineering)
ในรู ปแบบของ SDLC
ขั้นตอนที่ 3 กำรออกแบบควำมปลอดภัยขั้นละเอียด
เตรี ยมการออกแบบ
ปรับปรุ งแก้ไขแผนความ
ปลอดภัยขั้นละเอียด
พัฒนาเอกสารทางด้าน
ความปลอดภัย
การเขียน ER-Diagram โดยพิจารณาถึงโมดูล การทางานอะไรบ้างที่
ตรวจสอบสิ ทธิ์ใช้งาน หรื อการเก็บ log หลังจากนั้น ทดสอบความปลอดภัย เมื่อ
เกิดปัญหาทาการปรับปรุ งแผน และรายงานผล
หลักวิธีการของ วิศวกรรมซอฟต์ แวร์ (SoftwareEngineering)
ในรู ปแบบของ SDLC
ขั้นตอนที่ 4 กำรพัฒนำโปรแกรม และ ทำคู่มอื กำรใช้ งำน
พัฒนาระบบ
ทา Unit Test และ
ประเมินผล
ทาคู่มือการใช้งาน
หลักวิธีการของ วิศวกรรมซอฟต์ แวร์ (SoftwareEngineering)
ในรู ปแบบของ SDLC
ขั้นตอนที่ 5 ขั้นตอนกำรสรุ ปและกำรประเมินผล
ทดสอบ
ตรวจเชค
ติดตั้งระบบ
ทาเอกสาร
ทางด้าน
coding
ทาเอกสารการ
ยอมรับจาก
ลูกค้า
ตัวอย่าง การจัดการความเสี่ ยง อุปกรณ์เครื อข่าย
20 ธรรมเนียมปฏิบตั ิพ้นื ฐานที่เกี่ยวข้องกับระบบรักษา
ความปลอดภัย
1.
2.
3.
4.
สร้างอานาจและระดับการเข้าเครื่ อง
มัน่ ใจในความซื่อสัตย์ของบุคลากร
สร้างวิธีแก้ปัญหา โดยมีผรู้ ับผิดชอบ
มีระดับความสาคัญในการป้ องกัน
อุปกรณ์
5. นับข้อมูลที่สาคัญ, ไม่สาคัญที่ตอ้ ง
ป้ องกัน
6. เพ่งความสนใจไปที่อุปกรณ์สาคัญๆ
7. สร้างขอบเขตรอบๆ อุปกรณ์ที่จะป้ องกัน
8. ป้ องกันขอบเขตนั้นด้วย
9. สอดส่ องดูแลบารุ งรักษาขอบเขต
10. ควบคุมอุปกรณ์ และการเข้าใช้
13 เมษายน 2558
11. จากัดความรู ้ ความรับผิดชอบ และแบ่งแยกการ
ทางาน ของเจ้าหน้าที่
12. ไม่ควรให้คนอื่นล่วงรู ้สินทรัพย์ของเรา
13. การอนุญาตให้คนอื่นเข้าไปใช้
14. กาหนดความรับผิดชอบในแต่ละส่ วน
15. ทาเอกสารให้รู้วา่ ใครรับผิดชอบอะไร
16.ตรวจสอบหลายๆ ครั้งให้ครอบคลุม
17. วิเคราะห์เอกสารว่าครอบคลุมหรื อยัง
18. สื บหาสิ่ งผิดปรกติในสื่ อที่เกิดขึ้น
19.ลงโทษในสิ่ งที่สืบหาเจอ
20.เตรี ยมพร้อมอยูเ่ สมอ เพื่อที่จะกลับมา ใหม่
27
เทคนิคในการจัดการความปลอดภัย
การจัดการความปลอดภัย
กายภาพ
บุคคล
การเข้ ารหัส
การแพร่กระจายคลื่น
การจัดการระบบการสื่อสาร
กลุ่มของฟั งก์ ชัน
ลับที่สุด
X
X
X
X
-
ลับ
X
x
X
-
ปกปิ ด
X
X
X
ไม่ ปกปิ ด
X
X
X
หมายเหตุ x จะเปลี่ยนไปตามลักษณะขององค์กรไม่ตายตัว
13 เมษายน 2558
28
การจัดการความปลอดภัยขั้นพื้นฐาน
1.
2.
3.
กำรจัดกำรแบบไม่ อยู่คนเดียว
ถ้ามี Never alone principles เมื่อไหร่ พฤติกรรมของความปลอดภัยทั้งหมด
จะต้องมีคนมากกว่า 1 คนในพฤติกรรมนั้นๆ
กำรจัดกำรแบบจำกัดช่ วงระยะเวลำกำรทำงำน Time Limitation of Duties
- จะต้องไม่มีบุคคลใด บุคคลหนึ่งดูแลความปลอดภัย
- หมุนเวียนสลับตาแหน่ง
แยกงำนออกจำกกัน Separation of Duties
จะต้องไม่มีใครคนใดคนหนึ่ งจะต้องมีความรู ้ที่รับผิดชอบเท่านั้น ไม่สามารถ
ล่วงรู ้งานอื่นที่นอกเหนือไปจากงานที่ได้รับมอบหมาย
13 เมษายน 2558
29
งานต่อไปนี้ควรแยกออกจากกันเพื่อให้มีความปลอดภัยที่ดี
1.
2.
3.
4.
5.
6.
คนที่เป็ น Operation ควรแยกหน้าที่กบั Programming ไม่ควรเป็ นคนเดียวกัน
การเตรี ยมข้อมูลการประมวลผลข้อมูล
การทางานของ Computer Operation การบันทึกข้อมูลบน Mediaควรแยกออก
จากกัน
การรับรู ้ขอ้ มูล ข้อความหรื อทรัพยากรมีค่า ควรแยกออกจากการส่ งทรัพยากร
นั้น
การเขียนโปรแกรมที่เกี่ยวข้องกับการประยุกต์ + การเขียนโปรแกรมที่
เกี่ยวข้องกับระบบแยกกัน
การเขียนโปรแกรมที่เกี่ยวข้องกับการประยุกต์ + การเขียน Program database
ควรแยกกัน
13 เมษายน 2558
30
แบ่งงานออกจากกันโดยใช้
1.
2.
สร้ ำงกำแพงกั้นห้ อง
- สื่ อที่จะต้องเก็บไว้ในที่ที่มีความปลอดภัยควรจะติดกับห้องคอมพิวเตอร์
- การเตรี ยมข้อมูลต้องเตรี ยมในที่มีความปลอดภัย ใกล้หอ้ งคอมพิวเตอร์แต่ไม่ควรอยูใ่ นห้อง
คอมพิวเตอร์
- ควรแยกออกจากศูนย์คอมพิวเตอร์เพื่อความปลอดภัย
- จะต้องจากัดคนทัว่ ไปยกเว้นคนที่เกี่ยวข้อง
- ห้องรักษาความปลอดภัยจะต้องแยกออกจาก Operators
- สิ่ งที่เกี่ยวข้องกับขยะ ที่รอจะทาลายสมควรจะกาจัดในที่ปลอดภัยไม่ควรอยูใ่ นห้อง
คอมพิวเตอร์
กำรแยกจำกกันโดยกำรบริหำร
- โปรแกรมเมอร์จะต้องไม่ไปยุง่ เกี่ยวกับสารสนเทศ
- โอเปอร์เรเตอร์ตอ้ งไม่เขียนหรื อส่ งโปรแกรม
- คนที่ทาหน้าที่เกี่ยวกับความปลอดภัย ไม่ควรให้คนอื่นมาทาหน้าที่เกี่ยวข้องได้
13 เมษายน 2558
31
การวิเคราะห์ภยั คุกคาม และการจัดการความเสี่ ยง
กำรวิเครำะห์ เพือ่ หำจุดอ่ อนทีง่ ่ ำนต่ อกำรโจมตี
- ภัยคุกคามที่ไม่มีแนวทางที่แน่นอน และโครงสร้างที่แน่นอน
ตัวอย่างโรงพยาบาล
ภัยคุกคามที่เกิดขึน้
เป็ นเหตุให้ โดย
1.
2.
3.
4.
5.
13 เมษายน 2558
ไฟล์ที่เก็บข้ อมูลของคนไข้
เสียหาย
ระบบบัญชีเสียหาย
ข้ อมูลของคนไข้ ถกู เปิ ดเผย
ตารางการทางานแพทย์
เปลี่ยนแปลงได้
ข้ อมูลของคนไข้ เรี ยกมาดูไม่ได้
1.
2.
3.
รายงานที่ไม่ครบถ้ วน
รายงานไม่มีหลักฐานและ
เหตุผลเพียงพอ
ความไม่สม่าเสมอในการ
รายงาน
32
Threat tree
ตัวอย่างโรงพยาบาล
Threat
โรงพยาบาล
เกี่ยวกับคนไข้
Sub threats
Disclosure
threats
Sub threats
Integrity
threat
เกี่ยวกับชีวติ
ไม่เกี่ยวกับคนไข้
ไม่เกี่ยวกับชีวติ
เกี่ยวกับเงิน
Denial of
Service
threat
คนภายนอก
13 เมษายน 2558
ไม่เกี่ยวกับเงิน
คนภายใน
33
คานวณความเสี่ ยงของความปลอดภัย
Threat
Subtheats1
Effort = moderate (2)
Effort = high (3)
Criticality = high (4)
Criticality = moderate (2)
Subtheats2
Effort
Risk = Critical/ Effort
Risk = 3/2 = 1.8
Risk = 2/3 = 0.67
13 เมษายน 2558
Critication
Type
Valve
Type
Valve
Low
1
Low
1
Moderate
2
Moderate
2
high
3
high
3
34
คานวณความเสี่ ยงของความปลอดภัย
ตัวอย่ ำง Aircraft
Serve to
engine
Temperature
Main
Controller
Cooling
System
ลำดับควำมสำคัญ
Main controller
Temperature = 2
Cooling System
Serve to engine
Flight recorder= 1
=3
=2
=3
Position
Sensor
Flight recorder
(Back Box)
13 เมษายน 2558
35
คานวณความเสี่ ยงของความปลอดภัย
ตัวอย่ำง Aircraft
Aircraft
Denial of
Service threat
Disclosure
threat
Main Controller
Critical – 3
Effort – 3
Risk - 1
13 เมษายน 2558
Server to engine
Critical – 3
Effort – 2
Risk – 1.5
Temperature
Critical – 2
Effort – 3
Risk – 0.67
Cooling System
Critical – 2
Effort – 3
Risk – 0.67
Integrity threat
Fight recorder
Critical – 1
Effort – 3
Risk – 0.3
36
วัฏจักรของการสร้างระบบการรักษาความปลอดภัย
ระบบที่จะทาการวิเคราะห์การรักษาความปลอดภัย
การแยกระบบออกเป็ นส่ วนๆ
ใส่ ระบบป้ องกันภัยเข้าไป
พยายามแจกแจงจุดอ่อน ภัยคุกคาม ที่อาจจะเกิดขึ้น
ประมาณค่าความเสี่ ยง
จัดลาดับจุดอ่อนในระบบ
ยอมรับหรื อไม่
No
Yes
13 เมษายน 2558
37
เว็บไซต์กลางที่รวบรวมเรื่ องราวหรื อข้อมูลเกี่ยวกับเหตุการณ์การละเมิดการรักษา
ความปลอดภัย เช่น
www.securityfocus.com ให้บริ การข้อมูลเกี่ยวกับจุดอ่อนและช่อง
โหว่ต่างๆ
www.incident.org ให้บริ การข้อมูลเกี่ยวกับภัยต่างๆในปั จจุบนั
www.sans.org ให้ขอ้ มูลเกี่ยวกับการฝึ กอบรมทางด้านความปลอดภภัย
และรวบรวมเอกสารทางด้านนี้มากมาย
www.cert.org ให้ขอ้ มูลเกี่ยวกับภัยคุกคาม คาแนะนา วิธีป้องกัน
www.thaicert.nectec.or.th ศูนย์ประสานงานการรักษาความ
ปลอดภัยคอมพิวเตอร์ประเทศไทย
คาถามท้ายบท
Information Security Management
System(ISMS) หมายถึงอะไร
 สรุปใจความสาคัญของขัน
้ ตอนทัง้ สี่ คือ
PDCA ของมาตรฐาน 27001
 มาตรฐานใดที่มีวตั ถุประสงค์ในการกาหนดวิธีปฏิบตั ิที่ดีที่สุด (Best
Practice) สาหรับกระบวนการการส่ งมอบงานและการบริ การ
ทางด้านไอที
End of Chapter
Company
LOGO Thank You