Lyal Collins is a Loop security expert specializing in PCI-DSS matters. He advises Loop clients on PCI compliance and other security challenges. This is the first in a series of posts where Lyal talks about some of the eternal challenges in managing information security. If you have a question for Lyal, please email info@looptech.com.au .
Eternal challenges in Information Security
Across 20+ years in the Information Security space, in operational security roles, project security roles and compliance assessing roles, I have witnessed the continual struggle organisations face in maintaining effective security controls from both the security management and compliance aspects.
Keeping software and firmware up to date with all current security patches is one of the “eternal issues” I perceive to exist. To deal with this important issue, it is necessary for every organisation to have a thought-through plan in place that will enable the right prioritisation and application of patches across the enterprise in a timely manner.
As an example, consider the recent update to the PCI Data Security Standard (PCI DSS 3.1). Among several minor changes, the updates include a requirement to migrate to recent versions of a well tested and analysed security protocol – Transport layer Security (TLS) Version 1.2 in place of the venerable and commonly used Secure Socket Layer or SSL.
SSL emerged in the early 1990s, and has undergone significant security evaluations and critiques since then. Along the way, a number of security issues were identified, resulting in the evolution of SSL to Version 3.0, then the emergence of the successor protocol, Transport Layer Security, which has evolved from TLS Version 1.0 to TLS V1.2 currently.
As you have no doubt seen in the security press, several serious weaknesses have been identified in SSL over the past few months. Some of these issues affect the early versions of TLS in addition to rendering SSL V3.0 and earlier ineffectual in protecting against even moderately skilled attackers.
What exacerbates the problem is that SSL and TLS support is embedded in virtually all modern web servers, all modern browsers, and most recent web clients.
A few moments reflection on the magnitude of this issue across the ‘typical organisation’ shows that reconfiguring SSL is not a trivial “change a setting” problem. SSL and or TLS is used extensively across most organisations –
Browser versions
VPN remote access clients
Logging and monitoring solutions
AV update servers
Administration consoles on servers, firewalls, databases
Load balancers
“Light out” management interfaces on hardware.
Potentially, dozens or hundreds of software and firmware patches will be needed across most organisations. Developing, testing and deploying these changes is not trivial. External facing web sites and web payment applications have a significantly higher threat which many organisations can patch or upgrade within a few days or weeks.
I’d take a wild guess and expect (hope) many, if not most external facing Apache based web servers, IIS-based web applications and OpenSSL-based applications to be patched or re-configured by now.
Organisations with mature operational security approaches will have probably mitigated these external facing SSL based threats by now.
You might ask – why write this post if the individual problem is already largely fixed – or fixable?
Simply, many of the clients I have worked with have outsourced some or all of their infrastructure and IT environment. It is sometimes difficult for the outsourcer or hosting provider and their client to have a common understanding of the urgency of applying patches – or in some cases for the outsourcer/hosting provider to even know what patching their client requires. This is simply an extension of a deeper problem I regularly experience in outsourced environments; namely, the lack of a common understanding of the respective obligations and expectations of the other party (i.e. the client or the provider) in delivering the agreed services. It is common that the sales cycle promises more than the legal team include in the contract – but that is a story for another day!
As a result, I find that several questions always get asked during assessment engagements where outsourcing is involved:
Have you prioritised the released patches, based on relevance and security impact to your organisation (and or your clients)?
Do you AND your hosting providers have a clear and effective process for patching all components relevant to your environment? Does it need improving? Do you conduct periodic assessments or audits of patching levels?
If you are a hosting provider – are you effective in managing your patching obligations for your clients?
Having proactive processes in place addressing these questions is a positive boost to the security maturity of your organisation. Along the way, contract compliance and ISO/PCI/SOX/HIPAA compliance are usually enhanced as well.
I know – this is not trivial. But patching is fundamental operational security management. Getting the process right, operationally, and the appropriate language into contracts and agreements is critical to controlling security, costs and compliance. A risk based proactive approach to patching, with a shared understanding of the operational plan can go a long way toward dealing with this eternal security challenge.
