Để trở thành hacker - .:: HVAOnline ::.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận việc định hướng

Để trở thành hacker

[Guidance] Để trở thành hacker	02/08/2010 21:46:30 (+0700) \| #61 \| 217380

khuecoi94
Member

Joined: 20/02/2010 03:16:39
Messages: 72
Location: C:\RECYCLER
Offline

đáp án của câu này thì bạn cứ chọn bừa đi,không thì chờ thêm 1 thời gian nữa chờ bác Conmale quên trả lời smilie

Mình đúng là 1 thằng Vô Tích Sự
--------- Con đường lớn ------
...........oooo0.............
...... .....(.....)....0oooo..
...... ......\...(......(.....)....
...... .......\._)......

[Guidance] Để trở thành hacker	02/08/2010 21:58:34 (+0700) \| #62 \| 217381

tuandinh
HVA Friend

Joined: 05/09/2002 12:44:34
Messages: 210
Location: Thiên đường tình ái
Offline

louisnguyen27 wrote:

Em ra Hoa Viên làm vài ly, ngắm cha Kanishka dẫn nguyên team IBM đi nhậu về tới nhà mới hiểu ra ý đồ của anh.

Mình kính đề nghị Louisnguyen27 xử lý case study này trên tinh thần ISO27001 cho mình mở mang tầm mắt tí smilie

. Lần tỉ thí Tuý quyền trên đỉnh Ngũ Hành vào tháng sau mình nhất định uống trước 3 chén gọi là đa tạ :X

[Guidance] Để trở thành hacker	02/08/2010 22:08:35 (+0700) \| #63 \| 217383

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

Tình huống conmale đặt ra thật hóc búa nhưng cũng là cơ hội cho cả 3 vai trò hacker, programmer và project manager (PM) hợp tác chặt chẽ với nhau hơn.

Đối với programmer nếu không có bản thiết kế và mã nguồn thì đề nghị của họ chỉ dừng ở mức hỗ trợ cho hacker/PM khi cần như bên dưới.

Với PM, thường họ sẽ nghĩ đến 1 vài giải pháp:
- Dời thời gian ra sản phẩm mới. Điều này tuỳ, nhưng khó xảy ra vì những lý do bên dưới. Về lâu dài giải pháp này cũng có lợi vì đủ thời gian sửa và kiểm lỗi hệ thống, giúp tiết kiệm chi phí về sau.
- Cùng cấp trên thương lượng với nhà cung cấp rút ngắn thời gian sửa lỗi, chịu chi phí cao khi mà thời gian ra sản phẩm mới là không thể kéo dài hơn. Vì để ra được sản phẩm mới người ta đã trải qua một kế hoạch dài hạn có lịch trình rõ ràng, giới thiệu đến khách hàng và tốn kém chi phí nên khó thay đổi được. Như vậy sẽ phải chấp nhận chi phí fix bằng mọi giá, đồng thời cũng chấp nhận rủi ro cao vì ko còn đủ thời gian kiểm tra.

- Xây dựng hệ thống đề phòng, theo dõi và khắc phục sự cố nhanh nhất có thể đề giảm thiểu khả năng down hệ thống. Thậm chí huy động thêm nhân lực vào công tác này, theo dõi 24/7. Hệ thống này có thể được xây dựng nhanh trong vòng dưới 1 tháng.
- Hợp tác với hacker và programmer xây dựng một hệ thống xác thực bổ sung và điều chỉnh cho các request từ người dùng sang hệ thống này trước, rồi mới đến hệ thống xác thực hiện có. Hoặc thêm một lớp validation dưới database. Hệ thống này có thể được xây dựng nhanh trong vòng dưới 1 tháng với nhân lực hiện có.

Với hacker, 2 giải pháp có thể được đưa ra khi họ không thể có mã nguồn:
- Xây dựng thêm các tầng (lớp) phòng thủ hỗ trợ hệ thống hiện có, bằng hardware hay software. Việc này sẽ cần kết hợp với programmer và sự hỗ trợ về mặt nhân sự, quản lý.. của PM.
- Reverse engineering hệ thống hiện có, nhưng có vẻ giải pháp này ít khả thi nhất vì những hạn chế về thời gian, thoả thuận bản quyền, cách thức sử dụng phần mềm...

Hibernating

[Guidance] Để trở thành hacker	02/08/2010 23:17:31 (+0700) \| #64 \| 217397

louisnguyen27
Member

Joined: 12/08/2008 18:04:41
Messages: 321
Offline

@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!!!

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!

[Guidance] Để trở thành hacker	02/08/2010 23:32:12 (+0700) \| #65 \| 217399

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

Trên thực tế tui thấy project manager và các cấp cao hơn tham gia nhiều vào Risk Management hơn là anh em programmer hay hacker, những người làm công việc đặc thù nào đó trong việc trên. Đúng là cần có sự cân bằng khi chọn lựa giải pháp xử lý. Khi chi phí bỏ ra để khắc phục risk cao vượt mức cho phép, thì có thể chấp nhận (hoặc transfer) risk nếu nó không quá ảnh hưởng đến hoạt động, việc kinh doanh và hình ảnh của tổ chức.

Hibernating

[Guidance] Để trở thành hacker	03/08/2010 06:59:57 (+0700) \| #66 \| 217415

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Cho đến thời điểm này, phản hồi của z0rr0 và mrro là đậm tinh thần "hacker" nhất. Trong đó, mrro thể hiện tính chất "run free" của hacker và z0rr0 thể hiện tính cẩn thận của một người làm công tác quản lý (project manager). Cả hai đều đề cập đến giải pháp "RE" smilie

. Tiếp theo, phản hồi của tmd và phanledaivuong lại nghiêng hẳn về phía "sysadmin". Phản hồi của H3x4 mang tính thăm dò hơn là thể hiện quan điểm một cách rốt ráo. Jino thì có cố gắng đưa ý kiến nhưng chưa rõ nét nên không xác định được.

- Phản hồi của mrro thể hiện kinh nghiệm thực tế xuyên qua đúc kết: security = prevention + detection + response và phân tích hạn chế của thói quen chỉ tập trung vào prevention. mrro thể hiện mentality của một thinker + doer ở mức độ agressive (đề nghị hack và re). mrro không thể hiện rõ khía cạnh và tính chất của một project manager.

- Phản hồi của z0rr0 thể hiện kinh nghiệm thực tế xuyên qua những cân nhắc lợi hại về yếu tố thời gian và nhân lực. Đây là biểu hiện đặc thù của người làm công tác quản lý. Khía cạnh "hacker" của z0rr0 ít aggressive như mrro, thậm chí biểu hiện rõ sự cân nhắc nhưng tinh thần "hacker" vẫn tồn tại trong z0rr0 (cái này có lẽ đã ăn sâu vào... máu rồi smilie

). Có lẽ đây là một biểu hiện của tuổi tác và kinh nghiệm công việc. z0rr0 thể hiện mentality của một planner.

- Phản hồi của tmd và phanledaivuong thể hiện kinh nghiệm thực tế xuyên qua việc quản lý hệ thống. Đây có lẽ là dạng thể hiện thường gặp nhất. Cả tmd và phanledaivuong đều đưa ra ngay giải pháp ở cấp độ quản lý. Đây là mentality của doer.

- Phản hồi của H3x4 tương tự như tmd và phanledaivuong. Cả ba phản hồi của tmd, phanledaivuong và H3x4 ít hàm chứa tinh thần "hacker" nhưng mang nặng tinh thần "protector". Trong ba người, tmd thể hiện tinh thần "hacker" cao nhất (vì tmd đề cập đến tính chất "trong cả quả trình 1 tháng đầu, họ cố gắng tìm hiểu các hoàn cảnh xãy ra lỗi").

Xét trên mặt thực tế, case study có 3 dạng "mentality" đặc thù nhất (tất nhiên mỗi người phản hồi đều có một chút này, một chút kia nhưng tính chất nào thể hiện rõ nhất thì mentality của người ấy nghiên hẳn về tính chất ấy):
1. Tinh thần "hacker": luôn luôn dùng cơ hội để tiếp tục khai phá, tìm tòi và đào sâu những biến đổi (variations) của lỗi đã được công bố. Các giải pháp đưa ra thường dứt khoát và ít quan tâm đến yếu tố thời gian + nhân sự. Hầu như không quan tâm đến vấn đề pháp lý và tiền bạc. Thay vào đó là những đề nghị nặng tính kỹ thuật, thậm chí đi đến chỗ vi phạm bản quyền (miễn sao giải quyết được vấn đề).

2. Tinh thần "programmer": luôn nghĩ đến và thể hiện ở khía cạnh coding và quy trình diễn tiến xảy ra lỗi. Tinh thần của họ rất nặng tính chất "systematic". Họ có thể chú trọng một phần đến yếu tố thời gian và nhân sự nhưng điều họ quan tâm nhất là làm sao có giải pháp lâu dài hơn là ngắn hạn.

3. Tinh thần "project manager": luôn đặt nặng những khía cạnh lợi hại về thời gian, nhân sự và tiền bạc bởi vì đây là những yếu tố hàng đầu đối với họ. Ngay lặp tức, họ hình thành chiến thuật tiến hành thay vì chi tiết kỹ thuật.

@ louisnguyen27: case study này là một trong những case "real life" trong công việc của anh. Tất cả đều là đồ xịn chính hiệu con nai vàng chớ chẳng "cóp" của ai hết. Phân tích của em trên bình diện risk vs incident rất hay cho thảo luận này. Risk thuộc biên độ "problem management". Trong khi đó "incident" thuộc biên độ "incident management". Risk là hiểm hoạ có thể xảy ra (nhưng chưa xảy ra) và Incident là hiểm hoạ đã xảy ra. Bởi thế, tài nguyên và định hướng quản lý hai mảng ấy rất khác nhau. "Problem space" có thể tiến sát đến "incident space" nếu như thẩm định (nhiều cách) cho thấy incident rất có thể sẽ xảy ra trong thời gian rất ngắn và khi "Problem space" di chuyển về hướng gần hơn với "incident space", tài nguyên, nhân lực và tiền bạc dành cho việc khắc phục sẽ thay đổi. Tất nhiên, đối với ban giám đốc mọi thiệt hại đều được quy về đồng tiền và uy tín (cũng có thể quy ra tiền). Bởi thế, tài nguyên, nhân lực và tiền bạc sẽ được điều chỉnh để khắc phục sự cố.

Case study trên không dùng để đánh giá khả năng kỹ thuật của từng cá nhân mà chỉ để xếp loại "dạng tinh thần" của từng cá nhân khi đối diện với problem nhằm minh hoạ cụ thể hơn cái gọi là "tinh thần hacker" smilie

What bringing us together is stronger than what pulling us apart.

[Guidance] Để trở thành hacker	03/08/2010 08:33:45 (+0700) \| #67 \| 217433

khuecoi94
Member

Joined: 20/02/2010 03:16:39
Messages: 72
Location: C:\RECYCLER
Offline

1 case study tuyệt vời với những góp ý những phân tích định hướng về tinh thần " hacker,programmer và projecht manager.
Em xin phép copy bài này về đọc thêm. smilie

[Guidance] Để trở thành hacker	03/08/2010 08:45:41 (+0700) \| #68 \| 217434

tuthanhp
Member

Joined: 30/07/2010 05:45:37
Messages: 4
Offline

hê. Theo em nghĩ trở thành hacker cần có thời gian và quyết tâm là đủ rùi. còn kinh phí thì cần 1 cái mày tình là xong thui, nếu ai làm việc văn phòng thì càng có điều kiện. chỉ học để nâng cao kiến thức thui chứ kiếm tiền ỏ VN thì hơi khó

[Guidance] Để trở thành hacker	03/08/2010 08:51:48 (+0700) \| #69 \| 217436

khuecoi94
Member

Joined: 20/02/2010 03:16:39
Messages: 72
Location: C:\RECYCLER
Offline

tuthanhp wrote:

hê. Theo em nghĩ trở thành hacker cần có thời gian và quyết tâm là đủ rùi. còn kinh phí thì cần 1 cái mày tình là xong thui, nếu ai làm việc văn phòng thì càng có điều kiện. chỉ học để nâng cao kiến thức thui chứ kiếm tiền ỏ VN thì hơi khó

1 cái máy tính sao mà đủ được hả bạn smilie

,làm việc ở văn phòng mà làm việc riêng như bạn nói mà bị ông sếp phát hiện mà không bị sút ra khỏi công ty à.

[Guidance] Để trở thành hacker	03/08/2010 09:12:00 (+0700) \| #70 \| 217446

kcytuanhoang
Member

Joined: 02/08/2010 16:56:49
Messages: 3
Offline

con đường để trở thành hacker thật gian nan và vất vả
dù chưa biết nhiều về ngành IT
chỉ đang trong quá trình học tập và tìm hiểu
nhưng có lẽ một thời gian nữa sẽ cố gắng tu bổ thêm ^^

[Guidance] Để trở thành hacker	03/08/2010 09:28:02 (+0700) \| #71 \| 217457

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Nếu đề thi ra những câu như thế này thì thật tuyệt.

Về khía cạnh xử lý lỗi, em nghĩ bài viết này của mrro http://vnhacker.blogspot.com/2008/07/khng-phi-c-c-li-l-v.html một vài ý trong đó nêu ra được hướng giải quyết vấn đề anh conmale đưa ra. Vấn đề xử lý lỗi cho một hệ thống lớn hoạt động kinh doanh .

[Guidance] Để trở thành hacker	03/08/2010 09:32:29 (+0700) \| #72 \| 217458

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

kcytuanhoang wrote:

con đường để trở thành hacker thật gian nan và vất vả
dù chưa biết nhiều về ngành IT
chỉ đang trong quá trình học tập và tìm hiểu
nhưng có lẽ một thời gian nữa sẽ cố gắng tu bổ thêm ^^

Con đường nào mà chẳng vất vả gian nan. Những người thành công đều được trui rèn từ những khó khăn trở ngại. Có câu nói rất hay rằng "Đừng bao giờ để đến ngày mai những gì bạn có thể làm hôm nay - Never put off till tomorrow what you can do today", mỗi ngày là một cơ hội nên đừng bỏ phí nó.

Hibernating

[Guidance] Để trở thành hacker	03/08/2010 09:41:12 (+0700) \| #73 \| 217460

H3x4
Member

Joined: 02/04/2009 00:03:16
Messages: 242
Offline

Em không muốn spam nhưng mà thôi cũng spam bài này vậy, câu hỏi và câu trả lời của anh conmale quả là quá sức tưởng tượng. Nhìn vào từng câu trả lời mà có thể thấy được tuổi đời và tuổi nghề của từng người, mức kinh nghiệm ra sao và cách suy nghĩ cũng như điểm mạnh và điểm yếu. Thêm vào đó còn biết được người trong cuộc và ngoài cuộc sẽ nhìn nhận khác nhau như thế nào ( qua câu trả lời của anh louisnguyen27).

Nhờ anh conmale và mọi người mà em tiết kiệm được một lượng thời gian không nhỏ để có thể nhận ra những điều này. Hòn đá có bị nước mài mòn thì hòn đá mới không còn sần sùi nữa, cám ơn mọi người nhiều. Hi vọng sẽ tiếp tục nhận được những bài học bổ ích như vậy.

@conmale: anh còn câu hỏi nào khác như vậy không smilie

@all: nợ các anh 1 trận tuý quyền smilie

)

[Guidance] Để trở thành hacker	03/08/2010 10:05:02 (+0700) \| #74 \| 217465

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

H3x4 wrote:

Em không muốn spam nhưng mà thôi cũng spam bài này vậy, câu hỏi và câu trả lời của anh conmale quả là quá sức tưởng tượng. Nhìn vào từng câu trả lời mà có thể thấy được tuổi đời và tuổi nghề của từng người, mức kinh nghiệm ra sao và cách suy nghĩ cũng như điểm mạnh và điểm yếu. Thêm vào đó còn biết được người trong cuộc và ngoài cuộc sẽ nhìn nhận khác nhau như thế nào ( qua câu trả lời của anh louisnguyen27).

Nhờ anh conmale và mọi người mà em tiết kiệm được một lượng thời gian không nhỏ để có thể nhận ra những điều này. Hòn đá có bị nước mài mòn thì hòn đá mới không còn sần sùi nữa, cám ơn mọi người nhiều. Hi vọng sẽ tiếp tục nhận được những bài học bổ ích như vậy.

@conmale: anh còn câu hỏi nào khác như vậy không
@all: nợ các anh 1 trận tuý quyền )

Trong chương trình thi CISSP (và tương tự) có cả một "domain" hẳn hòi về "risk management". Tuy nhiên, nếu đọc suông thì mấy thứ này rất... khô và khó nuốt. "Risk management" là một đề tài không thể thiếu cho chuyên gia bảo mật (và cả dân chuyên exploit, nếu nhìn ở góc độ ngược lại). Tuy vậy, đây là đề tài ít người thật sự quan tâm vì nó không nặng tính kỹ thuật theo kiểu "get my hand dirty with real stuffs". Đứng trên bình diện bảo mật, người làm công tác bảo mật cần hiểu rõ hiểm hoạ dựa trên mặt vật chất để có thể lượng định những giải pháp cho thích hợp. Ngược lại, đứng trên bình diện tấn công, kẻ tấn công nếu nắm rõ độ dung hại thì họ càng nguy hiểm hơn những kẻ tấn công chỉ chuyên chú khía cạnh kỹ thuật. Đó là "vẻ đẹp" của hai mặt của vấn đề smilie

.

Đôi khi làm việc trong lãnh vực bảo mật và CNTT nói chung, nếu không muốn mãi "làm thợ" thì rất nên khai phá những góc độ như đã thảo luận trong chủ đề này.

@ H3x4: còn nhiều lắm. Chỉ sợ em "chán" thôi smilie

What bringing us together is stronger than what pulling us apart.

[Guidance] Để trở thành hacker	03/08/2010 10:11:07 (+0700) \| #75 \| 217466

louisnguyen27
Member

Joined: 12/08/2008 18:04:41
Messages: 321
Offline

@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.

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!

[Guidance] Để trở thành hacker	03/08/2010 10:26:53 (+0700) \| #76 \| 217468

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

có ai có câu trả lời khác ko? ko thì mình trả lời =]

Cánh chym không mỏi
lol

[Guidance] Để trở thành hacker	03/08/2010 12:36:42 (+0700) \| #77 \| 217479

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

@louisnguyen27: Tất nhiên trong qui trình làm việc đều phân trách nhiệm rõ ràng. Vấn đề mình gặp thực tế ở doanh nghiệp làm phần mềm (lưu ý không phải chuyên lĩnh vực security) là mặc dù cty phần mềm có risk management trong qui trình đàng hoàng nhưng vướng một số thứ:
- Cấp trên không tham gia nhiều trong việc hoạch định, theo dõi, giám sát. Đặc biệt ở thời điểm khủng hoảng kinh tế, họ phải lo chạy kiếm khách hàng, lo lắng lời lỗ cũng hụt hơi rồi.
- Không có đủ chi phí đầu tư trọn vẹn vào risk management, đặc biệt ở khâu quan trọng như mitigation và evaluation để có thể phát triển và dùng lại về sau. Đôi khi chỉ dừng lại ở mức analysis và hiệu chỉnh thiết kế, mã để khắc phục nhanh rồi khách hàng lại hối làm việc khác quan trọng hơn.
- Không đủ nhân lực và trình độ về security để tham gia và duy trì. Một người có khi phải ôm đồm mọi việc. Như các bạn biết, tuyển một người đam mê và hiểu biết về network/software security không dễ chút nào ở các cty chỉ chuyên gia công phần mềm.
- Khách hàng không thật sự cần một qui trình phức tạp như vậy, tốn kém tiền bạc và thời gian. Vì mình không cung cấp miễn phí, tất cả thời gian dành cho dự án đều tính tiền, do vậy chỉ áp dụng một cách tinh giản và hiệu chỉnh cho phù hợp dự án/khách hàng cụ thể.

Nói chung, risk management để thực hiện đúng không đơn giản chút nào, cần sự hỗ trợ nhiều phía, kiến thức, quyết tâm và thời gian thực hiện.

@gamma95: Xin lỗi vì ngắt ngang, giờ nhường lời lại cho em smilie

Hibernating

[Guidance] Để trở thành hacker	03/08/2010 13:21:24 (+0700) \| #78 \| 217483

vikjava
Elite Member

Joined: 28/06/2004 02:32:38
Messages: 926
Location: NQN
Offline

Hi anh conmale. Đối với trường hợp trên thì anh và cty anh xử lý thế nào smilie

[Guidance] Để trở thành hacker	03/08/2010 14:05:13 (+0700) \| #79 \| 217485

louisnguyen27
Member

Joined: 12/08/2008 18:04:41
Messages: 321
Offline

@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

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!

[Guidance] Để trở thành hacker	03/08/2010 14:22:16 (+0700) \| #80 \| 217487

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

louisnguyen27 wrote:

@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?

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.

Hibernating

[Guidance] Để trở thành hacker	03/08/2010 15:10:25 (+0700) \| #81 \| 217490

tranvanminh
HVA Friend

Joined: 04/06/2003 06:36:35
Messages: 516
Location: West coast
Offline

louisnguyen27 wrote:

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.

Cái câu này louisnguyen27 y chang trong Manual của ISMS .

Mình thấy những điều khoản ISMS bắt mình làm thì rất nhiều nhưng không có tác dụng bao nhiêu, ví dụ như làm cái luật không cho dùng USB nhưng lại không cấm dùng Yahoo Messenger hoặc webmail thì cũng vậy . Mình lấy ISMS xong mới thấy , thật tế ra cái ISMS giống như 1 đống luật thôi, nên theo mình, ISMS chỉ đóng vài trò tạo bộ luật cho đối tượng vận hành nó, quan trọng hơn hết vẫn là ỳ thức bảo mật của từng con người trong tổ chức có chịu thực hiện theo bộ luật hay không .

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.

Cái này mình đọc cũng thấy đúng đúng, nhưng nếu nói theo "tiêu chí" ISMS mình cảm thấy có thể hơi bị lệch . Vì Risk hay Incident gì thì cũng nên giải quyết tổng quát chứ không phân chia ra cho từng lớp để giải quyết theo từng quá trình riêng . 3 vài trò này chỉ chú ý đến 1 bài toán của họ rồi tự ý làm riêng thì theo mình đó là tâm lý chứ không phải tiêu chí (hoặc là mục tiêu) của ISMS . (Loại trừ những việc mang tính chuyên môn quá cao.)

Nếu theo tiêu chí vận hành ISMS thì tại đây, Programmer - Hacker - Project Manager đều phải tham gia vào hết quá trình xử lý, kiểm soát, đánh giá để đưa ra kêt luận giải quyết vấn đề dựa trên bộ luật vận hành .

Bởi vậy nếu theo ISMS (của công ty mình) thì Risk Management thì ai cũng tham gia thì mới có ý nghĩa . Còn cái về kinh doanh, tài chính, chiến lược abc thì đúng là phải hạn chế chỉ trong 1 số người .

[Guidance] Để trở thành hacker	03/08/2010 15:13:33 (+0700) \| #82 \| 217491

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

vikjava wrote:

Hi anh conmale. Đối với trường hợp trên thì anh và cty anh xử lý thế nào

Hì hì, đây là câu hỏi mang tính thực dụng nhất trong chủ đề này. smilie

. Chi tiết thế nào thì anh không thể bật mí 100% được nhưng tổng quát thì như thế này.

Sau khi xong cuộc họp, tay "Problem Manager" liền triệu tập một cuộc họp thứ nhì để hình thành một cái gọi là "collaboration team". Nhóm này bao gồm đại diện của tất cả các tầng kỹ thuật (như network, security, middleware, DBA, midrange, developers, testers...). Nhóm này được tạo ra nhằm mục đích hình thành một "white boarding session" (nhóm tập họp lại trong một phòng họp có bảng trắng) để đưa ra tất cả các giải pháp có thể nghĩ ra được.

Sau khi mười mấy "giải pháp" được đưa ra, từ ngớ ngẩn nhất (vì không đủ thời gian và tiền bạc để thực hiện) cho đến khả thi nhất được hình thành, tất cả thành viên của nhóm đi xuyên qua giai đoạn thẩm định (assessment) và cho điểm mỗi giải pháp (với thang điểm từ 1 đến 10 chẳng hạn với 1 là ít khả thi và 10 là khả thi nhất). Bốn giải pháp có điểm cao nhất được chọn ra để đi đến chỗ "cãi lộn" nhằm chọn ra hai giải pháp khả thi nhất cho ngắn hạn và dài hạn (nên nhớ, nhóm này toàn là những tay nắm vững các tầng kỹ thuật chớ không lơ tơ mơ).

Sau khi hình thành khung của giải pháp, nhóm bắt tay vô thực thi ngay. Bởi vì các thành viên của nhóm có quyền thay đổi và điều chỉnh ở khu vực kỹ thuật của mình nên cần thực thi ở bất cứ tầng nào cũng xảy ra nhanh chóng (chớ không còn chờ đợi được thực thi như hoàn cảnh bình thường nữa). Mỗi lần thực thi như vậy được xem là đi xuyên qua 1 "iteration" (1 vòng). Công ty anh áp dụng "agile principle" nên tất cả quy trình thảo luận và thực thi xảy ra rất nhanh. Thậm chí, kéo nhau vô phòng họp, mỗi đứa mang theo laptop của mình và thực hiện ngay tại chỗ các thay đổi (tất nhiên chỉ thực hiện trên hệ thống thử nghiệm chớ không phải trên hệ thống production đang hoạt động).

Problem Manager có trách nhiệm thu thập các ghi chú kỹ thuật của từng cá nhân trong nhóm để hình thành "action plan" cho production system sau này và mỗi cá nhân phải có trách nhiệm tự "take notes" và viết tài liệu chuyên biệt cho phạm vi của mình. Xuyên qua mỗi iteration, những thiếu sót hoặc những chi tiết chưa hoàn chỉnh phải được điều chỉnh cho hoàn chỉnh.

Kết quả, giải pháp được áp dụng vào hệ thống production trước thời hạn 1 tuần. Giải pháp ngắn hạn, rẻ tiền nhất và nhanh nhất đã được chọn là thay thế hai con IBM HTTP server chạy trên AIX bằng hai con RHEL 5.x chạy trên 2 virtual machine (vmware) và Apache 2.2.x được cài với mod_security để áp dụng cản lọc nhờ khả năng "transformation" của nó. Giải pháp dài hạn là coding lại application để tiếp nhận và kiểm soát giá trị của cookies / sessions một cách chặt chẽ trước khi "xi nhan" cơ chế authentication / authorisation cho phép xuất truy cập tiếp tục. Chi tiết kỹ thuật thì khá phức tạp bởi vì một application có thể có nhiều "context" và mỗi context trỏ đến một hệ thống khác nhau có chức năng và thông tin khác nhau. Để các hệ thống A, B, C, D.... đều bảo đảm user session X là có giá trị thì chúng phải thông tin và kiểm chứng với nhau dựa trên các điều kiện bảo mật cụ thể.

Điều cần nói ở đây là cách tổ chức và xử lý vấn đề của từng tổ chức doanh nghiệp có thể khác nhau. Nếu sự cố được đưa ra vẫn không khắc phục và kỳ hạn phải tung ra một sản phẩm mới không thể thay đổi được (vì nó quyết định thắng thua bạc triệu) thì bằng mọi cách phải khắc phục. Nếu không khắc phục mà một khách hàng nào bị "dính chấu" thì coi như sản phẩm và chiến dịch ấy hỏng bét. Uy tín của cty cũng trôi xuống sông, xuống biển. Việc hình thành một nhóm "response" để làm việc dedicated và liên tục trong 3 tuần là việc không đơn giản vì chi phí không nhỏ. Tuy nhiên, nếu xét thấy chi phí này chiếm một tỉ lệ không lớn so với doanh thu (theo dự tính) thì không có lý do gì mà không tiến hành hết.

What bringing us together is stronger than what pulling us apart.

[Guidance] Để trở thành hacker	03/08/2010 15:20:12 (+0700) \| #83 \| 217492

Bướm Đêm
Member

Joined: 25/03/2008 18:30:01
Messages: 223
Location: Phố Hoa
Offline

Xem những real-world solutions to real-world problems như này thích nhỉ smilie

GZ tqf zìeq ˘ऐ xखc sड़e cav xন qrqr

[Guidance] Để trở thành hacker	03/08/2010 15:22:21 (+0700) \| #84 \| 217493

louisnguyen27
Member

Joined: 12/08/2008 18:04:41
Messages: 321
Offline

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.

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!

[Guidance] Để trở thành hacker	03/08/2010 15:24:52 (+0700) \| #85 \| 217494

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

He he.... ISMS or not ISMS? smilie

Hãy thử hình dung "risk management" cho HVA, một forum không có lợi nhuận như thế nào xem? smilie

What bringing us together is stronger than what pulling us apart.

[Guidance] Để trở thành hacker	03/08/2010 15:36:36 (+0700) \| #86 \| 217495

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

Dùng agile có lẽ là cách phù hợp trong trường hợp này khi nó giúp hình thành rất nhanh giải pháp. Rõ ràng những người tham gia team đủ giỏi về kĩ thuật và khả năng làm việc nhóm, đặc biệt là leader của nhóm này, để có thể đưa ra quyết định nhanh chóng và chất lượng.

Ngoài ra, coi bộ application này được thiết kế và xây dựng rất tốt, có độ portability rất cao smilie

Hibernating

[Guidance] Để trở thành hacker	03/08/2010 15:51:04 (+0700) \| #87 \| 217497

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

louisnguyen27 wrote:

Xoá đi vì anh conmale trả lời rồi. Nhưng post lại vì lão spam thêm ở dướ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????
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.

Không rõ ý của louisnguyen27 lắm. Tuy nhiên bị rầy mà sinh ra code bậy là không được rồi smilie

ISMS qui định software engineer (hay nhân viên) ra vào cửa thế nào, sử dụng hardware/software/printer/network/etc ra sao, nếu vi phạm thì xử lý ra sao, vv.
CMM trong phát triển phần mềm nó bao gồm rất nhiều thành tố xuyên suốt chu trình sống của một phần mềm, risk management chỉ là 1 trong số đó.

Cả 2 ISMS và CMM đều giúp tổ chức làm việc hiệu quả hơn chứ không khẳng định chất lượng sản phẩm sẽ tốt hay an toàn hơn (tất nhiên làm ăn quy cũ thì khả năng cho ra sản phẩm chất lượng sẽ cao hơn).
Tuy nhiên qui trình có thể giúp hạn chế rủi ro sinh ra lỗi và chỉ ra đường hướng (ko phải kĩ thuật) để giải quyết. Còn cách giải quyết cụ thể thì lại phụ thuộc vào con người.

Hibernating

[Guidance] Để trở thành hacker	03/08/2010 16:07:25 (+0700) \| #88 \| 217501

louisnguyen27
Member

Joined: 12/08/2008 18:04:41
Messages: 321
Offline

@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.

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!

[Guidance] Để trở thành hacker	03/08/2010 16:23:02 (+0700) \| #89 \| 217503

Z0rr0
Q+WRtaW5pc3RyYXRvc+g

Joined: 14/08/2002 12:52:01
Messages: 1323
Location: Underground
Offline

@louisnguyen27: Chủ đề này hơi chệch hướng. Nếu tạo ra những chủ đề thảo luận về ISMS và Risk/threat management sẽ rất hay và học được nhiều điều smilie

Hibernating

[Guidance] Để trở thành hacker	04/08/2010 08:38:03 (+0700) \| #90 \| 217573

prof
Moderator

Joined: 23/11/2004 01:08:55
Messages: 205
Offline

Topic phát triển nhanh quá. Từ việc để trở thành hacker, sau đó chuyển sang "võ lâm chánh tông", rồi giờ thành.... ISMS smilie

. Có lẽ tại anh conmale mở rộng ghê quá, đôi khi là khá quá sức đối với một vài người :p.

Mình thấy ở topic nào có bạn louisnguyen27 tham gia, là ở đó rất dễ bị ISMS... hoá. Hi hi. Bạn louisnguyen27 có lẽ hoặc là đang "phải lòng" ISMS quá, hoặc đang nhận việc tư vấn về ISMS nên nắm mớ lý thuyết ISMS rất vững smilie

.

Cá nhân mình thấy ISMS, CMM, hay bất kỳ mô hình nào khác, cũng khó có thể gọi là thành công thực sự, hay nói cách "văn vẻ" là đi-vào-đời-sống-quần-chúng doanh nghiệp, nếu như: các nhân sự tham gia vận hành mô hình không có nhận thức tốt & chuyên nghiệp, không nhận được hỗ trợ tốt từ quản lý cấp cao nhất, và không có kiến thức chuyên môn tốt.

Btw, mình thích câu này: lý luận mà không gắn với thực tiễn là lý luận suông.

Cuối cùng, để trở thành hacker, hay để thế giới, cộng đồng công nhận mình là một hacker thực thụ, có lẽ nên có một kế hoạch định hướng học tập & làm việc dài hơi + sự đam mê không ngừng nghỉ smilie

Go to:

Users currently in here
2 Anonymous