dangerous-bend
Security

Turning the Corner on Security: Beyond the Penetration Test

Major enterprises often rely heavily on third party suppliers to develop, test, and operate their software, even their most important applications. In such situations, penetration tests fit the contract model well: it is easy to insert a test as an acceptance gate during development and to prioritise its results, requiring the vendor to fix them prior to launch or the deployment of an update. Throughout Western Europe, enterprises have relied on outsourcing to third parties for years. We have ample data about the high cost and schedule delay that result from fixing defects that are found just prior to deployment. Enterprises are supplementing their penetration test strategy with activities that find defects earlier. They want to dramatically reduce the number and severity of what is found at the last minute.

The contractual model in place with third party software developers influences what security services can be applied. Approaches (like training, source code review, architecture analysis) that work when the enterprise owns the developer and its code must be delivered in a different way to address the arms-length relationship between the owner of the application and the vendors that build and operate it. Several techniques are being tried as contracts are renewed. Three worth mentioning are additional gates, vendor management, and contractual obligations.

Applying additional gates, such as architectural analysis and source code review, is now more practical than in years past. A variety of firms are able to deliver these activities as a service, meaning they can be plugged into a third party development lifecycle. The inputs and outputs are clear and there are tools to provide consistency and efficiency, much as in penetration testing. The advantage of these early lifecycle activities, though, is the lower cost of fixing security issues found during development.

Few Western European firms have hundreds or thousands of software developers on staff, so they have been forced to tackle the problem of vendor management early. Two valuable trends emerge: knowing your supplier and independent testing. Firms query software development suppliers on their methodologies, security controls, and security processes in the software lifecycle. This allows an informal and collaborative method of suggesting changes, standards, or security requirements. Another valuable technique in vendor management is to establish separate vendors performing development and testing. While development vendors will argue the cost efficiencies of having collocated and closely collaborating testers, there are many advantages to having a separate vendor testing the code. The independent tester acts as an advocate for the business with no conflict of interest arising from being under the same management as the developers. Independent testers also act as a convenient and capable collaborator for security activities. The independent testing formalises the transfer of development artefacts. Versions, deployment processes, project milestones and such must all be agreed by all parties. When security activities need documentation, testing environments, source code, etc., it will be more readily available because the developers already deliver regular, well-defined bundles to the independent testers.

Finally, contractual structures, as relationships, that are negotiated for the first time can make security obligations plain. One contractual technique is to define clear requirements for any “warranty period” in the software delivery: which issues must be fixed, at what priority, and at what cost. By establishing the requirement that, for example, failures corresponding to a “top ten” list must be fixed at no charge, the firm has contractual leverage with which to extract compliance. A second technique is to establish a “preferred supplier” list, based on specific criteria. Vendors might have to demonstrate a security training program for developers, commit to specific software security capabilities such as static code analysis tools, and provide evidence of software security activities like architecture risk analysis. Then the buying firm designates the most important projects as available only to “preferred suppliers”. This creates pressure among vendors to demonstrate their compliance with the supplier program while also giving them a competitive business advantage in return for their efforts.

These three approaches—software security gates, vendor management, and contractual enforcement—can be combined to varying degrees. Some firms will find contracts hard to alter, but gates easy to deploy. Others will prefer the soft touch of vendor management and relationships. The key is to establish a constructive and effective means for injecting security activities into a third party’s lifecycle. The goal is secure software, which all sides agree is worth the effort.

 

Paco Hope is Principal Consultant at Cigital

PREVIOUS ARTICLE

« The 5-Step Plan for a Successful Business Intelligence Program

NEXT ARTICLE

Sierra Leone Building the ICT of the Future »
Paco Hope

Paco Hope is Principal Consultant at Cigital

  • Mail

Recommended for You

How to (really) evaluate a developer's skillset

Adrian Bridgwater’s deconstruction & analysis of enterprise software

Unicorns are running free in the UK but Brexit poses a tough challenge

Trevor Clawson on the outlook for UK Tech startups

Cloudistics aims to trump Nutanix with 'superconvergence' play

Martin Veitch's inside track on today’s tech trends

Poll

Is your organization fully GDPR compliant?