Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Insanity
SECURITY SHELF

Insanity 

Consider a point of sale (POS) system. Typical components include a computer, operating system, software, monitor, customer display, bar code scanner, and a payment card terminal.

Payment processing, inventory, and other business functions require networking equipment, a WAN or Internet connection, and additional operating systems, software, and back-end servers.

It is relatively straightforward to conduct a security assessment on each component and conclude they all exhibit acceptable levels of risk. Yet massive security breaches have escalated again this year.

When individual components are connected together to form a system additional vulnerabilities emerge. Low levels of risk in components often combine, resulting in significantly higher risks at the system level. In addition, despite intending to design defence in depth, single vulnerabilities with the potential to compromise the entire system are often overlooked.

For example, many POS systems were built on Windows XP and variants such as POSReady. Since the computer was dedicated to POS and presumably intended for use on an isolated network, many organizations may not have felt that the expense of patching and upgrading the operating system was worthwhile. Until recently, the vast majority of corporate desktops also ran Windows XP, making it a popular malware target. POS software can be immaculately designed and incorporate all the right security controls. But, as many retailers have learned the hard way, if criminals are able to infect the operating system with malware, then all bets are off.

It is understandable that a POS vendor may consider the operating system, and maintenance thereof, the customer’s responsibility. To some degree that is a fair approach; the purchaser presumably knows the underlying operating system when making the purchasing decision. However, the POS vendor chose the operating system and other components and should bear responsibility for those design decisions.

This issue is certainly not limited to POS vendors. Some developers make outrageous and outright negligent claims about the security of their software. Many have never performed a proper risk assessment. Others have clearly considered only their code and not the whole system as it will actually be used.

Consider the “secure”chat systems that have flooded the market in response to global surveillance revelations. While some developers are up-front about the limits of their solution, many are not. The latter often suggest that their products are highly secure and promote them with terms like “military-grade encryption.”

Even if the developers of these systems do get all the cryptography right, including key exchange and authenticating users to defeat man-in-the-middle attacks, and avoid security-relevant software defects, the platforms upon which their software operates are vulnerable to attack. In many cases metadata is exposed and simple traffic analysis techniques can be used to identify parties to a communication. Selecting AES-256 as an encryption algorithm doesn’t make a chat system “military-grade”any more than a putting a gun on top of an SUV makes it a tank. Real “military-grade” cryptographic products include physical, logical, and procedural controls that cannot be accomplished by installing software on a consumer device.

While it is possible for a developer to produce the most secure chat system that can exist on top of iOS or Android, they need to be transparent about the reality and limitations of their system. In other words, like POS vendors, their risk model needs to take into account all components of the system, including those provided and maintained by the end user.

Software developers seldom build an entire solution. They usually begin with a commercial or open-source operating system and a variety of libraries. This is not necessarily a bad thing; few developers have the time, money, and skills required to design an operating system kernel or to implement their own cryptographic functions. However, the choice of these components directly impacts the security of the overall system. Risk must be assessed at the system level and reflect real-life use. Until then this insanity will continue.

Related posts