金融企业信息安全考核体系建设

华盟学院山东省第二期线下学习计划

金融企业信息安全考核体系建设

安全考核,属于企业评价体系的一部分,和人力资源、人员激励等相关性比较大。考核话题也比较大,考核的方式、考核指标、考核结果运用等。资源是有限的,如果给干活的人都发一颗钻石,无疑工作又快又好的完成了。在资源受限的情况下,如何最大化的激励团队与员工,实现安全目标,需要企业安全负责人认真思考的问题,本文做一些探讨。


1.评价体系与原则


笔者所经历过的企业比较重视评价体系与原则。以下是比较赞同的几个原则。


1.1 评价体系


组织评价体系尊崇“赛马胜相马”,不能制胜的能力不是真能力,不能制胜的能力还要训练,只是白白浪费时间。组织将部门利益和个人利益挂钩,如果部门因为某个员工的努力获取了利益,就应该以某种形式反馈为员工利益;如果因某个团队的努力使部门获取了利益,也应该以某种形式反馈给团队,再由团队以公平的形式反馈给员工。


德、能、勤、绩是组织评价员工的四要素,德代表思想品行,能代表能力,勤代表工作表现,绩代表绩效。比如:这活给钱我干,不给钱我也干,就是德。别人不行,我行,就是能。别人休息了,我拼搏,就是勤。白猫黑猫,抓了老鼠,就是绩。我们用人用所长,绝不求全责备,员工和初级管理者主要考核绩和勤,中级管理者主要考核绩和能,高级管理者主要考核德和能。


绩效评估和考核是组织对员工进行评价一般形式。组织的考核是上级、下级、同级(相关者)的多维考核体系,力求真实反映各团队和员工的综合绩效。团队层面,通过KPI实现上级的利益诉求,通过互评和协助评分实现同级相关团队利益诉求,通过员工满意度实现下级利益诉求。绩效考核不单单是绩效的评估,KPI的考核成绩本身就是德、能、勤的函数在概率分布下的结果。满意度和互评更是第三者对员工德、能、勤的主观感受。没有团队精神的员工,不爱部下的干部,再有能力也不可能在互评和满意度评估中获得高分。


KPI考核根据组织战略,制定各团队和条线的KPI,并由团队或条线逐层分解到员工的形式。一线团队和二线团队制定不同的考核项,考核标准向一线团队倾斜。


绩效考核结果运用遵循长短期利益结合,现金收入是短期利益,是对于个人价值贡献回馈体系的一部分,组织提供的做事机会、承担各重要领域重要任务的信任,是给各位员工提供个人价值提升的机会,属于长期利益,优秀员工必然会从长期利益中获得丰厚回馈。即使是短期利益,也是和员工日常工作中完成的每一项工作,每一次重要会议,每一个项目分不开的,合抱之木,生于毫末;九层之台,起于累土;千里之行,始于足下。日常工作的辛勤积累,才能造就每年的丰硕果实,体验奋斗带来的丰收喜悦。


1.2 奖惩机制


组织奖惩遵循两个原则:奖励与惩罚并重的原则,组织为每个人提供充分的长期创新动力或制度激励,同时为每个人提供行为选择的制度罚单和约束条件,从而建构起奖励与惩罚并重的有效均衡机制;物质奖惩与精神奖惩相结合的原则,物质奖惩和精神奖惩依据每个人基本物质需求和精神需求,物质奖惩与精神奖惩是双向强化的方式,各自承担不同的功能,组织要充分利用好人的趋利主义动机和精神主义作用。


1.3 干部选拔机制


组织干部选拔原则:择优和奋斗,择优包括品德、绩效、能力、贡献、合作、责任,奋斗包括额外工作时间的投入。我们不单纯任人唯贤,也任人唯亲,亲不是指血缘关系,而是指是否认同我们的组织文化。组织会创造多种机会便于人才的脱颖而出,包括虚拟条线、轮岗锻炼、跨界学习等。


1.4 管理者的权利和义务


管理者具有本条线人力资源管理职责,各级管理者有责任记录、指导、支持、激励与评价下属员工的工作,负有帮助下属员工成长的责任,下属优秀员工的数量和质量是管理者绩效的重要指标。

2. 考核对象

安全考核分成对团队和个人的考核两部分。


2.1 团队考核


2.1.1 总部IT部门


企业内部一般由人力资源部(或薪酬绩效委员会)负责整个企业内部的考核体系、考核标准,以及每年下达各部门的绩效目标书。总部IT部门的绩效目标书通常会包含信息安全考核指标(没有的话,说明安全非常非常不受重视,可以考虑换公司了),考核权重从5%到20%,一般不会超过20%。信息安全考核内容包括:


  • 安全事件数。有的也称为:安全运行率,属于结果指标。主要考核一年内安全防护情况,通俗的讲就是不出事。该指标也代表风险偏好和容忍度。根据企业的实际情况不同,有的企业愿意安全投入少一点,能适当容忍一些安全事件发生。有的企业要求比较高,投入大,不太能容忍安全事件,甚至不接受发生安全事件的结果。注意安全事件数要看是否区分原因,比如安全事件数的计算是指因IT部门管理失职导致的,还是不区分原因,只要公司发生安全事件就算。实际中还是区分原因的比较合理。

  • 合规率。结果指标。这个指标一般指监管标准达标率(内规承接外规比例),制度建设完备情况,以及合规报送合格率(及时率、差错率)等,反映的是监管合规工作质量。

  • 安全建设项目完成率。过程指标。这个指标指IT部门每年的建设项目中,安全项目建设完成情况。

  • 扣分项。结果指标。主要是公司内控合规、稽核审计部门,在内外部安全检查、安全审计中发现问题的扣分。


通常情况下,总部IT部门考核会分解成细项指标,由总部IT部门安全团队和非安全团队承接,安全团队承接的比重不超过20%,通常是结果指标和过程指标相结合的方式


2.1.2 总部非IT部门


总部非IT部门,包括业务部门和职能部门,除风控部门外,通常没有信息安全考核指标,主要是发生安全事件,责任归属于上述部门的,实行扣分机制。比如发现非IT部门员工泄露客户资料数据,需要对该员工所在部门进行安全考核扣分处罚,严重的甚至进行内部问责。


2.1.3 分支机构IT部门(或有)


金融企业一般会有总部和分支机构。分支机构不一定会有IT部门,所以是“或有”。分支机构IT部门(或有)信息安全考核,和总部IT部门类似,考核结果指标和过程指标。


2.1.4 分支机构非IT部门(或有)


和总部机构非IT部门考核类似。


2.2 个人考核


2.2.1 公司安全负责人


公司安全负责人,有的企业设有专人,首席安全官(以下简称“CSO”)。大部分金融企业都没有CSO岗位(预计未来5-10年内会迎来爆发),一般由总行行长,公司总裁,公司分管IT领导兼任。公司安全负责人的考核已经由《网络安全法》明确规定了^_^。《网络安全法》第三十四条规定:关键信息基础设施的运营者还应当履行下列安全保护义务:设置专门安全管理机构和安全管理负责人,并对该负责人和关键岗位的人员进行安全背景审查。第七十四条规定:违反本法规定,构成违反治安管理行为的,依法给予治安管理处罚;构成犯罪的,依法追究刑事责任。


2.2.2 总部IT部门负责人


总部IT部门负责人的考核是360度综合评分,部门负责人的考核是比较复杂的方式,信息安全考核和运维考核一样,属于底线考核(不能出事),但考核的主要权重在于IT对业务发展的支撑,IT引领业务发展等方面。


2.2.3 总部IT部门安全团队负责人


在公司高管层、部门总经理那,安全考核只有一个指标,别出事情,出了事情等着背锅。说白了就是要对结果负责,所以我们的考核设计,无论是对其他团队的安全考核,还是对安全团队考核,就是结果指标要占到考核的50%以上。比如对平行团队考核,就两个指标,风险发现、安全合规要求落实。风险发现包括漏洞和事件,内外审计发现,安全合规要求落实就是安全部门部署工作的完成情况,简单有效。安全团队考核两类指标,安全事件数和安全建设工作完成率,IT部门内平行各团队对自己的安全结果负责,安全团队对整个部门的安全结果负责,承担整个部门安全事件数考核。安全建设包括安全项目、安全合规、安全宣传等工作,也都是承诺具体指标数据的。具体指标包括:

(1)安全事件数;

(2)安全建设完成情况;

(3)其他指标,包括安全团队人才培养、团队企业文化建设、安全团队满意度等。

2.2.4 总部IT部门安全团队成员


在我经历过的安全团队,一般考核安全团队成员以下内容:安全性、安全建设重点项目、督办事项、技术创新、常态化工作、人才成长、满意度。(具体内容见3.3 个人考核)


2.2.5 分支机构IT部门负责人(或有)

负责承接总部下达的本分支机构安全考核任务完成。


2.2.6 分支机构IT部门安全团队负责人(或有)


负责承接分支机构IT部门负责人安排的本分支机构安全考核任务目标完成。


2.2.7 公司员工


公司员工主要承担安全职责,没有安全考核。安全职责主要是保守公司秘密,保护公司分配的账户密码、双因素动态令牌Token卡等重要敏感信息。一把属于出事后的责任追究范畴。


综上所述,信息安全考核的重点是:总部IT部门安全团队和非安全团队、总部IT部门安全团队负责人和成员四部分。下面分别探讨面向总部IT部门安全团队和非安全团队的考核方案。

3.考核方案


团队考核最重要的是两部分:总部IT部门安全团队和非安全团队。个人考核最重要的是总部IT部门安全团队负责人和安全团队成员。


3.1 总部IT部门安全团队


3.1.1 考核内容


(1)结果项


包括安全事件数量,信息系统漏洞整改率等结果指标。


安全事件数量包括全年由行业监管部门通报、且安全团队未主动发现的高、中危安全事件数量。安全事件类型包括:应用系统漏洞、直接获取重要系统权限、敏感信息泄露等。


信息系统漏洞整改率,指所有内外部发现的信息系统高中危漏洞整改修复应大于一定比例。


有关信息安全事件与安全合规不符合项分级定义见附录5.1《信息安全事件与安全合规不符合项分级定义》


有关信息系统漏洞分级标准示例见附录5.2《信息系统漏洞分级标准定义》。

(2)过程项

包括安全建设、安全运营、安全检查、安全意识宣贯、监管合规落实等指标。

(3)加减分项

加分项包括:一是完成各项安全任务的同时,为公司或部门带来良好声誉,或避免了安全事件发生;二是按制定计划提前完成,且质量达到要求,或按计划完成,质量超预期。减分项包括:一是给公司造成不良影响的,在原有扣分标准上加倍。二是由于主观原因,未按计划完成,在原有扣分标准上加倍


3.1.2  考核周期、考核权重、考核分数


一般是以自然年为考核周期。考核权重中,结果指标一般占安全团队至少50%绩效。


3.2 总部IT部门非安全团队(平行团队)


3.2.1 考核内容

(1)结果项

包括安全事件数量,信息系统漏洞整改率、安全合规检查风险发现数量等结果指标。安全事件、信息系统漏洞定义和等级划分见上述标准。安全合规检查风险发现主要考核安全合规检查不符合项(含内审、风险评估、安全专项任务等)。

漏洞分级标准:信息系统漏洞风险分级:漏洞级别采用信息安全通用风险定义标准(见附录5.2),分为严重、高危、中危、低危四个级别。漏洞分级综合考虑了漏洞的危害及实际被利用的难易程度。


漏洞考核标准(漏洞扣分按100分制计算)

 

漏洞风险级别

考核标准

S1

S2

S3

S4

严重

高危

中危

低危

单个漏洞扣分标准

2

1

0.6

0

漏洞修复周期标准

1

3

7

--

漏洞修复时间见下表:

 

漏洞风险级别

考核标准

S1

S2

S3

S4

严重

高危

中危

低危

单个漏洞扣分标准

2

1

0.6

0

漏洞修复周期标准

1

3

7

--

漏洞考核计算方式

 

考核计算方式

漏洞类别

检测发现

修复

1周期内

修复

超过1周期

修复

超过n周期

发现即考核的漏洞

100%

减免50%

100%

100% * n

仅考核修复的漏洞

--

--

100%

100% * n

说明:


  1. 发现即考核的漏洞:检测发现时按漏洞等级扣分,在修复周期内修复减免50%;修复时间超过1周期按100%扣分,超过2周期按200%扣分,依次类推。

  2. 仅考核修复的漏洞:检测发现时不考核,在漏洞等级修复周期内修复不考核;修复时间超过1周期按漏洞风险级别按100%扣分,超过2周期时按200%扣分,依次类推。

  3. 如遇特殊情况,可申请延期修复,审核通过后可获得最高2个周期的延期。

(2)过程项

安全任务落实情况,正向指标。通过OA流程发起的落实合规监管、安全推动等任务的完成情况,每次任务完成情况综合评价(时间、质量)。


3.2.2 考核周期、考核权重、考核分数


一般是以自然年为考核周期。考核权重一般占IT部门各团队的5%绩效。以百分制计算为5分。

3.3 个人考核


个人考核,主要是制定安全团队成员的个人考核。一般遵循几个原则:


(1)结果第一,过程也是为结果服务,能力必须通过结果体现。


(2)职责和职级匹配,如果一个员工是10万薪酬的职级,却和20万,30万员工的职责相同,放在同一级别池子里考核,这是不公平的。薪酬高的员工,就应承担同等薪酬的职责和绩效考核。如果是骨干员工,发展对象,除了上述职责职级匹配外,还需要额外付出。


(3)建设性、事务性工作结合,工作和学习结合,多维度考核。


在上述原则指导下,每年会和员工沟通,确定绩效考核年度目标,包含:安全性(30%)、安全建设重点项目(30%)、督办事项(5%)、技术创新(10%)、常态化工作(5%)、人才成长(10%)、满意度(10%)。


安全性,和整个安全团队安全事件数量等安全结果指标挂钩,同时和该员工负责的领域的安全结果挂钩。


安全建设重点项目,项目来自于前一年修订的安全三年规划,以及实际中爆发的安全威胁。每人承担2-3项安全重点建设项目。考核时兼顾项目完成质量、取得的收益(效率提升,还是安全管控质量提升等)、获得部门认可等。


技术创新,激励安全团队员工进行新技术跟踪、研究报告撰写和分享,新技术测试和引入等,哪怕是开展一次有质量的头脑风暴和组织一次有效果的安全活动,都转换成技术创新积分,获得技术创新绩效。


督办事项:大部分工作在年初制定绩效考核目标时能确定,但总是会临时出现一些工作,比如检查配合、应急处置等。这部分工作放入督办事项中考核。

常态化工作:安全工作中有很多常态化工作,每位安全团队成员都应承担一部分常态化工作,比如日常报表、安全事件日例会等,常态化工作主要考核差错情况。


人才成长:除了工作,还要督促团队成员参加各类培训,考取各类认证,以及看书学习。企业安全建设的安全人员,容易脱离实战,因此定期参加攻防对抗的培训,考取诸如CEH等实战类的认证,对安全团队成员发展有利,同时还应鼓励团队成员提升非安全技能的软性技能,比如沟通、逻辑、表达、战略、规划等方面能力,督促员工多看书多学习。


满意度:团队协作、沟通配合等方面的考核放入满意度,满意度是考核的一个维度,也是员工专业性、协作、态度等多方面的综合表现。


3.4 一些细节


3.4.1 考核Tips


实际安全考核中有几个小的注意点。


(1)防止恶性竞争,比如有的考核项是计算数量的,要设置一个数量上限,防范恶性竞争的问题。比如设置了一个安全知识库数量的考核,要同时设置一个数量上限,比如以团队为考核单位,最多2条,超过2条即可拿满分,否则容易造成各团队恶性竞争。


(2)大小团队规模不均带来的公平性问题,漏洞考核时一般会给各团队漏洞数量豁免,豁免数量要考虑大小团队规模,维护的系统数量等实际情况,不能一刀切。


3.4.2  防止秋后算账


考核是手段,而非目的。考核的目的是希望通过考核,促进各团队的安全规则落地。因此在发生安全事件,出现安全漏洞,不合规情况时,要立即进行考核通报,防止年终一次性计算,要即时结账,不要秋后算账的另一好处是,落后的团队看到排名和不好的结果,还可以努力补救,这也达到了考核的目的。


3.4.3 5%实现100%的效果


安全考核对平行团队考核虽然只有5%,但要发挥出100%的效果。这需要整个考核体系的支持和配合。在我经历过的企业中,就可以达到这个效果,因为强制排名。每个团队是强制排名的,也就是即时只比前一名的团队少0.1的得分,但因为是强制排名,最终可能获得的优秀指标就会少50%,从而每个团队对每0.1分的考核都不敢掉以轻心,5%实现100%的效果。


3.4.4 正向还是负向激励


多用正向激励,慎用负向激励。负向激励可转化为正向激励。有两种方式转化:

(1)如果考核在【-X,+Y】区间,那么设置考核分数为【0,X+Y】的效果要比【-X,+Y】好很多。因为【0,X+Y】全部为得分项,属于正向激励。


(2)考核完成时间的,在规定时间内完成,要么减免50%扣分,要么增加一倍加分。比如在修复周期内完成修复,漏洞考核减免50%扣分。这样起到了正向激励的作用,既督促了大家,也达到了安全考核目标。


4.考核相关


4.1 如何推动工作


职业生涯之初我自己,以及现在做企业安全负责人遇到团队成员,都或多或少会有一些困惑,怎么说服别人支持自己,以推动安全工作?如果资源是无限的,每个人完成了配合工作,都可以发一枚钻石,那这个就简单了,可惜资源是有限的。正因为资源是有限的,因此我们要多喂免费的胡萝卜。


胡萝卜,在管理学的范畴中,被引申为有效的赏识和奖励机制,员工都渴求这种机制的感应和刺激。能力是否得到上司认可,这关系到员工是否要改换门庭——寻找他们能够得到承认和赏识的更好的职场环境。所以,为了留住卓越的员工,保持中坚力量的稳定,领导者就必须在企业内部营造胡萝卜文化,吸纳人才,并努力使团队更多地活跃在达观和愉悦的工作环境中。除了对团队成员喂胡萝卜有效,对推动工作相关的任何干系人都有效。关注该领域的参考《24只胡萝卜的管理》。


在安全建设推动工作中有哪些免费的胡萝卜呢?表扬、排名、通报、扣分、给荣誉奖项等等都是可行的。


除了上述推动工作方式以外,我个人还喜欢的一点就是跑的勤快一点。人怕见面,树怕剥皮,为了推动工作,达到想要的目标,找到关键干系人,一次不行,两次,两次不行再来,多去找几次,见面谈,成功概率很大的。我特别不提倡的就是发邮件、发微信、打电话,和别人谈很重要的工作,以及别人拒绝的工作沟通,这种需要硬啃的山头,一定要拿出自己的诚意,让别人看到自己的付出和努力,发发邮件、打打电话的方式不可取。

4.2 要不要满意度


以目前国内企业对安全的认知,安全团队不太可能获得好的满意度。反倒是满意度高的安全团队要思考一下,大BOSS会怎么想。我自己的实际经历来看,满意度高的团队绩效表现一般都比较平庸甚至较低。满意度实际是多方维度,平行团队对你的满意度和上级对安全团队的满意度,以及团队成员对安全团队的满意度,三者都需要考虑。我一般考虑的优先级是上级对安全团队满意度>安全团队成员对安全团队满意度>平行团队对安全团队满意度。


上级对安全团队的满意度,其实就是安全团队的价值,安全团队的绩效。得有价值,作出成绩,解决问题,才能满意,这个道理简单易懂。


安全团队成员对安全团队的满意度,其实很重要。满意度不高,团队容易一团散沙,瞬间分崩离析,肯定也不会取得好的安全绩效。这就要求安全负责人要研究怎么满足安全团队成员的满意度。我个人的亲身体会(包括我自己做员工)是,要让团队成员个人价值得到成长提升,能够通过自己的辛勤劳动获得体面的收入,同时能够收获尊重和认可。价值提升和体面收入,一个是长期收益,一个是短期收益,有眼光的人会优先关注长期收益。我经常和团队成员沟通,要有危机感,不要有太多优越感。大家可以多想想,如果公司不是只有一个安全团队,我们如果不是垄断,我们的用户会不会买我们的服务?把我们自己放互联网企业、制造企业,我们会不会适应快节奏、低成本、一切都围绕有效来开展工作?


平行团队对安全团队满意度,如果安全团队做出价值,为公司、部门和平行团队带来安全保障,我相信有格局的管理者会给出公平的满意度评价,即使有时候由于各种主观客观原因,对安全团队的打分评价不是很客观,我倒也觉得能理解。这个满意度的关键还是在于大BOSS怎么看,如果安全团队做的很糟糕,即使大家给安全团队满意度很高,结果也不会好。如果安全团队做的很好,同时还能影响和照顾平行团队的诉求,满意度虽然不一定会很高,但至少不会排名倒数第一,反正我多年来的体会就是,我从倒数第一满意度努力到倒数第二,就是成功。在成为倒数第一的时候,我并没有很生气,至少说明两点:


  1. 安全管控实实在在,不再是可有可无;

  2. 安全肯定有很大改进提升空间。


接下来的事也挺简单,和平行团队沟通,哪些是可以改进优化的改进优化,按这个思路,第二年基本就不会倒数第一了。


4.3 内部问责


有了考核,有了排名、通报,还需不需要内部问责。我的建议是:需要。在安全这个需要认真来不得半点敷衍的领域,规则+检查是最好的落地方法。约定达成一致的安全规则,强有力的检查发现违反规则的行为,并进行考核,对于违反红线的,进行内部问责。内部问责是高压线。


吴瀚清先生在《白帽子讲Web安全》讲安全开发流程(SDL)中提到SDL实战经验的四条准则,第三条是树立安全部门的权威、项目必须由安全部门审核完成后才能发布。如果没有这样的权威,安全就变成了可有可无的东西。当然,这句话并非绝对,在树立安全部门权威的同时,安全也可能对业务拖鞋。比如对于不是非常严重的问题,在业务时间压力非常大的情况下,可以考虑事后再进行修补,或者使用临时方案应对紧急情况。安全最终是需要为业务服务的。


4.4 安全考核,没有唯一标准答案,在于实践


我想再强调一遍:安全考核,属于企业评价体系的一部分。安全考核不可能脱离企业评价体系而单独存在,而企业评价体系有各种风格,各种实际情况,和企业的文化、风格、所属行业等因素皆相关,因此安全考核注定没有一份唯一的标准答案,但坚持实践一定会得到你想要的最好答案,路径是日拱一卒。这也是我一直关注和致力于推动的企业安全建设实践系列话题,本文也如此。


5. 附录


5.1 信息安全事件与安全合规不符合项分级定义(示例,供参考)


5.1.1 安全事件信息安全事件分级:包括重大事件、较大事件、一般事件三级:


(1)重大事件


  • 被行业监管部门、公司内控部门通报或批评;

  • 被行业权威部门发现系统漏洞或风险(中证信息、公共漏洞平台),且存在重大隐患或已造成重大损失;

  • 行业《信息安全事件报告及调查处理办法》中定义的特别重大事件、重大事件;

  • 安全检测(内部、外部)中发现的因违反安全管理规范或开发规范等相关要求,产生的重大安全隐患或高风险系统漏洞。

 

(2)较大事件


  • 被外部单位发现系统漏洞或风险,且存在较大隐患;

  • 行业《信息安全事件报告及调查处理办法》中定义的较大事件;

  • 安全检测(内部、外部)中发现的因违反安全管理规范或开发规范等相关要求,产生的较大安全隐患或中风险系统漏洞。


(3) 一般事件


  • 部门内部通报;

  • 行业《信息安全事件报告及调查处理办法》中定义的一般事件;

  • 安全检测(内部、外部)中发现的因违反安全管理规范或开发规范等相关要求,产生的一般安全隐患。


5.1.2 安全合规检查不符合项(含内审、风险评估等)分级(示例,供参考)


按不符合项对应标准的相关级别分为严重、一般、轻微三级。


(1)严重不符合


  • 不符合监管部门发布的相关制度、办法及指引中操作类要求;

  • 不符合公司发布的相关制度、办法中相关要求;

  • 不符合安全规范要求,且存在重大隐患;


(2)一般不符合


  • 不符合公司发布的各类操作指引、技术规范;

  • 不符合安全规范要求,且存在较大隐患;


(3)轻微不符合


  • 不符合部门发布的各类细则、指引、规范;

  • 不符合部门内部安全管理要求。


5.2 信息系统漏洞分级标准定义(示例,供参考)


风险等级

描 述

严重

  1. 直接获取重要系统权限的漏洞(服务器权限、PC客户端权限)。包括但不仅限于远程命令执行、任意代码执行、上传获取WebshellSQL注入获取系统权限、缓冲区溢出(包括可利用的 ActiveX缓冲区溢出)。

  2. 直接导致业务拒绝服务的漏洞。包括但不仅限于直接导致移动网关业务API业务拒绝服务、网站应用拒绝服务等造成严重影响的远程拒绝服务漏洞。

  3. 严重的敏感信息泄漏。 可获取大量核心用户的身份信息、订单信息等接口问题引起的敏感信息泄露。

  4. 严重的逻辑设计缺陷和流程缺陷。包括但不仅限于通过业务接口批量发送任意伪造消息、任意账号行为操作、批量修改任意帐号密码漏洞。

高危

  1. 敏感信息泄漏。包括但不仅限于边缘系统的SQL注入、源代码压缩包泄漏、服务器应用加密可逆或明文、移动API访问摘要、硬编码等问题引起的敏感信息泄露。

  2. 敏感信息越权访问。包括但不仅限于绕过认证直接访问管理后台、后台弱密码、获取大量内网敏感信息的SSRF

  3. 直接获取系统权限的漏洞(移动客户端权限)。包括但不仅限于远程命令执行、任意代码执行。

  4. 越权敏感操作。包括但不仅限于账号越权修改重要信息、进行买卖普通操作、重要业务配置修改等较为重要的越权行为。

  5. 大范围影响用户的其他漏洞。包括但不仅限于可造成自动传播的重要页面的存储型XSS(包括存储型DOM-XSS)和涉及交易、资金、密码、CSRF

中危

  1. 需交互方可影响用户的漏洞。包括但不仅限于一般页面的、反射型 XSS(包括反射型 DOM-XSS)、重要操作CSRFURL跳转漏洞。

  2. 普通越权操作。包括但不仅限于不正确的直接对象引用。影响业务运行的Broadcast消息伪造等Android组件权限漏洞等。

  3. 普通信息泄漏。包括但不仅限于客户端明文存储密码、客户端密码明文传输以及web路径遍历、系统路径遍历。

  4. 普通的逻辑设计缺陷和流程缺陷。

低危

  1. 本地拒绝服务漏洞。包括但不仅限于客户端本地拒绝服务(解析文件格式、网络协议产生的崩溃),由Android组件权限暴露、普通应用权限引起的问题等。

  2. 轻微信息泄漏。包括但不仅限于路径信息泄漏、轻微敏感信息泄露,以及客户端应用本地:仅轻微泄漏数据库名称、字段名、cache内容、日志打印、配置信息、异常信息等。

  3. www.idc126.com

    难以利用但存在安全隐患的漏洞。包括但不仅限于无法利用的SQL注入点、不可引起传播和利用的Self-XSS

本文由来源 君哥的体历,由 congtou 整理编辑,其版权均为 君哥的体历 所有,文章内容系作者个人观点,不代表 华盟网 对观点赞同或支持。如需转载,请注明文章来源。
0

发表评论