So often when we talk about software security we discuss things like encryption, authentication, authorization, etc. But there is another level of security that is equally harmful, especially in mission critical systems.
Unfortunately this software security concern is much more difficult to identify, analyze and mitigate. It has to do with badly architected and/or designed and/or written software that can cause network degradation and then denial of service.
Consider some examples:
- Using synchronous based architecture where an asynchronous approach would be better suited.
- Using an asynchronous architecture when a synchronous approach might be better suited.
- Using badly defined interfaces that cause unnecessary network traffic. (Fine grained Vs course grained interfaces).
- Opening up a system designed for use on a LAN to users across a WAN without examining the type of network traffic expected due to the interface design.
- Bad configuration that allows unnecessarily large call retries or allows high call blocking durations.
- Or simply memory leaks in a badly written client or server.
All of these problems with the way the software was either architected or designed or written could cause serious security problems.
Obviously detecting these potential security problems takes more than the traditional security policies that we spend so many dollars on each year. As the internet becomes more pervasive and integration of services across departments and agencies and companies becomes more pervasive then the integrity of your “business” partners code and of course your own code becomes a major risk concern.
And that is basically what we’re taking about here – software integrity as it relates to security risk in a distributed system.
So what approaches can you take? Well first off you could define best practices for use of technology and architectural approaches and design and coding standards. But also you must be able to enforce these policies and best practices. That involves examining code. And that’s not so easy. Tools could be developed to analyze code in a more automated way to identify specific patterns. But in the end a highly experienced QA department with engineers and architects is also required. However often these are the folks you need actually building the system.
One thing is for sure - this is going to become an increasingly big issue - consider the off-shoring practice.
Suggestions and/or comments welcome.