16

BayNewsletter_5

Embed Size (px)

DESCRIPTION

2 l Bay Computing Newsletter l 5 rd Issue นิดา ตั้งวงศศิริ , ผูจัดการทั่วไป Bay Computing Conference 02 EDITOR’s NOTE & QUESTIONNAIRE 03 CONTENTS & NEWS UPDATE 04 COVER STORY 08 SOLUTION UPDATE 13 SOLUTION UPDATE 02 เบย รวมงาน WUNCA ครั้งที่ 20 06 IT GREEN Bay Computing Newsletter l 5 rd Issue l 3 Business Continuity Technology ตอนที่ 2 เสริมมาตรการความปลอดภัยไอทีดวย ISO 27001:2005 ตอนที่ 3 “คำจำกั ดความ”

Citation preview

Page 1: BayNewsletter_5
Page 2: BayNewsletter_5

2 l Bay Computing Newsletter l 5rd Issue

EDITOR’S NOTE & QUESTIONAIRE

สวัสดีป 2009 สำหรับทานผูติดตาม Bay Newsletter หวังวาจะเปนปที่ทุกทานไดรับประสบการณใหมๆ ที่ดีที่ไดเพิ่มพูน ความรูความเขาใจในสิ่งที่ทานปฏิบัติและเปนประโยชนในอนาคต สำหรับปนี้เราไดปรับปรุงรูปแบบใหมีสีสันและนาอานยิ่งขึ้น โดย

ยังคงเนนเนื้อหาที่เปนประโยชนตอแนวโนมทางดานไอทีของป ทั้งนี้ เราไดแนบแบบสอบถามเกี่ยวกับการจัดทำ Newsletter มาในโอกาสนี้ดวย หวังเปนอยางยิ่งวาจะไดรับคำแนะนำจากทาน

เนือ้หา Business Continuity Management (BCM) ในภาคตอฉบบันี ้คงชวยใหทานไดประเมนิความพรอมขององคกรในการจัดเตรยีม BCM ทีต่รงตามมาตรฐาน ซึง่เทคโนโลยทีีร่องรบัการจดัเตรยีม BCMนั้นมีการจัดเตรียมไดหลายระบบ และเหมาะสมกับองคกรแตกตางกันไป หากทานตองการทราบขอมูลเพิ่มเติมสามารถติดตอทีมงานเพื่อรับคำปรึกษาไดโดยตรง

นิดา ตั้งวงศศิริ, ผูจัดการทั่วไป

Page 3: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 3

CONTENTS & NEWS UPDATE

01 13th AnniversaryBay ComputingBay 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 ดวยทีมงานที่มีประสิทธิภาพและมีความรูความชำนาญในทุกโซลูชันที่นำเสนอ

02 EDITOR’s NOTE & QUESTIONNAIRE03 CONTENTS & NEWS UPDATE04 COVER STORY

Business Continuity Technology ตอนที ่2

06 IT GREENคณุพรอมเตรยีมรบักระแส ไอทสีเีขยีว (Green IT) แลวหรอืยงั?

08 SOLUTION UPDATEแนวทางการปฏิบัติที่เหมาะสม สำหรับการจัดการขอมูล Log ตอนที่ 3 (ตอบจบ)

13 SOLUTION UPDATEเสริมมาตรการความปลอดภัยไอทีดวย ISO 27001:2005 ตอนที่ 3

“คำจำกดัความ”

04 CDIC Cyber Defense InitiativeConferenceหลายๆ ทานที่ไปรวมงาน CDIC ซึ่งเปนงานสัมมนาที่มุงเนนทางดานSecurity คงไดมีโอกาสแวะเวียนมาเยี่ยมบูธของ เบย ในวันที่ 25-26พฤศจกิายน ทีผ่านมา ซึง่เบยไดมโีอกาสรวมนำเสนอโซลชูนัตางๆ ทีต่รงกบัTrend ของเทคโนโลยใีนปจจบุนั ไมวาจะเปน User Authentication, LogManagement, IP Management หรือ Load Balance และ WebApplication สำหรบั Trend ในปนีห้ลายๆ ทานคงไดทราบถงึความสำคญัของมาตรฐานตางๆ ในโลกเทคโนโลยีที่พัฒนาอยางตอเนื่อง ซึ่งองคกรระดบัใหญหรอืหนวยงานราชการจะมงุสรางมาตรฐานแกองคกรดวยการCertified Standard ทีต่รงตอ Business Line ของตวัเอง เชน ISO 27001,COBIT หรือ PCI DSS เปนตน

ตองการทราบขอมลูหรอืสนใจตดิตอสอบถาม Consult Service เกีย่วกบัมาตรฐานตางๆ ไดที ่ทมี Professional Customer Support เบย คอมพวิติง้ไดแลววันนี้

04

03

02

01

Page 4: BayNewsletter_5

4 l Bay Computing Newsletter l 5rd Issue

โดย อวริทุธ เลีย้งศริ ิEnterprise Solution Manager, Bay Computing

COVER STORY

Business ContinuityTechnology

จากตอนทีแ่ลวเราไดกลาวถงึ Availabilityในแงมุมตางๆ ไปแลว ในตอนนี้ เราจะ

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

สาเหตขุองปญหา Downtime

ตอนที่ 2

Application Availability and Monitoring : การทำ Application Availability คือการตรวจสอบและใหบรกิาร Application อยางตอเนือ่ง ในทกุๆสถานการณ

Performance Monitoring : การทำ PerformanceMonitoring เปนการตรวจวดัประสทิธภิาพการใหบรกิารและทำงานของ Application และ System

Data Backup and Archival : การทำสำรองและสำเนาของขอมลู

Disaster Recovery : การกขูอมลูจากเหตวุบิตัภิยัData and System Rollback : การกคูนืขอมลู

และระบบกลบัคนืสภาพเดมิ

กระบวนการในการออกแบบแผนการทำ BusinessContinuityแผนการคงความตอเนื่องของธุรกิจ (BusinessContinuity Plan : BCP) จะตองประกอบไปดวยสาระสำคญัอยางนอย ดงัตอไปนี้

Business Continuity Planning (BCP) เกีย่วของกบัการ Maintain การกลบัไปดำเนนิงาน (Resuming)และการกูคืนของธุรกิจ ไมใชเพียงการกูคืนสภาพของเทคโนโลยีเทานั้นกระบวนการออกแบบแผน ตองทำในระดบัของ

ทัว่ทัง้องคกร ไมใชเพยีงหนาทีข่องเทคโนโลย ีหรอืฝายบริหารเทานั้นการทำ Business Impact Analysis และ Risk

Assessment อยางทะลปุรโุปรงเปนพืน้ฐานทีส่ำคญัของ BCP ที่ดีความมีประสิทธิภาพของ BCP จะสามารถ

ตรวจวดัไดจากการทดสอบ และฝกซอมเทานัน้

แผน BCP และผลการทดสอบ ควรเปนหนาทีข่องผูตรวจสอบอิสระ และถูกนำเสนอเพื่อตรวจทานโดยผูบริหารระดับสูงแผน BCP ควรถกูปรบัปรงุอยางสม่ำเสมอ เพือ่

สะทอนถึงและตอบสนองตอความเปลี่ยนแปลงภายในองคกร หรอืผใูหบรกิารทีใ่หบรกิารแกองคกร

ขัน้ตอนการออกแบบแผน BusinessContinuity1. Business Impact Analysis2. Risk Assessment3. Risk Management4. Other Policies, Standards and Processes5. Risk Monitoring

Business Impact Analysisขัน้ตอนการทำ Business Impact Analysis (BIA)หรือการวิเคราะหถึงผลกระทบที่เกิดขึ้นกับธุรกิจเปนขั้นตอนแรกในการออกแบบ BCP ซึ่งควรจะประกอบดวยสิง่เหลานี ้คอืการระบุถึงความเปนไปไดของผลกระทบ ใน

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

ไมเพยีงแคการประมวลผลขอมลูเทานัน้ประมาณการณถึงเวลามากที่สุด ที่ยอมใหเกิด

downtime และระดบัทีย่อมรบัไดของการสญูเสยีขอมลู การปฏบิตังิาน และความสญูเสยีทางการเงนิ

Risk AssessmentRisk Assessment หรือ การประเมินความเสี่ยงเปนขั้นตอนที่ 2 ในการสรางแผน BCP โดยควรจะ ประกอบไปดวยสิง่เหลานี ้คอืการจัดลำดับความสำคัญ (Prioritizing) ของ

ความเปนไปไดทีส่งผลตอการดำเนนิการของธรุกจิโดยเรยีงตามลำดบัความรายแรง และโอกาสทีจ่ะเกิดขึ้นไดของเหตุการณนั้นๆทำ Gap Analysis โดยเปรียบเทียบกับ BCP

ปจจุบัน และถามี ควรระบุวาสิ่งใดบางที่ตอง

จะเหน็วา สาเหตหุลกัของการเกดิ Downtime สงูสดุ3 อันดับแรก คือ ปญหาของ Software 40%, การDowntime ทีว่างแผนลวงหนา 30% และขอผดิพลาดทีเ่กดิจากคน 15%

เมื่อเราทราบถึงสาเหตุหลักๆ แลว เราจะสามารถวางแผนเพือ่ปองกนัและลดปญหาลงไดระดบัหนึง่แตปญหาทีเ่กดิจากปจจยัอืน่ๆ หลายครัง้เปนสิง่ที่ปองกนัไมไดเชนกนั ดงันัน้ การวางแผนเตรยีมพรอมจงึยงัเปนสิง่ทีจ่ำเปน โดยเมือ่เริม่วางแผนเพือ่เตรยีมBusiness Continuity จงึควรเริม่ดวยคำถามพืน้ฐานเลยคือ “อะไรคือจุดประสงคหลักของการทำBusiness Continuity” ซึ่งจะตอบถึงเทคโนโลยีที่จะใช และระดบัการลงทนุไดในทีส่ดุ โดยประเภทของการตอบโจทยนีแ้บงไดเปนหลายๆ ดาน คอื

System Availability : การทำ System Availabilityเปนการเพิ่มเสถียรภาพใหแกระบบโดยรวม แตไมไดเนนในระดบัของ Application

Data Availability : การทำ Data Availabilityเปนการเพิม่เสถยีรภาพใหกบัขอมลู โดยใหสามารถเขาถงึไดจากทกุสถานทีแ่ละทกุสถานการณ

Client <1%LAN/WANEquip <1%

Environment5%

People15%

Hardware 10% Software 40%

PlannedDowntime 30%

Page 5: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 5

COVER STORY

กำหนด Recovery Time และ Recovery PointObjective (RTO, RPO)การวิเคราะหถึงภัยคุกคาม โดยใชพื้นฐานจาก

ผลกระทบทีจ่ะเกดิกบัองคกร ลกูคา และเศรษฐกจิภายนอก ไมใชจากลกัษณะหรอืคณุสมบตัขิองภยัคุกคามนั้นๆ

Risk ManagementRisk Management เปนขั้นตอนของการพัฒนาBCP ที่เขียนขึ้น และทำในระดับทั่วองคกร ซึ่งองคกรตองทำใหแนใจวา BCP มีสิ่งตางๆ เหลานี้เขยีนขึน้ และมรีายละเอยีด เพือ่ใหบคุลากรใน

หลายๆ กลมุ สามารถนำไปปฏบิตัแิละใชงานไดในเวลาไมนานเกินไปมีการระบุอยางชัดเจนวา เหตุการณใดบางจึง

ควรรีบนำแผนนี้ไปใชและปฏิบัติมกีารระบอุยางชดัเจนวา กระบวนการทีต่องทำ

เมือ่เกดิเหตขุดัของขึน้ คอือะไรบางมีความยืดหยุนพอเพื่อจะตอบสนองตอภัย

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

กลบัมาดำเนนิการตอได ในเหตกุารณทีส่ถานทีแ่ละสิง่อำนวยความสะดวก (Facility) หรอื Functionของธุรกิจไมสามารถดำเนินตอไดมากกวามีประสิทธิภาพในการลดความไมตอเนื่องของ

การใหบรกิาร และความสญูเสยีในรปูตวัเงนิ

Other Policies, Standardsand Processesเปนการนำแผน BCP มาเปรยีบเทยีบ และคำนงึถงึผลกระทบที่อาจสงผลตอ กฎ นโยบาย และมาตรฐานที่องคกรจำเปนตองปฏิบัติตาม เชนมาตรฐาน ISO หรือ GLBA เปนตน ซึ่งประกอบไปดวย

System Development Life Cyclesนโยบายการทำ Change ControlData Synchronization Proceduresแผนการฝกอบรมบคุลากร และ แผนการสือ่สาร

ในองคกรนโยบายการรบัประกนั หรอื ทำประกนัองคกรภาครัฐ, สื่อ และนโยบายในการสื่อสาร

กบัชมุชนขององคกรSecurity

Risk Monitoringการทำ Risk Monitoring เปนกระบวนการในการ

คอยตรวจสอบประสิทธิภาพ และปรับปรุงแผนBCP โดยประกอบดวยสิ่งเหลานี้ คือทำการทดสอบแผน BCP อยางนอยปละ 1 ครั้งนำสงแผน BCP ใหกับผูตรวจสอบอิสระทำการ

Review หรือใหคำแนะนำทำการปรับปรุงแผน BCP โดยยึดถือตามการ

เปลีย่นแปลงทีเ่กดิขึน้กบับคุลากร และสภาพแวดลอมทัง้ภายในและภายนอก

เทคโนโลยทีีน่ยิมใชในการทำBusiness Continuityเราจะมาดูในรายละเอียดของการเลือกใชเทคโนโลยีเพื่อความเหมาะสม โดยสามารถสรุปอยางงายๆ ดงัตารางตอไปนี้

อยางแนนอน ไมเกดิเหตกุารณที่หา Tape ไมพบ หรือ Tapeวางเปลา อกีตอไป

เทคโนโลยีที่ เปนที่ นิ ยมในปจจุบัน ทั้งสภาพแวดลอมที่ใช ระบบปฏิบัติการ Windowsและระบบปฏบิตักิาร Unix/Linuxคือการทำ Cluster ซึ่งเปนเทคโนโลยีที่มีความเหมาะสมกับการทำงานที่ตองการความ

จากแผนภาพดานบน พอจะสรปุไดวา เทคโนโลยีหลกัๆ ทีน่ยิมใชกนัในปจจบุนัประกอบไปดวย

BackupReplication-FailoverClusteringContinuous Availability

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

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

ภาพแสดงปญหาของการใชงาน Microsoft Clusterโดยทั่วไป

ตอเนื่องในระดับหนึ่ง เนื่องจากระหวางการFailover จาก Node หนึ่งไปยังอีก Node หนึ่งจะเกดิความขาดชวงกนั โดยเฉพาะความตอเนือ่งในระดับ Session และ Transaction ของApplication ที่ทำงานอยูบน Cluster ตัวอยางเชนระบบปฏิบัติการ Microsoft Windows Clusterมขีอเสยีทีพ่อจะสรปุเปนแผนภาพทางดานบน

โดยจะเหน็วาขอเสยีหลกัของ Microsoft WindowsCluster คอื จำเปนตองใช Application Licenseถงึ 2 ชดุ และมคีวามไมตอเนือ่งของ Session และTransaction ในหนวยความจำระหวาง Nodeเมือ่เกดิเหตกุารณ failover ขึน้ และความเสีย่งทีเ่กดิจากการใช Disk ที่แชรภายนอกทำใหตองเพิ่มตนทนุและเปนจดุทีเ่สีย่งตอการเปนตนเหตใุหเกดิขอผดิพลาดได (Single Point of Failure)

ในตอนตอไป เราจะมาลงรายละเอยีดในสวนของแนวโนมเทคโนโลยีของการทำ BusinessContinuity อืน่ๆ และการประยกุตใชเพือ่ใหเกดิประโยชนสูงสุดสำหรับแตละ Application

Page 6: BayNewsletter_5

6 l Bay Computing Newsletter l 5rd Issue

IT GREEN

โดย เทรนด ไมโคร

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

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

คณุพรอมเตรยีมรบักระแสไอทสีเีขยีว (Green IT) แลวหรอืยงั?

Page 7: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 7

IT GREEN

เรามาลองดกูนัวาเราจะชวยลดภาระขององคกร และลดมลภาวะทีเ่กดิขึน้จากอตุสาหกรรมไอทใีนองคกรของเราไดอยางไรบางในปจจุบันมีการนำเสนอแนวทางหลายทางที่สามารถนำมาประยุกตใช ไมวาจะเปนในแงของการใชผลิตภัณฑไอทีที่ไดรับเครื่องหมาย Energy Star หรือเลือกใชผลิตภัณฑที่ทำจากวัสดุ Recycle (ทั้งหีบหอและตัวผลิตภัณฑ) แตในวันนี้ผเูขยีนจะขอนำเสนออกีเทคโนโลยหีนึง่ทีเ่รยีกวา Consolidationand 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 เซริฟเวอรกท็ำงานแคเพยีงหนาทีเ่ดยีว โดยมเีหตผุลวาการใหเซิรฟเวอรทำงานมากกวาหนึ่งงานขึ้นไป อาจทำใหประสทิธภิาพของการทำงานลดลงและเสีย่งตอการเกดิ singlepoint of failure อกีดวย แตปญหาทีส่ำคญัทีไ่มมกีารแนะนำใหตดิตัง้ซอฟตแวรหลาย ๆตวัลงบนเซริฟเวอรตวัเดยีวกค็อื ปญหาดานการจดัการทรพัยากรระบบ (Resource Management)ซึง่ปญหาดงักลาวเกดิขึน้จากตวัระบบปฏบิตักิารนัน่เอง จงึมีการนำเทคโนโลย ีVirtualization มาแกปญหาดงักลาว โดยที่

ตัว Virtualization Software จะเขามาทำหนาที่บริหารทรพัยากรระบบแทน จงึทำใหเซริฟเวอรสามารถทำงานตางๆไดมากขึน้ โดยสามารถทำใหใชทรพัยากรทีม่อียไูดเพิม่ขึน้ถงึ80 เปอรเซ็นต และลดความตองการดานตัวอุปกรณไดถึงอตัราสวน 10:1 เลยทเีดยีว

CPU Memory NIC Disk

จาก 2 แนวคดิขางตน ทำใหเกดิแนวขึน้ทีจ่ะลดขนาดเซริฟเวอรที่ใชในองคกรดวยการทำ server consolidation andvirtualization เกิดขึ้น โดยการรวมเซิรฟเวอรจำนวนมากที่มีอยลูงสรูะบบ Blade Server และใช Virtualization ในการเพิม่ประสทิธผิลในการทำงานใหมากทีส่ดุ (Maximum Utilization)แนวความคดินีเ้ริม่มกีารพดูถงึกนัมากขึน้อยางแพรหลาย แตยงัตดิปญหาในสวนของการลงทนุตัง้ตน (Initial Cost) ซึง่เปนจำนวนเงินที่สูงมาก แตถาเทียบกับผลลัพธที่ไดในระยะยาวไมวาจะเปนเรือ่งของการลดความรอน ปรมิาณการใชกระแสไฟฟา รวมถึงการดูแลรักษา และขยะที่จะเกิดขึ้นในอนาคต(เมือ่คณุหนัมาใช blade server กจ็ะเหลอืขยะเพยีงชิน้เดยีวในอีก 5 ปขางหนา) และขณะนี้ แนวคิดนี้ก็ไดถูกนำไปพิจารณาในหลายๆ องคกรเพื่อที่จะนำมาใชกับองคกร เพื่อลดจำนวนเซริฟเวอรทีใ่ชอยเูปนจำนวนมากอกีดวย

สนใจรับเอกสารเกี่ยวกับประโยชนในการใช Virtualization เพิ่มเติม หรือ ขอรับ Software Trailเพือ่ทดลองใช กรณุาตดิตอคณุมทนิา สหวฒัน / Product Marketing ManagerBay Computing Co., Ltd.โทร. 0-2962-2223 ตอ 612หรอื อเีมล : [email protected]เพื่อแจงความประสงคในการรับ

InterScan Web Security Virtual Appliance (IWSVA) หรือInterScan Mail Security Virtual Appliance (IMSVA) หรือทั้ง IWSVA กับ IMSVA

Page 8: BayNewsletter_5

8 l Bay Computing Newsletter l 5rd Issue

ในฉบบัทีแ่ลว เราไดทราบถงึ “ความตองการทัว่ไป”ซึง่เปนปจจยัแรก จากทัง้หมด 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 จากระบบและอปุกรณจำนวนมากทัว่ทัง้องคกรมรีปูแบบฟอรแมตที่ไมเหมือนกัน และมักไมถูกตองตรงกับรูปแบบโครงสรางของ RDBS

ตวัอยางเชน ไฟรวอลลทีถ่กูอพัเกรด อาจมฟีอรแมตของขอความLog ของไฟรวอลลเปลีย่นไป ทำใหระบบ RDBS ทีเ่คยออกแบบไวในแพลตฟอรม SIEM จดัการกบัฟอรแมตแบบใหมไดยาก และอาจเกดิความสบัสนหรอืตกหลนบางขอมลูได และหากขอความLog แบบใหมมขีอมลูแตกตางจากเวอรชนักอนหนา กเ็ทากบัวาขอมูลที่ถูกรวบรวมมานั้น แทนที่จะถูกเขียนลงในคอลัมน Aเหมอืนเวอรชนักอนหนา กอ็าจถกูนำไปเขยีนลงในคอลมัน B ไดเปนตน นอกจากนีห้ากขอความ Log แบบใหมมขีอมลูเพิม่ขึน้จากทีเ่คยมใีนเวอรชนักอนหนา กจ็ะทำใหคอลมันไมสอดคลองกนัและขอมลูอาจจะถกูตดัทิง้ไปดวย

SOLUTION UPDATE

แนวทางการปฏบิตัทิีเ่หมาะสมสำหรบัการจดัการขอมลู Log“Infrastructure Requirements”โดย ภรูทิตั ทองปรชีา

ตอนที่ 3

Page 9: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 9

อกีปจจยัทีค่วรระลกึถงึในการเกบ็รวบรวมขอมลูใหถกูตองคอืวธิทีีเ่ทคโนโลย ีSIEM ใชจดัการกบั การพชุ (pushing) ของขอความจากอุปกรณตางประเภท โดยอุปกรณที่เปนยูนิกซจำนวนมากจะใชโพรโตคอล UDP (User Datagram Protocol)เพือ่สงขอความทีร่วมถงึขอมลู Log ดวย โดยเทคโนโลย ีUDPpush ผสูงจะไมตรวจสอบวาขอความสงถงึปลายทางหรอืไมจงึไมมกีารแจงกลบัหากสงไมได ดวยเหตนุี ้เทคโนโลย ีSIEMตองรวบรวมใหถูกตองและจับทุกขอความ UDP แมแตชวงที่มปีรมิาณการสงสงูสดุ ไมอยางนัน้ขอความดงักลาวจะหายไปแบบถาวร

III. การเกบ็ขอมลู Log และอปุกรณจดัเกบ็ (Log retention andstorage)1. สนับสนุนกลยุทธ ILM (InformationLifecycle 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 นั้น จะขึ้นอยูกับนโยบายของแตละองคกรที่จะแตกตางกันออกไป อยางไรก็ตาม คำแนะนำตาม RSARecommended Best Practices ไดระบเุอาไววา ระยะเวลาในการเกบ็สำรองขอมลูทีเ่หมาะสมสำหรบั Production Dataกค็อื ไมควรนอยกวา 1 ปบวกกบัอกี 1 ไตรมาส หรอืเทากบั15 เดอืนนัน่เอง ซึง่ระยะเวลาในการออนไลนเอาไว 15 เดอืนนี้จะชวยทำใหแนใจไดวา การใชประโยชนจากขอมูลจะยังคงสมบรูณและสามารถเขาถงึไดอยตูลอดรอบการตรวจสอบ(Audit Cycle) ทั้งจากภายในและภายนอกองคกร

RSA Recommended Best Practices ไดแนะนำเอาไวดวยวา สำหรับ Back-up Data นั้นควรจะเก็บอยูใน Near-lineStorage ในระยะเวลาเทาๆ กบั Production Data ทัง้นีเ้พือ่ใหแนใจวา Back-up Data จะสามารถพรอมใชงานไดทันทีหาก Production Data เกิดความเสียหายหรือไมสามารถใชงานได ซึง่จดุประสงคเดยีวของการแบก็อพัขอมลู Log คอืตองสามารถกคูนืขอมลูไดเมือ่ตองการ

2. ใชกลยทุธการบรหิารจดัการตามชวงอายุตัง้แตเกดิจนตาย กบัขอมลู Logโครงสรางพื้นฐานควรจะสนับสนุนการบริหารจัดการขอมูลLog ตลอดชวงอายุการใชงาน นั่นหมายถึง มีการบังคับใชนโยบายการเกบ็ขอมลูขององคกรอยางอตัโนมตั ิตวัอยางเชนมนัควรงายในการกำหนดใหแพลตฟอรม SIEM สามารถเกบ็ขอมลู Log แตละประเภทเอาไวโดยมรีะยะเวลาในการเกบ็ที่แตกตางกนัออกไป รวมทัง้การอนญุาตใหเลอืกจดัเกบ็ขอมลูLog จากแอพพลิเคชันที่แตกตางกันในชวงเวลาตางกันไดแพลตฟอรมดงักลาวควรยอมใหผดูแูลระบบสามารถโยกยายLog จากสตอเรจระดบัหนึง่ไปยงัสตอเรจอกีระดบัหนึง่ได เชนยายจากสตอเรจแบบ On-line ไปสตอเรจแบบ Near-line และสามารถลบขอมูล Log ที่ตรงกับเงื่อนไขได สวนการขยาย

SOLUTION UPDATE

Page 10: BayNewsletter_5

10 l Bay Computing Newsletter l 5rd Issue

ระยะเวลาการจดัเกบ็จากเดอืนเปนปตองมกีารจดัการทีง่ายไมยงุยาก

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) ทำใหระบบไมสามารถเขาถงึองคประกอบตางๆ ของขอมลูได

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

SOLUTION UPDATE

4. มรีะบบจดัการทีด่เีมือ่เลกิใชขอมลูแลวเมือ่ขอมลู Log ไมมคีวามจำเปนตองใชอกีตอไป แพลตฟอรมที่ดีควรมีระบบที่งายและเชื่อถือไดในการจัดการกับขอมูลดงักลาว องคกรควรสามารถตัง้คำสัง่ยายขอมลู Log ทัง้หมดที่เขามากอนหนาวันและเวลาที่กำหนดไปไวที่อื่น แตการลบขอมูลแบบถาวรเปนการลบทีไ่มเหมาะสม เพราะไฟลทีถ่กูลบอาจจำเปนตองถูกกูคืนหรือสรางใหมเพื่อใชงานในกรณีที่มีการฟองรอง

IV. การวเิคราะห Log(Log Analysis)1. มองเห็นภาพรวมของทั้งองคกรโครงสรางพื้นฐานของระบบควรมีอินเทอรเฟซแบบกราฟก(Graphical User Interface : GUI) ทีช่วยใหสามารถตรวจสอบและวิเคราะหขอมูล Log ทั้งหมดที่รวบรวมมาจากระบบอุปกรณ และแอพพลิเคชันตางๆ ที่กระจายอยูทั่วเครือขายขององคกรได ดวยการมองเหน็ภาพรวมของขอมลู Log นีจ้ะทำใหองคกรเห็นภาพสถานะดานความปลอดภัยเกี่ยวกับทาทแีละการรวมมอืขององคกรได นอกจากนีเ้หตกุารณตางๆที่เกิดขึ้นทั้งในอดีตและที่กำลังเกิดขึ้นในปจจุบันก็ควรถูกนำมาแสดงดวย

2. ตรวจจับเหตุการณผิดปกติแบบอาศัยความสมัพนัธทีข่อมลูมตีอกนัองคกรตองมีความพรอมในการระบุถึงเหตุการณตางๆ ที่มีความสำคญัได เชน เหตกุารณทีเ่กดิขณะนัน้ หรอืปญหาในการดำเนินการดานตางๆ ที่จำเปนตองมีการตอบสนองหรือแกไขในลกัษณะใดลกัษณะหนึง่ เปนตน การตรวจสอบแตละLog ทีเ่ขามาอยางอสิระตอกนัเปนเรือ่งทีย่งุยาก สญูเปลา และทำใหระบบที่ใชอยูแทบไมมีประโยชนอันใดเลย เพราะการโจมตีมักจะเกี่ยวของกับทรัพยสินหลายๆ ชิ้นหรือหลายๆเหตุการณ ถาคุณเพียงเฝาดูแตละอุปกรณหรือวิเคราะหเหตุการณที่เกิดขึ้นแยกกัน กิจกรรมเดี่ยวๆ ที่เกิดขึ้นอาจดูเหมือนไมไดเปนภัยคุกคามทั้งที่กิจกรรมนั้นเปนภัยคุกคามนัน่เพราะกจิกรรมนัน้สมัพนัธกบักจิกรรมอืน่ๆ ทีก่ำลงัเกดิขึน้

Page 11: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 11

ในเวลาเดียวกัน สำหรับปญหาอื่นๆ จะเกี่ยวกับการที่มีเหตุการณจำนวนมากถูกตรวจพบจากหลากหลายอุปกรณเพราะเปนการยากที่จะแยกแยะเหตุการณที่สำคัญออกจากเหตุการณปกตินั่นเอง

ดงันัน้ เพือ่แยกแยะเหตกุารณทีไ่มเกีย่วของออกไปและสามารถระบเุหตกุารณทีม่คีวามสำคญัจรงิๆ ได โครงสรางพืน้ฐานของLog Management จะตองมคีวามสามารถในการดำเนนิการเกีย่วกบัความสมัพนัธของเหตกุารณ (Event Correlation) ไดไมวาจะเปนการคนหารปูแบบของเหตกุารณ หรอืการมองหาความสัมพันธระหวางขอมูล Log ที่เขามาตั้งแต 2 รายการขึน้ไป ซึง่โครงสรางดงักลาวจะเปนประโยชนอยางยิง่ในการชวยลดความผดิพลาดในลกัษณะ false positive (ความผดิพลาดทีร่ะบบพจิารณาใหเปนเหตกุารณทีส่ำคญัทัง้ทีใ่นความเปนจรงิไมใช) ลงได

ปกตคิวามสมัพนัธของเหตกุารณสวนใหญจะเปนความสมัพนัธตามกฎที่ Log ตางๆ ที่ไดจากแหลงเดียวหรือหลายแหลงสมัพนัธกบัคณุคาของ Log เชน เวลาบนัทกึ (time stamp),หมายเลขไอพีแอดเดรส และประเภทของเหตุการณ ความสัมพันธของเหตุการณสามารถแสดงในลักษณะอื่นไดดวยเชน การใชวิธีการทางสถิติหรือเครื่องมือที่ชวยใหมองเห็น(virtualization tools)

3. สรางระบบการเตอืนภยัทีค่รอบคลมุทกุประเภทของการโจมตแีละการฝาฝนระบบเตือนภัยควรถูกสรางขึ้นเพื่อชี้วาเหตุการณใดหรือชุดของเหตกุารณใดจำเปนตองไดรบัการตรวจสอบ และตองไมใชแคเพียงแจงเตือนเมื่อเกิดการโจมตีที่เห็นแจมแจง แตตองแจงเตือนเหตุลักลอบตางๆ ที่เกิดขึ้นบนเครือขายไดทุกที่ทุกเวลา ซึง่สวนใหญผโูจมตทีีช่่ำชองจะไมแฮกเขาไปในเครอืขายขององคกรทัง้หมดในครัง้เดยีว แตจะโจมตอียางชาๆ ทีเ่รยีกวา“Low and Slow attack” โดยการทดลองเจาะพอรตทีไ่มคอยไดใช แลวเวนชวงเปนวันหรือสัปดาหแลวคอยทดลองเจาะใหม จนกระทั่งหาชองโหวพบ

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

4. จดัเตรยีมระบบพืน้ฐานอตัโนมตัิแพลตฟอรมที่ดีควรจะมีความสามารถในการเรียนรูลักษณะการดำเนินการตามปกติขององคกรได และยกระดับการเตือนภัยไดหากคาตัวแปรปกติถูกฝาฝน คุณสมบัติดังกลาวถอืวามปีระโยชนอยางมากในการปองการโจมตแีบบ Zero-dayAttack ซึ่งเปนการโจมตีที่ยังไมมีใครทราบแนวทางในการตรวจจับและแกปญหาที่ถูกวิธี

5. จดัเตรยีมรายงานใหอตัโนมตัแิละปรบัเปลีย่นไดการรายงานเปนการสรุปกิจกรรมสำคัญๆ ที่เกิดในชวงเวลาตางๆ ซึ่งจะมีการบันทึกขอมูลที่มีรายละเอียดเกี่ยวกับเหตกุารณทีผ่ดิปกตสิำหรบัการวเิคราะห (forensic analysis)หรือการประเมินในเชิงที่เปนหลักฐานในการดำเนินการทางกฎหมายได และแนนอนวาแพลตฟอรมที่ดีควรจะสามารถรับมือกับความตองการการใชประโยชนจากรายงานทั้งในระยะสัน้และระยะยาวไดดพีอๆ กนัดวย

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

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

SOLUTION UPDATE

Page 12: BayNewsletter_5

12 l Bay Computing Newsletter l 5rd Issue

ปจจัยสำคัญอีกประการหนึ่งที่จะสงผลกระทบตอการบริหารจดัการกบัเหตกุารณทีเ่กดิขึน้คอื การมรีะบบ Vulnerability andAsset 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)

และยังคงความถูกตองของขอมูลไดตลอดวัฏจักร ตั้งแตถูกสรางขึน้จนกระทัง่ถงึเวลาทีเ่ลกิใช

โดยทัว่ไปแลว ขอมลู Log จะตองมคีวามสมบรูณ (integrity)และจะตองมคีวามนาเชือ่ถอืพอ เพือ่ใหแนใจวาองคกรสามารถมองเหน็ภาพของกจิกรรมตางๆ ทีเ่กีย่วของกบัสภาพแวดลอมดานไอทไีดอยางถกูตองชดัเจน เพือ่ใหสามารถตรวจสอบและประเมินพฤติกรรมของพนักงานไดอยางถูกตองและตรงกับความเปนจรงิไดนัน่เอง หาไมแลวขอมลูนัน้กจ็ะไมมคีาอนัใดเลย

2. ควบคุมการเขาถึงขอมูลโครงสรางพืน้ฐานทีด่คีวรมรีะบบการกำหนดสทิธ ิ(AuthorizedAssignment) ที่มีประสิทธิภาพ เพื่อปองกันมิใหผูใชงานสามารถเขาถงึขอมลูทีพ่วกเขาไมมสีทิธจิะเขาถงึไดดวย เรือ่งดงักลาวถอืเปนเรือ่งสำคญัสงูสดุอกีประการหนึง่สำหรบั LogManagement ดวยเหมอืนกนั

3. ดแูลรกัษาระบบอยางตอเนือ่งแพลตฟอรมสำหรบั Log Management ทีด่คีวรจจะสามารถทำใหแนใจไดวา จะไมมีการสะดุดในภารกิจการเก็บขอมูลLog ซึง่ในเรือ่งนี ้องคกรควรจะมกีารดแูลรกัษาและอพัเกรดระบบอยางสม่ำเสมอ เพือ่ใหระบบทีอ่อกแบบมาอยางดแีลวสามารถทำงานไดอยางตอเนื่องตลอดไปนั่นเอง

บทสรุปในสภาพแวดลอมทีเ่ตม็ไปดวยภยัคกุคามทัง้จากภายในและภายนอกองคกร อีกทั้งเต็มไปดวยขอกำหนดตางๆ ที่จะตองปฏิบัติตามกฎหมายอยางเชนทุกวันนี้ ความจำเปนในการพัฒนาแนวทางปฏิบัติที่เหมาะสม (Best Practice) สำหรับLog Management นัน้ กจ็ะยงัคงเปนหวัขอทีม่คีวามสำคญัมากขึ้นเรื่อยๆ ตอไป และในการจัดเตรียมความตองการสำหรับโครงสรางพื้นฐานที่มีประสิทธิภาพนั้น บทความชิ้นนี้นาจะชวยใหองคกรตางๆ สามารถตระหนกัและเหน็ถงึความสำคัญในการปฏิบัติตามขั้นตอนที่ถูกตองได และจะตองสามารถสรางกลยทุธดานเทคโนโลยทีีจ่ะเปนการวางรากฐานที่ดีแกการบริหารจัดการความเสี่ยงจากเหตุการณไมคาดฝนและภัยคุกคามที่จะเกิดขึ้นในอนาคตไดดวย

เบย คอมพวิติง้ ผเูชีย่วชาญใน Solution Log Managementเรายึดหลักแนวทางปฏิบัติที่เหมาะสม เพื่อใหเกิดประโยชนสงูสดุจากการจดัเกบ็ขอมลูอยางเตม็ที ่(Best Practice) ขอมลูจราจรทางคอมพวิเตอรทีท่านมอียอูาจเพิม่มูลคามหาศาลใหแกองคกรของทาน สามารถชวยองคกรลดตนทุน หากจัดเก็บอยางมีประสิทธิภาพและมีการนำไปวิเคราะหใหเกิดประโยชน สนใจปรึกษาทีมงานเพื่อสอบถามขอมูลเกี่ยวกับBest Practice ไดที ่หมายเลข 0-2962-2223

SOLUTION UPDATE

Page 13: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 13

SOLUTION UPDATE

เสริมมาตรการความปลอดภัยไอทีดวยISO 27001:2005“คำจำกดัความ”โดย ภคัณฏัฐ โพธิท์องบวรภคั, 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 ขององคกร และแกไขปรงัปรงุในจดุทีเ่กดิปญหา

ตอนที่ 3

Owner : คอื บคุคลหรอืคณะบคุคลทีอ่งคกรหรอืบรษิทัแตงตัง้ใหมหีนาทีค่วามรบัผดิชอบตอสนิทรพัยหรือกลุมของสินทรัพย แตไมไดรวมถึงการเปนเจาของในทางกฎหมาย Asset Owner มีหนาที่รับผิดชอบตอความปลอดภัยของสินทรัพยและดแูลใหสนิทรพัยสามารถใชในการดำเนนิธรุกจิขององคกรหรือบริษัท

PDCA Model : ยอมาจาก Plan-Do-Check-Act ใน ISO 27001 วาไววา ในทกุๆ การดำเนนิการของ ISMS ใช PDCA Model เปนตัวจัดการประกอบดวย Plan (การวางแผนในการจัดทำISMS), Do (การดำเนนิการจดัทำ ปฏบิตั ิและดแูลISMS), Check (การเฝาดูแล ตรวจสอบ และพจิารณา ISMS) และ Act (การปรบัปรงุ ISMS)

Policy : นโยบายที่ประกาศจากผูบริหารขององคกรหรือบริษัท เพื่อใหพนักงานรับทราบและปฏิบัติไปในทิศทางเดียวกัน

Preventive Actions : เปนขั้นตอนการปองกันหลกีเลีย่ง และดำเนนิการกบัปญหาหรอืเหตกุารณที่อาจจะเกิดขึ้น กอนที่ปญหาจะเกิดขึ้นกับองคกรหรือบริษัท

Procedure : ตวัควบคมุขัน้ตอนการดำเนนิงานหรือการปฏิบัติงาน ประกอบดวย การทำงานที่

Page 14: BayNewsletter_5

14 l Bay Computing Newsletter l 5rd Issue

สอดคลองกนัระหวาง Input และ Output โดยทัว่ไปรูปแบบของ Procedure จะเปน Flow Diagramโดยเนือ้หาใน Procedure อาจจะไมลงรายละเอยีดมากหรอืลงรายละเอยีดแบบละเอยีดกไ็ด Procedureจะแสดงใหเห็นวางานในสวนไหนทำเสร็จแลวทำเสรจ็ไดอยางไร ใครเปนคนทำ และอยใูนสถานะไหน และยังบอกไดวาใครเปนผูมีอำนาจสั่งการและผูที่รับผิดชอบ วัตถุดิบอะไรบางที่ตองใชและจัดหาในการดำเนินงาน เอกสารอะไรบางที่ตองใชในการดำเนินงาน

Process : ขัน้ตอนในการดำเนนิงานทีม่กีารนำInput มาใชงาน และเปลีย่นแปลงเปน Output

Process Approach : เปนกลยุทธทางการบรหิารทีใ่ชในการควบคมุการดำเนนิการของ ISMS

Record : สือ่กลางซึง่บนัทกึเหตกุารณทีเ่กดิขึน้วาเกิดเหตุการณอะไรขึ้นบางในองคกร

Requirement : ความตองการ ความคาดหวงัหรือขอผูกมัด ตามสภาพการณขององคกรหรือบริษัทลูกคา หรือบริษัทคูคา

Residual Risk : เปนความเสี่ยงที่ยังเหลืออยูหลงัจากมกีารทำ Risk Treatment เชน การยอมรบัความเสีย่ง การเลีย่งความเสีย่ง การถายโอนความเสีย่ง การทำใหความเสีย่งนอยลง

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

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

Risk Acceptance : เปนสวนประกอบในขัน้ตอนการทำ Risk Treatment ความหมายคือ องคกรหรอืบรษิทัสามารถดำเนนิธรุกจิตอไดแมวาจะเกดิเหตุการณซึ่งเปนเหตุการณที่ผิดปกติ

Risk Analysis : เปนการนำเอาขอมลูมาใชเพือ่บงชี้หาสาเหตุของการเกิดความเสี่ยง การโจมตีหรือเหตุการณอันตรายที่มีผลกระทบตอองคกรหรือบริษัท

Risk Assessment : ประกอบดวยเทคนคิ 2 อยางคือ Risk Analysis และ Risk Evaluation

Risk Evaluation : เปนการเปรยีบเทยีบคาความเสีย่งกบัเกณฑความเสีย่ง

Risk Management : เปนขั้นตอนที่ประกอบไปดวยกจิกรรมตางๆ ทีอ่งคกรหรอืบรษิทัใชในการจัดการและควบคุมความเสี่ยง ประกอบไปดวย4 ขั้นตอน ไดแก 1. Risk Assessment 2. RiskAcceptance 3. Risk Treatment และ 4. RiskCommunication

Risk Treatment : เปนขั้นตอนในการตัดสินใจกบัความเสีย่งขององคกรหรอืบรษิทั แบงเปน 4 แบบ

ไดแก 1. การยอมรบัความเสีย่ง (Accept the Risk),2. การหลกีเลีย่งความเสีย่ง (Avoid the Risk) 3.การโอนถายความเสีย่ง (Transfer the Risk) และ4. การลดความเสีย่ง (Reduce the Risk)

Standard : เปนเอกสารทีป่ระกอบดวยกฎเกณฑทีใ่ชในการควบคมุบคุคลในการพฒันาและจดัการวัตถุดิบ ผลผลิต บริการ เทคโนโลยี ภาระหนาที่ขั้นตอนปฏิบัติ และระบบ

Statement of Applicability : เปนเอกสารที่ประกอบไปดวยวตัปุระสงคและตวัควบคมุตางๆ ที่องคกรหรอืบรษิทัเลอืกใช กอนทีจ่ะจดัทำ Statementof Applicability องคกรหรือบริษัทจะตองจัดทำสวนประกอบตางๆ ดงันีก้อน เพือ่จดัทำ Statementof Applicability สำหรับองคกรหรือบริษัทนั้นๆตามแนวทางการดำเนินธุรกิจของแตละบริษัท

1. Risk Assessment2. Risk Treatment3. ทำความเขาใจกฎหมายหรอืขอบงัคบัทีเ่กีย่วของ4. ศึกษารายละเอียดในสัญญาตางๆ5. ทบทวนโครงสรางขององคกรหรือบริษัท และแนวทางการดำเนินธุรกิจของบริษัท

Third Party : บุคคลหรือบริษัทภายนอกที่ไมมีความเกี่ยวพันกับองคกรหรือบริษัท

Threat : เหตกุารณทีอ่าจจะเกดิขึน้ เมือ่เหตกุารณเกดิขึน้ เหตกุารณดงักลาวอาจจะเปนเหตกุารณที่ไมตองการใหเกดิขึน้ เพราะเหตกุารณดงักลาวอาจสงผลกระทบรายแรงตอระบบหรอืองคกรหรอืบรษิทั

Vulnerability : ชองโหวทีเ่กดิขึน้กบัสนิทรพัยหรอืกลมุของสนิทรพัย และอาจถกูโจมตกีาร Treat ไดหลายแบบ

ทกุทานคงไดทำความเขาใจกนัไปแลวนะครบัในสวนของความหมายของคำตางๆ ที่ใชในISO 27001:2005 มาตรฐานเกีย่วกบัระบบบรหิารความมั่นคงปลอดภัยของสารสนเทศกันแลวนะครับ เพราะเปนสวนหนึ่งที่สำคัญในการใชงานตัวมาตรฐาน สำหรับในฉบับหนา เราจะมาทำความเขาใจในสวนอื่นๆ ในตัวมาตรฐานกนัเพิม่เตมิ ฉบบันีค้งตองลากนักอนและกลับมาพบกันใหมกับ ISO 27001:2005ในตอนที่ 4 ครับ

SOLUTION UPDATE

Page 15: BayNewsletter_5

Bay Computing Newsletter l 5rd Issue l 15

Page 16: BayNewsletter_5

16 l Bay Computing Newsletter l 5rd Issue

SOLUTION UPDATE