mita-publichealthit-security privacy wp final

8/6/2019 MITA-PublicHealthIT-Security Privacy WP Final

http://slidepdf.com/reader/full/mita-publichealthit-security-privacy-wp-final 1/26

Security and Privacy in Health IT:Overview of Current Challenges and Solutions

Sub-committee Chair: Patrick Fendt, Oracle Corporation

Sub-committee Contributing Team Members:

Emanuel Mkrtichian, Fox SystemsAdeola Odunlami, eServicesGreg Anderson, Minnesota DHSDave Walsh, eServices

Revision: 1.0Date: 08-14-2009

MITA Technical Advisory Committeean industry collaboration

PSTGPrivate Sector Technology Group

www.pstg.org

HSITAGHuman ServicesInformation Technology

Advisory Group

http://www.pstg.org/

http://www.pstg.org/



General IT Security Risks and Investment Justification

Security and privacy management is a fundamental and growing concern for healthinformation technology professionals. In addition, the need for exchange of informationlbetween monolithic MMIS systems and other health IT applications (and data stores)are continuing to increase. This process is expedited by modernization initiatives (e.g.the migration toward Service Oriented Architecture), as well as more federatedinformation sharing and inter-organizational transactions -- as part of the MITA businesstransformations. As a result, this paper will address the requirements and solutionsrelating to security and privacy in the context of health information technology. Thispaper will provide requirements and propose solutions that are quite broad in scope.

However, we will approach this topic from the standpoint of health information systems,and as appropriate, narrow the focus to MMIS systems (both in the current legacyenvironment as well as SOA-enabled systems).

The IT landscape continues to change rapidly. IT professionals facemany challengesand have many new technologies available to them (some of which actually increaseour security risk). As a result, security and privacy remains one of our top priorities. For example, the data maintained in MMIS environments involves claims for medicalservices and is highly sensitive. An MMIS (and/or HIE) security breach would havewide implications and could adversely affect the lives of many citizens. In general, thereare four reasons organizations invest in security infrastructure:

1. Save money – primarily by reducing IT-related administrative costs2. Lower the risk of lawsuits and associated liability3. Comply with laws and regulatory requirements4. “Brand” protection (protecting reputation of organizations and people)

As a result, let’s consider each of these topics individually. First, since IT organizationsare typically viewed as cost centers, cost-savings is a critical consideration. Recentresearch shows that organizations can save approximately 68% of their security-relatedadministrative costs when using identity and access management software. For example, a typical enterprise performs the following tasks via end-users, administrators,or help-desk staff:

1. Adding, modifying, or deleting users2. Password maintenance and provisioning/privilege-related requests3. End-user time consumed by password and account maintenance

This time adds up, and as a result, when this time is optimized by proper securityinfrastructure, it leads to an estimated savings of $587 per user per year. This

Copyright 2009. All Rights Reserved.



approach would provide an annual cost savings of 59% -- as a result of using acomprehensive identity management solution.

Second, with respect to breaches, the CSI-FBI “Computer Crime and Security Survey”

has historically been an excellent source of information on the impact of computer breaches. Their research estimated that, back in 2000, organizations, on average, lostapproximately $1 million per security breach – and this excludes “intangible” lossessuch as reputation and the associated lost revenue. However, this number doesinclude time spent doing forensic analysis of the breach, as well as the associateddisruptions to normal work productivity.

Finally, the executive leadership of organizations are typically held liable for ensuringthat proper safeguards and compliance measures are taken – including theimplementation of proper IT security infrastructure. In addition, violations of regulatorycompliance can lead to severe penalties – even including criminal prosecution (FERPA

violations are good examples of this). This is, no doubt, a major force in the adoption of these technologies. Additionally, as Medicaid agencies increasingly utilize web basedsystems (and possibly clouds in the future) to make health services available toenrollees and providers; Security and Privacy risks increase and must be mitigated.However, the good news is that the cost-savings alone justifies the expenditureon security technology . (Refer to Appendix A for a real-world estimate.) For a typicalHHS organization, the net savings can easily add up to several million dollars over aperiod of a few years.




Security- and Privacy-Related Business Requirements

The health and Medicaid arena is amidst a good deal of change. Specifically, theStates and supporting organizations are planning and/or implementing many of thefollowing business initiatives:

• Health Information Exchange (HIE)• Support for Electronic Health Records (EHRs)• Support for Personalized Health Records (PHRs)• ePrescribing• Remote Monitoring• Personalized Healthcare (PHC / genetically-based care technologies)• “Integrated” Health & Human Services• Call Center consolidations to provide greater accessibility to services to enrollees• Web 2.0 Social Networking Initiatives

In an effort to “kill more birds with fewer stones,” the authors have researched theseinitiatives (in the context of security and privacy for health systems – including MMIS),and attempted to distill the business requirements into the following list:

• Quality Reporting• De-identification and re-identification• Public Health Case and Adverse Event Reporting• Patient-to-Provider secure messaging• Provider-to-Patient secure messaging• Managing Consent Directives

o Document/form management (secured)o Request for Patient Consento Confirmation of NOPP

• Lab to Electronic Health Record messaging• Lab Results Redaction based on Privilege/Role/Context• Clinician authentication• Clinician authorization (based on privileges/role/context)• Electronic Signature capability (clinician's)• Notify Locator Service of Lab Results• Notify provider(s) (e.g. when patient has new test results)• Infectious Disease Notification• Provider-to-Provider Patient Data exchange• PHR Provider List Management




• PHR Transfer • PHR Information Management (e.g. patient-controlled redaction)• Medication Management• PHR to Clinician/EHR messaging• Provider-Prescriber messaging• EDIS to Electronic Health Record messaging• Provider to Provider messaging• Remote monitoring information intermediary (RMII) - confidentiality• RMII data collection via encrypted means• RMII user/clinician authentication• RMII user/clinician access controls• RMII auditing• RMII to PHR/EHR/HIE exchange/messaging• Non-repudiation• Regulatory Compliance:

o HIPAAo FISMA (if national) - implies GRC/reporting requirementso FERPA - school-related care/information - applicable for interaction with

schoolso NIST 800-53o PCI DSS - credit card information and associated PII liability

We felt this grouping and distillation is especially appropriate given the crosscuttingnature of security and privacy technologies, as well as the aforementioned “blurring of lines” between Medicaid and other health systems. The following section will provide anapproach and specific technical solutions addressing these requirements listed above.

Security- and Privacy-Related Technical Requirements

In order to address the business requirements listed above, we have identified thefollowing security/privacy-related technical requirements in the following table (as wellas some proposed solutions and associated standards that apply):

Technical Requirement Technology Solution ApplicableStandard(s)

Consent Directive Support CMS, Audit Infrastructure JSR 170 for contentmanagement plug-ins

Document/Records Mgt JSR 170 for content




management plug-insBasic Authentication Username/Password, WS-

Security Basic ProfileWS-Security and WS-Iinteroperability

End-to-End Auditing Vendor-specific; need credentialsto be passed through/acrossarchitectural "tiers"

N/A

Maintain authorizedprovider list (e.g. via clinicalsystem or MPI)

Secured Database/RDBMS SAML 2 and XACML 2may play role for webservice requests.

Locator Service (for shared-services like patientmatching, PHR lookup,etc.)

Web Service and associatedbackend database

WS-Security and WS-Iinteroperability

Identity matching (e.g. for quality reporting)

Web Service and associatedbackend database

WS-Security and WS-Iinteroperability

Automated Provisioning Provisioning software SPMLCredential Management Infrastructure middleware XKMS, JEE and JAAS

(for Java-basedsolutions)

Access Mgt / ATZ /Privilege Mgt

Centralized AUTHZ engine XACML

Role-based Access Control(RBAC)

Centralized AUTHZengine/service

XACML, JEE (for Java)

Attribute-based AccessControl (ABAC)

Centralized AUTHZengine/service

XACML, SAML

Fine-grained Authorization(FGA)

Centralized AUTHZengine/service capable of fine-grained, contextual and policy-based authorization decisions

XACML, SAML

Contextual ATZ Centralized AUTHZengine/service

XACML, RBAC, ABAC

Federated ATN - Web SSO Federation Product SAML 2.0, WS-Federation passiverequestor

Federated ATN -Messaging

Federation Product SAML, LibertyAlliance, WS-Trustand WS-Federation

Strong/Two-factor Authentication

Multiple approaches areavailable

Various options: PKI,XKMS, X.509, TokenCards, One-timePasswords, User Questions and PINs

Strong/CertificateAuthentication

Multiple approaches areavailable

Asymmetric PKI,X.509, SAML, WS-




Security for webservices

Governance, Risk, andCompliance Controls(GRC)

GRC Solution and People/Mgt COBIT, COSO, ITIL,Liberty IGF, OCEG,:http://www.oceg.org/view/20083 and www.coso.org

Directory Mgt Virtual directories or directorysynchronization solutions

LDAP v3

Non-repudiation All of above + auditing XML Signature,Asymmetric PKI withdigital signatures

Privacy - Doc Encryption Information/Digital Rights Mgtsolutions (a.k.a. IRM or DRM)

XML Encryption, 3-DES, AES, X.509, PKI

Privacy -

wire/channel/sessionencryption

SSL / TLS SSL, HTTPS

Privacy - MessageEncryption

XML Encryption XML Encryption

Privacy - Data-at-restencryption

DB encryption Typical defacto standardsare: 3DES168, AES128,AES192, and AES256

Privacy - De-identification DB/Bus-tier/Central-ATZ/UI-tier See abovePrivacy Re-identification Matching program See aboveData-use Agreement(electronic)

Business Process w/GRC andRecords/content Mgt

Content/DocumentManagement (JSR170)

The following section will now introduce the MITA Security and Privacy reference model – serving to put some more MITA and MMIS-specific context around the potentialsolutions to these requirements.

MITA Security and Privacy Reference Model and Guidance

Security and Privacy requirements are documented in Technical Architecture (Part III) of the Medicaid IT Architecture (MITA) Framework 2.0. The Application Architecturesection of the framework describes a series of security and privacy focus areas(guidance or goals) that must considered throughout your planning and design phases:

• Requiring Integration from the Beginning


http://www.oceg.org/view/20083



http://www.coso.org/



http://www.coso.org/



• Taking into Account the Business Perspective• Candidate S&P Use Cases• Providing Protection with Low Maintenance• Consistent Across Medicaid• Adaptable/Responsive• Platform/Software Independent• Cross-Agency Integrated and Aligned• Going Beyond HIPAA• Defining Goals and Objectives by Formal and Informal Policies

To achieve the goals outlined above, a basic approach for addressing security andprivacy is proposed. In general it involves tying the security and privacy implementationto both business and legislative requirements. The approach recommends severalreference models and guidelines. At a more detailed level the framework recommends

several basic security and privacy principles to follow:• Compartmentalize your IT environment to minimize vulnerabilities and risk• Use principle of least privilege – only allowing access as required• Apply defense in depth (a.k.a. end-to-end security )• Do not trust user input• Check at the gate• Fail securely• Secure the weakest link• Create secure defaults• Reduce your attack surface• Simplify security implementations to increase uptake and avoid subversion

The section concludes with a description of a security and privacy policy model thatmentions several control points and services for the security and privacyimplementation. In addition, it is very useful to consider the MITA Threat Model whenperforming risk assessments:

• Spoofing – masquerading as a privileged user • Tampering – with messages or data• Repudiation – denying having sent or received something•

Information Disclosure – inappropriate/unauthorized access to data• Denial of Service – flooding system with requests• Elevation of Privilege – malicious or unintentional/gradual acquisition of more

privileges than one should have given their role

For reference purposes, what follows (Figure 1) is a pictorial description of the MITASecurity and Privacy Model – as depicted in the MITA Application Architecture 1.




Figure 1: MITA Security and Privacy Model:




The following section will provide detailed solutions to address the needs andvulnerabilities for the technical requirements listed above.

Security and Privacy Solutions for Today’s Environment

In order to meet the requirements and achieve the objectives detailed above, we mustemploy several technologies offered my security and privacy vendors. First, we shouldcategorize the solution areas using MITA Application Architecture and MITA TACTechnical Services 2 (detailed in prior published documents). To summarize, thefollowing list provides a good summary of the types of vendor technologies required to

meet these needs:1. Firewalls and perimeter security2. Fraud detection/prevention software3. Automated user provisioning4. Single-signon (simplified signon)5. Centralized authentication “service”6. Encryption support throughout the architectural “tiers” and between machines7. Middle-tier security context propagation and role-support (RBAC)8. Centralized, coarse-grain and fine-grained authorization “service”9. Digital / information rights management and document management

10.End-to-end auditing11.Securing the data (RDBMS)12.Security and Privacy Governance

Now we will provide a bit more detail about each of these solutions.

Firewalls and Perimeter Security

These products are mature and well understood. The key here is opening up only thoseports that are necessary, and automating the administrative processes around makingchanges -- to ensure that it is efficient. In addition, these hardware/software firewallsshould be capable of sending audit-related events into a file or database. (Refer toauditing section for more details on aggregating this information.)

Fraud Detection/Prevention Software

Technology has advanced a great deal in this area over the last several years. You cannow deploy fraud detection and prevention software that prevents hackers fromexecuting the following types of attacks:




1. Masquerading as your web site2. Attempting or gaining access from computers located outside of your State or

Country (many attacks originate from other countries)

3. Employees or contractors “shoulder surfing” to learn passwords of administrativeor other users (to access personally identifiable data or health data – hereafter referred to as “PHI”)

4. Employees, contractors, or 3 rd-party personnel gaining access by installing“keyboard logger” software (malware) on your computers

5. Users performing odd/abnormal transactions – i.e. you can monitor the systemlooking for abnormal usage behavior. This protects against most types of insider/employee-based misuse, fraud, or inappropriate-access situations.

6. Other suspicious behavior such as attempting or gaining access during abnormalhours/days; or using computers that they do not normally use (e.g. personalcomputers that are not sanctioned/controlled by the organization)

This type of software can also feed its information into a central auditing and alertingsolution, or potentially serve as the central event-correlation and alerting mechanism.

Automated User Provisioning

The area of “user provisioning” refers to when new users are granted access tosystems, as well as removing their access when they leave an organization. This is aparticularly important area of security because, if it is done wrongly or inefficiently, itresults in significant security exposures/vulnerabilities as well as increased costs. What

follows are some interesting statistics related to provisioning:

1. Approximately 20% of access provisioning requires rework2. 27% of IT organizations exceed 5 days to grant or remove access rights3. 62% of user’s access is removed upon termination4. Security risk is 23X compounded by “orphan” accounts5. 81% of security breaches from disgruntled employees6. 60% to 80% of access profiles are out of date.7. Password resets cost approximately $25 per incident

As a result, organizations should consider purchasing and deploying a provisioning

automation solution to ensure that errors are greatly reduced and cost efficiencies areachieved.

SSO and Centralized Authentication

SSO provides for greater productivity by reducing the number of identifiers andpasswords that users have to remember/use. For example, this discourages or




obviates the need for users to write passwords down near their computer/desk, andgreatly reduces the chance that inappropriate users can gain access to your systemsand data. In addition, SSO software typically also supports a centralized authenticationservice that can be used across the IT enterprise to support authenticating various

types of users in a heterogeneous environment. For example, vendors often supportweb-service interfaces for authentication of users in a MITA and service-orientedarchitecture (SOA). Finally, centralization provides multiple benefits such as:

1. Reduce chance for duplication and errors2. Reduce administrative overhead3. Decrease number of system administrators with “super user” privileges4. Standardization and simplification of application development, deployment,

and management5. Can re-use personnel, infrastructure and policies (if desired)

Encryption Support Through the Architectural “Tiers”

Sensitive data should be encrypted throughout the architectural tiers of your healthsolution. The good news is that many technologies and standards are now offered byvendors to simplify the implementation of this policy:

1. SSL encryption between machines and over the internet2. XML encryption for web services that cross organizational boundaries (or cross

firewalls)3. Digital rights management software to encrypt documents (or parts of

documents) that are distributed to users. Refer to the section below for moreinformation on this.4. Database encryption to protect sensitive PHI

Middle-tier Security Context Propagation and RBAC

It is critical that identity data (e.g. fully qualified username or email address), as well asany associated role information, be passed through the architectural tiers of your applications. This means that the following tiers of functionality carry/pass thisinformation to/from the next tier:

1. User interface tier 2. Business logic tier 3. Data or host-access tier

One typical approach, for web-based user interfaces, is to capture the identity via theHTTP session, and then pass it along (via web-services or remote-calls) into thebusiness logic tier. The front-end of the business logic tier is often implemented via




web-service technology. The web services can then invoke business processes(passing the identity and role data into that process. The business process then uses a“RunAs” mechanism to enable the process to execute as per the identity and privilegesof the appropriate user. In addition, the web services or business processes can also

propagate the user identity into the backend data tier (e.g. via “proxy authentication”technology). One critical benefit here is that identity propagation provides theunderpinnings for auditing. Auditing requires that end-user identity, as well ascorrelating transactional identifiers, is logged/persisted and carried across these tiers.In addition, non-repudiation requires this auditability; and more importantly, non-repudiation is often required as part of a business process.

Centralized Authorization Service

Authorization is another “common service” required by most business logic,

transactions, and business processes. In addition, sensitive operations and data oftenrequire an authorization step to ensure that the function/process is not accessed via aninappropriate channel or user. And the benefits of centralized authorization are thesame as those for centralized authentication (listed above).

Document Management and Digital / Information RightsManagement

General document management is an integral part of security. Sensitive PHI data iscontained in many of the healthcare forms and documents – whether electronic or

paper-based. And these documents should be classified according to the type of datathey contain as well as the retention policies applying to them. If documents are notproperly categorized, then the security and privacy infrastructure cannot possibly grantor deny access appropriately.

In addition, lnformation Rights Management (IRM, also referred to as DRM) softwareallows documents to be distributed freely (e.g. via internet) while still protecting theconfidentiality/privacy of that information. This is achieved by encrypting the document,and then disallowing access (decryption) unless:

1. User authenticates to a central authority (e.g. provider or payor)

2. User has been granted appropriate access privileges to all or part of thatdocument

If authenticated and authorized, the IRM/DRM solution will send/enable a decryptionkey to the end-user machine that allows the document to be viewed (partially or wholly)

– subject to the security and privacy policies defined centrally. This technology is quiteadvanced and provides for greater flexibility in designing and delivering healthcareapplications/solutions – while still adhering to regulations such as HIPAA, FERPA, etc.




End-to-End Auditing

Auditing provides many benefits:

1. Critical for regulatory compliance2. Can facilitate debugging system problems3. Supports and facilitates legal actions/response

Auditing should be one of the high-priority items on any IT project plan, and this isespecially important since it is often relegated to being an afterthought. Some vendorsalso offer audit data aggregation and correlation software that can monitor multipleheterogeneous audit data sources, and then manage that data to support eventaggregation, correlation, and alerting.

Securing Data in the Database

The “last mile” of security is the database. In the context of security, the database isalso sometimes referred to as “data at rest”. Sensitive (PHI) data should always beencrypted and closely managed to ensure that only those persons with appropriateprivileges can view that data. In addition, securing and encrypting database dataprovides for an additional level/layer of security – for those cases when another “tier” of your architecture has been compromised. For example, a hacker may get into your system, but by encrypting the PHI in the database, they might not be able to see the

PHI because, when accessed, it is still encrypted. Moreover, encrypting the databasedata will help protect against internal violations (employees or contractors). And it is awidely accepted fact that the majority of security attacks are performed byemployees/contractors.

However, when applying these technologies, we highly recommend that you follow theMITA guidance and threat model described in the previous section, as well as theguidance provided in the document “Security in the Context of MMIS and MITA.” For amore technical perspective, please refer to the MITA TAC Security and Privacy“Technical Functions Overview” document published in 2008. In addition, theappendices contain a recap summarizing many of the relevant technical standards that

support the recommendations of this document. Finally, the appendices also contain aseries of questions aimed at assessing your “status quo” and needs analysis goingforward with respect to implementing security and privacy technologies.

Security and Privacy Governance




Governance, Risk, and Compliance (GRC) management processes and tools arerelatively new concepts and technologies. GRC solutions automate the managementand enforcement of internal controls and improve the efficiency of the compliancemanagement process. What follows is a list of typical GRC functions that can greatly

facilitate the management and enforcement of your security and privacy policies:

1. Central repository of information for things such as: policies, procedures, processdiagrams, control descriptions, test plans, control matrices, and remediationplans

2. Support for comparing current and previous versions of control documents3. “Chain of custody” support for enforcing accountability as well as delegation of

responsibilities4. Reporting capabilities for viewing status of compliance as well as risk-related

exposures and issue tracking. Managers should be able to view the status of controls testing, aging of open issues, financial statement certifications, audit

findings and other critical GRC processes5. Enforce segregation of duties and monitor critical enterprise data andauthorization-related applications

6. Support for performing periodic assessments – including questionnaires anddistribution and collection of survey data

7. GRC audit trail




Conclusion and Best-Practice Summary

Nobody would disagree that security and privacy are of utmost importance, and areindeed common high-priority focus areas for executives in both private and publicorganizations. The following list provides a good summary of some important bestpractices:

1. Identify security and privacy issues at beginning of IT lifecycle2. Form a Security/Privacy Governance Committee3. Employ widely accepted industry standards wherever possible4. Leverage FEA / EA efforts such as FEA “Privacy Profile”

o

Similar to FTC “Fair Information Principles” (FIPs)5. Embark on Data Classification Project6. Review record retention and backup policies/practices7. Review IT Asset Disposal Policies and Practices8. Institutionalize auditing and perform audits periodically; consider using GRC

software solutions to facilitate this process

The good news is that the standards, technologies and products now exist (and aremature enough) to provide organizations with all the tools necessary to providecomprehensive security management. Moreover, the cost savings achieved byemploying these security and privacy technologies exceeds their total cost of

ownership. It is indeed an exciting time in the healthcare industry in that we now havethe tools necessary to implement new business processes, even those spanningmultiple organizational boundaries, and to do so in a way that preserves the securityand privacy required in today’s complex and fast-changing world.




Appendix A: Return-on-Investment for SecurityInfrastructure

The following table illustrates one real-world pre-implementation analysis (an estimate)done for a non-healthcare use-case (a U.S. Public School System). However, webelieve this ROI use-case is quite analogous to MMIS and HIE type IT environments. Inaddition, Gartner has stated that organizations with at least 12 (or more) applicationscan save 3.5 million over 3 years and see a 295% ROI on security infrastructureinvestments. Note that the Gartner estimate is consistent with the data in this use-case.This particular project involved deployment of an SSO, automated provisioning and self-service password reset solution for several applications:


Year 1 Year 2 Year 3 Year 4 Year 5

Costs,Benefits 2008 2009 2010 2011 2012 Total

TotalMeasurableBenefits $683,793 $1,460,876 $1,562,878 $1,674,488 $1,796,704 $7,178,739

TotalEstimatedCosts $906,168 $149,453 $149,453 $149,453 $149,453 $1,503,980

ProjectedBenefitsminusCosts ($222,375) $1,311,423 $1,413,425 $1,525,035 $1,647,251 $5,683,759

Year 1 Year 2 Year 3 Year 4 Year 5

Costs,Benefits 2008 2009 2010 2011 2012 Total

TotalMeasurableBenefits $683,793 $1,460,876 $1,562,878 $1,674,488 $1,796,704 $7,178,739

TotalEstimatedCosts $906,168 $149,453 $149,453 $149,453 $149,453 $1,503,980

ProjectedBenefitsminusCosts ($222,375) $1,311,423 $1,413,425 $1,525,035 $1,647,251 $5,683,759



Appendix B: Security Standards Summary

The IT industry has been relatively aggressive in creating and adopting standards tosupport security within an SOA environment. More specifically, the industry has, via theOASIS standards organization ( http://www.oasis-open.org ), created numerousstandards to ensure interoperability and protect investments in SOA infrastructure.What follows is a summary of the relevant security-related standards and anarchitectural picture (Figure 2) depicting how the most prominent standards relate toeach other:

1. WS-Security (WSSE)

a. This standard is the core and fundamental building block for securitywithin an SOA. The WSSE standard enables applications to conductsecure (SOAP-based) message exchanges. The specification provides aflexible set of mechanisms that can be used to construct a range of security protocols. The specification supports the following securityfeatures:

i. Multiple security token formatsii. Multiple trust domainsiii. Multiple signature formatsiv. Multiple encryption technologies (e.g. public-key or Kerberos)v. End-to-end message content security and not just transport-level

security2. XML Encryption

a. WS-Security includes this standard as a mechanism for encrypting anddecrypting all or part of a message.

3. XML Signaturea. WS-Security includes this standard as a mechanism for digitally signing a

message in order to prove that the message is from the alleged sender,and to prove the message has not been modified (provides messageintegrity).

4. WS-Policya. This specification provides a framework for describing information about a

service (meta-information) – such as the their constraints andrequirements. Service consumers and providers can then automatically(without human intervention) match up what the consumer needs withwhat the provider supplies. For example, a provider can assert thatauthentication is required in order to use this service, and specifically that


http://www.oasis.org/

http://www.oasis.org/



only a username and password are required to authenticate. Notsurprisingly, WS-SecurityPolicy is based on this standard.

5. WS-SecurityPolicy

a. This specification defines policy assertions for the security properties for Web services. In other words, it defines an initial set of patterns or sets of assertions that represent common ways to describe how messages aresecured. For example, the service provider can assert things such as: 1)parts of a message are being secured, 2) general pre-conditions prior tocalling the service, 3) specific mechanism and token types use to securethe service, etc.

6. WS-Trusta. This specification provides methods for issuing, renewing, and validating

security tokens, and in addition, it provides a way to establish and broker

trust relationships. The key here is that the Secure Token Server (STS)can accept one type of token and then provide/return a different type of token – thereby supporting a more heterogeneous and federatedenvironment.

7. WS-SecureConversationa. This specification provides a way for one or more service consumers and

providers to establish a secure context within which messages may beexchanged. Note that this context can span multiple service invocationsand involve multiple-endpoint message exchanges. The context isestablished using keys and allows sessions to be maintained – within

which other context-specific keys can be derived such that more efficientcommunication is supported.

8. WS-Federationa. This specification supports exchanging security credentials between

organizations in a standards-based way. It provides several different“profiles” for how identities and trust can be maintained across differentorganizational boundaries – where those organizations do not share acommon identity store. This is analogous to single-signon acrossorganizational boundaries and in a web services context.

9. SAML (Security Assertion Markup Language)a. SAML is an XML-based framework for communicating user authentication,entitlement, and attribute information. SAML allows business entities tomake assertions regarding the identity, attributes, and entitlements of asubject (an entity that is often a human user) to other entities, such as apartner company or another enterprise application.

b. SAML v2.0 has expanded the scope of SAML to include support for:i. Single-signon across organizational boundaries




ii. Identity Federation (identity providers, abstraction of user identity)iii. Sessions and Logout – user can have multiple sessionsiv. Attribute Services – exchange attributes via: XML name/value

pairs, LDAP, UUID, and XACML

v. Metadata exchange – identify roles, exchange configuration or trust data; helps with deployment as well

10. XACML - eXtensible Access Control Markup Languagea. XACML is a security policy management standard. It serves two major

functions: 1) expression of access policies and rules in a standard format,and 2) provides an access-control decision request/response standard.XACML 2.0 is the latest standard and is widely accepted. Note that SAML2.0 was expressly designed to interoperate with XACML 2.0 – in supportof a synergistic approach for federating authentication and authorizationdata between organizational entities and/or disparate applications. TheSAML profile within XACML supports several important functions:

i. Mapping SAML attributes to XACML attributesii. Sending a SAML authorization query to a XACML Policy DecisionPoint (PDP)

iii. Receiving a XACML response in the form of a SAML authorizationdecision statement

iv. Requesting one or more XACML policies using a SAML policyquery

v. Receiving XACML policies in the form of a SAML policy statementwithin a SAML assertion

vi. Storing XACML policies in the form of SAML policy statements11. XKMS – XML Key Management System

a. XKMS supports the registration, subscription, and management of keyswithin a SOA/web-services environment. It can be used to manage publickey certificates – performing functions such as certificate issuance,processing, validation, revocation, status checking, etc. As a result, thesefunctions could be provided by external 3 rd-party service providers (via theinternet). In summary, with XKMS, dealing with public keys is much morefeasible and less expensive (assuming that XKMS servers/providers areavailable and used by the IT/healthcare industry).

It should be noted that not all of these specifications (above) are finalized and adoptedby the vendor community. The good news is that the critical standards such as WS-

Security, SAML, and to some degree, WS-Federation, are mature enough that vendorshave implemented these. Indeed, WS-Security and SAML, as well as a relatedinteroperability specification (WS-I Basic Security Profile v1.0), have been adopted byall the major vendors. As a result, WS-Security and SAML give you the tools you needtoday to achieve most any security-related requirements in the context of SOA-enabledapplications and enterprises.




Figure 2 – SOA-Related Security Standards Overview:




Appendix C: Security Assessment Questions

Here is a list of questions to help characterize your security “status quo” andneeds:

1. Do you need to provide strong protection against all the major types of onlinethreats, including new and emerging blended threats?

2. Do you need to be able to automate the process of filtering and analysis of your massive audit log files, so that you could focus your attention quickly on the mostimportant security events?

3. How do you currently manage your user identities and their access to key ITresources centrally, so that you could improve overall security and reduce your ITadministrative expenses?

4. Do you need to provide automated proof to your IT auditors that your securitycontrols are working effectively?

5. Do you have strong, centralized policies for who can access each file or resourceon your servers (e.g. database tables, application servers, backup devices, etc.)?

6. How do you currently control the access of your super users, so that they can

only access the resources required to do their jobs?7. Does IT know who has access to what, what they did and when they did it?

8. How do you currently manage your access policies? This includes systems,applications (both Web and non-Web), files and databases. Can this be doneacross all platforms, including mainframes?

9. How do you currently provision and de-provision your employees and contractors? How long does it take and what resources (skills, time, people) does itrequire ? Do you have “ghost accounts” that are no longer used?

10.How do you collect, aggregate, and report on security-related events (logins,logouts, accessing sensitive data, etc.), and can you transform this data intoactionable business intelligence? Can this information be used to detect andresolve security breaches?

11.Are audit trails available for tracking regulatory compliance?




12.Is there an automated process for discovering, tracking and remediatingvulnerabilities detected on all systems in the IT infrastructure?

13.Is the latest worm or virus outbreak affecting critical assets?

14.Can appropriate actions be taken based on the information coming in fromfirewalls, antivirus solutions and other security devices?

15.To safeguard valuable and sensitive information is there a way to managethe use of devices such as flash memory keys or external hard drives?

16.Is the agency adequately protected against the spread of spyware?

17.Is user productivity impacted by excessive amounts of spam?

18.Are employees and other users using IT resources for non-business purposes?

19.Are you protecting the privacy of sensitive data in your databases?

20.Are you protecting the privacy of sensitive data as it gets passed betweencomputers (intranet or internet)?

21.Are you protecting the privacy of sensitive data that is backed up to tape or disk?




End Notes




1 MITA Security and Privacy Model. Excerpted from MITA Framework 2.0 – ApplicationArchitecture (Chapter 7), page 38, March, 2006. Author: Center for Medicare and MedicaidServices.

2 MITA PSTG Technical Architecture Committee; PSTG MITA TAC Security Overview-Technical Functions and Services. August, 2008.

mita-publichealthit-security privacy wp final

Documents