Demystifying Cloud Security
1 like1,529 views
The document outlines a project focusing on creating a public-facing web application for consumer products while ensuring PCI compliance for data security in the cloud. It details the timeline, modules development, agile project management workflows, and the hybrid cloud structure designed to securely manage credit card information. Key benefits of cloud computing such as cost-effectiveness, scalability, and remote management are also highlighted, alongside a plan for future advancements in cloud technology.
![Non
Provisional
Patent
Applica&on
Filed
Hos9ng
E-‐Commerce
Based
on
Cloud
Compu9ng
CROSS-‐REFERENCE
TO
RELATED
APPLICATIONS
The
instant
applica&on
claims
priority
to
and
incorporates
by
reference
for
all
purposes
United
States
provisional
patent
applica&on
number
61/471,666
filed
April
4,
2011,
en&tled
“Hos&ng
E-‐Commerce
Based
on
Cloud
Compu&ng,”
by
Benjamin
Franklin
Clay,
et
al.
[0001]
©
2009
–
2012
WriEen
and
All
Copyrights
reserved
by:
Ben
Clay
and
Rob
Morrow](https://image.slidesharecdn.com/demystifyingcloudsecurity-final-130927065333-phpapp01/85/Demystifying-Cloud-Security-22-320.jpg)
Demystifying Cloud Security
- 1. Demys&fying Cloud Security J o u r n e y f r o m P r o j e c t t o P a t e n t t o P u b l i c C o n s u m p & o n By Ben Clay and Rob Morrow Platform as a Service Software as a ServiceDatabase as a Service Load Balancing as a Service Monitoring as a Service Central Access Control as a Service Infrastructure as a Service Notification as a Service Validation as a Service Health Information Exchange as a Service © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 2. Cloud compu&ng is virtualized resources served up as services in the web. © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 3. Objec&ves • Public facing web applica&on for consumer product consump&on • House consumer credit card informa&on • Process credit cards for payment • Mine the credit card informa&on and purchases • Finish in six (6) months or less – Five (5) Web applica&ons – Four (4) mobile applica&ons © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 4. Timeline and Release Schedule Twenty-‐One (21) Business Day Sprint Dura&on 1st Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Database schema • UX/UI • Cloud infrastructure • QA • DEV • Staging • Local DEV Month 1 Month 2 Develop, skin, QA and deploy produc&on ready 1st module to staging. 2nd Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI Develop, skin, QA and deploy produc&on ready 2nd module to staging. 3rd Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI Month 3 Month 4 Develop, skin, QA and deploy produc&on ready 3rd module to staging. 4th Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI Develop, skin, QA and deploy produc&on ready 4th module to staging. 5th Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI Month 5 Month 6 Develop, skin, QA and deploy produc&on ready 5th module to staging. Mobile Applica9ons Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI Mobile Applica9ons Develop, skin, QA and deploy produc&on ready mobile applica&ons to staging, apple store and android market. Launch everything May 1 Month 7 © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 5. Agile Project Management Flow Chart Practical Scrum Adaptive PMLC Work Flow Benjamin F Clay © 2012 = Adaptive Project Management Life Cycle Equivalent Product Backlog Grooming 24/7 PreSprint Plan (Plan Cycle) Sprint Plan (Plan Cycle) Release Plan (Plan Cycle) Sprint Showcase (Close Cycle) Release Backlog (Scope and Plan Cycle) Yes Next Sprint (Next Cycle) Close Project No Product Backlog (Scope and Plan Cycle) Based on need. I schedule once a week reoccurring Once every week Every 24 hours Meta Scrum Daily Scrum Scrum of Scrum Sprint (Execute Iteration, Monitor & Control and Launch Cycle) Start Here © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 6. Why this project was different • We would be the first documented PCI compliant Cloud environment – Securing personal and credit card informa&on in a cloud environment • processing • mining and more • No documented cases – No blueprint – No prac&cal guide – No how to © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 7. Our Actual Team Venn Diagrams © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay Ideal Scrum Teams Daily Scrum Standups Meeting room: Conference room Remote: Conference/Video - Team number @ Time CST - Team number @ Time CST Scrum Master Business Analyst Product Owner Product Manager Developers Front-End Dev, Back-End Dev Quality Assurance Feature/Product Team 1 RULES • No more than 15 minutes in length • Traditionally a stand-up meeting • Not for problem solving • Whole world is invited • Only team members, Scrum Master, and product owner can speak • Each team member answers 3 questions (signifies commitment in front of team) • What did you do since the last meeting to help the team accomplish their goals and/or deadlines? • What are you going to help the team work on today to accomplish their goals and/or deadline? • Is anything preventing you from accomplishing your goal(s)? • Each member only speaks 60 seconds or less. March 10, 2011 Created by: Ben Clay CSM, CSP [email protected] 940.783.3372 - mobile Benjamin F Clay © 2012 Chief Infrastructure Engineer Lead Automation Engineer Chief Architect or Lead Developer Senior Product Manager Leadership Team Senior Product Marketing Manager Scrum of Scrums Master Business Analyst, CBAP Lead DBA Creative Director Scrum Master Business Analyst Product Owner Product Manager Developers Front-End Dev, Back-End Dev Quality Assurance Scrum Master Business Analyst Product Owner Product Manager Developers Front-End Dev, Back-End Dev Quality Assurance Scrum Master Business Analyst Product Owner Product Manager Developers Front-End Dev, Back-End Dev Quality Assurance Feature/Product Team 2 Feature/Product Team 4 Feature/Product Team 3
- 8. Contributor Types • EVP Product Management – Product Owners (IIBA’s) • Lead IT Porgolio Manager – ScrumMasters • Chief architect – Lead Infrastructure Engineer • Suppor&ng IT staff – Developers – UI/UX Expert – QA Staff – UAT (CEO, CFO, subsidiary and Focus Groups) © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 9. Risk • Comple&ng everything in six (6) months – Development and deploy all apps to produc&on • iOS apps to the apple store • Droid apps to the android market • Securing credit card data in the cloud © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 10. Problem/Resolu&on • Problem – Securing data in the cloud • Resolu&on – Hybrid Cloud • Public and private side © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 11. • Keeping credit card data on file Use Case 1 XXXXXXXXXXCardholder Name: XXXSecurity Code: XXXX"XXXX"XXXX"X123Card Number: Credit card Information Expiration Date: Telephone: XXX - XXX - XXXX 201412 XXXXXXX - State - XXXXXCity, State, Postal Code: VisaCard*Type Payment(Informa-on XXXXXXXXXXAddress*Line*1: Billing*Address*associated*with*this*card Address*Line*2: © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 12. • Housing and sharing pa&ent data for various purposes, but especially an HIE (Health Informa&on Exchange) Use Case 2 Virtual DB DBDB DB Application Server Hospital DB Application Server Hospital DB Application Server Hospital DB Application Server Hospital DB Application Server Hospital DB Application Server Hospital DB Application Server Hospital DB Application Server Hospital Clinic Clinic ClinicClinic Clinic Clinic Clinic Clinic © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 13. • IaaS -‐ Work environments for different purposes – Development environment – QA environment – Staging Environment – Sales Demo environment Use Case 3 © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 14. Financial Institutions Browser Web Application Auxiliary Services Virtual DB Transaction Server Auxillary Application DB Comm Network Computer Physical Computing Services Cloud Computing Service PCI Compliant Public Hybrid Cloud Overview © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 15. The Need and Benefit • Cloud compu&ng offers the following: – No massive equipment purchase – Lower Total Cost of Ownership (TCO) – Remote management with ease – Increased speed to market – Greater efficiency © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 16. The Need and Benefit Con&nued – Scalability – Faster and easier development – Ease of produc&on deployment – Plagorms for modular development – Unmatched flexibility – Infrastructure as a service © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 17. What is inside the Cloud? • Encapsulated complexi&es of the infrastructure that normally would be in a server room are now virtualized • No need to see and/or know what exactly is in your cloud only the services it delivers © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 18. Why a Hybrid Cloud? • Combina&on of applica&on, sonware and hardware for PCI compliance • Private secure Cloud for the PCI data – Security is the main concern. • Public Cloud for consumer facing applica&ons © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 19. PCI Compliant Hybrid Cloud • Combina&on of a public and private cloud • Private cloud secure for storing credit card processing data • Public cloud for allowing access to consumer facing web applica&on(s) © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 20. PCI Compliant Hybrid Cloud Produc&on Diagram © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 21. PCI Compliant Hybrid Cloud Patent Process • Func&onal decomposi&ons • Sequence Diagrams • Flow Charts • Network diagrams • Fully documented process and patent applica&on • Demo fully func&onal PCI Compliant Hybrid Cloud in produc&on © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 22. Non Provisional Patent Applica&on Filed Hos9ng E-‐Commerce Based on Cloud Compu9ng CROSS-‐REFERENCE TO RELATED APPLICATIONS The instant applica&on claims priority to and incorporates by reference for all purposes United States provisional patent applica&on number 61/471,666 filed April 4, 2011, en&tled “Hos&ng E-‐Commerce Based on Cloud Compu&ng,” by Benjamin Franklin Clay, et al. [0001] © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 23. Future for the Cloud • Endless possibili&es – Next most important is GHIE • Global Health Informa&on Exchange – Global Financial Informa&on Exchange (GFIE) – Global Intelligence Informa&on Exchange (GIIE) – Global ANY KIND OF Informa&on Exchange © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 24. Q&A © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
- 25. Contact Info Ben Clay [email protected] Linkedin hEp://www.linkedin.com/profile/view? id=49080988&trk=tab_pro © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 26. Bonus Slide 1 © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay 24/7 No Yes Have you groomed the product backlog? PreSprint Plan (Sprint 0.x) Groom the Product Backlog Don't expectthe Team toread yourmind! Sprint Plan Release Plan Have you broken user stories into high level task? Yes Have you estimated all the tasks & rolled them up into one estimate total? No No Yes Have you finished the Sprint No Sprint Showcase Was the Product accepted by the Product Owner? Yes Practical Scrum Work Flow Benjamin F Clay © 2012 Yes No Have you added up the totals and calculated the end dates of each sprint? No Release Backlog Yes Start Here Based on need. I schedule once a week reoccurring Every 24 hours Daily Scrum Sprint Meta Scrum If not accepted then the team didn't do all the user stories committed to PreRelease Planning (What the business would like to have) Once every week Scrum of Scrum Release BSchedule (add shippable product)
- 27. Time Range Es&ma&on Bonus Slide 2 TIME RANGE ESTIMATION CHAPTER 4 FIBONACCI TIME RANGE ESTIMATION SEQUENCE Each team member will give a number to weight each task with a total weight for each story known as story points. This is based off of an eight (8) hour business workday. 1,2,3 and 5 are the numbers to be used. 1=easy,.30–4hours 2 = easy &me consuming, 4.5 – 8 hours 3 = medium 8.5 – 16 hours 5 = advanced, 16.5 – 24 hours No story point shall be greater than 5. If it is determined to be greater than 5, the task shall be broken down into smaller tasks. ESTIMATING THE TASK If a team member thinks the task will take four (4) hours and ten (10) minutes then you assign two (2) story points to that task. By assigning two (2) story points to this task you have effec&vely stated that this task could take four and a half (4.5) to eight (8) hours to complete. This covers most anomalies and/or scope creep that might arise for that task. Always round up ensuring that you aEempt to cover anomalies and/ or scope creep. If a team member es&mates it will take four (4) hours to complete a task you also assign two (2) story points to that task. Always round up to the next increment. Following this method for all the tasks it takes to create all user stories allows for managing scope creep by automa&cally buffering the &me range es&ma&on allowing room for a certain amount of addi&onal and/or development changes. Obviously it isn’t meant to be a way for business to force the team to do more work, but rather enough buffer to catch a certain amount of incidentals only. You will s&ll need to manage this, but at least you will have some wiggle room. © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 28. Time Range Es&ma&on Bonus Slide 3 TIME RANGE ESTIMATION CHAPTER 4 DAILY WORK LOGS A team member should always log the actual work not the es&mated work. The actual work may have taken less or more &me than es&mated and by logging and/or recording the actual &me it took to complete, the data is referenceable and can be used to compare against similar task in the future. This data will also help the team become more accurate and/or efficient with &me range es&ma&on allowing for the Scrum Master to more effec&vely forecast anything from story points to produc&on deployable dates. There are a lot of scenarios I could talk about here concerning miss logged work, but I will talk about only two of them. Scenario 1. An inexperienced team member is not accurately es&ma&ng the task logging more points than es&mated. May need some remedial task &me range es&ma&on from the team lead and/or help breaking down and es&ma&ng their future task. Scenario 2. An experienced team member es&ma&ng more &me than it should take and logging those points for the purpose of appearing to do more work than they really are. If a team member is always logging as many points as they es&mate have that team member pair es&mate with the team lead and/or a senior developer. I’m sure if you have problems like the above or more your team will let you know. No one likes to take up the slack while others are sliding by. There are a lot of reason why es&ma&ng like this won’t work, but there are a lot of reasons why it will. More than that you can use just the &me range es&ma&on should you want to not use story points. © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 29. Time Range Es&ma&on Bonus Slide 4 TIME RANGE ESTIMATION CHAPTER 4 Establishing Team and/or Individual Veloci9es From this point it is easy to show the es&mated team velocity prior to the sprint start date and then monitor the actual team velocity during and/or aner the sprint. This also makes it easy to manage scope creep as long as the work logs are entered daily or at least semi daily. Establishing any velocity has some kind of monetary meaning &ed to it and is why I &tled this sec&on, “Establishing Team and/or Individual Veloci&es”. The fact is someone has to present something to a governing body of one or more people or group such as a board of directors. I have used team veloci&es to assist me in the forecas&ng of break-‐even points, Return On Investment (ROI) and lowering the Total Cost of Ownership (TCO). I have used Individual Veloci&es to show why a company should invest money in a developer and/or any other member of the team by training them, giving spot bonuses, base pay raises and/or any other monetary gain or incen&ve. Combine all this data and you can confidently forecast your team’s velocity from sprint to sprint or even quarter to quarter. © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
- 30. Time Range Es&ma&on Bonus Slide 5 TIME RANGE ESTIMATION CHAPTER 4 TIME RANGE ESTIMATION EXAMPLE Team Es&mated, Actual, Forecasted Es&mate and Forecasted Actual Veloci&es © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay 145 152 156 138 152 154 151 148 125 130 135 140 145 150 155 160 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Team 4 Estimated, Actual, Forcasted Estimate and Forcasted Actual Velocities Estimated Actual Forcasted Estimate Forcasted Actual Linear (Actual)
- 31. Time Range Es&ma&on Bonus Slide 6 Disclaimer All forecas&ng data should be based off the same four series of sprint dura&on, team size, experience level and skillset level. Should any of that change you will need to start over and average out at least three successful sprints. All my data was based off of a twenty-‐one (21)-‐ business day sprint cycle. © 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay