|
|
ÊAdvertise ÊContact ÊSecurityWatch |
| Ê Articles | Editorials | Reviews | News | InfoSec Directory | Releases | Submit PR |
|
GFI MailArchiver for Exchange - Easily archive Exchange Server mail & comply with Sarbanes Oxley - Free evaluation available. Network Security Software - Sponsored by GFI Network Security. 
|
Centralized Management of Enterprise Network Security and the Never Ending Logs Author: Tareque Choudhury, Technical Manager, CyberGuard Corporation Wednesday, 18 May 2005, 11:09 GMT Security policies and architectures are becoming ever more complex and demanding. There is still a need to restrict which users can access a particular server or application. But governments and regulatory agencies worldwide are imposing stringent new rules to protect individual privacy, enhance state security and support law enforcement efforts. To meet these challenges, you need an enterprise-class central management solution that enables you to implement security policies and policy changes quickly, easily and accurately. Centralizing the management of these architectures and policies is key to a secure and cost effective solution. Architectures are becoming more distributed with firewalls, intrusion detection system, and anti-virus servers being deployed across organizations globally. Teams of administrators are typically required in order to maintain the security infrastructure. Within the team of administrators, skill set in each device is usually attained via training courses and certifications. Each time a new type of device is introduced to the network it requires new skill set learning, involving time spent on the course and not on administration which costs the organization money alongside the funding of the course fees itself. 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 gives a sense of misunderstanding amongst administrators who have various management interfaces to configure. Let’s take an example, if you have firewalls for organization X, located in New York, London, Frankfurt and Dubai. The global Internet browsing policy dictates that everyone must authenticate with user credentials prior to having 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. The reason this has occurred is because each firewall had to be configured using the firewalls local graphical user interface so the configurations were not done according to the global security policy. This is an easily made and 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, is it proxying to appropriate websites? Each organization needs to ensure that the investment they have made on security is actually performing the duties according to the dictated security policy. Reading and correlating vast amounts of logs is a hefty task, especially when it is from multiple devices. Many enterprise organizations that I have visited have one of two things, either a team of individuals whose sole duty is to read logs, or this duty fall under the role of the administrator. When it falls under the role of the administrator, which is the norm, reading of the logs is usually bottom of the list until there is some troubleshooting to perform. This is usually due to the fact that the in order to read the logs of each device, they must go to each interface of the device in order to get to them. They may have a central SYSLOG server where logs are sent to, however SYSLOG messages are usually not the most coherent. By having a central management approach, we can have all logs sent to the central management server where the data from the logs can be stored and correlated on one interface. SEM or security event management is a hot topic amongst many of the enterprise 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 being stored within the devices itself. Let’s take the example of organization X again. Instead of each firewall in each city storing the logs on its local device where by each administrator would have to log into the system to view the logs, it would be more cost effective from a time approach 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 managers 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 signaling. For example, if one area of the dashboard is for the proxy server to determine of it being overloaded, the dashboard signal may turn red once it begins 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 the admin with data to show management that another server is required. Another example would be a firewall under a distributed denial of service attack. If the firewall device were under attack it would begin to generate a high number of logs within a short period. These logs if sent to a central management server that performed event management would raise an alarm on the dashboard that the system was under a denial of service attack. This coupled with the data that would come from the intrusion detection server 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 once the firewall was inaccessible to the organizations users. Many administrators spend part of their day sifting through logs and trying to correlate the data themselves, central management systems that support security event management can perform this functionality automatically for the admin saving vital time which at the end of the day costs the organization money. From a total cost of ownership point of view, having software automatically gather your data and provide them to you in an understandable format is an intangible saving which can only be seen over time. Now let’s take a look at the type of central management solution to look for and what fits best into most enterprise organizations. When we look at central managers we look at a system that sits centrally amongst all your security devices i.e. Firewalls, VPN’s, content security. 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. The central manager system should also be looked at as a security device as well and should sit on top of a hardened operating system, or should be tightly integrated with a multi-level secure operating system that uses mandatory access control along side other type 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 centre while the administrator can sit relaxed in the comfort of his office administrating the security infrastructure. Now that we are 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, such as firewalls, VPN’s and content management servers that are deployed 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 SSL, also known as secure socket layer. This type of traffic allows the data to be encrypted while the data is being sent from one device to another. So the data from the administrators 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. Now, although encryption is great and typically quite secure, another level of security should be taken into account when architecting a central management approach. Authentication should be ensured to determine that the system that is 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. Central management of the network infrastructure is a fairly large topic that can be discussed in fine detail. Throughout this article we touched on the very basic principles that should be thought of when implementing architectures of this type. All enterprise networks should quickly adopt this approach as it provides cost saving by reducing the man power required to administrate the network as well as providing a more robust approach to log management, which is a topic unto itself. |
Monday, May 23, 2005 Network Security
 Wireless Security
InfoSec Directory
 Press Releases |
| ÊCopyright © 2000 - 2005 eBCVG IT Security | Affiliates :: RSS feeds :: PrivacyÊ |
Ê