Assuming your company has some sort of security policy in place to at least specify how often passwords should be changed, and what format they should take, how organised is it about evaluating how vulnerable your network is to security breaches and careless users?
Many vulnerabilities present on networks are the result of misconfigurations of one sort or another, be it not changing default passwords, setting firewall rules incorrectly or leaving Unix installations with default permission settings on files and directories that aren’t appropriate. There are obviously the inherent flaws and bugs in OS and network software that you can’t do anything about: however the greatest risk from these is usually after the bug has been publicly admitted or advertised and a patch issued, and before patches have actually been applied - poor patch management is a major contributor to the vulnerability of your systems.
Not disabling unnecessary and dangerous services, such as finger, whois, telnet etc adds greater risk than needs to be present. If you do have to have some of these services, tuning them to tighten security can reduce your exposure.
And finally users, both the ones you do want on your network and the ones you don’t. Keeping out unauthorised intruders is basic - but so is protecting the network against your valid users, by controlling what they are and are not allowed to do, so that if they do harbour a grudge - or are just careless - their actions have a limited effect.
Why manage vulnerabilities?
If you do have a security policy, why do you need a vulnerability one too? Managing security means setting rules in place to control things like password control, remote access procedures and safeguards, anti-virus policies and acceptable use of email and web resources. Vulnerability management, on the other hand, means continually and consistently monitoring your network to determine if there are risk areas. By having a vulnerability policy, you are making this risk assessment part of a business-driven process, not a one-off project you pay a consultant to come in and write a report on once every couple of years, or when the auditors ask to see something.
As the number of attacks and attackers grows, the only way to reduce the potential impact on your business is to reduce the vulnerabilities. While many companies do carry out some ad-hoc form of vulnerability assessment, this tends to be pretty fragmented. Port scans, for instance, are one of the most common checks run, and they are worthwhile checks, but the results tend to be dependant on where they’re run from, so, while they’ll tell you what an intruder can see, for instance, they may not give you an overall picture.
Similarly firewall checks are great for determining how secure you are from outside parties, but firewalls don’t always give much protection against your internal users and systems. And there’s nothing to tie these individual assessments together to give an overall view of your network, one that you can give to auditors, customers or partners.
Ideal vulnerability management
What’s needed is a more formal process. One that covers both the technology and human sides of security, can be used to produce compliance reports that plainly show where remediation is needed, and can evolve over time with each iteration of the process as your network changes. It’s important too that it ties in with your business processes and requirements, so that account is taken of the importance (fiscal or legal, say, rather than technological) of the different systems within your IT environment. Meaningful metrics, qualifying risks as relevant to your organisation should be the desired output, not just a list of bugs you’ve found or dodgy access rules.
Creating a reliable policy for vulnerability management is going to take time and effort. It’s important to distinguish between vulnerability assessment and management: assessment is running all the checks and figuring out how they relate to your organisation. To a large extent that’s the easy bit, since it’s the techy part. A full management process has to include having something in place to deal with what you’ve found.
That will have to include deciding your security standards (for people as well as systems), educating users on those standards and enforcing the policies you’ve decided on. There are numerous management tools that can be used to test the individual pieces, whether it’s URL-checking to make sure nobody is trying to access something on the Web that they shouldn’t, or a program that checks for open ports on your firewall. The clever bit is pulling all of this together to turn a load of individual tests into a useful process that actually helps to keep your company secure.