devops
今年早些时候，我们与Manicode安全部门的Jim Manco进行了交谈。 紧接在Oracle OpenWorld 2017之前，Manico在该会议上发布了有关Java SE 9安全性的JavaOne会话。
最新版本的JDK中有许多新工具和技术，可帮助最大程度地减少开发人员可能遇到的Java安全错误。 当然，仅具有JEP-273（基于DRBG的SecureRandom实现），JEP-290（传入的序列化数据过滤）和Java 9规范中新的无限制JCE（Java密码学扩展）之类的技术还不够。 要最大程度地减少投入生产的Java安全错误的数量，重要的是让开发人员知道这些各种安全控件的功能以及如何使用它们。
与Jim Manico谈论安全性
以下是TheServerSide的Cameron McKenzie和Manico先生之间的访谈记录，其中涉及各种Java安全性主题，包括Java模块化将如何影响安全性bug的解决方式，出现Java安全性bug时DevOps自动化工具的缺点。 ，当然，还有对Java SE 9中新增的各种Java安全控件的见解。
卡梅隆·麦肯齐（Cameron McKenzie）：关于企业Java安全性 ，与您有关的事情是什么，与Java进行企业软件开发的人员应该关注的事情是什么？
吉姆·马尼科（Jim Manico）：我真正关心的是抵御Java和Java受到攻击的风险。 对许多开发人员来说，老实说，这是深奥的东西。 因此，它不一定是Java最令人兴奋或最性感的功能，但我敢说这是必需的东西。 例如，有一个新的JSR解决序列化问题，并尝试允许对Java应用程序中多个层上的确切类进行直接白名单过滤。 这不是令人兴奋的东西，对不对？ 但是必须有一个安全的Java应用程序，或者至少它为您提供了一种解决已知Java风险的方法。 但是，你知道，这并不性感。 但这很重要。
避免Java安全性错误
Cameron McKenzie：通常，企业Java开发人员只是专注于满足业务需求，并不真正关心自己正在编写的代码对安全性的影响 。 对于开发人员每天都会编写的某些代码，为了避免Java安全错误发现它们进入代码的方式，他们应该考虑哪些安全方面的考虑？
吉姆·曼尼科（Jim Manico）：有时，将数字用于财务处理比人们期望的要复杂得多。 现在还有其他问题，例如，当您使用较旧的Java技术时，您想提供某些控件（例如escaping ）来停止跨站点脚本编写，而这不是核心语言的一部分。 J2EE中有它的某些部分，有一些框架提供了它，但它不在语言的核心中。 我认为应该让开发人员更容易使用该控件。
还有所有加密API的问题。 我认为一些最好的加密API不在Java的核心中。 他们在不同的地方，例如Google项目。 Google Tink是一个新项目。 它是一种加密API，使Java的世界变得更加轻松，这使得Java开发人员与低级加密API进行交互的世界变得更加容易。 我很乐意看到更多此类API靠近核心。 我再改一下。 这些API与核心语言越接近，我们越有可能被开发人员使用，对吗？
我们都是Java安全工程师
卡梅隆·麦肯齐（Cameron McKenzie）：现在我在这里向您解释一下，如果我错了，请纠正我。 但是，在我参加过的上一届会议中，我记得您谈论过您对软件开发人员和DevOps员工如今应该真正考虑自己是安全工程师的看法。 那是什么意思？
Jim Manico：你知道，世界在变化。 因此，我向大多数开发人员提出挑战，无论他们是否相信，是否认为，甚至不愿意，他们都是安全工程师。 因为他们正在编写的代码位于保护组织免受数据丢失，财务损失，声誉损失，侵犯隐私，合规性规定和罚款的前线。 因此，这些开发人员及其编写的代码位于所有这些问题以及更多问题的最前沿。 因此，他们是安全工程师。 因此，这取决于他们是否愿意这样做 。 而且，如果您像笔测试一样击败开发人员，并让一些安全团队运行工具，并且，尤其是在成熟的早期，您知道培训开发人员攻击他们的代码确实会有所帮助。
在成熟阶段的后期，开发人员将参与设计初期的对话，并使用现有的安全性库以及知识和控件，例如可供开发人员使用的严格的身份验证和访问控制服务以及高级密码服务。 这些是设计软件初期的控件。 那是理想的，对不对？ 但是首先，如果您还处于成熟的初期阶段，也许您以前从未在组织中完成过应用程序安全性，那么我认为需要进行大量评估，只是为了初步了解开发人员的位置，向他们展示针对其软件的攻击，这通常是早期有助于改变文化的好方法。 但是，您知道，我们想更主动地这样做，因为我们在编写安全软件方面变得更好。
基于DevOps的安全性的限制
Cameron McKenzie： DevOps是否会改变软件安全性游戏？ 您对DevSecOps的感觉如何？
吉姆·马尼科（Jim Manico）：这是一个难题。
我认为这是一个很好的词，但概念是我们正在使软件开发生命周期的各个方面自动化。 就像我们使构建过程自动化一样，我们已经做了很多次。 我们将在构建和部署软件的不同阶段将安全性测试集成到构建生命周期中。 我们正在自动化。 我们还在做什么？ 我们正在自动化动态测试，我们正在自动化代码外观测试，我们正在自动化软件部署。 在部署软件时，我们针对我们的代码运行大量测试，自动化单元测试，动态测试和静态测试，以寻找安全漏洞。 也许我们发现了安全漏洞，我们将停止构建并不允许部署该代码。 也许这只是一个警告，无论如何我们都会发货。 我们如何实现自动化有很多梯度。
DevOps还讨论了有关自动化不同的仪表板和警报的问题，因此，实时监控应用程序的人员可以在发生安全性时获得更好的情报。 这些都是我们在软件领域已经做的很长时间了。 我认为DevOps对其提出了更高的要求，并在其前面加上了一个不错的名字，并且至少在我的世界中，试图为它增加更多的安全性，并使其尽可能自动化。
现在，另一方面是应用程序安全中的某些元素不能很好地转化为自动化。 就像，尤其是如果想，如果您想使用交钥匙工具，那么总会发现工具，尤其是那些可能会导致访问控制问题，业务逻辑问题或笔测试可能发现的更深层问题的工具，并不总是那么好。您可以将其调整为在DevOps环境中快速工作，也许只有五分之一的人会发现手动操作可能会遗漏问题。 DevOps的阴暗面是我们仍然需要人员。 我们不能只是自动化一切。 我认为，如果您需要的话，我们仍然需要参与深度审查的人员才能真正提供更深层次的安全保证。
卡梅隆·麦肯齐（Cameron McKenzie）：坦白地说，对Java Web浏览器插件的弃用对安全分析师来说是最大的事情吗？
吉姆·曼尼科（Jim Manico）：作为一名程序员，我很喜欢“ 随便什么 ”，但是作为基础架构人员，他试图管理大量的PC或Mac，或者不维护组织的安全，不支持通常是一件好事，对吧？ 我不想浪费Java，但传统上客户端中的Java并不是一件好事。 许多策略都在严格限制Java在客户端上的运行方式。 所以这是朝那个方向的一脚踢，这很好。 我并不是说Java客户端很糟糕，这只是……对管理员来说是一件好事，因为管理员可以尽可能多地控制客户端的JVM。 而且，从任何仅运行浏览器和类似技术的网站获取恶意小程序都不是理想的情况，对吗？ 因此，我们想限制它并尽可能地对其进行管理。
软件安全工具
卡梅隆·麦肯齐（Cameron McKenzie）：现在，当您担任安全顾问并进入一个组织时，一旦到达那里，您希望看到哪些工具，治理模型和策略？
吉姆·曼尼科（Jim Manico）：好的认证服务通常是个好主意，对吗？ 因此，对于开发人员而言，尤其是随着组织的成熟，实际上是……而不是让每个开发人员都以某种方式对身份验证服务的某些部分进行重新编码，拥有或使用所有开发人员都可以以标准方式使用的严格的编码，这将使您的前门应用程序更容易锁定。 我要看的第二层当然是访问控制。 拥有良好的访问控制服务以及一系列方法，数据库驱动的规则和配置功能，所有这些好东西都可以以您团队中所有开发人员都可以利用的方式实现真正的水平，详细，权限级别的访问控制。 。
您知道，我们也希望能够以安全的方式构建用户界面。 无论我们使用什么框架，我们都想了解如何通过脚本来保持锁定状态。 我们还希望确保开发人员了解，通过客户端的正确数据流是什么，长期和不应该存储在客户端上的数据。 什么样的逻辑应该和不应该在客户端上运行？ 什么东西我们应该推动更多的服务器端？ 我们甚至不应该对客户做什么？ 您知道吗，我们如何将数据访问和用户界面功能访问与客户端和服务器上相同的一致访问控制规则集联系起来？
您知道，所有这些都是开发人员每天要做的事情，他们确实需要了解如何使用和正确使用。 而且，如果我们没有这些工具，例如，“您好，开发人员，欢迎您，欢迎加入团队，现在就去研究访问控制，”，祝您好运。 您知道，这对您的软件领域非常重要，这不是您可以...而是您不能...它是您可以做到的，但我敢说这是您不应随便放入应用程序中的。 这应该是非常故意的。
Cameron McKenzie：而且，您知道，Java生态系统中出现了很多热门话题。 关于容器，微服务和编码的讨论很多。 但是安全性很重要。 而且，如果您想了解安全性，那么最好的演讲者是Jim Mancio。
您可以在Twitter上关注Jim Manico： @manicode 您可以在Twitter上关注Cameron McKenzie： @cameronmcnz
devops
922
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
