Sunday, February 10, 2008
ECM and Insecurity
Laurence Hart called me out on security within the world of ECM and I figured I would take this as an opportunity to help the ECM community deeply understand why their solutions are insecure...
Before I get started, it is important to acknowledge a few things before we get into details.
1. Neither my day job nor night has anything to do with ECM and therefore one cannot assume that I am indoctrinated into certain ECM nomenclature. I may not use the right terminology but the concept is still applicable.
2. My thoughts aren't specific to any one vendor, but with a few exception apply to every single ECM vendor. I believe that ECM as a domain when viewed through a security lens, is weaker than BPM, ERP, ESB and CRM vendors combined.
3. One should never attempt to understand why I post. It is almost guaranteed that you will get it twisted if you think I am doing so just to get under people's skins in order to provoke a response. The only response I am truly interested in is for software vendors to make the security of their products better. If they respond to me in order to have a dialog, that is fine. If they choose to exercise their right to remain silent then that too is fine. As an agilist, I believe that high quality secure working software is the primary measure of progress...
With all of this being said, let me attempt to respond to Laurence. First, Laurence uses an example of how quickly a particular vulnerability was patched but this isn't a holistic view of security. Consider that patching tends to be reactive where much of what I discuss requires one to be proactive.
Put yourself in the shoes of a customer. Would you rather have a vendor that reactively patches software or proactively changes the design of their product to meet future needs. Bex Huff talked about an ECM should store content and not users. If we acknowledge this to be a good thing for security reasons, then if an ECM products underlying design doesn't support this notion, then can we really say that are responsible for being thoughtful about security if the product doesn't actually change?
Sure, we can copy data via synchronization mechanisms but we have to acknowledge that anytime latency is introduced into a solution that it exposes a window of opportunity for attack. The key thing I can say is that John Newton publicly acknowledged this flaw in the design of his product yet didn't bury his head in the sand as he is genuinely interested in understanding how to make his product better. Now if only others did the same.
Laurence, have you ever heard of SQL Injection attacks? The world of ECM needs to understand the clever indoctrination and renaming of SQL (with a few features piled on) is somewhat delusional. If Oracle came up with OQL, Nuxeo with NQL and Alfresco with AQL, at the end of the day it is still SQL that when exposed as a web service makes security weaker.
The key takeway is that a Java developer would never allow unvalidated input to traverse to the backend, yet that is exactly what ECM developers do all the time. If you aren't familar with SQL Injections check out the OWASP Example. Did you happen to notice the notion of PreparedStatement being horrific? One of the approaches to making this secure is to consider usage of stored procedures and to minimally validate incoming input. Can I validate on the client-side whether the ECM query language is valid or am I required to send it to the backend? How do I do the equivalent of a stored procedure in the world of ECM?
My third thought says that SOA in ECM is also insecure in that it minimally violates SOA principles. Can we agree that a consumer shouldn't know what language the producer is implemented in? Can we say that holds true in the world of ECM? I think we all know the answer.
If you study the WSDL from many of these products, they also violate another security principle in that for a SOAP fault, many of them actually return the Java stack trace. To understand why this is fugly, please check out the Common Weakness Enumeration as this is classified as a system information leak. It has CWE ID 497 if you want to read in more detail.
Laurence, this posting is getting kinda long and I will answer the remaining questions shortly. I appreciate the dialog with you and your passion for serving the community. I do hope that others will also participate in this important conversation you have started...
| | View blog reactionsBefore I get started, it is important to acknowledge a few things before we get into details.
1. Neither my day job nor night has anything to do with ECM and therefore one cannot assume that I am indoctrinated into certain ECM nomenclature. I may not use the right terminology but the concept is still applicable.
2. My thoughts aren't specific to any one vendor, but with a few exception apply to every single ECM vendor. I believe that ECM as a domain when viewed through a security lens, is weaker than BPM, ERP, ESB and CRM vendors combined.
3. One should never attempt to understand why I post. It is almost guaranteed that you will get it twisted if you think I am doing so just to get under people's skins in order to provoke a response. The only response I am truly interested in is for software vendors to make the security of their products better. If they respond to me in order to have a dialog, that is fine. If they choose to exercise their right to remain silent then that too is fine. As an agilist, I believe that high quality secure working software is the primary measure of progress...
With all of this being said, let me attempt to respond to Laurence. First, Laurence uses an example of how quickly a particular vulnerability was patched but this isn't a holistic view of security. Consider that patching tends to be reactive where much of what I discuss requires one to be proactive.
Put yourself in the shoes of a customer. Would you rather have a vendor that reactively patches software or proactively changes the design of their product to meet future needs. Bex Huff talked about an ECM should store content and not users. If we acknowledge this to be a good thing for security reasons, then if an ECM products underlying design doesn't support this notion, then can we really say that are responsible for being thoughtful about security if the product doesn't actually change?
Sure, we can copy data via synchronization mechanisms but we have to acknowledge that anytime latency is introduced into a solution that it exposes a window of opportunity for attack. The key thing I can say is that John Newton publicly acknowledged this flaw in the design of his product yet didn't bury his head in the sand as he is genuinely interested in understanding how to make his product better. Now if only others did the same.
Laurence, have you ever heard of SQL Injection attacks? The world of ECM needs to understand the clever indoctrination and renaming of SQL (with a few features piled on) is somewhat delusional. If Oracle came up with OQL, Nuxeo with NQL and Alfresco with AQL, at the end of the day it is still SQL that when exposed as a web service makes security weaker.
The key takeway is that a Java developer would never allow unvalidated input to traverse to the backend, yet that is exactly what ECM developers do all the time. If you aren't familar with SQL Injections check out the OWASP Example. Did you happen to notice the notion of PreparedStatement being horrific? One of the approaches to making this secure is to consider usage of stored procedures and to minimally validate incoming input. Can I validate on the client-side whether the ECM query language is valid or am I required to send it to the backend? How do I do the equivalent of a stored procedure in the world of ECM?
My third thought says that SOA in ECM is also insecure in that it minimally violates SOA principles. Can we agree that a consumer shouldn't know what language the producer is implemented in? Can we say that holds true in the world of ECM? I think we all know the answer.
If you study the WSDL from many of these products, they also violate another security principle in that for a SOAP fault, many of them actually return the Java stack trace. To understand why this is fugly, please check out the Common Weakness Enumeration as this is classified as a system information leak. It has CWE ID 497 if you want to read in more detail.
Laurence, this posting is getting kinda long and I will answer the remaining questions shortly. I appreciate the dialog with you and your passion for serving the community. I do hope that others will also participate in this important conversation you have started...
