banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: TheEyes  XML
Profile for TheEyes Messages posted by TheEyes [ number of posts not being displayed on this page: 0 ]
 
Câu hỏi của em viết có điểm gì không hay, không hấp dẫn, hay thiếu thông tin không ?
Cá nhân mình thì thấy công việc cứ trót lọt, có kết quả phè phè thì thể nào cũng có hứng thú. Còn khi bế tắc thì tập trung tìm hướng giải quyết, xem xét, hỏi han thì thể nào cũng ra. Ra được kết quả rồi thì lại hứng thú mà làm tiếp. Có cái vòng "luẩn quẩn" ở đây mà smilie Để thiết lập được cái vòng đó thì bản thân phải tự chăm chỉ thôi.
Em chào các bác.

Em xin vào đề luôn.

Một số khách hàng đôi khi không hiểu rõ nhu cầu bản thân họ cần gì. Thâm chí, họ không có hiểu biết về công nghệ nữa. Với những khách hàng thuộc nhóm này, yêu cầu đưa ra cho đội ngũ kỹ thuật sẽ rất mông lung. Đại loại như: "Làm cho chị web site bán hàng này nhé. Chị muốn bán được hàng qua đó".

Khi gặp phải những khách hàng này, em cảm thấy rất mơ hồ về thứ mình sẽ phải tạo ra. Có lẽ với những khách hàng nhóm này, ta không thể mong họ tự làm yêu cầu chính xác đầy đủ cho mà tự bản thân mình phải làm thay họ thôi. Nhưng nói thiệt em chưa quen phân tích yêu cầu lắm. Không biết nên bắt đầu từ đâu. Những yêu cầu này lại liên quan trực tiếp đến công việc nghiệp vụ chuyên môn của khách hàng nữa chứ. Em có rành mấy chuyện buôn bán lắm đâu. Em cũng không biết phạm vi mong muốn của khách hàng đến đâu nữa. Nhỡ mà chẳng may, làm giữa chừng, họ lại sực nhớ họ cần cái nọ cái kia hay đổi ý thêm nọ bớt kia thì lại mệt mất.

Em cũng chưa phân biệt rõ ràng ranh giới giữa business requirement và system requirement nữa. Theo em đọc thì business requirement sẽ là các yêu cầu thuần tuý liên quan đến nghiệp vụ một ngành nghề nào đó. Còn system requirement là các yêu cầu ở mức business nhưng đã được mô tả lại theo hướng kỹ thuật hơn. Thế thì yêu cầu "Tớ muốn web site có chức năng thanh toán điện tử. Cậu cung cấp cho tớ thêm tool để làm báo cáo về doanh số bán hàng nữa..." thì nên xếp vào yêu cầu business nhỉ ? Từ business requirement này thì triển khai thành system requirement như thế nào nhỉ ?

Có bác nào có kinh nghiệm trong khâu phân tích yêu cầu thì cho em xin vài lời khuyên đi ạ.
Nếu em là chuyên viên nhận trách nhiệm khắc phục server sau khi bị thâm nhập. Em nghĩ em sẽ làm như thế này:

Xác định các đối tượng liên quan:
Ai liên quan đến sự cố thâm nhập ?
- Khách hàng
- Công ty
- ISP
- Xã hội

Công ty cần làm gì với các bên ?
- Với khách hàng:
+ Trong thời gian đầu nên chỉ thông báo với khách hàng server đang bảo trì
+ Đồng thời chuẩn bị sẵn sàng trường hợp sự cố dai dẳng, không thể chốc lát mà giải quyết được
-> Cần phải nói rõ với khách hàng về mức độ thiệt hại
-> Chuẩn bị các phương án đền bù nếu mức độ thiệt hại ảnh hưởng đến khách hàng

- Với ISP:
+ Contact trực tiếp với bên ISP
-> Yêu cầu họ cô lập server
-> Yêu cầu họ giữ nguyên hiện trạng
-> Tiếp tục yêu cầu họ báo cáo tình hình server, mức độ thiệt hại, ảnh hưởng

Những báo cáo đó có thể được chính nhân viên của công ty đó phân tích (nếu họ có thể) hoặc chuyển giao cho bên thứ ba như C50 hoặc tiến hành trong sự hợp tác cả ba bên: nhân viên kỹ thuật của công ty, ISP và C50

+ Xem xét các điều khoản với ISP. Trách nhiệm của ISP trong trường hợp này là gì ?

- Với xã hội:
-> Cần một phát ngôn viên chính thức để thông cáo tình hình với báo chí. Luôn luôn đảm bảo giữ một kênh thông tin liên lạc thường xuyên và chính thức với cánh báo giới.

- Hiện trạng là gì ?
+ Dịch vụ nào không hoạt động
+ Những bất thường xảy ra đã ghi nhận được

- Xác nhận thời điểm tấn công gần đúng qua file log
smilie Riêng chuyện file log có thể bị làm giả, mất tính toàn vẹn thì em cũng chưa biết sẽ xử lý thế nào ?

- Loại hình mà attacker đã sử dụng để thâm nhập server
+ Kết hợp hai yếu tố trên cộng với xem xét lại cấu hình hệ thống tìm ra cách mà attacker đã dùng để thâm nhập
+ Tại đây, nhân viên phân tích cũng sẽ lưu tâm đến các yếu tố liên quan: Liệu xung quanh thời điểm bị tấn công, dedicated server có liên hệ với server nào khác, có được sửa đổi cấu hình gì không.

- Thử nghiệm
+ Thử dựng lại tình huống tương tự với các điều kiện tương tự để xác nhận các phỏng đoán về cách thâm nhập

- Xác định nguyên nhân
+ Biết được cách thâm nhập thì sẽ tìm ra lỗ hổng của hệ thống

- Khắc phục
+ Tìm cách bít lỗ hổng này

- Tính đến các giải pháp lâu dài:
Lỗ hổng đã được vá. Công ty cần xem xét xây dựng bổ sung quy chế bảo mật và điều khoản chặt chẽ minh bạch với ISP

- Mở rộng điều tra:
Tìm xem nguồn gốc tấn công đến từ đâu ?
...
Đến đây thì em mù mờ. Em không có những kỹ năng chuyên sâu của lãnh vực bảo mật và forensics nên không thể đi sâu hơn nhưng với đề bài này thì em nghĩ tiêu điểm của case study không nhằm hướng tới các chi tiết kỹ thuật phức tạp, nặng tính chuyên môn smilie


 

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|