Wednesday, October 24, 2012
OWASP and AIIM: Building Security into ECM
Many people know that I am passionate about building security into enterprise applications. One of the biggest gaps in the marketplace in this regard is in the Enterprise Content Management (ECM) space. I had the opportunity to talk with Laurence Hart, CIO of AIIM regarding three use-cases that I think OWASP and AIIM could work together to help make ECM platforms more secure...
Entitlements Management
Consider the scenario of how a BPM and ECM platform should work together in an insurance claims architecture. It is fair and reasonable to think that the BPM platform should handle all user interactions related to process including whom next in the process needs to take action. In scenarios where you have a high profile person you are working the case, you may want to define a BPM flow that flags the process with special handling flags.
The ECM system should store content related to the claims process. This could be photographs, notes, investigation reports, etc. Ideally, the ECM system should maintain a logical record identifier that allows for correlation to the BPM workflow. Interestingly enough, ECM systems will attempt to implement their own security that is separate and distinct from the necessary security built into the BPM workflow AND provide zero ability to syncronize them.
Want do you think will happen if the BPM and ECM system have different notions of what to protect? Imagine the scenario of Barack Obama and Paris Hilton getting into an auto accident and you can see how important it may be for ECM to have the ability to externalize its security model in order to remain secure.
User Stores
Bex Huff of ECM fame and formerly of Stellent and I had an blog exchange almost five years ago where we equally noted that it is a best practice for ECM platforms to store content and not users. This becomes especially important in scenarios where the enterprise may want consumers to retrieve content directly.
ECM platforms whenever possible should have deeper interactions with directory services. In scenarios where they still need to know who the user is, they should implement standards-based services that allow for the provisioning of these users. The OASIS SPML specification works perfectly in this scenario.
Service-Oriented Security
Many ECM platforms expose web services that allows applications to retrieve and/or manipulate content. Within a web services architecture, there are three levels of security protection that are typically considered.
The first is to ensure that all sensitive communications occur over a secure channel. This could be SSL, Identity-Based Encryption or other mechanisms. What is important is that there is no layer in the architecture that permits any form of snooping. There are more than a few ECM platforms that run their services in a distinct process from the native engine, affording the opportunity for an attakcer to exploit this vulnerability.
The second is to avoid using weak schemes such as username/password in lieu of choosing a stronger mechanism such as the OASIS SAML protocol. In this scenario, ECM platforms would need to come out of the box as SAML Relying Parties (RP). The third mechanism is relatively straightforward in that much of good security starts with proper input validation. Sadly, in this regard there isn't much different in a web-based SQL injection attack and an equivalent ECM Document Query Language injection attack.
It is a web-services security best practice to perform input validation. One of the ways this can be accomplished is by specifiying validation criteria in XML schema. Sadly, there are no great ways in ECM products to even define what valid content even looks like. You know those metadata fields, they can contain anything and everything. The same thing can we said for much of the XML elements defined by most ECM web services.
| | View blog reactionsEntitlements Management
Consider the scenario of how a BPM and ECM platform should work together in an insurance claims architecture. It is fair and reasonable to think that the BPM platform should handle all user interactions related to process including whom next in the process needs to take action. In scenarios where you have a high profile person you are working the case, you may want to define a BPM flow that flags the process with special handling flags.
The ECM system should store content related to the claims process. This could be photographs, notes, investigation reports, etc. Ideally, the ECM system should maintain a logical record identifier that allows for correlation to the BPM workflow. Interestingly enough, ECM systems will attempt to implement their own security that is separate and distinct from the necessary security built into the BPM workflow AND provide zero ability to syncronize them.
Want do you think will happen if the BPM and ECM system have different notions of what to protect? Imagine the scenario of Barack Obama and Paris Hilton getting into an auto accident and you can see how important it may be for ECM to have the ability to externalize its security model in order to remain secure.
User Stores
Bex Huff of ECM fame and formerly of Stellent and I had an blog exchange almost five years ago where we equally noted that it is a best practice for ECM platforms to store content and not users. This becomes especially important in scenarios where the enterprise may want consumers to retrieve content directly.
ECM platforms whenever possible should have deeper interactions with directory services. In scenarios where they still need to know who the user is, they should implement standards-based services that allow for the provisioning of these users. The OASIS SPML specification works perfectly in this scenario.
Service-Oriented Security
Many ECM platforms expose web services that allows applications to retrieve and/or manipulate content. Within a web services architecture, there are three levels of security protection that are typically considered.
The first is to ensure that all sensitive communications occur over a secure channel. This could be SSL, Identity-Based Encryption or other mechanisms. What is important is that there is no layer in the architecture that permits any form of snooping. There are more than a few ECM platforms that run their services in a distinct process from the native engine, affording the opportunity for an attakcer to exploit this vulnerability.
The second is to avoid using weak schemes such as username/password in lieu of choosing a stronger mechanism such as the OASIS SAML protocol. In this scenario, ECM platforms would need to come out of the box as SAML Relying Parties (RP). The third mechanism is relatively straightforward in that much of good security starts with proper input validation. Sadly, in this regard there isn't much different in a web-based SQL injection attack and an equivalent ECM Document Query Language injection attack.
It is a web-services security best practice to perform input validation. One of the ways this can be accomplished is by specifiying validation criteria in XML schema. Sadly, there are no great ways in ECM products to even define what valid content even looks like. You know those metadata fields, they can contain anything and everything. The same thing can we said for much of the XML elements defined by most ECM web services.
