Back in December, James asked a few good questions regarding CMIS. I thought I would take a minute to answer them as best I could, with apologies for the delay. Any insight into making my answers more complete are welcome. I am only on the outside looking into the process.
The Endless Security Cycle
I have been thinking about how to write this post for a while now. I have several approaches to choose from, but then I hit on the key concept. It doesn’t matter. Here is the general pattern of James’ approach to this topic.
- James will criticize ECM security as a whole and then point to one or more issues.
- I then attempt to explain why those key “issues” aren’t issues.
- James will then elaborate or comment on my post in one or more follow-ups, usually explaining something that I didn’t put in my post for one or more reasons. In the case in point, I didn’t take it deep enough. While doing this, he ignores any defenses I may have made of the “issues”. He invariably bringing up other “issues” as well.
Rather than continue the cycle, and eat my time up, I’m going to post one more time on this topic and move on for now. Some disclaimers of my own:
DQL versus SQL
James has often compared DQL and SQL, assigning the security weaknesses of one to the other. While there may be valid concerns for some ECM query languages, DQL is actually fairly secure from this type of attack. Don’t get me wrong, it isn’t foolproof, but it isn’t an apples to apples comparison. Let’s compare and look. Be sure to add comments to question or add.
Secure ECM Systems
In my earlier post, I called James out on his post, which was a fairly biased statement about EMC’s testing for security, or lack thereof. In my post, I pointed out that the security warning did not warrant such an attack. I tried to point out that James wasn’t necessarily wrong in his statements, just that he didn’t provide any evidence that backed them up. He criticized their proactive efforts when the source material calls for a reactive effort.
Well, James replied to me in two subsequent posts. The first post endeavored to teach me about the importance of testing for security in systems proactively. It wasn’t a lesson that I needed, having heard of the SQL Injection attack back in the 90s as a weakness in ASP applications (or at least an attack that was fairly similar). Being aware of these issues, I’ve make a point of controlling what a user can do in interfaces.
His points are valid though, so I wanted to take time to talk about them. This is my first post in a series addressing the points he brings up. So if I don’t address something now, don’t worry it’ll come.
Inciting Insight or Panic?
Normally when I read a post by James McGovern, I understand that he is trying to get under people’s skins in order to provoke a response. Some people respond to this by attempting to give the type of information that James is looking for in a post of their own. Others view it as a form of harassment and try their best to ignore it, though James just looks on that as a form of encouragement. Both reactions are perfectly fine.
I, and pretty much every blogger, are not compensated for writing our blogs, much less for responding to James. It is optional. When I blog, I do so as me, myself, and I. Not as an employee of any company or organization.