Messages posted by: louisnguyen27

Không hẳn, một hệ thống tốt là hệ thống tiếp cận có hai chiều.
Những gì bottom up tiếp cận phải quay về được top down, bottom up chỉ giải quyết được vấn đề nhất thời không giải quyết được vấn đề lâu dài và ngược lại.

H3x4 wrote:

Để change DNS thì theo em biết chì cần mật khẩu là đủ rồi

Nếu có mật khẩu thì xác suất các tên miền khác cũng bị thay đổi rất cao. Trong trường hợp này liệu có đúng không?

louisnguyen27 wrote:

Cũng không hẳn từ phía registrar, còn phải xem con trojan đó "hành xử" như thế nào, mặc dù attacker không biết được anh conmale có sử dụng hay không, nhưng một khi máy được sử dụng thì thông tin sẽ được tận dụng triệt để.
Mình muốn hỏi một câu: Attacker nắm được thông tin gì để khởi động tấn công?

Không ai muốn trả lời tui vậy cà? smilie

LeVuHoang wrote:

Theo suy đoán riêng của tôi thì con trojan trên máy anh conmale không liên quan đến cuộc attack lần này. Vì attacker không thể biết anh conmale sẽ xài máy nào để cài vào từ trước được. Tôi nghiêng về phía lỗi của registra.
Ngoài ra, nếu tài khoản quản lý domain HVAOnline.net bị mất, *có thể* kéo theo các domain khác mất theo, không phải chỉ HVAOnline.net

Cũng không hẳn từ phía registrar, còn phải xem con trojan đó "hành xử" như thế nào, mặc dù attacker không biết được anh conmale có sử dụng hay không, nhưng một khi máy được sử dụng thì thông tin sẽ được tận dụng triệt để.
Mình muốn hỏi một câu: Attacker nắm được thông tin gì để khởi động tấn công?

conmale wrote:

Chuyện tốn kém không thể nói bừa mà phải chiết tính kỹ lưỡng để xác định cụ thể lợi hại.

Em thấy hai cha này hơi nhảm: ông thứ nhất nói mua này mua nọ nhưng chẳng phải là người chi tiền để đi mua, ông thứ hai cũng nhảm nốt vì bỏ thời gian đi cãi với ông thứ nhất.
Vấn đề duy nhất của hai đồng chí này là đưa ra phương án, tính ROI và khả năng.

@panfinder & winwinwin: http://en.wikipedia.org/wiki/Product_lifecycle

panfider wrote:

mình nghĩ cũng tuỳ ứng dụng mà cpu có tuổi thọ.
Ví dụ xài desktop hay laptop thì khoảng 3-5 năm
server thì hơn

Không hẳn, do cả môi trường nữa.
Trước giờ chưa nghe ai đề cập đến tuổi thọ của CPU cả, thực tế thì vì tuổi thọ của technology nhanh hơn tuổi thọ của CPU. Với lại người ta đánh giá chu kỳ sống của CPU chứ không đánh giá về tuổi thọ, dấu WEEE có nghĩa chuyện đó.

conmale wrote:

1. Sự gián đoạn (dài hoặc ngắn).
2. Sự thay đổi tính chất (giá trị).
3. Sự chấm dứt (vĩnh viễn).

Em mở rộng thêm phần của anh một chút.
Đánh giá risk bao gồm 2 phần, một phần là qualitative và phần khác là quantitative. Trong 3 cái risk anh conmale trình bày thì cái đầu tiên là quantitative vì thời gian gián đoạn là measurable, cái risk thứ hai là qualitative. Cái risk thứ 3 thực ra là một trường hợp đăc biệt của cái risk thứ 2 và thứ 1.
Hai cái risk này có một sự tương quan qua lại: một sự gián đoạn có thể làm thay đổi tính chất giá trị và ngược lại sự thay đổi tính chất giá trị có thể làm gián đoạn hệ thống.

Đi sâu hơn vào chi tiết các yêu cầu sau phải xem xét:
- Cấu trúc tổ chức (vai trò và hoạt động của admin và mod - đó là câu hỏi tại sao 1 người thì khác gì 2 người cho H3x4, 1 người thì có thể tạo ra risk 1 nhưng 2 người có thể tạo ra risk 2).
- Quản lý tài sản (kể cả tài sản vô hình hay hữu hình - vấn đề newbieproit đề cập - chu kỳ sống của một phần cứng, một kỹ thuật hay một phần mềm cần được phân tích và đánh giá, khó nhất là có thể dự báo được công nghệ hay kỹ thuật thay thế).
- Nguồn nhân lực (năng lực của admin mod, trong trường hợp các min hiện tại đều về vườn thì khả năng thay đổi tính chất và giá trị rất lớn)
- Môi trường và các yếu tố vật lý
- Trao đổi thông tin và quản lý hoạt động (Hoạt động của các min và mod, phòng thủ cho HVA, phần này 100% là kỹ thuật)
- Access control (Cái này thể hiện ở việc các elite hoặc mod được truy cập vào các khu vực sâu hơn).

1. Trong một cái Risk lớn sẽ có những cái risk nhỏ hơn và xác suất để cái risk nhỏ đó trở thành cái risk lớn.
2. Khi phân tích các risk phải có cái nhìn bao quát và toàn diện.
3. Việc khai triển từ cái risk lớn xuống cái risk nhỏ hơn sẽ được tiếp tục cho đến khi các risk con là có khả năng kiểm soát được tức là các control có tính thực tế.

@jino_hoang Mới nhìn vào thì ISMS thiên về quản lý, nhưng càng đi sâu vào chi tiết thì càng nhiều vấn đề kỹ thuật. Bắt đầu từ 27011 trở đi gần như kỹ thuật rất nhiều. Đặc biệt chỉ riêng 27033 và 27034 nó chứa một loạt 14 tiêu chuẩn con.
Mặc dù nó không hướng dẫn là phải làm như thế nào nhưng nó yêu cầu là phải đảm bảo. Mà để đảm bảo thì kỹ thuật phải rất vững.

5. Làm ISMS bắt đầu từ đâu???
Làm ISMS phải bắt đầu từ việc học từ ngữ (ISO27000) sử dụng trong ISMS để thống nhất cách hiểu, tư duy, diễn đạt và trình bày. Tránh trường hợp một từ bị diễn giải thành nhiều nghĩa lệch lạc. Tuy nhiên, vì lý do thời gian, tiền bạc, và kể cả... kiêu ngạo mà nhiều đơn vị thường bỏ qua bước này.
Câu trả lời thông thường khi người tư vấn yêu cầu triển khai học về từ vựng là: "Cái này dễ, để tự đọc là được rồi" nhưng thực tế không mấy ai đọc. Hơn nữa mục đích chính không phải là hiểu từ vựng mà để cho toàn bộ nhân viên có cách hiểu giống nhau.
Chính vì vậy mà khi làm ISMS các đơn vị thường bị thất bại và có tính hình thức vì quan điểm và cách hiểu của mỗi người, mỗi cấp trong tổ chức là khác nhau. Những người mới vào cũng không được học nên dần dần khi mà turnover của employee cao thì cách tư duy và định hướng không còn được như ban đầu.

@Vikjava & IQ thực ra thì chủ để là Risk chứ không phải là ISMS nhưng mình sẽ trình bày ISMS để mọi người tự nhận xét.

1. Khi nhắc đến ISMS người ta phải nói đến bộ tiêu chuẩn ISO/IEC 27000 series chứ không phải là một riêng một tiêu chuẩn nào cụ thể.
2. Bộ tiêu chuẩn 27000 có 21 tiêu chuẩn, nhưng tư tưởng chính nằm ở ISO/IEC27001 - cải tiến liên tục.
3. Có nhiều đồng chí chỉ tìm hiểu mỗi 27001 rồi phán: quá dễ, không thực tế... xin các đồng chí học hết 21 tiêu chuẩn rồi phán tiếp. Các bác đi tư vấn, xin làm ơn đừng nổ đừng xạo làm mất giá trị của tiêu chuẩn.
Em cũng chưa đủ trình độ để đi kiếm tiền bằng ISMS nên đó là lý do chỉ dám tư vấn miễn phí. Hiểu đầy đủ bộ này thì CISA cũng chỉ là muỗi.

4. Em xin liệt kê bộ tiêu chuẩn ISO 27000 ở đây:

* ISO/IEC 27000 — ISMS Tổng quát và từ vựng
* ISO/IEC 27001 — ISMS Yêu cầu
* ISO/IEC 27002 — Chuẩn mực thực hiện ISM
* ISO/IEC 27003 — Hướng dẫn triển khai ISMS
* ISO/IEC 27004 — Đo lường ISM
* ISO/IEC 27005 — Quản lý rủi ro IS
* ISO/IEC 27006 — Yêu cầu về tổ chức đánh giá và chứng nhận ISMS
* ISO/IEC 27011 — Hướng dẫn ISM cho tổ chức viễn thông.
* ISO 27799 - ISM trong y tế sử dụng ISO/IEC 27002
* ISO/IEC 27007 - Hướng dẫn đánh giá ISMS
* ISO/IEC 27008 - Hướng dẫn cho chuyên gia đánh giá về ISMS controls
* ISO/IEC 27013 - Hướng dẫn tích hợp triển khai ISO/IEC 20000-1 và ISO/IEC 27001
* ISO/IEC 27014 - Khung quản lý IS
* ISO/IEC 27015 - Hướng dẫn ISM cho tài chính và bảo hiểm
* ISO/IEC 27031 - Hướng dẫn mức độ sẵn sàng ICT cho BCM
* ISO/IEC 27032 - Hướng dẫn cybersecurity
* ISO/IEC 27033 - IT network security
* ISO/IEC 27034 - Hướng dẫn application security
* ISO/IEC 27035 - Quản lý security incident.
* ISO/IEC 27036 - Hướng dẫn bảo mật sử dụng trong outsourcing
* ISO/IEC 27037 - Hướng dẫn xác định, thu thập và/hoặc thu nhận và bảo quản các bằng chứng số.

Trong sê ri này có một số tiêu chuẩn không được đề cập (ví dụ ISO27012 cho egovernment) là do nguyên nhân các tiêu chuẩn này chưa định hình, hoặc chưa đủ điều kiện để nâng cấp lên thành tiêu chuẩn do Uỷ ban kỹ thuật của ISO và IEC quyết định.
Ngoài ra hai tiêu chuẩn 27033 và 27034 có các tiêu chuẩn con tương ứng hay còn gọi là các phần như 27033-1, 27034-5.

cvhainb wrote:

risks thì quá nhiều

Vấn đề ở chỗ thu hẹp phạm vi kiểm soát như thế nào???

newbieproit wrote:

Thêm nữa, đó 'risks' tiềm ẩn trong mọi vấn đề liên quan đến 'tài sản' quan trong nhất của HVA là database

Còn các tài sản khác ??? Tài sản là một khởi đầu tốt cho việc đánh giá risk.

newbieproit wrote:

Luôn bảo vệ và phát triển hình ảnh của HVA

Cái này không phải là biện pháp, mà là policy.

H3x4 wrote:

Do vậy giải pháp của em là 1 hoặc cùng lắm là 2 người!

Vậy trong trường hợp 1 người thì Risk của nó là gì? 2 người thì risk là gì???

vikjava wrote:

Thật sự mình chưa tiếp xúc hoặc đọc, hiểu về risk management. Tuy nhiên theo mình RISK bao gồm những thứ thấy đươc và có thể không thấy được.

Nên mình mới nói trí tưởng tượng phải phong phú một chút.

H3x4 wrote:

-Chỉ có 1 người duy nhất nằm quyền "sinh sát" cho hva.

Chỗ này có một risk khác.

@AIO cvhainb nói cũng có lý đó.
@vikjava tư duy của bồ nặng kỹ thuật quá.
@updateloves tư duy risk khá tốt. Tiếp tục phân tích sâu hơn đi.
@all Để làm risk thì phải có trí tưởng tượng phong phú một chút. Có thể GIẢ LẬP nhiều tình huống khác nhau, nhiều nguy cơ khác nhau.

conmale wrote:

1. HVA có "risks" không? Nếu có, những "risks" ấy là gì?

Nếu nói risks nó có thể hơi mơ hồ một chút, có người sẽ lý luận vì các bác admin quá giỏi nên sẽ không có risk. smilie

Có thể chuyển câu hỏi sang thành:

1. HVA có "threats" hay không? Nếu có, đó là những "threats" gì?

mrro wrote:

@louisnguyen27: bạn trả lời mình không hiểu gì hết :p. vậy làm sao mà đi tư vấn? àh cũng có khi đó là cách tư vấn hay, cứ nói sao mà khách hàng không hiểu là họ thấy sợ và thích thôi .
PS: mình không hiểu cái ý mã MD5 dễ hơn mã di truyền rất nhiều. dễ ở đây nghĩa là gì?

Vậy mới đi tư vấn miễn phí smilie

, thế mà cũng không chịu hiểu. smilie

Cuộc sống có nhiều thứ thú vị, không hẳn phải làm IT Hacker, mà làm Food Hacker cũng có cái hay. smilie

Nhiều lúc tự hỏi: Các bác hacker IT của chúng ta suốt ngày ngồi vá lỗi này fix lỗi nọ trên một cái IS để kiếm vài ngàn, trong khi các hacker finance cũng vá lỗi, fix lỗi trên FS họ kiếm vài chục ngàn, hay các bác hacker motorbike ngồi vá xe sửa xe kiếm chỉ vài đồng. ---> Hacker là một niềm đam mê về một system và sự trưởng thành về tư duy của cái system đó. Có là một hacker IT giỏi cỡ nào thì con bạn ốm bạn vẫn phải chở đi bác sỹ, có thể là một hacker IT có tiếng nhưng ra đường đi sửa xe máy vẫn phải đóng tiền "ngu", trong cái thế giới của bạn thì bạn là "chùm" nhưng trong thế giới người khác bạn chẳng là gì cả. Khi bạn tự hào ta là một hacker, ông bác sỹ hay ông sửa xe chẳng thèm quan tâm vì system của bạn không phải là system của họ.

@mrro: Có một cái vulnerability và một cái threat vậy xác suất xảy ra của một incident là bao nhiêu???

@mrro đồng ý với quan điểm hacker gần như là trưởng thành.
Mỗi system đều có hacker riêng của nó, về kỹ thuật và phương pháp có thể khác nhau nhưng tư duy là gần giống nhau.
http://foodhacking.com/
http://www.hackingphotographyworkshop.com/
Sở dĩ hacker của IT nổi tiếng vì IT là một ngành sử dụng nhiều khá nhiều chất xám. Nhưng cũng chính vì thế mà làm việc định hướng của hacker trong IT bị lệch lạc khá nhiều.
Nhiều người tự hào mình là hacker nhưng không hề biết rằng mã MD5 dễ hơn mã di truyền rất nhiều.
Mrro hỏi "Kém kỹ thuật thì làm sao đánh giá đúng risk cho hệ thống thông tin?"
Trả lời: "Risk thì không bao giờ đúng cả mà đã đúng thì nó chẳng có risk" bản thân mình kém kỹ thuật nó đã là một cái risk rồi vấn đề ở chỗ mình control chuyện đó bằng cách nào????
Kém so với anh em thôi nhưng không phải là củ chuối smilie

Mrro hỏi "Làm sao kiến nghị các control thích hợp?"
Trả lời: "Control thích hợp là tư duy của người đưa ra giải pháp không phải là tư duy risk, tư duy của risk là khi triển khai control đó tạo ra risk gì?"
Mrro hỏi: "Làm sao triển khai các control được chọn lựa?"
Trả lời: "Như trên".

@Z0rr0
Ý kiến anh cũng hay, để hôm nào em rảnh rỗi làm cái topic đó cho ra ngô ra khoai. smilie

@Prof
Mình không đi tư vấn, nếu có làm thì làm miễn phí nếu có thời gian rảnh rỗi. ISMS cũng chỉ là một phần rất nhỏ của risk management (ISO31000). Mình rất kém về kỹ thuật nhưng thường xuyên làm việc với Risk.
Thông thường trong những công ty lớn nó có một vị trí gọi là Chief Risk Officer. smilie

@tranvanminh Bên bồ làm ISMS kiểu đó là làm cho có đó.
Đã cấm USB mà cho YM và webmail thì chưa đi vào gốc của vấn đề mà chỉ show cho người ta thấy mình có hoạch định việc kiểm soát.
Khi làm risk assessment thì phải quy định quy mô của việc xử lý chứ không phải là giải quyết tổng quát.
Đã giải quyết xong cái risk thì nó không còn cái incident nữa mà nó là cái residua risk.
Hôm nào trao đổi thêm nhe. smilie

@all nhiều người không biết:
Thực tế ISMS nó tồn tại trong tất cả các công ty nhưng ISMS của họ chưa được chuẩn hoá.
ISMS không cần phải chứng nhận việc chứng nhận chỉ đưa ra một cam kết chứ không phải là một giá trị.
Việc hiểu sai ISMS làm mất đi giá trị của bản thân nó.

@conmale ISMS or not - Anh bỏ thẻ url làm gì? Sao có tới mấy admin và mấy mod lận? Anh tuyển thêm mod làm gì? Bấy nhiêu em nghĩ là đủ một cái ISMS rồi.

@Z0rr0 ISMS hay CMM hay ITIL nó là một cam kết chứ không phải là giá trị giống như em nói ở trên.

Xoá đi vì anh conmale trả lời rồi. Nhưng post lại vì lão spam thêm ở dưới.

Z0rr0 wrote:

Dễ nhận thấy louisnguyen27 tiếp cận ở góc độ người tham gia ISMS, trong khi anh đi từ góc độ người trực tiếp làm phần mềm. Cho nên những qui định, hướng dẫn, cách thức ISMS không thể can thiệp sâu vào qui trình làm phần mềm được, vì đó là 2 qui trình hoàn toàn khác nhau, chỉ hỗ trợ nhau mà thôi.

Về nhà bị vợ chửi hôm sau vô coding tầm bậy tầm bạ mà bảo là không liên quan???? smilie

Em nghĩ không riêng gì ISMS; CMM, TMM, hay PCMM cũng là phương pháp hạn chế Risk mà. Không phải chỉ có hỗ trợ không thôi đâu.

@Z0rr0 Em quan niệm khác anh. Những vấn đề anh nêu ra với em nó lại là những cái risk khác, đó là giải quyết theo kiểu ISMS.
Dù anh có làm gì hay xử lý như thế nào thì kết quả vẫn là câu hỏi thiệt hại gì và tổn thất bao nhiêu? smilie

@Z0rr0
Trong Risk management nó có allocation of responsibilities mà anh, anh control một team security mà mạnh thằng nào thằng đó làm thì chuyện đó nó cũng là một cái risk. Em cũng thấy nhiều nơi nhân viên thờ ơ với cái risk management vì nghĩ nó là vấn đề của cấp trên.

@Conmale
Em kết hợp với cái case này: /hvaonline/posts/list/13314.html và thấy ngay là đủ yếu tố để xây dựng một hệ thống ISMS: Risk management - Incident management - Change management.
(Anh nhắc CISSP mới sực nhớ ra cái domain này)

@H3x4
Kiểu tư duy của anh conmale là đem được những kiến thức trong hacking để chiêm nghiệm vào cuộc sống. Ngoài việc đặt câu hỏi để người khác trả lời thì việc đặt câu hỏi còn nhằm mục đích để người khác bộc lộ mình.
Để đạt được mức độ này thì về kiến thức phải rất sâu và thoát ra khỏi lối mòn tư duy thông thường và khi đã đạt mức độ này thì làm việc gì cũng thấy thoải mái.

@tuandinh, lỡ tui phán đoán sai tui tạ lỗi lại 3 chai. He he.

Đơn giản hơn cách nghĩ của mọi người mình chỉ nghĩ như sau:
Vấn đề này là một cái Risk và việc xử lý nó phải được tuân theo Risk Management (trong 27001 gọi là Risk Treatment Plan).
Bản thân nó CHƯA gây ra incident và nó không phải là một incident để mà giải quyết.

Phân tích quá trình từ Risk ---> Incident

Với programmer: quan tâm đến việc xử lý cái risk.
Với hacker: quan tâm đến việc risk có khả năng chuyển thành incident hay không và đánh giá và kiểm soát nó. Risk matrix lúc này cực kỳ quan trọng.
Với project manager: quan tâm việc xảy ra incident sẽ tốn của họ bao nhiêu tiền.

Bản chất có những cái risk sau khi đã có biện pháp control thích hợp thì xác suất xảy ra incident là thấp. Cũng có những cái risk có khả năng xảy ra incident cao nhưng vì nguồn lực (tiền bạc, thời gian, con người) không đủ nên đành phải chấp nhận nó. Không hẳn trường hợp nào cũng phải nhảy thẳng vào fix.

Tưởng tượng nếu hệ thống quân sự Mỹ có risk bị tấn công từ bên ngoài mà các nghị sỹ đều đòi fix thì nguy to!!!

@tmd góp ý là góp ý, chẳng ai phê phán được góp ý nào là không chuyên nghiệp cả. smilie

@anh conmale không biết có cóp của ai không mà casestudy hay thiệt. He he. Em ra Hoa Viên làm vài ly, ngắm cha Kanishka dẫn nguyên team IBM đi nhậu smilie

về tới nhà mới hiểu ra ý đồ của anh.
@Mọi người: tham gia thảo luận các kỹ năng lão conmale đưa ra là đang tìm hiểu và xây dựng hệ thống an toàn thông tin. Nếu link tới topic kỹ năng khác là thấy ngay. Rõ ràng mọi người vẫn bị "lún" vào kỹ thuật.

conmale wrote:

Có một "case study" nho nhỏ để đánh giá tinh thần hacker qua một mẩu chuyện.

Trong một buổi họp, giám đốc kỹ thuật đưa ra một vấn đề như sau:

Vừa qua, trong quá trình thực hiện penetration test hàng năm cho hệ thống khảo giá của chúng ta, một số lỗi nghiêm trọng được tìm thấy trong cơ chế xác thực danh tính và gán quyền cho tài khoản. Những lỗi bảo mật này đã được cảnh báo đến công ty cung cấp phần mềm. Tuy nhiên, sau khi nghiên cứu, họ cho biết họ không thể giúp được gì vì cách khai triển đi ra ngoài giới hạn và đề nghị của họ. Nếu muốn họ giúp, cơ chế này phải được thay đổi theo thiết kế họ đưa ra và chi phí của việc làm này sẽ không nhỏ. Trở ngại lớn nhất ở đây là vấn đề thời gian vì tháng sau công ty phải ra mắt một sản phẩm mới trên hệ thống khảo giá. Quy trình thay đổi và kiểm nghiệm cơ chế xác thực danh tính và gán quyền này cần ít nhất là hai tháng để thực hiện và không có cách gì rút ngắn lại được bởi vì nó đòi hỏi phải điều chỉnh lại mã nguồn và thiết kế lại cơ sở hạ tầng liên quan đến cơ chế này.

Hãy hình dung xem,
- Một người có tinh thần là một "hacker" sẽ có đề nghị và giải pháp như thế nào?
- Một người có tinh thần là một "programmer" sẽ có đề nghị và giải pháp ra làm sao?
- Một người có tinh thần là một "project manager" sẽ có đề nghị và giải pháp như thế nào?

@huyannet
Về tìm hiểu rookit của LeVuHoang đề cập là cái gì đã trước khi phán xanh rờn.
@tmd
Xem cái post đầu tiên của tui trong cái thread này.

@tmd đang phát ốm vì con virus smilie

@tuandinh lão phu đã thách đấu với các hạ môn tuý quyền rồi đó nhe.

H3x4 wrote:

Hacker cũng giống như security, là một con đường chứ không phải là một cái đích, mục đích em viết bài này ở đây giống như là nêu ra những "người thầy" đại diện, bởi vì không phải ai cũng biết được nên làm gì và sẽ phải làm gì, cho nên em nghĩ đúng như người ta nói:
look to the master, follow the master, walk with the master, see through the master, become the master.Đối với người bắt đầu nên chọn cho mình một "người thầy", người thầy ở đây không phải là một cá nhân cụ thể, mà là một hình tượng, một phong cách, một tinh thần làm việc đúng đắn, ví dụ như hầu hết hình tượng của các bạn muốn trở thành "hacker" là những người chuyên deface, hack web với tinh thần và mục đích nổi tiếng và được phong là "hacker", tuy không cụ thể là ai nhưng rõ ràng các bạn cũng đang có một "master". Vì thế chuyện chọn một người thầy là hết sức quan trọng.

===>

Che Guevara wrote:

"Hạnh phúc không phải là cảm giác tới đích mà là trên từng chặng đường đi."