Maksim Kabakou - Fotolia
Security Think Tank: How to achieve software hygiene
What is the most practical and cost-effective way for organisations to identify and remediate high-risk software vulnerabilities?
All software is, by nature, susceptible to vulnerabilities. This becomes greater the more you customise, hone, develop and share it, especially if developers are not following a trusted development methodology and using guidance from organisations such as The Open Web Application Security Project (OWASP).
I recently read the report by Rapid 7 – Under the Hoodie – which was discussed here in Computer Weekly. I can’t say I was very surprised by some of the findings, such as that only 16% of companies investigated were clear of vulnerabilities that attackers could use to gain access to IT systems.
Studies show that most attacks exploit a vulnerability that has been known about for over a year. Indeed, a wide range of security reports and surveys have been telling us for many years that organisations are not patching effectively, among a range of basic failings.
If you want some proof, then look at what happened with WannaCry and NotPetya – after the first round of infection, patches were issued to cover the legacy vulnerabilities that were being targeted, but organisations failed to use them, and guess what happened?
For me, this indicates a couple of things. First, those organisations were probably not aware that the assets in question were built on platforms no longer supported or patched.
Second, as much as you try to help, the need for increased software hygiene has to be recognised and driven by the organisation itself. If an outdated platform issues you a patch, but you don’t realise its relevance and act on it, then your security issues go beyond superficial.
How to improve software hygiene
So let’s talking about being better. The first things to consider when improving matters would be:
- A more effective patching regime and improved patching hygiene. The easiest and simplest way would be to start with known vulnerabilities.
- Next would be to move away from the outdated methodology of annual penetration testing. Regular informal vulnerability assessments should be conducted by IT staff as an integrated part of their change and configuration management process. This would mean changes to installations, configuration or privilege escalations could be quickly identified and easily remediated. External penetration testing needs to be commissioned more intelligently and scheduled according to risk profile.
- Organisations need to get a better understanding of their key information assets and they should be sensibly configured and segmented, with more critical or valuable information assets being given additional protection.
- Finally, stop forcing users to change their passwords every 30 days. Instead, start educating users with quality, role-specific training, so they become part of the solution rather than being considered as the security problem.
When it comes to software vulnerability, yes, there will always be those who seek to exploit them, but we don’t have to make it easy for them. We need to start working smarter with what we have and get our arms around all of our information assets. Don’t let how you have always done it dictate the way you always will.
Read more from the Computer Weekly Security Think Tank about managing software vulnerabilities
