Vulnerabilities – within an operating system (OS) or an application – can result from:
Whereby an error in the program code may allow a computer virus to access the device and take control
Legitimate, documented ways in which applications are allowed to access the system
If vulnerabilities are known to exist in an operating system or an application – whether those vulnerabilities are intended or not – the software will be open to attack by malicious programs.
Eliminating System Vulnerability
Of course, it’s possible to design an OS in a way that prevents new or unknown applications from gaining reasonably broad or complete access to files stored on the disk – or getting access to other applications running on the device. In effect, this type of restriction can boost security by blocking all malicious activity. However, this approach will also impose significant restrictions on legitimate applications – and that can be very undesirable.
Closed and partly-closed systems
Here are some examples of closed and partly-closed systems:
Closed systems on mobile phones
The operating systems in many basic mobile phones – as opposed to smartphones and phones that support the use of third-party, Java-based applications – provide an example of widely-used, protected systems. These devices were not generally prone to virus attacks. However, new applications could not be installed – so, the devices were severely limited in their functionality.
Java virtual machine
The Java machine partly satisfies the ‘closed’ protection condition. The machine runs Java applications in the ‘sandbox mode’ – which strictly controls all potentially hazardous actions that an application may try to execute. For quite a long period, no ‘real’ viruses or Trojans – in the form of Java applications – have occurred. The only exceptions have been ‘test viruses’ that were not particularly viable in real life. Malicious Java applications generally only occur after the discovery of methods that bypass the security system that’s embedded into the Java machine.
The Binary Runtime Environment for Wireless Mobile Platform (BREW MP)
The BREW platform is another example of an environment that is closed for viruses. Mobile phones that run this platform will only allow the installation of certified applications with crypto signatures. Although detailed documentation is published – to help third-party software producers to develop applications – the certified applications are only available from the mobile service providers. Because each application has to be certified, this can slow down software development and delay the commercial release of new applications. As a result, the BREW platform is not as widely used as some other platforms – and some other alternatives offer a much wider selection of applications for users to choose from.
Are ‘closed’ systems practical for desktops and laptops?
If desktop operating systems, such as Windows or MacOS, were based on the principle of the ‘closed system’, it would be much more difficult – and maybe impossible in some cases – for independent companies to develop the wide range of third-party applications that consumers and businesses have come to rely on. In addition, the range of available web services would also be much smaller.
The Internet – and the world in general – would be a very different place:
A lot of business processes would be slower and less efficient.
Consumers would not benefit from the rich ‘customer experience’ and dynamic Internet services that they’ve come to expect.
Guarding against the risks
To some extent, the risks that system vulnerability and malware bring may be the price we have to pay for living in a world where technology helps us to achieve our work and leisure objectives… more rapidly and more conveniently. However, choosing a rigorous antivirus solution can help to ensure you can enjoy technology’s benefits – in safety.
Other factors that help malware to thrive
To discover the other factors that enable malware to thrive and survive, please click the following links: