安全专业人士在工作中可能会有一种虚假的安全感。如果想要维护企业安全，旧有安全方法和技术中有几处地方需要改进。
向云端迁移。安全左移。购买最新的XDR和欺骗工具。技术和网络安全行业总是容易受到市场炒作的影响，但这些举动真的让企业更安全了吗?或者说，这些动作不过是增加了复杂性?
从SolarWinds后门到微软Exchange漏洞，重大黑客事件层出不穷，安全专业人员怎么才能睡个好觉?他们总觉得自己在做正确的事，但这难道真的难道不是一种虚假的安全感吗?
Salt Security技术布道者Michael Isbitski表示，安全专业人员应该多加关注应用编程接口(API)安全，因为API支撑着上述很多技术策略。从托管内部云应用到依赖网关和传统补丁管理工具，旧有安全方法对API安全并未投入足够的重视，而API很容易遭到攻击者染指。
Isbitski称：“风险实在太大，企业应该老实承认自己在这些安全方法和工具选择上过于自信了。面对现代威胁，企业真的应该寻找相应的工具和过程更新方法。”
下面谨列出七条建议，帮助安全专业人员梳理部署安全概念和技术的过程中应该考虑的问题。
![]()
▶ 你构建的云应用真的安全吗?
随着迈向云端的步伐，企业在为云重新设计的安全工具上投入了大量资金，投资重点通常是云工作负载保护和容器安全工具。此类工具有助于识别已知脆弱依赖，检测错误配置，微分隔工作负载，以及防止偏离已确立的安全基线。但Kubernetes等平台中未修复的漏洞和错误配置一直以来都是攻击者的入口点，可供他们绕过访问控制，在被黑集群上执行恶意代码，以及部署加密货币挖矿机。
Isbitski说道：“很不幸，此类新型云安全工具仍然无法解决很多应用层安全问题。这些工具主要解决的是网络安全和基础设施安全，却将应用安全继续置于脆弱境地。所以，公有云可能是安全的，但这并不意味着你内部构建的应用是安全的。”
▶ 安全可以左移，但也必须右移
左移概念鼓励开发团队将安全过程和工具尽早纳入软件开发生命周期(SDLC)，并传播安全专业技术知识。左移与DevSecOps实践紧密相关，而后者的目标是在设计、构建和部署阶段集成和自动化安全。DevSecOps实践为很多企业带来了丰厚回报，因为采用此实践的企业能够更快速地迭代安全，验证是否从一开始就恰当构建了安全，还能减少SDLC后期修复漏的开支。
然而，企业无法以运行时安全为代价整体左移。开发人员不可能编写出完美代码，也无法在发布窗口期内充分细致地扫描代码，而且扫描器从设计上就是用来发现遵循明确模式的已知漏洞或弱点的。
安全左移从来就不是只意味着“左移”。但是，有利的一面是，左移确实让开发团队能够更快找到并修复大量安全漏洞。
新型攻击和零日漏洞总会出现，生产中的应用也需要保护。很多公司应该不会左移到将运行时安全排除在外。大多数人已经意识到首尾两端均需兼顾了。
▶ WAF和网关无法全面保护API
API是当今现代应用的基础，但只有少数企业真正认识到API的重要性或其呈现的风险水平。API对攻击者的吸引力太大了，以致于承担了与自身体量很不相称的风险，但太多企业假定Web应用防火墙(WAF)和API网关能够充分保护自身API。实际上，这些技术由于固有的设计局限而无法阻止绝大多数类型的API攻击，往往会给企业造成自身API和API驱动的应用很安全的虚假感觉。
API对每个企业而言都很特殊，针对API的真实攻击往往不遵循已知漏洞的明确模式。对抗这类安全风险需要运行时安全，运行时安全才能够持续学习API行为并尽早阻止攻击者，无论攻击者所用的攻击技术是哪种。
安全团队需利用WAF或API网关之外的技术解决API安全问题。
记得2005年左右还有人争论称，网关供应商会站出来满足对额外安全功能的需求，至少Apigee这家供应商确实发布了一个安全附加模块。然而，API安全毕竟很大程度上是一组独立供应商的专属领域，而不是API网关企业的专利。
企业通过API暴露出了大量应用和海量数据。API造成的数据泄露和未授权访问很常见。今天的API安全由大量工具组合构成：一些扩展到API防护的运行时应用安全工具，一些解决特定安全用例的API管理工具，可以测试API的应用安全测试工具，以及专用于API的安全工具。
▶ 传统补丁和漏洞管理工具无法保护API
尽管补丁和漏洞管理程序能够帮助安全团队应对现成软件和组件的安全风险，但应用和API安全策略需要的不止这些。
可惜，因为急于避免沦为99%的已知漏洞的受害者，企业将大量精力放在了补丁和漏洞管理上。已发布软件或硬件中定义明确的漏洞往往通过通用漏洞与暴露(CVE)分类法来跟踪记录。然而，这一分类法根本无法捕获企业在构建或集成应用与API时可能引入的各种潜在漏洞与弱点。
攻击者有时会以软件中众所周知的漏洞为目标，例如最近的Exchange服务器黑客攻击事件。不过，更为普遍的情况是，攻击者寻找目标企业特有的API或API集成中的漏洞。企业创建或集成的代码可没有“补丁”供安全工程师用来缝合应用与API。
通用缺陷列表(CWE)ID是更适合描述自主开发的应用与API中缺陷的分类法。如果企业自行开发代码或集成其他代码，那么安全人员应该很熟悉CWE和OWASP Top 10。这些都是更为相关的分类法，更适合自行构建应用或API而不是从使用CVE ID的其他地方采购的情况。
cwe.mitre.org表示，CWE可帮助开发人员和安全从业者做到以下事项：
- 以通用语言描述和讨论软件及硬件缺陷。
- 检查现有软件及硬件产品中的缺陷。
- 评估针对这些缺陷的工具的覆盖率。
- 利用通用基准执行缺陷识别、缓解和预防。
- 在部署前防止软件及硬件漏洞。
▶ 基本安全意识培训远远不够，尤其是针对工程师的培训
安全意识培训的重点往往围绕勒索软件攻击、网络钓鱼和社会工程攻击，因为这些技术是攻击者常会利用的。
企业往往过于自信此类意识培训能够实际改变员工行为的程度了。太多企业采用的是照单划勾的方法，往往每年通过第三方搞个一两次培训，确保员工都参加了这个培训，然后就将之抛诸脑后，直到下一次培训期到了再走一次过场。
这显然远远不够，老实说，完全是在浪费时间。专注即时安全培训会好上很多，能够改变员工的行为，让他们以更具安全思维的方式工作。
很多企业的应用安全培训和意识仍落后于时代。随着应用发布节奏加快，开发人员和工程师往往根本没有时间参加培训。即使挤出时间学习，这些人也只会专注自己的技术栈，安全在很大程度上沦为了一项事后考虑。
大多数企业仍然缺乏安全专业知识，尤其是在“全栈”工程这方面。这就造成非安全人员在创建或更新应用时几乎没有安全指南。敏捷方法论和开发运维实践导致的开发和发布时间线压缩，也没给安全设计审查或威胁建模演练等安全培训和意识本可以产生成效的方面留下多少时间。
缺乏时间一直是一项安全挑战，但开发生命周期中的安全左移不可避免;安全不能一直是事后考虑，从组织的角度考虑，为什么不前期构建安全呢?
事前预防可比安全事件或数据泄露发生后再补救省钱多了。但这确实需要给开发人员留出时间来培训和学习，也需要开发人员愿意这么做。意识培训不是一朝一夕之功。
▶ 仅仅购买新工具并不能保护企业安全
企业往往会觉得只要购买了最新、最热门的安全工具就能保障安全了，但事实并非如此。
优秀人才的招募和保留颇不容易，所以企业购买的新工具相当程度上管理得并不恰当，管理员经常错误配置了这些工具。安全团队需要扪心自问：我们真的用的是最新版本吗?我们确实充分利用了新产品的所有功能?某些规则是不是在更新过程中被重写了?
很多人都觉得靠买买买就能解决安全问题。但很不幸，多数情况下，最初安装产品的人早已离职。这就是为什么有时候可能会有1000条规则放在那儿，现任管理员碰都不敢碰。他们害怕一旦动了会不会搞掉一些非常重要的东西。改一行代码就导致整个系统崩溃这种事，大家就算没经历过也听说过很多了。
企业还需要员工具备软技能：遵循规程、阅读文档、向管理层报告/沟通问题。
另外，很多人都会认为所有这些新产品肯定是完全集成的。这也是扩展检测与响应(XDR)兴起的原因之一，因为XDR基本上就是包含了端点、网络和云威胁检测与响应的预集成解决方案。
但不管怎么说，安全问题总归是个难题。所以，托管安全服务仍在发展，甚至顶级供应商都还在不断推出托管服务。他们认识到，无论自己的产品平台多么集成和有效，还是有越来越多的CISO想要尽可能多地外包技术的管理。而且这种趋势可能会随时间稳步发展。
▶ 推出物联网产品的企业未必关注安全
企业的关注点可能落在制造汽车、电子消费品或家用电器上，未必总能意识到自己理应多投入点时间和金钱在这些产品及其集成移动应用的代码开发与管理方面。
计算发展演进到今天就是这样。不从事软件开发业务的公司如今也在开发应用和API来驱动自身核心业务了。但企业并非总能认识到自己应该保护好支撑着这么多物联网设备的API和应用。
围绕物联网的漏洞真的太多了。随着5G在美国和很多发达国家的铺开，各种类型物联网设备的泛在连接将不仅仅是可能，而是会成为标准操作。而许多此类设备不仅没有内置安全功能，还从开发伊始就没考虑过安全。
因此，如果缺乏良好的5G物联网防护，物联网僵尸网络可能会卷土重来，尤其是在对很多黑客而言僵尸网络驱动的加密货币挖矿越来越有利可图的情况下。未来十年，物联网可能是网络安全叙事的重点之一。
