security avalanche

83
Security Avalanche Michele Leroux Bustamante [email protected] t

Upload: michele-bustamante

Post on 06-May-2015

989 views

Category:

Technology


0 download

DESCRIPTION

Session I delivered at Oredev, with some updates, more detail, reviewing all of the security standards including ws-federation, saml, ws-trust, oauth,openID connect.

TRANSCRIPT

Page 1: Security Avalanche

Security Avalanche

Michele Leroux [email protected]

Page 2: Security Avalanche

Hello World!1992

Page 3: Security Avalanche

Hello World!

Page 4: Security Avalanche

Hello World!1995-2007

Page 5: Security Avalanche

RichClient

Web Services Web App

Web Services

Page 6: Security Avalanche

1999 - 2007

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Page 7: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Transport Protocols

HTTPSHTTP SMTP

Page 8: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

XMLXML Schema

XML XML Encryption

XML Digital Signatures

Page 9: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

MessagingWS-Eventing

WS-Addressing SOAP

MTOM

sWa

WS-Transfer

WS-Enumeration

DIMEWSRF

WSN

Page 10: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Met

adat

a

WS-Policy

WSDL

WS-PolicyAttachment

WS-Discovery

WS-MetadataExchange

Page 11: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

ReliableMessaging

WS-RX

WS-RM Policy

WSRM

Page 12: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Transactions

WS-TX

WS-CAF

WS-BusinessActivity

WS-Coordination

WS-AtomicTransaction

Page 13: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

WorkflowWS-ChoreographyBPEL

Page 14: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Man

agem

ent/

QO

S

WS-Manageability

WSDM

Page 15: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Industry-Specific StandardsInsurance Law Enforcement

Financial Services Goverment

Page 16: Security Avalanche

XML

Messaging

Security ReliableMessaging Transactions

Met

adat

a

Workflow

Industry-Specific Standards

Transport Protocols Man

agem

ent/

QO

S

Security

OASIS Web Services Security

WS-SecurityPolicy

WS-Federation

SAML

WS-SecureConversation

WS-Trust

WS-SX

Page 17: Security Avalanche

WS*

HELL

WS-Eventing

WS-Addressing

SOAP

MTOM

sWa

WS-Transfer

WS-Enum

eration

DIME

WSNWS-ResourceTransfer

WSRF

OASIS Web Services Security

WS-SecurityPolicy

WS-Federation

SAML

WS-SecureConversation

WS-

Trus

t

WS-ReliableMessaging

WS-RM

Policy

WS-

Relia

bilit

y

WS-CAF

WS-BusinessActivity

WS-Coordination

WS-A

tom

icTr

ansa

ctio

n

WS-Policy

WSDL

WS-PolicyAttachment

WS-Discovery

WS-M

etadataExchange

Page 18: Security Avalanche

Hello World!1992

Page 19: Security Avalanche

RichClient

Web Services Web App

Web Services

Page 20: Security Avalanche

iPhoneWindowsPhone 8

Windows8/Surface

RichClient

WindowsPhone 7

Android

iPad

Web API(mobile)

Web App

MobileBrowsers

Web API(business)

Web API(ajax)

Page 21: Security Avalanche

2006 - 2013Open ID 1.0

Open ID 2.0

OpenID Connect1.0

Simple Web Token (SWT)

JSON Web Token (JWT)

OAuth 1.0a

OAuth WRAP

OAuth 2.0

Page 22: Security Avalanche

SIMPLICITY WINS

Page 23: Security Avalanche

Security Standards: Goals

• Single Sign-On (Passive Federation)• Partner Federation (home realm redirection)• Active Federation• Delegation (on behalf of)• Delegated Authorization

Page 24: Security Avalanche

Session Agenda

• Review the relevant standards of today• Practical applications• Trends• Implementation and architecture scenarios

Page 25: Security Avalanche

Passive Federation

Browser

WebApplication STS

LoginPage

1

2

5

3

4

Page 26: Security Avalanche

Active Federation

STS Web Service

RichClient

1 2 3

Page 27: Security Avalanche

WS-Federation

• HTTPS• SAML bearer tokens

– Signed by issuer– Unencrypted and no proof key– Requires transport protection

• Core Messages– SignIn request and response– Sign out and clean up

27

SignIn ResponseRequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

Page 28: Security Avalanche

WS-Federation

Browser

ActiveSTS

PassiveSTS

HTTP GETwa=wsignIn1.0wctx=[context]wreq=[tokentype]

RST RSTR

HTTP POSTwctx=[context]wresult=RSTR

RSTRRequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

PassiveRP

Page 29: Security Avalanche

Home Realm Discovery

1

Web Site(RP)

IP-STS(IdP)

Browser(requestor)

HTTP POSTwresult={Signin

Response}wctx=[context]

HTTP GETwa=wsignIn1.0wtrealm=[Uri]whr=[Uri]wreply=[Uri]wctx=[context]

2

SignIn ResponseRequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

Page 30: Security Avalanche

WS-Trust

• HTTPS or Message Security (WS-Security)• SAML holder-of-key tokens

– Signed by issuer– Encrypted for relying party– Includes proof key

• Core Messages (WS-Federation also uses)– RST and RSTR– Token validation, renewal or cancellation

30

Page 31: Security Avalanche

ActiveSTS

Client

RST RSTR

WS-Trust / Issue()

RST

TokenType = SAML 2

Claims = name, role

RequestType = Issue

AppliesTo = /RelyingParty

RSTRLifetime

RequestedProofToken

RequestedSecurityToken

SAML 2 Token

Attributes (Claims = name, role)

Subject Confirmation

Token Lifetime

Signature

Proof Key

Proof Key

1

RP

Message Headers

SAML Token

Signature = Proof Key

2

3

Page 32: Security Avalanche

Delegation / On Behalf Of

Client

Service

STS CredentialsWeb Application

Holder-of-key token

Bearer token

Page 33: Security Avalanche

SAML

• Security Assertion Markup Language– OASIS standard– Several versions 1.0, 1.1, 2.0

• Describes an XML security token format and message exchange protocol– Tokens are also used in federated security

scenarios for web services– Message exchange is primarily browser-

based

Page 34: Security Avalanche

SAML 2 SP-Initiated

Browser

ServiceProvider

IdentityProvider

(STS)

LoginPage

1

2

5

3

4

Page 35: Security Avalanche

Claims

• Identity providers typically issue claims based on the user’s identity

Authenticate

Claims:[email protected]=trueRole=AdminRole=User

Credentials:UserName=mlbPassword =*******

Page 36: Security Avalanche

Claims

• Applications may transform identity claims into application-specific claims

Transform

Application Specific Claims:LicenseKey=ABC12345Permission=CreatePermission=ReadPermission=UpdatePermission=Delete

Identity ProviderClaims:[email protected]=trueRole=AdminRole=User

Page 37: Security Avalanche

Where are we now?

WS-Federation

WS-Trust

SAML 2

Page 38: Security Avalanche

Motivation for OAuth

• No password sharing (valet key)• Reduced risk of compromised credentials• Ability to revoke access without changing

password

Page 39: Security Avalanche

History

• OAuth 1.0a– Complicated workflows– Required signatures– BUT, no SSL required

• OAuth 2– Simplified workflows– Rely on SSL for transfer protection– Signatures NOT required

Page 40: Security Avalanche

OAuth2 Participants

• Resource Owner• Client• Authorization Server• Resource Server

Page 41: Security Avalanche

OAuth2 Abstract Flow

• Client requests authorization from Resource Owner to access resources

• Resource Owner grants access through Authorization Server

• Client uses access token to request resources from Resource Server

• Resource Server returns resource if access token is valid

Page 42: Security Avalanche

OAuth 2 Abstract Flow

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Authorization Response(return authorization

code/grant)

Authorization Request

Authorization Response

Access Token Request (send authorization code)

Access Token Response (return access_token / refresh_token)

Resource Request (send access_token)

Protected Resource

Page 43: Security Avalanche

OAuth 2 Abstract Flow

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Authorization Response

Authorization Request

Authorization Response

Access Token Request

Access Token Response

Resource Request

Protected Resource

IdentityProvider

Credentials

Authentication Token

Page 44: Security Avalanche

Authorization Grant

• Represents Resource Owner authorization• Types of grants

– Authorization Code– Implicit – Resource Owner Password Credentials– Client Credentials

Page 45: Security Avalanche

Endpoints

Client Authorization Server

RedirectionEndpoint

POST

TokenEndpoint

AuthorizationEndpoint

GET/POST

Page 46: Security Avalanche

OAuth2 Flows

• Authorization Code Grant– Redirect based, web server redirect endpoint

• Implicit Grant– Browser based (JavaScript), Mobile

• Resource Owner Password Credentials Grant– Resource owner username/password known to client

• Client Credentials Grant– Application based

• Extension Grant

Page 47: Security Avalanche

Authorization Code

• User agent redirection (I.e., browser)• Resource Owner must authenticate to

Authorization Server – Credentials never shared with Client– Authorization code sent to Client

• Client requests access token using authorization code– Access token never passed to user agent

Page 48: Security Avalanche

Authorization Code Grant

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Authorization Response

Authorization Request

Authorization Response

Access Token Request

Access Token Response

Resource Request

Protected Resource

Page 49: Security Avalanche

Authorization Code Flow

Browser

ClientApplication

Authorization Server

LoginPage

1

2

5

3

4

ResourceServer

codestate*

grant_typecoderedirect_uriclient_id6

7Credentials

response_typeclient_idredirect_uri*scope*state*

codestate*

5

acess_tokentoken_typeexpires_in*scope*state*refresh_token*

Page 50: Security Avalanche

Implicit

• Optimized for JavaScript clients• Access token issued to Client directly

– No authorization code (intermediate credential)– Access token may be visible to resource owner,

user agent

Page 51: Security Avalanche

Implicit Grant

ResourceOwner

Client

Authorization Server

ResourceServer

Authorization Request

Access Token Response

Authorization Request

Access Token Response

Resource Request

Protected Resource

Page 52: Security Avalanche

Implicit Flow

Browser

ClientApplication

Authorization Server

LoginPage

1

5

2

3

ResourceServer

access_token

Credentials

response_typeclient_idredirect_uri*scope*state*

4

acess_tokentoken_typeexpires_in*scope*state*

Page 53: Security Avalanche

Resource Owner Password Credentials

• Resource Owner credentials supplied to request access token

• Client is tightly coupled to Resource Owner– High degree of trust– Client collects credentials to get access token

• Can exchange credentials for access token– Dispose of passwords in memory

Page 54: Security Avalanche

Resource Owner Password Credentials Grant

ResourceOwner

Authorization Server

ResourceServer

Access Token Response

Resource Request

Protected Resource

Client

Resource Owner Password Credentials

Access Token Request

Page 55: Security Avalanche

Resource Owner Password Credentials Grant

ClientApplication

Authorization Server

LoginPage

ResourceServer

3

7Credentials

grant_typeUsernamepasswordscope*

acess_tokentoken_typeexpires_in*scope*state*refresh_token*

1 2

Page 56: Security Avalanche

Client Credentials

• Client is also Resource Owner• Present client credentials to request access

Page 57: Security Avalanche

Client Credentials Grant

Authorization Server

ResourceServer

Access Token Response

Resource Request

Protected Resource

Client

Access Token Request

ResourceOwner

Page 58: Security Avalanche

Client Credentials Grant

ClientApplication

Authorization Server

ResourceServer

1

2Credentials

grant_typeclient_id*scope*

acess_tokentoken_typeexpires_in*scope*state*refresh_token*

Page 59: Security Avalanche

Extension Grant Flow

• Client requests access token by presenting a token and specifying its kind– I.e., OAuth-SAML2 specification

Page 60: Security Avalanche

Client Registration

• Establishing trust with Authorization Server– Provide a client type– Provide a Url– Provide other optional information

• Required for public and for implicit grants

Client Profile Client Type

Web Application Confidential

User-Agent Based Public

Native Application Public

Page 61: Security Avalanche

Client Authentication

• Clients may register a password (secret) with the Authorization Server

• Pass with Basic Authentication • If not supported, pass as form parameters

Page 62: Security Avalanche

Client Authentication

• Basic Authentication (recommended)

• ParametersPOST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

POST /token HTTP/1.1 Host: server.example.comAuthorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Page 63: Security Avalanche

Access Token

• Represents authorization to resources• May be signed• Format described by accompanying

specifications– I.e., SAML2, JWT

Page 64: Security Avalanche

Access Token Response

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example",

"expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

Page 65: Security Avalanche

Refresh Token

• Optional, Authorization Server decides• Sent to Authorization Server to retrieve another

access token– Different scope– Additional time

• If access token is expired, can use refresh token to request another one– Without prompting Resource Owner– Unless scope increases beyond what was approved

Page 66: Security Avalanche

Facebook Examples

Page 67: Security Avalanche

Authorization Request

GET https://www.facebook.com/dialog/oauth?client_id=438893679548466&redirect_uri=http%3A%2F%2Fdemo.snapboard.com%2FSnapBoardDemo%2FAccount%2FExternalLoginCallback%3F__provider__%3Dfacebook%26__sid__%3D9fbc4fb2ac434930a78e50c895271a0f&scope=email%20user_about_me%20user_birthday%20user_friends%20publish_actions HTTP/1.1

Page 68: Security Avalanche

Response w/ Grant

GET http://demo.snapboard.com/SnapBoardDemo/Account/ExternalLoginCallback?__provider__=facebook&__sid__=9fbc4fb2ac434930a78e50c895271a0f&code=AQCxVpduOEybUZVpB74wFCzZZVCPgBfpnBj7tvxSDVGag9u9zV9yX268Wf0eB1rb6nZYmoFRlweasCIKksFQkwzEzE0aWYuzstA_ciHbhJSTmMb0ZsrlZ9jjXLMHrdirigIOz13WC8nW-gbXQzuwG1DmmJFEv2KtupZl8KMAIZBSVsu9aewPT5R2lNgSgfg_SW53Qt2qliVP32NEu-q0BiuvdphDDSjwWCjSHtW4SMC73DdL9O7Bjt2vz-lumDq9b5asuuxFvx_KQknhFRhAX15W-8CYBOEWZ0vVYsFjI5tCSMEAYZ6EAm62HEbNZTj9aJw HTTP/1.1

Page 69: Security Avalanche

Request Access Token

GET https://graph.facebook.com/oauth/access_token?client_id=438893679548466&redirect_uri=http%3A%2F%2Fdemo.snapboard.com%2FSnapBoardDemo%2FAccount%2FExternalLoginCallback%3F__provider__%3Dfacebook%26__sid__%3D9fbc4fb2ac434930a78e50c895271a0f&client_secret=8022ba46243c1becc5e4020f72f08bd7&code=AQCxVpduOEybUZVpB74wFCzZZVCPgBfpnBj7tvxSDVGag9u9zV9yX268Wf0eB1rb6nZYmoFRlweasCIKksFQkwzEzE0aWYuzstA_ciHbhJSTmMb0ZsrlZ9jjXLMHrdirigIOz13WC8nW-gbXQzuwG1DmmJFEv2KtupZl8KMAIZBSVsu9aewPT5R2lNgSgfg_SW53Qt2qliVP32NEu-q0BiuvdphDDSjwWCjSHtW4SMC73DdL9O7Bjt2vz-lumDq9b5asuuxFvx_KQknhFRhAX15W-8CYBOEWZ0vVYsFjI5tCSMEAYZ6EAm62HEbNZTj9aJw&scope=email HTTP/1.1

Page 70: Security Avalanche

Access Token ResponseHTTP/1.1 200 OKAccess-Control-Allow-Origin: *Cache-Control: private, no-cache, no-store, must-revalidateContent-Type: text/plain; charset=UTF-8Expires: Sat, 01 Jan 2000 00:00:00 GMTPragma: no-cacheX-FB-Rev: 997953X-FB-Debug: b8sYgk6apQZlsdJEXdTuEN+gisLdVvOQ15CK8o3cLSA=Date: Thu, 07 Nov 2013 11:47:59 GMTConnection: keep-aliveContent-Length: 215

access_token=CAAGPKZBXdGDIBAImEo6Pf6GthtiEdjQoAGWUBiNSwUeTuZAbztASscJKpNZCsuKUSBDQqwJ9ZAPUF7tugWkgbaUqh8vQkHwZCsARz7rEu0j8EfDA0tZA8CIW2ZAbSQh4fNDTNpUm0B4zZAxqycQsYjLhY8BarPp9izFZBUVeAsYQCfoVBqK4WwSxq

Page 71: Security Avalanche

Request Profile Info

GET https://graph.facebook.com/me?access_token=CAAGPKZBXdGDIBAImEo6Pf6GthtiEdjQoAGWUBiNSwUeTuZAbztASscJKpNZCsuKUSBDQqwJ9ZAPUF7tugWkgbaUqh8vQkHwZCsARz7rEu0j8EfDA0tZA8CIW2ZAbSQh4fNDTNpUm0B4zZAxqycQsYjLhY8BarPp9izFZBUVeAsYQCfoVBqK4WwSxq HTTP/1.1Host: graph.facebook.com

Page 72: Security Avalanche

Profile Response

HTTP/1.1 200 OK…Content-Length: 609

{"id":"574847493","name":"Michele Leroux Bustamante","first_name":"Michele","middle_name":"Leroux","last_name":"Bustamante","link":"https:\/\/www.facebook.com\/michelebusta","username":"michelebusta","birthday":”LA LA LA LA","bio":"I'm a geek. Wait, no I'm not. Wait, yes I am...","quotes":"Never complain, never explain. -Katherine Hepburn”,"gender":"female","email":"michelebusta\u0040gmail.com","timezone":1,"locale":"en_US","verified":true,"updated_time":"2013-11-07T11:44:01+0000"}

Page 73: Security Avalanche

Invalid Access Token

GET https://graph.facebook.com/574847493/friends?access_token=CAAGPKZBXdGDIBAGtzITGJq3ykpbuSDF6xQlDxonZCGW15CKCgq4fmfKH5QK7pYq374C9uWcZAZBnJrqZAEpx4gp73U9bGNmJlb0dvby3LkvuVrzGZCxBvZCbWrXWyHuouAil15sm76Q5g4uQ5myiCFRaRaMEOHXLNPCTClK2IApKEkB7A51qe7F&limit=5000&fields=%5B%22id%22%2C%22name%22%2C%22link%22%5D HTTP/1.1

HTTP/1.1 400 Bad Request…WWW-Authenticate: OAuth "Facebook Platform" "invalid_token" "Error validating access token: User 574847493 has not authorized application 438893679548466."…Content-Length: 172

{"error":{"message":"Error validating access token: User 574847493 has not authorized application 438893679548466.","type":"OAuthException","code":190,"error_subcode":458}}

Page 74: Security Avalanche
Page 75: Security Avalanche

And now, for a creepy image of the

original OpenID

Page 76: Security Avalanche

http://openidexplained.com/

Page 77: Security Avalanche

OpenID Connect vs. OAuth 2

Page 78: Security Avalanche

OpenID ID Token ResponseHTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiJ9.ew0KICAgICJpc3MiOiAiaHR0cDovL 3NlcnZlci5leGFtcGxlLmNvbSIsDQogICAgInVzZXJfaWQiOiAiMjQ4Mjg5NzYxM DAxIiwNCiAgICAiYXVkIjogInM2QmhkUmtxdDMiLA0KICAgICJub25jZSI6ICJuL TBTNl9XekEyTWoiLA0KICAgICJleHAiOiAxMzExMjgxOTcwLA0KICAgICJpYXQiO iAxMzExMjgwOTcwDQp9.lsQI_KNHpl58YY24G9tUHXr3Yp7OKYnEaVpRL0KI4szT D6GXpZcgxIpkOCcajyDiIv62R9rBWASV191Akk1BM36gUMm8H5s8xyxNdRfBViCa xTqHA7X_vV3U-tSWl6McR5qaSJaNQBpg1oGPjZdPG7zWCG-yEJC4-Fbx2FPOS7-h 5V0k33O5Okd-OoDUKoFPMd6ur5cIwsNyBazcsHdFHqWlCby5nl_HZdW-PHq0gjzy JydB5eYIvOfOHYBRVML9fKwdOLM2xVxJsPwvy3BqlVKc593p2WwItIg52ILWrc6A tqkqHxKsAXLVyAoVInYkl_NDBkCqYe2KgNJFzfEC8g" }

Page 79: Security Avalanche

ID Token

{ "iss": "https://server.example.com", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "auth_time": 1311280969, "acr": "urn:mace:incommon:iap:silver", "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng" }

Page 80: Security Avalanche

Where are we now?

WS-Federation + SAML 1.1/2WS-Trust + SAML 1.1/2

SAML 2

OAuth2 + JWT

OpenID Connect

Page 81: Security Avalanche

Suggested Implementations

• Thinktecture– Authorization Server and Identity Provider– All but SAML 2– Open Source

• Auth0– Hosted model or appliance– Affordable, from small bus to enterprise– All protocols– FREE version for dev

Page 82: Security Avalanche

References

• Conference resources to be referenced here: – http://michelebusta.com

• See my snapboards:– Currently at the alpha site:

http://snapboardalpha.cloudapp.net/michelebusta– Will move these to snapboard.com/michelebusta when we

go live on the main site (SOON watch my blog for announcement)

• Contact me:– [email protected]– @michelebusta

Page 83: Security Avalanche

Michele Leroux BustamanteManaging Partner

Solliance (solliance.net) CEO and Cofounder

Snapboard (snapboard.com)

Microsoft Regional Director Microsoft MVP

Author, SpeakerPluralsight courses on the way!Blog: [email protected]@michelebusta