federal cloud security wp

8/4/2019 Federal Cloud Security WP

1/12

Federal Cloud Security Challenges and SolutionsWhats Happening, Whos Driving, and What to Do About It

Abstract

This paper is designed to define the landscape of federal

cloud security initiatives, distill relevant standards and security

design patterns, and map these to commercial technologies in themarket today. Our goal is to equip government security practitioners

with actionable knowledge and solutions to accelerate their adoption of the Federal

cloud. Intel and McAfee contracted this paper to be written by Gunnar Peterson - anindependent security consultant with significant field experience in the federal sector.

WHITE PAPER

Paper Focus:

Describes the latest Federal Cloudsecurity initiatives

Distills the latest relevant

federal standards and security

design patterns

Arms practitioners with solutions

to accelerate adoption of the

Federal Cloud

Author

Gunnar Peterson

Federal Security Expert

Managing Principal at Arctec Group


2/12

Federal Cloud Security Challenges and SolutionsWhats Happening, Whos Driving, and What to Do About It

Abstract ....................................................................................................................................................1

Cloud Security Trends, Initiatives and Standards ..........................................................3

Addressing Federal Identity Credential & Access Management .........................4

Federal ICAM solution guidance .......................................................................................5

Addressing FedRAMP for Cloud applications ...................................................................7

FedRAMP solution guidance...............................................................................................7

Addressing HSPD-12 for Cloud applications .....................................................................8

HSPD-12 solution guidance .................................................................................................8

Addressing NSTIC for Cloud applications ............................................................................9

NSTIC solution guidance........................................................................................................10

Conclusion ................................................................................................................................................10

Federal Reference Guide ...............................................................................................................11

More Information ................................................................................................................................12

Reading Tip: For upfront background on each federal initiativementioned in this paper, scan the table listed at the bottom of

this document.

Give us the tools and we will finish the job Winston Churchill, 1941

2


3/12

Whats Happening - Cloud Security Trends, Initiatives and Standard

The username and password

combination is outdated. We need

to create a more secure online

environment.

Commerce Secretary Gary Locke

Cloud applications offer many features,

but for Federal systems, security is not

an optional feature. Federal standardsand initiatives like NSTIC, Federal ICAM,

FedRAMP, and HSPD-12 are unambiguous

statements of the importance of creatingsecurity baselines that enable safety for

users and online transactions. Amidst

increasing cybersecurity threats, Federalstandards and initiatives clearly indicate a

recognition of this new environment:

Federal ICAM Roadmap Goal: Increasedsecurity, decreased identity theft, data

breaches, and trust violations

NSTIC Why We Need It:

- 1. Passwords are inconvenient

and insecure

- 2. Individuals are unable to provetheir true identity online for

significant transactions

FedRAMP: The decision to embrace

cloud computing technology is a risk-

based decision, not a technology-based

decision.

HSPD-12 Requirement: Secure and

reliable forms of identification. NISTGuidelines on Security in Cloud

Computing: Critical pieces of technology,

such as a solution for federated trust,are not yet fully realized, impinging on

successful cloud computing deployments.

The themes that each of these havein common is a recognition of rising

cybersecurity threats and acceptance that

the security baseline must be raised tocounter these threats.

The Federal government has produced

a number of timely publications andstandards that offer guidance for building

a strong cybersecurity posture to handle

the changes the Cloud brings. Takentogether, this work represents a shift in

how the Federal government engages

with technology and its consumers. What

they all have in common is a recognitionof the current trends, and the types of

security technology required stronger

identity, identity federation, usecase centric architecture, continuous

monitoring, and the importance of

information security.

These new standards and initiatives

arrive at a critical time in the technology

industrys history - targeted attacks areon the rise:

2007 Estonia DDoS brute force attack

2009 attacks against Google in China more sophisticated & targeted attack

2010 Stuxnet attackers understoodtarget in great detail, had zero-day

vulnerabilities and ability to replicate

These trends show increasing technicalsophistication on the attacker side,

more focused attacks and determined

opponents,that target strategic assets.A key distinction with current attacks

such as Advanced Persistent Threats

(APTs) is a focus on intelligence gathering.Access control technology remains anecessary but still insufficient technology

to withstand these threats, because

intelligence gathering can discover weakpoints in deployments.

Whats important today is the[development of standards] in the

area of security, interoperability

and data portability to ensure

information is protected; cloudsand the computer applications they

support can work together; and

content can be moved within andamong different clouds without

jeopardizing access to or integrity

of the data.

Vivek KundraFormer Federal CIO

Real world implementations demandpractical security solutions. Security

Gateways for Web access, Web services

and Mobile applications have emergedas crucial building blocks for deploying,

enforcing, and managing security policies

and protocols.

This whitepaper examines the unique

challenges associated with addressing the

new Federal standards and initiatives, andoffers solution guidance for meeting the

standards for Cloud applications.

3


4/12

The Challenge

The Federal ICAM Roadmap lays out a

comprehensive vision for the full lifecycle

of Digital Identity including: Credentialing,Privilege Management, Authentication,

Authorization & Access, Cryptography,

and Auditing & Reporting services.This strategic vision is accompanied by

specific criteria and measurable targets.

The architecture enables trust andinteroperability for digital transactions for

broad use by constituents in the Federal

government, other governments, external

organizations, and citizens.

The Federal ICAM architecture maps

the level of assurance required by thetransaction to an appropriate credential

type. This approach scales well in

real world deployments because thesensitivity and risk of the transaction

drives what credential is required,

keeping costs and deployment time in

line. To enable multiple credential types(such as PIV, SAML, and PKI) across the

array of services specified in the Federal

ICAM roadmap means that Credentialing,Privilege Management, Authentication,

Authorization & Access, Cryptography,

and Auditing & Reporting services

must interoperate. Moreover, standardsand security services must deliver a

straightforward user experience and an

appropriate level of assurance.

Figure 1: Federal ICAM lays out a comprehensive vision

Addressing Federal Identity Credential & Access Management (ICAM)Roadmap for Cloud Applications

Enable Trust andInteroperability

CredentialTypes

Persons,

Non-Persons

LogicalAccess,

PhysicalAccess

4

LevelsofIdentity

Assurance

(No

confidence

through

fullconfidence)

Taxpayers Grant Recipients Medical/Medicaid

Beneficiares

Industry Financial Institutions Healthcare Providers

State Local Tribal Allied Partners

Intra-Agency

Inter-Agency

Internal tothe Federal

Community (IEE) PIV Credentials

PIV -InteroperableCredentials

Open Solutions- OpenID- iCard- SAML

- WSFed- Etc.

With OtherGovernments

(G2G)

With ExternalOrganizations

(G2B)

With theAmerican People

(G2B)

4


5/12

The Federal ICAM Roadmap describes thekey use cases its designed to support.

The use cases describe the functional

requirements necessary to completethe task, but in addition, there are non-functional security requirements that are

important to delivering on the promise of

interoperable digital identity.

The Federal ICAM Roadmap describes the

following high level use cases:

Establish a trusted digital representation

of an individuals identity

Provide credentials tied to an individualsidentity for use in applications

Bind digital identity data, credentials and

privileges to user accounts for use inapplications

Use credentials in physical and logical

access applications to gain access toresources

Use credentials for other applications(e.g. securing information)

Each of these use cases can then bebroken down based on the interaction

type (G2C, G2G, G2B). To realize the

security and assurance requirements foreach use case, the non-functional security

requirements may include:

Detailed Audit logging required fortracking user lifecycle management

Cryptographic support for sensitive

information process and stored

Access control authentication and

authorization

Single Sign On simplify user experience

Attribute exchange exchangingverifiable attributes

Federation exchanging identity

information across technical and

organization domains

Solution Guidance

The Policy Enforcement Point (PEP)

has emerged as the standard way to

deploy security services such as accesscontrol. The Federal ICAM Roadmap

summarizes the Policy EnforcementPoints job: Restrict access to specific

systems or content in accordance with

policy decisions that are made. Use cases

provide the usage context, and securityservices provide the access control based

on the context described in those

use cases.

Figure 2: Security Policy Enforcement Point provides a location to manage and make access control decisions

Citizen

InteractionTypes

Government

Business

Security PolicyEnforcement Point

Mobile,Web Browser,Web Services

Government

5


6/12

technologies almost always naively

trust anything that starts with http://.Attackers exploit this trust with

malicious payloads infecting iFramesand other targets invisible to users. WebSecurity Gateways prevent threats via

restricting inbound and outbound access,

and blocking malicious content, sites

and URLs.

Mobile Access: Mobile applications use

different protocols and formats foridentity and access control and require

Gateways to provide an abstraction layer

to interoperate with these standards.

Email traffic: Email is host to a wide

variety of malicious content, spyware,

malware, and zero day threats. EmailSecurity Gateways rapidly analyze the

Email message traffic and sort the

malicious email from business critical.

The Gateways role as a Policy

Enforcement Point is to enforce the

security standards and goals involved

with the use case along with the realitiesof the user and deployment environment.

Deployment realities dictate that system

administrators benefit from centralizingsecurity policy enforcement and

management. These management and

administration requirements do not show

up in typical user-facing use cases, but

streamlining where and how the systemshould be managed is often a make

or break proposition for the systemsreliability and performance.

The security policy describes allowable

and non-allowable system usage. To

make a security policy actionable in a realworld system, Security Gateways enable

organizations to apply security policies

to key security boundaries, manage thelifecycle and versioning, and enforce the

security policy at runtime.

Security Policy is critical, but sophisticatedattacks like Advanced Persistent Threats

(APT) dont break standards and policies

they break implementations exploitingthe gap between the policy intent and

the real world deployment. As identity

standards evolve, there are real benefits

to organizations moving to SAML andother identity standards. No technology

is a silver bullet, though. Determined

attackers such as APTs may findimplementation flaws in deployment that

they can exploit. This fact puts a premium

on focusing attention on monitoring, data

loss prevention and malware scanning.These processes and technologies give

the organization the ability to identify andrespond to attacks that deliberately hide

in the system.

Figure 3: Security Policy Lifecycle

1 Guide to Secure Web Services, NIST http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf2 http://www.idmanagement.gov/documents/FICAM_Roadmap_Implementation_Guidance.pdf

Registry/Repository

CreateSecurity Policy

ManageSecurity Policy

Gateway Runtime

EnforceSecurity Policy

Gateway orRegistry/Repository

Define security policyfor subjects, objects,message exchanges

Define identityproviders, relying parties

Define authorized usage

Versioning

Change management

Monitoring policy points& enforcement points& policy decision points

Make runtime accesscontrol decisions

Enforce integrity &encryption policies

Implement logging &monitoring sensors

The Policy Enforcement Point is critical to

Cloud architecture. Because of the widevariety of different technologies involved

in Cloud applications (Web user access,Web services and Mobile access), thePolicy Enforcement Point forms a strong

boundary separating the Cloud Consumer

and the Cloud Provider.

The Policy Enforcement Point role is to

act as a Gateway for the deployment

environment, defining the integrationboundary between the Cloud Consumer

and the Cloud Provider and delivering

security services:

Web User Access: Federation Gateways

deliver Cloud Single sign on, web account

provisioning, and strong second factorauthentication tied to the SSO event.

Web Services: Web service Security

Gateways enable security servicesfor Cloud and other Web services

based applications including integrity,

authentication, authorization, Web

services security standards1, threatprotection, and API level security be it

SOAP or REST.

Web Traffic: Security pros know Webtraffic is inherently untrusted, but

browsers, email clients and other web

6


7/12

Identity and Access services often

manifest as security building blocks forproviding access control to achieve a

desired security target profile such asLevel of Assurance standards documentedin NIST SP 800-633 that dictate increasing

strength to achieve certain targets. The

Levels of Assurance standard is quite

powerful as demonstrated by its broaduse in other identity work such as Federal

ICAM and OIX Trust Frameworks4. The

assurance extends to the token, identityproofing and provisioning, authentication

and assertion mechanisms. As a

framework it can be extended to specificinterpretation based on usage context

for example:

Level of Assurance 2 requires SAMLprotocol and Audit logging

Level of Assurance 3 Two factor

authentication

Level of Assurance 4 requires SAML

with Holder of Key5

Interoperability standards such as

REST, SOAP, SSL, X.509, SAML and

others are also required so that the use

cases and the security services workin implementations where integration

is required whether they are Web, Web

services or Mobile deployments. Standardsenable scale. Interoperability standards

like SAML for Federated Identity and

FIPS 140-2 for cryptography enable theactors and system interfaces in the Cloud

applications to work together in large

scale deployments.

Federated Identity standards and other

technologies that enable Single Sign On

(SSO) and secure attribute exchangehave emerged as crucial building blocks

for Cloud applications. For Web user

access scenarios, Single Sign On is ahighly desirable usability feature, and

the challenge is to provide secure tokens,

session management and policy to govern

these SSO scenarios.

The Challenge

The FedRAMP process is a risk based

framework, which begins with an

assessment of the type of Cloudapplication (IaaS, PaaS, and SaaS), and

then establishes a control baseline

with specific security guidance andrequirements for that Cloud application.

For Government organizations subject

to FedRAMP looking to use Cloudapplications, meeting the FedRAMP

control baseline is an important task.

The controls cover a broad set of

seventeen different types of securityarchitecture concerns from Access Control

and Authentication to Configurationmanagement and Risk Assessment.

Many standards focus primarily on Identity

and Access standards to achieve strong

access control. Access control standardsare mainly geared to provision and provide

access to authorized users, not protect

against actively malicious actors. Due tothe increased Attack Surface that Cloud

Applications brings, Access Control is

necessary but not sufficient for security.FedRAMP addresses this gap with a

requirement for a ContinuousMonitoring program6:

The objective of the continuous

monitoring program is to determine if

the set of deployed security controlscontinue to be effective over time in

light of the inevitable changes that

occur. Continuous monitoring is a proven

technique to address the security impactson an information system resulting from

changes to the hardware, software,

firmware, or operational environment

FedRAMPs required Risk Assessmentsand Audit activities drive a risk focused

approach for Cloud adoption. Theseactivities enable the risk profile to drive

the security architecture capabilities

required for moving to the Cloud based onthe type of Cloud system. The implication

is that while there is no single set of

controls that makes a system Secure forthe Cloud, the FedRAMP approach is to

right-size security based on risk.

Solution Guidance

Continuous monitoring gives the security

architecture improved capabilities and

visibility into the runtime operations.Since the threat landscape is not static,

the security architecture should be able to

identify and report on threat activity asit evolves.

Because many different identity

standards are supported, Gateways area convenient location to deploy strong

identity and access services. Since they

are located on inbound and outboundperimeters, Gateways are useful points to

monitor access.

Advanced Persistent Threat (APT) clearlydemonstrates that attackers capabilities

have grown and exceeded traditional

Information security defenses. Forsystems that are APT targets, security

architects must factor in protection

and detection requirements, to BuildVisibility In. Defending against APT means

defending against adaptable, intelligent,

and determined opponents. The security

mechanisms that security architectsrely on, such as access control, may be

bypassed or in fact be the targets ofAPT. The net result is that even strongaccess control is vulnerable to APT and

dealing with this reality entails building

visibility into system usage, events andtransactions through robust Monitoring

services, Data Loss Prevention, and

Threat Prevention technologies.

Monitoring services must be deployed to

provide visibility into the areas of greatest

threat entry and egress points likeemail, and Web access are key important

structural boundaries to detect maliceand provide the organization information

it needs to respond to security events.Combating threats like APT requires a

cohesive end to end strategy placing

security tools and sensors in the properlocation for best protection and detection.

3 http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf4 http://openidentityexchange.org/working-groups/us-icam5 At LOA 4, bearer assertions SHALL NOT be used solely to authenticate the end user to the RP. However, holder-of-key assertions made by the IdP MAY be used to bind keys or otherattributes to an identity. Holder-of-key assertions may be used at LOA 4 provided that the following requirements are met Federal Identity, Credential, and Access Management, SAML 2.0Web Browser Single Sign-on Profile http://www.idmanagement.gov/documents/SAML20_Web_SSO_ Profile.pdf6 https://info.apps.gov/sites/default/files/Chapter-2-Continuous-Monitoring.pdf

Addressing FedRAMP for Cloud ApplicationsStandards in Practice

7


8/12

The Challenge

Identity and access management are

disparate technologies -- that yet, must

work together. Access decisions cannever be stronger than the quality of

the identity provisioning. This puts a

premium on identifying and integratingstrong provisioning and an identity

proofing process. In the case of HSPD-127

theres demonstrable value through the

credentialing process of this effort:

HSPD-12 credentials Issued as ofMarch 1, 2011:

Credentials issued to Employees:

3,973,061 (85%)

Credentials issued to Contractors:839,675 (79%)

(Total credentials issued: 4,812,736

(84%))

Background investigations verified/

completed as of March 1, 2011:

Background investigations completed for

employees: 4,128,544 (88%)

Background investigations completed forcontractors: 904,083 (85%)

(Total investigations verified/completed:

5,032,627 (87%))

18 federal credential issuance

infrastructures are in operationnationwide

59 system integrators and 576 products

on GSA Approved Products and ServicesList

The metrics above show the breadth

and depth of the HSPD-12 credentialing

process. These statistics lend furthercredence to the notion that integration

for the authoritative source of identity isa critical integration task.

The act of writing user account data

to a directory is the first step, but theIdentity Providers value is realized by

the amount of integration to identity

consumers, Relying Parties and ServiceProviders. The challenge is to unlock

the value in the HSPD-12 Credentialing

process and broaden the availability ofverified identity information available for

use in Cloud applications. The organizationleverages strong identity provisioning

processes, like HSPD-12 credentialing,via integrating that identity data to

more identity consumers like Cloud

applications and Web services.

Solution Guidance

Federated Identity guidelines, such asNSTIC and Federal ICAM Roadmap, use

standards like SAML 2.0 to make identity

information more portable. To make

Federated Identity work in the real world,integration is required. Integration on the

Cloud Consumer Identity Provider side

requires that adapters must be configuredand implemented for the user experience

(such as a browser) and connect to the

user account store (such as a directory)so that these are seamlessly connected

to the Identity Provider and the user does

not see any visible signs ofprotocol plumbing.

On the Relying Party Cloud Provider side,

the last mile integration work deals withimplementing a Policy Enforcement Point

to validate the identity assertion and

launch the users session on the CloudProvider in a policy-based way.

SAML 2.0 is a key enabling technology

standard for Identity Records andProvisioning. Widely adopted standards

like SAML are critical to realizing the vision

of communicating identity informationin G2C, G2G, and G2B interactions.

Implementing SAML 2.0 to meet Federal

ICAM Roadmap use cases can extend the

reach of HSPD-12 provisioning.

In Web access use cases, Federated

Identity standards like SAML are widely

used for Single Sign On, but for Webservices based systems SAML is often

used for backend attribute retrieval. For

linking systems together and exchangingverifiable attributes from authoritative

sources. Backend Attribute Exchange

standards have been created.

Addressing HSPD-12 for Cloud Applications

7 http://www.idmanagement.gov/presentations/HSPD12_Current_Status.pdf

Effective beginning FY2012,

agencies must be fully FIPS 201 PIV-

enabled and be able to accept andelectronically verify PIV credentials

issued by other federal agencies.

Security is only as good as its weakestlink, the attacker may seek to circumvent

a well protected server with spearphishing

attacks that target the administrators ofthat system. The email and web channels

remain a favorite channel for attackers to

deliver malicious content. As their attacksevolve, Web Gateways, Threat monitoring

for Malware and Spyware are critical

to adapt to these new techniques. Foraccountability, attribution and response,

DLP and Threat monitoring services

should monitor egress points to ensure a

holistic approach.

To manage risks to the systems attack

surface, FedRAMP defines clear targets

for Continuous Monitoring:

Configuration management and control

processes for information systems;

Security impact analyses on proposed or

actual changes to information systems

and environments of operation;

Assessment of selected security controls

(including system-specific, hybrid, and

common controls) based on the definedcontinuous monitoring strategy;

Security status reporting to appropriate

officials; and

Active involvement by authorizing

officials in the ongoing management ofinformation system-related

security risks.

These Monitoring service requirementsdiffer in goals from authentication and

authorization and Continuous Monitoring

offers an important backstop to identity

and access services. FedRAMPs riskassessment and security capabilities cover

a broad range of security technologies

and processes, pushing organizations tothink about security in holistic terms.

8


9/12

The separation of attribute retrieval

services offers many architecturalbenefits: Systems are not hard wired

together, and loose coupling can promotea separation of concerns so that each

system can focus on what it does best.

The roles and responsibilities in Federated

Identity drive a division of labor betweenthe Identity Provider who asserts the

identity and the Relying Party who

consumes the identity assertion. This

division of labor enables specializationwhere the Identity Provider can focus

on provisioning and user account

The Challenge

Passwords just wont cut it here.

We must do more to help consumers

protect themselves, and we must make

it more convenient than remembering

dozens of passwords.

-Commerce Secretary Gary Locke

on NSTIC

Historically, one of the primary security

mechanisms has been the username/

password combination, but this is now

management, while the Relying Party can

optimize applications, resources and datathat users would like to access.

The roles are generally split as a Cloud

Consumer (such as a government agency)that plays the role of an Identity Provider

while the Cloud Provider (external Cloud

or Internal Cloud) acts as the RelyingParty. Since the Cloud Consumer is likely

to want to use the identity information

for multiple applications and the Relying

Party is likely to want to serve multiplecustomers, the role of standards like SAML

is essential.

proving to not be up to the task. NSTIC8

recognizes the limitations of passwords

both from a security (ineffective toprovide identity online) and usability

(inconvenient) point of view. NSTICaddresses real world problems . In 2010,

for example, 8.1 million U.S. adults were

the victims of identity theft or fraud, withtotal costs of $37 billion.

Current password based schemes leave

a user with a cumbersome password(s)system that offers very little security;

and this system offers identity consumers

(Governments, businesses) typically with a

low level of assurance at great cost.

By contrast, NSTIC is focused on

formalizing solutions that offer realworld improvements. The Department

of Defense found that strong access

credentials resulted in a 46% reduction

in intrusions. Delivering securityimprovements that result in that sort

of impact requires understanding the

deployment landscape its lifecyclemanagement, capabilities, and constraints.

Addressing NSTIC for Cloud Applications

The Department of Defense

found that strong access

credentials resulted in a 46%reduction in intrusions.

8 The National Strategy for Trusted Identities in Cyberspace: Why We Need It, http://www.nist.gov/nstic/NSTIC-Why-We-Need-It.pdf

#1 Access Request #2 Retrieve Attributes from Issuing Authority

#3 Authorization Access

Federal Identity BrokerApps (LACS)

Facility (PACS)

PIV Card

Use Models

Inter-agency Visits

Cardholder Emergency

Special Access Requirements

Suspected Tampering

Figure 4: A broker can accelerate HSPD-12 compliance for cross-agency attribute sharing.

9


10/12

Solution Guidance

By making online transactions more

trustworthy and better protecting

privacy, we will prevent costly crime, wewill give businesses and consumers newconfidence, and we will foster growth

and untold innovation. Thats why this

initiative is so important for oureconomy, President Barack Obama

speaking on NSTIC.

As experience makes clear, security isvery context-driven. Levels of Assurance

provide an example of how to define

security requirements based on riskand sensitivity. Trust Frameworks have

emerged as a second level of this line of

thinking to show not just the securityrequirements but a governance model

defining the roles and responsibilities

of different, independent, co-operative

actors in an identity system. NSTIC9defines Trust Frameworks:

A trust framework is developed by

a community whose members havesimilar goals and perspectives. It defines

the rights and responsibilities of that

communitys participants in the IdentityEcosystem; specifies the policies and

standards specific to the community, and

defines the community-specific processesand procedures that provide assurance. A

trust framework considers the level of risk

associated with the transaction types ofits participants. For example, for regulated

industries, it could incorporate the

requirements particular to that industry.

Different trust frameworks can existwithin the Identity Ecosystem, and sets of

participants can tailor trust frameworks to

meet their particular needs. In order to be

a part of the Identity Ecosystem, all trustframeworks must still meet the baseline

standards established by the IdentityEcosystem Framework.

Currently there several different Trust

Framework Providers designed to meet

different Levels of Assurance. Open Identity Exchange (LOA 1)

Kantara Initiative (LOA 1, 2,

non-crypto 3)

InCommon Federation (LOA 1 and 2)

This approach represents a leap forward

towards stronger identity systems

through Levels of Assurance, and moreadaptable identity systems through clear

governance of identity infrastructure as a

whole. The old username/password point

to point protocol is not well suited to theintegration reality of today.

Private Sector Trust Framework Providerslike PayPal and Google can be used to

provide access to government Cloud

applications based on the LOA support.This streamlines provisioning, drives down

cost and opens up access to larger user

communities that have seamless accessto Federal information. Certain Federal

agencies then do not have to manage user

information. Trust Frameworks make the

standards and guidance actionable anddefine a role for both Government and

Private sector innovation.

Conclusion

Threats to our national intellectual

property, data and identity information

are not standing still; and Federalstandards and initiatives like NSTIC,Federal ICAM, FedRAMP, and HSPD-12

show that the Federal Government is

actively engaged in addressing theserisks. Standards and initiatives such

as the ones mentioned in this paper go

about improving security and identityarchitecture in different ways, but what

they all have in common is a recognition of

the need to evolve and improve security

architectures to meet the challenge ofemerging threats.

Cloud applications add another dimensionto the Security Architects problem set,

but, when executed properly, Cloud

applications offer new solutions too. The

Federal Government plays a vital role inbacking security standards, and these

standards in turn offer improvements to

the Cloud Providers security posture. Thesecurity posture must focus on security

and identity standards must be deployed

in combination with threat protection tocope with skilled, adaptable adversaries.

Security architects must understand the

implications of both the Federal standardsand initiatives as well as the benefits

and limitations of implementing security

in the Cloud. The Federal governmentsstandards and initiatives give Security

architects a broad and deep set of tools,

proven in real world deployments, to

realize concrete improvements in theirCloud applications today.

9 The National Strategy for Trusted Identities in Cyberspace10


11/12

FEDERAL CLOUD SECURITY

INITIATIVE OR PROGRAM INITIATIVE DESCRIPTION

APPLICABLE INTEL/

MCAFEE SOLUTION HOW SOLUTION ADDRESSES

Identity Credential &Access Management (ICAM),Backend Attribute Exchange(BAE), HSPD-12 compliance,National Strategy for TrustedIdentities in Cyberspace(NSTIC), Personal IdentityVerification (PIV)

Identity and AccessManagement

(Fed SSO)

Intel Expressway CloudAccess 360

McAfee Cloud IdentityManager

(Web Services Security)

Intel Expressway ServiceGateway

McAfee Service Gateway

Enabling Federated access, CloudSSO (SAML, OAuth, Open ID), AccountProvisioning, Strong Auth SoftwareOne Time Passwords

Authenticating Web Services, SOAP,REST, Expose secure APIs

National InformationExchange Model (NIEM)

Utilization of standardized XMLschemas to create mutuallyintelligible data sharing acrosscommunities-now being appliedto cloud



Service gateways provide a fastpath to handle the complex XMLprocessing requirements for NIEM:transformation, validation, messagefiltering, semantic mapping, messagedecoration

DoD Public KeyInfrastructure (PKI)

Data integrity, user identificationand authentication, user nonrepudiation, data confidentiality,encryption and digital signatureservices



Ability to authenticate and validatecertificates against DoD rootauthority.

NIST Guidelines on Securityand Privacy in Public CloudComputing 800-144

Threats, technology risks, andsafeguards for public cloudenvironments- arch, web servicesAuthN & AuthZ, trust, VPN,

Client, Server security



Authenticating Web Services,SOAP, REST, Expose secure APIs.Authorization via XACML

NIST- Guide to Protectingthe Confidentiality ofPersonally IdentifiableInformation (PII) SP-800 122

Protects the Confidentialityof Personally IdentifiableInformation

McAfee Data LossPrevention

McAfee Web Gateway

Protects from risks of data loss

Use layered security to enhanceprotection, Block data loss, Protectencrypted traffic

OMB Cyberscope Provide federal agenciesan automated method forsubmitting FISMA audit results.

McAfee Policy Auditor



Vulnerability ManagerCyberScope Data FeedGenerator

SCAP validated product that workswith the IPS and endpoint productsto report audit information

As a PEP, gateways intercept all webservice traffic as a proxy to internalinfrastructure and cloud- lending to acomplete audit trail.

The Vulnerability ManagerCyberScope Data Feed Generator toolhelps you to generate a data feedreport directly from VulnerabilityManager that can be submitted tothe CyberScope application.

Table 1: Federal Reference Guide

11


12/12

For more information, please visit:

www.intel.com/go/identity

www.mcafee.com/cloudsecurity

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BYTHIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND I NTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY,RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHTOR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THEINTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or unde fined. Intel reserves these forfuture definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice.Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published speci fications. Currentcharacterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copiesof documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or by visiting Intels Web siteat www.intel.com.

Copyright 2011 Intel Corporation. All rights reserved. Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other countries.

*Other names and brands may be claimed as the property of others.

Printed in USA Please Recycle 326014-001US

About the Author

Gunnar Peterson is a Managing Principalat Arctec Group. He is focused on

distributed systems security for large

mission critical Federal/Government,financial, financial exchanges, healthcare,

manufacturer, and insurance systems, as

well as emerging start ups. Mr. Petersonis an internationally recognized software

security expert, frequently published,

an Associate Editor for IEEE Security &

Privacy Journal on Building Security In, anAssociate Editor for Information Security

Bulletin, a contributor to the SEI and

DHS Build Security In portal on softwaresecurity, and an in-demand speaker at

security conferences.

He blogs at http://1raindrop.typepad.com

Intel & McAfee

As Federal fully embraces the cloud, theprimary traffic channels of email, web, and

identity authentication traffic begin to

proliferate beyond the controlled firewall,to mobile and off-premise private cloud

platforms. This traffic crosses security

layers- each requiring a unique set ofsecurity capabilities to address data

loss prevention, identity federation, and

threat prevention-all critical to federal

infrastructure sharing in the cloud.Commonly, this requires deployment of

multiple vendor products and expensive

system integrators to create a cohesive,working system. McAfee and Intel have

assembled a better approach based on

a modular cloud security platform thatdelivers on the vision of unified security

policies, reporting, DLP, threat intelligence,

and standards based identity & access

management- all cloud based, availablefrom a single trusted vendor and certified

to meet federal standards.

Americas: 978-948-2585 Email: [email protected]

ICAM is a critical piece in

protecting information and

achieving cybersecurity goals.

As a rising priority, cybersecurity

will continue to grow and changewithin the Federal Government...

Moreover, the White HouseCyberspace Policy Review states

that one of the near term actions

... [will be] to build a cybersecurity-based identity management vision

and strategy.2

federal cloud security wp

Documents