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 Platform as a Service Software as a Service Database 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

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
benfclay@gmail.com
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
benfclay@gmail.com
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