EDITOR’S NOTE & QUESTIONAIRE
สวัสดีป 2009 สำหรับทานผูติดตาม Bay Newsletter หวังวาจะเปนปที่ทุกทานไดรับ ประสบการณใหมๆ ที่ดีที่ไดเพิ่มพูน ความรูความเขาใจในสิ่งที่ทานปฏิบัติและเปน ประโยชนในอนาคต สำหรับปนี้เราไดปรับปรุงรูปแบบใหมีสีสันและนาอานยิ่งขึ้น โดย ยังคงเนนเนื้อหาที่เปนประโยชนตอแนวโนมทางดานไอทีของป ทั้งนี้ เราไดแนบแบบสอบถามเกี่ยวกับ การจัดทำ Newsletter มาในโอกาสนี้ดวย หวังเปนอยางยิ่งวาจะไดรับคำแนะนำจากทาน เนือ้ หา Business Continuity Management (BCM) ในภาคตอฉบับนี้ คงชวยใหทา นไดประเมินความ พรอมขององคกรในการจัดเตรียม BCM ทีต่ รงตามมาตรฐาน ซึง่ เทคโนโลยีทรี่ องรับการจัดเตรียม BCM นั้นมีการจัดเตรียมไดหลายระบบ และเหมาะสมกับองคกรแตกตางกันไป หากทานตองการทราบขอมูล เพิ่มเติมสามารถติดตอทีมงานเพื่อรับคำปรึกษาไดโดยตรง z
2 l Bay Computing Newsletter l 5rd Issue
นิดา ตั้งวงศศิริ, ผูจัดการทั่วไป
CONTENTS & NEWS UPDATE
01 13
Anniversary Bay Computing th
Bay Computing ฉลองครบรอบ 13 ป บนเสนทางอันยาวนานและ ประสบการณที่มากกวาในธุรกิจดานไอทีดวยความมุงมั่นและตั้งใจ นำเสนอโซลูชนั ทีส่ รางสรรคเพือ่ เปนผนู ำทางดาน Security อยางแทจริง
02 เบย รวมงาน WUNCA ครัง้ ที่ 20
เบย คอมพิวติ้ง รวมงานการดำเนินกิจกรรมบนเครือขายสารสนเทศ เพือ่ การศึกษา (WUNCA) ครัง้ ที่ 20" จังหวัดหนองคาย เมือ่ วันที่ 14-17 มกราคม ทีผ่ า นมาไมนานนี้ โซลูชนั ทีเ่ รานำเสนอมงุ เนนตอบสนองความ ตองการแกสถาบันการศึกษา ไมวาจะเปน โซลูชัน IP Management, Bandwidth Mangement, Proxy หรือ Anti-Virus ซึง่ ทีมงานไดเก็บภาพ บรรยากาศของงานมาฝากทุกทาน
03 Bay Website New Look
เยี่ยมชมเว็บไซตของ เบย คอมพิวติ้ง โฉมใหมไดแลววันนี้ ที่ http://www. baycoms.com เรามีบริการทางดานไอที ซีเคียวริตี้ ทีต่ รงตามความตองการขององคกรทัง้ SME และ Enterprise ดวยทีมงานที่มีประสิทธิภาพและมี ความรูความชำนาญในทุกโซลูชันที่นำเสนอ
04 CDIC Cyber Defense Initiative Conference
หลายๆ ทานที่ไปรวมงาน CDIC ซึ่งเปนงานสัมมนาที่มุงเนนทางดาน Security คงไดมีโอกาสแวะเวียนมาเยี่ยมบูธของ เบย ในวันที่ 25-26 พฤศจิกายน ทีผ่ า นมา ซึง่ เบยไดมโี อกาสรวมนำเสนอโซลูชนั ตางๆ ทีต่ รงกับ Trend ของเทคโนโลยีในปจจุบนั ไมวา จะเปน User Authentication, Log Management, IP Management หรือ Load Balance และ Web Application สำหรับ Trend ในปนหี้ ลายๆ ทานคงไดทราบถึงความสำคัญ ของมาตรฐานตางๆ ในโลกเทคโนโลยีที่พัฒนาอยางตอเนื่อง ซึ่งองคกร ระดับใหญหรือหนวยงานราชการจะมงุ สรางมาตรฐานแกองคกรดวยการ Certified Standard ทีต่ รงตอ Business Line ของตัวเอง เชน ISO 27001, COBIT หรือ PCI DSS เปนตน ตองการทราบขอมูลหรือสนใจติดตอสอบถาม Consult Service เกีย่ วกับ มาตรฐานตางๆ ไดที่ ทีม Professional Customer Support เบย คอมพิวติง้ ไดแลววันนี้
01
03
02
04
02 EDITOR’s NOTE & QUESTIONNAIRE 03 CONTENTS & NEWS UPDATE 04 COVER STORY Business Continuity Technology ตอนที่ 2
06 IT GREEN คุณพรอมเตรียมรับกระแส ไอทีสเี ขียว (Green IT) แลวหรือยัง?
08 SOLUTION UPDATE แนวทางการปฏิบัติที่เหมาะสม สำหรับการจัดการขอมูล Log ตอนที่ 3 (ตอบจบ)
13 SOLUTION UPDATE เสริมมาตรการความปลอดภัยไอทีดวย ISO 27001:2005 ตอนที่ 3 “คำจำกัดความ” Bay Computing Newsletter l 5rd Issue l 3
COVER STORY
Business Continuity Technology ตอนที่ 2 z โดย อวิรท ุ ธ เลีย้ งศิริ Enterprise Solution Manager, Bay Computing
จากตอนทีแ่ ลวเราไดกลาวถึง Availability ในแงมุมตางๆ ไปแลว ในตอนนี้ เราจะ กลับมาดูการประยุกตใช และเทคโนโลยีทสี่ ามารถ นำมาใชเพื่อเพิ่มความมั่นคงใหกับระบบงานของ องคกรตอไป
สาเหตุของปญหา Downtime LAN/WAN Equip <1%
Client <1%
Planned Downtime 30%
Environment 5%
กระบวนการในการออกแบบ แผนการทำ Business Continuity
People 15% Hardware 10%
Application Availability and Monitoring : การ ทำ Application Availability คือการตรวจสอบ และใหบริการ Application อยางตอเนือ่ ง ในทุกๆ สถานการณ Performance Monitoring : การทำ Performance Monitoring เปนการตรวจวัดประสิทธิภาพการให บริการและทำงานของ Application และ System Data Backup and Archival : การทำสำรอง และสำเนาของขอมูล Disaster Recovery : การกขู อ มูลจากเหตุวบิ ตั ภิ ยั Data and System Rollback : การกคู นื ขอมูล และระบบกลับคืนสภาพเดิม
Software 40%
จะเห็นวา สาเหตุหลักของการเกิด Downtime สูงสุด 3 อันดับแรก คือ ปญหาของ Software 40%, การ Downtime ทีว่ างแผนลวงหนา 30% และขอผิดพลาด ทีเ่ กิดจากคน 15% เมื่อเราทราบถึงสาเหตุหลักๆ แลว เราจะสามารถ วางแผนเพือ่ ปองกันและลดปญหาลงไดระดับหนึง่ แตปญ หาทีเ่ กิดจากปจจัยอืน่ ๆ หลายครัง้ เปนสิง่ ที่ ปองกันไมไดเชนกัน ดังนัน้ การวางแผนเตรียมพรอม จึงยังเปนสิง่ ทีจ่ ำเปน โดยเมือ่ เริม่ วางแผนเพือ่ เตรียม Business Continuity จึงควรเริม่ ดวยคำถามพืน้ ฐาน เลยคื อ “อะไรคื อ จุ ด ประสงค ห ลั ก ของการทำ Business Continuity” ซึ่งจะตอบถึงเทคโนโลยีที่ จะใช และระดับการลงทุนไดในทีส่ ดุ โดยประเภท ของการตอบโจทยนแี้ บงไดเปนหลายๆ ดาน คือ System Availability : การทำ System Availability เปนการเพิ่มเสถียรภาพใหแกระบบโดยรวม แต ไมไดเนนในระดับของ Application Data Availability : การทำ Data Availability เปนการเพิม่ เสถียรภาพใหกบั ขอมูล โดยใหสามารถ เขาถึงไดจากทุกสถานทีแ่ ละทุกสถานการณ 4 l Bay Computing Newsletter l 5rd Issue
แผนการคงความตอเนื่องของธุรกิจ (Business Continuity Plan : BCP) จะตองประกอบไปดวย สาระสำคัญอยางนอย ดังตอไปนี้ Business Continuity Planning (BCP) เกีย่ วของ กับการ Maintain การกลับไปดำเนินงาน (Resuming) และการกูคืนของธุรกิจ ไมใชเพียงการกูคืนสภาพ ของเทคโนโลยีเทานั้น กระบวนการออกแบบแผน ตองทำในระดับของ ทัว่ ทัง้ องคกร ไมใชเพียงหนาทีข่ องเทคโนโลยี หรือ ฝายบริหารเทานั้น การทำ Business Impact Analysis และ Risk Assessment อยางทะลุปรุโปรงเปนพืน้ ฐานทีส่ ำคัญ ของ BCP ที่ดี ความมีประสิทธิภาพของ BCP จะสามารถ ตรวจวัดไดจากการทดสอบ และฝกซอมเทานัน้
แผน BCP และผลการทดสอบ ควรเปนหนาทีข่ อง ผูตรวจสอบอิสระ และถูกนำเสนอเพื่อตรวจทาน โดยผูบริหารระดับสูง แผน BCP ควรถูกปรับปรุงอยางสม่ำเสมอ เพือ่ สะทอนถึงและตอบสนองตอความเปลี่ยนแปลง ภายในองคกร หรือผใู หบริการทีใ่ หบริการแกองคกร ขัน ้ ตอนการออกแบบแผน Business Continuity 1. Business Impact Analysis 2. Risk Assessment 3. Risk Management 4. Other Policies, Standards and Processes 5. Risk Monitoring
Business Impact Analysis
ขัน้ ตอนการทำ Business Impact Analysis (BIA) หรือการวิเคราะหถึงผลกระทบที่เกิดขึ้นกับธุรกิจ เปนขั้นตอนแรกในการออกแบบ BCP ซึ่งควรจะ ประกอบดวยสิง่ เหลานี้ คือ การระบุถึงความเปนไปไดของผลกระทบ ใน กรณีที่เกิดเหตุการณที่ไมสามารถควบคุมได หรือ ไมสามารถระบุลวงหนาได เกิดขึ้นกับความคงอยู ของธุรกิจและลูกคาของธุรกิจ คำนึงถึงทุกแผนก ทุกสวน และหนาทีข่ องธุรกิจ ไมเพียงแคการประมวลผลขอมูลเทานัน้ ประมาณการณถึงเวลามากที่สุด ที่ยอมใหเกิด downtime และระดับทีย่ อมรับไดของการสูญเสีย ขอมูล การปฏิบตั งิ าน และความสูญเสียทางการเงิน
Risk Assessment
Risk Assessment หรือ การประเมินความเสี่ยง เปนขั้นตอนที่ 2 ในการสรางแผน BCP โดยควร จะ ประกอบไปดวยสิง่ เหลานี้ คือ การจัดลำดับความสำคัญ (Prioritizing) ของ ความเปนไปไดทสี่ ง ผลตอการดำเนินการของธุรกิจ โดยเรียงตามลำดับความรายแรง และโอกาสทีจ่ ะ เกิดขึ้นไดของเหตุการณนั้นๆ ทำ Gap Analysis โดยเปรียบเทียบกับ BCP ป จ จุ บั น และถ า มี ควรระบุ ว า สิ่ ง ใดบ า งที่ ต อ ง
COVER STORY กำหนด Recovery Time และ Recovery Point Objective (RTO, RPO) การวิเคราะหถึงภัยคุกคาม โดยใชพื้นฐานจาก ผลกระทบทีจ่ ะเกิดกับองคกร ลูกคา และเศรษฐกิจ ภายนอก ไมใชจากลักษณะหรือคุณสมบัตขิ องภัย คุกคามนั้นๆ
Risk Management
Risk Management เปนขั้นตอนของการพัฒนา BCP ที่เขียนขึ้น และทำในระดับทั่วองคกร ซึ่ง องคกรตองทำใหแนใจวา BCP มีสิ่งตางๆ เหลานี้ เขียนขึน้ และมีรายละเอียด เพือ่ ใหบคุ ลากรใน หลายๆ กลมุ สามารถนำไปปฏิบตั แิ ละใชงานไดใน เวลาไมนานเกินไป มีการระบุอยางชัดเจนวา เหตุการณใดบางจึง ควรรีบนำแผนนี้ไปใชและปฏิบัติ มีการระบุอยางชัดเจนวา กระบวนการทีต่ อ งทำ เมือ่ เกิดเหตุขดั ของขึน้ คืออะไรบาง มี ค วามยื ด หยุ น พอเพื่ อ จะตอบสนองต อ ภั ย คุกคาม ที่ไมไดคาดการณไวลวงหนา และความ เปลี่ยนแปลงที่เกิดขึ้นภายในองคกรเอง หลังการ กำหนดแผน ทำการโฟกัสไปยังการปฏิบัติงานที่ทำใหธุรกิจ กลับมาดำเนินการตอได ในเหตุการณทสี่ ถานทีแ่ ละ สิง่ อำนวยความสะดวก (Facility) หรือ Function ของธุรกิจไมสามารถดำเนินตอไดมากกวา มีประสิทธิภาพในการลดความไมตอเนื่องของ การใหบริการ และความสูญเสียในรูปตัวเงิน
Other Policies, Standards and Processes
เปนการนำแผน BCP มาเปรียบเทียบ และคำนึงถึง ผลกระทบที่ อ าจส ง ผลต อ กฎ นโยบาย และ มาตรฐานที่ อ งค ก รจำเป น ต อ งปฏิ บั ติ ต าม เช น มาตรฐาน ISO หรือ GLBA เปนตน ซึ่งประกอบ ไปดวย System Development Life Cycles นโยบายการทำ Change Control Data Synchronization Procedures แผนการฝกอบรมบุคลากร และ แผนการสือ่ สาร ในองคกร นโยบายการรับประกัน หรือ ทำประกัน องคกรภาครัฐ, สื่อ และนโยบายในการสื่อสาร กับชุมชนขององคกร Security
Risk Monitoring
การทำ Risk Monitoring เปนกระบวนการในการ
คอยตรวจสอบประสิทธิภาพ และปรับปรุงแผน BCP โดยประกอบดวยสิ่งเหลานี้ คือ ทำการทดสอบแผน BCP อยางนอยปละ 1 ครั้ง นำสงแผน BCP ใหกับผูตรวจสอบอิสระทำการ Review หรือใหคำแนะนำ ทำการปรับปรุงแผน BCP โดยยึดถือตามการ เปลีย่ นแปลงทีเ่ กิดขึน้ กับบุคลากร และสภาพแวดลอม ทัง้ ภายในและภายนอก
เทคโนโลยีทน ี่ ย ิ มใชในการทำ Business Continuity
เราจะมาดู ใ นรายละเอี ย ดของการเลื อ กใช เทคโนโลยีเพื่อความเหมาะสม โดยสามารถสรุป อยางงายๆ ดังตารางตอไปนี้
ภาพแสดงปญหาของการใชงาน Microsoft Cluster โดยทั่วไป
อยางแนนอน ไมเกิดเหตุการณ ที่หา Tape ไมพบ หรือ Tape วางเปลา อีกตอไป เทคโนโลยี ที่ เ ป น ที่ นิ ย มใน ปจจุบัน ทั้งสภาพแวดลอมที่ ใช ระบบปฏิบัติการ Windows และระบบปฏิบตั กิ าร Unix/Linux คื อ การทำ Cluster ซึ่ ง เป น เทคโนโลยีที่มีความเหมาะสม กับการทำงานที่ตองการความ จากแผนภาพดานบน พอจะสรุปไดวา เทคโนโลยี หลักๆ ทีน่ ยิ มใชกนั ในปจจุบนั ประกอบไปดวย Backup Replication-Failover Clustering Continuous Availability โดยแตละเทคโนโลยีกม็ คี วามเหมาะสมและตนทุน ในการดูแลและจัดหาแตกตางกันไป ขึ้นอยูกับ การประเมินความตองการตามกระบวนการที่ได กลาวมาแลวขางตน การสำรองขอมูล หรือ Backup เปนวิธีการและ เทคโนโลยีทมี่ กี ารใชงานมาตอเนือ่ งยาวนาน และ ยังถือวามีความสำคัญในปจจุบนั แตกเ็ ปนวิธกี าร งายๆ ที่หลายๆ คนยังคงมองขาม การกำหนด กระบวนการขั้ น ตอนอย า งเหมาะสมเป น สิ่ ง ที่ สำคัญทีส่ ดุ เพือ่ ใหการ Backup สัมฤทธิผล รวมถึง การทดสอบกูคืนขอมูล (Restore) ขอมูลอยาง สม่ำเสมอ เปนอีกสิ่งที่พึงกระทำ เพื่อใหมั่นใจวา เมือ่ เกิดเหตุขดั ของ จะสามารถกคู นื (Restore) ได
ต อ เนื่ อ งในระดั บ หนึ่ ง เนื่ อ งจากระหว า งการ Failover จาก Node หนึ่งไปยังอีก Node หนึ่ง จะเกิดความขาดชวงกัน โดยเฉพาะความตอเนือ่ ง ในระดั บ Session และ Transaction ของ Application ที่ทำงานอยูบน Cluster ตัวอยางเชน ระบบปฏิบัติการ Microsoft Windows Cluster มีขอ เสียทีพ่ อจะสรุปเปนแผนภาพทางดานบน โดยจะเห็นวาขอเสียหลักของ Microsoft Windows Cluster คือ จำเปนตองใช Application License ถึง 2 ชุด และมีความไมตอ เนือ่ งของ Session และ Transaction ในหนวยความจำระหวาง Node เมือ่ เกิดเหตุการณ failover ขึน้ และความเสีย่ งทีเ่ กิด จากการใช Disk ที่แชรภายนอกทำใหตองเพิ่ม ตนทุนและเปนจุดทีเ่ สีย่ งตอการเปนตนเหตุใหเกิด ขอผิดพลาดได (Single Point of Failure) ในตอนตอไป เราจะมาลงรายละเอียดในสวน ของแนวโนมเทคโนโลยีของการทำ Business Continuity อืน่ ๆ และการประยุกตใชเพือ่ ใหเกิด ประโยชนสูงสุดสำหรับแตละ Application Bay Computing Newsletter l 5rd Issue l 5
IT GREEN
คุณพรอมเตรียมรับกระแส ไอทีสเี ขียว (Green IT) แลวหรือยัง? z โดย เทรนด ไมโคร
กระแสไอทีสเี ขียว กำลังเริม่ เปนทีก่ ลาวขานกันอยางมากในทุกๆ วงการทีม่ ไี อทีเปนสวนเกีย่ วของ หัวขอดังกลาวไดรบั การตอบรับอยางกวางขวางทัง้ ในมุมมองของผผู ลิตและผบู ริโภค และยัง ไดรับการตอบรับอยางดีในสังคมดวย เนื่องจากในทุกวันนี้คนสวนใหญเริ่มตื่นตัวกันมากขึ้นในเรื่อง ของการอนุรักษพลังงานและอนุรักษสิ่งแวดลอม และเริ่มมีการรณรงคเพื่อปกปองสิ่งแวดลอมที่ได รับการตอบรับเปนอยางดี ไมวา จะเปนแนวคิดพลังงานสีเขียว หรือถุงผาลดโลกรอน หันกลับมามองใน โลกไอทีของเราบาง เปนที่ทราบกันดีในหมูนักอนุรักษวา โลกไอทีกอใหเกิดมลภาวะสูง ไมวาจะเปน ในสวนของการผลิตหรือขยะไอที ที่นับวันจะมีแตเพิ่มขึ้นอยางรวดเร็ว (อันเนื่องจากอายุการใชงานที่ สั้นลง) และรวมถึงดานการใชพลังงานที่นับวาสิ้นเปลืองพอสมควร จึงเปนที่มาของ ไอทีสีเขียว ที่กำลังไดรับการกลาวขานถึงอยางกวางขวางนี่เอง
6 l Bay Computing Newsletter l 5rd Issue
IT GREEN เรามาลองดูกนั วาเราจะชวยลดภาระขององคกร และลดมลภาวะ ทีเ่ กิดขึน้ จากอุตสาหกรรมไอทีในองคกรของเราไดอยางไรบาง ในปจจุบันมีการนำเสนอแนวทางหลายทางที่สามารถนำมา ประยุกตใช ไมวาจะเปนในแงของการใชผลิตภัณฑไอทีที่ได รับเครื่องหมาย Energy Star หรือเลือกใชผลิตภัณฑที่ทำ จากวัสดุ Recycle (ทั้งหีบหอและตัวผลิตภัณฑ) แตในวันนี้ ผเู ขียนจะขอนำเสนออีกเทคโนโลยีหนึง่ ทีเ่ รียกวา Consolidation and Virtualization ทัง้ 2 เทคโนโลยีนไี้ ดมกี ารกลาวถึงมาเปนระยะเวลาหลายป แตเพิง่ จะเริม่ มีการนำมาประยุกตใชรวมกันเมือ่ ไมกปี่ ท ผี่ า นมา โดยเทคโนโลยี Consolidation นัน้ มีการแนะนำใหมกี ารรวม เซิรฟ เวอรทใี่ ชอยใู นองคกรทีม่ อี ยเู ปนจำนวนมาก (สังเกตจาก จำนวน Rack) ใหเหลือนอยลง ซึง่ จะชวยประหยัดไดทงั้ พืน้ ที,่ อุณหภูมิ (เซิรฟ เวอร 1 ตัวจะสรางความรอนประมาณ 10oC 35oC ในขณะที่ตูเย็นที่ใชตามบานทั่วไปก็สรางความรอน ประมาณ 32oC เพราะฉะนั้ น อย า แปลกใจว า ทำไมห อ ง เซิรฟเวอรถึงตองเย็นมาก) และรวมถึงสวนที่สำคัญที่สุดคือ ปริมาณการใชกระแสไฟฟา (เซิรฟ เวอร 1 ตัว จะใชกระแสไฟฟา อยทู ปี่ ระมาณ 670W ในขณะทีท่ วี ี LCD 52" ใชกระแสไฟฟา เพียง 290W เทานัน้ ) ทางผผู ลิตเซิรฟ เวอรทงั้ หลายจึงไดมกี าร แนะนำผลิตภัณฑที่เรียกวา Blade Server ออกมา ภายใต แนวคิดทีว่ า องคกรสามารถลดจำนวนเซิรฟ เวอรทใี่ ชในองคกร ใหเหลือนอยทีส่ ดุ โดยทีย่ งั ไดประสิทธิภาพการทำงานเทาเดิม โดย Blade Server นั้ น สามารถจำลองการทำงานของ เซิรฟ เวอรทวั่ ๆ ไปไดตงั้ แต 4 เซิรฟ เวอร จนถึง 32 เซิรฟ เวอร ใหทำงานไดบนตัว Blade Server แคเพียงเครือ่ งเดียวเทานัน้ นอกจากช ว ยประหยั ด พื้ น ที่ ที่ ต อ งการใช แ ล ว ยั ง ช ว ยลด ปริมาณความรอนที่เกิดขึ้น และที่สำคัญลดปริมาณการใช กระแสไฟฟาไดอยางมากอีกดวย (จาก 4 x 290W = 1,160W เหลือเพียง 950W เทานัน้ ) สวนของเทคโนโลยี Virtualization นัน้ มีในตลาดมาเปนเวลา นานแลว แตเพิง่ ไดรบั การตอบรับจากผผู ลิตซอฟตแวรมากขึน้ ในชวง 2 ปทผี่ า นมานีเ้ อง แมกระทัง่ ทางไมโครซอฟทเองก็มี เปาหมายที่จะขยายตลาดดาน Virtualization ใหมากยิ่งขึ้น การทำ Virtualization นั้น เกิดมาจากแนวคิดที่มีการวิจัย พบวา โดยปกติเซิรฟ เวอรทใี่ ชงานอยนู นั้ ทำงานในระดับปกติ อยเู พียงแค 10-20 เปอรเซ็นต ของประสิทธิภาพของทัง้ หมด และใน 1 เซิรฟ เวอรกท็ ำงานแคเพียงหนาทีเ่ ดียว โดยมีเหตุผล วาการใหเซิรฟเวอรทำงานมากกวาหนึ่งงานขึ้นไป อาจทำให ประสิทธิภาพของการทำงานลดลงและเสีย่ งตอการเกิด single point of failure อีกดวย แตปญ หาทีส่ ำคัญทีไ่ มมกี ารแนะนำ ใหตดิ ตัง้ ซอฟตแวรหลายๆ ตัวลงบนเซิรฟ เวอรตวั เดียวก็คอื ปญหา ดานการจัดการทรัพยากรระบบ (Resource Management) ซึง่ ปญหาดังกลาวเกิดขึน้ จากตัวระบบปฏิบตั กิ ารนัน่ เอง จึงมี การนำเทคโนโลยี Virtualization มาแกปญ หาดังกลาว โดยที่
ตั ว Virtualization Software จะเข า มาทำหน า ที่ บ ริ ห าร ทรัพยากรระบบแทน จึงทำใหเซิรฟ เวอรสามารถทำงานตางๆ ไดมากขึน้ โดยสามารถทำใหใชทรัพยากรทีม่ อี ยไู ดเพิม่ ขึน้ ถึง 80 เปอรเซ็นต และลดความตองการดานตัวอุปกรณไดถึง อัตราสวน 10:1 เลยทีเดียว
CPU
Memory
NIC
Disk
จาก 2 แนวคิดขางตน ทำใหเกิดแนวขึน้ ทีจ่ ะลดขนาดเซิรฟ เวอร ที่ ใ ช ใ นองค ก รด ว ยการทำ server consolidation and virtualization เกิดขึ้น โดยการรวมเซิรฟเวอรจำนวนมากที่มี อยลู งสรู ะบบ Blade Server และใช Virtualization ในการเพิม่ ประสิทธิผลในการทำงานใหมากทีส่ ดุ (Maximum Utilization) แนวความคิดนีเ้ ริม่ มีการพูดถึงกันมากขึน้ อยางแพรหลาย แต ยังติดปญหาในสวนของการลงทุนตัง้ ตน (Initial Cost) ซึง่ เปน จำนวนเงินที่สูงมาก แตถาเทียบกับผลลัพธที่ไดในระยะยาว ไมวา จะเปนเรือ่ งของการลดความรอน ปริมาณการใชกระแส ไฟฟา รวมถึงการดูแลรักษา และขยะที่จะเกิดขึ้นในอนาคต (เมือ่ คุณหันมาใช blade server ก็จะเหลือขยะเพียงชิน้ เดียว ในอี ก 5 ป ข า งหน า ) และขณะนี้ แนวคิ ด นี้ ก็ ไ ด ถู ก นำไป พิจารณาในหลายๆ องคกรเพื่อที่จะนำมาใชกับองคกร เพื่อ ลดจำนวนเซิรฟ เวอรทใี่ ชอยเู ปนจำนวนมากอีกดวย สนใจรับเอกสารเกี่ยวกับประโยชนในการใช Virtualization เพิ่มเติม หรือ ขอรับ Software Trail เพือ่ ทดลองใช กรุณาติดตอ
คุณมทินา สหวัฒน / Product Marketing Manager Bay Computing Co., Ltd. โทร. 0-2962-2223 ตอ 612 หรือ อีเมล : matina@baycoms.com เพื่อแจงความประสงคในการรับ InterScan Web Security Virtual Appliance (IWSVA) หรือ InterScan Mail Security Virtual Appliance (IMSVA) หรือ ทั้ง IWSVA กับ IMSVA
Bay Computing Newsletter l 5rd Issue l 7
SOLUTION UPDATE ในฉบับทีแ่ ลว เราไดทราบถึง “ความตองการทัว่ ไป” ซึง่ เปนปจจัยแรก จากทัง้ หมด 5 ปจจัยทีอ่ งคกรตอง คำนึงถึงในการสรางโครงสรางพื้นฐานของระบบการจัดการ Log ดังนั้น ในฉบับนี้เราจะมาทำความเขาใจกับ 4 ปจจัยที่ เหลือกันตอ
II. การตรวจจับและการสราง Log (Log Generation and capture)
1. จัดเตรียมใหมก ี ารรวบรวมขอมูล จากแหลงตางๆ จากการที่ อ งค ก รส ว นใหญ มั ก จะมี ร ะบบต า งๆ ที่ มี ค วาม หลากหลายแตกตางกันออกไป ดังนั้น โครงสรางพื้นฐาน ของ Log Management จึงควรรองรับการเก็บรวบรวมขอมูล (collection) จากระบบรักษาความปลอดภัย ระบบปฏิบตั กิ าร และแอพพลิเคชันทุกๆ ชนิดทีอ่ งคกรใชอยู แตมนั ไมเสมอไป ที่จะรองรับอุปกรณหรือแอพพลิเคชันไดทุกชนิด เทคโนโลยี SIEM (Security Information and Event Management) จึง ควรจัดเตรียมไวเปนหนทางสะดวกในการเพิ่มการสนับสนุน อุปกรณรนุ เกา (legacy) และแอพพลิเคชันทีอ่ งคกรพัฒนาขึน้ เฉพาะของแตละองคกรดวย
2. รองรับการเก็บรวบรวมขอมูล ปริมาณมากๆ ได สำหรับเทคโนโลยี SIEM นัน้ ความสามารถในการประมวลผล ขอมูล Log จะถูกจัดระดับ (rate) โดยจำนวนของเหตุการณ (event) ที่สามารถประมวลผลไดภายในเวลาที่กำหนด ซึ่ง ปกติเราวัดกันโดยมีหนวยเปน EPS (Events Per Second) สำหรับแพลตฟอรมของ Log Management ทีด่ นี นั้ ควรจะ สามารถจัดการไดดที งั้ กับปริมาณงานปกติ (typical volume) และปริมาณงานหนาแนนสูงสุด (peak volume) ไมวา Log นั้นๆ จะมาจากแหลงใดก็ตาม ความสามารถดังกลาวยัง รวมไปถึงความสามารถในการรองรับสถานการณตา งๆ ทัง้ ที่ ตั้งใจใหเกิดขึ้นและไมไดตั้งใจใหเกิดขึ้นดวย เชน การแพร กระจายของมั ล แวร การสแกนหาช อ งโหว ต า งๆ การทำ Penetration Test ที่อาจจะเปนสาเหตุใหเกิดการสราง Log เปนจำนวนมากภายในชวงเวลาสั้นๆ 3. รวบรวมขอมูลไดอยางถูกตอง เทคโนโลยี SIEM ไดรบั การออกแบบมาโดยตัง้ อยบู นพืน้ ฐาน ของระบบฐานขอมูลเชิงสัมพันธ (relational database system หรือ RDBS) ซึง่ จะวิเคราะหแจงสวนขอความ Log เพือ่ ทีจ่ ะ
แนวทางการปฏิบต ั ท ิ เี่ หมาะสม สำหรับการจัดการขอมูล Log ตอนที่ 3
“Infrastructure Requirements” z โดย ภูรท ิ ตั ทองปรีชา
ใสขอมูลลงในคอลัมนตามโครงสรางที่กำหนด ดวยวิธีการนี้ เปนไปไดวา ขอมูลจะถูกเขียนลงไปในฐานขอมูลอยางไมถกู ตอง หรืออาจถึงขัน้ ขอมูลสูญหายไปเลยก็ได นัน่ เปนเพราะขอความ Log จากระบบและอุปกรณจำนวนมากทัว่ ทัง้ องคกรมีรปู แบบ ฟอรแมตที่ไมเหมือนกัน และมักไมถูกตองตรงกับรูปแบบ โครงสรางของ RDBS ตัวอยางเชน ไฟรวอลลทถี่ กู อัพเกรด อาจมีฟอรแมตของขอความ Log ของไฟรวอลลเปลีย่ นไป ทำใหระบบ RDBS ทีเ่ คยออกแบบ ไวในแพลตฟอรม SIEM จัดการกับฟอรแมตแบบใหมไดยาก และ อาจเกิดความสับสนหรือตกหลนบางขอมูลได และหากขอความ Log แบบใหมมขี อ มูลแตกตางจากเวอรชนั กอนหนา ก็เทากับวา ขอมูลที่ถูกรวบรวมมานั้น แทนที่จะถูกเขียนลงในคอลัมน A เหมือนเวอรชนั กอนหนา ก็อาจถูกนำไปเขียนลงในคอลัมน B ได เปนตน นอกจากนีห้ ากขอความ Log แบบใหมมขี อ มูลเพิม่ ขึน้ จากทีเ่ คยมีในเวอรชนั กอนหนา ก็จะทำใหคอลัมนไมสอดคลอง กันและขอมูลอาจจะถูกตัดทิง้ ไปดวย 8 l Bay Computing Newsletter l 5rd Issue
SOLUTION UPDATE
อีกปจจัยทีค่ วรระลึกถึงในการเก็บรวบรวมขอมูลใหถกู ตองคือ วิธที เี่ ทคโนโลยี SIEM ใชจดั การกับ การพุช (pushing) ของ ขอความจากอุปกรณตางประเภท โดยอุปกรณที่เปนยูนิกซ จำนวนมากจะใชโพรโตคอล UDP (User Datagram Protocol) เพือ่ สงขอความทีร่ วมถึงขอมูล Log ดวย โดยเทคโนโลยี UDP push ผสู ง จะไมตรวจสอบวาขอความสงถึงปลายทางหรือไม จึงไมมกี ารแจงกลับหากสงไมได ดวยเหตุนี้ เทคโนโลยี SIEM ตองรวบรวมใหถูกตองและจับทุกขอความ UDP แมแตชวงที่ มีปริมาณการสงสูงสุด ไมอยางนัน้ ขอความดังกลาวจะหายไป แบบถาวร
III. การเก็บขอมูล Log และอุปกรณ จัดเก็บ (Log retention and storage)
1. สนับสนุนกลยุทธ ILM (Information Lifecycle Management) ดวยวิธีการ ทีข่ อ มูลจะถูกจัดเก็บในสตอเรจทีแ่ บงระดับชัน ้ ตามความตองการใชงานของขอมูล โครงสรางพืน้ ฐานสำหรับ Log Management ควรครอบคลุม ถึงระบบจัดเก็บขอมูลที่แบงเปนระดับชั้นเอาไวดวย เพื่อให องคกรสามารถจัดการใชงานระบบสตอเรจไดทงั้ แบบ On-line, Off-line, Near-line และแบบ Off-line ซึง่ นอกจากจะเปนการ ใชสอื่ บันทึกขอมูลไดอยางถูกตอง คมุ คา และไดประสิทธิภาพ สูงสุดแลว ยังจะชวยใหเกิดระดับของการเขาถึงขอมูลทีแ่ ตกตาง กันไดอกี ดวย ตัวอยางเชน On-line Storage : ขอมูลจะถูกเก็บอยใู นระบบสตอเรจแบบ เน็ตเวิรก (Networked Storage Systems) ทีม่ ปี ระสิทธิภาพ สูง มีระยะเวลาการเขาถึงขอมูล (Access times) เพียงไมกี่ เสีย้ ววินาทีเทานัน้ ทัง้ นีเ้ พือ่ ใหผใู ชทมี่ อี ยจู ำนวนมากสามารถ เขาถึงขอมูลไดตลอดเวลา Near-line Storage : ขอมูลจะถูกเก็บอยูในระบบสตอเรจ ยอย (Storage subsystem) ที่มีระยะเวลาการเขาถึงขอมูล ในระดับวินาที สำหรับความตองการเขาถึงขอมูลทีไ่ มบอ ยนัก ของผู ใ ช ง านจำนวนไม ม ากที่ มี ห น า ที่ เ ข า ใช ง านในส ว นนี้ (dedicated users) และนานๆ ครัง้ ถึงจะเขามาใชงาน
Off-line Storage : ขอมูลจะถูกเก็บเอาไวในดิสกและเทป ทีถ่ กู เก็บเอาไวในหองเก็บขอมูล (data library) ซึง่ คอมพิวเตอร ใดๆ จะไมสามารถเขาถึงขอมูลในสวนนี้ได จนกวาจะมีการ เชือ่ มตอ (mount) ใหสามารถใชงานไดเสียกอน สำหรับระยะเวลาในการเก็บขอมูลทีเ่ ปน Production, Back-up และ Archive นั้น จะขึ้นอยูกับนโยบายของแตละองคกรที่ จะแตกตางกันออกไป อยางไรก็ตาม คำแนะนำตาม RSA Recommended Best Practices ไดระบุเอาไววา ระยะเวลา ในการเก็บสำรองขอมูลทีเ่ หมาะสมสำหรับ Production Data ก็คอื ไมควรนอยกวา 1 ปบวกกับอีก 1 ไตรมาส หรือเทากับ 15 เดือนนัน่ เอง ซึง่ ระยะเวลาในการออนไลนเอาไว 15 เดือน นี้จะชวยทำใหแนใจไดวา การใชประโยชนจากขอมูลจะยัง คงสมบูรณและสามารถเขาถึงไดอยตู ลอดรอบการตรวจสอบ (Audit Cycle) ทั้งจากภายในและภายนอกองคกร RSA Recommended Best Practices ไดแนะนำเอาไวดว ย วา สำหรับ Back-up Data นั้นควรจะเก็บอยูใน Near-line Storage ในระยะเวลาเทาๆ กับ Production Data ทัง้ นีเ้ พือ่ ใหแนใจวา Back-up Data จะสามารถพรอมใชงานไดทันที หาก Production Data เกิดความเสียหายหรือไมสามารถ ใชงานได ซึง่ จุดประสงคเดียวของการแบ็กอัพขอมูล Log คือ ตองสามารถกคู นื ขอมูลไดเมือ่ ตองการ 2. ใชกลยุทธการบริหารจัดการตามชวงอายุ ตัง้ แตเกิดจนตาย กับขอมูล Log โครงสรางพื้นฐานควรจะสนับสนุนการบริหารจัดการขอมูล Log ตลอดชวงอายุการใชงาน นั่นหมายถึง มีการบังคับใช นโยบายการเก็บขอมูลขององคกรอยางอัตโนมัติ ตัวอยางเชน มันควรงายในการกำหนดใหแพลตฟอรม SIEM สามารถเก็บ ขอมูล Log แตละประเภทเอาไวโดยมีระยะเวลาในการเก็บที่ แตกตางกันออกไป รวมทัง้ การอนุญาตใหเลือกจัดเก็บขอมูล Log จากแอพพลิเคชันที่แตกตางกันในชวงเวลาตางกันได แพลตฟอรมดังกลาวควรยอมใหผดู แู ลระบบสามารถโยกยาย Log จากสตอเรจระดับหนึง่ ไปยังสตอเรจอีกระดับหนึง่ ได เชน ยายจากสตอเรจแบบ On-line ไปสตอเรจแบบ Near-line และ สามารถลบขอมูล Log ที่ตรงกับเงื่อนไขได สวนการขยาย Bay Computing Newsletter l 5rd Issue l 9
SOLUTION UPDATE ระยะเวลาการจัดเก็บจากเดือนเปนปตอ งมีการจัดการทีง่ า ยไม ยงุ ยาก 3. สามารถคนหาขอมูลไดอยางรวดเร็ว ไมวา จะ เก็บอยท ู ไี่ หน (On-line, Near-line, Off-line) โครงสรางพื้นฐานของ Log Management ควรจะสามารถ เติบโตเพือ่ รองรับขอมูล Log ปริมาณมากๆ ในวันขางหนาได พรอมกับตองมีเครือ่ งมือคนหาและเรียกดูขอ มูล Log ไดอยาง รวดเร็ว ซึง่ จะทำใหขอ มูลดังกลาวมีประโยชนอยางมาก และ ผใู ชงานของระบบไดผลิตผลมากขึน้ การเรียกดูขอ มูล Log ทีจ่ ดั เก็บไวไดอยางรวดเร็ว ถูกทำใหงา ย ขึ้นได ดวยโครงสรางพื้นฐานที่มีลักษณะดังตอไปนี้ เก็บขอมูล Log แบบ On-line และ Near-line : เพราะ การเรี ย กข อ มู ล Log จากสื่ อ สตอเรจบางชนิ ด อาจช า ได ตัวอยางเชน การโหลด archived log จากเทปแทนการเรียก โดยตรงจากไฟล On-line log จัดการขอมูลจากสวนกลาง : ดวยวิธกี ารเขาถึงสตอเรจ แบบไซโล การเรียกดูขอ มูลจะถูกทำใหชา เพราะขอมูลทัง้ หมด ไมสามารถคนหาไดภายในครัง้ เดียว ตองคนหาทามกลางขอมูล Log ทีถ่ กู จัดเก็บกระจายอยใู นระบบสตอเรจทีห่ ลากหลาย อยาใชฐานขอมูลเชิงสัมพันธ (Relational Database) : เพราะฐานข อ มู ล เชิ ง สั ม พั น ธ จ ะค น หาข อ มู ล ที่ ใ หญ ข นาด เพตะไบตไดชา มาก เนือ่ งจากตองรวม (merge) องคประกอบ ตางๆ ของขอมูลที่หลากหลายเขาไวดวยกันในแถว (rows) หรือตาราง (tables) ทำใหระบบไมสามารถเขาถึงองคประกอบ ตางๆ ของขอมูลได จัดเตรียมสตอเรจแบบระดับชั้น : การโยกยายขอมูลที่ มีการใชงานไมบอ ยนักออกจากระบบสตอเรจหลัก ทำใหงา ย สำหรับผูใชในการคนหาขอมูลที่ตองการไดเร็วขึ้น
10 l Bay Computing Newsletter l 5rd Issue
4. มีระบบจัดการทีด ่ เี มือ ่ เลิกใชขอ มูลแลว เมือ่ ขอมูล Log ไมมคี วามจำเปนตองใชอกี ตอไป แพลตฟอรม ที่ดีควรมีระบบที่งายและเชื่อถือไดในการจัดการกับขอมูล ดังกลาว องคกรควรสามารถตัง้ คำสัง่ ยายขอมูล Log ทัง้ หมด ที่เขามากอนหนาวันและเวลาที่กำหนดไปไวที่อื่น แตการลบ ขอมูลแบบถาวรเปนการลบทีไ่ มเหมาะสม เพราะไฟลทถี่ กู ลบ อาจจำเปนตองถูกกูคืนหรือสรางใหมเพื่อใชงานในกรณีที่มี การฟองรอง
IV. การวิเคราะห Log (Log Analysis)
1. มองเห็นภาพรวมของทั้งองคกร โครงสรางพื้นฐานของระบบควรมีอินเทอรเฟซแบบกราฟก (Graphical User Interface : GUI) ทีช่ ว ยใหสามารถตรวจสอบ และวิเคราะหขอมูล Log ทั้งหมดที่รวบรวมมาจากระบบ อุปกรณ และแอพพลิเคชันตางๆ ที่กระจายอยูทั่วเครือขาย ขององคกรได ดวยการมองเห็นภาพรวมของขอมูล Log นีจ้ ะ ทำใหองคกรเห็นภาพสถานะดานความปลอดภัยเกี่ยวกับ ทาทีและการรวมมือขององคกรได นอกจากนีเ้ หตุการณตา งๆ ที่เกิดขึ้นทั้งในอดีตและที่กำลังเกิดขึ้นในปจจุบันก็ควรถูกนำ มาแสดงดวย 2. ตรวจจับเหตุการณผิดปกติแบบอาศัยความ สัมพันธทขี่ อ มูลมีตอ กัน องคกรตองมีความพรอมในการระบุถึงเหตุการณตางๆ ที่มี ความสำคัญได เชน เหตุการณทเี่ กิดขณะนัน้ หรือปญหาใน การดำเนินการดานตางๆ ที่จำเปนตองมีการตอบสนองหรือ แกไขในลักษณะใดลักษณะหนึง่ เปนตน การตรวจสอบแตละ Log ทีเ่ ขามาอยางอิสระตอกันเปนเรือ่ งทีย่ งุ ยาก สูญเปลา และ ทำใหระบบที่ใชอยูแทบไมมีประโยชนอันใดเลย เพราะการ โจมตีมักจะเกี่ยวของกับทรัพยสินหลายๆ ชิ้นหรือหลายๆ เหตุการณ ถาคุณเพียงเฝาดูแตละอุปกรณหรือวิเคราะห เหตุการณที่เกิดขึ้นแยกกัน กิจกรรมเดี่ยวๆ ที่เกิดขึ้นอาจดู เหมือนไมไดเปนภัยคุกคามทั้งที่กิจกรรมนั้นเปนภัยคุกคาม นัน่ เพราะกิจกรรมนัน้ สัมพันธกบั กิจกรรมอืน่ ๆ ทีก่ ำลังเกิดขึน้
SOLUTION UPDATE ในเวลาเดี ย วกั น สำหรั บ ป ญ หาอื่ น ๆ จะเกี่ ย วกั บ การที่ มี เหตุการณจำนวนมากถูกตรวจพบจากหลากหลายอุปกรณ เพราะเปนการยากที่จะแยกแยะเหตุการณที่สำคัญออกจาก เหตุการณปกตินั่นเอง ดังนัน้ เพือ่ แยกแยะเหตุการณทไี่ มเกีย่ วของออกไปและสามารถ ระบุเหตุการณทมี่ คี วามสำคัญจริงๆ ได โครงสรางพืน้ ฐานของ Log Management จะตองมีความสามารถในการดำเนินการ เกีย่ วกับความสัมพันธของเหตุการณ (Event Correlation) ได ไมวา จะเปนการคนหารูปแบบของเหตุการณ หรือการมองหา ความสัมพันธระหวางขอมูล Log ที่เขามาตั้งแต 2 รายการ ขึน้ ไป ซึง่ โครงสรางดังกลาวจะเปนประโยชนอยางยิง่ ในการชวย ลดความผิดพลาดในลักษณะ false positive (ความผิดพลาด ทีร่ ะบบพิจารณาใหเปนเหตุการณทสี่ ำคัญทัง้ ทีใ่ นความเปนจริง ไมใช) ลงได ปกติความสัมพันธของเหตุการณสว นใหญจะเปนความสัมพันธ ตามกฎที่ Log ตางๆ ที่ไดจากแหลงเดียวหรือหลายแหลง สัมพันธกบั คุณคาของ Log เชน เวลาบันทึก (time stamp), หมายเลขไอพีแอดเดรส และประเภทของเหตุการณ ความ สัมพันธของเหตุการณสามารถแสดงในลักษณะอื่นไดดวย เชน การใชวิธีการทางสถิติหรือเครื่องมือที่ชวยใหมองเห็น (virtualization tools) 3. สรางระบบการเตือนภัยทีค่ รอบคลุมทุกประเภท ของการโจมตีและการฝาฝน ระบบเตือนภัยควรถูกสรางขึ้นเพื่อชี้วาเหตุการณใดหรือชุด ของเหตุการณใดจำเปนตองไดรบั การตรวจสอบ และตองไมใช แคเพียงแจงเตือนเมื่อเกิดการโจมตีที่เห็นแจมแจง แตตอง แจงเตือนเหตุลักลอบตางๆ ที่เกิดขึ้นบนเครือขายไดทุกที่ทุก เวลา ซึง่ สวนใหญผโู จมตีทชี่ ่ำชองจะไมแฮกเขาไปในเครือขาย ขององคกรทัง้ หมดในครัง้ เดียว แตจะโจมตีอยางชาๆ ทีเ่ รียกวา “Low and Slow attack” โดยการทดลองเจาะพอรตทีไ่ มคอ ย ไดใช แลวเวนชวงเปนวันหรือสัปดาหแลวคอยทดลองเจาะ ใหม จนกระทั่งหาชองโหวพบ โครงสรางพื้นฐานควรจะสามารถเตือนองคกรใหรูถึงความ เปนไปไดในการบุกรุกตั้งแตขณะที่เกิดเหตุการณเลยทีเดียว ไมวาเหตุการณนั้นๆ จะเปนเหตุการณที่เปนภัยตอนโยบาย ดานความปลอดภัยขององคกร หรือเปนภัยตอขอกำหนดดาน กฎหมายหรือมาตรฐานตางๆ ที่มีการกำหนดเอาไวก็ตาม ระบบการเตือนภัยควรจัดเตรียมวิธีที่มีประสิทธิภาพในการ ลำดับความสำคัญของเหตุการณที่เปนการละเมิดหรือการ บุกรุกใดๆ ทีจ่ ะเกิดขึน้ ได อยางไรก็ตาม ถาระบบการเตือนภัย ของคุณแจงเตือนเหตุการณตางๆ จนมากเกินความจำเปน แลว มันก็อาจจะทำใหผูดูแลระบบหมดความสนใจในสิ่งที่ ระบบเตือนก็เปนได
4. จัดเตรียมระบบพืน ้ ฐานอัตโนมัติ แพลตฟอรมที่ดีควรจะมีความสามารถในการเรียนรูลักษณะ การดำเนินการตามปกติขององคกรได และยกระดับการ เตือนภัยไดหากคาตัวแปรปกติถูกฝาฝน คุณสมบัติดังกลาว ถือวามีประโยชนอยางมากในการปองการโจมตีแบบ Zero-day Attack ซึ่งเปนการโจมตีที่ยังไมมีใครทราบแนวทางในการ ตรวจจับและแกปญหาที่ถูกวิธี 5. จัดเตรียมรายงานใหอต ั โนมัตแิ ละปรับเปลีย ่ นได การรายงานเปนการสรุปกิจกรรมสำคัญๆ ที่เกิดในชวงเวลา ต า งๆ ซึ่ ง จะมี ก ารบั น ทึ ก ข อ มู ล ที่ มี ร ายละเอี ย ดเกี่ ย วกั บ เหตุการณทผี่ ดิ ปกติสำหรับการวิเคราะห (forensic analysis) หรือการประเมินในเชิงที่เปนหลักฐานในการดำเนินการทาง กฎหมายได และแนนอนวาแพลตฟอรมที่ดีควรจะสามารถ รับมือกับความตองการการใชประโยชนจากรายงานทั้งใน ระยะสัน้ และระยะยาวไดดพี อๆ กันดวย การทำใหการสรางรายงานเปนเรือ่ งทีง่ า ยขึน้ นัน้ แพลตฟอรม ที่ดีควรจะจัดเตรียมรายงานชนิดตางๆ เอาไวใหผูใชงานได เลือกใชอยางหลากหลายพอสมควร และควรจะมีเครื่องมือ ในการสรางรายงานที่สามารถปรับแตงไดตามความตองการ (custom report) ของผใู ชงานแตละคนดวย แนนอนวาองคกร แตละแหงนั้นยอมจะมีความตองการที่ไมเหมือนกัน ดังนั้น ที ม งานที่ ดำเนิ น การด า นความปลอดภั ย และปฎิ บั ติ ต าม ขอกำหนดตางๆ นั้น ควรจะสามารถสรางรายงานที่ดีและมี ความหมายตอองคกรของตัวเองไดดวย 6. สนับสนุนการบริหารจัดการเหตุการณ ความสามารถทีจ่ ะตองพิจารณาสำหรับเทคโนโลยี SIEM นัน้ รวมไปถึงความสามารถในการลำดับความสำคัญดวย นั่น หมายถึงเหตุการณตา งๆ ทีเ่ กิดขึน้ จะถูกเรียงลำดับและจัดกลมุ แยกแยะประเภท ซึง่ จะทำใหการทำงานเปนเรือ่ งทีง่ า ยขึน้ Bay Computing Newsletter l 5rd Issue l 11
SOLUTION UPDATE และยังคงความถูกตองของขอมูลไดตลอดวัฏจักร ตั้งแตถูก สรางขึน้ จนกระทัง่ ถึงเวลาทีเ่ ลิกใช โดยทัว่ ไปแลว ขอมูล Log จะตองมีความสมบูรณ (integrity) และจะตองมีความนาเชือ่ ถือพอ เพือ่ ใหแนใจวาองคกรสามารถ มองเห็นภาพของกิจกรรมตางๆ ทีเ่ กีย่ วของกับสภาพแวดลอม ดานไอทีไดอยางถูกตองชัดเจน เพือ่ ใหสามารถตรวจสอบและ ประเมินพฤติกรรมของพนักงานไดอยางถูกตองและตรงกับ ความเปนจริงไดนนั่ เอง หาไมแลวขอมูลนัน้ ก็จะไมมคี า อันใดเลย 2. ควบคุมการเขาถึงขอมูล โครงสรางพืน้ ฐานทีด่ คี วรมีระบบการกำหนดสิทธิ (Authorized Assignment) ที่มีประสิทธิภาพ เพื่อปองกันมิใหผูใชงาน สามารถเขาถึงขอมูลทีพ่ วกเขาไมมสี ทิ ธิจะเขาถึงไดดว ย เรือ่ ง ดังกลาวถือเปนเรือ่ งสำคัญสูงสุดอีกประการหนึง่ สำหรับ Log Management ดวยเหมือนกัน ปจจัยสำคัญอีกประการหนึ่งที่จะสงผลกระทบตอการบริหาร จัดการกับเหตุการณทเี่ กิดขึน้ คือ การมีระบบ Vulnerability and Asset Management (VAM) ดวยการผนวกขอมูลเกี่ยวกับ องคกรและจุดออนทีม่ เี ขาดวยกันนัน้ ทำใหแพลตฟอรม SIEM สามารถชวยลดตนทุนตางๆ ในการจัดการกับเหตุการณทเี่ กิด ขึน้ ได ระบบ VAM สามารถปรับปรุงการตรวจจับความผิดพลาด ในลักษณะ false positive ลงได และชวยใหการตัดสินใจ กระทำการใดๆ ตอเหตุการณนนั้ ๆ มีการคำนึงถึงสถานะของ ทรัพยสนิ ขององคกรกอนทีจ่ ะทำการตัดสินใจดวยเสมอ 7. มีการกลัน ่ กรองขอมูล โครงสรางพืน้ ฐานควรจะสามารถทำใหแนใจไดวา นักวิเคราะห สามารถหาขอมูลทีพ่ วกเขาตองการไดอยางรวดเร็ว และขอมูล ที่ไดมีความนาเชื่อถือพอดวย พวกเขาควรจะสามารถคนหา ขอมูล Log ทั้งหมดไดดวยการใชคุณสมบัติการเขาถึง ที่ สามารถกำหนดได (definable attribute) และสิง่ ทีส่ ำคัญอีก ประการหนึ่งก็คือ การกลั่นกรองเหตุการณดวย “บัญชีจับ ตามอง” (watchlist) ที่จะสามารถตรวจสอบการดำเนินการ ใดๆ ของผใู ชงานทีอ่ ยใู นระบบ (specific user action) หรือ ภัยคุกคามตางๆ ทีก่ ำหนดเอาไว (security threat) หรือการ โจมตีจากแหลงทีม่ งุ ราย (malicious address) หรือการโจมตี ใดๆ ทีจ่ ะมีผลตอพอรตใดๆ (specific port) ในระบบของเราดวย
V. การปกปองและการรักษาความ ปลอดภัยของ Log (Log Security and Protection)
1. ปกปองบรูณาการของขอมูลตลอดวัฎจักร การใชงาน โครงสรางพืน้ ฐานทีด่ คี วรจะทำใหแนใจวาขอมูลจะถูกปกปอง จากการเปลีย่ นแปลงแกไขทีไ่ มมสี ทิ ธิ (unauthorized alteration)
12 l Bay Computing Newsletter l 5rd Issue
3. ดูแลรักษาระบบอยางตอเนือ ่ ง แพลตฟอรมสำหรับ Log Management ทีด่ คี วรจจะสามารถ ทำใหแนใจไดวา จะไมมีการสะดุดในภารกิจการเก็บขอมูล Log ซึง่ ในเรือ่ งนี้ องคกรควรจะมีการดูแลรักษาและอัพเกรด ระบบอยางสม่ำเสมอ เพือ่ ใหระบบทีอ่ อกแบบมาอยางดีแลว สามารถทำงานไดอยางตอเนื่องตลอดไปนั่นเอง
บทสรุป
ในสภาพแวดลอมทีเ่ ต็มไปดวยภัยคุกคามทัง้ จากภายในและ ภายนอกองคกร อีกทั้งเต็มไปดวยขอกำหนดตางๆ ที่จะตอง ปฏิบัติตามกฎหมายอยางเชนทุกวันนี้ ความจำเปนในการ พัฒนาแนวทางปฏิบัติที่เหมาะสม (Best Practice) สำหรับ Log Management นัน้ ก็จะยังคงเปนหัวขอทีม่ คี วามสำคัญ มากขึ้นเรื่อยๆ ตอไป และในการจัดเตรียมความตองการ สำหรับโครงสรางพื้นฐานที่มีประสิทธิภาพนั้น บทความชิ้นนี้ นาจะชวยใหองคกรตางๆ สามารถตระหนักและเห็นถึงความ สำคัญในการปฏิบัติตามขั้นตอนที่ถูกตองได และจะตอง สามารถสรางกลยุทธดา นเทคโนโลยีทจี่ ะเปนการวางรากฐาน ที่ดีแกการบริหารจัดการความเสี่ยงจากเหตุการณไมคาดฝน และภัยคุกคามที่จะเกิดขึ้นในอนาคตไดดวย เบย คอมพิวติง้ ผเู ชีย่ วชาญใน Solution Log Management เรายึดหลักแนวทางปฏิบัติที่เหมาะสม เพื่อใหเกิดประโยชน สูงสุดจากการจัดเก็บขอมูลอยางเต็มที่ (Best Practice) ขอมูล จราจรทางคอมพิวเตอรทที่ า นมีอยอู าจเพิม่ มูลคามหาศาลให แก อ งค ก รของท า น สามารถช ว ยองค ก รลดต น ทุ น หาก จัดเก็บอยางมีประสิทธิภาพและมีการนำไปวิเคราะหใหเกิด ประโยชน สนใจปรึกษาทีมงานเพื่อสอบถามขอมูลเกี่ยวกับ Best Practice ไดที่ หมายเลข 0-2962-2223
SOLUTION UPDATE
เสริมมาตรการความปลอดภัยไอทีดวย ISO 27001:2005 ตอนที่ 3
“คำจำกัดความ”
z โดย ภัคณัฏฐ โพธิท ์ องบวรภัค, Senior Network and Security Engineer, บริษทั เบย คอมพิวติง้ จำกัด
กลับมาพบกันอีกครัง้ นะครับ สำหรับเรือ่ ง ISO 27001:2005 มาตรฐานเกี่ยวกับ ระบบบริหารความมัน่ คงปลอดภัยของสารสนเทศ ในฉบับนีจ้ ะพูดถึงคำจำกัดความทีม่ กั พบบอยๆ ตอ จากตอนที่แลว เพื่อชวยใหเราศึกษามาตรฐาน ISO 27001:2005 ไดอยางเขาใจมากขึน้ Information Security Event : เปนเหตุการณ ที่บงบอกวาความปลอดภัยในระบบ บริการ หรือ ระบบเครือขายมีชองโหว หรือมีการละเมิดการ ปฏิ บั ติ ต ามนโยบาย หรื อ ระบบป อ งกั น ความ ปลอดภัยไมทำงานตามปกติ Information Security Incident : เปนเหตุการณ ที่เกิดขึ้นจากระบบ บริการ หรือระบบเครือขายมี ชองโหว ซึ่งทำใหขอมูลขององคกรหรือบริษัทไมมี ความปลอดภัย หรือทำใหการดำเนินธุรกิจของ องคกรมีปญหา Information Security Management System (ISMS) : เปนสวนหนึ่งในแผนการบริหารองคกร หรือบริษทั ประกอบดวย นโยบายตางๆ ขัน้ ตอนการ ดำเนินการ การวางแผน แนวทางปฏิบตั ิ การปฏิบตั ิ อยางตอเนือ่ ง กฎเกณฑ ความรับผิดชอบในหนาที่ ทรัพยากร และโครงสราง ที่ใชในการปองกันและ คมุ ครองขอมูล และยังรวมถึงสวนประกอบตางๆ ที่ องคกรใชในการจัดการและควบคุมความเสี่ยง
Information Security Policy : เปนนโยบายดาน ความมั่นคงปลอดภัยขอมูลที่มีการประกาศจาก ผูบริหารขององคกรหรือบริษัท เพื่อใหพนักงาน รั บ ทราบในเรื่ อ งการรั ก ษาความปลอดภั ย ของ ขอมูล และใชในการดำเนินการดูแลระบบและ ปรับปรุงระบบ ISMS Integrity : การคมุ ครองความถูกตองของขอมูล มีความหมายวา การปองกันความถูกตองและ ครบถวนของขอมูลและขั้นตอนในการดำเนินการ และจัดการ Management Review : มีวัตถุประสงคเพื่อ ประเมินผลภาพรวมของประสิทธิภาพ ISMS ของ องคกร และแกไขปรังปรุงในจุดทีเ่ กิดปญหา
Owner : คือ บุคคลหรือคณะบุคคลทีอ่ งคกรหรือ บริษทั แตงตัง้ ใหมหี นาทีค่ วามรับผิดชอบตอสินทรัพย หรือกลุมของสินทรัพย แตไมไดรวมถึงการเปน เจาของในทางกฎหมาย Asset Owner มีหนาที่ รับผิดชอบตอความปลอดภัยของสินทรัพยและ ดูแลใหสนิ ทรัพยสามารถใชในการดำเนินธุรกิจของ องคกรหรือบริษัท PDCA Model : ยอมาจาก Plan-Do-CheckAct ใน ISO 27001 วาไววา ในทุกๆ การดำเนินการ ของ ISMS ใช PDCA Model เป น ตั ว จั ด การ ประกอบดวย Plan (การวางแผนในการจัดทำ ISMS), Do (การดำเนินการจัดทำ ปฏิบตั ิ และดูแล ISMS), Check (การเฝาดูแล ตรวจสอบ และ พิจารณา ISMS) และ Act (การปรับปรุง ISMS) Policy : นโยบายที่ประกาศจากผูบริหารของ องคกรหรือบริษัท เพื่อใหพนักงานรับทราบและ ปฏิบัติไปในทิศทางเดียวกัน Preventive Actions : เปนขั้นตอนการปองกัน หลีกเลีย่ ง และดำเนินการกับปญหาหรือเหตุการณ ที่อาจจะเกิดขึ้น กอนที่ปญหาจะเกิดขึ้นกับองคกร หรือบริษัท Procedure : ตัวควบคุมขัน้ ตอนการดำเนินงาน หรือการปฏิบัติงาน ประกอบดวย การทำงานที่ Bay Computing Newsletter l 5rd Issue l 13
SOLUTION UPDATE ไดแก 1. การยอมรับความเสีย่ ง (Accept the Risk), 2. การหลีกเลีย่ งความเสีย่ ง (Avoid the Risk) 3. การโอนถายความเสีย่ ง (Transfer the Risk) และ 4. การลดความเสีย่ ง (Reduce the Risk) Standard : เปนเอกสารทีป่ ระกอบดวยกฎเกณฑ ทีใ่ ชในการควบคุมบุคคลในการพัฒนาและจัดการ วัตถุดิบ ผลผลิต บริการ เทคโนโลยี ภาระหนาที่ ขั้นตอนปฏิบัติ และระบบ
สอดคลองกันระหวาง Input และ Output โดยทัว่ ไป รูปแบบของ Procedure จะเปน Flow Diagram โดยเนือ้ หาใน Procedure อาจจะไมลงรายละเอียด มากหรือลงรายละเอียดแบบละเอียดก็ได Procedure จะแสดงให เ ห็ น ว า งานในส ว นไหนทำเสร็ จ แล ว ทำเสร็จไดอยางไร ใครเปนคนทำ และอยใู นสถานะ ไหน และยังบอกไดวาใครเปนผูมีอำนาจสั่งการ และผูที่รับผิดชอบ วัตถุดิบอะไรบางที่ตองใชและ จัดหาในการดำเนินงาน เอกสารอะไรบางที่ตอง ใชในการดำเนินงาน Process : ขัน้ ตอนในการดำเนินงานทีม่ กี ารนำ Input มาใชงาน และเปลีย่ นแปลงเปน Output Process Approach : เปนกลยุทธทางการ บริหารทีใ่ ชในการควบคุมการดำเนินการของ ISMS Record : สือ่ กลางซึง่ บันทึกเหตุการณทเี่ กิดขึน้ วาเกิดเหตุการณอะไรขึ้นบางในองคกร Requirement : ความตองการ ความคาดหวัง หรือขอผูกมัด ตามสภาพการณขององคกรหรือ บริษัทลูกคา หรือบริษัทคูคา Residual Risk : เปนความเสี่ยงที่ยังเหลืออยู หลังจากมีการทำ Risk Treatment เชน การยอมรับ ความเสีย่ ง การเลีย่ งความเสีย่ ง การถายโอนความ เสีย่ ง การทำใหความเสีย่ งนอยลง Risk : นิยามของความเสีย่ ง อันประกอบไปดวย 3 แนวคิดคือ 1. เลือกเหตุการณที่คิดวานาจะมี ผลกระทบมาประมวลผล 2. ตั้งคำถามไวสัก 2 คำถาม วาเหตุการณผดิ ปกติใดทีม่ คี วามเปนไปได 14 l Bay Computing Newsletter l 5rd Issue
ที่อาจจะเกิดขึ้นในอนาคต และผลกระทบทางลบ ทีจ่ ะเกิดขึน้ จากเหตุการณดงั กลาวเปนอยางไร ถา ผลของความเสีย่ งสูงแสดงวา ความเปนไปไดทจี่ ะ เกิดเหตุการณดงั กลาวสูง และผลกระทบทีต่ ามมา จะสูงเชนเดียวกัน และ 3. นิยามของความเสีย่ ง จะ เปนการมองถึงเหตุการณที่อาจเกิดขึ้นในอนาคต และความกังวลถึงผลกระทบทีจ่ ะเกิดขึน้ Risk Acceptance : เปนสวนประกอบในขัน้ ตอน การทำ Risk Treatment ความหมายคือ องคกร หรือบริษทั สามารถดำเนินธุรกิจตอไดแมวา จะเกิด เหตุการณซึ่งเปนเหตุการณที่ผิดปกติ Risk Analysis : เปนการนำเอาขอมูลมาใชเพือ่ บงชี้หาสาเหตุของการเกิดความเสี่ยง การโจมตี หรือเหตุการณอันตรายที่มีผลกระทบตอองคกร หรือบริษัท Risk Assessment : ประกอบดวยเทคนิค 2 อยาง คือ Risk Analysis และ Risk Evaluation Risk Evaluation : เปนการเปรียบเทียบคาความ เสีย่ งกับเกณฑความเสีย่ ง Risk Management : เปนขั้นตอนที่ประกอบ ไปดวยกิจกรรมตางๆ ทีอ่ งคกรหรือบริษทั ใชในการ จัดการและควบคุมความเสี่ยง ประกอบไปดวย 4 ขั้นตอน ไดแก 1. Risk Assessment 2. Risk Acceptance 3. Risk Treatment และ 4. Risk Communication Risk Treatment : เปนขั้นตอนในการตัดสินใจ กับความเสีย่ งขององคกรหรือบริษทั แบงเปน 4 แบบ
Statement of Applicability : เปนเอกสารที่ ประกอบไปดวยวัตปุ ระสงคและตัวควบคุมตางๆ ที่ องคกรหรือบริษทั เลือกใช กอนทีจ่ ะจัดทำ Statement of Applicability องคกรหรือบริษัทจะตองจัดทำ สวนประกอบตางๆ ดังนีก้ อ น เพือ่ จัดทำ Statement of Applicability สำหรับองคกรหรือบริษัทนั้นๆ ตามแนวทางการดำเนินธุรกิจของแตละบริษัท 1. Risk Assessment 2. Risk Treatment 3. ทำความเขาใจกฎหมายหรือขอบังคับทีเ่ กีย่ วของ 4. ศึกษารายละเอียดในสัญญาตางๆ 5. ทบทวนโครงสรางขององคกรหรือบริษัท และ แนวทางการดำเนินธุรกิจของบริษัท Third Party : บุคคลหรือบริษัทภายนอกที่ไมมี ความเกี่ยวพันกับองคกรหรือบริษัท Threat : เหตุการณทอี่ าจจะเกิดขึน้ เมือ่ เหตุการณ เกิดขึน้ เหตุการณดงั กลาวอาจจะเปนเหตุการณที่ ไมตอ งการใหเกิดขึน้ เพราะเหตุการณดงั กลาวอาจ สงผลกระทบรายแรงตอระบบหรือองคกรหรือบริษทั Vulnerability : ชองโหวทเี่ กิดขึน้ กับสินทรัพยหรือ กลมุ ของสินทรัพย และอาจถูกโจมตีการ Treat ได หลายแบบ ทุกทานคงไดทำความเขาใจกันไปแลวนะครับ ในสวนของความหมายของคำตางๆ ที่ใชใน ISO 27001:2005 มาตรฐานเกีย่ วกับระบบบริหาร ความมั่นคงปลอดภัยของสารสนเทศกันแลว นะครับ เพราะเปนสวนหนึ่งที่สำคัญในการ ใชงานตัวมาตรฐาน สำหรับในฉบับหนา เรา จะมาทำความเข า ใจในส ว นอื่ น ๆ ในตั ว มาตรฐานกันเพิม่ เติม ฉบับนีค้ งตองลากันกอน และกลับมาพบกันใหมกับ ISO 27001:2005 ในตอนที่ 4 ครับ
Bay Computing Newsletter l 5rd Issue l 15
SOLUTION UPDATE
16 l Bay Computing Newsletter l 5rd Issue