2008年3月29日星期六

CISA&CISSP Case Study 2

  最中意唧Role Play又來啦!這次又是做給人Audit的那個,還好有個Partner在,不是的話還真的很難過。
  這次有4個Role:Auditor & Audit Manger VS IT Manager & IT Technician。而主題是這樣子的,有一間公司,它超過500個的員工,15種應用軟件系統。每半年就會有一次外部審計,審計委員會就由審計員(Auditor)與審計經理(Audit Manger)組成,由他們來對這個IT部門的經理與技術人員來對2個范疇來進行審計。
  這一次我的角色是IT部門經理,技術人員則是同學S,同學S和我也是剛結束的MCSE的同學,所以比較有默契,配合得也蠻好的,上次Case Study也是同一組的。
  而我的角色在這次審計中需要負責以下工作:(不翻譯了)
  Maintain operational procedure to ensure the smooth operation of IT.
  (01). Discuss with your staff on the User Account Administration procedure
  (02). Participate in the Audit Opening Meeting
  (03). In the audit process, meeting with the auditor
  (04). Try to stop your technical staff to describe the user account administration procedure to the auditor due to you want to minimize mis-understanding between parties
  (05). Write down the requests from the auditor and try to fulfill the requirement if it is reasonable
  (06). The auditor finds out 1 staff has left the company but the account still exist
  (07). Discuss with your technical staff to find out the root cause
  (08). Explain the reason
  (09). Provide future remedy actions
  (10). Participate in the Audit Closing Meeting

  在這里主要是針對User Acount那里出了問題之后,解說給審計員聽,發生問題的原因,涉及的部門以及解決的方法。另外一個范疇則是會在Meeting中由審計員說出,這個是由他們自由發揮的命題。我們主要的任務就是要想出整個故事出來,讓審計員滿意我們解決問題的方式。

  2個人聊了幾分鐘之后,基本上就把這個問題的責任推向了HR部門,哈哈哈。最主要且最重要的是公司已經定了Security Policy去執行相關的步驟,如果連這點也沒有就什么也別吹了。然后假設離職員工在27日正式離職,我們IT部門在29日,也就是在今天早上才收到書面通知,也由於同學S工作繁忙沒來得及停掉該Account,所以才出現Security方面的空隙。解決與補救的方法就是,要與HR部門加強溝通,并要求HR在收到離職信的同時,或者通知離職之前,要及早通知IT部門,而我們會與該部門主管聯系,看是否需要對其工作權限進行限制或者暫停Account。以上只是2人商討的結論,接下來就開始要“對付”審計委員會了。

  哼哼哈哈笑臉迎人,這大概就是對著審計員時候的標準表情了。開始的時候,由我們的審計員K長篇大論地講著這次審計的目的與標準了,心里想著如何如何去回答,也沒多少聽進去。殊不知,他們并沒有就離職員工Account仍然存在的問題進行挑戰,也不知道為什么了,這應該是必要的挑戰題,看來是私底下換了其他的。他們其中的一個問題也是關于Account管理的,另外一個是軟件更改管理。問答如下:
  (1). 說一說建立與刪除Account的流程。
    答:收到HR部門的通知,有新人入職需新增一個Account,再經由新人之部門主管通知IT部門該新人所需的工作權限。刪除則也是一樣,需要HR通知,與職員部門的主管Approve,然后再進行刪除或者暫停使用。
  (2). 新增或者刪除后,有沒有去做確認,例如新人得到的權限是否正確,離職員工的Account是否已經刪除或者停用。
    答:由於人手不足,沒有去做確認。(沒有想到還要做確認,死掉一條)
    再問:什么時候可以改正。
    答:如果正式由上頭通知要做確認,一個月內可以正式實施。
  (3). 新Account的密碼如何給該用戶呢?(@@ 很多陷阱)
    答:發一個加密的郵件給該員工的主管,由該主管拿給員工。該員工在首次登入后必須更改密碼,才能順利登入。
  (4). 密碼的設置如何
    答:至少8位密碼,由英文大小寫、數字和符號組成。
  (5). 密碼沒有設置定期修改嗎?例如3個月更改一次。登入失敗次數的限制又如何呢?
    答:都沒有設置。(又中招了,假定了自己是小公司)
  (6). 軟件修改更新的流程又是如何呢?
    答:對用戶提供的問題進行測試,確定需要修改。修改之后發布之前會對系統進行并行測試(Pararell Test),并由用戶書面確認問題已改正,然后正式發布更新。
  (7). 誰進行確認,誰進行修改與發布呢?
    答:由IT經理進行問題確認與發布確認,由技術人員進行修改,2個人同時進行發布的時候,IT經理會進行指導。(還是小公司思想,應回答重大的更新,應該由更高的管理層批準)
  (8). 如果技術人員很多工作,無法兼任所有修改工作,IT經理會幫忙嗎?
    答:會。(又死掉一條,這個是Segregation of Duties的問題)

  最后Audit那邊提出了結論
  (1). Account的新增、修改及刪除都要進行Double Check。
  (2). 密碼方面要加強,8位密碼不夠,要至少3個月更換,登入失敗的次數要限定,超過要鎖Account,然后要IT部門來開啟。
  (3). 密碼需要直接交與員工,而不是主管。(這個我有保留,下次問導師)
  (4). 重大的軟件更新發布要經過更高的管理層同意確認。
  (5). 軟件的修改以及確認,在責任上要分開,由不同人負責。這里有抵觸。

  導師在聽完也給了些意見,首先公司里面一共有15個應用軟件系統,并不是每個軟件系統都支援Window的AD功能,如果要用戶每3個月修改一次密碼,這可真的是很麻煩的,不說15個了,就算是5個也夠讓你受的了。

  雖然都不是一些重大的失誤,但是小公司思想始終縈繞在我的腦中,在IT Security方面應該是從大公司方面去想,能做到IT Audit的都應該是些上市的大公司,這一方面是十分注重的。以后要思考多一點了。

沒有留言: