There are a number of elements that relate to the early stages of the Software/System Development Lifecycle (SDLC) that should be considered in regards to security. Unfortunately, for a number of projects, our company becomes involved at the final stages of the process, which often results in highlighting a lack or ineffective due diligence at the early phases. It is difficult to manage a project where the software is found out to be inherintly insecure and often leads to excessive launch delays, greatly increased budget requirements for additional resolution or even an outright cancelling of an expensive project.
While many people hate the analogy of “buying a car” when it is applied to IT, it is actually particularly relevant for product selection. In both cases, you have to be wary of products being rebadged, inferior internals within the product, whether it performs well in a test drive, an inability to easily conduct ongoing maintenance and poor after-purchase support.
Surely if I bought a product from a large software vendor everything would be fine?
A product that carries the supposed weight of a large multinational corporate has absolutely no bearing on its quality. Keep in mind that large corporates typically tend to conduct company acquisitions today rather than gamble on developing a product from scratch internally. The quality of the product is usually directly dependent on the company who authored the software – whom you may not have even heard of.
How do I find some indication that it may be a secure product?
Attempt to find out, through searching yourself or via your vendor’s sales people, who created the original product and what the original name was if it has since changed. Attempt to find whitepapers, security advisories and other relevant information relating to the product. A complete lack of security advisories or vulnerability fixes within patch notes is a strong indicaton that the product simply has not been security tested.
Get your own system architects and administrators to examine the product installation guide and notes. This can provide insight into whether the software is maintained. In particular, the use of third party software, such as libraries, are usually documented along with their version numbers which may be correlated. In the event that they are not provided, they can usually be found through examination of a test software installation.
Security testing should be done at the end along with the other testing right?
It is amazing when contracts for a significant amount of money are signed simply on the promise of a working product. Get a proof of concept system built and see whether it even remotely conforms to your requirements. In addition, this is an excellent time to perform an initial security review to find the “show stopper” vulnerabilities, which may be resolved by the vendor in parallel to your own project work.
Just remember that while the customisations of a product may well impact the security of the overall solution, the fixes within the core of the product typically take the longest to resolve. It is a proactive approach to test a proof-of-concept installation, even if it’s only remotely indicative of the final result to find out if the product you are looking at is a “lemon”.
Depending on the size of the project, or more accurately – the potential profit to the vendor, it may be possible to even negotiate an approach to keep the cost of a security test low. We have been aware of interesting engagements which include the vendor paying for the test outright if any significant vulnerability is found to the vendor agreeing to pay for half the cost.
What restrictions may I have with ongoing maintenance with a particular product?
The answer to this is unfortunately fairly open-ended. A particular product may need system administrators to look after some of the software the product requires to run (“dependencies”) or it may provide everything itself. While the latter sounds appealing, it can become frustrating and outright dangerous if the vendor does not maintain the dependencies appropriately by releasing release updates in a timely manner. This is unfortunately rarely done. Work with your system administrators and architects to understand which components are provided by the vendor or yourselves.
What other things may impact security testing?
License agreements from larger vendors typically state that “reverse engineering” is not to be performed. Depending on the type of product, this could be an unfortuante restriction or it could greatly impact the depth of security testing. Where possible, the agreement should be amended to remove or reword that particular clause. If that is not possible, seek to get a written statement to specifically allow reverse engineering for security testing. Ensure this is sourced from an appropriate contact at the vendor, which may be from their legal team if they are a large corporate.
In an ideal world, the vendor will provide the source code to the application, and this is usually done in at least part if it is based on an “Open Source” solution. Having access to the application source code within a security review will always speed up testing and provide a deeper analysis.