Saturday, April 16, 2016

Security assumptions

When it comes to application security there is lots of
discussion on the Internet about web applications and network security. I however found far less information when it
comes to desktop applications and other applications that typically reside
behind a firewall.

For example the initial version of App Tethering communication
was clear text. It has a password but it was sent in the
clear. The reasoning I was given that
the original was sent in clear text was that it was intended to be used behind
the firewall. This design flaw has
since been resolved.
By default your data in the communication is still clear text, although your
passwords now use a HMAC method for authentication with each other. You
now have optional hooks where you can encrypt the data. Not
as nice as communicating over TLS, but is far more secure that the original
version.

I tend to take a different approach; I make the following
assumptions when it comes to security when I code something.

Assume there is no
firewall and hackers can hit any server you publish.

Assume a server,
network switch or router on your network will be compromised and will be
collecting your data.

Assume the machine your code is on will be compromised and/or stolen.

Assume that all input can be malicious

Every day computers around the world are infected with
virus, malware, etc...

These are sometimes these might have been caught by a
scanner and sometimes they can be slip past the scanner. So although a virus scanner is a good idea, it's not
perfect. Given that you have to assume that someone on your network
is infected, and a hacker now has access to a machine behind the firewall.

If an application takes these assumptions into account
during its design, it will help prevent a data breach from occurring.

Data Breaches are costly just ask Target and Home
Depot. So spending some time upfront can
go a long way in reducing potential unexpected downstream costs.

2 comments:

The idea that everything "behind the firewall" is secure is utterly naive. It's an outdated way to think about security, all the evil is outsise, everything inside is fully trusted.

First, outside attackers look for a foothold in your system (a bad Internet facing application, a phishing email, a compromised USB stick...), then look for more vulnerabilites to strengthen that foothold, gain new credentials and privileges, and "move laterally" to become difficult to eradicate. You need a "defense-in-depth" approach, each layer needs to be secured.

Second, could you trust all of you employees and contractors? As Snowden shown, you can't. You should worry about insiders, which may be even a bigger risk. Actually, today you must assume applications runs in an "hostile" environment.

Delphi frameworks that use a single, fixed password shared across all instances of an application are not secure at all. If you have the application, you can decrypt all other users' traffic - no confidentiality at all. I can't understand why nobody at Emb can implement a Diffie-Hellman algorithm, or at least the proper hooks to add it. Then, of course, to avoid man-in-the-middle attacks you need to properly authenticate endpoints... there's no need to reinvent the wheel, standards and tools are there, just use them properly.

You can't have "half-security" or "enough security", you can have only proper security, or no security at all. Delphi design assumptions, and their implementations, are just wrong and dangerous. And as soon as more and more companies are forced to become security-conscious, every product that doesn't offer proper security is less and less valuable.