Fulfilling non-functional requirements with patterns and best practices
By Randall Nagy
One of the great benefits of developing software properly the first time, using proven patterns and sound best practices, is the fact that while addressing the core requirements in the software, many of the non-functional requirements get preliminarily addressed as well.
A rocket scientist once patiently explained to a new software developer why a precise starting point is important. Pointing to an imaginary celestial body he said "even one degree of error will make us completely miss our target." In a like manner, someone else added, "when we do things exactly right, even unexpected things just seem to work out properly." And so it is with service orientation and security: when we design our services right, non-functional requirements, like security, often take care of themselves.
Unintended, yet beneficial, consequences
A standard best practice for service oriented software delivery is to provide multiple ways of representing a response unit to clients. Interestingly, this best-practice, which is intended to improve the quality of web service delivery, also has the unintended benefit of improving the security of the applications we develop.
Imagine application security from the point of view of a potential miscreant: understand that designing a simple, single, stateless request or response unit, classically call an RU, easily provides an all-in-one cypher to would be system attackers. Things can even get worse when a single-page key is used. While the interception of 100 HTTPS RUs might be tough to break, having 1,000,000 can make certificate reverse-engineering a lot easier.
Indeed, the first rule of cypher-cracking is to have common, recurring patterns to look for. Therefore, sending the exact same metadata to a requests over and over again might be something to avoid. All one needs to break a cypher, after all, are enough common keywords to look for in something like a anticipated, standard, SOAP envelope. Put enough of those tokens in the exact same location each time, and one might as well not encrypt anything at all.
So even from a security standpoint, providing two ways of representing an RU is far better than providing only one. Therefore, the practice of providing more than two ways of representing any single service request, even to the exact same service, should be considered a security best-practice. Providing multiple certificates does not harm anything, except perhaps caching and performance, either. In many ways, providing support for multiple, varying RU encodings is merely a simple extension of proper service version control (SVC).
Indeed, after we open ourselves to the prospect of submitting many RU versions to the same service, over time data transmission tends to become a tad more secure, demonstrating that when applications are properly designed using patterns and best practices, many non-functional requirements will take care of themselves.
Let us knowabout your strategies for handling non-functional requirements.
07 Jun 2013
Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.