Many IT systems are insecure, others are simply dangerous. Some people argue that this is because the vendors that develop them are ignorant. I think not. However, I do believe they like money. A quarterly report with great numbers is never wrong.
It costs 5-10% more to develop a secure system than a clumsy and insecure system. If the organisation making the system has never worked securely in the past the cost can be up to 25% more, but this rapidly decreases as the processes become embedded. Despite the cost, the investment is worthwhile because higher quality radically reduces downtime, successful hacker attacks and other ills. Not to mention fewer headaches.
When development is placed with an external provider, the problem is that you take the business risk while the supplier delivers to a specification. If security is not included in the specification, then security will not be delivered. Why would the supplier reduce their margins by 5-10%? If a provider includes security in the price when it hasn’t been requested, they may even lose the deal because the customer chooses a cheaper alternative.
There is only one solution. Include security requirements in the contract and follow them up. Believe me, you do not want software that does not meet at least the following:
- The system should not have any of the SANS 25 programming errors and, if it is a web application, it should not have any security holes in the OWASP Top 10.
- The supplier should specify which software components, including version numbers, are used to create the system.
- The supplier should use only standard methods for encryption and signing. All security-related documentation should be available on request.
- You should have the right to review the security system.
- The supplier should provide documentation on how the system has been installed, with a minimum of access rights to the operating system and what network traffic is necessary for the system to work in the particular environment.
- The supplier should indicate the update cycle.
- The supplier should be able to demonstrate how security is integrated into the system lifecycle.
- Depending on which comes first, the supplier should provide information on vulnerabilities detected in the system within thirty days or when an update is issued that resolves the problem.
- The system should log all events and comply with SIEM standards.
- The system should be able to identify and authenticate users and confirm eligibility. It should comply with open IAM standards.
Really, you should conduct a security analysis to ascertain the right level of security and cost framework. But the above points are a good start. Then you won’t be disappointed by system crashes or being pulverised by hackers. And you can happily throw the headache pills in the bin.