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:
- I no longer work for a vendor, and I never did on the development side of the house for an ECM vendor. (I was a hired-gun for PC DOCS in the late 90s). My job is to architect and deliver solutions that are secure, fast, and scalable. When I find a problem, I let the vendor know and work around it. When I find a cool solution that I can share contractually, you’ll see it.
- I am not writing a manual here. This isn’t a wiki where I am going to come back and update things. This is basically a long series of articles. Due to time and space, I don’t put everything down in detail. I understand that my readers have to take the time to read everything, and I’m sure not going to write something that seems too long, like these disclaimers.
That being said…
Do Your Best
James is right. I’m not a big fan of his tactics at times, but his basic message is important. Security is important. You can’t always point to a return on the investment, but when it goes wrong, it is too late.
You try and test for the unexpected. That means architects banging on the system just to see what they can do. That means using testing automation software when the scenarios start to get out of hand. That means testing on as many different platforms and configurations as possible.
If a product has a bug, which is what a security issue is when you get down to it, it means that the tests missed something. It doesn’t necessarily mean that the testing was poor or treated as unimportant. It means that the developers and testers weren’t all-knowing and missed something. If lots of bugs and security issues pop-up, then you question the entire process and the commitment.
The bigger the system, the more bugs that will be found. A committed vendor can improve its testing at a rate at least equal to the growth of the product. There will be bad releases. The question is, do they continue to be that bad or does the vendor improve?
If nobody finds a security hole or bug in the real world, that means that nobody is using the system. Simple as that. The vendor can do all the right things, but there are so many quirks out there in the “wild” that they’ll never get them all.
When a bug was found in the “wild”, back in the day, we would identify it, fix it, and add tests to catch it in the future. We would also look for similar bugs. Usually for every bug that someone reported, we would find one or two more that we could catch and fix before anyone encountered them.
Making a secure and stable product is a process that never ends. The only products that release with no bugs or security flaws aren’t growing and are in maintenance mode.
Minor Little Detail on DFS
The DFS SDK now includes a.NET productivity layer (consumer library) for development of .NET-based DFS consumers. The .NET productivity layer is functionally equivalent to the Java productivity layer, with the exception that a .NET client can consume DFS services only remotely (as web services).
The DFS .NET productivity layer is Common Language Specification (CLS) compliant; therefore, you are free to develop above DFS using your CLS-compliant language of choice (e.g. C#, VB.NET, Managed C++, even IronRuby, IronPython, etc.). Samples of C# DFS consumers are provided in the SDK as well as new XML Documentation (i.e. C# equivalent to Java’s Javadoc) and HTML Help (.chm) documentation.
DFS service development tools have been enhanced to provide a facility for generating CLS-compliant .NET productivity layer support for your won services, too. The DFS .NET productivity layer is based on Microsoft’s Windows Communication Foundation (WCF) framework within .NET 3.0.
James, it is a development TOOL designed to help .NET developers more quickly develop DFS based applications. There is no actual change to DFS itself in relation to this feature. Calls could be made to DFS from .NET before this latest release. The difference is that before everything had to be built manually.
EMC is just trying to make life easier for developers.
On Abuse in the Blogsphere
I just want to let James know that I don’t feel abused. I said that in jest. If I truly felt abused, I’d be done.
I would have been done a while ago for his constant attacks on Craig Randall, blaming him for every ECM issue and taking him to task for not responding. Others have called it a day . I keep reading to try and call James to task on some of the things he posts and because I do learn some things outside of the ECM world. Eventually, that may not be enough motivation to keep reading.
James, please start to challenge and question people without insulting. If you don’t, you may find yourself yelling into the void and not get any response. It is your blog and your right to use it as you will. Just remember, we respond and interact at our will.