CN102495978B - 开放计算环境下任务执行体与执行点可信指数计算方法 - Google Patents

Abstract

开放计算环境的动态性、异构性、自治性、分布性等特征使系统存在着严重的安全隐患。本发明提出了一种开放计算环境下任务执行体与执行点可信指数计算方法，对任务执行体和任务执行点的可信指数从多方面进行综合计算，从而将合适的执行体调度到合适的执行点上运行。对任务执行体可信指数的计算综合考虑了任务执行体来源的身份信誉度、来源的可信程度、任务执行体的代码可信度；对任务执行点可信指数的计算综合考虑了所有者的身份信誉、任务执行点历史可信度、任务执行点当前可信度和任务执行点安全度。

Description

开放计算环境下任务执行体与执行点可信指数计算方法

技术领域

本发明是一种用于在基于互联网的开放网络计算环境中，为了保障任务执行体本身和执行节点的安全稳定性，而提出的一种任务执行体与执行点可信指数计算方法。本技术属于分布式计算、计算机网络、信息安全等信息技术类应用领域。

背景技术

开放计算环境与相对封闭的计算环境不同，计算节点分属于不同的机构，各节点是自治、异构、动态的，且存在多个用户向系统提交服务请求来共享计算与存储基础设施，这就为保障系统安全可信性和服务质量带来困难：

(1)任务的代码和数据在异构网络的传输过程被恶意节点攻击或窃取；

(2)任务的代码和数据被恶意执行环境与恶意节点攻击或窃取；

(3)任务包含的恶意代码对执行环境及网络系统进行攻击、破坏或信息窃取；

(4)用户提交的任务的执行代码互相攻击和窃取对方的信息。

对于传输中的代码和数据保护问题，可以依靠传统的网络安全技术加以解决，目前已经有了很多成熟、有效的解决方案。对于任务包含的病毒对终端节点的执行环境及主机系统的攻击问题，目前已经提出了一些有效可行的方法，例如沙盒模型、签名、认证、授权和资源分配、携带证明码、代码检验和审计记录等技术。而对于如何避免任务代码和数据被执行环境及主机攻击则比较困难。因为任务被传输并部署到目的主机执行时，任务的发起者就完全失去了对子任务的控制，任务的每一行代码都要被任务执行节点的主机系统解释、执行，代码完全暴露在执行系统中。任务执行者可以很容易地孤立、控制任务代码，对其进行攻击。例如恶意主机可以窃取任务的代码或者数据，从而了解任务整体的执行策略；修改任务的数据；窥探任务的控制流，篡改任务的代码，使任务按节点自己的意愿执行。

可信计算组织从主体行为的角度来定义可信：“当一个实体始终沿着预期的方式达到既定目标，则它就是可信的”。即强调计算机系统中的软硬件实体行为的结果可预测和可控性，以防御抗恶意代码和物理干扰造成的破坏。国内沈昌祥院士等信息安全专家等认为“可信计算系统是能够提供系统的可靠性、可用性、信息和行为安全性的计算机系统”。开放计算环境的动态性、异构性、自治性、分布性等特征使系统存在着严重的安全隐患。

发明内容

技术问题：本发明的目的是提供一种开放计算环境下任务执行体与执行点可信指数计算方法，使开放计算系统能够不断的演化并趋于安全可信状态。在动态的开放计算环境中，用户向系统提交作业后，系统如何使任务执行体和任务执行点能够相互进行可信评价需要重点解决的关键技术问题。

技术方案：本发明的一种开放计算环境下任务执行体与执行点可信指数计算方法，对任务执行体和任务执行点的可信指数进行计算，以此作为任务执行体和任务执行点相互评价的依据，从而可以将合适的执行体调度到合适的执行点上运行。

任务执行体的可信指数主要取决于以下几个因素：

(1)任务执行体的来源(即任务提交者)的可信程度；

(2)任务执行体包含的代码、执行逻辑的安全可信程度；

(3)任务执行体对执行点软硬件资源的使用程度和范围情况。

而任务执行点的可信指数则主要取决于以下几个因素：

(1)任务执行点所有者的可信程度；

(2)任务执行点历史表现记录；

(3)任务执行点安全可信保障措施设置情况；

(4)任务执行点上运行的其它任务执行体的可信指数。

之所以在考虑任务执行点的可信指数时需要考虑运行于其上的其它任务执行体的可信指数，是因为在多用户计算环境下，多个任务执行体运行于同一执行点上。若其中包含恶意任务执行体，其具备攻击其它任务执行体的可能性，这显然会降低执行点的可信指数。因此任务执行点的可信指数是动态变化的，这种动态性主要取决于当前运行的任务执行体的情况。

某一个任务执行体是否能够迁移到某一个的执行点上运行取决于双方各自的安全策略。简言之，彼此的当前可信指数是否满足双方的安全策略中的规定。因此，计算出能够客观反映彼此安全程度的、量化的、可操作的可信指数是解决问题的关键。

1、任务执行体的可信指数

首先需要评估任务执行体的来源的身份信誉度(SourceReputation)。这主要通过人工按照标准来进行评级获得。任务执行体来源于某个信誉良好的权威机构，该机构为了继续维护其良好的信誉，通常提交的任务及其执行代码是可信的，不会对系统和其它用户带来损坏；任务执行体来源之前的行为表现是一贯良好的，从未提交过包含恶意代码的任务，则其今后的行为也是大概率可信的。

对任务来源可信程度的量化评价计算方法如下式所示：

$\mathrm{SourceC}{\mathrm{redit}}_i=\underset{k=1}{\overset{m}{\mathrm{\Σ}}}{s}_{k,i}(-t_{k,i})---\left(1\right)$

式(1)中的SourceCredit_i是指任务执行体i来源的可信程度；t_k，i是某一次任务执行体的代码恶意程度；s_k，i指任务计算规模，k是任务执行体i来源曾经提交的任务次数变量，对于恶意代码来说，大规模的执行显然会带来更加严重的损失；m是任务执行体i来源曾经提交的任务总次数。

仅依赖基于历史行为的任务执行体来源可信程度难以完全保障当次任务代码的安全可信性，因此还需要对任务执行体包含的代码、执行逻辑的安全可信程度以及本地软硬件资源的使用程度和范围进行考察。代码可信度如下式所示：

CodeCredit_i＝<CPUCost_i，MemCost_i，I/O_i，APICall_i>            (2)

式(2)中的CodeCredit_i指迁移到当前执行点的任务执行体i的代码可信度；CPUCost_i指任务执行体i的代码时间复杂度；MemCost_i指任务执行体i的代码空间复杂度I/O_i指任务执行体i的输入输出情况；APICall_i指任务执行体i调用的本地组件。执行点以此作为是否接纳任务执行体i的依据，若接纳并执行，则以此作为衡量执行情况是否可信的审计凭证。

综上所述，任务执行体的可信指数AgentCredit设定为向量：

AgentCredit＝(SourceReputation，SourceCredit，CodeCredit)    (3)

2、任务执行点的可信指数

任务执行点的可信指数则主要取决于任务执行点所有者的可信程度、任务执行点历史表现记录、任务执行点安全可信保障措施设置情况、其上运行的其它任务执行体的可信指数。开放的计算环境的公共云与私有云中包含的任务执行点及其计算、存储与数据资源分属于不同的所有者，不同的所有者的可信程度显然也各不相同，如何评价任务执行点所有者的可信程度，本发明衡量的标准同样按照执行点所有者的身份信誉(ExecutorReputation)、执行点历史行为记录来综合确立。一份任务执行点属于某个信誉良好的权威机构，该机构为了继续维护其良好的信誉，其执行点的行为一般是可信的，不会对用户提交的任务代码和数据进行窃取和攻击破坏；一个任务执行点及其所有者所属其它节点的行为表现是一贯良好的，从未有过恶意代码的行为表现，则其今后的行为也是大概率可信的。

执行点历史可信度的计算方法如下式所示：

${\mathrm{HistoryCredit}}_j=\underset{k=1}{\overset{n}{\mathrm{\&Sigma;}}}(-x_{k,j})---\left(4\right)$

式(4)中的HistoryCredit_j是指执行点j的历史可信度；x_k，j是某一次执行点行为的恶意程度；n是执行点执行的任务次数。假设执行点j上当前运行着w个任务执行体，则该执行点的当前可信度的量化评价计算方法如下式所示：

$\mathrm{Current}{\mathrm{Credit}}_j=\left\{\begin{array}{c}\frac{\underset{k=1}{\overset{w}{\mathrm{\&Sigma;}}}\mathrm{AgentCredi}{t}_k}{w},w\&GreaterEqual;1\\ \left(\mathrm{0,0,0}\right),w=0\end{array}\right.---\left(5\right)$

式(5)中的CurrentCredit_j是执行点j的当前可信度向量。如果当前节点上没有其它的任务执行体(即w＝0)，则CurrentCredit_j值为(0，0，0)。这意味着如果一个执行点上的多个任务执行体的可信指数都是高的，该执行点的可信程度也高。

任务执行点安全可信保障措施设置情况主要体现在：如果迁移过来的任务执行体是恶意的，该任务执行点没有能够检测出来，并向系统管理节点报告的话，该任务执行点的安全可信保障措施显然是不完善的。执行点的安全度的量化评价计算方法如下式所示：

${\mathrm{SecurityCredit}}_j=\frac{u_j-w_j-\mathrm{\&mu;}{f}_j}{\underset{k=1}{\overset{n}{\mathrm{\&Sigma;}}}{u}_k}---\left(6\right)$

式(6)中的SecurityCredit_j是执行点j的安全度；u_j是执行点j提交的真实安全告警报告数；w_j是执行点j应提交但并未提交安全告警报告数；f_j是执行点j提交的虚假安全告警报告数，μ作为节点提交虚假安全告警报告的惩罚因子。

综上所述，任务执行点的可信指数ExecutorCredit设定为向量：

ExecutorCredit＝(ExecutorReputation，HistoryCredit，CurrentCredit，SecurityCredit)  (7)

有益效果：本发明提出的任务执行体与执行点可信指数计算方法可以有效提升开放计算环境中应用系统的安全性，达到以下的有益效果：

(1)可以有效地保障了用户提交的任务执行体在异地执行的安全性；

(2)可以有效地保障了承担任务的任务执行点自身的安全性。

具体实施方式

本发明提供了一种开放计算环境下任务执行体与执行点可信指数计算方法，对任务执行体和任务执行点的可信指数进行计算，从而将合适的执行体调度到合适的执行点上运行。

某一个任务执行体是否能够迁移到某一个的执行点上运行取决于双方各自的安全策略。简言之，彼此的当前可信指数是否满足双方的安全策略中的规定。因此，计算出能够客观反映彼此安全程度的、量化的、可操作的可信指数是解决问题的关键。

1、任务执行体的可信指数计算方法

首先需要评估任务执行体的来源的身份信誉度(SourceReputation)。这主要通过人工按照标准来进行评级获得。任务执行体来源于某个信誉良好的权威机构，该机构为了继续维护其良好的信誉，通常提交的任务及其执行代码是可信的，不会对系统和其它用户带来损坏；任务执行体来源之前的行为表现是一贯良好的，从未提交过包含恶意代码的任务，则其今后的行为也是大概率可信的。但这里仍需要对执行体所含代码的恶意程度进行细化，如表1所示。

表1 执行体所含代码的恶意程度

执行体代码行为	恶意程度
		正常代码，无任何恶意行为	0
代码对资源使用轻微过量，但对节点运行和其它任务基本没有影响	0.1
		代码对资源使用过度，且对节点运行和其它任务产生影响	0.3
代码使节点产生类似于拒绝服务的效果	0.5
		代码试图窥探其它执行体的数据和执行逻辑	0.7
代码试图攻击其它执行体，篡改执行逻辑和执行结果	0.9
		代码试图攻击整个计算环境，使整个系统大规模瘫痪并造成重大损失	1.0

对任务来源可信程度的量化评价计算方法如下式所示：

${\mathrm{SourceCredit}}_i=\underset{k=1}{\overset{m}{\mathrm{\&Sigma;}}}{s}_{k,i}(-t_{k,i})---\left(8\right)$

式(8)中的SourceCredit_i是指任务执行体i来源的可信程度；t_k，i是某一次任务执行体的代码恶意程度；s_k，i指任务计算规模，k是任务执行体i来源曾经提交的任务次数变量，对于恶意代码来说，大规模的执行显然会带来更加严重的损失；m是任务执行体i来源曾经提交的任务总次数。

仅依赖基于历史行为的任务执行体来源可信程度难以完全保障当次任务代码的安全可信性，因此还需要对任务执行体包含的代码、执行逻辑的安全可信程度以及本地软硬件资源的使用程度和范围进行考察。代码可信度如下式所示：

CodeCredit_i＝<CPUCost_i，MemCost_i，I/O_i，APICall_i>            (9)

式(9)中的CodeCredit_i指迁移到当前执行点的任务执行体i的代码可信度；CPUCost_i指任务执行体i的代码时间复杂度；MemCost_i指任务执行体i的代码空间复杂度I/O_i指任务执行体i的输入输出情况；APICall_i指任务执行体i调用的本地组件。执行点以此作为是否接纳任务执行体i的依据，若接纳并执行，则以此作为衡量执行情况是否可信的审计凭证。

综上所述，任务执行体的可信指数AgentCredit设定为向量：

AgentCredit＝(SourceReputation，SourceCredit，CodeCredit)    (10)

2、任务执行点的可信指数计算方法

任务执行点的可信指数则主要取决于任务执行点所有者的可信程度、任务执行点历史表现记录、任务执行点安全可信保障措施设置情况、其上运行的其它任务执行体的可信指数。开放的计算环境的公共云与私有云中包含的任务执行点及其计算、存储与数据资源分属于不同的所有者，不同的所有者的可信程度显然也各不相同，如何评价任务执行点所有者的可信程度，本发明衡量的标准同样按照执行点所有者的身份信誉(ExecutorReputation)、执行点历史行为记录来综合确立。一份任务执行点属于某个信誉良好的权威机构，该机构为了继续维护其良好的信誉，其执行点的行为一般是可信的，不会对用户提交的任务代码和数据进行窃取和攻击破坏；一个任务执行点及其所有者所属其它节点的行为表现是一贯良好的，从未有过恶意代码的行为表现，则其今后的行为也是大概率可信的。这里对执行点的行为进行细化，如表2所示。

表2 执行点行为的恶意程度

执行点历史可信度的计算方法如下式所示：

${\mathrm{HistoryCredit}}_j=\underset{k=1}{\overset{n}{\mathrm{\&Sigma;}}}\left({-x}_{k,j}\right)---\left(11\right)$

式(11)中的HistoryCredit_j是指执行点j的历史可信度；x_k，j是某一次执行点行为的恶意程度；n是执行点执行的任务次数。假设执行点j上当前运行着w个任务执行体，则该执行点的当前可信度的量化评价计算方法如下式所示：

$\mathrm{Current}{\mathrm{Credit}}_j=\left\{\begin{array}{c}\frac{\underset{k=1}{\overset{w}{\mathrm{\&Sigma;}}}\mathrm{AgentCredi}{t}_k}{w},w\&GreaterEqual;1\\ \left(\mathrm{0,0,0}\right),w=0\end{array}\right.---\left(12\right)$

式(12)中的CurrentCredit_j是执行点j的当前可信度向量。如果当前节点上没有其它的任务执行体(即w＝0)，则CurrentCredit_j值为(0，0，0)。这意味着如果一个执行点上的多个任务执行体的可信指数都是高的，该执行点的可信程度也高。

任务执行点安全可信保障措施设置情况主要体现在：如果迁移过来的任务执行体是恶意的，该任务执行点没有能够检测出来，并向系统管理节点报告的话，该任务执行点的安全可信保障措施显然是不完善的。执行点的安全度的量化评价计算方法如下式所示：

${\mathrm{SecurityCredit}}_j=\frac{u_j-w_j-\mathrm{\&mu;}{f}_j}{\underset{k=1}{\overset{n}{\mathrm{\&Sigma;}}}{u}_k}---\left(13\right)$

式(13)中的SecurityCredit_j是执行点j的安全度；u_j是执行点j提交的真实安全告警报告数；w_j是执行点j应提交但并未提交安全告警报告数；f_j是执行点j提交的虚假安全告警报告数，μ作为节点提交虚假安全告警报告的惩罚因子。

综上所述，任务执行点的可信指数ExecutorCredit设定为向量：

ExecutorCredit＝(ExecutorReputation，HistoryCredit，CurrentCredit，SecurityCredit)  (14)

具体到对于某一个任务发起者来说，他的不同任务执行体的重要性和对于安全可信需求是不相同的；对于所有者的各个执行点来说，其对于达到什么可信指数的任务执行体能够迁移到本地来执行取决于自身的安全策略。

首先设计了与任务执行体和执行点相关的模态算子，主要包含了：

●信任算子Tru。表示主体x信任当前某一个客体达到标准

●能力算子Obt。表示主体x具备条件

任务执行点以上述任务执行体可信指数为依据，按照如下方法判断任务执行体是否可信：

EtoATrust＝Tru_j(Obt_i(f(SourceReputation_i)＝true)                     (15)

∧(SourceCredit_i≥α)∧(g(CodeCredit_i)＝true)))

式(15)中的f()是任务执行体来源的身份信誉度的判别函数，α是执行点对任务执行体来源可信度的预设可信阈值，g()是代码可信度的判别函数。

任务执行体以上述任务执行点可信指数为依据，按照如下方法判断任务执行点是否可信：

AtoETrust＝Tru_i(Obt_j(h(ExecutorReputation_j)＝true)∧(HistoryCredit_j≥β)  (16)

∧(CurrentCredit_j≥λ)∧(SecurityCredit_j≥δ)))

式(16)中的h()是执行点的所有者身份信誉的判别函数，β是任务执行体对执行点历史可信度的预设可信阈值，λ是执行点当前可信度的预设可信阈值，δ是执行点安全度的预设可信阈值。

应用任务执行体与执行点可信指数计算方法的原型系统的关键类包括CurrentCodeCredit等，下面具体阐述。

其中，CurrentCodeCredit为基本的数据结构，用以表示任务执行体为其自身代码的说明并为其余各类提供接口，其中CPUcost表示本次任务代码的时间复杂度，Mencost表示本次任务代码的空间复杂度，IOcost表示本次代码的I/O使用情况(如量与次数)，APIcall表示本次代码对本地组件的调用情况(如次数等)。

AgentCredit类为表示任务执行体可信指数的数据结构。其中SourceRepution表示任务执行体来源的身份信誉度指数，SourceCredit表示来源的可信程度(由CreditJudgement类来对其进行初始化)，CodeCredit表示对任务执行体自身代码的说明，由GetCodeCredit()方法对其进行初始化。

ExecutorCredit类为表示任务执行点可信指数的数据结构，其中ExecutorReputation表示节点所有者的身份信誉，HistoryCredit表示节点的历史可信度(由CreditJudgement类来对其进行初始化)，CurrentCredit是该执行点当前可信度向量(由CreditJudgement类来对其进行初始化)，SecurityCredit该执行点的安全度(由CreditJudgement类来对其进行初始化)。

NodeInformation类为表示某节点信息的数据结构，其中NodeName是节点在MasterNode中注册的名字，是该节点区别于其他节点的唯一标识。AgentSourceCredit是该节点对任务执行体来源可信度的预设阈值。

AgentInformation类为表示任务执行体相关信息的数据结构。其中UserName表示该任务执行体提交用户的标识，是该用户区别于其他用户的唯一表示。CurrentAgentCredit表示此次任务执行体的可信指数。NodeHistoryCredit表示任务执行体对执行点历史可信度的预设阈值，NodeCurrentCredit对执行点当前可信度的预设阈值，NodeSecurityCredit表示对执行点安全度的预设阈值。

CreditJudgement为进行迁移匹配的主类，用以调用存储在本地数据库的用户和节点信誉历史来进行初始化工作并在任务执行体与执行点匹配成功后，将执行任务切分为若干执行体发送到其匹配的节点上并最终将任务执行体和执行点反馈回来的信息存入数据库为下一次调用提供初始化。其中UserCredit()方法用以读取任务执行体的自带信息，按照任务执行体的提交者的名称查询本地数据库，返回一个AgentCredit向量。NodeCreditSearch()方法用以读取执行点的信息，按照执行点的名称查询本地数据库，返回一个ExeCutorCredit向量。Nodeestimate向量用以将任务执行体派遣至相应执行点后，更新该节点存储在本地数据库的CurrentCredit。CreditUpdate用以在接收到任务执行体和执行点的报告后，更新数据库中对应的用户和执行点的历史信誉值。

Claims (1)

1.一种开放计算环境下任务执行体与执行点可信指数计算方法，其特征在于对任务执行体和任务执行点的可信指数从多方面进行综合计算，对任务执行体可信指数的计算综合考虑任务执行体来源的身份信誉度、来源的可信程度、任务执行体的代码可信度；对任务执行点可信指数的计算综合考虑所有者的身份信誉、任务执行点历史可信度、任务执行点当前可信度和任务执行点安全度；

具体计算方法如下：

需要综合考虑任务执行体来源的身份信誉度、来源的可信程度、任务执行体的代码可信度；

首先需要评估任务执行体的来源的身份信誉度SourceReputation；这主要通过人工按照标准来进行评级获得；

对任务来源可信程度的量化评价计算方法如下式所示：

${\mathrm{SourceCredit}}_i=\underset{k=1}{\overset{m}{\mathrm{\&Sigma;}}}{s}_{k,i}(-t_{k,i})---\left(1\right)$

式(1)中的SourceCredit_i是指任务执行体i来源的可信程度；t_k,i是某一次任务执行体的代码恶意程度；s_k,i指任务计算规模，k是任务执行体i来源曾经提交的任务次数变量，对于恶意代码来说，大规模的执行显然会带来更加严重的损失；m是任务执行体i来源曾经提交的任务总次数；

代码可信度的计算主要基于任务执行体包含的代码、执行逻辑的安全可信程度以及本地软硬件资源的使用程度和范围；代码可信度如下式所示：

CodeCredit_i＝＜CPUCost_i,MemCost_i,I/O_i,APICall_i＞   (2)

式(2)中的CodeCredit_i指迁移到当前执行点的任务执行体i的代码可信度；CPUCost_i指任务执行体i的代码时间复杂度；MemCost_i指任务执行体i的代码空间复杂度，I/O_i指任务执行体i的输入输出情况；APICall_i指任务执行体i调用的本地组件；执行点以此作为是否接纳任务执行体i的依据，若接纳并执行，则以此作为衡量执行情况是否可信的审计凭证；CodeCredit_i用于对任务执行体包含的代码、执行逻辑的安全可信程度以及本地软硬件资源的使用程度和范围进行考察；CurrentCodeCredit为其基本的数据结构，用以表示任务执行体为其自身代码的说明并为其余各类提供接口，其中CPUcost表示本次任务代码的时间复杂度，Mencost表示本次任务代码的空间复杂度，IOcost表示本次代码的I/O使用情况，APIcall表示本次代码对本地组件的调用情况；CodeCredit_i表示对任务执行体i的自身代码的说明，由GetCodeCredit()方法对其进行初始化；

任务执行体的可信指数AgentCredit设定为向量：

AgentCredit＝(SourceReputation,SourceCredit,CodeCredit)   (3)

当计算任务执行点的可信指数时：

需要考虑所有者的身份信誉、任务执行点历史可信度、任务执行点当前可信度和任务执行点安全度；

首先需要评估任务执行点所有者的的身份信誉度ExecutorReputation；这主要通过人工按照标准来进行评级获得；

执行点历史可信度的计算方法如下式所示：

${\mathrm{HistoryCredit}}_j=\underset{k=1}{\overset{n}{\mathrm{\&Sigma;}}}(-x_{k,j})---\left(4\right)$

式(4)中的HistoryCredit_j是指执行点j的历史可信度；x_k,j是某一次执行点行为的恶意程度；n是执行点执行的任务次数；

假设执行点j上当前运行着w个任务执行体，则该执行点的当前可信度的量化评价计算方法如下式所示：

${\mathrm{CurrentCredit}}_j=\left\{\begin{array}{c}\frac{\underset{k=1}{\overset{w}{\mathrm{\&Sigma;}}}{\mathrm{AgentCredit}}_k}{w},w\&GreaterEqual;1\\ \left(\mathrm{0,0,0}\right),w=0\end{array}\right.---\left(5\right)$

式(5)中的CurrentCredit_j是执行点j的当前可信度向量；如果当前节点上没有其它的任务执行体，即w＝0时，CurrentCredit_j值为(0,0,0)；

执行点的安全度的量化评价计算方法如下式所示：

${\mathrm{SecurityCredit}}_j=\frac{u_j-w_j-\mathrm{\&mu;}{f}_j}{\underset{k=1}{\overset{n}{\mathrm{\&Sigma;}}}{u}_k}---\left(6\right)$

式(6)中的SecurityCredit_j是执行点j的安全度；u_j是执行点j提交的真实安全告警报告数；w_j是执行点j应提交但并未提交安全告警报告数；f_j是执行点j提交的虚假安全告警报告数，μ作为节点提交虚假安全告警报告的惩罚因子；

任务执行点的可信指数ExecutorCredit设定为向量：

ExecutorCredit＝(ExecutorReputation,HistoryCredit,CurrentCredit,SecurityCredit) (7)。