Thursday 22 February 2018

Why All Applications Should be Created as if They Were Security Applications


Before I go in to detail on this subject, let me make some statements clear:

  1. I do not believe that organizations should stop purchasing specific security applications, CASB's, Firewalls, VPN's etc.
  2. I believe that security is multi-faceted and that organizations must take different and layered approaches to protect their data and systems. 
  3. I am not the devil in carnet. (Although this has yet to be proven outright!)

This has to be said up front, as I just spoke at a conference and addressed this subject and inevitably people told me how wrong I was and that an application's job should be to do what it says on the tin. This then leads on to them accusing me of not taking security seriously. (Not the case).

But while we are on it, let me also add in here that I am not a great lover of the current rush to use external libraries - API's into other applications yes, but not external libraries that we as developers have no insight into and no definitive way to make sure that they are programmed correctly and in a secure manner. Oh yes, there is Open Source. This does have a place, but the licensing can be restrictive on organizations, and also it not immune to massive security errors.

So here go my thoughts on it:

Systems are inundated with bad actors every hour of the day - all 24 of them and every single day of our seven-day week. We have had the current security practices for over a decade now, and while they have definitely worked in some cases, there are other well documented ones where they have blatantly not. This alone tells me that we need to re-evaluate how we are protecting our systems and data. One of these places must be within the applications that are used. If I create an application that connects and retrieves data from a database in a data center far far away, is it not incumbent on me to make sure that:

  1. I check for SQL Injection Attacks
  2. I make sure that there are ZERO login credentials held in plain text that my application uses.
    • This means, no scripts
    • No uncompiled code
    • No ini files
    • No conf files and
    • No txt file

Or, to put it another way, there is no mechanism for a bad actor to read a file that held on the system and take from it details that will compromise the data.

I do not see this as being controversial or special, just good practice!

In addition to the basic points above, I also believe that the software developers job is to:
Create an application that does what it says on the tin, making it as simple to use as possible, while maintaining security to a degree that makes it incredibly hard for any non-authorized actor to access anything that the application has been designed for, without, compromising the usability.

And then this last point is vital. As soon as usability is compromised, the users will find a work around and then security is forgotten about, as a user’s primary role is to complete the task at hand, and they will just assume security.

This leads me nicely on to my next rant. Security of data is down to us as technologists. We are the ones who should know how to secure up a database. A bank's role is to secure my money and make it available for me. My role is to make all the transactions in between secure. I have more knowledge than they do on that, and I hope they have more knowledge than I on the markets, so they and in turn I do not go broke!

These are all great words and statements, but in practice how does a developer create an application that does what it is designed to and separately keeps the data secure?

This is where I lose the few friends I have within the industry, but here it goes:

When programming, STOP relying on external libraries that you have zero insight into. Programming is an art form. We create an application from a blank screen, it appears before us. I have never heard anyone say, "Wow Simon that painting by numbers book you have completed has really made a difference and it is truly unique." I am not saying that all libraries are bad, of course they are not, but let us not rely on them. Start looking within and creating your own. This allows you to know they are written as securely as they can be, and that you have full control of the source code. Otherwise, how do you know that your application is secure? The library may have security flaws in It, or worse, it may be calling out sending usage and other data to the publisher. Security starts from the basis of 'I do not trust you.'

Then there is the programming itself. I am not the world's best. I create an application, a library for our applications or a routine to go in to one of our applications, and that then goes to the engineering department who scrutinize, scream, fix and generally work on my code. Once they are complete, it comes back to me for review where I invariantly will have a lot of changes and once more send it to engineering. This process goes on until we are happy. Then a code review happens with myself, my CTO and our chief developer. We look at the code and check for security holes. Once this is done we go to Beta. During the whole process, we are continuously testing and pushing the code to its limits and in some cases sending it out for review and testing.

To sum up. I see my job as a technologist to help with security and make sure that the applications I have control of can be a part of an organizations security defenses, no matter what the application is designed to do.

No comments:

Post a Comment