Demystifying Dloud Security

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 ServiceInfrastructure 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

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

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


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


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)

YesNext 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


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


Our Actual Team Venn Diagrams


Ideal Scrum TeamsDaily Scrum StandupsMeeting room: Conference roomRemote: Conference/Video- Team number @ Time CST- Team number @ Time CST

Scrum Master Business Analyst Product Owner

Product Manager

DevelopersFront-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, 2011Created by: Ben Clay CSM, [email protected] - mobileBenjamin F Clay © 2012

Chief Infrastructure

Engineer

Lead Automation Engineer

Chief Architect orLead Developer

Senior Product Manager

Leadership Team

Senior Product Marketing Manager

Scrum of Scrums MasterBusiness Analyst, CBAP

Lead DBA Creative Director


Product Manager


Quality Assurance


Product Manager


Quality Assurance


Product Manager


Quality Assurance




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)


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


Problem/Resolu&on

•  Problem – Securing data in the cloud

•  Resolu&on – Hybrid Cloud

•  Public and private side


•  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:


•  Housing and sharing pa&ent data for various purposes, but especially an HIE (Health Informa&on Exchange)

Use Case 2

Virtual DB

DBDB

DB ApplicationServer

Hospital


Hospital


Hospital


Hospital


Hospital


Hospital


Hospital


Hospital

Clinic Clinic

ClinicClinic

Clinic

Clinic

Clinic

Clinic


•  IaaS -‐ Work environments for different purposes – Development environment – QA environment – Staging Environment – Sales Demo environment

Use Case 3


Financial Institutions

Browser

Web Application

Auxiliary Services

Virtual DB

TransactionServer

AuxillaryApplication

DB

Comm Network

Computer

PhysicalComputingServices

Cloud ComputingService

PCI Compliant Public Hybrid Cloud Overview


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


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


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


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


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)


PCI Compliant Hybrid Cloud Produc&on Diagram


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


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]


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


Q&A


Contact Info

Ben Clay [email protected] Linkedin hEp://www.linkedin.com/profile/view?id=49080988&trk=tab_pro


Bonus Slide 1


24/7

No YesHave you groomed the product backlog?

PreSprint Plan(Sprint 0.x)

Groom the Product Backlog

Don't expect the Team to read your mind!

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

YesHave you finished the Sprint

No

Sprint Showcase

Was the Product accepted by the Product Owner?

Yes

Practical Scrum Work FlowBenjamin 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)

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.



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.



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.



TIME RANGE ESTIMATION CHAPTER 4 TIME RANGE ESTIMATION EXAMPLE Team Es&mated, Actual, Forecasted Es&mate and Forecasted Actual Veloci&es


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)


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.


Date post:	17-Oct-2014
Category:	Technology
View:	297 times
Download:	1 times

Demystifying Dloud Security

Technology