精明的组织正在接受基础设施即代码的概念，正是像你这样的开发人员可以在制作安全代码方面做出重大贡献，甚至在构建应用程序之外。起初，这似乎是一条漫长的道路，但为了在同行中脱颖而出，这个旅程是值得的。

在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前，我想邀请你玩一个敏感数据存储漏洞的游戏化挑战；现在就玩，从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。

那是怎样的？如果你的知识需要一些努力，请继续阅读。

如今，在休息时对密码、个人信息和财务记录等关键数据进行加密是任何网络安全防御的基石。在很多方面，它既是最后一道防线，也是最好的保护方式之一。这是因为，即使攻击者能够突破其他防线并获得关键文件，只要它们被适当地散列和存储，就不会对他们有太大的好处。

这也是对恶意内部人员的坚实的二级保护，因为加密文件可以与网络的其他部分有单独的密钥或密码。在这种情况下，像系统管理员或破坏了管理员证书的黑客可能能够浏览到受保护的目录，但如果加密密钥被保存在其他地方，他们仍然无法解锁在那里发现的加密文件。

当然，所有的加密保护方法都依赖于拥有强大的加密标准，即使是最强大的计算机也无法破解。

为什么不安全的密码学是危险的？

谈到计算机技术，能够创建强大的加密算法和破解算法的能力已经竞争了很长时间。早在1977年，美国联邦政府就开发了数据加密标准（DES），这是一种56位的算法，鉴于计算机的相对功率，在当时被认为是安全的。

但是，计算机在不断发展，人们找到了将它们联网协作的方法，以进一步增加它们的力量。1999年，电子前线基金会与Distributed.net合作，在短短22小时内公开破解了一份受DES保护的文件的加密。突然间，任何受DES加密保护的文件都不再安全了。

信不信由你，一些组织仍然用DES算法或类似的弱加密保护来保护他们的重要文件。虽然1999年需要一个分布式网络来破解56位加密，但今天几乎任何足够强大的独立计算机只要有一点时间就能做到。黑客们还创造了由图形处理器单元（GPU）组成的专用破解机。这些GPU在这项任务上非常出色，获取和本地联网的成本相对较低。

如果你今天选择用不安全或弱的加密算法来保护你的重要文件，那么不用多久，大多数黑客就可以破解这些文件并使其可读。如果你遭受了数据泄露，那么你必须假设，如果文件没有得到充分的保护，最终会被破坏。

例如，下面的Kubernetes代码片段在NGINX ingress控制器层面使用了一种弱加密算法来保护信息。

apiVersion: v1
kind:ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers:DES-CBC3-SHA
ssl-protocols:"TLSv1.2"

在这个例子中，DES密码套件被用来保护信息。然而，攻击者可以轻易地破译它并获取敏感信息。

建议使用强密码算法。在下面的Kubernetes例子中，强密码套件被用来保护NGINX ingress控制器级别的信息。

apiVersion: v1
kind:ConfigMap
metadata:
name: nginx-load-balancer-conf
namespace: kube-system
data:
ssl-ciphers:|
ecdhe-ecdsa-aes256-gcm-sha384:ecdhe-rsa-aes256-gcm-sha384:
ecdhe-ecdsa-chacha20-poly1305:ecdhe-rsa-chacha20-poly1305:
ecdhe-ecdsa-es128-gcm-sha256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA256
ssl-protocols:"TLSv1.2"

在这个例子中，为了避免攻击者获得潜在的敏感信息，已经使用了一套强大的密码器。

用强大的加密技术保护关键信息

如今有了几乎无法破解的强大加密技术。2001年，美国国家标准与技术研究所（NIST）创造了一种新的加密技术来取代DES。它被称为高级加密标准（AES），使用三种不同的密钥长度，即128、192或256比特。256位的AES加密是最安全的，尽管鉴于今天的技术，所有这三种加密都被认为是几乎完全不可破解的。用超级计算机进行的测试发现，要破解大多数AES保护的文件，需要数千年的持续工作。

为了适当地保护关键文件，开发人员应首先识别它们。没有必要对网络上的所有文件进行加密，因为这样做可能会因为不断的加密和解密过程而降低操作速度。但像人事记录、客户数据和财务信息这样的关键文件需要充分的保护。从本质上讲，这是一个在安全和拥有一个可行的系统之间的平衡行为。

这些数据应该按照AES标准之一进行加密，对于不应该落入坏人手中的真正关键信息，甚至可以达到256位加密。

还有一点需要考虑的是，增加加密就像给网站增加更多的密码。这意味着，授权用户将需要跟踪加密密钥。为了防止这成为工作流程的瓶颈，考虑实施一个密钥管理平台来跟踪这些密钥并保证其安全。即使你最终没有使用集中的密钥管理，也要确保所有的密钥和密码都受到保护，以确保未经授权的用户不能进入你最安全的数据库。

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和你的客户免受其他安全缺陷的蹂躏。你也可以在Secure Code Warrior 培训平台中尝试演示IaC挑战，以保持你所有的网络安全技能得到磨练和更新。

当谈到在你自己的组织中部署安全的基础设施即代码时，你做得怎么样？这可能是一个学习曲线，但学习绳索将是一个很好的机会来提高你的技能，在你的同行中脱颖而出，并保持更多的最终用户数据安全。

在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前，我想邀请你玩一个敏感数据存储漏洞的游戏化挑战；现在就玩，从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。

那是怎样的？如果你的知识需要一些努力，请继续阅读。

如今，大多数计算机安全的关键涉及密码。即使采用了其他安全方法，如双因素认证或生物识别技术，大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说，密码是唯一使用的。

我们如此频繁地使用密码，以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击，甚至是胡乱猜测。当然，有些人仍然使用薄弱的密码，NordPass最近的一份报告就证明了这一点。很难相信，在2020年，人们仍然在使用12345以及其他一堆可猜测的单词，如巧克力、密码和上帝来保护他们最敏感的资产。

总有一些人不屑于使用强大的密码，但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则，密码需要至少八个字符，由大写和小写字母组成，至少需要一个数字和一个特殊字符。

糟糕的是，即使用户遵守了制作最强种类的密码的规则，但如果这些密码都以明文形式存储，也可能没有任何好处。如果黑客能够读取整个密码文件，12345这个密码就和Nuts53！SpiKe&Dog12一样糟糕。

为什么以明文方式存储密码是危险的？

以明文方式存储密码是不好的，因为它使系统和用户都处于危险之中。很明显，如果黑客能够找到并读取每一个用于访问系统的密码，那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户，并破坏整个系统或网站。而且，由于他们会使用适当的用户名和密码，内部安全可能不会发现入侵行为，或在损害发生后很久才发现。

让攻击者很容易窃取以明文存储的密码也会伤害到用户，因为很多人都会重复使用密码。因为我们让密码变得如此难以创建，所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件，他们几乎肯定会尝试使用相同的名字和密码访问其他系统，这使用户面临着二次犯罪的巨大风险。

不小心将密码存储在纯文本中是比较容易的，或者没有意识到这可能会在以后造成重大问题。例如，下面的代码是使用Terraform模板定义AWS资源时，用来存储密码的常见方法。

资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

在这个例子中，用于管理AWS中的MySQL数据库实例的密码是以明文存储的。这意味着任何有权限进入源代码库的人都可以阅读，甚至复制它。

保护密码因框架的不同而不同，但每个平台都存在保护方法。例如，MySQL密码可以存储在AWS Secrets Manager这样的安全存储中。

资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

在这个例子中，Terraform模板将从AWS Secrets Manager服务中获得密码，它将永远不会以明文形式存储在模板文件中。

通过避免明文存储来保护密码

密码是你的王国的钥匙，不应该以明文形式存储。即使是一个组织的内部人员也不应该访问一个大的、不受保护的密码库，这也不应该是一个公认的商业协议（现在有很多密码管理器允许加密的凭证共享--没有借口！）。还有一个危险是，恶意的内部人员会窥探文件，获得他们不应该获得的权限。

对于外部攻击，试想一下，如果通过像SQL注入漏洞这样简单的方法找到了进入你的数据库的后门，并且他们也获得了对存储密码的目录的访问权，这将是一个双重打击。你认为这有太多的错误步骤可以实现吗？可悲的是，这种情况正好发生在索尼2011年的漏洞中。超过一百万的客户密码是以明文形式存储的，Lulzsec黑客组织通过一个常见的SQL注入攻击进入了这些密码和更多的密码。

所有的密码都应该由支持框架中的任何防御措施来保护。对于Terraform来说，密码不应该被存储在模板文件中。建议使用AWS Secrets Manager或Azure Key Vault等安全存储，这取决于基础设施提供商。

迫使用户创建安全的密码是一个好主意，但你也需要在后端做你的工作。将密码从明文存储中分离出来，对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳；基本上，任何人都可以看到它们。当务之急是（尤其是在IaC环境中，突然有更多的人可以接触到敏感信息），对它们进行充分的散列，只有那些绝对需要访问的人才能被授予访问权。

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战，以保持你的所有网络安全技能得到磨练和更新。

任何在软件生产中工作过的人都可能意识到在考虑安全因素时可能出现的紧张关系，主要是在开发人员和审查其代码的安全专家之间。

在过去，开发团队尽可能晚地发布代码，故意缩短安全大师检查漏洞的时间，这并不罕见--毕竟，如果发生什么问题，这就会延迟发布，而且人们已经渴望继续前进，开始建立下一个令人敬畏的功能。然而，这最终产生了负面影响，因为当代码最终被检查时--有时是在外部漏洞已经发生之后--代码仍然会反弹到开发人员那里，他们的软件宝贝仍然被安全团队称为丑陋的，他们不得不放下一切去热修复他们几个月前最后接触的代码。

这种功能障碍今天仍在继续，但有一个巨大的问题：正在开发的代码要多得多，一旦发生数据泄露，社会就会面临更大的风险。我们不再有时间继续打这场古老的战役，在2020年，是时候我们都加入到反对坏人的同一阵营了。

我们必须达到这样一个阶段：安全被视为整个组织和整个SDLC的共同责任。当你致力于建立一个全面的、高度支持的DevSecOps环境时，这当然是可能的。更重要的是，当你用正确的培训和工具点燃开发团队的安全之火时，他们就会成为一股强大的力量，不仅可以压制bug，还可以为那些长期以来被分散的安全专家减轻负担。

我希望你能观看我最新的网络研讨会之一，如何将 "Sec "放入DevOps。

这是AllTheTalks24小时峰会活动的一部分，它深入探讨了。

• 为什么旧的开发方法学使安全最佳实践变得如此困难
• 为什么DevSecOps是阻止常见安全漏洞的最新游戏规则？
• 安全作为一种共同的责任在一个组织中是什么样子的
• 你如何能够让开发人员有信心地发送安全代码，而不牺牲他们所喜爱的东西（提示：是建立令人敬畏的功能）。

在那里见到你!

如今，对网络安全的威胁是无处不在和无情的。随着我们生活的更多方面被数字化，网络犯罪分子的赌注就越大--有太多的代码需要保持安全，而私人数据又太宝贵。而且，在程序部署后，试图跟上并防御攻击面的每一个方面，已经变得几乎不可能。

有一些方法可以缓解其中的一些症状，当精明的组织接受基础设施即代码（IaC）的概念时，其中一种方法就很明显了。当然，与任何开发一样，也有一些安全隐患需要克服。而且，由于开发人员正在开发产生重要基础设施的代码，以托管应用程序，因此安全意识在这个过程的每个阶段都是至关重要的。

那么，一个刚进入云服务器环境的开发者究竟该如何提高技能，学习绳索，并以更高的安全意识接近构建？我们创建了下一个Coders Conquer Security系列，以解决常见的IaC漏洞，接下来的几篇博客将重点介绍你--开发者--可以采取的步骤，开始在你自己的组织中部署安全的基础设施即代码。

让我们开始吧。

美国旧西部有一则寓言，说的是一个人偏执地认为土匪会袭击和抢劫他的家园。为了补偿，他投资了各种安全设施，如安装一个特别坚固的前门，用木板封住所有的窗户，并在方便的地方放了很多枪。有一天晚上，他在睡觉时还是被抢劫了，因为他忘了锁侧门。匪徒们只是发现了残缺的安全设施，并迅速利用了这一情况。

在你的基础设施中禁用安全功能就很像这样。即使你的网络有一个强大的安全基础设施，如果元素被禁用，它也没有什么好处。

在我们深入讨论之前，让我提出一个挑战。

访问上面的链接，你会被带到我们的游戏化培训平台，在那里你可以尝试打败一个被禁用的安全功能漏洞。(注意。它将在Kubernetes中打开，但使用下拉菜单，你可以从Docker、CloudFormation、Terraform和Ansible中选择）。)

你做得怎么样？如果你仍有一些工作要做，请继续阅读。

安全功能可以由于各种原因被禁用。对于一些应用程序和框架，它们可能被默认禁用，必须首先打开才能开始运行。也有可能是管理员禁用了特定的安全功能，以便更容易地执行某些任务而不被不断挑战或阻止，（例如，使AWS S3桶公开）。在他们的工作完成后，他们可能会忘记重新激活这些禁用的功能。他们也可能倾向于让它们处于关闭状态，以使他们将来的工作更容易。

为什么禁用的安全功能如此危险

有一个或多个禁用的安全功能是不好的，原因有几个。其一，安全功能被投入到基础设施资源中，以保护其免受已知的攻击、威胁或漏洞。如果它被禁用，那么它将无法保护你的资源。

攻击者总是试图首先找到容易利用的漏洞，甚至可能使用脚本来运行常见的弱点。这与小偷检查一条街上的所有汽车，看是否有车门没有上锁并不一样，这比砸窗容易得多。黑客可能会惊讶地发现，一个常见的安全防御是不活跃的。但当这种情况发生时，他们不会花很长时间来利用它。

其次，拥有良好的安全设施，然后禁用，会产生一种虚假的安全感。如果管理员不知道有人禁用了这些防御措施，他们可能会认为自己受到了保护，免受普通威胁。

作为一个攻击者如何利用被禁用的安全功能的例子，请考虑AWS S3的阻止公共访问的安全功能。通过Amazon S3阻止公共访问，账户管理员和桶主可以很容易地设置集中控制，以限制公众对其Amazon S3资源的访问。然而，一些管理员在访问S3桶时遇到问题，为了尽快完成任务，决定将其公开。如果他们忘记启用该安全功能，攻击者就可以完全访问存储在该S3桶中的信息，不仅造成信息泄露，而且由于数据传输费用而产生额外费用。

让我们比较一些真实世界的代码；看看这些CloudFormation的片段。

脆弱的。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status:已启用
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

安全。

CorporateBucket:
Type:AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status:Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm:"AES256"

防止禁用安全功能

阻止被禁用的安全功能对你的组织造成负面影响，既是一个政策问题，也是一个实践问题。应该有一个坚定的政策，规定只有在非常特殊的情况下才可以禁用安全功能。应该记录那些必须暂时禁用功能以解决问题或更新应用程序的事件。在所需的工作完成后，应检查这些功能，以确保它们已被完全重新激活。

如果为了简化操作而必须永久禁用某项安全功能，就应该为受影响的数据提供其他保护措施，以确保黑客在没有默认保护的情况下无法访问这些数据。如果一个需要的保护功能被禁用，那么攻击者找到那扇未锁的门并利用这种情况只是时间问题。

了解更多，挑战自己。

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。

准备好找到并修复这个漏洞了吗？是时候在Secure Code Warrior 平台上尝试IaC游戏化安全挑战，以保持你所有的网络安全技能得到磨练和更新。

这是一个每周一次的系列报道，涵盖了我们最重要的八个基础设施即代码的漏洞；请在下周查看更多内容。

现在是我们 "基础设施即代码 "系列的下一期，这些博客将把像你这样的开发人员在自己的组织内部署安全基础设施时的安全意识提高到一个全新的水平。

哦，对了......你在上一篇博客中的安全错误配置挑战中表现如何？如果你想现在就去解决一个缺失的功能级访问控制漏洞，请到平台上去。

上面的链接将带你到Kubernetes挑战，但一旦你进入该平台，使用下拉菜单选择Ansible、CloudFormation、Terraform或Docker。你可以选择）。)

今天部署的几乎每一个应用程序都有某种访问控制机制，检查用户是否有权限执行所要求的功能。在创建一个应用程序时，这几乎是良好的安全以及功能的基石。事实上，所有的网络应用都需要访问控制，以允许具有不同权限的用户使用该程序。

然而，当这些相同的访问控制验证功能没有在基础设施层面执行，或者配置错误时，就会出现问题。如果基础设施层面的访问控制不完善，就会使整个企业向黑客敞开大门，黑客可以利用这一漏洞作为他们的网关，进行未经授权的窥探或全面攻击。

事实上，利用缺失或错误配置的功能访问控制漏洞是非常容易的。攻击者甚至不需要太多技巧。他们只需要知道在支持应用程序的任何框架中，哪些命令可以执行功能。如果他们知道，这只是一个试验和错误的问题。他们可以不断地提交不应该被允许的请求，只要有一个成功，目标网站、应用程序、服务器，甚至整个网络都可能被暴露。

缺失的功能级访问控制漏洞是如何运作的？

有几种方法可以使功能级访问控制悄悄进入一个组织。例如，功能级访问可以留给应用程序，而不被底层基础设施所验证。或者，基础设施级别的访问控制可能被错误地配置。在某些情况下，管理员认为非授权用户不知道如何进入只有高级用户才能看到的基础设施资源，并使用 "隐蔽的安全 "模式，这很少奏效。

对于一个隐蔽性安全的例子，以下URL很可能容易受到攻击。

http://companywebsite.com/app/NormalUserHomepage

如果一个经过认证的用户采用了一种叫做 "强制URL浏览 "的技术，他们可以尝试到达一个只显示给管理员的页面。一个例子可能是。

http://companywebsite.com/app/AdminPages

如果没有服务器端的验证，他们将简单地显示管理页面（如果它的名字与请求相匹配），然后可以访问管理员在新页面上做的任何额外功能。如果服务器向攻击者返回一个 "未找到页面 "的错误，他们可以简单地继续尝试，直到他们弄清楚管理页面的任何名称。

对于攻击者来说，利用缺失的功能级访问控制是一个类似的过程。他们不是试图浏览未经授权的页面，而是发送功能请求。例如，他们可能试图创建一个具有管理员权限的新用户。因此，他们的请求将看起来像这样，这取决于框架。

POST/action/createuser name=hacker&pw=password&role=admin

如果不存在功能级别的访问控制，那么上面的例子将是成功的，一个新的管理员账户将被创建。一旦攻击者以新管理员的身份重新登录，他们将拥有与该网络或服务器上其他管理员相同的访问和权限。

修复缺失的功能级访问控制

由于攻击者很容易利用缺失的功能级访问控制漏洞，因此发现、修复和防止这些漏洞是至关重要的。值得庆幸的是，只要有一些知识和基本的 "基础设施即代码 "安全培训，这并不是一件太困难的事情。

主要的保护将来自于在基础设施层面实施基于角色的授权。不要相信应用程序会处理这个功能。即使他们这样做了，拥有基础设施方面的授权将确保没有任何遗漏。理想情况下，授权应该来自一个集中的位置（例如AWS IAM、Azure IAM等），它被内置到你的组织的日常工作中，并应用于每个新的应用程序。这些授权流程可以来自框架本身或任何数量的易于使用的外部模块。

最后，你的组织应该接受最小特权的概念。所有的行动和功能在默认情况下都应该被拒绝，授权过程用来给有效的用户做任何他们需要的事情。他们应该只被给予足够的权限来执行所需的功能，并且只在需要的时候才被授予。

缺少功能层面的访问控制可能是毁灭性的。但值得庆幸的是，通过在你的组织中建立良好的基础设施级授权实践，你可以很容易地防止这个问题的发生。

你认为你已经准备好在野外发现一个访问控制的错误了吗？比较一下这些Docker代码片段；一个有漏洞，一个安全。

脆弱的。

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

安全。

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

了解更多，挑战自我

请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。

如果你之前错过了，你可以在Secure Code Warrior 平台上尝试IaC的游戏化安全挑战，以保持你的所有网络安全技能得到磨练和更新。

敬请期待下一章!

这是关于组织内PCI-DSS合规性的迷你系列的第二部分。在这最后一章中，我们将详细介绍首席技术官和首席信息官如何从高层领导减少网络风险，并使这一过程无缝、成功......也许对开发人员来说还有一点乐趣。(你错过了第一部分吗？ 点击这里查看了解应用安全专家如何抓住这个机会，取得更好的安全成果）。)

PCI-DSS的最佳实践无疑是一项共同的责任，但CISO和CTO可以利用他们相当大的影响力，从顶层打造一个繁荣的、积极的安全计划。他们是网络安全信任和最终用户相关情绪的形象代言人，早期对意识的关注具有强大的涓滴效应，帮助开发人员和AppSec专业人员获得他们所需的知识、工具和支持，以促进公司内部的强大安全态势。

保持合规性很重要，但当每个人都同意 "为什么"，看到结果并以正确的方式进行培养时，一个项目可以超越立法，成为第二天性。

CTO和CISO在创造互信方面有作用

你最近是否上过一个网站，在交出你的信用卡信息时考虑再三？除非是为你当地的比萨店提供在线订购服务的看起来很粗糙的网络应用，否则你可能不会经常遇到这种情况，特别是在大型企业和家喻户晓的在线零售业。

当然，除非他们披露了数据泄露事件。

全球住宿业巨头万豪刚刚披露了他们在三年内的第二次违规事件，这次导致520万条客户记录被盗。这一次，似乎支付信息还不是抢劫的一部分，尽管他们在2018年发生的灾难性违规事件已经解决了这个问题；3.83亿客户被泄露，500万未加密的护照号码被盗，以及800万信用卡号码。

如果顾客对万豪品牌的信任度还没有降到最低的话，我敢说它很快就会跌到谷底。这就是那种让CISO夜不能寐的东西，因为他们觉得在对抗网络威胁的战争中是坐以待毙。看看Equifax、雅虎、索尼、塔吉特--这些只是一些经历过大规模漏洞的大公司，代表着数十亿被盗的数据记录，数千亿美元的损失，以及客户形状的洞，直接打穿了他们的经济心脏。这对企业来说是一场灾难（塔吉特公司在2014年的信息泄露事件后的一个季度内报告了4.4亿美元的利润暴跌），虽然个人通常不需要承担责任--毕竟，软件安全应该是一个共同的责任--但如果你当时碰巧在这些机构工作，你也不希望在本来光鲜的简历上出现这种情况。

在一个处理支付、敏感数据和作为积极客户情绪的无形黄金的组织中，放弃一个强大的安全计划来实现合规性，是一个公司不仅有风险，而且在创新方面严重滞后的标志。

每个人都应该关心客户/组织关系中的信任问题。

除了IT、开发和安全部门在漏洞发生后面临的压力和灾难外，信任因素是一个新公司长期成功的主要因素，也是一个成熟公司持续增长的主要因素。如果公司因失去信任而面临经济衰退，你显然会失去的是你的工作。

PCI-DSS法规要求企业承担责任--如上所述，忽视这些精心设计的计划会产生巨大的影响--但它们只与实施的安全计划以及在其中工作的人一样好。如果你认真对待这些规定，保持警惕，并为他人树立榜样，那么你就会以一种非常积极的方式使自己与众不同。

意识就是一切。

一个失败的安全意识计划会使大多数保持PCI兼容的尝试接近于无用。整个组织的安全意识构成了最佳实践指南的最关键部分；他们甚至提供了自己的培训模块，说明如何在跨职能的角色中实施安全意识，以及在做得好的企业中这是什么样子。

随着我们将DevSecOps作为当前安全软件开发的黄金标准--其中安全作为一种共同的责任是最基本的--企业必须花费时间、金钱和精力来确保每个人，包括供应商和承包商，都有安全意识并遵循最佳实践。

一个有安全意识的开发者就是一个合规的开发者（而要达到这个目标并不一定是枯燥的）。

当谈到成为一个 "认证的 "符合PCI-DSS的开发人员时，并没有太多的明显选择。为什么呢？可能是因为它不可能是一个 "一蹴而就 "的工作。

在学习如何挫败常见漏洞方面，OWASP组织是地球上最好的组织之一，他们的前十名被正式列入PCI-DSS的开发者指南中。然而，保持安全意识和磨练技能需要时间和持续努力。而没有人希望这是不鼓舞人心和浪费精力的。

积极的安全文化在一个组织中不是一个 "不错的选择"；如果他们认真对待安全问题，那么它就需要成为公司日常运作的一部分。

当涉及到阻止漏洞时，开发人员处于战斗的最前线。他们是否得到了支持、工具和培训，以维持他们在PCI-DSS合规性中的安全交易部分？

事实上，正确的培训是更加无缝的；它不应该让人感觉是在讲课，而且应该与每天的工作高度相关。这种实践培训是一个提高技能的机会--对于那些认真阻止漏洞并与团队其他成员合作以产生更高标准的代码的开发人员来说，这种职业发展只有积极意义。

想现在就测试一下你的安全编码技能吗？ 选择你的任务.

这是关于组织内成功遵守PCI-DSS的两部分系列中的第一部分。在本章中，我们将详细介绍AppSec专家如何与开发经理密切合作，以增强开发人员的能力，加强SSDLC，并从一般立法中获得具体成果。

合规 "这个词并不令人兴奋。它是正式的、干巴巴的、指令性的......甚至在语气上有点限制性。如果它有颜色，那就是米色。而且，它似乎与任何形式的创造性环境或创新不一致。

作为一个开发人员，我的 "合规 "经验通常意味着（纵向）阅读一些指南或观看演示，然后再回到编码功能，并专注于创建客户会使用和喜爱的软件。每个人都保留了他们当下能做的事情（并试图在任何时候都做正确的事情），但合规指南--尤其是那些围绕安全最佳实践的指南--通常不是以开发人员为目标受众而编写的，任何所需的行动都可能是不明确的。在这种情况下，仅仅停留在当前的目标上就太容易了。

问题是，安全的软件开发在任何公司都不再是一个 "不错的选择"；它是（或应该是）每个组织的头等大事......如果它持有大量敏感的客户信息，那么当涉及到网络攻击时，该公司已经成熟了。开发人员是第一个接触代码的人，因此，他们应该和团队的其他成员一样参与到任何安全合规措施中。

但是，等等...听我说完。这并不意味着每个人都必须成为僵化的、没有创造力的开发和软件成果的奴隶。这意味着企业有机会和权力共同创造更高标准的代码。迄今为止，世界正在慢慢赶上这个事实，即开发人员还没有完全掌握正确的工具来使安全成为优先事项（孤立的安全专家不能单独承担这个责任）。然而，随着行业走向以安全为共同责任的DevSecOps的未来，当设置成功时，他们可以帮助阻止反复出现的漏洞的流动。

PCI-DSS指南涵盖了银行卡支付网关的在线安全合规性--这是我们大多数人经常使用的服务。这些准则是全球适用的，他们实际上已经详细列出了开发人员必须做的事情，以保持与他们的任务一致的标准，同时还有一些跨越电子商务业务方面的合规文件。

数据泄露是可怕的、破坏声誉的风险，是企业无法承受的，而网络安全风险投资公司预测，2021年每天的零日泄露将达到一个，这是软件交付过程中的每个人都可以帮助打击的事情。

让我们来分析一下PCI-DSS的建议，以及它们如何在整个团队中发挥作用。

嘿，应用安全和合规团队。所有的开发者培训都是不一样的

大型（甚至小型）组织中的开发人员很少对他们在工作中接受的培训有大量的投入。为了留住明星员工，一些公司确实提供了全面的计划，但这些计划仍然比它们应该的要少。对安全培训的需求提供了一个很好的机会，不仅可以启动组织的合规性，而不至于让每个人都感到厌烦，还可以开始暖和与开发团队的冰冷关系。

在PCI合规性方面，你可以看到他们的指导方针对运行支付网关的任何软件所期望的结果是具体的；在其他目标中，他们希望应用程序得到加固（对阻止恶意代码注入或篡改至关重要），最小特权控制和对常见漏洞的全面认识...至少。所有与持卡人数据打交道的人员都必须接受充分的培训，对于开发人员来说，这种培训可以使他们从一开始就成功地编写安全代码。

官方的维护PCI-DSS合规性的最佳实践文件详细介绍了围绕安全意识、开发人员需求和适当培训的一些直接概念，比如。

Copyright © 2006 - 2020 PCI安全标准委员会, LLC.保留所有权利。

这让我们了解到了用必要的技能来武装开发人员所需的具体、深入的培训，但仍然没有指出任何特定类型的教育解决方案比另一个更有效。PCI-DSS开发者指南》更直接一些，将OWASP的前10名作为学习查找和修复最常见漏洞的基准，以及一些认证项目。

但是......问题来了。毫无疑问，你会从各种工作场所的培训和合规性举措中了解到，它们在质量和未来的成功方面会有很大的不同。而当涉及到开发人员时，许多安全编码培训项目似乎并没有迎合我们的需求、工作方式，甚至我们的日常工作也没有任何意义。在这种情况下，不是所有的培训都是平等的，也不是所有的培训都能使软件更安全。当然，这与你期望的结果完全相反，也不会使你自己的工作压力有任何明显的减少。如果你想减轻负担，阻止常见的漏洞造成潜在的灾难，你就需要搭建一座桥梁。

与工程经理一起弥合安全技能差距

直接与工程经理合作，找到一个适合的解决方案，同时还能被实际需要做的人所接受，是实现积极安全成果的快速通道。他们将对自己的团队有更直接的了解，并能说出以前使合规性培训变得困难的任何障碍（除了它不是一个好的经验，大多数时候）。

基于课堂的培训、视频点播和任何一次性的、打勾的练习都很难保持现状；这些都是静态的解决方案，无法跟上网络安全行业不断变化的形势。最终，工程经理希望看到时间承诺的价值，重要的是与他们合作，并提供可行的选择，以满足每个人的共同目标：更安全和合规的代码。

那么，好的培训是什么样子的？通过大量的、一次性的信息来学习如何安全地编码是没有什么意义的。一点一滴、循序渐进的学习过程更容易记忆和应用，而且绝对必须使用每天使用的语言和框架。就个人而言，我想接受挑战，我想看到我的努力有一个目的--我们都已经够忙了，对吗？

为了遵守上述PCI-DSS的最佳实践，根据所选择的解决方案，管理人员可能会发现自己不得不把不同的courses ，以涵盖整个企业使用的所有语言和框架，这时事情就会变得非常混乱，更不用说AppSec和合规性团队很难评估对软件的安全性和漏洞减少的影响。共同合作，找到合适的方案，而不是急于进入错误的选项，追逐快速的结果。否则，你可能最终会得到一个科学怪人的培训方案......而这看起来非常可怕。

感谢大家对这个PCI-DSS迷你系列的第一部分的关注。在最后一章中，我们将讨论CISO和CTO如何帮助这种文化转型，启用团队，以及安全前线 "你的开发者队伍 "如何利用PCI-DSS意识和合规性来发挥他们的优势。

与技术本身一样，开发代码的工具、技术和最佳流程也在快速发展。我们人类对更多的软件、更多的特性、更多的功能有着永不满足的需求......而且我们希望它比以前更快、更有质量，而且最重要的是：安全。就在几年前，敏捷开发是下一件大事，被用来把大块的工作分解成小块，并且能够快速适应来自客户的快速反馈周期。在这之前，瀑布法是山丘之王。

当许多人和组织正在从瀑布式转向敏捷式时--不是每个人都能做到的，让我们现实一点吧--他们已经遇到了一个新的问题：开发团队和他们的运营同行仍然在各自为政。在这种环境下，以敏捷方式工作的小团队如何才能实现快速部署、快速交付的承诺？

DevOps是一个结合了开发和运营的名称，是为了在创建新软件时合并开发人员和运营团队的职能。从本质上讲，这是为了帮助开发人员掌握把东西投入生产的所有权，而不是把它扔给运营团队，让他们负责。

他们当然可以更快地发货--甚至每天几次--这似乎是在敏捷的巷子里玩。然而，DevOps仍然创造了一个由工程师和运营人员组成的大型混合团队，这在现实中可能并不符合敏捷的要求。最终，最好把DevOps看作是敏捷的进化，因为这两种方法在很多方面是相似的，而在不同方面是互补的。DevOps提倡自动化、持续的集成和部署管道，这对于实现频繁的发布是必不可少的，但在团队层面却不够充分--而这正是敏捷的作用。敏捷使团队，特别是小团队，能够跟上这些快速发布和不断变化的需求，同时保持任务和协作。这当然看起来很理想--而且这个过程可以使团队保持在最终目标的轨道上--但它并非没有自己的问题。

使用DevOps最佳实践创建的软件仍然有可能在第一个老板的战斗中跌倒：安全团队。当传统的/瀑布式的AppSec专家检查代码时，无论是使用工具还是复杂的人工审查，他们经常发现不可接受的风险和漏洞，然后必须在事后修复。在已完成的应用程序中进行安全修复的过程既不迅速也不容易......而且对组织来说，成本也高得多。

那么，如果世界正在向瀑布、敏捷和现在的DevOps发展，解决方案是什么？而作为一个开发者，你在跟上这些方法的变化中扮演什么角色？

开发技术处于不断的演变之中，但值得庆幸的是，这一次的变化并不是很大。企业只需要在 "DevOps "中加入 "Sec"......于是，DevSecOps诞生了。DevSecOps的一个主要目标是打破障碍，在开发、运营以及最后但并非最不重要的安全团队之间展开合作。DevSecOps既是一种软件工程战术，也是一种文化，主张在整个软件开发生命周期中实现安全自动化和监控。

这似乎又是一个组织层面的过程，当涉及到一个有一长串功能需要建立的开发人员时，可能会有 "太多的厨师"。然而，DevSecOps方法论为有安全意识的开发者提供了一个真正的机会。

开发安全运营的光明前景

那么，为什么一个程序员会想成为DevSecOps工程师呢？也许你在DevOps（甚至是敏捷）方面有一些经验，但想迈出下一步，成为DevSecOps的精通者。首先，我们应该知道这是一个非常明智的举动，而不仅仅是为了让世界免受昂贵的网络攻击。专家说，对优秀网络安全人员的需求正在急剧上升，而且没有尽头。那些掌握DevSecOps的人可以期待一个长期和有利可图的职业生涯。

DevSecOps工程师的工作安全更有保障，因为与传统的网络安全策略（如用一系列基于软件的工具进行漏洞扫描）不同，DevSecOps要求人们知道如何在编码时实施安全。正如博思艾伦咨询公司的分析师在其题为《采用DevSecOps的5个误区》的博客中指出，企业希望甚至需要DevSecOps，但根本买不到。DevSecOps是一种让跨职能团队在整个软件开发生命周期中整合技术和协作的方法，这需要熟练的人员、变革管理和多个利益相关者的持续承诺。

根据Booz, Allen and Hamilton公司的说法，公司可以购买应用程序和工具来帮助DevSecOps的某些方面，如发布管理软件，"但真正实现它的是你的交付团队。"他们是推动DevSecOps及其文化和范式转变所提供的持续改进的人。

企业不能 "购买 "一个可行的DevSecOps项目；它必须被建立和维护，使用一系列的工具、内部知识和指导来提升安全文化，同时也要有商业意义。这并不容易，但也远非不可能。

你如何能在DevSecOps运动中踢到屁股？

在成为一名DevSecOps工程师的道路上，首先要认识到这是一种文化，也是一套技术。它要求你有意愿将安全作为你创建的每一段代码的一部分来实施，并希望通过在编码时积极寻找安全缺陷和漏洞来主动保护你的组织，在它们进入生产之前就将其修复。大多数DevSecOps工程师对他们的职业和技能组合非常重视。DevSecOps专业组织甚至有一个宣言来说明他们的信念。

宣言有点沉重，因为宣言很少是轻松的阅读。但其核心是一些所有伟大的DevSecOps工程师都应该学会接受的真理，比如。

• 认识到应用安全团队是你的盟友。在大多数组织中，应用安全专家与开发人员不和，因为他们总是把已完成的代码送回去做更多工作。应用安全团队往往也不太喜欢开发人员，因为他们会通过引入常见的安全漏洞来延迟已完成的代码进入生产。然而，聪明的DevSecOps工程师会意识到，安全团队的目标最终与开发人员和编码人员是一样的。你们不一定要成为最好的朋友，但形成一种平静和协作的工作关系对成功至关重要。
• 练习和完善你的安全编码技术。如果你能在应用程序还在建设中的时候就发现它们的漏洞，那么关闭这些漏洞就能阻止未来的黑客入侵。当然，这既需要对漏洞的理解，也需要有帮助修复漏洞的工具。Secure Code Warrior 博客页面可以让你深入了解你会遇到的最常见和最危险的漏洞，以及实用的建议和挑战来测试你的知识。最重要的方面是把安全问题放在心上，并抽出时间进行一点一滴的培训，以帮助你在现有的知识基础上发展。开发人员与安全的互动通常是相当不起眼的--甚至是负面的--但提高安全技能是一个伟大的职业发展，而且它不一定是一件苦差事。
• 请记住。DevSecOps的超级明星们为其组织的积极安全文化做出了贡献。与其专注于过去的目标，如快速交付应用程序而不考虑其固有的问题，不如将发现和修复开发代码中的漏洞作为首要任务。安全必须被视为每个人的工作，每个人都应该分享每次部署有效和高度安全的应用程序所带来的赞誉和奖励。

你可以通过从头开始倡导安全编码和安全最佳实践，推荐培训方案，并确保在全员参与、快节奏的DevSecOps世界中，没有一个编码员被落下，从而协助在你的组织中培养一种令人难以置信的安全文化。唯一好的代码是安全的代码，而熟练的、有安全意识的开发人员是拼图的重要组成部分。个人和职业的回报肯定是值得努力的，随着每年数以亿计的个人数据记录被泄露（而且还在增加），我们需要你。在前线站稳脚跟，帮助抵御我们数字世界中的坏人。

马蒂亚斯-马杜(Matias Madou)，博士，是美国国际开发署的首席技术官和共同创始人。 Secure Code Warrior.他是一名安全专家，长期从事开发工作，也是《堡垒之夜》的爱好者。

有一个众所周知的理论，即蟑螂基本上可以在任何情况下生存--甚至是核爆炸。虽然这个理论只在一定程度上是正确的，但它们简单的身体组成使它们的体型非常坚韧，在大多数情况下很难被消灭。

我一直在想......如果蟑螂在数字世界里有一个对应的东西，那一定是代码中的SQL注入（SQLi）漏洞。这已经是一个已知的漏洞，超过20年了，但组织却一次又一次地成为它们的受害者。塔吉特公司受到的广泛而昂贵的攻击就是SQL注入的结果，伊利诺伊州的选举黑客事件也是如此，其中20万选民的记录被暴露，这促使联邦调查局建议所有IT管理员迅速加强他们的安全实践。

Imperva的黑客情报计划报告显示，在2005年至2011年期间，在所有报告的数据泄露中，有83%使用了SQLi攻击。今天，注入漏洞仍然是OWASP前10名中的头号威胁。它们相对简单，但它们就是不死。

这个同样的漏洞仍然出现在大量的应用程序安全扫描中，这似乎很荒谬。我们知道它是如何运作的，我们也知道如何阻止它。这怎么可能呢？事实是，我们的软件安全有很大的改进空间。

Veracode的《软件安全状况报告》--基于2017年的40万个应用程序扫描--揭示了一个令人震惊的统计数字：只有30%的应用程序通过了OWASP的十大政策。这在过去五年中是一个一致的主题，几乎每三个新扫描的应用程序中就有一个出现了SQL注入。这证明了一个普遍存在的问题；我们没有从错误中学习，CISO似乎在能够采购到足够的安全人才方面面临着一场艰苦的战斗。通常情况下，应用安全专家与开发人员的比例为1:100，这是不充分的。

为什么软件安全要靠生命支持？

专业安全人才稀缺已经不是什么秘密了，但我们也必须注意一个事实，那就是开发人员没有在问题出现时进行修复，而且显然没有能力在一开始就不引入漏洞。在同一份Veracode报告中，它透露了所有开发漏洞中仅有14.4%有记录的缓解措施。换句话说，大多数漏洞是在没有开发缓解措施的情况下提交的。不到三分之一的漏洞在前90天内被关闭，42%的漏洞在开发期间从未被关闭。

我经常与安全专家、首席信息官和首席执行官交谈，从轶事来看，我意识到许多公司对发现的无法缓解的漏洞数量感到非常沮丧（除了被称为假阳性的祸害），以至于他们完全停止了对这些漏洞的扫描，掰着手指希望得到最好的结果。

为什么AppSec专业人员会让这种情况发生？

不要搞错了。应用安全人员对代码中的问题有着深刻的认识。毕竟，这是他们的核心技能之一，使他们成为如此宝贵的团队资源。然而，他们往往被几个因素所束缚。

例如，一个应用安全经理会发现一个问题，然后问开发人员，"你能修复代码吗？"。这个重要问题的答案因组织而异，但一般来说，开发人员在满足严格的功能交付冲刺方面的工作非常紧张，他们根本没有时间来修复这些问题，也没有像样的工具来帮助他们。AppSec专业人员本身可能能够识别漏洞，但他们往往没有技能和/或权限来当场修复这些漏洞。

我们还必须认识到，对于每一个问题，都有一个需要找到解决方案，实施它，然后测试它的过程。对于在代码中发现的哪怕是最轻微的问题，修复它可能需要的时间，更不用说所需的资源，都是巨大的。有超过700个漏洞可以被引入到软件中，任何一个人根本不可能对它们全部进行防御。正是由于这个原因，大多数公司都坚持只遵循OWASP的前10名。与此同时，开发人员不断地构建功能，反过来，他们也不断地将漏洞引入他们编写的代码中。

解决办法是什么？

一个简单的事实是，我们没有给我们的开发人员提供工具和培训来促进安全编码的成功。没有任何法规迫使组织确保开发人员拥有足够的安全技能，而且一个可悲的现实是，大多数大学和实习生也没有准备好初级开发人员的安全编码。

当有人想开飞机时，有一个非常严格的过程，确保在他们能够飞行之前有培训、实践经验、体检、安全知识和考试。没有人敢想象，在没有这种广泛的准备和技能验证的情况下，他们会被放上天空，然而这就是每天发生在代码编写上的事情。  

我们需要花时间来教育开发人员如何编写安全代码。然而，在当今世界，软件开发是快节奏的，优秀的开发人员和安全专家供不应求，这似乎从来没有成为一个优先事项。现在是我们改变对话的时候了。

世界经济论坛最近的一个头条新闻叫嚣着。"没有安全就没有数字经济"，附带的内容认为，安全需要成为任何数字转型战略的核心部分。"安全是保护企业的东西，使他们能够创新，建立新的产品和服务。除了防御作用，安全还为企业提供了战略增长优势"。

提高安全编码技能和成果将为组织增加一个强大的网络保护层，协助他们创造更好、更快的代码。开发人员不需要成为安全专家，但他们必须得到积极和实际的授权，以成为防范网络攻击的第一道防线。开发人员可以成为下一个安全和创新英雄。他们是非常聪明的人，他们是创造性的问题解决者，而且普遍热衷于培养自己的技能。发挥他们的优势，提供他们应得的专门培训，并致力于提高软件安全标准。阅读我们的白皮书以了解更多信息。

当有人想开飞机时，有一个非常严格的过程，确保在他们能够飞行之前有培训、实践经验、体检、安全知识和考试。没有人敢想象，在没有这种广泛的准备和技能验证的情况下，他们会被放上天空，然而这就是每天发生在代码编写上的事情。