Gastbeitrag von Amit Tailor, Network Security Specialist, CyberGuard Corporation (http://www.cyberguard.com). Let’s face it, managing security policies can give you a headache. Coping with the rules and properties and policies affecting hundreds of devices - firewalls, intrusion prevention systems, and anti-virus servers - is hard enough, and that’s before trying to manage them, or change their state.
The policies themselves are becoming ever more complex and demanding, and in need of instant usability and flexibility, so that changes can be made quickly, easily and accurately.
One way forward is to centralise the management of these architectures and policies. Yet managing this “centralised security management” (CSM) itself needs focus to ensure that all devices work coherently together to provide the security that justified their cost.
The benefit of the CSM approach is that it gives you a 10,000 ft “dashboard” view of the overall security landscape that enables you to more easily configure, validate, and prioritise the system from a security perspective. Administration of software updates, authentication and integration with third party devices also works more effectively if managed centrally.
One of the first areas to benefit is configuring devices. Misconfiguration of devices is a common problem, especially when managing across multiple domains. It is much easier to manage configuration if you can do it across the board, rather than having to continually reconfigure individual entities. At the heart of this is the concept of object reuse. If a policy has already been defined, it is easy to re-apply it.
CSM is also invaluable when it comes to validating the configuration. How do you know that what is being displayed is actually deployed and activated? You need to know what you are seeing is what the device is providing, and users are always looking for a way of verifying that. There may also be a need to be able to “back-manage” a piece of configuration. If you update a configuration, can it be changed back? The ability to restore a configuration by roll-back is very important when you are managing a complex configuration of firewalls or other devices.
You can, of course, configure each device independently. But using CSM, means you can access all devices. That includes mirror clusters of firewalls across duplicate and in different geographical areas.
Assuming you have managed to configure your devices, the next concern is monitoring them. You may have the devices set up to your satisfaction, but you need to know if the devices themselves are operational, and what the traffic flow is. You need to be able to access logs, and check on the health of devices, their memory state, and CPU utilisation. Furthermore, it all needs to be done in real time.
Managing the firewall is critical to your system’s security. You need to know the traffic flow through the firewall at a specific time for a number of reasons: troubleshooting, capacity planning, analysis and incident investigation. The firewall’s audit granularity and report capability is key to accomplishing this.
When it comes to event alerts, you need to know where they are coming from. For example, are they coming from one device, or a series of devices? It is clearly much more of a security threat if you have the same attacker targeting fifteen different devices, perhaps an automated attack, rather than perpetrating one isolated attack. The CSM system needs to be able to understand and correlate what is happening, and the criteria need to be flexible.
There also has to be some prioritisation built into the system. Where do the system’s priorities lie: in a port scan, or disk utilisation? In other words, does a security alert have priority over a system alert, such as 100% utilisation? These sorts of rules have to be built in, so the system can make some judgement calls on prioritisation.
The same can also be said of the priority given to software updates or patches. Which is the more important: software updates or security fixes i.e. patches? Normally, you’d say patches were more critical and so would have a higher priority. But how do you identify what updates are available? The CSM must be able to do that, identifying the type of firewall, which version is running, and whether any updates are available.
Assuming an update service is available, it is essential to know how to get it, and how it should be pushed out to security devices. An update candidate should be downloaded locally to the CSM ready for distribution to the firewalls centrally. The system will need to know if the update applies, and whether it can be validated. In applying the update, it is likely that the update will be an automated application, but will be initiated manually by the administrator. The interface to the update should be centrally managed.
When it comes to upgrading devices, it could take an hour to do each one manually, so upgrading all devices could take days to achieve. Centralised management is better, but more risky. The disadvantage is that that the risk impact of doing everything together is higher, because multiple devices are updated simultaneously, so if something does go wrong, the effect is magnified. Therefore all software updates must be digitally signed by the software vendor for integrity. That software verification must tell the system that the update has been signed by the correct vendor, that the validation is not corrupt, and that the update is the current version.
Once the upgrade process has been successfully completed, it is important that the firewall or other device is given a date and time stamp to say that the upgrade has been completed. This is important for version control i.e. the user knows which version is running at a particular time.
If the installation of an update fails, the system should have an “automatic rollback” procedure, in which any device in the process of being upgraded goes back to its previous working state. One of the problems with a central management system is that all information, such as configuration, logs, alerts and software upgrades, is held in a central repository. That itself can be a risk because all your security information on all devices, is saved in one place. All your eggs are in one basket. Therefore as part of your administration and security environment, the CSM itself must be backed up.
Permissions and authorisation for access is also an issue which users of centralised management systems must be aware of. For example, which users have access to which firewalls, and what access control do they have to those firewalls? Do they have read or write access? Or create, notify or delete? The type of permission a user has is vital to the secure running of the system.
Time is another important criterion in safeguarding access to devices. For example, your security may define login restrictions on a time basis. Typically, shifts for monitoring are for three per day each of 8 hours. Your system could have user IDs for login tied to specific times during a shift, and only when on that shift. That means the user ID can only be used during approved time periods.
The critical element of Centralised Security Management is the Management Server. If you are going to operate a centralised system, you need to manage the risk of what a user can do to CSM data, funnelled through the Management Server. Therefore access to the Management Server must be rigorously controlled for example by using a Public Key Infrastructure and digital certificates. It is also necessary to maintain a listing of who changed what, and when.
There is one final area regarding use of CSM that requires attention: integration with third party solutions. It is important that any centralised system allows effective integration with third party solutions, especially third party monitoring solutions such as HP OpenView, Webtrends, and IBM’s Netview, usually using an SNMP agent.
There is no doubt that CSM allows you to take control of your security. Without it, you could find that 70% of firewalls may be configured incorrectly. If you want to change key lengths or rotation for access control, it will help there as well. If you’re trying to do configuration for a VPN, either on a star or meshed topology, CSM will undoubtedly make your management easier.
Centralised Security Management allows you to
| | | |
| | · | Configure devices |
| | · | Validate them |
| | · | Improve version control |
| | · | Control access through permissions |
| | · | Prioritise updates |
| | · | Monitor and control events |
| | · | Integrate with third party products |
Security of Centralised Security Management is vital – access must be controlled by PKI and digital certificates.
Metadata