Difference between revisions of "OWASP Secure Software Development Lifecycle Project"

How can I participate in your project?

All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

If I am not a programmer can I participate in your project?

Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

Contributors

The OWASP Secure Software Development Lifecycle Project is developed by a worldwide team of volunteers. A live update of project contributors is found here.

The first contributors to the project were:

• RIP (Sub-project Owner)
• Silver Zhang(Sub-project Owner)
• Kevin (Sub-project Owner)
• Xia Tianze (Sub-project Owner)
• Yu Kan(Sub-project Owner)
• Lance Li (Sub-project Owner)
• Wang Jie (Sub-project Owner)
• Bao Yuezhong (Participant)
• Ricky Xu (Participant)

Base on the current estimation, the roadmap of the OWASP Secure Software Development Life Cycle Project is below:

Involvement in the development and promotion of the OWASP Secure Software Development Lifecycle Project is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:

• Helping find references to some of the principles.
• Project administration support.
• Wiki editing support.
• Writing support for the book.

This Page includes S-SDLC releated stuffs. Categorized as a.)Tools b.) Libraries c.)Technical Docs

Tools

• OpenRASP

OpenRASP is an open-source, free and self-adapting security tool made for OWASP S-SDLC Security Deployment & SecDevOps phase.

It can provide functions like threat detection, data stream monitor, quick-response to production by the deep integration of its protection engine.

Unlike other perimeter control solutions like WAF, OpenRASP directly integrates its protection engine into the application server by instrumentation. It can monitor various events including database queries, file operations and network requests etc.

When an attack happens, WAF matches the malicious request with its signatures and blocks it. OpenRASP takes a different approach by hooking sensitive functions and examines/blocks the inputs fed into them. As a result, this examination is context-aware and in-place. It brings in the following benefits:

1. Only successful attacks can trigger alarms, resulting in lower false positive and higher detection rate;

2. Detailed stack trace is logged, which makes the forensic analysis easier;

3. Insusceptible to malformed protocol.

OpenRASP FAQ

1. List of supported web applicationBelow table shows the recent updates of the project.Below tables shows recent updateBelow table shows recent updates.s. servers

Only Java based web application servers are supported for now. The support of other web application servers will also be soon included in the coming releases.

OpenRASP on the following application servers for both Linux and Windows platforms has been tested.

• Tomcat 6-8
• JBoss 4.X
• WebLogic 11/12

2. Performance impact on application servers

Multiple intense and long-lasting stress tests has been taken. Even in the worst-case scenario (where the hook point got continuously triggered) the server’s performance was only reduced by 10%

3. Integration with existing SIEM or SOC

OpenRASP logs alarms in JSON format, which can be easily picked up by LogStash, rsyslog or Flume.

4. How to develop a new plugin?

A plugin receives a callback when an event occurs. It then determines if the current behavior is malicious or not and blocks the associated request if necessary.

Detailed documents available on github.

• "INSIGHT" Platform

"INSIGHT" is a management platform developed by the Security Department of CreditEase which integrates Application system asset, Vulnerability lifecycle, and Security knowledge base.

1. Application System Asset Management: managing assets of application system in the company, including system name, domain, senior level, department, and owner.
2. Vulnerability Lifecycle Management: proceeding online submission, notification, verification, retesting, classification, risk calculation, repair deadline calculation, email reminder, and vulnerability data analysis for the security vulnerability found from application system in the company.
3. Security Knowledge Management: implementing centralized storage, online learning, security training, and knowledge inherited of security knowledge and standard specification.

"INSIGHT" was developed by Python language and form of Flask framework & MySQL & Docker container.

Detailed documents available on github.

The concept of design

Application security activities begin with the risk assessment of the application assets. When the company accumulates more assets, it shall encounter increasing problems, such as unclear assets resource, miss of asset owner, the high cost of continuous of vulnerability tracking and difficulty of security knowledge penetrating, no data support for high-frequency risks, and failure of solving core problems, In addition, risk quantification is also a problem.

In the design of application security management framework, the general process of risk governance is as follows:

Based on the demands of the above risk governance, “INSIGHT" came into being.

Highlights

After the implement of "INSIGHT" system, we achieved the following goals. Please see the following picture:

Vulnerability history at a glance

Vulnerability tracking is methodical

Learning Cases can be found easily

Safety requirements are precisely controlled

Threats and risks are well-founded

Quantitative figures are known in real time

Libraries

To be added.

Technical Docs

To be added.

InfoSec Awareness Top 10 2018 Released

The OWASP Top 10 - 2017 is now available.

Top 10 Awareness for Most Critical Public Information Security Threats

This project is one of sub-projects for OWASP S-SDLC Project, aimed at the hot spot of the social public information security problems. By analyzing and proving the collected problems, we are endeavoring to arouse the basic information security awareness for public, and encouraging the general people could learn, understand and apply the foundamental information security controls by learning this Top 10 document. Ultimately, everyone is responsible for the infosec risk-free guarantee in the online society .

本项目为OWASP S-SDLC子项目， 旨在针对社会公众关注的热点安全问题，通过对安全问题的分析、案例演示，唤起公众对安全的关注，提升人民群众网络安全意识，了解和掌握网络安全防范方法，营造网络安全人人有责、人人参与的良好氛围。

Final Release

The results of Top 10 cyber security incidents shows as below (detail information and English version will be updated)

Project Team

• Project Leader: Jack Ding (190907765@qq.com)

• Team Members:

1. SecZone: Chuanyong Cao, Xiangxi Chen, Fei Xu, Jie Wang, Tianzhe Xia, Qingmign Zou
2. Qingyuan Polytechnic College, Mentors: Hua Huang, Xiquan Guo, Bin Wang, Xianghui Chen, Zhicheng Liu
3. Qingyuan Polytechnic College, Students: Kaitao Zhen, Junpeng Zou, Ronghua Chen, Haoliang Chen, Zijian Liu, Qiping Huang, Yuanhong Yu, Guanxiong Liang, Shaomo Huang, Junming Ma, Junjie Zou, Huixin Kong, Yaoguang He

• 项目牵头人：丁子桓(190907765@qq.com)

• 项目参与者：

1. SecZone互联网安全研究中心：曹传勇、陈香锡、许飞、王颉、夏天泽、邹庆明
2. 清远职业技术学院—指导教师： 黄华、郭锡泉、王斌、陈湘辉、刘志成
3. 清远职业技术学院—学生团队：郑楷涛、邹俊鹏、陈榕华、陈浩亮、刘梓健、黄绮萍、余远宏、王春前、梁冠雄、黄邵模、马俊明、邹俊杰、孔慧欣、何尧光

Project Roadmap

Licensing

InfoSec Awareness Top 10 2018 is free to use. It is licensed under the Creative Commons Attribution-ShareAlike 4.0 license.

Attachment: Data Classification Standard

(Will provide English Version Later)

Please note that the following contents are currently in Chinese only.

1．企业必须自上而下推行S-SDLC实施，且有相应的组织结构支撑

企业要实施S-SDLC，单靠传统的信息安全部门或几个网络安全人员是不行的，必须由公司领导层至上而下去推行。之所以必须是至上而下推行，一个重要的原因就是S-SDLC的实施并不是只有信息安全部门投入就可以了。S-SDLC会与研发部门的各个环境深度结合，需要研发部门的积极支持和全体参与。另外，安全对于大部分企业而言，能直接看到的是成本投入增加，而产出收益却是隐性的，并不会因为做了S-SDLC就能看到产品的直接销售收益。

因此，不管是对于研发部门还是其他部门，都很难有主动实施S-SDLC的动力。微软在推行时，是由比尔.盖茨亲自发邮件要求员工停下手上所有的工作后才开始实施；而华为则是由CEO担任全球网络安全委员会主任来推行实施。也就是说，如果没有高层领导至上而下的要求，安全部门推行S-SDLC只会是一厢情愿。相信很多安全部门在推行S-SDLC时，都会遇到研发团队不配合而导致无法推行或推行效果不理想的情况。

有了至上而下的要求，企业还要有相应的组织结构支撑，而合理的组织结构是保障S-SDLC实施效果的基础。因为S-SDLC在实施过程中会产生大量新的工作内容和新的工作流程，而这部分工作内容和工作职责混乱不清，将直接影响S-SDLC的执行效率和实施效果。

2．S-SDLC要与企业的质量管理体系相结合

不少企业实施S-SDLC时，将S-SDLC作为一个独立的流程来操作。这使得企业需要投入大量额外资源来支撑S-SDLC整个流程的运转，且实施的质量得不到保障。因此，S-SDLC的实施效果往往达不到预期。 安全本质上是产品的一种质量属性。在质量管理领域，业界已有成熟的方法和流程，比如：ISO9001、CMM等级，这些都用来保障产品的质量。大部分企业都设置有质量部门，并设置有质量管理人员角色。但安全往往因为专业性强，缺乏成熟的管理方法和流程，再加上安全部门的存在，因此产品质量部门通常不关心产品的安全问题。

在S-SDLC落地的过程中，将安全工程活动标准化，并纳入产品的质量体系，是保障S-SDLC实施效果的基础。举个例子来说，当产品的某项安全指标没有达到要求时，质量部门有权否决产品的上市发布或上线运营。

3．建立合适的人员培训体系

在S-SDLC实施的过程中，安全不仅仅是软件安全专家的事，而是实施企业所有人的事。仅靠几个安全专家很难保证企业所有产品的安全质量，而信息安全部门或网络安全部门面对软件开发往往也力不从心。 S-SDLC虽然整体涉及软件产品的安全开发生命周期，偏重于方法和流程，但人的因素同样至关重要。对于同样的方法、同样的流程和同样的工具，如果实施人员的安全开发思想意识和技术能力不同，其产生的实施效果差异也会非常大。比如：某公司的安全部门要求所有口令都在hash后再存储，而开发人员就将口令设计成hash之后的结果，让人看了哭笑不得。

如何让所有研发人员都了解并关注软件安全开发？建立一套合适的培训体系是较好的业界实践。这里的培训强调的是体系化的软件安全开发培训，而不是安全部门内部组织的信息安全知识培训或攻防渗透技术培训，因为对于不同的部门、不同的岗位、不同的人员，其安全的认知意识和技术能力也是不一样的。 简单来说，建议将安全培训分成不同的等级，且不同等级面向不同类型的人员群体。比如：软件安全开发意识培训可以面向所有人、软件安全编码培训可只面向开发和测试人员，而网络攻击技术培训可只面向安全专业人员。另外，需要让所有研发人员宏观的理解S-SDLC方法与流程，有助于让每个研发人员认知其与S-SDLC流程中上、下游角色的互动关系，也有助于让每个研发人员理解每一个S-SDLC的工作环节对整体产品安全的重要性。

4．用度量体系将S-SDLC实施效果可视化

对于企业的研发高层领导来说，最关注的还是S-SDLC实施效果。如何让S-SDLC实施效果可视化，是S-SDLC实施过程中需要注意的重要问题。如果研发高层领导看不到S-SDLC的实施效果，那就意味着可能失去研发高层领导对S-SDLC实施的持续支持和资源投入，从而导致S-SDLC实施失败。 S-SDLC实施的效果本身就是隐性的。微软在这个问题上也没法给出立竿见影的效果，但今天Windows操作系统的安全性要比在S-SDLC实施前的Windows XP好多了，尽管今天的Windows操作系统还是有很多安全漏洞，但安全性的增强并不是简单地从漏洞数量上进行对比，而是漏洞发现的难度、漏洞利用的难度和漏洞被利用的影响都比之前有了明显的改善。

因此，作为S-SDLC实施人员，需要在实施S-SDLC前给研发部门高层领导一个相对合理的预期：世界上没有100%的安全，不能保证S-SDLC实施后就不会再有漏洞了；也不是实施了S-SDLC后安全就可以高枕无忧了。但这也并不意味着就完全看不到效果。 如何让S-SDLC实施的效果可视化，比较好的做法是建立一套度量体系，通过度量的方法让S-SDLC实施的效果可视化出来。度量体系本身也是一套复杂的工程，比如说业界的OWASP SAMM和BSIMM就是复杂的评估度量体系。实施人员可以选取一些比较直观且容易实施的工程活动，体现工程能力的成熟度提升，这个和软件成熟度CMM类似。另外，也要有结果性的数据，比如：可以对测试发现的安全问题进行分级，建立一个S-SDLC实施前的基线，再看S-SDLC实施后每一年的问题发展趋势。

5．产品的安全目标决定S-SDLC的过程

完整的S-SDLC包含众多的活动，而同样的活动在不同企业的投入弹性空间也非常大，以威胁建模为例，有的产品可能只花半天时间，而有的产品可能需要花一个月甚至更长时间。 在S-SDLC实施的过程中遇到过很多类似问题：这个活动需不需要做？这个活动需要做到什么程度？这个活动需求投入多少人？对于这些问题，并没有统一的答案。因为不同的产品所处的环境不一样，面临的风险也不一样。但我们可以给出基本的判断原则。 这些原则的基本出发点就是产品的安全目标是什么？安全目标说起来容易，但要说清楚，就不是一件容易的事了。很多专业的安全人员往往更多的考虑安全技术，而忽略了安全目标。技术应该是用来支撑目标的达成，所以当目标不清楚的情况下，很难判断一项技术的使用是否合理？这些技术是否足够？这就导致了很多企业当前的一个现象：安全的投入好像是一个无底洞，不知道什么时候才能做完。这显然不是企业领导者所要的结果。

因此，在实施S-SDLC的过程中，定义一个清晰的安全目标，才能使S-SDLC的实施过程更加科学合理。

6．威胁模型可以使产品避免大的设计风险

如果问S-SDLC实施过程中有什么过程是特别难的，OWASP S-SDLC项目组相信很多真正实施过的企业或专家都会将这一票投给威胁建模。因为威胁建模做得太浅则感觉没什么效果；而做的太深则导致实施难度和投入成本的增加。如何取得深浅之度的平衡是威胁建模的难点所在。 要解决这个问题，还得从威胁建模的本质说起。威胁建模的本质是建立产品的威胁模型。而需要通过威胁建模达到什么样的目的，不少安全人员的理解也不太一样。

根据OWASP S-SDLC项目组的实践经验，一方面希望专业的安全人员通过威胁建模发现更多、更深入的产品设计漏洞，以呈现威胁建模的效果；另一方面又希望这一过程能工具化，使普通的研发人员也能发现同样的问题。但通常实际的效果是：经验丰富的安全人员不通过威胁建模的方法就能发现该问题；而普通的研发人员即使用了威胁建模的方法，也发现不了该问题。

对于这一现象，并不是威胁建模本身出了问题，而是企业对威胁建模的使用以及目标预期出了问题，威胁模型的核心作用是通过模型化的方式来管理威胁、风险和对应的缓解措施。威胁、风险、缓解措施这三者相辅相成，S-SDLC中STRIDE威胁建模方法可以将大颗粒度的威胁结构化，从而避免了产品威胁模型遗漏了大颗粒度的威胁，保证了威胁的完整性；有了威胁就会有风险，有风险就需要根据风险来设计相应的缓解措施；这就是威胁建模的核心价值。而发现设计漏洞，实际上就是发现某个威胁没有相应的缓解措施或是缓解措施的设计BUG可以被绕过。

这里还有一点值得注意，就是所有的缓解措施都不能100%的缓解风险，缓解措施的目的是通过合适的成本将风险降低到一个可接受的范围内。

7．安全特性组件化可尽量避免编码漏洞

代码漏洞对于软件来说几乎是不可避免的，据数据统计，代码量与漏洞成正比。即便最早提出和实施方法论的微软，也不能保证代码百分之百没有漏洞。

漏洞问题对产品来说是最直观的（可直接利用），也是最头痛的（消灭不了）；代码漏洞也是S-SDLC需要重点解决的问题。目前多数也认识到这一问题，并选择使用代码扫描工具，例如SAST和DAST等，但这类工具存在致命的缺陷：误报和漏报。误报过多造成大量研发资源的浪费，而漏报过多又会使得工具的应用效果大打折扣。代码扫描工具的漏报和误报是必然存在的，S-SDLC中也有如何降低漏洞和误报的实践，但这更多需要依赖于新型的安全检测工具去解决。

从S-SDLC的整体视角上看，扫描工具只能发现部分已存在的代码漏洞，并不能减少代码漏洞的产生，属于“后端被动式”的解决思路。S-SDLC更关注如何减少代码漏洞的产生，也就是如何从“前端”主动解决问题。一个比较好的实践就是将产品中的安全特性组件化，比如：密码算法模块、认证授权模块，这些模块都是重要的缓解措施实现，一旦出问题就导致缓解措施被绕过的漏洞。因此，将这些模块组件化，让不同的产品在这些领域都使用公共组件，而不用自己开发，自然也就不会引入漏洞；而这些公共的组件则由安全专业团队重点保障。在微软，为了避免参数校验问题导致和缓冲区溢出问题，由专业的安全团队重写了经常导致漏洞的函数（如：memcpy、strcpy）,并由一系列自身带有安全校验的函数来代替。这一措施使得产品在很大程度上解决了缓冲区溢出的问题（虽不能全部解决，但效果显而易而，且投入成本不高）。

8．管理第三方软件的风险

不论是传统的软件企业还是新型的互联网企业，在软件开发的过程中都免不了要使用第三方组件。第三方组件既包含开源软件，也包含商业软件。而且随着软件越复杂，第三方软件的使用数量也越来越多。从安全的角度看，第三方软件也是一个重要的风险源（比如，前两年OpenSSL的漏洞集中暴发）。第三方软件不仅是产品集成的组件，开发环境中所用到的工具也要作为第三方软件来对待（XcodeGhost事件大家应该都还记得）。

第三方软件与自主研发的软件不一样。S-SDLC的方法和流程没法覆盖开源社区和第三方厂商。那么如何管理第三方软件的风险，也是S-SDLC实施过程中面临的一个主要的问题。具体来说，有以下实践供大家参考： （1）企业要有清单列表记录哪些产品使用了哪些第三方软件。一旦某个第三方软件出现漏洞，可以通过清单列表迅速排查。 （2）企业要有清单列表记录禁用的第三方软件。对于那些安全问题比较多、风险较大的第三软件，应加入到这个禁用清单列表中禁止使用。 （3）对于使用较多且开源的第三方组件，建议进行代码扫描，对于发现的漏洞，提交开源社区，并促使开源社区修复。 （4）对于第三方软件的使用要有安全性指导（主要是规避一些因配置不当引入的安全问题）。 （5）慎用对安全问题处理态度消极的厂商所开发的第三方软件。

9．安全服务化和自动化是实施DevSecOps的基础

近年来，DevOps的开发模式已被广泛应用。DevOps的核心思想是将开发和运维一体化，开发能快速推出产品进行AB测试，通过数个版本的迭代，使产品变得成熟稳定，同时也使产品功能变得丰富。 在DevOps开发模式下，传统的S-SDLC流程在DevOps模式下显得过于厚重，那么就需要有适用于DevOps流程的S-SDLC，这就是DevSecOps的由来。由于运维流程也一体化了，因此在传统S-SDLC的安全成本模型也就发生了变化。举个例子来说，在传统S-SDLC的测试过程中，我们要尽可能的发现所有的安全漏洞，因为产品一旦发布，漏洞的修复成本会很高；但在互联网企业自己开发、自己测试、自己运维的DevOps模式下，产品发布后，漏洞修复的成本并不一定有增加很多。因为运维一体化后，漏洞一旦发现，响应的时间可控制在一个很短的时间内。 但这并不是说DevOps之后开发过程中的安全活动就不需要做了，只是做的方式会有差异。这个差异主要来自于安全功能的服务化、自动化工具。安全功能服务化本身符合SOA架构和微服务架构的演进方向。安全功能服务化后，就能将产品的一些安全风险转移到安全服务上。以IAM服务为例，采用成熟的IAM服务能在很大程度上降低产品在认证和授权方面的问题。AWS提供的移动应用账号服务可以让移动应用直接集成，而不用担心账号的安全问题；或是采用OAuth认证方式，采用安全性很强的Google、QQ、微信等知名厂商的安全认证对接。这样自然就减少了产品研发过程中的安全投入，使S-SDLC可以变得快起来。另一方面，采用工具实现自动化，也在很大程度上能减少S-SDLC过程的投入。

10．S-SDLC工具链

无论在普通开发、敏捷开发还是DevSecOps模式下，S-SDLC落地的关键都离不开流程体系和高度自动化工具链的融合。根据OWASP S-SDLC项目团队的实践积累，若有一个一体化的平台能准确、完整地记录、管理和追踪软件产品在S-SDLC实施过程中的实际情况，实现软件产品开发信息在S-SDLC流程中跨活动、跨角色流动，才能真正确保软件产品的安全需求和安全威胁在开发、测试和部署运维过程中落地。而无论是需求阶段的需求库、开发与测试的安全测试工具，还是其他安全工具，都将成为S-SDLC工具链中的一环。