Week 4.1 Building security into the software development lifecycle copy.pptx

A secure software engineering

1. Week 4 : SSDLC and Security Design Principles Building security into the software development lifecycle

2. Secure Software Development Life Cycle Azida Zainol [email protected] Department of Computing College of Business, Technology and Engineering Sheffield Hallam University

3. Outlines Software Development Lifecycle (SDLC)/Models DevOps Secure Software Development Lifecycle (SSDLC) Conclusion

4. Software Development Life Cycle

5. What is SDLC?

6. Your Turn What is software development model? Any example?

7. SDLC Models Agile Lean Waterfall Iterative Spiral DevOps

8. Integration of DevOps Benefits: Faster Innovation Implementation Failure Reduction Better Communication/Collaboration Greater Competencies Costs Reduction DevOps  is a combination of software development (dev) and operations (ops). It is defined as a software engineering methodology which aims to integrate the work of development teams and operations teams by facilitating a culture of collaboration and shared responsibility. DevOps can be best explained as people working together to conceive, build and deliver secure software at top speed.

9. Secure-Software Development Life Cycle

10. Current Software Build Methodology

11. SECURE Software Development Life Cycle

12. Secure Software Development Consider security throughout the software development lifecycle Requirements Design Development Testing Deployment

13. Secure Software Development Life Cycle (SSDLC)

14. Phase 1 : Requirements In this early phase, requirements for new features are collected from various stakeholders. It’s important to identify any security considerations for functional requirements being gathered for the new release. Sample functional requirement:  user needs the ability to verify their contact information before they are able to renew their membership.  Sample security consideration : users should be able to see only their own contact information and no one else’s.

15. Phase 2 : Design This phase translates in-scope requirements into a plan of what this should look like in the actual application. Here, functional requirements typically describe what should happen, while security requirements usually focus on what shouldn’t. Sample functional design:  page should retrieve the user’s name, email, phone, and address from CUSTOMER_INFO table in the database and display it on screen. Sample security concern:  we must verify that the user has a valid session token before retrieving information from the database. If absent, the user should be redirected to the login page.

16. Phase 3 : Development When it’s time to actually implement the design and make it a reality, concerns usually shift to making sure the code well-written from the security perspective . There are usually established secure coding guidelines as well as code reviews that double-check that these guidelines have been followed correctly. 

17. Development Apply coding rules/practices that implement secure design

18. Development Coding Practice How to Implement It 1. Input validation: Never Trust User Input Check data length Validate characters set Check data format Use restrictions 2. Manage Authentication and Passwords Use transport layer security (TLS) client authentication Implement authentication error messages Store, control and manage your passwords safely Transmits passwords securely 3. Sanitize Data First, Then Send the Inputs to Other Systems Use a whitelist (allowlist) Use a blacklist (blocklist) Escape inputs to keep things safe 4. Adopt the Principle of Least Privilege Validate permissions on every request Create tests to validate permissions before release Periodically review permissions

19. Development Coding Practice How to Implement It 5. Architecture: Make It Unique and Secure Use subsystems Follow OWASP’ secure architecture (SA) practice Load only secure plugins and libraries 6. Keep It Intuitive But Effective Use a simple and small design Don’t over-complicate your security controls Be user-friendly 7. Deny Access by Default Keep unauthenticated users out Apply this policy to new user accounts too Keep new features sealed 8. Go Deep With Your Defense: Create Multiple Security Layers Configure the security settings of each application Pair secure programming with secure runtime environments Don’t forget authentication checkers

20. Development Coding Practice How to Implement It 9. Secure Your Work and Communication Use strong, readily available encryption Protect your database Use trusted security certificates Sign your code before releasing it 10. Check the Quality of Your Code and Follow Coding Standards Review your code Use effective quality assurance mechanisms Use coding standards developed by international bodies Prevent attacks with threat modeling

21. Development Use automated code review techniques to find potential vulnerabilities components Static Analysis Symbolic execution

22. Phase 4 : Verification The  Verification  phase is where applications go through a thorough testing cycle to ensure they meet the original design & requirements. This is also a great place to introduce automated security testing using a variety of technologies. The application is not deployed unless these tests pass.

23. Verification Verification at this phase may include: Automated tests that express the critical paths of your application Automated execution of application unit tests that verify the correctness of the underlying application Automated deployment tools that dynamically swap in application secrets to be used in a production environment

24. Phase 5 : Maintenance and Evaluation The story doesn’t end once the application is released. In fact, vulnerabilities that slipped through the cracks may be found in the application long after it’s been released. These vulnerabilities may be in the code developers wrote, but are increasingly found in the underlying open-source components that comprise an application.  Vulnerabilities at this stage may also come from other sources, such as external penetration tests conducted by ethical hackers or submissions from the public through what’s known as “bug bounty” programs.

25. Different methodologies BSIMM (Building Security In – Maturity Model) http://bsimm.com Microsoft Security Development Lifecycle https://www.microsoft.com/en-us/sdl/ OpenSAMM Software Assurance Maturity Model http://opensamm.org

26. Continuous Delivery of Software

27. Continuous Security Requires security automation Integrate into Continues Delivery (CD) environment and tools A CD environment is a type of production environment in which ongoing automation and monitoring are implemented to improve and expedite development processes for integration and testing, and deployment and delivery . Source code management systems GitHub , Bitbucket etc. Build systems Travis CI, Jenkins etc. Audit third party component and open-source library usage

28. Takeaways Security practices should be built in during the software development process Continuous delivery needs continuous security

29. Conclusion

30. Conclusion Necessary to integrate the SSDLC Cyber criminals’ efficiency is improving The cyber threat is only going to get worse

31. 34 Carlos Eduardo da Silva ([email protected])

32. Questions?