0x1本周话题TOP3
话题1：大佬们，有个问题：老板要求自研开发主管在互联网系统渗透上不能有高危，除了我每次调级别，我还能怎么帮助他们？我现在想的是在开发需求阶段让他们做威胁建模，然后根据输出做开发，虽然渗透是定期工作，有版本跨度，但是会好很多。
A1:很合理的要求，每次调级别，比如把什么调成什么呢。协商以后调级。
A2:感觉老板在帮你，你有啥为难的？有高危漏洞让开发修呀，老板意思是安全咋没发现？谁也不能不保证开发的系统没漏洞吧。微软谷歌也不敢保证。
A3:哪家公司啥级别的老板，说出来让大家躲着点。是不是要求不能带着高危投产？
A4:威胁建模，安全开发只是降低出现高危的概率，老板的不断前置思路挺好的啊，安全工作也好推。不带高危投产，是自己内部测试发现，没发现不就行了。
Q:是不是要引导一下老板，是有高危不上线就好？
A5:那不行，没精力。只能3个月搞一次渗透，后面代码审计定策略，有问题不能合代码，iast要跟集团策略走。
A6:是不是可以先分析下现在暴露的高危漏洞主要是哪几类？先做专项处理更容易见效些？一下子搞太大不容易推下去。
A7:所以我觉得能做的就是威胁建模，先降低点概率。
A8:只能尽量减少漏洞，在漏洞发现之后，老板能帮助推动开发尽快修复就很不错了。
A9:那不至于，我们很自觉。高危2周必须修完，就是见不得高危。最近来交流的我都会问，我们2周一个版本，会加多少时间。
A10:威胁建模的成本是非常高的，可能会极大的降低开发效率。建模时间可能比开发时间少不了多少。而且现在威胁建模也没有啥好用的工具吧。
A11:是啊，一开始和某人工服务的聊感觉有点累。最近有两家有工具，上去做做问卷就有输出，感觉效率大增。无非就是知识库？没做过，理想好像还行。
A12:关键是输出的东西开发能不能理解。
A13:2周一个版本，时间上还是蛮长的，黑灰白+人工，日常版本发布前做安全测试，除了例行版本，定期对未发版的系统专项滚动测。内部发现高危，总比被外面搞个高危好。安全需求，设计啊，能理解多少是多少，做好检测验证。不能指望全部解决，安全还是要有点玄学的。
A14:需求+白+定期黑，应该比较适合我们这种小公司，对吧。理论上没错可以搞一下？请开发搞，满足开发和安全的需求。
项目立项需求和迭代需求，我就数有几个安全功能点，不够数就退回。
A15:威胁建模好是好，一般规模的公司难有合格的威胁建模人员，我当时想要么就搞个checklist对一对。
A16:简单直接，换成安全，同样适用。
A17:问卷式的输出还是要先梳理常见场景，最好结合业务系统和常出现的漏洞，不然使用起来还是难受。
Q:哦，意思是，领导要求不能带病上线，业务就都来找安全测，但安全的资源不足应付不过来？为啥不是借机扩大资源，要人要资源？
A18:可以这么理解，但是主要还是靠开发自己先搞一波，小公司也没那么多精力投这上面。另外关于要人要资源这个问题很深，很难讲，不患寡而患不均。
A19:威胁建模、代码审计、黑盒测试...啥都可以做，不过有先后顺序，顺序就在于现有资源能不能覆盖住老板的要求。比如要求的系统梳理、发版情况、高危漏洞种类及级别定义，仅从满足老板的要求来看，白盒测试才是发现漏洞最多的方法，白黑盒都做好了，再威胁建模，或者其实不用到建模，就做个架构评审，效果也是不错的。
Q:你们威胁建模是哪些人做呀？
A20:现在做的产品不多，但是已经计划明年铺开做了。我们和公司的技术委员会合作，一起推架构评审，安全部分就是我们负责，其中一块就是威胁建模。之前是安全拉上业务开发在做，即将变为安全出威胁库、消减库，交给架构师团队来做，架构师团队来自各个产品线的开发大拿。
A21:有点厉害，威胁建模这个名字起的有点牛逼。回村的叫法就是安全需求点评审吗？安全需求点确定？安全大厂可能真的做建模，金融业半买半自研，命运不在自己手上。
Q:消减库是一般包含了哪些东西？消减库就是安全需求点吧，你们还需要威胁库出给开发吗？
A22:威胁库就是存在的风险点，每个业务不一样会有一些新的内容需要完善；消减库就是针对风险的修复或缓解措施，一一对应的。这里的安全需求是指安全设计checklist里面的要求？如果是的话，那我理解是消减库中的措施可能就是安全需求的细化、场景化的可操作方法。
A23:我是这么理解的：系统化的知识库、checklist，可以选择。
Q:是的，我理解的消减库也是针对风险的修复或缓解措施，但是我们是作为需求的，比如双因素的认证，所以刚才不太明白为什么安全要出威胁库给架构师团队来做。
A24:安全不了解业务，但是可以把安全的内容交给架构师去做，他们更清楚业务场景、懂数据流，这样做会更细。例子中的认证，其实是比较好识别出来的安全问题或者风险，大多数系统都会有这个功能。但是对于一个业务系统而言，除了有一般用户认证之外，可能还有管理员认证、调用其他系统的API认证...，及时在checklist中有说明系统调用要认证，但是在执行的时候并不太好识别和检查。
A25:这是个好思路，那就需要对架构师多培训，帮助他们能识别安全威胁；那安全人员在后续的工作中有其他动作么？比如项目中架构师识别风险并改进，后面是安全人员来介入检查验证？
A26:调低漏洞级别要非常小心，一定要有合理原因，不如研发承诺一个比上线还晚的时间修复，或者分阶段修复，以应对将来出事情，安全背责任，或内审不过。否则不如不调，让业务或者产品接受高风险上线，写清楚接受高风险的理由。
安全左移成本很高，威胁建模和代码评审都非常费时间，而且对人的要求很高。威胁建模对架构要熟悉，代码评审都要会写代码。这些靠安全来做成本很高，市场上合适的人很少。靠研发来做很可能走过场，安全抽查都来不及做。靠工具误报率很高，还得靠人工看的。这是比较可行的做法，搞个安全开发checklist，先把大问题改掉。比如key写在代码里，请求返回里包含过多敏感信息。
A27:是的，最好能明确调级的规则，包括后续处置措施，拉着开发业务一起评审。上述2位大佬的办法对安全同学来说很具操作性，还有得做的就是说服或者有套机制让开发能配合落实checklist，不然开发和安全还是两张皮，漏洞依然重复出现。
A28:我们之前是把这套流程嵌入到开发里面去，最后要上线需要有安全的批准，否则上不了线。一定程度上能解决很多事情，但是开发心底还是觉得安全是绊脚石，增加他们很多的工作量，只有部分arch在不断的交流中开始慢慢支持安全工作，另外还有一个大的痛点就是威胁建模这块没有太合格的人来做这块，更多的是sme拿着总结的checklist来对一下。
A29:Checklist好是好，就是要投入人力去做验证，安全人少项目多的时候就难以应付。我们现在更多的是自查。
Q:有没有把安全的一些简单要求和checklist落到测试团队的实践？我一直觉得对于安全设计里面一些功能性安全要求，落在测试团队是可行的。
A30:IAST？应该是指让测试人员参与做安全需求分析吧？测试经过简单培训做点简单的安全验证是没问题的。checklist写成case。
A31:我觉得不一定非得IAST，例如安全设计里面有一些登录错误次数锁定、通信加密、一些业务逻辑上越权等，都可以给出一些方法后由测试团队接手。核心是得把相关团队都卷进来把工作分散出去，IAST是实现的一种工具。和测试团队老大讲的逻辑是，测试团队还能测试安全问题，增加了测试团队的技能和重要性。同理，给架构师团队讲安全设计逻辑，让架构师团队能在架构层面设计安全，他们的KPI上也是亮点。
上面是前几年给某大行做SDL时候的一些经验，我发现测试团队和架构师团队还蛮愿意接受的。不过我自己没在甲方落地经验，纸上谈兵。
A32:不知道我们现在做的能帮上你忙吗？我们目前在测试阶段，正在做主被动式扫描。测试人员的工作不是接入繁琐的IAST，而是通过鼠标点点就把大部分漏洞都发现了。
A33:这对于公司来说，整体比较经济，我们未来考虑让开发和测试持证上岗（安全发证）。上面方法挺好，但测试团队愿不愿意要看他们的KPI吧。如果安全测试不是他们的职责，估计没什么动力。
A34:核心逻辑是要把关联方都卷进来，不要都把握在安全团队自己手上。这个最好是直接和研发老大谈，我觉得对于一些安全重视的企业，再加上大家每年也有一些创新要求的，应该是可行的。也要看怎么说。还有个核心逻辑是要把这些业绩帮他们想好，而不是最后安全干得好都是安全团队的功劳。
A35:我们之前跟测试团队一起合作的点是，他们帮我们做一些自动化的回归测试，例如我们做BAS的数据安全演练、数据外泄演练、ATT&CK演练，最终先是通过安全团队蓝军进行手工演练，然后给测试团队进行自动化演练的覆盖。这个点我之前觉得配合的相当好。
A36:像通信加密、登录错误次数限制、逻辑越权，这些通过一些简单的操作，浏览器的开发者工具加上postman基本就能发现，这些工具对于测试来说很常用，关键是要让测试的意识从功能测试上升到安全功能测试，培训都是方式，关键是要测试团队配合并且认为安全测试也是他们的工作之一。
A37:还有修漏洞也是同理，能不能把这个修漏洞的功劳给到运维团队呢？例如让运维老大能给大老板讲，经过运维和安全团队良好的合作和共建，高危漏洞修复率100%。而不是安全团队自己去讲因为安全团队的功劳所以高危漏洞都修复了，这样运维团队觉得反正做好了功劳都是你的，那就你安全团队自己干吧。
A38:这个CASE就是测试团队的KPI是减少BUG，包括安全BUG，所以他们要进行自动化的合作，所以你想要找到不管运维、研发还是测试团队的共赢的点，要先找到能互相得利的点。例如金融里面，总说（也许不准确轻喷）研发和安全存在一些潜在的小冲突，后来了解了一下，如果研发担心影响业务，那就融入流程，减少打扰；如果研发担心总是修复漏洞，那就推动自动化修复；如果担心效率不行，那就提升效率，增强安全能力。
A39:这个好，给研发（包括外包）做一些基本的安全开发、安全漏洞培训和上岗认证，能避免不少低级问题，让安全人员将更多时间花在更有深度的问题上。曾经畅享对研发人员引入类似驾照积分的管理机制，精细化差异化管理，有点复杂暂时搁置。
A40:总有解决办法的，做安全的最怕站在自己的角度思考。我为了解决安全问题，你必须修复，不然被入侵数据泄露了，有风险（恐吓式）。安全恐吓式->安全共赢发展。
A41:企业越大，每个团队越需要一些创新和亮点，也希望承担的更多，不是绝对，但我觉得适用于大部分。安全要时刻想的是怎么让关联方能享受到干安全的事情带来的正向kpi的推动和汇报。别想着把功劳都抓在安全团队手上。从大老板的角度，肯定也希望看到的是各个团队能合作的更紧密一些。只要能通过这些事情帮到各个老大KPI的加分，还愁以后找干活人家不帮忙？
再往前走一步，将常用的安全控制机制组件化，推广组件减少研发犯错误机会，同时提高效率，避免重复工作，双赢。
A42:能力嵌入开发流程，提升各个环节的效率，能力具有很强的召准，逐步迭代，再加上外部的ASM攻击面+蓝军巡检发现一些经常出错的问题。这样慢慢安全就会提高水位。还有BAS做安全防御点的一些回归。持续验证安全现状，度量安全水位。核心就是提升安全水位，收敛安全风险（攻防侧），数据安全的稍微复杂一些。
A43:我们这边应用系统上的安全bug由业务团队和安全团队共担，每个业务线技术团队都背安全漏洞系数。安全和测试团队共同制定组件化安全测试用例，覆盖逻辑性强、出现频次高的漏洞。具体项目中由安全人员评估出安全风险点，再与测试用例编号对应，由测试团队执行安全测试用例，安全做check和定期批量验证测试。
Q:大家认为研发和安全之间的合作存在那些矛盾？又如何能通过什么手段快速解决？
-
研发比较关注功能性需求，非功能需求取决于公司或者部门文化；
-
修修补补这类后续维护性需求，研发的价值体现感较弱，投入意愿不强；
-
一般安全要求会拆分到不同团队，但安全价值比较难体现到各个团队的日常，没有较好的绑定关系；
-
不少问题需要从架构层面来解决，可能涉及较多的投入。
话题二：想咨询大佬们点问题：1、应用系统的安全测试，一般是开发部门负责还是安全部门负责？2、如果公司没有安全测试团队，想让安全部门的渗透来替代安全测试，作为安全部门该怎么办？3、大家如何看待安全测试和渗透测试的区别和联系？
A1:开发不能测试自己的内容，运动员不能兼任裁判员。上线前的安全测试归安全部门负责，过程中的安全测试开发部门负责。渗透测试可以作为上线前安全测试的一项；另外还有漏扫和checklist。渗透只是安全测试的一种。
A2:看是否愿意承担更多责任？若愿意自己承担下来，若不愿意安全团队赋能给开发部门，渗透不能替代安全测试，安全测试--黑白灰盒测试等，渗透只是其中之一。
A3:如果有测试部门，上线前可以让测试部门做。能做渗透就不错了…还要啥自行车。加个漏扫和代码扫描。安全部门主导安全测试，业务测试团队协助赋能，业务功能测试安全就不需要参与了。这个需要业务配合。
A4:先写渗透或者安全或者应用开发制度明确自己的职责，全公司征求意见并下发，如果这一关都过不了，就不用干了；然后抽点买设备的预算，买个红队服务干一干，结果发给boss 和开发领导；后面你就为所欲为了。讨论职责和边界没有意义，之前给某运营商干活的时候，安全部门是业务部门的爹，想怎么摆弄怎么摆弄；安全部门是要给业务评绩效的，何况某运营商的业务还不是开发人员，感觉这种安全管理才舒服。
A5:1.安全部门；2.可以；3.白盒和黑盒的关系，左移和右移的关系，内生和攻防的关系，互相补充的关系 初期先用安全渗透兜底，修漏洞修多了，负责的核心开发应该会有代码走读的要求，逐渐提炼为白盒要求，安全有资源了再补白盒流程很常见，问题导向。
A6:安全文化确实能体会出来的，我当时还是乙方，碰到某运营商项目，他们自家和外包的开发配合度太哇塞了。后来到甲方公司开发都是我爹，所以运营商间发展的瓶颈就看出来在哪里了。
A7:安全文化自上而下就好了，现在都是业务导向。安全部门做出了东西，再找ld审批拿“尚方宝剑”，否则上面都不会。可以考虑给测试同学进行安全赋能减少安全测试工作量。
Q:业务上线前安全测试没测出漏洞，这责任怎么划分啊？主要是业务逻辑漏洞没发现，责任怎么划分？
A8:测试流程是否合规，测试人员是否有资质，是否为业务逻辑问题。这种后续制定测试checklist，如果都测了可以免责。
A9:没有就免责，或者少扣钱。这种研发和安全共责吧？还有是不是外部测试，这也可以甩锅。
A10:看问题难度吧，靠扫描就能发现的漏洞估计要测试和研发一起背锅，如果是那种黑盒确实无法发现的，可能也会酌情划分吧，而且不建议一出问题就要考核吧。自己安全团队做的还是采购的第三方渗透测试服务？
A11:团队搞的互联网业务。安全测试这关不好过。在研究自己测还是找第三方。
A12:自己测和第三方测，对开发团队来讲，其实是绑定在一起的啊。无论如何，对于系统安全质量提升，也是一回事啊。
Q:话说遇到没法整改的高危漏洞，研发要求掩耳盗铃，怎么处理？感觉还是要找第三方兜底，对外的系统自己可以在测一遍，总有漏的时候。在前面加固，或者让领导接受风险，记得让他签个字。
A13:这问题是你们领导问的吧。上线前一是看是否做安全测试并出具报告了，自己做，第三方做，或者乙方自己提供我理解都可以。二是看checklist是否完备。至于测的好孬跟测试人员能力，强项以及他当时状态都有关系，谁也保不齐测完了就是没问题的，但是这么做我理解至少是合规的。如果想把这块做好还需要每季度，每次有较大的变更或新增功能时时都要做渗透测试的例行制度保证。还有哪天出来个struts2,fastjson的很多涉及的不都要整改了？
话题三：各位在渗透测试漏扫的时候，遇到Tomcat、weblogic、Nginx等组件的高危漏洞，这是让开发项目组统一立即修复呢？还是说如果是仅供内部访问的系统就暂时不修复不管了？还是采用定期更新组件库的方式让开发迭代更新这些组件版本？还是说找找有现成poc的高危漏洞就修复下？
A1:我们医院是定期打补丁，除非是高危漏洞。这个每个公司不一样，看你们规范怎么定的，另外看安全容忍度。有威胁监测吗？
A2:会被监管发现通报的，跟着官方升，内部的没有可利用payload那种可以定期。
A3:可以参考cvss打分。内部访问的系统，如果有对应临时消减措施，可以按项目节奏迭代更新。没有消减措施的话，高危还是尽快改。
A4:第一阶段，只曝远程代码执行级的高危漏洞，先和修复部门打招呼，定好计划再捅，这个阶段如果有人冒头质疑就打，上面说了蓝军亮剑一个意思，其它的漏洞不曝风险我担，这是我给大家提供的服务。第二阶段出标准或制度，我们是参考CNNVD，你可以拿自己适用的标准，然后依据资产重要性，漏洞危害，利用难度做笛卡尔积，大家应该见过那种梯形的风险评估图，结果就是上面说的互联网必修，rce必修，漏洞影响评级拉上应用形成小组，但标准是你出的，安全措施能降低漏洞级别，这也是大家对我的依赖，不想天天应急就上措施。不同级别有不同的修复时效要求，你可以根据自己情况定，比如低危随版本迭代也不是不行。经过这两个阶段后，我想不会有人挑战漏洞问题。
A5:漏洞修复一般两种：临时规避、永久修复。综合业务的重要与否、规范要求，按需升级，不同公司要求不一样，需要安全、业务达成一致，最后ld拍板。
A6:但一般可能不大会动了，升级其实并不容易，自研的好说，外购的更麻烦，以后万一版本太高的中间件不支持jdk8，还要升jdk版本，就像今年的spring4shell，jdk版本低的反倒不受影响，可想而知多少系统还在用jdk1.6呢。
A7:高危的，尤其是RCE可执行的，这种基本上都是0容忍的。越接近代码，安全人员更要有分析能力，评估影响，不要当甩手掌柜。嗯，现在发现的高危不是RCE，主要是一些拒绝服务、有条件的提权等的高危漏洞。
A8:如果有威胁（攻击）监测+漏洞情报，那么：1、先修有RCE，且监测到有尝试攻击的。2、再修有RCE，暂时未监测到攻击的。3、再修暂时未有RCE的。
A9:反过来想想jdk1.6估计漏洞也不少，升级的安全版本了吗。所以历史漏洞有的时候还要回看，应该建立企业基线，明确标准版本，非标准版本应该靠拢，外购软件应该不低于基线版本，外购应该包括升级费用，对于无维保的软件应该及时下线。
A10:这些可以先做一下安全层面防护，内部指定一个修复计划，给个修复期限内修复掉。可以做一些基础的访问限制先保护一下。
A11:现在是在第三个里想优先级，或者说想统筹看看怎么管理好，而不想一直在救火。你先把第三个里的列个list，然后根据生产＞一切的原则，优先生产环境的，其次其他环境的，生产环境里的，重要业务部分优先级高，边缘业务优先级低，再然后就是评估修复难度，拒绝工具和越权这类你给个大致修改方案和期限，正常点开发应该都会配合修的。
A12:扫出来的高危，是一旦被利用后危害高，缺少了资产重要性和利用难度属性。需要企业自身补全。就和数据分类一样，漏洞分类是为了采取不同的应对措施，如果所有都按高级别走，成本上扛不住。结果反而会怠慢应当应急的真正高危漏洞。就是说不能尽信乙方产品，它的评级纬度是缺失的，要套进自己的漏洞分级标准里。
A13:嗯，其实对于上线前发现的问题，强制一下开发部门也就修复了。但是又在想是否需要和架构人员同步下组件库，免得总是一个一个系统让项目组修复。大家的组件库版本是来开发维护的吗？还是安全提建议，然后开发定期升级版本？
A14:这个是个供应链安全的行业共性问题，我们是有负责PaaS的组件部门负责维护版本（可以理解为开发部门的），安全负责维护黑白名单（可信库），做机制的时候考虑增量和存量两部分，先从卡点上保证新增的不会再带病上线，再考虑存量的紧迫性，是随版本迭代还是分批推进等。
A15:第三类很麻烦，谨慎，不建议大规模、高要求的去做，做大了容易成为全公司的公敌。拒绝服务真能算高危么，我一直好奇这个。低危的，我们也是从镜像等源头处入手，而不是让应急。归根到底还是钱的问题。
A16:看实施难度和业务连续性要求，如果系统本身高可用做得好，对拒绝服务也有遏制能力，那可能就不是高危 如果业务死了影响很大，也真实可利用，那该高危就是高危。
A17:实际还是需要每个系统自己做适配验证自己提变更修复的，你这边留个台账统筹推进就好了。有中间件科室可以把这活转给他们。
A18:比方说有的服务是toB，他弄死了影响的是自己，影响不了别人，那你甚至可以接受这个风险。
A19:嗯 现在就是在对新增系统想是否需要严格避免带病上线，比如Nginx、Tomcat的拒绝服务、提权等的漏扫到的高危漏洞，如果想漏扫不出现此类问题，基本只能通过更新组件库中的组件版本来避免了。否则，一个个的要求项目组上线前打补丁也是很麻烦。还是说由于无法从外部直接访问到这些服务器，就不管……
A20:我们公司自己开发了一套，申请专利，产品化中。有客户端，有web的配套。单台 16C，32G，300G 固态，30 人在线，Win10。
A21:安全负责维护黑白名单（可信库）----这句话能否理解为就是 除最新版外， 特定组件的哪些版本没有特定类型的漏洞？嗯 现在确实是别人在做，但我这边感觉版本还是比较老，导致很多系统出现共性问题，所以才想从组件供应链角度来 高效解决问题。
A22:嗯，也发现了，谢谢提醒哈。所以现在只在项目组有能力做且我能卡点的一些系统做。我现在是分日常漏洞发现和上线前漏洞发现两条线的。上线前漏洞发现希望走的严格一些，因为这时候开发修复漏洞的意愿最强烈，不然没法上线。日常是根据资产价值、漏洞利用难度评估多些。
A23:tomcat ajp任意文件读取问题呢，ajp一般不对外的 大家都修了么。外网按高危，内网按中危推的修复。
0x2 本周精粹
休刊
0x3 群友分享
【安全资讯】
历时四年打磨，可信执行环境开源操作系统Occlum v1.0正式发布！
【安全技术】
-------------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
往期群周报：
A企业从B企业获取个人社保信息做营销，如果得到B企业的授权，这合法吗？如何管理开发人员的终端及其软件安装？| 总第175周
CSO入狱启示、如何防止门禁卡被复制、关于钓鱼演练的探讨，包括点击率、填写率、演练频率、意识培训和价值等 | 总第174周
关基检查之企业必须成立领导小组或者委员会类组织机构吗？数据出境有无自评估的方案？如何治理办公类合规软件？| 总第173周
如何进群？
如何下载群周报完整版？
请见下图：
原文始发于微信公众号（君哥的体历）：漏洞修复&安全左移探讨：如何解决互联网系统上线不能有高危漏洞的问题？安全与测试、研发合作有哪些矛盾？如何解决？ | 总第176周
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论