Security Vendor Management

Yesterday, I shared my thoughts on the steps that I believe CIOs should consider when planning for security processes and technology standards.
 
Today, I wanted to outline some further thoughts that Pure Hacking has had to raise the security benchmark for Australian organisations. These ideas relate to software and ensuring that CIOs know what is being developed, implemented and tested. To put it more bluntly, you need a better understanding of what you aren’t paying for in many cases.
 
At some point in the career of a CIO, it is realistic to expect that you will be responsible for implementing a software solution already commercially available or developing a software solution that meets specific requirements. In days gone by, vendor contracts outlined the implementation periods, training, support and ongoing licensing arrangements. However, if we step back a step and consider security, who is responsible for this?
 
It’s tempting to think the vendor or developer is responsible for specifying security requirements.  Ultimately, it’s not their responsibility. It’s the CIOs. Vendors and developers are not obliged to produce a piece of software that is secure if the contract doesn’t state this.  They certainly would not if the budget doesn’t warrant it.
 
In light of the popularity of recent attacks, you should expect your own clients to start demanding more information from you about your security policies and procedures (and possibly including it in contracts with you).
 
Here are some recommendations about negotiating with software vendors and developers:
 

• Contract Negotiation - 

  When finalising the development or implementation contract, look long and hard at the approach to security. Insert a specific clause in the contract of sale to scope out the level of security being provided.  Include a penalty clause if the guarantee isn’t met. It is advisable to specify the business requirement for security as it is not the developer or vendor’s responsibility to add functionality at no further cost at a later date. Scope out the benefits of adding security layers to the development process and factor in any additional or unplanned costs, or understand the financial and business risks associated with not including robust security layers to your own business;

• Be aware of Industry Standards -

  Security standards such as the Open Software Assurance Maturity Model (OpenSAMM) is clear in outlining the security controls required in software. They are defined properly for each organisation and are entirely flexible.  OpenSAMM is a highly transparent guide for organisations to follow; and

• Software Testing -

  Make sure that a security specialist tests your software. This specialist can be in-house to the developer or vendor.  Perhaps you have an internal software specialist that is professionally qualified to perform these security tests. Alternatively, you should have an independent third party undertake penetration testing. This is the ideal acid test to determine whether remote attackers can manipulate your software.

Whatever approach you decide to take as a CIO, there are two items that I need to emphasise. Firstly, quality security costs money.  If you are buying a cheap piece of software, you should seriously consider the pros and cons of that software. A cheap piece of software may have been developed by cutting corners and not including adequate security. Secondly, customers are beginning to ask about security policies. They call me and ask me what they should be asking you.  You need to begin formulating a strategy around policy, standards, and guidelines.