6.2 软件开发人员和可用的安全性
Zurko & Simon 指出，不可用的安全性不仅会影响可能没有接受过特定计算或安全教育的普通员工，还会影响那些具有重要技术技能的人，例如开发人员和系统管理员。他们还面临着不断增加的工作量和复杂性，并且会犯错误，因为他们使用的库和应用程序编程接口 (API) 不可用。可以说，这些技术用户犯的错误通常比普通员工犯的错误（例如Heartbleed 漏洞）具有更大的影响。
|
开发人员和密码安全我们在上面提到了密码和其他身份验证系统的可用性问题，这些问题已经为最终用户进行了广泛的研究，突出了问题并为设计决策提供了更好的策略并激发了对替代方案的研究。但是，最终用户并不是唯一遇到密码可用性问题的人。负责编写用于存储密码的代码的开发人员必须安全地执行此操作。然而，历史表明，这项复杂的任务通常会因人为错误而失败，并带来灾难性的后果。如果开发人员忘记对密码数据库进行“散列和加盐”，这可能会导致数百万最终用户密码被泄露。Naiakshina 等人。对计算机科学专业的学生以及自由开发人员进行了一项随机对照试验，发现与最终用户类似，开发人员也受到任务关注的困扰，他们将安全视为次要任务。除非明确提示，否则没有一个学生参与者，只有少数自由开发者实施了任何类型的安全措施。有趣的是，在那些确实实施了一些安全措施的参与者中，学生比自由开发者做得更好，后者总体上使用了更多过时和不正确的密码机制来存储他们的密码。
|
许多研究，例如Enck等人和Fahl等人，都强调了以应用程序开发为中心的现代生态系统中脆弱性的程度。值得注意的是，在Fahl等人联系的96名开发商中，很多人愿意提供信息，但只有13人接受了采访，因为他们的公司拒绝允许他们这样做。从采访中，Fahl等人发现开发人员几乎没有接受过安全培训，并且在快速完成应用程序方面承受着极大的压力，这就是导致漏洞的错误的原因。
Acar等人研究了在线社交网络（如StackOverflow）对开发人员生成的代码安全性的影响。使用StackOverflow或教科书的开发人员中有三分之二能够在分配的时间内生成功能正确的解决方案，而使用官方文档的开发人员中只有40%能够做到。在安全任务方面，结果是相反的。使用官方文档的人生成的代码最安全，使用StackOverflow的人生成的代码最少。对这一结果的传统安全反应是“应禁止使用StackOverflow”但很明显，开发商及其组织将为生产率付出高昂的代价。
例如，最近的工作表明，开发人员利用此类论坛交换信息，并为解决安全问题提供相互支持。这并不是说这些建议总是有效的（如上所述），但论坛确实提供了一个实践社区，开发者可以在其中分享他们的问题并寻求帮助。因此，直接禁止此类论坛而不以相关支持取代它们，并不能解决开发者寻求此类支持的关键问题。Arzt等人强调了加密 API 及其文档的可用性挑战。和纳迪等人以及建议用于支持开发人员使用的工具。最近，还提出了一些工具来提高静态分析的可用性，
例如Green 和 Smith 将现有研究机构的见解综合为一组十项原则，以使安全和密码库的应用程序编程接口对开发人员更有用。帕特奈克等人。确定了四种可用性气味，表明加密 API 可能没有完全解决这些原则，为图书馆开发人员提供了关于重点关注的关键领域的见解，以提高图书馆的可用性。
还需要考虑开发人员和用户之间的脱节。卡普托等人。强调开发人员不了解缺乏可用性对个人绩效和幸福感、组织生产力或安全有效性的影响。他们建议管理层必须确保开发人员直接体验缺乏安全性和可用性的结果——通过处理服务台呼叫、损失的影响——并更多地参与。最近的工作提供了深入了解强大的组织安全文化对开发人员在安全方面的心态的作用以及专家如何改进他们的安全实践。
网络安全知识体系1.1人为因素（一）：了解安全中的人类行为
网络安全知识体系1.1人为因素（二）：可用的安全性——基础
网络安全知识体系1.1人为因素（三）：可用的安全性——目标和任务
网络安全知识体系1.1人为因素（四）：可用的安全性——交互上下文
网络安全知识体系1.1人为因素（八）：网络安全意识和教育——支持安全意识和行为改变的新方法
网络安全知识体系1.1人为因素（十一）：利益相关者参与之雇员
原文始发于微信公众号（河南等级保护测评）：网络安全知识体系1.1人为因素（十二）：利益相关者参与之软件开发人员和可用的安全性
评论