WHITE PAPER

Federal Cloud Security Challenges and Solutions

Whats Happening, Whos Driving, and What to Do About It

Paper Focus: Describes the latest Federal Cloud security initiatives Distills the latest relevant federal standards and security design patterns Arms practitioners with solutions to accelerate adoption of the Federal Cloud

Author

Abstract
This paper is designed to dene the landscape of federal cloud security initiatives, distill relevant standards and security design patterns, and map these to commercial technologies in the market 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 - an independent security consultant with signicant eld experience in the federal sector.

Gunnar Peterson
Federal Security Expert Managing Principal at Arctec Group

Federal Cloud Security Challenges and Solutions

Whats 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 initiative mentioned 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

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 The themes that each of these have in common is a recognition of rising cybersecurity threats and acceptance that the security baseline must be raised to counter these threats. The Federal government has produced a number of timely publications and standards that offer guidance for building a strong cybersecurity posture to handle the changes the Cloud brings. Taken together, this work represents a shift in how the Federal government engages with technology and its consumers. What they all have in common is a recognition of the current trends, and the types of security technology required stronger identity, identity federation, use case 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 are on the rise: 2007 Estonia DDoS brute force attack 2009 attacks against Google in China more sophisticated & targeted attack 2010 Stuxnet attackers understood target in great detail, had zero-day vulnerabilities and ability to replicate These trends show increasing technical sophistication 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 a necessary but still insufcient technology to withstand these threats, because intelligence gathering can discover weak points in deployments. Real world implementations demand practical security solutions. Security Gateways for Web access, Web services and Mobile applications have emerged as 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, and offers solution guidance for meeting the standards for Cloud applications.

Cloud applications offer many features, but for Federal systems, security is not an optional feature. Federal standards and initiatives like NSTIC, Federal ICAM, FedRAMP, and HSPD-12 are unambiguous statements of the importance of creating security baselines that enable safety for users and online transactions. Amidst increasing cybersecurity threats, Federal standards and initiatives clearly indicate a recognition of this new environment: Federal ICAM Roadmap Goal: Increased security, decreased identity theft, data breaches, and trust violations NSTIC Why We Need It: - 1. Passwords are inconvenient and insecure - 2. Individuals are unable to prove their true identity online for significant transactions FedRAMP: The decision to embrace cloud computing technology is a riskbased decision, not a technology-based decision. HSPD-12 Requirement: Secure and reliable forms of identification. NIST Guidelines 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.

Whats important today is the [development of standards] in the area of security, interoperability and data portability to ensure information is protected; clouds and the computer applications they support can work together; and content can be moved within and among different clouds without jeopardizing access to or integrity of the data. Vivek Kundra Former Federal CIO

Addressing Federal Identity Credential & Access Management (ICAM) Roadmap for Cloud Applications
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 specic criteria and measurable targets. The architecture enables trust and interoperability 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 the transaction to an appropriate credential type. This approach scales well in real world deployments because the sensitivity 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 specied in the Federal ICAM roadmap means that Credentialing, Privilege Management, Authentication, Authorization & Access, Cryptography, and Auditing & Reporting services must interoperate. Moreover, standards and security services must deliver a straightforward user experience and an appropriate level of assurance.

Figure 1: Federal ICAM lays out a comprehensive vision

Enable Trust and Interoperability

Credential Types

Internal to the Federal Community (IEE) 4 Levels of Identity Assurance (No condence through full condence)

Intra-Agency Inter-Agency

PIV Credentials

Persons, Non-Persons

With Other Governments (G2G)

State Local Tribal Allied Partners

PIV Interoperable Credentials With External Organizations (G2B)

Industry Financial Institutions Healthcare Providers

Open Solutions - OpenID - iCard - SAML - WSFed - Etc.

With the American People (G2B)

Taxpayers Grant Recipients Medical/Medicaid Beneciares

Logical Access, Physical Access

The Federal ICAM Roadmap describes the key use cases its designed to support. The use cases describe the functional requirements necessary to complete the task, but in addition, there are nonfunctional 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 individuals identity for use in applications Bind digital identity data, credentials and privileges to user accounts for use in applications Use credentials in physical and logical access applications to gain access to resources Use credentials for other applications (e.g. securing information)

Each of these use cases can then be broken down based on the interaction type (G2C, G2G, G2B). To realize the security and assurance requirements for each use case, the non-functional security requirements may include: Detailed Audit logging required for tracking user lifecycle management Cryptographic support for sensitive information process and stored Access control authentication and authorization Single Sign On simplify user experience Attribute exchange exchanging verifiable 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 access control. The Federal ICAM Roadmap summarizes the Policy Enforcement Points job: Restrict access to specic systems or content in accordance with policy decisions that are made. Use cases provide the usage context, and security services 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

Government

Mobile, Web Browser, Web Services

Security Policy Enforcement Point

Government

Interaction Types

Business

The Policy Enforcement Point is critical to Cloud architecture. Because of the wide variety of different technologies involved in Cloud applications (Web user access, Web services and Mobile access), the Policy 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, dening the integration boundary 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 factor authentication tied to the SSO event. Web Services: Web service Security Gateways enable security services for Cloud and other Web services based applications including integrity, authentication, authorization, Web services security standards1, threat protection, and API level security be it SOAP or REST. Web Traffic: Security pros know Web traffic is inherently untrusted, but browsers, email clients and other web

technologies almost always naively trust anything that starts with http://. Attackers exploit this trust with malicious payloads infecting iFrames and other targets invisible to users. Web Security 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 for identity 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. Email Security 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 realities of the user and deployment environment. Deployment realities dictate that system administrators benet from centralizing security 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 system should be managed is often a make or break proposition for the systems reliability and performance. The security policy describes allowable and non-allowable system usage. To make a security policy actionable in a real world system, Security Gateways enable organizations to apply security policies to key security boundaries, manage the lifecycle and versioning, and enforce the security policy at runtime. Security Policy is critical, but sophisticated attacks like Advanced Persistent Threats (APT) dont break standards and policies they break implementations exploiting the gap between the policy intent and the real world deployment. As identity standards evolve, there are real benets to organizations moving to SAML and other identity standards. No technology is a silver bullet, though. Determined attackers such as APTs may nd implementation aws 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 and respond to attacks that deliberately hide in the system.

Figure 3: Security Policy Lifecycle

Create Security Policy

Manage Security Policy

Enforce Security Policy

Gateway or Registry/Repository

Registry/ Repository

Gateway Runtime

Dene security policy for subjects, objects, message exchanges Dene identity providers, relying parties Dene authorized usage

Versioning Change management Monitoring policy points & enforcement points & policy decision points

Make runtime access control decisions Enforce integrity & encryption policies Implement logging & monitoring sensors

1 2

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

Standards in Practice
Identity and Access services often manifest as security building blocks for providing access control to achieve a desired security target prole such as Level of Assurance standards documented in NIST SP 800-633 that dictate increasing strength to achieve certain targets. The Levels of Assurance standard is quite powerful as demonstrated by its broad use in other identity work such as Federal ICAM and OIX Trust Frameworks4. The assurance extends to the token, identity proong and provisioning, authentication and assertion mechanisms. As a framework it can be extended to specic interpretation based on usage context for example: Level of Assurance 2 requires SAML protocol 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 work in implementations where integration is required whether they are Web, Web services or Mobile deployments. Standards enable scale. Interoperability standards like SAML for Federated Identity and FIPS 140-2 for cryptography enable the actors 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 exchange have emerged as crucial building blocks for Cloud applications. For Web user access scenarios, Single Sign On is a highly desirable usability feature, and the challenge is to provide secure tokens, session management and policy to govern these SSO scenarios.

Addressing FedRAMP for Cloud Applications

The Challenge
The FedRAMP process is a risk based framework, which begins with an assessment of the type of Cloud application (IaaS, PaaS, and SaaS), and then establishes a control baseline with specic security guidance and requirements for that Cloud application. For Government organizations subject to FedRAMP looking to use Cloud applications, meeting the FedRAMP control baseline is an important task. The controls cover a broad set of seventeen different types of security architecture concerns from Access Control and Authentication to Conguration management and Risk Assessment. Many standards focus primarily on Identity and Access standards to achieve strong access control. Access control standards are mainly geared to provision and provide access to authorized users, not protect against actively malicious actors. Due to the increased Attack Surface that Cloud Applications brings, Access Control is necessary but not sufcient for security. FedRAMP addresses this gap with a requirement for a Continuous Monitoring program6: The objective of the continuous monitoring program is to determine if the set of deployed security controls continue to be effective over time in light of the inevitable changes that occur. Continuous monitoring is a proven technique to address the security impacts on an information system resulting from changes to the hardware, software, rmware, or operational environment FedRAMPs required Risk Assessments and Audit activities drive a risk focused approach for Cloud adoption. These activities enable the risk prole to drive the security architecture capabilities required for moving to the Cloud based on the type of Cloud system. The implication is that while there is no single set of controls that makes a system Secure for the 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 as it evolves. Because many different identity standards are supported, Gateways are a convenient location to deploy strong identity and access services. Since they are located on inbound and outbound perimeters, Gateways are useful points to monitor access. Advanced Persistent Threat (APT) clearly demonstrates that attackers capabilities have grown and exceeded traditional Information security defenses. For systems that are APT targets, security architects must factor in protection and detection requirements, to Build Visibility In. Defending against APT means defending against adaptable, intelligent, and determined opponents. The security mechanisms that security architects rely on, such as access control, may be bypassed or in fact be the targets of APT. The net result is that even strong access control is vulnerable to APT and dealing with this reality entails building visibility into system usage, events and transactions 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 like email, and Web access are key important structural boundaries to detect malice and 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 proper location for best protection and detection.

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf http://openidentityexchange.org/working-groups/us-icam 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 other attributes 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.0 Web Browser Single Sign-on Prole http://www.idmanagement.gov/documents/SAML20_Web_SSO_Prole.pdf 6 https://info.apps.gov/sites/default/les/Chapter-2-Continuous-Monitoring.pdf
3 4 5

Addressing HSPD-12 for Cloud Applications

The Challenge
Effective beginning FY2012, agencies must be fully FIPS 201 PIVenabled and be able to accept and electronically verify PIV credentials issued by other federal agencies. Identity and access management are disparate technologies -- that yet, must work together. Access decisions can never be stronger than the quality of the identity provisioning. This puts a premium on identifying and integrating strong provisioning and an identity proong process. In the case of HSPD-127 theres demonstrable value through the credentialing process of this effort: HSPD-12 credentials Issued as of March 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 for contractors: 904,083 (85%) (Total investigations verified/completed: 5,032,627 (87%)) 18 federal credential issuance infrastructures are in operation nationwide 59 system integrators and 576 products on GSA Approved Products and Services List The metrics above show the breadth and depth of the HSPD-12 credentialing process. These statistics lend further credence to the notion that integration for the authoritative source of identity is a critical integration task. The act of writing user account data to a directory is the rst step, but the Identity Providers value is realized by the amount of integration to identity consumers, Relying Parties and Service Providers. The challenge is to unlock the value in the HSPD-12 Credentialing process and broaden the availability of veried identity information available for use in Cloud applications. The organization leverages strong identity provisioning processes, like HSPD-12 credentialing, via integrating that identity data to more identity consumers like Cloud applications and Web services.

Security is only as good as its weakest link, the attacker may seek to circumvent a well protected server with spearphishing attacks that target the administrators of that system. The email and web channels remain a favorite channel for attackers to deliver malicious content. As their attacks evolve, Web Gateways, Threat monitoring for Malware and Spyware are critical to adapt to these new techniques. For accountability, 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 denes 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 defined continuous monitoring strategy; Security status reporting to appropriate officials; and Active involvement by authorizing officials in the ongoing management of information system-related security risks. These Monitoring service requirements differ in goals from authentication and authorization and Continuous Monitoring offers an important backstop to identity and access services. FedRAMPs risk assessment and security capabilities cover a broad range of security technologies and processes, pushing organizations to think about security in holistic terms. 8
7

Solution Guidance
Federated Identity guidelines, such as NSTIC 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 congured and 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 of protocol plumbing. On the Relying Party Cloud Provider side, the last mile integration work deals with implementing a Policy Enforcement Point to validate the identity assertion and launch the users session on the Cloud Provider in a policy-based way. SAML 2.0 is a key enabling technology standard for Identity Records and Provisioning. Widely adopted standards like SAML are critical to realizing the vision of communicating identity information in 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 Web services based systems SAML is often used for backend attribute retrieval. For linking systems together and exchanging veriable attributes from authoritative sources. Backend Attribute Exchange standards have been created.

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

The separation of attribute retrieval services offers many architectural benets: Systems are not hard wired together, and loose coupling can promote a 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 between the Identity Provider who asserts the identity and the Relying Party who consumes the identity assertion. This division of labor enables specialization where the Identity Provider can focus on provisioning and user account

management, while the Relying Party can optimize applications, resources and data that 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 Relying Party. 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 multiple customers, the role of standards like SAML is essential.

The Department of Defense found that strong access credentials resulted in a 46% reduction in intrusions.

Figure 4: A broker can accelerate HSPD-12 compliance for cross-agency attribute sharing.
Use Models Inter-agency Visits Cardholder Emergency Special Access Requirements Suspected Tampering

#3 Authorization Access

PIV Card Apps (LACS)

Federal Identity Broker

#1 Access Request

Facility (PACS)

#2 Retrieve Attributes from Issuing Authority

Addressing NSTIC for Cloud Applications

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 proving to not be up to the task. NSTIC8 recognizes the limitations of passwords both from a security (ineffective to provide identity online) and usability (inconvenient) point of view. NSTIC addresses real world problems . In 2010, for example, 8.1 million U.S. adults were the victims of identity theft or fraud, with total 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 real world improvements. The Department of Defense found that strong access credentials resulted in a 46% reduction in intrusions. Delivering security improvements that result in that sort of impact requires understanding the deployment landscape its lifecycle management, capabilities, and constraints.

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

Solution Guidance
By making online transactions more trustworthy and better protecting privacy, we will prevent costly crime, we will give businesses and consumers new condence, and we will foster growth and untold innovation. Thats why this initiative is so important for our economy, President Barack Obama speaking on NSTIC. As experience makes clear, security is very context-driven. Levels of Assurance provide an example of how to dene security requirements based on risk and sensitivity. Trust Frameworks have emerged as a second level of this line of thinking to show not just the security requirements but a governance model dening the roles and responsibilities of different, independent, co-operative actors in an identity system. NSTIC9 denes Trust Frameworks: A trust framework is developed by a community whose members have similar goals and perspectives. It denes the rights and responsibilities of that communitys participants in the Identity Ecosystem; species the policies and standards specic to the community, and denes the community-specic processes and procedures that provide assurance. A trust framework considers the level of risk associated with the transaction types of its participants. For example, for regulated industries, it could incorporate the requirements particular to that industry. Different trust frameworks can exist within 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 trust frameworks must still meet the baseline standards established by the Identity Ecosystem 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 more adaptable identity systems through clear governance of identity infrastructure as a whole. The old username/password point to point protocol is not well suited to the integration reality of today. Private Sector Trust Framework Providers like 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 access to Federal information. Certain Federal agencies then do not have to manage user information. Trust Frameworks make the standards and guidance actionable and dene 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 Federal standards and initiatives like NSTIC, Federal ICAM, FedRAMP, and HSPD-12 show that the Federal Government is actively engaged in addressing these risks. Standards and initiatives such as the ones mentioned in this paper go about improving security and identity architecture 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 of emerging threats. Cloud applications add another dimension to the Security Architects problem set, but, when executed properly, Cloud applications offer new solutions too. The Federal Government plays a vital role in backing security standards, and these standards in turn offer improvements to the Cloud Providers security posture. The security posture must focus on security and identity standards must be deployed in combination with threat protection to cope with skilled, adaptable adversaries. Security architects must understand the implications of both the Federal standards and initiatives as well as the benets and limitations of implementing security in the Cloud. The Federal governments standards and initiatives give Security architects a broad and deep set of tools, proven in real world deployments, to realize concrete improvements in their Cloud applications today.

10

The National Strategy for Trusted Identities in Cyberspace

Table 1: Federal Reference Guide FEDERAL CLOUD SECURITY INITIATIVE OR PROGRAM APPLICABLE INTEL/ MCAFEE SOLUTION (Fed SSO) Intel Expressway Cloud Access 360 McAfee Cloud Identity Manager (Web Services Security) Intel Expressway Service Gateway McAfee Service Gateway National Information Exchange Model (NIEM) Utilization of standardized XML schemas to create mutually intelligible data sharing across communities-now being applied to cloud Data integrity, user identification and authentication, user non repudiation, data confidentiality, encryption and digital signature services Intel Expressway Service Gateway McAfee Service Gateway Service gateways provide a fast path to handle the complex XML processing requirements for NIEM: transformation, validation, message filtering, semantic mapping, message decoration Ability to authenticate and validate certificates against DoD root authority.

INITIATIVE DESCRIPTION

HOW SOLUTION ADDRESSES Enabling Federated access, Cloud SSO (SAML, OAuth, Open ID), Account Provisioning, Strong Auth Software One Time Passwords Authenticating Web Services, SOAP, REST, Expose secure APIs

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

DoD Public Key Infrastructure (PKI)

Intel Expressway Service Gateway McAfee Service Gateway

NIST Guidelines on Security and Privacy in Public Cloud Computing 800-144

Threats, technology risks, and Intel Expressway Service safeguards for public cloud Gateway environments- arch, web services McAfee Service Gateway AuthN & AuthZ, trust, VPN, Client, Server security Protects the Confidentiality of Personally Identifiable Information Provide federal agencies an automated method for submitting FISMA audit results. McAfee Data Loss Prevention McAfee Web Gateway McAfee Policy Auditor Intel Expressway Service Gateway McAfee Service Gateway Vulnerability Manager CyberScope Data Feed Generator

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

NIST- Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) SP-800 122 OMB Cyberscope

Protects from risks of data loss Use layered security to enhance protection, Block data loss, Protect encrypted traffic SCAP validated product that works with the IPS and endpoint products to report audit information As a PEP, gateways intercept all web service traffic as a proxy to internal infrastructure and cloud- lending to a complete audit trail. The Vulnerability Manager CyberScope Data Feed Generator tool helps you to generate a data feed report directly from Vulnerability Manager that can be submitted to the CyberScope application.

11

ICAM is a critical piece in protecting information and achieving cybersecurity goals. As a rising priority, cybersecurity will continue to grow and change within the Federal Government... Moreover, the White House Cyberspace Policy Review states that one of the near term actions ... [will be] to build a cybersecuritybased identity management vision and strategy.2

About the Author

Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical Federal/Government, nancial, nancial exchanges, healthcare, manufacturer, and insurance systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at http://1raindrop.typepad.com

Intel & McAfee

As Federal fully embraces the cloud, the primary trafc channels of email, web, and identity authentication trafc begin to proliferate beyond the controlled rewall, to mobile and off-premise private cloud platforms. This trafc crosses security layers- each requiring a unique set of security 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 that delivers on the vision of unied security policies, reporting, DLP, threat intelligence, and standards based identity & access management- all cloud based, available from a single trusted vendor and certied to meet federal standards.

For more information, please visit:

www.intel.com/go/identity www.mcafee.com/cloudsecurity Americas: 978-948-2585 Email: asipcustomercare@intel.com

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 BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL 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, COPYRIGHT OR 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 THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specications 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 undened. Intel reserves these for future denition and shall have no responsibility whatsoever for conicts or incompatibilities arising from future changes to them. The information here is subject to change without notice.Do not nalize 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 specications. Current characterized errata are available on request. Contact your local Intel sales ofce or your distributor to obtain the latest specications and before placing your product order. Copies of 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 site at 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