Why We Exist at 360Secure

And so it begins…. Like every good company, there needs to be a mission, a driving need to fix a...

And so it begins….

Like every good company, there needs to be a mission, a driving need to fix a problem. Well, there certainly is here at 360Secure…

You’ve probably heard the old axiom, “why do people break into banks -> because that’s where the money is”. You might think you have to break into the mall atrium to get to the bank, but there is very little value to gaining access to a mall atrium, are you going to steal the garbage bins? No… it’s just a means to an ends, the ends of getting into the mall atrium being access to the bank. You probably could have gotten to the bank entrance “through the perimeter” so to speak more than a few different ways actually, ultimately the focus is still really on just breaking into the bank, this just seemed to be the easiest way to do it at the time. Which way you do it doesn’t really matter to you.

Remember the time when applications required firewalls supporting fancy stuff like UPnP and dynamic and reflexive port tracking for our applications in our firewalls? How that stuff would from a support perspective sometimes work and sometimes, well, not so much… ? Wow, I think I just sounded way old to a bunch of people, but looking back at those good old days, port scans were something to fear. This was somebody trying to get into the mall atrium, and the bank could be next….

So now in this wonderful little world of “everything runs over HTTP”, we have an application that goes through the firewall, straight from customers into the bank, just as it should to support key customer enabling and business driving functions that add to the bank’s value. So why hack through the “virtual mall” when the “virtual bank” door is right in front of you? Forget hacking the firewall, hack the bank application directly. It’s where the money is. It’s likely easier. It’s what you were there to do in the first place.

Even for applications not supposed to be directly reachable, breaches happen in the perimeter constantly. Anybody who doesn’t build their corporate security around this central premise is simply being ignorant and foolish. A little social reconnaissance, resulting in a very well executed targeted phish that I would challenge most would have a hard time resisting, add a black market supplied exploit attachment, you’re in. That simple. So that internal application that is not supposed to be reachable through the internet? Yeah, that’s not going to work out so good for you…

Applications themselves need to be secured independently. Period. It just doesn’t matter if they are behind firewalls or not. And yes… we can test applications just as we test perimeter security. To do this is a great step in addressing fundamental IT corporate security and risk. However, the ideal place to most proactively deal with security defects is to ensure they never get into the code of the application in the first place. Is this actually doable? Yes… we know how to make this technology work. Is this hard? Well, it can be, but if you have the specialized skills at your disposal, you can mitigate that pain… Will this slow down my application development? Well maybe initially a bit as an investment. But think of it this way… if you treat the notion of “not becoming a headline” seriously, you need to feel confident that you have a secure framework for delivering your applications to your constituents. Once that framework is systemically in place for application delivery, one can argue that is enabling applications to actually be delivered faster in the long run.

And enabling that vision, that is why we exist…

Leave a reply

You must be logged in to post a comment.