安全的系統(tǒng)發(fā)展生命周期SSDLC介紹

安全的系統(tǒng)發(fā)展生命周期(SSDLC)介紹1.

基礎(chǔ)概念2.

安全需求3.

設(shè)計階段4.

開發(fā)階段5.

測試階段6.

布署與維運階段大綱01向有權(quán)訪問該程序的人員或程序公開信息02確保系統(tǒng)以不受損害的方式執(zhí)行其預(yù)期功能

.

而無需故意或由于疏忽而對系統(tǒng)進(jìn)行未經(jīng)授權(quán)的操作.03確保系統(tǒng)迅速運行

.并且不會拒絕授權(quán)用戶

的服務(wù)機密性完整性可用性信息系統(tǒng)安全SecureSoftware

Development

LifeCycleprocesses安全需求審查安全設(shè)計審查滲透測試源碼審查維

護(hù)部署運用需求定義測試設(shè)計開發(fā)McGraw’sSecureSoftware

DevelopmentLifeCycle

Process需求及使

用者案例系統(tǒng)架構(gòu)

及設(shè)計測試與測

試結(jié)果撰寫程序測試計劃反饋微軟SDLTeamSoftware

ProcessforSecureSoftware

DevelopmentAEGIS-Spiral-Model-of-Software-DevelopmentSecure-Software-Development-ModelPROCESS需求

設(shè)計

開發(fā)測試部署安全測試及源碼掃

描安全評估及設(shè)定威脅建模

及審查風(fēng)險評估靜態(tài)分析SSDLCSDLC設(shè)計準(zhǔn)則和安全的設(shè)計模式

識別可能的軟件威脅

審查活動錯誤和威脅識別

風(fēng)險分析威脅建?；顒有枨笠?guī)格書審查活動

安全需求規(guī)范語言

風(fēng)險分析使用安全資源

設(shè)定審查網(wǎng)絡(luò)設(shè)定審查Securityactivitiesforeach

phase安全的編譯語言選擇靜態(tài)分析源碼掃描執(zhí)行安全確認(rèn)需求資源設(shè)計ISO27034techniques—

Applicationsecurity采取流程方法，在應(yīng)用系統(tǒng)中指定、設(shè)計、開發(fā)、測試、實施和維護(hù)安全功能ISO/IEC27034-1:2011Overviewandconcepts和控制。應(yīng)用程序安全性不是作為應(yīng)用程序系統(tǒng)的安全狀態(tài)，而是「組織可以執(zhí)行一個過程，對其應(yīng)用程序應(yīng)用控制和測量，以管理使用它們的風(fēng)險」ISO/IEC27034-2:2015Organizationnormative

framework組織規(guī)范框架之間的結(jié)構(gòu)、關(guān)系和相互依存性-與應(yīng)用安全相關(guān)的策略、程序、角色和執(zhí)掌的架構(gòu)ISO/IEC27034-3:2018Applicationsecurity

managementprocess組織使用的每個特定應(yīng)用程序管理安全的整體流程ISO/IEC27034-4(DIS)Applicationsecurityvalidation申請安全驗證和認(rèn)證過程，以評估和比較申請系統(tǒng)的「信任水平」ISO/IEC27034-5:2017Protocolsandapplicationsecuritycontroldatastructure概述并解釋了ASC

的最小基本屬性，詳細(xì)說明應(yīng)用程序安全生命周期參考模型

（ASLCRM）

的活動和作用ISO/IECTS27034-5-1:2018Protocolsandapplicationsecuritycontroldatastructure,

XMLschemas定義XMLschemasISO/IEC27034-6:2016Casestudies如何開發(fā)和記錄的范例，定義在軟件開發(fā)過程中如何處理信息安全I(xiàn)SO/IEC27034-7:2018Assuranceprediction

framework提供對計算機程序安全安排的信任所需的保證的框架，例如當(dāng)一個程序（如應(yīng)用程式）依賴另一個程式（如資料庫管理系統(tǒng)、效用、作業(yè)系統(tǒng)或配套程式)

執(zhí)行關(guān)鍵安全功能（如使用者身份驗證、邏輯存取控制或加密）時，或當(dāng)組織更新或修補受信任的程式時ISO/IEC27034:2011

Informationtechnology—SecurityISO27034

ContNISTSP800-64

Revision2SecurityConsiderations

intheSystem

DevelopmentLife

Cycle初始階段在機密性、完整

性與可用性方面

初期劃分其業(yè)務(wù)

需求；針對傳輸、儲存

或建立的信息，確定其信息分類

并識別已知且需

特別處理的需求，

如個人識別信息；

確定任何的隱私

要求建置與評鑒階段系統(tǒng)將被安裝并

在該組織的營運

環(huán)境內(nèi)進(jìn)行評鑒。

主要的安全活動

包括：整合信息

系統(tǒng)納入其環(huán)境；

與安全控制測試

同步的計劃與實

行系統(tǒng)認(rèn)證活動；

完整的系統(tǒng)認(rèn)可

活動需求與獲取階段進(jìn)行風(fēng)險評鑒

，

并使用其結(jié)果來

補充安全控制的

基準(zhǔn)線；分析安全需求

；

執(zhí)行功能與安全

測試；準(zhǔn)備系統(tǒng)認(rèn)證與

認(rèn)可的初期文件；

設(shè)計安全架構(gòu)

.汰除階段確保系統(tǒng)的有序

終止，并保存有

關(guān)系統(tǒng)的重要資

訊，使一些或所

有的信息可以在

未來有必要的情

況下重新啟用

。

尤其是信息安全

議題相關(guān)的信息

與系統(tǒng)汰除應(yīng)該

被明確的處理

.操作與維

護(hù)階段系統(tǒng)應(yīng)到位(In-

place)并運行

、

增強和(或)修改

系統(tǒng)的開發(fā)與測

試，以及硬件和

(或)軟件的添加

或更換安全需求軟件安全需求類型需求萃取

方式資料分級來自軟件安全政策的需求軟件安全問卷誤用案例模型(Misuse

Case

Modeling)設(shè)計階段活動的反饋主體-物件矩陣(Subject

-

Object

Matrix)腦力激蕩靜置信息及相關(guān)具保護(hù)需求之機密資訊應(yīng)加密儲存資通系統(tǒng)如以密碼進(jìn)行鑒別時，該密碼應(yīng)加密或經(jīng)雜湊處理后儲存。電子票證應(yīng)用安全強度準(zhǔn)則電子支付機構(gòu)信息系統(tǒng)標(biāo)準(zhǔn)及安全控管作業(yè)基準(zhǔn)辦法軟件安全政策需求資通安全責(zé)任等級分級辦法TextFile機敏性資料資料內(nèi)容具機敏性，

如有泄漏將對組織造成危害，例如：

個人資料；合

約等資料僅限制經(jīng)

過授權(quán)人員使

用，

例如：僅

承辦人員可使

用

。資料內(nèi)容不可被公開僅供內(nèi)部使用，例如：

內(nèi)部作業(yè)信息資料可公開使

用，

例如：網(wǎng)

站內(nèi)容資料分級限制使用內(nèi)部使用公開軟件安全問卷誤用案例模型(MisuseCase

Modeling)物件1物件2檔案設(shè)備角色1read,write,execute,ownread,writeread,writewrite角色2read,writeread,write,execute,ownread,writeread角色3readread,write,readread角色4readread,write,executereadread主體-物件矩陣(Subject–Object

Matrix)腦力激蕩是最快也最非結(jié)構(gòu)化產(chǎn)生軟件安全需求的方式。

于此過程中，成員不需要闡述提出該軟件安全需求背后

的原因，而是持續(xù)的記錄所有成員想到的軟件安全需求。

雖然此快速產(chǎn)出軟件安全需求的方式相當(dāng)符合現(xiàn)今軟件

需要快速發(fā)展的環(huán)境有很高的可能性，提出的軟件安全需求并不直接與組織的商業(yè)決策需求或是軟件的技術(shù)背景、安全背景吻合。很容易有所遺漏，忽略某些重要的安全考量個人想法是相當(dāng)主觀的，通常結(jié)果不全面或是不一致腦力激蕩攻擊面分析安全設(shè)計審查設(shè)計階段活動的反饋安全軟件設(shè)計階

段的活動，其結(jié)

果也應(yīng)反饋并修

正安全需求架構(gòu)風(fēng)險分析威脅建模設(shè)計階段最弱環(huán)節(jié)(Weakest

Link)權(quán)限分離(Separation

ofDuties)開放設(shè)計(OpenDesign)縱深防御(Defense

inDepth)簡化設(shè)計

(Economy

of

Mechanism)使用現(xiàn)存元件(LeveragingExistingComponents)完全仲裁

(Complete

Mediation)可接受度(Psychological

Acceptability)最少共享機制(LeastCommonMechanism)安全設(shè)計原則防范單點失效(Single

Point

ofFailure)最小權(quán)限(Least

Privilege)安全故障(Fail

Secure)威脅建?！裢{建模采用系統(tǒng)化的方法，以攻擊者角度，識別可

能影響軟件系統(tǒng)

的威脅并進(jìn)行評估?！窕趯軜?gòu)與設(shè)計的了解，識別與評估威脅后，以風(fēng)險高低的順序?qū)?/p>

威脅發(fā)展適當(dāng)?shù)目刂拼胧┩{建模

1st威脅建模2nd威脅建模3rd架構(gòu)風(fēng)險分析攻擊面分析Attack

ResistanceAnalysis定義攻擊面攻擊面的識別和對應(yīng)攻擊面的衡量和評估管理攻擊面全(Underlying

FrameworkWeaknessAnalysis)系統(tǒng)依賴其他底

層軟件元件底層軟件的安全

問題影響系統(tǒng)安尋找底層軟件已

知安全弱點底層框架弱點分析英文字首項目高(3分)中(2分)低(1分)D可能傷害DamagePotential攻擊者取得完整的機敏資料;取得系統(tǒng)最高權(quán)限泄漏部分機敏資料泄漏系統(tǒng)細(xì)節(jié)信息R可重制性Reproducibility攻擊可以不停重制且不需要暫停時間攻擊可以重制，但需要暫停時間攻擊難以重制，或需要對弱點有深入知識才能

重制E可刺探性Exploitability不具有相關(guān)技能者也可以發(fā)動攻擊具有相關(guān)技能者可以發(fā)動攻擊需要對弱點有深入知識才能發(fā)動攻擊A影響使用者數(shù)AffectedUsers所有的使用者部分使用者極低比例的使用者Di可發(fā)現(xiàn)性Discoverability公開信息已揭露攻擊手法及漏洞已被找到相關(guān)的信息，但漏洞尚未被揭露極少用到的功能且使用者難以找出漏洞風(fēng)險因子

-

DREAD風(fēng)險計算與控制措施列表設(shè)計研究

設(shè)計分析安全需求目標(biāo)安全設(shè)計審查確認(rèn)設(shè)計

設(shè)計研討

設(shè)計變更設(shè)計文件

搜集開發(fā)階段敏感資料外泄(SensitiveData

Exposure)功能層級存取控制不正確

(MissingFunction

Level

Access

Control)物件參考不安全(Insecure

DirectObjectReferences)安全設(shè)定錯誤(SecurityMisconfiguration)暴力破解/字典檔攻擊密碼偷竊或密碼以

明文寫于文字檔中會話劫奪(Session

Hijacking)置換會話ID(Session

Fixation)使用已知含有弱點元件

(UsingKnownVulnerable

Components)未驗證進(jìn)行重導(dǎo)和導(dǎo)向

(InvalidatedRedirectsand

Forwards)常見軟件漏洞及控制措施暴力破解?限制密碼嘗試次數(shù)：

目前金融系統(tǒng)大多是這種方法，密碼錯了幾

次后就不能再使用了?IP

banned：延續(xù)1.，當(dāng)此IP嘗試幾次失敗后，直接ban掉這個IP?Incremental

delay：暴力攻擊法大多是反覆的對畫面上欄位進(jìn)行

密碼猜測，我們可在系統(tǒng)設(shè)計時，當(dāng)使用者輸入錯誤密碼時，做

某種程度的處理延遲，例如延遲一秒鐘，再錯，再延遲

...當(dāng)錯了

100次后，就會延遲100秒，在某種程度上就大大拉長了被駭?shù)乃?/p>

率

...?

避免太過明確的錯誤訊息：有些網(wǎng)站當(dāng)?shù)侨朊艽a錯誤時，會跳出

密碼錯誤，賬號不存在時會跳出賬號不存在，其實這樣的錯誤訊

息對黑客來說非常有用，可讓他們了解目前的賬號是否正確，帳

號正確后繼續(xù)測試密碼，直到破解為止，一些對使用者方便的訊

息，其實都間接幫助了黑客

...?密碼竊取

/

HardCode

password-

利用其他弱點取得數(shù)據(jù)庫或儲存媒體中的密碼-

特權(quán)密碼直接寫于檔案中或程序碼中?明文密碼儲存或簡易的密碼hash皆不安全一般系統(tǒng)的設(shè)計不會以明文來儲存密碼，

當(dāng)使用者設(shè)定密碼時，系統(tǒng)會透過一個單向函數(shù)的運算，萃取出一個密碼的特征值(Hash)，且此特征值只能單向運算而無法從特征值回推出密碼。之后使用者輸入密碼時，系統(tǒng)會經(jīng)由運算取得其特征值，再與之前的特征值進(jìn)行比對

，相符時即通過密碼驗證防范密碼竊取措施PasswordHashing(SecureSalted)

hashalgorithm:MD5、SHA1、SHA-256

、SHA-512、SHA-3-512Salted:產(chǎn)生唯一且隨機數(shù)的salt

(EX:

JavaUUID)

Salt

+

password

后進(jìn)行

Hash，例如SHA-512

分

別儲存Salt

以及Hash結(jié)

果密碼偷竊或密碼以明文寫于文字檔中雙因子認(rèn)證是一種計算機存取控制的

方法，使用者要通過兩

種以上的認(rèn)證機制之后，才能得到授權(quán)，使用電

腦資源。例如，使用者

要輸入PIN碼，插入銀行

卡，最后再經(jīng)指紋比對，通過這三種認(rèn)證方式，才能獲得授權(quán)。這種認(rèn)

證方式可以提高安全性.密碼重設(shè)機制采用其他管道(Email、SMS)

，重新身分驗證后，

允許重設(shè)密碼常見作法為先要求使用者輸入郵件信箱並驗證，

后續(xù)透過Email

寄送一次

性的令牌(Token)，檢查

其時效性后，允許使用

者重設(shè)

密碼

使用者未活動一段時間應(yīng)進(jìn)行登出(IdleSessionTimeout)

。使用

HTTPS

協(xié)定。不將SessionID或使用者

ID

顯示于

URL。HTTP

為無狀態(tài)協(xié)定，但大部分WEB應(yīng)用程式需要維持

狀態(tài)，

因此使用SessionID作為識別。攻擊者等待認(rèn)證

完成后，使用者已取得身分認(rèn)證的SessionID會話劫奪(SessionHijacking)置換會話

ID(Session

Fixation)攻擊者先行登入，取得一組

Session

ID

。后續(xù)置換使用者

Session

ID為攻擊

者的該組

Session

ID

，使用者成功登入后，攻擊者的

Session

ID

即被賦予權(quán)

限建

議

措

施

使用者登入后改變

Session

ID值

使用者未活動一段時間應(yīng)進(jìn)行登出(IdleSession

Timeout)

設(shè)置HttpOnly，關(guān)閉透明化SessionID，User-Agent驗證，

Token校驗等敏感資料外泄(Sensitive

Data

Exposure)如果未有效保護(hù)系統(tǒng)免受未經(jīng)授權(quán)的訪問，則黑客很可能會利用該漏洞并竊取該信息。所有加密均使用高強度加密算法

,

并生成加密密鑰，適當(dāng)?shù)拿荑€

管

理機制，包括密鑰置換。設(shè)置適當(dāng)?shù)臑g覽器指令和標(biāo)頭可

以保護(hù)瀏覽器提供或發(fā)送給

瀏覽

器的敏感資料。長期存儲的所有位置對其進(jìn)行加密

,

包括備份資料。在傳輸過程中，內(nèi)部和外部都對

它進(jìn)行加密。所有網(wǎng)際網(wǎng)絡(luò)流量都應(yīng)加密。功能層級存取控制不正確(Missing

Function

LevelAccessControl)可能由于應(yīng)用程序內(nèi)對敏感信息請求處理

程序的保護(hù)不足造成的：用戶可以直接瀏覽資源嗎？UI是否暴露了未經(jīng)授權(quán)的資源？系統(tǒng)應(yīng)包含具有一致全面性，強制適用于全系統(tǒng)的授權(quán)及存取控制機制

.是否采用Server端的驗證授權(quán)機制?此機制是否運作正常?

.Server端是否僅采用使用者提供的信息作為驗證的依據(jù)?

.UI界面是否呈現(xiàn)

連結(jié)或參數(shù)指向

未授權(quán)的功能

.RBACfilter物件參考不安全(Insecure

DirectObject

References)軟件開發(fā)者暴露了參考物件的實作方式或邏輯，

例如參考檔案、

目錄名稱、數(shù)據(jù)庫紀(jì)錄等，

卻未加以進(jìn)行存取限制安全設(shè)定錯誤(Security

Misconfiguration)未修補的軟件，舊選項，不需要的服務(wù)，未使用的頁面/功能以及不受保護(hù)的文件/目錄都在應(yīng)用程序上運行不必要的管理連結(jié)

埠

端口保持打開狀

態(tài)啟用Internet服務(wù)的出口連接在正式環(huán)境中使用偵錯模式目錄列表未禁用使用已知含有弱點元件(Using

KnownVulnerableComponents)未驗證進(jìn)行重導(dǎo)和導(dǎo)向(Invalidated

Redirectsand

Forwards)發(fā)生原因為軟件具備將使用者重導(dǎo)致其他

頁面或網(wǎng)站的功能，此一功能接受

URL

參數(shù)時，沒有驗證的機制參數(shù)不應(yīng)提供使用者輸入明確的目標(biāo)，而是采用間接參考的作法。例如，http://example.com/redir.jsp?url=Stkc9C，于軟件內(nèi)部邏輯再行對應(yīng)Stkc9C等于某一固定網(wǎng)頁

URL盡可能避免于使用者輸入欄位、URL或網(wǎng)頁內(nèi)提供可以指定重導(dǎo)頁面的功能確保每次重導(dǎo)或?qū)虻?/p>

行為，導(dǎo)向目標(biāo)皆為

「合法」且「使用者具

備導(dǎo)向該網(wǎng)頁之授權(quán).OWASPTop

102017-2021>

A1>權(quán)限控制

失效致未經(jīng)授權(quán)的資訊泄露、修改或破壞所有資料，或執(zhí)行超出用戶限制的業(yè)務(wù)功能不受信任的資料作為命令或查詢的一部分發(fā)送，會產(chǎn)生諸如SQL注入、NoSQL注入、OS

注入和LDAP注入的注入缺陷。>

A3>

注入式攻

擊Injectionslidesdowntothe

thirdposition.94%

oftheapplicationsweretestedforsomeform

ofinjection.

.通常是由于不安全的預(yù)設(shè)配置、不完整的臨時配置、開源云

存儲、錯誤的

HTTP

標(biāo)頭配置以及包含敏感信息的詳細(xì)錯誤信息所造成的。OWASPTop

10>

A2>

加密機制

失效靜態(tài)資料及資料

傳輸?shù)姆雷o(hù)需求著重于在設(shè)計與架構(gòu)中的風(fēng)險。來呼吁更多使用到威脅建模、安全設(shè)計模式與參考架構(gòu)。>

A4>

不安全設(shè)

計>

A5>

安全設(shè)定

缺陷>

A10>

服務(wù)器端請

求儰造當(dāng)網(wǎng)頁應(yīng)用程序正在取得遠(yuǎn)端資源，卻未驗證由使用者提供的網(wǎng)址，此時就會發(fā)生偽造伺服端請求。即便有防火墻、VPN或其他網(wǎng)絡(luò)ACL保護(hù)的情況下，攻擊者仍得以強迫網(wǎng)頁應(yīng)用程序發(fā)送一個經(jīng)過捏造的請求給一個非預(yù)期的目的端>

A9>

不足的日志

記錄和監(jiān)控使攻擊者能夠進(jìn)一步攻擊系統(tǒng)、保持持

續(xù)性或轉(zhuǎn)向更多系統(tǒng)，

以及篡改、提取或銷毀資料。大多數(shù)缺陷研究顯示，缺陷被檢測出的時間超

過200天，且通常通過外部檢測方檢測，而不是通過內(nèi)部流程或監(jiān)控檢測>

A6>易受攻擊和已

淘汰的組件軟件容易受到攻

擊、已不支援或

已淘汰。

包括作

業(yè)系統(tǒng)、網(wǎng)頁/應(yīng)

用程序服務(wù)器、數(shù)據(jù)庫管理系統(tǒng)

(DBMS)

、應(yīng)用程

式、API

以及所有

組件、執(zhí)行環(huán)境和程序庫(libraries)。>

A8>

軟件及資料

完整性失效著重在軟件更新，關(guān)鍵資料及持續(xù)性整合/部署(CI/CD)流程未經(jīng)完整性驗證之假設(shè)。>

A7>

認(rèn)證及驗證

機制失效確認(rèn)用戶的身分、認(rèn)證、會話(session)管理對于防止與認(rèn)證相關(guān)的攻擊至關(guān)重要OWASPTop

10(Cont.)測試階段靜態(tài)測試(源碼檢測)動態(tài)測試(弱點掃瞄、滲

透測試)測試計劃安全需求驗證65%52%安全性測試75%測試計劃V1.1安全軟件開發(fā)生命周期要求

V1.2身份驗證架構(gòu)要求V1.3會話管理架構(gòu)要求

01

Level

1

V1.4存取控制架構(gòu)要求V1.6加密架構(gòu)要求V1.7錯誤，

記錄和稽核架構(gòu)要求

V1.8資料保護(hù)和隱私架構(gòu)要求V1.9通信架構(gòu)要求

V1.10惡意軟件架構(gòu)要求 V1.11業(yè)務(wù)邏輯架構(gòu)要求V1.12安全文件上傳架構(gòu)要求

V1.13API架構(gòu)要求V1.14配置架構(gòu)要求02

Level

2

大多數(shù)應(yīng)用程序.03

Level3高價值，高保證，高安全性.第一步，自動化以整體概觀方式執(zhí)行

.

V1.5輸入和輸出架構(gòu)要求OWASPApplicationSecurityVerificationStandard4.0.2https://en./wiki/List_of_tools_for_static_code_analysis/www-project-web-security-testing-guide/latest/6-Appendix/A-Testing_Tools_Resource.html靜態(tài)測試static_code測

試

報

告弱

點

掃

描應(yīng)用程序網(wǎng)絡(luò)服務(wù)Using

ComponentswithKnownVulnerabilitiesInsufficientLogging&MonitoringSecurityMisconfigurationSensitiveData

ExposureBroken

Access

ControlInsecureDeserializationBrokenAuthenticationXMLExternal

Entities網(wǎng)站弱點掃描系統(tǒng)弱點掃描Cross-Site

Scripting網(wǎng)絡(luò)通訊埠Injection作業(yè)系統(tǒng)錯誤設(shè)定后門程序密碼破解需求訪談討論并確認(rèn)測

試范圍確定執(zhí)行日期

與時間確認(rèn)執(zhí)行方式

制定相關(guān)規(guī)則

定期進(jìn)行溝通

撰寫執(zhí)行計劃

書信息搜集搜尋引擎公開網(wǎng)站DNS查詢

Whois查詢網(wǎng)絡(luò)與主機掃

描連接埠掃描作業(yè)系統(tǒng)識別

版本掃描漏洞掃描.弱點利用證明威脅

取得權(quán)限

排除誤判.法令遵循需求訪談信息搜集網(wǎng)絡(luò)與主機掃描弱點利用報告撰寫滲透測試報告撰寫簡介執(zhí)行結(jié)果

結(jié)論滲透測試報告用于正式作業(yè)環(huán)境中的存取控制程序，

也應(yīng)實施于測試環(huán)境。每次正式作業(yè)環(huán)境中的信息要復(fù)制到

測試環(huán)境時，單獨進(jìn)行授權(quán)。正式作業(yè)環(huán)境的信息用于測試環(huán)境，

完成測試后應(yīng)立即刪除。復(fù)制及使用正式作業(yè)環(huán)境資料，應(yīng)被

記錄以提供稽核證據(jù)。

.安

全

需

求

驗

證布署與維運階段02

變更管理軟件于維運階段中，不可避免地將會因客戶需求或軟件具有錯誤等原因，而必須進(jìn)行程序的異動更新on

.01

強化環(huán)境強化部署環(huán)境工作需考量現(xiàn)代的軟件通常建立在其他底層之上，并與外部軟件或系統(tǒng)溝通布署與維運階段相對于持續(xù)性監(jiān)

控活動追蹤監(jiān)看

可能對軟件造成

損害的企圖，事

故處理則是當(dāng)安

全事故或破壞真

正發(fā)生時，所遵

循的處理步驟可提供組織驗證其軟件運算環(huán)境的正常運作維運階段進(jìn)行

持續(xù)性的監(jiān)控，04

事故處理03

監(jiān)控量測數(shù)據(jù)庫-定期更新數(shù)據(jù)庫的安全修補。-盡可能采用加密連