More and more organizations are including firewalls, intrusion detection systems, and anti-virus servers in their network architectures – with teams of administrators typically required in order to maintain the security infrastructure.
In any team of administrators, however, members need to maintain their skills through regular training courses and certifications. Each time a new type of device is introduced to the network, new skills need to be learned.
Configuration policies are also distributed alongside each type of security device, with each policy configured and driven by the graphical user interface of the server itself. This type of distributed policy often creates misunderstanding among administrators who have various management interfaces to configure.
Let us take an example of one particular organization which has firewalls located in New York, London, Dubai and Frankfurt.
The global internet browsing policy dictates that everyone must authenticate with user credentials prior to gaining access to the internet. The New York and Frankfurt users are authenticating fine, but London and Dubai users are freely browsing the internet without having to provide credentials.
This has occurred because each firewall had to be configured using the local graphical user interface, so the configurations were not done according to the global security policy.
This is a common mistake that occurs in many organizations. Having a central management solution which has the ability to configure all firewalls from one graphical user interface would limit the administration error that can occur.
After the architecture has been deployed and the policy has been set, making sure that the policy is being enforced is a full time job itself. For example, making sure your firewalls are doing what they are supposed to do involves reading through the intrusion detection logs to make sure that:
- What is being detected by the device is valid and accurate;
- What is being denied by the firewall is supposed to be denied;
- What is being permitted through the firewall is valid traffic;
- If there is a proxy server, that it is not proxying to appropriate websites.
Each organization needs to ensure that, after a substantial investment in security, it is actually performing the duties according to the dictated policy.
Reading and correlating tens of thousands of logs is a hefty task, especially when it is from multiple devices. Many enterprises that I have visited have one of two things: either a team of individuals whose sole duty is to read logs; or this duty falling to the administrator.
Administrators often put this job bottom of the list until there is some troubleshooting to perform – usually due to the fact that, in order to read the logs of each device, they must go to each interface of the device. Even if they have a central Syslog server, where logs are sent to, Syslog messages are not usually the most coherent.
By having a central management approach, however, all logs can be sent to a central management server, where the data can be stored and correlated on one interface.
Security event management (SEM) is a hot topic among many of the organizations I have visited. With the vast amount of data floating through the networks, they would like it to be more integrated into the management infrastructure, and not be stored within the devices itself.
Let us take a look at our sample organization again. Instead of each firewall in each city storing the logs on its local device, it would be more far more cost-effective to have each firewall send its logs to the management server, where it is stored in a database and correlated and presented to the graphical user interface in an easily understood format.
By having the logs displayed in the central manager's graphical user interface in a dashboard-type approach provides the administrator with easy-to-view windows where he can react based on what the dashboard is signalling. For example, if one area of the dashboard shows that the proxy server is being overloaded, the signal might turn red once it starts to receive a certain number of logs in a given timescale.
This correlation of data would allow the administrator to react and maybe redirect the traffic to another server, or provide data to show management that another server is required.
Another example would be a firewall under a distributed denial-of-service attack. When a firewall device is under attack it starts to generate a high number of logs within a short period. If these logs are sent to a central management server that performed event management, it would raise an alarm on the dashboard.
Coupled with the data coming from the intrusion detection server, this would allow the administrator to take the necessary actions.
Typically, without this type of centralized log management, the administrator would determine that an attack was taking place only once the firewall was inaccessible to the organization's users.
From a total cost of ownership point of view, having software automatically gather, and present your data in an understandable format is an intangible saving that can only be seen over time.
The central manager is a system itself that should typically have an SQL database in order to store the configuration of the devices, as well as the storage of the logs from each device. It should also be looked at as a security device that sits on top of a hardened operating system, or should be tightly integrated with a multi-level secure operating system that uses mandatory access control alongside other types of access controls.
It is important that the central manager has a remote, Windows-based graphical user interface, as the majority of administrator desktops are of the Microsoft type, so that the management server can sit in the data center while the administrator can sit in the comfort of his office.
Still on the topic of remote connectivity, we need to discuss how all the devices send their data back and forth between the administrator interface, the management server and the devices the manager server controls throughout the organization.
Since the subject of central management revolves around security, we must make sure that the data transfer is also secure. This is typically done using secure sockets layer (SSL). This type of traffic allows the data to be encrypted while it is being sent from one device to another. So the data from the administrator's interface and the management server is encrypted as well as the traffic from the management server to the device it is configuring or gathering log data from.
While encryption is typically quite secure, another level of security should be taken into account when changing to a central management approach. Authentication should be ensured to determine that the system updating the firewall or VPN device is actually the central management server, and this type of authentication should be done via digital certificates. This determines that there is a trust relationship between the administrator, the central management server and the devices that are being managed.
Tareque Choudhury is technical manager, EMEA, at CyberGuard Corp.
