ในระดับ Application Layer เราควรมองพฤติกรรมเป็นสองฝั่งคือ
* ฝั่งของผู้ให้บริการ เช่น จัดตั้งเป็น Web Server ที่มีชื่อ world wide web (www.) , Mail Server ที่ผ่าน Protocol SMTP และอื่นๆ นั้นสามารถถูกเรียกใช้จากภายนอกได้อยู่เสมอ ซึ่งเป็นข้อมูลสาธารณะ
** ฝั่งของผู้ใช้บริการ คือเราๆท่านๆ ที่ทำการเรียกใช้ เช่น การค้นหาข้อมูล การดูหนัง ฟังเพลง ในฝั่งของผู้ใช้บริการหากพิจารณาให้ดี ก็จะแบ่งได้อีก คือ ผู้ใช้บริการนั้น ใช้อินเตอร์เน็ตติดต่อที่ใด ?
หากเป็นสถานที่เชื่อมต่ออินเตอร์เน็ต ที่อยู่ใน LAN ผู้ใช้บริการจะมี IP Address เป็น Private IP (10.x.x.x, 172.16.x.x. , 192.168.x.x สุดแล้วจะตั้งค่า subnet ให้เป็น class A,Bหรือ C ซึ่งเป็น IP v4 ที่สงวนไว้สำหรับใช้ใน LAN)
หากเป็นสถานที่เชื่อมต่ออินเตอร์เน็ต ที่ติดต่อตรง (ซึ่งน้อยมาก) ผู้ใช้บริการจะมี IP Address เป็น Public IP
ในการสืบสวนสอบสวนหาผู้กระทำความผิด สำหรับผู้ใช้บริการแล้วหากสามารถหา IP Public มักจะหาผู้กระทำผิดได้ไม่ยาก แต่ในทางตรงข้าม IP private ที่เกิดจากผู้ใช้งานในเครือข่าย (Network) องค์กรก็สามารถหาได้เช่นกันหากองค์กรนั้นได้มีการจัดเก็บข้อมูลจราจรตาม พระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ ซึ่งได้บังคับให้ทุกที่ได้มีการจัดเก็บ Log ขึ้นเพื่อประโยชน์ในการสืบหาผู้กระทำความผิดนั้นเอง
ฝั่งของผู้ให้บริการ ผมขอแยกเป็น Application protocol ที่จำเป็นและสำคัญที่ทุกเครือข่ายเปิดใช้จะกล่าวถึงเฉพาะ Application Protocol ที่สำคัญอยู่ 3 ชนิดได้แก่ Web , DNS และ Mail เรามาดูตัวแรกกัน
1. Web (HTTP) ภัยคุกคามที่มากับ Protocol นี้นับว่าเป็นการรับมือการโจมตีชนิดต่างๆได้ยาก เนื่องจากการเปิด Web Server ขึ้นมานั้นประกอบด้วยทางเข้าถึงระบบมีหลากหลายหนทาง ไม่ว่าเป็นช่องโหว่ (Bug) ต่างๆ ที่เกิดขึ้นได้แก่
- ช่องโหว่ที่เกิดขึ้นจาก OS (Operating System) การโจมตีก็มี ทั้งแบบ Remote และ Access โดยตรงกับเครื่องที่ให้บริการ ไม่ว่าเป็นการโจมตีแบบ Remote Exploit ผ่านเครือข่ายเพื่อเข้าถึง OS หรือการ Access โดยตรงเพื่อทำให้เกิด Buffer overflow เป็นต้น
- ช่องโหว่ที่เกิดจาก Web Server เอง เช่น IIS 6 , IIS 7 , Apache อื่นๆ มีทั้งแบบ Remote และ Access โดยตรงกับเครื่องที่ให้บริการ ไม่ว่าเป็นการโจมตีแบบ Remote Exploit และการ Access โดยตรงเพื่อทำให้เกิด Buffer overflow
- ช่องโหว่ที่เกิดจากโปรแกรม ไม่ว่าเป็นการให้บริการของ Web Application ที่ใช้โปรแกรมในการเขียน เช่น Java , CGI , Perl ,PHP อื่นๆ อีกมากมาย ยิ่งถ้าเป็น Web 2.0 แล้วการเปิด Web Application มากขึ้นก็ทำให้การเข้าถึงระบบ มีช่องทางเข้าถึงระบบ ตามช่องโหว่าที่พบ OS , Application ยิ่งถ้าใน Web Application นั้นมี Data Base (SQL Server, Mysql เป็นต้น) ในเครื่องเดียวก็ยิ่งมีความเสี่ยงมากขึ้นเป็นเงาตามตัว
เพียงช่องทางเดียวคือ Port 80 ที่เปิดให้บริการ
สิ่งที่เราควรตรวจสอบ Web Application มีดังนี้
1.1 ตรวจหา Web Application Fingerprint : เพื่อให้รู้ถึงเวอร์ชั่นและชนิดของ web server ที่ใช้เพื่อให้ผู้ทดสอบสามารถรู้ถึงช่องโหว่และการโจมตีที่ถูกต้องในระหว่างการทดสอบได้
1.2 ตรวจสอบ Application Discovery : เพื่อค้นหาว่ามีแอพพลิเคชั่นใดที่ทำงานอยู่ใน web server นี้บ้างเช่นตรวจดู Hyper link ทั้งหมดในเว็บไซต์เพื่อดูความผิดปกติ Link และหากพบว่ายังขาดการตั้งค่าสิทธิการเข้าถึง Link path ที่สำคัญก็ควรปิด เช่น path ที่เกี่ยวข้องกับการ config ต่างๆ
1.3 วิเคราะห์หา Error Code : การทดสอบ web application มักจะพบกับ error code จากแอพพลิเคชั่นหรือ web server เป็นไปได้ที่จะทำให้เกิดมีการแสดง error เหล่านี้โดยการใช้ request เฉพาะ ข้อความแสดงข้อผิดพลาดเหล่านี้มีประโยชน์มากสำหรับผู้ทดสอบเพราะมันจะเปิดเผยข้อมูลที่มีประโยชน์เกี่ยวกับฐานข้อมูล ช่องโหว่ (bug) และองค์ประกอบอื่น ๆ ที่เกี่ยวข้อง
1.4 ทดสอบ file extensions handling : web server มักใช้ file extension เพื่อตัดสินใจเกี่ยวกับเทคโนโลยี ภาษา ปลั๊กอินที่ต้องใช้เพื่อร้องของผ่านทางเวบให้สำเร็จผล การทดสอบ file extension ให้ข้อมูลที่มีประโยชน์สำหรับผู้ทดสอบเกี่ยวกับเทคโนโลยีที่ใช้ใน web application และยังช่วยให้การเลือกรูปแบบในการโจมตีสำหรับเทคโนโลยีต่าง ๆ ทำได้ง่ายขึ้น นอกจากนี้การกำหนดค่าที่ผิดพลาดใน web server ยังอาจเปิดถึงข้อมูลสำคัญเกี่ยวกับการเข้าถึงระบบอีกด้วย
1.5 ทดสอบ SSL-TLS : การกำหนดค่าที่ผิดพลาดใน web server ที่เกี่ยวกับการเข้ารหัสการสื่อสาร อาจทำให้ผู้โจมตีสามารถใช้การเข้ารหัสที่มีความปลอดภัยน้อยกว่าเพื่อเข้าถึงช่องทางการสื่อสารที่เข้ารหัสไว้ได้
1.6 ทดสอบการค้นหา old file : ไฟล์ที่ไม่ใช้งานหรือไฟล์เก่าอาจสามารถใช้เพื่อหาข้อมูลสำคัญเกี่ยวกับโครงสร้างระบบหรือวิธีการเข้าถึงระบบได้
1.7 ทดสอบค่า Default or Guessable User Account : web application ในปัจจุบันนี้มักอาศัยซอฟท์แวร์ยอดนิยม ซึ่งอาจเป็นแบบโอเพ่นซอร์สหรือขายเชิงพาณิชย์ซึ่งติดตั้งใน server และจำเป็นต้องมีการกำหนดค่าหรือปรับแต่งโดยผู้ดูแลระบบ บ่อยครั้งที่ แอพพลิเคชั่นเหล่านี้ไม่ได้กำหนดค่าอย่างถูกต้องและไม่ได้อัพเดทชื่อผู้ใช้และรหัสผ่าน ทำให้ผู้บุกรุกสามารถใช้เพื่อเข้าถึงเครือข่ายภายในและขโมยข้อมูลได้
1.8 ทดสอบการ Brute Force password : เป็นการทดลองเข้าระบบโดยการใช้ชื่อผู้ใช้และรหัสผ่านที่เป็นไปได้ทั้งหมด ในการทดสอบ web application เราจะตรวจสอบชนิดของการพิสูจน์ตัวผู้ใช้และความมีประสิทธิภาพในการโจมตี brute-force แบบต่าง ๆ
1.9 ทดสอบการ Bypassing Authentication Schema : ในขณะที่แอพพลิเคชั่นส่วนใหญ่จำเป็นต้องอาศัยการพิสูจน์ตัวเพื่อการเข้าถึงข้อมูลหรือทำงานบางอย่าง แต่ไม่ได้หมายความวิธีการที่ใช้ในการพิสูจน์ตัวทุกวิธีที่มีใช้การรักษาความปลอดภัยอย่างเพียงพอ ความละเลย ความไม่รู้ หรือไม่ให้ความสำคัญกับภัยคุกคามด้านความปลอดภัยมักมีผลทำให้ระบบที่ใช้ในการพิสูจน์ตัวผู้ใช้ถูกหลบหลีกได้อย่างง่ายดายโดยการหลบหลีกหน้าล็อกอินและเรียกหน้าภายในโดยตรง นอกจากนี้ยังอาจสามารถหลบหลีกมาตรการในการพิสูจน์ผู้ใช้โดยการแก้ไขการร้องขอโดยการหลอกให้แอพพลิเคชั่นคิดว่าได้ผ่านการพิสูจน์ตัวแล้ว โดยการแก้ไขพารามิเตอร์ของ URL หรือแก้ไข form หรือปลอม session
1.10 ทดสอบ Directory Traversal : มี web application หลายตัวที่ใช้และจัดการไฟล์ ถ้าแอพพลิเคชั่นเหล่านี้ใช้วิธีการตรวจสอบอินพุทที่ออกแบบมาไม่ดี ผู้โจมตีสามารถอาศัยประโยชน์เพื่ออ่าน/เขียนไฟล์ที่ไม่ได้ตั้งใจให้สามารถเข้าถึงได้ ในบางสถานการณ์อาจสามารถทำให้สามารถเอ็กซิคิวท์โค้ดที่ต้องการได้
1.11 ทดสอบหา Vulnerable Remember Password and Pwd Reset : มี web application หลายตัวที่ช่วยให้ผู้ใช้สามารถรีเซ็ตรหัสผ่านในกรณีที่ลืมรหัสผ่าน ซึ่งโดยปกติมักจะส่งอีเมลที่บอกรหัสผ่านที่รีเซ็ตใหม่ไปให้ หรือถามคำถามที่ผู้ใช้เคยกำหนดไว้ให้ถูกต้อง ในการทดสอบนี้เราจะตรวจสอบว่าระบบนี้ทำงานได้อย่างถูกต้องและไม่มีช่องโหว่ในการทำงาน
1.12 ทดสอบหาค่าตกค้าง จากการ Logout และ Browser Cache Management : ในขั้นตอนนี้ เราจะตรวจสอบว่าการทำงานของระบบ logout ทำงานได้อย่างถูกต้องหรือไม่ และเป็นไปได้ที่จะใช้ session ใหม่อีกครั้งหลังจาก logout แล้วหรือไม่ เรายังตรวจอีกด้วยว่าแอพพลิเคชั่นดังกล่าวได้ logout ผู้ใช้แบบอัตโนมัติหลังจากผู้ใช้ไม่ทำงานหลังจากช่วงระยะเวลาหนึ่งผ่านไปแล้วหรือไม่ และไม่มีข้อมูลสำคัญที่ยังคงค้างอยู่ใน cache ของบราวเซอร์
1.13 ทดสอบค่า Session Management Schema : ในการหลีกเลี่ยงการพิสูจน์ตัวผู้ใช้สำหรับแต่ละหน้าของเวบไซต์หรือบริการหนึ่ง web application จะใช้กลไกต่าง ๆ ในการเก็บและตรวจสอบชื่อผู้ใช้และรหัสผ่านสำหรับช่วงเวลาหนึ่งที่กำหนดไว้ กลไกเหล่านี้เรียกว่า Session Management ซึ่งช่วยให้แอพพิลเคชั่นเหล่านี้ใช้งานง่าย แต่มันอาจจะถูกใช้ประโยชน์จากผู้ทดสอบเพื่อให้สามารถเข้าถึงแอคเคาท์ของผู้ใช้โดยไม่จำเป็นต้องใส่ชื่อและรหัสผ่านที่ถูกต้องได้
1.14 ทดสอบค่า Cookie and Session Token Manipulation : ตรวจสอบว่า cookie และสิ่งที่ใช้สำหรับแสดง session แบบอื่น ๆ ได้สร้างขึ้นมาอย่างปลอดภัยและไม่สามารถคาดเดาได้ ผู้โจมตีที่สามารถเดาและปลอม cookie ได้จะสามารถเข้าถึง session ของผู้ใช้ที่ถูกต้องได้
1.15 ทดสอบค่า Exposed Session Variables : ถ้าสิ่งที่ใช้แสดง session (cookie, SessionID, Hidden Field) ถูกเปิดเผย ทำให้ผู้โจมตีสามารถปลอมเป็นเหยื่อและเข้าถึงแอพพิลเคชั่นได้ ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องป้องกันจากการดักข้อมูล โดยเฉพาะในการส่งข้อมูลระหว่างไคลเอ็นท์และ application server
1.17 ทดสอบ HTTP Exploit : ขั้นตอนนี้จะอาศัยฟีเจอร์ของ HTTP protocol เพื่อโจมตี ซึ่งอาจอาศัยช่องโหว่ใน web application หรือวิธีการต่าง ๆ ที่ agent ใช้เพื่อตีความข้อความของ HTTP
1.18 ทดสอบ Cross site scripting : เป็นการโจมตีในระดับแอพพิลเคชั่นที่พบได้บ่อยครั้ง Cross Site Scripting ใช้ตัวย่อ XSS เพื่อหลีกเลี่ยงความสับสนกับคำว่า Cascading Style Sheets (CSS) การทดสอบ XSS มักเป็นผลให้มีการแสดงหน้าต่าง JavaScript alert แสดงให้ผู้ใช้เห็น หน้าต่าง alert อาจเป็นสัญญาณที่บ่งชี้ได้ว่าผู้โจมตีสามารถรันโค้ดที่ต้องการได้ อ่านเพิ่มเติมได้ที่ http://www.sran.net/archives/200 และ http://www.sran.net/archives/201
1.19 ทดสอบค่า HTTP Methods and XST : ในขั้นตอนนี้เราจะตรวจสอบว่า web server ไม่ได้กำหนดค่าให้ยอมรับคำสั่ง (method) HTTP ที่มีอันตรายและการโจมตี Cross Site Tracing (XST) ไม่สามารถทำได้
1.20 ทดสอบ SQL Injection : เพื่อทดสอบการโจมตี SQL Injection ประกอบด้วยการป้อนคำสั่ง SQL ผ่านทางข้อมูลอินพุทจากไคลเอ็นท์ไปยังแอพพลิเคชั่น การโจมตี SQL injection ที่สำเร็จสามารถอ่านข้อมูลที่เป็นความลับจากฐานข้อมูล แก้ไขข้อมูลในฐานข้อมูล เอ็กซิคิวท์คำสั่งของผู้ดูแลระบบ หรือในบางกรณีสามารถใช้คำสั่งภายในระบบได้
1.21 ทดสอบ SSI Injection : เพื่อทดสอบ web server หลายตัวที่มีฟีเจอร์ที่ช่วยให้สามารถเพิ่มโค้ดแบบไดนามิคเข้าไปในหน้า html แบบ static ฟีเจอร์นี้เรียกว่า Server-Side Includes (SSI) เป็น extension ที่อาจทำให้ผู้โจมตีสามารถใส่โค้ดเข้าไปในหน้า html หรือเอ็กซิคิวท์โค้ดจากระยะไกลได้
1.22 ทดสอบ IMAP/SMTP Injection : เพื่อตรวจสอบภัยคุกคามนี้มีผลกระทบกับแอพพลิเคชั่นที่สื่อสารกับ mail server (IMAP/SMTP) ส่วนใหญ่แล้วจะเป็น webmail เพื่อทดสอบความเป็นไปได้ในการป้อนคำสั่ง IMAP/SMTP เข้าไปใน mail server เนื่องจากไม่มีการตรวจสอบข้อมูลที่ป้อนเข้าไปอย่างเพียงพอ
1.23 ทดสอบ Code Injection : เพื่อทดสอบว่าสามารถใส่โค้ดเข้าไปในหน้าเวบและทำให้ web server เอ็กซิคิวท์โค้ดดังกล่าวได้หรือไม่
1.24 ทดสอบ Command Injection : เป็นการทดสอบการป้อนคำสั่งของระบบปฏิบัติการผ่านทาง HTTP request ไปยังแอพพลิเคชั่น
1.25 ทดสอบช่องโหว่ Web Application ผ่านช่องทางระบบ Search engine ซึ่งเราสามารถค้นหาลักษณะตัวแปรของการเขียน code web application และหาช่องโหว่ได้ ผมได้เขียนไว้ที่ http://nontawattalk.blogspot.com/2004/12/personal-information-is-not-secured.html
2. ผู้ให้บริการ DNS Server ที่เป็นบริการสาธารณะ (อ่านมุมมองในการเก็บ Log http://nontawattalk.blogspot.com/2009/04/blog-post.html เพื่อสืบหาผู้กระทำความผิด)
ช่องโหว่ที่มีกับ DNS Server ที่เป็นลักษณะ Fast flux ซึ่งเป็นเทคนิคทาง DNS ที่ใช้โดย botnet เพื่อซ่อนไซต์ที่ทำหน้าที่ให้บริการ phishing และมัลแวร์ ที่อยู่เบื้องหลังเครือข่ายของโฮสต์ที่ถูกบุกรุก
ทำตัวเป็น proxy ที่มีการเปลี่ยนแปลงตลอดเวลา ยังหมายถึงเครือข่ายแบบ peer-to-peer รวมกันหลายเครือข่าย ใช้เทคนิคต่าง ๆ ได้แก่ การใช้คำสั่งและการควบคุมแบบกระจาย (distributed) การใช้ load-balancing และการเปลี่ยนเส้นทาง proxy เพื่อทำให้การเครือข่ายมัลแวร์ยากต่อการถูกตรวจพบและการป้องกัน Storm Worm เป็นหนึ่งในมัลแวร์ที่ใช้เทคนิคเหล่านี้ผู้ใช้อินเทอร์เน็ตอาจพบการใช้ fast flux ในการโจมตี phishing ที่มีเชื่อมโยงกับกลุ่มอาชญากร รวมถึงการโจมตี MySpace , facebook อีกด้วย
ลักษณะการโจมตี DNS แบบ Single-flux และ double-flux
fast flux แบบง่าย ๆ เรียกว่า "single-flux" มีโหนดหลาย ๆ โหนดภายในเครือข่ายที่ลงทะเบียนและเลิกลงทะเบียนที่อยู่ของพวกมันโดยใช้ DNS A record สำหรับชื่อ DNS เดียว ใช้ round robin DNS ที่มีค่า TTL (time to live) สั้นมาก ๆ เพื่อสร้างรายชื่อของที่อยู่เป้าหมายที่มีการเปลี่ยนแปลงตลอดเวลาสำหรับชื่อ DNS เดียว รายชื่อนี้อาจยาวเป็นหลายร้อยหรือหลายพันบรรทัด fast flux ที่มีความซับซ้อนมากกว่านี้เรียกว่า "double-flux" มีหลายโหนดภายในเครือข่ายที่ลงทะเบียนและเลิกลงทะเบียนที่อยู่ของพวกมัน
โดยใช้ DNS SOA (start of authority) record ซึ่งจะช่วยเพิ่มเสถียรภาพและความอยู่รอดภายในเครือข่ายมัลแวร์นี้ได้
การทดสอบ DNS Server
ให้มีการตรวจสอบการ query Zone Tranfer ซึ่งเป็นผลทำให้ทราบข้อมูลในส่วนเครื่องแม่ข่าย (Server) ทั้งหมดในองค์กรได้
Zone transfer เป็นวิธีการที่ secondary DNS server ใช้สำหรับอัพเดทข้อมูลจาก primary DNS server, DNS server ของโดเมนหนึ่งจะทำงานใช้วิธีการที่เรียกว่า master-slave ซึ่งตัวที่เป็น slave จะอัพเดทข้อมูล DNS จากตัวที่เป็น master ผู้ดูแลระบบควรกำหนด DNS server ให้ยอมให้มีการทำ zone transfer จาก secondary (slave) DNS server เท่านั้น
3. Mail Server ที่เป็นการให้บริการสาธารณะ Mail Server มักจะมีการใช้ DNS และ Web Application มาเกี่ยวข้องดังนั้นภัยคุกคามที่เกิดกับ Mail Server นั้นต้องพิจารณา DNS และเรื่องของ Web Application มาเกี่ยวข้องด้วยเสมอ เนื่องจาก Mail ในยุคปัจจุบันก็สามารถทำงานผ่าน Web Application มากขึ้น
ภัยคุกคามจาก Mail Server ที่ควรตรวจสอบก็ควรพิจารณาผู้อื่นมาใช้ Mail Server เราเพื่อทำเป็น Spam Server ได้จากการตรวจสอบขั้นต้นคือดูที่ Mail server เปิด Open relay ที่จะอนุญาตให้บุคคลภายในใช้ mail server เพื่อส่งอีเมลไปยังที่อื่นได้หรือไม่ จากคำสั่ง
เนื่องจากรายละเอียดในแต่ละ Application Protocol มีอยู่มาก ดังนั้นการที่เราจะทำให้ระบบนี้ปลอดภัยทั้งหมดจำเป็นต้องอาศัยผู้เชี่ยวชาญมาทำการประเมินความเสี่ยง (Vulnerability Assessment) และหาวิธีการปิดกั้นภัยคุกคาม (Hardening) ที่อาจเข้าถึงระบบของเราได้ รวมถึงการออกแบบระบบเครือข่าย (Network Re-design) เพื่อรองรับปริมาณข้อมูลและความปลอดภัย จึงทำให้ปัญหาต่างๆบนระบบไอซีทีขององค์กรเราเหลือน้อยลงและมีสร้างประสิทธิภาพการทำงานให้สูงขึ้นได้ จงจำไว้ว่าความมั่นคงปลอดภัยทางไอทีจะเกิดขึ้นได้ต้องมี 3 ประสานเดินไปพร้อมกัน ไม่ว่าเป็น คน กระบวน และเทคโนโลยี มีกระบวนการนโยบายมาควบคุมคน มีคนมาควบคุมการใช้เทคโนโลยี และมีเทคโนโลยีเพื่อตอบสนองความสะดวกสบายและความปลอดภัยในองค์กรเป็นชั้นๆไป หากขาดสิ่งใดสิ่งหนึ่งย่อมทำให้เกิดช่องโหว่ตามมาไม่ทางใดก็ทางหนึ่ง
ส่วนอีกมุมคือ มุมของผู้ใช้บริการ ส่วนใหญ่ปัญหาต่างๆเกิดจากผู้ใช้บริการ (User) นั่นแหละ ผู้ใช้บริการมี 2 ลักษณะคือ ผู้ใช้บริการที่มีเจตนาในการโจมตีระบบ และ ผู้ใช้บริการที่ไม่มีเจตนา
ผู้ใช้บริการที่เจตนาในการโจมตีระบบ (Hacker) ส่วนใหญ่แก้ไขโดยต้องสร้างจรรยธรรมในการใช้คอมพิวเตอร์ และให้คิดถึงใจเขาใจเรา หรือใช้กฏหมายมาควบคุมคนเหล่านี้
ผู้ใช้บริการที่ไม่มีเจตนาในการโจมตีระบบ มักเป็น zombie ผีดิบ หากมี zombie หลายๆตัวรวมเป็นกองทัพ botnet เนื่องจากเครื่องคอมพิวเตอร์เหล่านั้นติด Malware จากพฤติกรรมการใช้งานไอซีที ก็จะสร้างความเสียหายให้กับเครือข่ายองค์กรมาก มักจะพบสถิติมีจำนวนมากขึ้นเรื่อย เนื่องจากการขาดความตระหนักในการใช้ข้อมูล และทำให้เครื่องผู้ใช้งานเป็นฐานทัพของ Hacker เพื่อใช้เครื่องคอมพิวเตอร์ในการโจมตีระบบต่อไป ไม่รู้จักจบสิ้น วิธีป้องกันเพื่อไม่ให้ผู้ใช้งาน (User) เป็น botnet ต้องอาศัยการจัดอบรมความมั่นคงปลอดภัยในการใช้ข้อมูลสารสนเทศขึ้นอย่างต่อเนื่องเพื่ออัพเดทเทคนิคใหม่ๆ ภัยคุกคามใหม่ๆ และควบคุมพฤติกรรมการใช้งานของผู้ใช้ (User) ให้ได้จากเทคโนโลยี ซึ่งจะทำให้ความเสี่ยงน้อยลง ถึงแม้ปัญหาพวกนี้เป็นปัญหาโลกแตกจนไม่สามารถทำให้ทุกเครื่องคอมพิวเตอร์บนโลกใบนี้ปลอดภัยได้หมดได้ แต่ก็เป็นหน้าที่ของทุกคนที่ทำให้เครื่องปลอดภัย เพราะความมั่นคงปลอดภัยต้องเริ่มจากตัวเองก่อนเสมอ ...
นนทวรรธนะ สาระมาน
Nontawattana Saraman
22/09/52
ทางบริษัท Global Technology Integrated มีผู้เชี่ยวชาญที่ให้คำปรึกษาและจัดการออกแบบระบบเครือข่ายให้มีความปลอดภัย ในบริการที่ชื่อว่า One Security Services และบริการอื่นๆ สามารถอ่านได้ที่
http://www.gbtech.co.th/th/servicesบทความเกี่ยวข้อง
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 1
ภัยคุกคามตาม Layer ทั้ง 7 ตอนที่ 2
ไม่มีความคิดเห็น:
แสดงความคิดเห็น