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.
Tuesday, October 23, 2012
Should Business Analysts capture more than functional requirements?
To the question of whether a business analyst should solely capture functional requirements, I scream emphatically NO! It is important to understand that if we want to build secure software, we information security professionals need to encourage business analysts to think beyond functional requirements and start focusing on proper methods in capturing security requirements as well.
Let's face it, if we know that the quality assurance process starts with analysis of business requirements in order to generate test cases, then why aren't we helping business analysts capture them?
As a participant in the Open Web Application Security Project (OWASP) and chapter leader in the Hartford CT area, I have been savage in helping more than just architects and developers understand the value proposition in making security visible. Awhile back, I held a meeting with the ISACA community in order to provide insights into better ways to audit web applications.
On Wednesday, October 24th 2012, I will be speaking at the Hartford Chapter of the International Institute of Business Analyts on capturing security requirements. It is my plan to talk about requirements around identity, provisioning, authorization and entitlements and of course privacy. I plan on talking about this in context of use-cases and threat modeling such that they can connect the concepts to something they are familiar with. I will conclude with an overview of the OWASP Risk Rating methodology such that the business analyst community can aid in properly priortizing security requirements relative to others.
I sometimes think I am alone in the wildnerness with my thoughts. I am hoping that a few bright people in the OWASP community will see the value proposition of bringing our sage wisdom to other communities and do their part in making security visible to all participants in the IT ecosystem...
| | View blog reactionsLet's face it, if we know that the quality assurance process starts with analysis of business requirements in order to generate test cases, then why aren't we helping business analysts capture them?
As a participant in the Open Web Application Security Project (OWASP) and chapter leader in the Hartford CT area, I have been savage in helping more than just architects and developers understand the value proposition in making security visible. Awhile back, I held a meeting with the ISACA community in order to provide insights into better ways to audit web applications.
On Wednesday, October 24th 2012, I will be speaking at the Hartford Chapter of the International Institute of Business Analyts on capturing security requirements. It is my plan to talk about requirements around identity, provisioning, authorization and entitlements and of course privacy. I plan on talking about this in context of use-cases and threat modeling such that they can connect the concepts to something they are familiar with. I will conclude with an overview of the OWASP Risk Rating methodology such that the business analyst community can aid in properly priortizing security requirements relative to others.
I sometimes think I am alone in the wildnerness with my thoughts. I am hoping that a few bright people in the OWASP community will see the value proposition of bringing our sage wisdom to other communities and do their part in making security visible to all participants in the IT ecosystem...
