开发人员和运维团队一起构建、发布和维护软件
发表时间:2023-12-02 20:05:49
文章来源:炫佑科技
浏览次数:117
菏泽炫佑科技
开发人员和运维团队一起构建、发布和维护软件
作者|
译者| 明治山
规划| 丁小云
我在网络安全领域工作了大约两年,学到了很多教训。 这段时间,我早上的作息基本保持不变,起床,喝杯咖啡,打开应用程序,欣赏每日新闻。 戴夫和他的团队在这些播客上做了很多工作。 多年来一直存在的问题是网络攻击、数据泄露以及大量个人身份信息被盗并在暗网上出售。
网络安全人才严重短缺,许多组织正在采取措施试图填补这一空白,甚至尝试培训和留住网络安全人才。 但事实是,开发人员的数量远远超过安全专业人员。 那么我们是如何陷入这种困境的呢? 更重要的是,业界正在采取哪些措施来解决跨平台和产品的网络安全问题?
从历史上看,许多组织都将安全问题视为事后的想法。 安全性始终是在开发结束时进行的检查,优先级*低,并且付出的努力很少。 这种开发团队与运营团队合作部署和维护软件的成功模式已广为人知。 开发人员和运营人员协作构建、发布和维护软件。 然而,安全往往不是优先考虑的问题。 此外,软件开发、部署和维护的复杂性不断增加。
如今,安全已不再是事后的想法,这已成为大多数技术领域专业人士的普遍共识。 事实上,人们已经注意到,在生产环境中修复安全缺陷的成本远高于在开发过程中修复安全缺陷的成本。 确保 SDLC 的每个阶段都考虑安全性正在成为标准做法。
安全和隐私是所有软件的必要组成部分,其重要性比以往任何时候都更高。 这是一个挑战,因为一夜之间改变过时的旧流程并不容易。 然而,随着安全事件数量的增加以及组织继续为数据泄露付出极高的成本,这种改变变得势在必行。 我们正在开展大量工作,以确保所有产品从概念阶段就考虑到安全性。 这通常称为左移安全性或。
大多数公司都努力为其客户提供安全的软件。 目前,新软件正在以闪电般的速度开发。 在许多情况下,开发人员几乎每小时都会向生产代码库推送新的更新。 确保创新不放缓和产品安全不受影响之间存在着复杂的平衡。 近年来开发人员和运维团队一起构建、发布和维护软件,甚至政府也一直在努力推动 SDLC 流程更加安全。 这催生了应用程序和软件供应链安全方面的新实践。
挑战
当前安全问题面临哪些挑战? 如果组织致力于提高安全性和隐私性,为什么开发的软件仍然容易受到攻击? 这个问题的答案可能很复杂。 可能有很多可能性,但在本文中,我将重点讨论大多数人可能会同意的几点。
《网络安全技术人才危机》
关于网络安全专业人员短缺的报道和讨论层出不穷。 这是导致大多数组织面临安全挑战的一个因素。
高级持续威胁
如今,国家支持的黑客攻击已成为常态。 这些老练的黑客一直在暗中制造破坏,破坏防御并造成混乱。
归因仍然是一个复杂的话题,但大多数安全研究人员将矛头指向某些亚洲和东欧行为者。 Andy 在他的《》一书中通过著名工业控制系统安全工程师 M. Lee 的**手资料提供了丰富的细节和见解。
勒索软件攻击
在过去几年中,针对各种组织和基础设施的勒索软件攻击有所增加。 这些勒索者入侵网络,加密数据,并要求支付巨额赎金以获得解密密钥。 Conti 勒索软件团伙可能是*多产的团伙,并与一些众所周知的、破坏性特别大的攻击有关。
云安全风险
大多数人可能还记得 One hack。 云平台的错误配置继续给组织带来重大的安全挑战。 如果云平台不提供适当的安全护栏,它可能会成为一些人所说的“狂野西部”。
软件供应链攻击
这个话题*近引起了很多人的关注。 不良行为者使用一些常见的方法来进行这些攻击:损害软件构建工具和/或基础设施,例如,攻击者通过受感染的 FTP 服务器发起攻击,将受感染的代码植入硬件或固件中,窃取代码签名证书,用于放置恶意应用程序进入应用程序下载商店和软件包存储库。
软件供应链的安全挑战
它是所有安全问题的解决方案吗? 不幸的是,答案是否定的。 没有什么灵丹妙药可以解决所有组织面临的所有安全挑战。 然而,毫无疑问,实践和确保软件供应链安全对于显着降低软件和应用安全风险起着关键作用。
提倡将安全性作为软件开发的每个阶段(从启动到发布)的考虑因素。 开发周期的每个阶段都会考虑安全性,我们采取了许多措施来推动这一趋势。 我公司*重视的两个是:
一般来说,为了实现这一目标,组织通常需要采用一组*佳实践来提高整个软件开发生命周期的安全性。 一些关键实践可以总结如下:
安全即代码
安全性应该集成到代码库中并被视为代码,安全策略将作为代码保存在版本控制系统中。 我们可以使用Chef和等代码驱动的配置管理工具轻松地在数百台服务器上设置标准化配置。 通过使用通用模板,可以*大限度地降低未打补丁的服务器被不良行为者利用的风险。 此外,这还可以*大限度地减少生产、测试和开发环境之间的差异。
您的托管环境的所有配置信息都在中央存储库中可见,并且处于版本控制之下。 这意味着当软件组件出现漏洞时,很容易知道哪个系统需要打补丁,也很容易推送补丁。
我曾经是云平台运营团队的成员。 当时,在云环境中启动虚拟机存在问题,我们需要一种方法来控制可以在环境中启动哪些类型和版本的 AMI。 我们的解决方案是根据CIS基准标准创建黄金镜像。 然后,我们实施了一些策略,限制虚拟机的创建仅使用特定的黄金 AMI。
*后,我们有一个遵循*佳实践的 EC2 实例。 为了进一步锁定,我们创建了模板来限制哪些策略可以附加到虚拟机。 为了实现我们的目标,我们使用这些模板和服务控制策略 (SCP) 作为安全创建虚拟机的标准方法。 我想通过这个故事强调的是,代码驱动的配置可用于实现自动化、标准化和安全的基础设施部署。
自动化安全测试
自动化安全测试应该成为持续集成和部署(CI/CD)管道的一部分,包括漏洞、代码质量和合规性测试。 通过使用自动化工具,我们通常可以对环境中的系统运行自动化渗透测试,作为自动化测试的一部分。
在担任网络安全工程师期间,我一直在管道中设置这些工具,其唯一目的是自动扫描应用程序中任何已知的 OWAST 十大漏洞。 OWASP Zap 是一个开源工具,可用于实现类似的结果。
当时,这产生了两个直接后果:开发人员对 OWASP 十大漏洞有了更好的了解,并在开发过程中积极尝试解决这些漏洞。 *重要的是,一些例行的安全任务被从已经捉襟见肘的应用程序安全团队中夺走了。 这是自动化测试如何在解决软件安全挑战方面发挥重要作用的一个例子。
持续监控
持续监控应用程序和基础设施对于实时检测和响应安全威胁至关重要。 一种流行的设计模式是使用集中式日志记录。 来自网络、基础设施和应用程序的日志被收集到一个中央位置以进行存储和分析。 这为团队提供了所有活动的统一视图,从而更容易主动检测、识别和响应事件。
本文详细介绍了一些用于实现集中式日志记录的免费解决方案。 日志记录是使用监控指标的基础。 2013 年 数据泄露事件经常被用作案例研究,以说明为什么在日志记录和监控方面进行适当的投资至关重要。
合作
开发、运营和安全团队之间的协作对于确保整个开发生命周期的安全至关重要。 许多公司已经采用了敏捷的工作方式,为团队在软件开发过程中提供了更大的灵活性,从而进一步促进了团队内部的协作。
主要目标之一是避免减慢交付速度。 是一种演进形式,使应用程序开发人员、软件发行商和安全团队能够更有效地协作,以更高的速度交付应用程序,同时遵守安全要求。 *终目标是实现大规模快速交付,同时确保相关不同团队之间的协作和自由交流想法。
安全培训和意识
为所有团队成员提供安全培训,以确保每个人都了解自己在确保安全方面的角色。 在我的**份与网络安全相关的工作中,我的主要任务之一是在组织内建立安全的编码文化。 我们决定对公司内部的开发人员进行大规模的培训,提高他们的安全意识。 我们这样做是因为,如果模拟网络钓鱼测试在大多数组织中都有效,那么同样的概念也适用于开发人员,即训练他们的眼睛识别常见问题。
这是一项相当艰巨的任务,*终我们通过两种方法实现了我们的目标。 一种是使用集成到 IDE 中的商业软件在开发人员编写代码时扫描代码,并向他们提供修复代码中安全缺陷的建议。 这项措施取得了巨大成功。
我们做的第二件事是为开发人员提供定期培训。 每两周我都会选择一个主题,准备一些幻灯片软件开发,并演示如何利用不同的安全错误配置来破坏基础设施。 实现这一目标的两个关键工具是 和 Web ,它们提供了有关 API 和 Web 安全配置错误的丰富实践。
当我离开时,这已经成为常态,开发人员对一些常见的安全错误配置更加敏感。 我们通过“夺旗”活动为获胜团队提供一些奖励,从而保持每个人的积极性。 这是我职业生涯中实施的*成功的实践之一,对于开发团队和安全团队来说都是双赢:开发人员获得了关键知识,而安全团队则减少了工作量。
防止软件供应链攻击
每当看到这几个字,我的大脑就会自动回想起2020年的攻击事件和2021年的Log4j漏洞。大多数安全领域的人都对这两起事件非常熟悉,不仅因为它们造成了巨大的破坏,还因为它们发生在圣诞假期! 由于这两起事件,有关软件安全供应链的话题受到了极大的关注。
关于软件供应链的讨论很多,但解决问题的实际行动却很少。 Log4j 漏洞引起的轩然大波似乎是推动组织采取行动所需的力量。 美国国家安全局一直在向开发者和组织提供如何更好地解决这一问题的建议。 但软件供应链安全问题不可能一朝一夕解决。 到目前为止,我们仍然看到有关恶意软件包甚至恶意应用程序进入 Play 商店的报告。
早在 2020 年,我正在阅读一篇博客,试图了解有关该主题的更多信息,并看到了一个与软件供应链的简单类比。 该博客作者将软件供应链攻击与古代王国进行了比较,敌人会在水井中投毒,使村庄变得虚弱而无法战斗。
供应链攻击的类比非常准确。 攻击者不需要危害许多不同的目标,他们只需要危害毫无戒心的受害者通常使用的一种东西。 做了这一步之后,攻击者后续的攻击就会变得更加容易,后续的Log4j漏洞就是这种情况。 考虑到当前软件的开发方式严重依赖开源库和软件包,这显然是极其危险的。
John P. Mello Jr. 的这篇文章提供了 10 个备受瞩目的软件供应链攻击案例,其中包括 2022 年袭击 Okta 的案例。从这篇博文来看,仅对 npm 和 Index (PyPI) 的攻击就影响了超过700,000 个用户。 在这种情况下,攻击者不需要攻击这 70 万受害者中的每一个,他们只需要找到一种方法来篡改第三方软件内置的组件,然后享受他们的战利品。 就像在井里投毒的比喻一样,任何使用受损软件包的人都会遭受被泄露的后果。 第三方风险评估现在在大多数组织中都是一件大事,但这仍然不能防止油井中毒。
*大的问题是,这些第三方库和包的安全性如何? 这是一个值得单独写一篇文章的主题,因为有太多内容要涵盖。 随着这个问题变得更加突出,政府和私人组织正在采取哪些措施来防止此类攻击的发生?
对于保证软件开发的安全性发挥着巨大的作用。 确保软件依赖包的安全也是防止大多数软件供应链攻击的关键。 威胁形势如何演变还有待观察,但目前我们必须专注于打好基础。
随着网络威胁的不断发展,我们必须将安全性融入到软件开发过程中。 是一种文化转变,促进协作、分担责任、持续改进,并将安全性融入到开发过程的每个阶段。 通过采用*佳实践,组织可以更快地构建更安全的软件并降低安全漏洞的风险,同时还可以改善团队协作并降低成本。
关于作者:
是思科的工程架构师和博主。 他*初在 PLC Kenya 工作,目前在 Cisco 工作,专注于设计和实施安全和隐私。 他在肯尼亚出生和长大,目前在波兰克拉科夫工作和生活。 他喜欢足球和一级方程式赛车,并且是一名狂热的航空迷。
原文链接:
炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等