SOA Security in a Federated Web Services Environment -
Upcoming SlideShare
Loading in...5

SOA Security in a Federated Web Services Environment -






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

SOA Security in a Federated Web Services Environment - SOA Security in a Federated Web Services Environment - Document Transcript

  • SOA Security in a Federated Web Services Environment - Security Standards for Information Assurance Argosy Omnimedia, Inc. Version 1.0 3/27/2006 Document Number: A1000224 Argosy Omnimedia, Inc 6110 Executive Blvd., Suite 1065 Rockville, MD 20852 For more information contact: Rob Montgomery 301.816.9373 x17
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance 1 Synopsis This paper is targeted to the technical staff of an organization (e.g. CIO, CTO, VP, Director) and assumes a broad understanding of the principles of; 1) information technology security, 2) basic web services technologies, and 3) architectural principles of Internet-enabled e-Business solutions. This paper is not intended to act as a tutorial for the standards or technology components, nor does it cover the business principles and benefits of a Services Oriented Architecture. The purpose of this paper is to provide an overview of the web services security-related specifications and standards with a focus on federated business architectures where data must be shared securely with other trading partners and collaboratively updated or functionally pipelined to meet the collective business objectives of a consortia of information sharing partners (e.g. trading partner network). The topic of Web Services (WS) security standards is an exceptionally complex one because it must encompass multiple operational scenarios of users (or applications) of the underlying web services, span multiple network and operating systems, and interface with most layers of the protocol stack ranging from Data Link to Application. The ability to dynamically access and bind with other data processing services also increases the risk to both parties (the user of the service and the provider) if proper security provisions are not implemented throughout the networked resources/assets. This paper is the one of a series of papers that focuses on the security aspects and considerations of WS and how they are applied in the real world. 1.1 Example WS Applications Government Centers of Excellence (COE) - In government, an example application of this federated network (“Federation”) is the distribution of business logic and data among different agencies organized around Centers of Excellence (COE) business models. Business operations or processes that are similar across agencies can be outsourced to one or more agencies that specialize in a given business domain (e.g. grants, payroll, recruiting). These Centers of Excellence can then provide cost effective services to other agencies based on their superior level of staff expertise and significant investments in capital assets. Secure Information Processing Between Intelligence Agency “Stovepipes” - Another example of a government Federation is the distribution of threat intelligence among partnering intelligence and law enforcement agencies that have loosely coupled their intelligence related data processing assets in order to facilitate collaborative, secure knowledge discovery across traditionally “stove piped” data repositories or intelligence centers. Disaster Recovering Coordinated Response – Government agencies have specific services that they provide to specific jurisdictions. Information sharing through secure collaboration is extremely important to the quality and speed of responsiveness in the event of a disaster. The Katrina preparation and recovery effort is an example of how important timely, accurate information is to an effective response. The interstate 3 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance transport of hazardous materials is another example. In the event of a train accident that involves a shipment of hazardous material (e.g Chlorine Gas, nuclear materials, or military munitions), multiple agencies and jurisdictions would require a coordinated response of local, state and federal agencies such as DHS-FEMA, DOE, DOJ and the DoD. This coordinated response would require the rapid and reliable sharing of information across multiple network domains with a coordinated method for authentication, authorization, auditing, encryption and non-repudiation capabilities. Web services provide a technology pathway toward achieving this level of interoperability and secure collaboration. The term Web Services represents the business perspective of the embodiment of underlying technologies implemented through the more technical reference of Services Oriented Architecture. Each term will be used in this way throughout this paper. The term Web Service is broadly applicable to a wide variety of network based application topologies. In this document, Web Service encompasses application components whose functionality and interfaces are exposed to potential users through the application of existing and emerging web technology standards including XML, SOAP, WSDL, and HTTP. In contrast to a web site’s browser-based interactions or platform-dependent technologies, Web Services are services offered computer-to-computer, via defined formats and protocols, in a platform-independent and language-neutral manner. W3C states that “A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols”. The evolution of WS can be classified into three stages ranging from; simple RPC-like remote calls, federated applications, transactional web services. In this latest stage, web services can invoke each other to form chained or transactional operations. Section 3 WS Security Standards and Technology presents a broad spectrum of specifications that cover the security technologies that provide a foundation for a “best practices” implementation of authentication, authorization, privacy, trust, integrity, confidentiality, secure communications channels, federation, delegation and auditing across a wide spectrum of application and business topologies. These specifications provide a framework that is extensible, flexible, and maximizes existing investments in security infrastructure. By leveraging the natural extensibility that is at the core of the Web services model, the specifications build upon foundational technologies such as SOAP, WSDL, XML Digital Signatures, XML Encryption and SSL/TLS. This allows Web service providers and requesters to develop solutions that meet the individual security requirements of their business processes and applications. Providing a comprehensive model of security functions and components for WS requires the integration of currently available processes and technologies with the evolving security requirements of future applications. It demands unifying concepts; it requires solutions to both technological (secure messaging) and business process 4 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance (policy, risk, trust) issues; and finally, it requires coordinated efforts by management and technology consultants, platform vendors, application developers, network and infrastructure providers, and trading partners. Unifying the range of security technologies means that the functional requirements of application security must be abstracted from the specific mechanisms employed. The complexity involved in deploying secure SOA systems is difficult to manage due to: Complex, distributed, federated business agreements and service contracts implementing different operational polices and procedures Changing and evolving standards supporting interoperability Coordination of implementation across multiple trading partner environments/networks Application and platform specific security analysis must be performed with great attention to detail. Aspects of the overall security configuration can be buried in many corners of each platform and component. Examining each configuration option to ensure the overall system security is a time consuming and error prone process. It requires expertise in each deployment platform and application domain. Argosy Omnimedia has a long history of full-life-cycle implementation of complex information technology solutions for federal and commercial clients. As a professional consulting services firm, Argosy’s experience spans the implementation of e-Business solutions for clients throughout the full-life-cycle implementation of secure, collaborative communication and trading environments; many of these utilizing Services Oriented Architecture and the underlying Web Services technologies. Argosy’s management and technology consultants have the training and experience to assist your organization with the implementation of enterprise- wide and federation-wide web services. This paper is designed to provide an overview of the many areas of consideration and scope for securing a Services Oriented Architecture (SOA) technology web services implementation. 5 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance 2 Web Services The basic, operational components of WS are; 1) the capability of remote access for invoking business logic provided by the Simple Object Access Protocol (SOAP) and the standards initiatives surrounding industry specific extensions and 2) the structured, human readable data file format of eXtensible Markup Language (XML) with various industry specific ontologies and related dictionaries. The first generation of web services consisted of a simple one to one interaction. This execution process is encapsulated entirely within a service domain and does not depend on other external services. A typical sequence of operations of this generation of web service is illustrated in Figure 1: Web Service - First Generation. In this example, a request is submitted for a cargo manifest that can be extracted from a government maintained database of shipment inventory data. This request is posted to the SOAP server from any client process authenticated to access this information based on credentials managed within the domain. The user could be authenticated by a simple user ID and password pair or through a more sophisticated digital certificate presentation to the SOAP server. Figure 1: Web Service - Second Generation 1. A requesting application will send a request message to a SOAP server. 2. The SOAP server invokes the internal class implementing the service in question. 3. The class performs the tasks required by the job (e.g. reading from an internal database) and returns to the SOAP server. 4. The SOAP server eventually authors the SOAP response and sends the response back to the requesting application over HTTP. The next generation of web services supported federating, distributing, or outsourcing the processing of method invocation calls to a trading partner or other application running in a separate subnetwork or security domain. In the same example, the user is authenticated through the forwarding of user credentials to a third party for verification, in this case, within the domain. A “trust relationship” exists between and where the later has the responsibility for managing the background investigation and credential management services for the users (or process) that has the 6 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance rights to access the cargo manifest. Processes and standards for managing this trust relationship are discussed later. 7 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance Figure 2: Web Service - Second Generation The current generation of web services represents a logical extension of the second generation. When the Federation chain becomes too long or the business logic is inherently complex, these distributed, federated applications take the form of web pipelined service transactions. The various steps in a business process are distilled into their tasks and those tasks could be performed by reusable services that are distributed across network domain boundaries (or can be managed within a single domain). These services could be managed and implemented through “centers of excellence” that take ownership of tasks that are replicated throughout the federation (of agencies in this example) and utilize a range of best practices in order to provide a high level of service quality that is leveraged across the entire user community resulting in the lowest possible cost of implementation. 8 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance Figure 3: Federated WS Transactions Figure 3: Federated WS Transactions Workflow Business Identify Cargo Cargo Triage Suspect Source & Inspection Cargo Destination Report Description Catalog & Query Query Cargo Shipment Bills Manifest of Lading SOAP Header Data Payload Data File XML HTTP Each SOAP server in the above examples knows only the information related to the web services it is hosting (names of the services, names of the methods in each service, where to find the actual classes that implement the web services, and so on) and has the capability of processing incoming SOAP requests. A SOAP server itself doesn't have any capability to check whether the incoming SOAP request is coming from an anonymous user or a known business/trading partner. Without a WS security infrastructure, SOAP cannot distinguish between sensitive and non-sensitive web services and cannot perform user authentication, authorization, and access control. Without a security management layer, any client that has access to a SOAP server can invoke any method of any services hosted on the particular SOAP server. 9 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance 2.1.1 Security Context Effective security within WS is not a separate overlay to the WS architecture and standards, but an integral part of each of the WS components. Peripheral security standards exist at each of the layers of the stack (OSI Layer model), however, the WS security standards facilitate both loosely coupled, as well as tightly coupled, security services. The standards also facilitate a variety of trust models necessary to support both Federated as well as Enterprise-wide subnetwork bounded/limited exposure of web services. 10 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance 3 WS Security Standards and Technology Figure 4 provides a view of how the various standards and specifications that define WS are functionally related. Various services like Choreography and Registry are designed to facilitate the “late binding” capability of WS that ensures various services can both find each other and be able to talk or communicate data in a uniform and reliable format. This paper focuses on those standards pertaining to security and how they relate to other non-security standards (e.g. Transactions, Reliability). Two organizations have provided the structure and forums for standards development that has been based on proposals from product companies like IBM & Microsoft. The World Wide Web Consortium (“W3C” – has a long history of stewardship for the Internet protocol and communication standards. Oasis-Open ( has approached the standards development process more from a top-down approach by facilitating the development of vertical industry specific standards, particularly around XML schemas and dictionaries. There is an Oasis forum for just about any industry that one could imagine that has been working on standards to consolidate the abstraction of processes and modeled entities for business, scientific research and even theology (ATLAS (American Theological Library Association Serials Project)). OASIS members are defining many of the infrastructure standards that enable Web services used in specific communities and across multiple industries. The WS specific standards can be partitioned into; 1) XML, 2) WS* and 3) technical committees. These security standards from W3C and OASIS are designed to help implementers understand: the security requirements of web service applications; how the different standards fulfill the different security requirements; how the different security standards are related to each other; and how they coordinate to form modules of the entire web services security architecture. 11 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance Figure 4: Security Domain in the Context of Other Web Services ( 3.1 XML Security for Web Services This section briefly discusses the high level features of some of the XML specific security protocols supported by W3C, OASIS and IETF. These protocols establish data integrity and authentication (both message and signer authentication) features, wrapped inside the XML format. W3C's XML Encryption specification addresses the issue of data confidentiality using encryption techniques. Encrypted data is wrapped inside XML tags defined by the XML Encryption specification. 3.1.1 Cryptography (asymmetric & symmetric) Asymmetric cryptography is a technique using a pair of keys consisting of a public and a private key. A suitable cryptographic algorithm is used to generate your public-private key pair. Your public key will be open for use by anyone who wishes to securely communicate with you. You keep your private key confidential and do not give it to anybody. The public key is used to encrypt messages, while the matching private key is used to decrypt them. To send a confidential message, a sender may ask for a recipient’s public key. The sender then encrypts the message using the recipient’s public key and sends the encrypted message across the wire. The recipient uses their private key to decrypt the message. No one else will be able to decrypt the message, provided that the recipient has kept the private key confidential. This is known as asymmetric encryption. Public-private key pairs are also sometimes known as asymmetric keys. 12 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance In symmetric encryption, the same key is used for encryption and decryption. In this case, the key has to be a shared secret between communication parties. The shared secret is referred to as a symmetric key. Symmetric encryption is computationally less expensive when compared to asymmetric encryption (this is why asymmetric encryption is ordinarily only used to exchange the shared secret). Once both parties know the shared secret, they can use symmetric encryption. 3.1.2 Security Assertion Markup Language (SAML) OASIS SAML provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved. The latest information can be found at Security Assertion Markup Language (SAML) V2.0 3.1.3 eXtensible Access Control Markup Language (XACML) OASIS XACML lets you express your authorization and access policies in XML. XACML defines a vocabulary to specify subjects, rights, objects, and conditions -- the essential bits of all authorization policies in today's e-commerce applications. The latest information can be found at Extensible Access Control Markup Language (XACML) v1.0. 3.2 SOAP Figure 5: WS* security specification domains shows that the Simple Object Access Protocol (SOAP) is one of the key foundation protocols underlying Web Services, and correspondingly, WS security. More information on SOAP can be found through the following sites: SOAP Specification & Reference W3C Simple Object Access Protocol (SOAP) 1.1 SOAP Routing Protocol W3C Note: SOAP Messages with Attachments SOAP 1.1 Reference Figure 5: WS* security specification domains 13 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance 3.3 OASIS WS* Standards OASIS has been very aggressive in the stewardship of the WS* set of standards and specifications. Various working groups and technical committees have worked on these standards and have spawned web sites dedicated to the development, promotion and maintenance of them. The hypertext links for each standard links to the specifications document or a supporting website. All of the relevant OASIS standards can be accessed through the OASIS Standards page. 3.3.1 WS-Security WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message. WS-Security contains a standard set of SOAP extensions that can be used when building secure Web services to implement integrity and confidentiality. WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety of security models including PKI, Kerberos, and SSL. Specifically WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies. The specification provides three main mechanisms: security token propagation, message integrity, and message confidentiality. These mechanisms by themselves do not provide a complete security solution. Instead, WS-Security is a building block (see Figure 5: WS* security specification domains) that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and encryption technologies. These mechanisms can be used independently (e.g., to pass a security token) or in a tightly integrated manner (e.g., signing and encrypting a message and providing a security token hierarchy associated with the keys used for signing and encryption). WS-Security enables applications to construct secure message exchanges. WS-Security is a message security model that provides the basis for the other security specifications. Layered on this, we have a policy layer which includes a Web service 14 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance endpoint policy (WS-Policy), a trust model (WS-Trust), and a privacy model (WS- Privacy). Together these initial specifications provide the foundation upon which we can work to establish secure interoperable Web services across trust domains. WS-Security: SOAP Message Security - WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. WS-Security also provides a general- purpose, but extensible, mechanism for associating security tokens with messages. Additionally, WS-Security describes how to encode binary security tokens—specifically X.509 certificates and Kerberos tickets, as well as how to include opaque encrypted keys. WS-Security: UsernameToken Profile - This document describes the use of the UsernameToken with the WS-Security specification. WS-Security: X.509 Certificate Token Profile - This specification describes the use of the X.509 authentication framework with the WS-Security specification. WS-SecureConversation - WS-SecureConversation defines extensions that build on WS- Security to provide secure communication. Specifically, we define mechanisms for establishing and sharing security contexts, and deriving session keys from security contexts. WS-SecurityPolicy - WS-SecurityPolicy indicates the policy assertions for use with WS- Policy that apply to WS-Security, WS-Trust, and WS-SecureConversation. WS-SX TC - The purpose of the OASIS WS-SX TC is to define extensions to OASIS Web Services Security to enable trusted SOAP message exchanges involving multiple message exchanges and to define security policies that govern the formats and tokens of such messages. This work will be carried out through continued refinement of the WS- SecureConversation, WS-SecurityPolicy, and WS-Trust were contributed to the OASIS Web Services Secure Exchange (WS-SX) Technical Committee in December 2005. OASIS Standard (Security) 1.1 OASIS has versioned the WS-Security standards. This section presents one of the latest sets. The following documents make up the WS-Security 1.1 OASIS standard. The links below are to the PDF versions of the documents. WS-Security Core Specification 1.1 Username Token Profile 1.1 X.509 Token Profile 1.1 SAML Token profile 1.1 Kerberos Token Profile 1.1 Rights Expression Language (REL) Token Profile 1.1 SOAP with Attachments (SWA) Profile 1.1 15 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance OASIS Standard (Security) 1.0 The following documents make up the WS-Security 1.0 OASIS standard. The links below are to the PDF versions of the documents. Web Services Security: SOAP Message Security V1.0 Web Services Security: Username Token Profile V1.0 Web Services Security: X.509 Token Profile V1.0 Schema files V1.0 [1] and [2] 3.3.2 OASIS Security Technical Committees In order to continue the development of the standards and to assist the information technology community with the implementation of these, OASIS has many security related technical committees that work on application and implementation specific problems within the WS domain. An overview of these is provided below: OASIS Digital Signature Services (DSS) TC - Defining an XML interface to process digital signatures for Web services and other applications. OASIS eXtensible Access Control Markup Language (XACML) TC - Representing and evaluating access control policies. OASIS Provisioning Services TC - Providing an XML framework for managing the provisioning and allocation of identity information and system resources within and between organizations. OASIS Public Key Infrastructure (PKI) TC - Advancing the use of digital certificates as a foundation for managing access to network resources and conducting electronic transactions. OASIS Security Joint Committee - Coordinating the technical activities of several, security-related OASIS TCs. OASIS Security Services (SAML) TC - Defining and maintaining a standard, XML- based framework for creating and exchanging security information between online partners. OASIS Web Services Secure Exchange (WS-SX) TC - Defining WS-Security extensions and policies to enable the trusted exchange of multiple SOAP messages. OASIS Web Services Security (WSS) TC - Delivering a technical foundation for implementing security functions such as integrity and confidentiality in messages implementing higher-level Web services applications. 3.4 Microsoft Web Services Security Standards The following list of WS Security related standards are being promoted by Microsoft, but have not been approved or endorsed by any independent standards organization to date. They have been submitted to a technical committee and are under evaluation for standards body approval. 16 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance WS-Trust - WS-Trust defines extensions that build on WS-Security to request and issue security tokens and to manage trust relationships. WS-Federation - WS-Federation defines mechanisms that are used to enable identity, attribute, authentication, and authorization federation across different trust realms. WS-Federation Active Requestor Profile - WS-Federation Active Requestor Profile defines how the cross trust realm identity, authentication and authorization federation mechanisms defined in WS-Federation are used by active requestors such as SOAP- enabled applications. WS-Federation Passive Requestor Profile - WS-Federation Passive Requestor Profile describes how the cross trust realm identity, authentication, and authorization federation mechanisms defined in WS-Federation can be utilized used by passive requestors such as Web browsers to provide Identity Services. Passive requestors of this profile are limited to the HTTP protocol. WS-Security: Kerberos Binding - WS Security: Kerberos Binding describes how to use Web Services security specifications with Kerberos. Web Single Sign-On Interoperability Profile - Web Single Sign-On Interoperability Profile defines an interoperability profile of the Web Single Sign-On Metadata Exchange Protocol that allows using either Liberty Identity Federation or WS-Federation-based Identity Providers to interact with a service. Web Single Sign-On Metadata Exchange Protocol - Web Single Sign-On Metadata Exchange Protocol defines how a service can query an identity provider for metadata that describes the identity-processing protocol suites supported by that provider. WS-Policy - The Web Services Policy Framework (WS-Policy) provides a general- purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities. WS-PolicyAssertions - specifies a set of common message policy assertions that can be specified within a policy. WS-PolicyAttachment - specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies. Specifically, we define how to associate policy expressions with WSDL type definitions and UDDI entities. We also define how to associate implementation-specific policy with all or part of a WSDL portType when exposed from a specific implementation. 17 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance 4 Next Steps Future papers discussing the following topics will augment the information provided in this paper: WS Threat Assessment – what are the most likely vulnerabilities and how could potential compromises occur. WS Security Best Practices – what are the architectural and system design elements necessary to improve the security posture of a given WS Federation or Enterprise. Argosy Omnimedia’s security consultants provide a broad range of expertise in information technology security, management consulting and industry specific expertise such as healthcare. Argosy’s security analysts have “written the book” on healthcare’s HIPAA Security regulatory compliance investigation and enforcement based on an in-depth knowledge of the regulations, industry common and best practices in security design, tools, and technology in addition to information technology security policies and procedures. The Argosy Team also has in-depth knowledge of the operations and business processes of health plans, health care clearinghouses and health care providers where HIPAA implementation and compliance occur. This staff expertise is exemplified through the following compilation of accolades and accomplishments: CISSP – Certified Information Systems Security Professional – (ISC)2 CHSP – Certified HIPAA Security Professional – (ISC)2 (awarded in 2003 when there were only 150 such certified professionals nationwide) CIPP/G – Certified Information Privacy Professional/Government (IAPP) CISA - Seminar training SANS Institute Training: Perimeter Defense (2003) and HIPAA Security Implementation (2004) Practice Management Institute, Certified Medical Office Manager Healthcare cash management, Wage and salary administration CPT/ICD-9 coding methodology, Medicare CMS/HCFA guidelines and ethics Nationally recognized HIPAA Privacy and Security Rule Implementation and Compliance subject matter expert HIPAA compliance assessments, training and remediation to Covered Entities Understanding of covered entity business and healthcare operations, organization and services Other Staff Certifications 18 Argosy Omnimedia, Inc. Proprietary
  • SOA Security in a Federated Web Services Environment – Security Standards for Information Assurance o e-Business Developer o J2EE Sun o MCSE2003 Microsoft Educational credentials o MBA – marketing, finance and operations management o JD – regulatory compliance in healthcare and interstate commerce Argosy’s team of consulting professionals are uniquely qualified to work with and augment your organization’s staff to improve overall performance and to reduce the risk of your WS implementation. 19 Argosy Omnimedia, Inc. Proprietary