Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Requirements Gathering for a Successful Rugged DevOps Implementation - Hasan Yasar
Similaire à Requirements Gathering for a Successful Rugged DevOps Implementation - Hasan Yasar (10)
Plus de SeniorStoryteller
Plus de SeniorStoryteller (17)
Dernier
Dernier (20)
Requirements Gathering for a Successful Rugged DevOps Implementation - Hasan Yasar
- 1. Requirements Gathering for a Successful Rugged DevOps Implementation Hasan Yasar | Technical Manager | Software Engineering Institute - CMU
- 5. Background • The Software Engineering Institute (SEI) is a Federally Funded Research and Development Center (FFRDC) • Research and practice in software development, acquisition, and maintenance practices • Assisted numerous government organizations in modernizing their software development practices in the spirit of DevOps principles. • Application security is the principle quality attribute of the software they produce.
- 7. The Rugged Manifesto I am rugged and, more importantly, my code is rugged. I recognize that software has become a foundation of our modern world. I recognize the awesome responsibility that comes with this foundational role. I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended. I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security. I recognize these things – and I choose to be rugged. I am rugged because I refuse to be a source of vulnerability or weakness. I am rugged because I assure my code will support its mission. I am rugged because my code can face these challenges and persist in spite of them. I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.
- 10. What went wrong? • DevOps is – AFAD – Only about tooling – A Product – Only about Dev and Ops – Same for all orgs – Only continues integration/deployment – New organizational unit
- 12. Current State Assessment • Interview with functional leads from key areas related to Application Development. • Review of: – Validation of statements (e.g., through observations of the work environment or shadowing) – Demonstrations of any software tools used for automation of software development and deployment – Cultural perspective related to development evolution and Security team – Legal, Risk Management and all stakeholders
- 13. Assessment Plan 1. Agree on definitions(DevOps, DevSecOps) and process 2. Identify stakeholders 3. Perform interview on each team 4. Identify and analyze technical tool stack 5. Collect key metrics and establish measurement 6. Identify gap areas and develop a roadmap 7. Select suitable project to implement: Build , Learn, evaluate
- 14. Assessment Process • Scheduling an interview with teams • Anonymous Survey • Analyze outcomes • Provide feedback to the teams • Brief the executive team
- 21. Assessment – Business Analyst/ PM • Requirements development & management • Acquisition & contracting process • Risk management process • Compliances requirements • Project Planning and tracking
- 22. Assessment – Developer • Development methodology – agile, waterfall, SAFe, EP, Lean, or cowboy coding • Development environments • Task assignment/management / completion • Collaboration with other (internal/external) teams
- 23. Assessment – Quality Assurance • Software testing methodologies • Software {quality} assurance • Compliances verification • Audit requirements • Feedback to dev team
- 24. Assessment – Deployment /Release • Software configuration management • Integration process • Software verification and validation process • Software review and audit process • Securing the deployment pipeline
- 25. Assessment – IT Operations • Software operational process • Team engagement • Policy knowledge management • Assets management • IT governance • Service management • Audit and monitoring
- 26. Assessment – Information Security • Management and auditing supply chain • Security controls • Security polices (compliance requirements) • Application security testing • Product security management (PSIRT) • Security awareness training and knowledge management
- 27. Assessment – Technology Stack • Development language and tools • IT solution stack • Enterprise support services • Legacy systems • Application development support tools • Software reuse process • Accreditation and approval process
- 28. Identify Metrics and Measurement • Software metrics • Quality metrics • Checkpoint diagnostic – Qualitative process baseline – Quantitative performance baseline – Benchmark performance comparison • Define end-goal as being Rugged: What that means to all stakeholders
- 29. Identify Suitable Project • Select {new or existing} project as pilot – Most stakeholders involvement – Minimize risk to business – Ability learn/develop/ implement security in the process – Scalable to the organization
- 31. Feedback to the team • Collaborate all team leads • Share identified requirements • Categorize and prioritize the requirements • Collectively develop an implementation plan: People+ Process+ Platform
- 32. People • Heavy collaboration between all stakeholders – Secure Design / Architecture decisions – Secure Environment / Network configuration – Secure Deployment planning – Secure Code Review • Constantly available open communication channels: – Dev and OpSec together in all project decision meeting – Chat/e-mail/Wiki services available to all team members
- 33. Process • Establish a process to enable people to succeed using the platform to develop Rugged application • Such that; • Constant communication and visible to all • Ensures that tasks are testable and repeatable • Frees up human experts to do challenging, creative work • Allows tasks to be performed with minimal effort or cost • Creates confidence in task success, after past repetitions • Faster deployment , frequent quality release
- 34. Platform • Where people use process to build rugged software • Automated environment creation and provisioning • Automated infrastructure testing • Parity between Development, QA, Staging, and Production environments • Sharing and versioning of environmental configurations • Collaborative environment between all stakeholders
- 35. Rugged Continued … • Culture – NOT a tool, SDLC, or org structure • Rugged != Secure - secure is only an instant in time • Proactive security is better than reactive – Reactive will fail eventually
- 36. Culture Process and Practices System and Architecture Automation and Measurement Rugged DevOps on Security Culture • Developer and OpSec collaborate • Developers and OpSec support releases beyond deployment • Dev and OpSec have access to stakeholders who understand business and mission goals Security Automation / Measurement • Automate repetitive and error- prone tasks (e.g., build, testing, and deployment maintain consistent environments) • Static and dynamic security analysis automation • Performance dashboards Security in Process and Practices • Secure Pipeline streamlining • Continuous-delivery practices (e.g., continuous integration; test automation; script-driven, automated deployment; virtualized, self-service environments) Secure System and Architecture • Architected to support test automation and continuous- integration goals • Applications that support changes without release (e.g., late binding) • Scalable, secure, reliable, etc.