Patching puzzle

|~|piece200x.jpg|~||~|A favourite metaphor for IT pundits at the moment is the silo – every application in an organisation has its own, and refuses to interact with any of the other siloed applications. This, of course, makes things harder for enterprises trying to bring all of their IT systems together and trying to make them play nicely. But it’s not quite true. Now, although many older applications may sit in perfect isolation, they still need to send and receive data over the network. This network is now almost certainly connected – at some point – to the wider internet; for many customer-facing organisations such as banks or online stores, the connection may be more or less direct with web applications connected to back-end systems. For newer applications, designed with closer integration with third-party systems in mind, the problem is more serious – these programs may well have even more sophisticated communications channels open to the world. And while much of network design is now focused on protecting the network itself, it is difficult to build in protection for potentially dozens of applications, many of which will no doubt suffer ongoing flaw exposure. And if such software was designed in an age when external access was not even a possibility, or even built up from code that was, the number of possible entry points for hackers could be very high. This is a rather paranoid and extreme view, but it is quite conceivable that within many organisations, the challenge of securing every application which connects to the network is not as high on the priority list as basic network security. Many software vendors are now much more organised when it comes to tracking and fixing flaws in their applications, but this in itself can cause headaches for IT managers. Applying patches for applications distributed over a network of several hundred machines is not an enviable task, unless the vendor has designed a facility for pushing out patches more easily. A more fundamental part of the problem is that software vendors are still often slow in testing their own applications for vulnerabilities, and then working to patch them as quickly and effectively as possible. This can lead to a number of potentially critical problems, according to Faisal Khan, senior security consultant Middle East at McAfee. “Perhaps the most significant issue with patch management is one that is often simply ignored,” says Khan. “The entire patch process, by definition, protects enterprises only against known vulnerabilities – those which have already been discovered and disclosed by the vendor or an independent security researcher. Having patch levels up to date does nothing to protect against latent vulnerabilities and zero-day attacks. This is why patch management, while a crucial part of any information security program, will always remain a reactive process.” For enterprise software, the problem is made potentially worse by the large amount of customisation which is required to ensure the system integrates with other systems. This can lead to critical applications developing unforeseen faults, which only manifest themselves over months or years. “A primary challenge for IT organisations is to maintain the availability of applications that depend on unreliable software,” says Mathew Lodge, director of product marketing at Symantec EMEA. “Intermittent, recurring software problems that only manifest themselves in production environments are the most difficult to resolve – and the most expensive. Especially challenging are problems that appear over extended periods of time or only under the heaviest of workloads. “Many common software errors, such as buffer overwrites and memory leaks, can cause intermittent application failure and performance degradation hours or even days before they are recognised as problems,” adds Lodge. ||**|||~|azazi200p.jpg|~|We have an open budget for the security guys, as long as they can prove it.” Sabri Al-Azazi, CIO of Dubai Holding.|~|“Buffer overwrites are surprisingly common programming errors. Many well-publicised security issues in commercial software are buffer overwrite problems.” Symantec’s approach to the application security issue is to deploy intrusion detection and prevention on the host system, in order to stop any attacks or other malicious activity at the traffic level. It also offers systems which include security profiles for various software systems, aimed at preventing attacks specifically against those particular systems. “For large organisations patching large numbers of machines frequently is difficult. In some specific verticals, it’s impossible,” explains Lodge. “One example of this is embedded Windows systems, such as those used for bank cash machines. These systems are never patched. This is why it is essential to protect these systems with host intrusion detection and prevention software. Diebold, a leading maker of cash machines, ships Symantec’s Enterprise Protection product in all of its ATMs for this reason – because embedded Windows systems cannot be patched frequently.” This approach, though, illustrates one of the fundamental problems with securing large and varied application environments – if the version on your systems differs slightly, or is not sufficiently mainstream to be covered by a security package such as Symantec’s, there is scope for problems. One answer to this is that if an application is that obscure, it is unlikely to be targeted when compared to more highly-developed exploits for Microsoft or Oracle applications, for example. But in these days of targeted attacks against specific organisations – or an internal attack – this may not be sufficiently convincing. One of the problems with looking at security in general is how paranoid to become about the vulnerabilities in a particular system. Yes, it is true that a hacker could potentially develop and execute an attack against your one obscure database system, but how likely is this in reality? For application security, risk assessment then becomes a critical part of developing a robust policy. Only by having a clear idea of the risks and potential consequences for particular security breaches can organisations formulate a realistic and workable approach to IT security, and application security in particular. One example of this realistic decision making process is Dubai Holding. The company is focusing on making security very flexible and adaptive to support the agility of the organisation. For example it does bar user services such email downloads to PDAs because of the potential security risks. But it also does a comprehensive risk assessment and analysis, highlights the risk and then puts in the right infrastructure to support it and minimise the risk and mitigate any threat. “Dubai Holding is no different than any other organisation in terms of applying security architectures,” says Sabri Al-Azazi, CIO of Dubai Holding. “What is different is the dynamism; the speed of implementation has got to be there and in terms of virtualisation, that doesn’t have a boundary. We apply security on the systems more than on the perimeter - there is no access control, we cannot because the of the nature of Dubai Holding as a business.” Al-Azazi’s approach to security is to make it a much more accountable part of the business and IT infrastructure, and to make it justify itself. Dubai Holding is prepared to invest significantly in security solutions, as long as there is a demonstrable benefit and return – either in investment or else in risk reduction. “We have an open budget for the security guys, as long as they can prove it,” says Al-Azazi. “There is no open space for them. They need to apply network security by having firewalls and IDS; they need to apply application security; they need to apply encryption and links security.||**|||~|cables200xx.jpg|~|Networked applications pose a particular problem to security managers, especially if they were designed before the days of ubiquitous connectivity.|~|“However, they cannot just say we need everything at the same time. They need to take it gradually. You ask him: before you need encryption parts, what have you done to protect the application? You must keep challenging them. If they come up with a very good business case, we approve it,” he adds. For application security management, there are a number of important issues to look at when formulating the best approach. Not least of these issues is the status of an organisation’s security layer – security managers will need to take a very different approach to a green-field site, compared to one with a large number of existing applications. “In the case of a large legacy install base, there are a lot of parameters that IT managers need to look at,” says Shahnawaz Sheikh, regional sales manager for the Middle East and Africa at SonicWall. “Firstly, how seamlessly can a new application interoperate with the legacy system? How easy it is to migrate from a legacy system to a new system? How to use the best functionalities of both of the systems? “There needs to be a comprehensive assessment of the application to determine the robustness, vulnerabilities, scalability, ease of use and management, whether the new system integrated with legacy meets the needs of business processes or not, the user comfort and adaptability, patch management, system redundancy and contingency planning, and so on,” he adds. The necessity of application management is a part of security that can quite easily fall between the cracks of an organisation’s IT security planning, depending on the structure of the IT department. If network and systems security are handled separately, then coming up with a coherent policy towards external threats to applications on the network may be difficult. One increasingly popular approach is to deploy network access control (NAC), which effectively combines many of the aspects behind networking and application security (see box). But NAC is not an easy system to implement, and requires a certain level of network infrastructure in place to begin with – otherwise it may be rendered both ineffective and pointless. “Most organisations are not equipped to implement a decent end-point security; for example, the NAC requires an organization to have up-to-date networking components along with latest operating system,” says McAfee’s Khan. “However, most organisations cannot remember the last time they updated their internal networking switch. “NAC is a process of admission control, i.e. restricting or allowing access based on a certain criteria which includes up-to-date anti-virus, Windows patches, operating system policies, host IPS policies, host firewall policies and anti-spyware policies. However not many organisations have a fair checklist in place along with the underlying technologies to even perform NAC as more than 95% of organisations today have only anti-virus,” he comments.||**||