2022年，大量企业组织开始关注AppSec（应用程序系统的安全性），并将其作为保障组织数字化转型发展的推动因素。而在此前，AppSec往往被视为阻碍业务系统快捷运行的一种障碍。通过正确实施AppSec计划，不仅可以保障企业业务的稳定开展，而且可以避免安全攻击导致的财产和商誉损失。不过有安全研究人员表示，为了在2023年提高应用程序的安全性，企业组织应该为AppSec制定专门的事件响应计划。
AppSec威胁形势严峻
2022年初爆发的Log4j漏洞，让很多企业陷入了业务系统应用防护的困境，这突出表明了目前大多数的组织还不熟悉应用程序的构成组件，也没有找到在应用开发过程中保证安全性的方法。据Sonatype最新发布的AppSec态势研究报告研究认为，2023年的AppSec威胁形势将依然严峻，很多企业需要与不安全的应用程序、脆弱的软件组件以及易受攻击的云服务开展斗争。
报告数据显示，软件供应链攻击在2021年快速增长了633%，其中有41%的应用程序组件还是易受攻击的版本。与此同时，随着企业组织将IT基础设施迁移至云端，并采用更多的Web应用程序，这导致对API使用快速增长，平均每家企业使用了15,600个API。这也使得企业中的员工成为可被利用的攻击路径。攻击者可以通过勒索软件、恶意软件、网络钓鱼和诈骗等诸多手段，通过普通员工的人为错误达成攻击企图。
在2022年，有83%的受访企业遭受了基于电子邮件的网络钓鱼攻击，这很容易导致凭据失窃，继而危及Web应用程序和云基础设施。西班牙桑坦德银行（Banco Santander）网络安全研究全球主管Daniel Cuthbert认为，通过一些非常简单的社会工程技术就可以绕过企业多层应用安全措施，实现访问敏感数据、系统和网络的攻击目标，而对此的防范措施还很不完善。
除此之外，攻击者还专注于通过在网络边缘运行的许多安全控制来锁定应用程序。在2022年举行的Black Hat Asia会议上，研究人员就展示了通过WAF设备漏洞进行入侵攻击的方法。而在2021年12月，网络安全公司Claroty也同样演示了如何使用JSON绕过五款主流WAF产品进行模拟攻击。
制定专属事件响应计划
随着AppSec威胁变得越来越普遍，企业安全团队应该在应用系统安全事件响应方面做得更好。通过制定专门的AppSec事件响应计划，企业可以更好地应对AppSec威胁，为各种可能出现的应用系统攻击做好准备。主要原因包括：
- 软件开发成为新的攻击面：由于软件系统的研发速度不断加快，开发人员成为一个重要的攻击目标。根据供应链攻击防护的要求，企业安全团队需要对业务有更深入的了解，他们必须能够展示出具备数据管理和评估安全问题的领导力，而不是在安全攻击发生后成为研发部门的负担；
- 大规模灾难事件：供应链攻击通常是大规模灾难事件，可能在一次“攻击”中影响数千个组织。标准的安全事件响应计划通常不适用于需要外部协商的大规模应用系统安全事件。外部的安全专家们此时可能已经不堪重负，而企业组织却无法承担响应延迟的后果与损失；
- AppSec还是一个不成熟的领域：AppSec的重要性直到最近才得到企业组织的关注，这也是安全团队必须正视的客观现象，因此很多安全人员对这类威胁的认知并不全面。如今，随着应用程序攻击面不断扩大并在全球范围内相互交织，可用的解决方案和专有技术在能力上仍然存在不足；
- 攻击者并不需要先进的技术：由于企业缺乏足够的工具来保护行业免受供应链风险的影响，并且现有的安全工具仍然不够完善。这对攻击者而言是非常有利的，一旦攻击成功，他们可以从数千个组织获得重要数据，而非一个组织。在防御方面，组织对通过CI/CD构建的应用系统缺乏可见性，对开发过程的可见性更少，这使得保护AppSec非常困难。
事件响应是一项专业的工作，涉及大量的资源和策略，并非一蹴而就的，每个AppSec事件响应计划都只适合特定的组织。以下是针对恶意应用系统攻击（如ESLint攻击）的基本AppSec事件响应清单示例：
- 检查CI日志，查看恶意包的具体使用情况；
- 识别被恶意代码获取到访问权限的资产；
- 识别所有可能受到损害的凭据，并在相关环境中更新/轮换所有凭据；
- 识别所有提交了恶意包的相关开发人员，轮换相关凭据，并让安全或IT部门对其工作站进行调查；
- 通知研发部门（R&D）存在恶意包嫌疑，相关密钥需要尽快轮换；
- 审计对组织资产的所有访问。识别任何表明凭据使用被破坏的异常情况。在初始事件响应之后继续执行此步骤；
- 在采取以上步骤的同时，企业管理层应该考虑并起草一份针对攻击事件的公开回应，并让所有利益相关者和部门参与进来，共同完成后续的事件处置工作。
参考链接：
