Application Security 101

As security professionals, we often assume that all of our clients involved in the testing process understand the who, what, why, how, and where of securing their applications.  As I pondered the vast array of subjects that I could cover on this, I realized that maybe I should just start at the beginning.  This will be the first in a soup-to-nuts series for everyone involved in the development cycle.  From business analysts to help desk folks, my goal is to guide you towards a better understanding of application security.  

Security is our business, but security should be everyone’s business.  I know that sounds cliche, but treating it as an afterthought can impact every level of an organization negatively, from board members to end users.  Today's applications can be available over various networks and many of it is connected to the cloud.  Software vulnerabilities are commonplace, and something as simple as a patch being put off can be the pinhole in the waterbed.  If you aren’t as old as me and don’t get the reference, it basically means if you are lucky enough to catch it early you may be able to stop the leak.  But if not, you’re in for a long night.

Application security is a big job, for sure.  And it’s not just the job of the developers or the SOC.  There is an incredible amount of surface to cover and keep track of.  If you read the lists out there all you have to do is harden your systems, encrypt, monitor, log, and patch everything.  And buy all the cool new security software to automate it and solve all your problems.  If only it were that simple.  I feel like this is a great time to drag out the good ole CIA Triad.

No, not that CIA.  This is not classified information.  The CIA Triad is viewed as the primary goal or objective of security. This includes three core principles that any organization should consider when securing their systems or data.  It’s like having three legs of a stool, and if one of them is missing, then things tend to fall over.  Each principle of the CIA Triad is broken down below:

• Confidentiality: Likely the most obvious.  Hiding information from those who should not be able to view it.  Cryptography and Encryption are examples of how data in transfer is secured.
• Integrity: Ensuring that the data is accurate, unchanged, and reliable.  One of the ways we test applications is by proxying the traffic through a tool that allows us to tamper with the information.
• Availability:  Data is useless unless users are able to access it in a reasonable amount of time.  Power outages, natural disasters, and deliberate sabotage can all affect availability.

The CIA Triad should be utilized in most security situations.  From development to training to mitigating a breach, each segment is critical.  Focusing on each area's security, it guides us towards pinpointing vulnerabilities and coming up with solutions.

When considering an application’s security as a whole, I like to use the house analogy. 

Think of the application as your house.  You trust it’s been built well.  You secure it with all the things you think you are supposed to.  You have keypad locks on the doors and only your family knows the codes (passwords).  There are alarms on the windows (alerting).  Maybe some cameras that record the perimeter (monitoring, logging).  You make sure to check all the windows and doors at night before you go to bed (patching) and you feel pretty safe.  But when we look closer we can start to see the cracks in this model.  You can certainly decide just to take these security measures and go about your life.  You can accept the risk.

But, that sounds like a pretty solid setup, you say?  What risk?  We can use the CIA Triad here too.  I’ll use the door lock as an example.  Did someone in your family give their door passcode to a friend or service person and forget to change it?  Did you change the default code when you programmed it?  You can check the door all you want but if someone else knows the code they can walk right in.  Those both fall under confidentiality.  Is the software on the lock maintained and up to date?  Is it vulnerable?  Is the lock itself reliable?  Or will a credit card, shim or lock picker be able to get past it?  Or a hacker?  Or a good kick?  Here we question the integrity of this feature.  Of course, we can just barricade the door.  That’s pretty secure.  But then no one’s getting in, including your family.  At least not without a huge amount of effort.  Availability is now an issue.  I think you see what I’m getting at here.

Does this mean we arm ourselves and build a moat around the house?  Maybe that’s right for someone.  But we are usually going to sacrifice one of the other segments of the CIA Triad if all our efforts are focused on one or two.  So we work to meet all these standards and create the most secure environment possible for our particular organization.  A financial institution’s data is going to have different needs, requirements and usability considerations than a hospital.  We need to assess what is being protected, where the vulnerabilities are, where the threats are coming from, and how much risk they pose.  Continuously.  It’s an ongoing process and an investment.  Hackers get better.  Technology changes overnight.

I hope I’ve given you the big picture here.  We will dive a little deeper into some more interesting aspects of application security in future blogs.  Until then, I will leave you with my favorite CIA joke.  A CIA agent walks into a bar [REDACTED].