Security professionals need to work tirelessly to ensure that, when projects are mooted – that is before the project is actually funded – they are well and truly plugged into the purchasing and/or tendering processes writes Peter Wenham.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
It does not matter if software code is to be created in-house or purchased from or developed by an external supplier. Where code is to be developed externally, the security professional needs to ensure that clauses are included in the contract of supply that call for the code to be developed using current accepted industry good practices for the delivery of secure code and outlining the acceptance/rejection process for that developed code.
For internally developed code, the security professional should ensure that internal procedures call for code to be developed with security in mind and is well documented. On the project side, the security professional needs to ensure that all code received – regardless of whether it is bespoke, commercial of the shelf or internally generated – is passed through a “sheep-dip” process to test for viruses and malware.
Ideally the code should be checked by two different commercial antivirus products during this sheep-dip process. The security professional should also ensure the project allows for a test environment where code can be run as if it were in production, to ensure it is well behaved and not doing anything that would compromise security.
Large and complex projects may well have multiple test environments to undertake basic testing, check integration with other project components, and test performance and user acceptance. Small projects may well have to rely on good and well documented back-out procedures so any received and sheep-dipped code can be run directly in production.
Read more about security procurement
Finally the security professional needs to ensure that any project has appropriate and effective mechanisms in place to reject faulty code, together with metrics that clearly define the accept/reject parameters which should tie back to a contract or internal project specification.
It should not be forgotten that an IT security health check of the system running the code is a worthwhile and arguably a necessary thing to do, but is not a substitute for other measures and should be considered rather as an “in addition to” measure.
Peter Wenham is a committee member of the BCS Security Forum strategic panel and director of information assurance consultancy Trusted Management.