วิเคราะห์ความเสี่ยงของ Web Application ด้วย D.R.E.A.D.

วิเคราะห์ความเสี่ยงของ Web Application ด้วย D.R.E.A.D.

การจัดการโครงการทางด้านไอที
การวิเคราะห์ความเสี่ยงของ Web Application ด้วยแบบจำลอง DREAD เป็นวิธีการที่ใช้กันอย่างแพร่หลาย ในการคำนวณระดับความเสี่ยงที่ถูกแสดงด้วยภัยคุกคาม มันเกี่ยวข้องกับการให้คะแนนตัวเลข กับตัวแปรความเสี่ยงทั้ง 5 แล้วเอามาคำนวณค่าความเสี่ยง ตัวแปรห้าตัวสำหรับการคำนวณความเสี่ยงในรูปแบบ DREAD คือ: Damage potential: ความเสียหายที่อาจเกิดขึ้น ประเมินความเสียหายที่อาจเกิดขึ้นจากช่องโหว่ที่เกิดขึ้น ค่าความเสียหายยิ่งมาก ความเสี่ยงก็ยิ่งสูง Reproducibility: ความสามารถในการเกิดซ้ำ กำหนดระดับความยากลำบากในการเกิดปัญหาซ้ำๆ หรือความสำเร็จที่จะทำให้เกิดปัญหาขึ้น การเกิดปัญหาซ้ำๆได้ง่าย จะทำให้ความเสี่ยงสูงขึ้น Exploitability: ความสามารถที่จะทำให้สำเร็จ ประเมินระดับความเชี่ยวชาญ เวลา และเครื่องมือที่จำเป็นในการทำใ้เกิดปัญหา กระบวนการที่เกิดปัญหานี้ยิ่งง่ายมากเท่าใด ค่าความเสี่ยงจะสูงขึ้น Affected users: ผู้ใช้ที่ได้รับผลกระทบ คำนวณจำนวน และความสำคัญของผู้ใช้ ที่อาจได้รับผลกระทบ ยิ่งจำนวนของผู้ใช้งานที่มากขึ้น และมีความสำคัญมากเท่าใด ก็ยิ่งมีความเสี่ยงสูงเท่านั้น Discoverability: การค้นพบ ประเมินความง่ายในการระบุภัยคุกคาม ซึ่งอาจมองเห็นได้ง่าย แสดงในแถบที่อยู่ของเว็บเบราเซอร์ ไปจนถึงสิ่งที่ไม่ได้รับการบันทึกไว้ และยากที่จะตรวจจับ ยิ่งความยากมากเท่าใด ความเสี่ยงก็ยิ่งมากขึ้น ค่าความเสี่ยง ขั้นตอนต่อไป เราจะกำหนดค่าใดค่าหนึ่งต่อไปนี้ ให้กับแต่ละตัวแปรทั้งห้าตัว เพื่อให้ได้รูปแบบการรักษาความปลอดภัยที่ชัดเจน: 0 = ไม่เสี่ยงเลย 5 = ความเสี่ยงปานกลาง 10 = ความเสี่ยงสูง ตัวอย่างการกำหนดค่าความเสี่ยง ตัวอย่างต่อไปนี้ คือ ช่องโหว่ของ Cross Side Script ซึ่งคะแนน DREAD ควรจะเป็นดังนี้ ความเสียหาย: 10 ความสามารถในการทำซ้ำได้: 5 การใช้ประโยชน์ได้: 10 ผู้ใช้ที่ได้รับผลกระทบ: 10 ความสามารถในการค้นพบ: 5 คะแนนรวม: 40 ในกรณีนี้ เราสามารถประเมินได้จากคะแนนรวมที่สูงว่า ช่องโหว่นี้มีศักยภาพในการทำให้เกิดความเสียหายอย่างมาก กับผู้ใช้จำนวนมาก และควรได้รับการบรรเทาทันที
Read More
นิยามความหมายของ การพัฒนาซอฟต์แวร์

นิยามความหมายของ การพัฒนาซอฟต์แวร์

การจัดการโครงการทางด้านไอที
การพัฒนาซอฟต์แวร์ เป็นกิจกรรมที่เกี่ยวข้องกับการสร้าง หรือปรับแต่งซอฟต์แวร์ ซึ่งอาจรวมถึง การเปิดตัวเว็บไซต์ใหม่ การติดตั้งเครื่องมือการบริหารลูกค้าสัมพันธ์ (Customer Relationship Management: CRM) การนำชุดบัญชีใหม่ไปใช้งาน การสร้างแอปพลิเคชันเฉพาะ สำหรับธุรกิจของคุณ กิจกรรมเหล่านี้ทั้งหมดเป็นคุณสมบัติของการพัฒนาซอฟต์แวร์ ธุรกิจส่วนใหญ่ ในบางประเด็นจะต้องเผชิญกับโครงการพัฒนาซอฟต์แวร์ เทคโนโลยีในตอนนี้มันถูกผนวกเข้าเป็นส่วนเดียวกับธุรกิจ และเป็นไปไม่ได้ที่จะหลีกเลี่ยงมัน ทำไม 'การพัฒนาซอฟต์แวร์' จึงเป็นเรื่องยาก? ก็เพราะมันไม่ใช่การสร้างบ้านน่ะสิ ผู้คนจำนวนมาก ใช้เปรียบเทียบในการสร้างบ้าน เพื่อเปรียบเทียบกับการพัฒนาซอฟต์แวร์ ผมเชื่อว่าการเปรียบเทียบแบบนี้ มันไม่ถูกต้อง เนื่องจากมันทำให้เข้าใจความรู้สึกตรวจจับทางด้านความปลอดภัย (Security) และธรรมชาติของการพัฒนาซอฟต์แวร์ (Nature of Software Development) ก็ผิดไป บ้านเป็นคอนกรีต และเป็นที่เข้าใจกันโดยทั่วไปว่า เราทุกคนอยู่ในบ้าน เราทุกคนมีข้อสมมติฐานต่างๆเกี่ยวกับเรื่องบ้าน แต่มันไม่สามารถกล่าวได้ในทางเดียวกันกับซอฟต์แวร์   บ้านต้องสร้างจากฐานชั้นแรก ไปชั้นสอง และสามตามลำดับ แต่การพัฒนาซอฟต์แวร์นั้นสามารถทำจากจุดใดก่อนก็ได้ เมื่อเอามารวมกันก็จะสามารถใช้งานได้ เราอาจจะทำหน้าจอ User Interface ก่อนทำฐานข้อมูลก็ได้ ดังนั้นการออกแบบจึงต้องออกแบบให้ครบถ้วนก่อนที่จะเริ่มทำ และซอฟต์แวร์แต่ละส่วนที่แยกกันพัฒนา รวมถึง Computer Hardware และเครือข่าย จะต้องเข้ากันได้เป็นอย่างดี รองรับการทำงานซึ่งกันและกัน
Read More
คำจำกัดความของ การจัดการโครงการแบบ Agile และ Waterfall

คำจำกัดความของ การจัดการโครงการแบบ Agile และ Waterfall

การจัดการโครงการทางด้านไอที
ในการจัดการโครงการทางด้านไอที การจัดการแบบ Waterfall กับแบบ Agile ได้ถูกนำมาประยุกต์ใช้ ในการจัดการโครงการด้านไอทีต่างๆอย่างแพร่หลายในอดีตจนถึงปัจจุบัน และการจัดการแบบ Waterfall กับแบบ Agile ก็มีความแตกต่างกัน ในการประยุกต์นำไปใช้งาน เรามาดูความแตกต่างของการจัดการโครงการทั้ง 2 แบบกัน การจัดการโครงการแบบ Waterfall แบบจำลองการจัดการโครงการแบบน้ำตก หรือ Waterfall นิยมใช้ในการพัฒนาระบบแบบ Software Development Life Cycle สำหรับวิศวกรรมซอฟต์แวร์ มักจะใช้พิจารณาวิธีการแบบคลาสสิกในการพัฒนาระบบด้วย System Development Life Cycle, แบบจำลอง Waterfall จะอธิบายถึงวิธีการพัฒนาที่เป็นเชิงเส้นและตามลำดับ (Linear and Sequential) การพัฒนาแบบ Waterfall มีเป้าหมายแตกต่างกันไปในแต่ละขั้นของการพัฒนา เราจะต้องลองนึกภาพน้ำตก ที่ตกลงมาจากหน้าผาชันที่สูงชัน เมื่อน้ำได้ไหลผ่านขอบของหน้าผา และได้เริ่มตกลงสู่ด้านล่างของหน้าผา น้ำที่ตกลงมาจะไม่สามารถไหลย้อนกลับได้ เป็นแบบเดียวกันกับการพัฒนาแบบ Waterfall เมื่อขั้นตอนการพัฒนาเสร็จสมบูรณ์ การพัฒนาจะดำเนินไปสู่ขั้นต่อไป และจะไม่มีการย้อนกลับ อีกด้านหนึ่งของการจัดการโครงการแบบ Waterfall คือ ใช้เป็นตัวขับเคลื่อนแผนการณ์ (Plan Driven) โดยพยายามที่จะกำหนดเอกสารรายละเอียดความต้องการ และแผนสำหรับโครงการทั้งหมดก่อนที่จะเริ่มโครงการ คำว่า Waterfall มักถูกใช้บ่อยๆ อย่างหลวมๆ เพื่ออ้างถึงวิธีการขับเคลื่อนแผนการณ์แบบใดๆก็ตาม คำว่า Waterfall ก็มีความหมาย หมายถึง รูปแบบทั่วไปของการจัดการโครงการ ที่เน้นความสามารถในการคาดการณ์และควบคุม มากกว่าความคล่องตัว (Agile) จึงทำให้กลายเป็นเพียงรูปแบบการจัดการโครงการที่ไม่ดี การจัดการโครงการแบบ Agile ความหมายของการจัดการโครงการแบบคล่องตัว หรือ Agile ในการเปรียบเทียบแบบนี้ ก็ค่อนข้างเข้าใจยากเพราะเป็นแนวคิดที่มีความหมายบางอย่างในการใช้งานจริง, ในระดับโครงการ, อย่างน้อยที่สุด, ในสหรัฐอเมริกา คำว่า Agile ได้ใช้ความหมายแฝงเฉพาะที่เกี่ยวข้องกับการใช้วิธีการ Scrum ในโครงการพัฒนาซอฟต์แวร์ การ Scrum เป็นรูปแบบการพัฒนาซอฟต์แวร์แบบ Agile ในรูปแบบของทีมขนาดเล็กหลายทีม ที่ทำงานในลักษณะที่เข้มข้นและพึ่งพากัน (Intensive and Interdependent Manner) คำว่า Scrum เป็นคำที่ใช้ในการเรียกรูปแบบการเล่นรักบี้ ซึ่งใช้ในการเริ่มเกมใหม่หลังจากเหตุการณ์ที่ทำให้การเล่นหยุดลง เช่น การทำผิดกติกา การ Scrum มีกระบวนการตัดสินใจในแบบเรียลไทม์ ขึ้นอยู่กับเหตุการณ์ และข้อมูลที่เกิดขึ้นจริง คำจำกัดความดังกล่าว มีการพัฒนาขึ้นในช่วงหลายปีที่ผ่านมา เนื่องจากการ Scrum กลายเป็นมาตรฐานสำหรับโครงการแบบ Agile อย่างไรก็ตาม ความหมายเดิมของ Agile ถูกคิดขึ้นใน Manifesto of Software Development ที่เผยแพร่ในปี พ. ศ. 2544 (หรือปี 2001) เป็นที่รู้จักกันดีในชื่อ Agile Manifesto…
Read More
วัฏจักรการพัฒนาซอฟต์แวร์: Software Development Life Cycle

วัฏจักรการพัฒนาซอฟต์แวร์: Software Development Life Cycle

การจัดการโครงการทางด้านไอที
วัฏจักรการพัฒนาซอฟต์แวร์ หรือ Software Development Life Cycle เป็นวัฏจักรพื้นฐานในการพัฒนาซอฟต์แวร์ หรือโปรแกรมคอมพิวเตอร์ ให้มีประสิทธิภาพมากยิ่งขึ้น นับตั้งแต่เริ่มเก็บความต้องการ (Get Requirement) ไปจนถึงการสำรวจความเห็นย้อนกลับ (Feedback) มาที่ผู้พัฒนา Software Development Life Cycle มีส่วนประกอบพื้นฐาน ดังต่อไปนี้ 1. Planning: วางแผนโครงการ การวางแผนการพัฒนาซอฟต์แวร์ เริ่มต้นจาก การเก็บความต้องการ (Get Requirement) ทั้งจากลูกค้า (Customer) หรือผู้ใช้งาน (User) อาจจะเป็นการกำหนดจากขั้นตอนทางธุรกิจ หรือ Business Process ก็ได้ 2. Analysis: วิเคราะห์โครงการ เมื่อเราได้ความต้องการจากลูกค้า หรือผู้ใช้งานแล้ว จะเข้าสู่ขั้นตอนการวิเคราะห์ระบบ ซึ่งจะต้องวิเคราะห์ความคุ้มค่าในการลงทุน (Return On Investment: ROI) ว่าคุ้มค่าในการดำเนินการต่อหรือไม่ เมื่อเราคำนวณความคุ้มค่าของโครงการแล้ว จึงจะนำมาจัดทำขอบเขตของโครงการ หรือ Project Scope Of Work เพื่อกำหนดขอบเขตการพัฒนาซอฟต์แวร์ว่าเราจะทำหรือไม่ทำอะไรบ้าง โดยขั้นตอนนี้จะต้องสรุปกับลูกค้า หรือผู้ใช้งาน ตามความต้องการ (Requirement) ที่ได้เก็บมาตั้งแต่ต้น จนได้ข้อสรุปที่ตกลงได้ทั้ง 2 ฝ่าย เมื่อเราสามารถสรุปขอบเขตของโครงการได้แล้ว ขั้นตอนต่อไปคือ การทำแผนการปฏิบัติการ หรือ Action Plan เพื่อกำหนดการทำงานภายใต้ระยะเวลาตามที่ได้สรุปกับลูกค้า หรือผู้ใช้งาน ในขอบเขตของโครงการ (Project Scope Of Work) 3. Design: ออกแบบระบบ การออกแบบระบบนี้ นอกจากการออกแบบทางด้านซอฟต์แวร์ ทั้งหน้าจอตอบสนองผู้ใช้งาน (User Interface: UI) และการโค้ดซอฟต์แวร์ (Software Coding) ด้วยการทำรายละเอียดซอฟต์แวร์ หรือ Software Specification แต่จะรวมถึงการออกแบบฐานข้อมูล (Database Design) และเครือข่าย (Network Design) ด้วย เพื่อให้ซอฟต์แวร์สามารถทำงานได้ตามความต้องการของลูกค้า หรือผู้ใช้งาน 4. Implementation: พัฒนาซอฟต์แวร์และติดตั้ง เมื่อทำการออกแบบระบบเรียบร้อยแล้ว จะเข้าสู่ขั้นตอนการพัฒนาซอฟต์แวร์ให้ใช้งานได้จริง โดยพัฒนาซอฟต์แวร์ตามที่ได้ออกแบบไว้แล้ว ให้กลายเป็นความจริง สามารถใช้งานได้อย่างมีประสิทธิภาพ ตรงตามความต้องการของลูกค้า หรือผู้ใช้งาน ตามที่ได้เก็บมา ขั้นตอนนี้จะทำอยู่ในสภาวะแวดล้อมทดสอบ หรือ Test Environment 5. Testing & Integration: ทดสอบและนำไปใช้งาน หลังจากพัฒนาซอฟต์แวร์แล้ว ขั้นตอนต่อไปคือการทดสอบและการบูรณาการ จะต้องทำการทดสอบจนกว่า ความผิดพลาดของซอฟต์แวร์ หรือบั๊ก (Bug) จะลดน้อยมากที่สุด…
Read More