Breach of the Drones

When it was discovered that video feeds from U.S. Predator and Reaper unmanned drones were being hacked by insurgents in Iraq, it became evident that cybersecurity has a long way to go to become more secure. The natural reaction is to point the finger at software producers, the government, and the push for functionality over security. But it may be that a different model is needed for the software itself.

When you think of military security, if you are like me, you think of planes, tanks, guns, and bombs. If you look at a tank, you have a weapon that can withstand direct attack against some serious ammunition. It is designed to be attacked and still fulfill its mission.

Software is not designed to be attacked. It is designed to provide features and functionality, but it is seldom designed specifically to be attacked. Instead, software is designed to minimize vulnerabilities.

What would happen if software were developed as if it were a military tank? If you were to develop a design pattern for software that resembled a tank, it would obviously require a very tough exterior interface to protect the crew and equipment inside. It would require very strong encapsulation to ensure that all interfaces to the outside world are well-defined and secure.

If all software were created using such a Tank design pattern there may be a variety of predefined, standardized system utility interfaces that allow secure communication with other systems and other subsystem components. This would allow the developer to implement the Tank pattern and simply select secure interface services without having to worry about coding each one.

Do you think it is possible for a one-size-fits-all design pattern or perhaps even a framework that toughens the exterior of software so it can better withstand attacks?

Read More...

Implementing Trust Between Systems

When designing or reviewing a system, it is common to ensure that trust is established between end-users and the applications. Trust in this context means that the users are trusted because they have proven their identity, and their authority to access the application has been verified. Many times, trust between system components is overlooked. This can be a deadly sin for software design that can lead to security vulnerabilities.

When trust is not established between system components, it means that any application that has access to the network can connect to the subsystem's exposed ports. For example, consider an application that exposes port 443 for receiving XML using HTTP over SSL. You might think that this is secure, since it uses encryption; however, encryption does not guarantee trust. Any web browser or system that supports HTTP over SSL can connect to that application and send malicious XML payloads.

You may say, "But my application uses a proprietary protocol that people would not understand." Unfortunately, security by obscurity is not security at all. With enough time or inside information, an application that does not require trust of the systems that connect to it may be easily compromised.

Trust generally comes with a certain amount of overhead. Here are two ways you can establish system trust in your application. First, you can require that all clients that connect to an open port present a user name and password or a shared secret key. This approach has the lowest overhead. When using web services, this can be accomplished using WS-Security. Second, you can use asymmetric encryption for non-repudiation to ensure that only the client could have connected because only it has a public key that can decrypt the message. This approach has high overhead, since encryption requires time and system resources, but it also ensures that the credentials are not exposed in clear text.

Many companies allow so many other companies into their networks, and insiders are frequently as much of a threat as external attackers. With this in mind, firewalls have limited value and are not very good at establishing trust. They are good for building a layer of security around your applications, but this does not compensate for a listening port that does not require trust.

How are your applications doing at establishing trust?

Read More...