Security inside your software

Security inside your software

I’ve talked about IT security before but today I’d like to elaborate more about a different part of the whole security challenge, from the software vendor side. Today, most (if not all) enterprises are regularly investing in many different ways in order to secure both access and content and stop bad things happening. The global IT security market is massive, with approximately $21.4 billion in revenue during 2014, up 5.3% from the year before (source Gartner). Let me also be clear that I’m not a security expert! I’m merely a CTO, so my thoughts and experiences when it comes to security are very much based on practical everyday discussions, both internally and with op5 customers.

Security and open source (OSS)

Open source has always been “perceived” and “attacked” by legacy closed source vendors as being “unsecured” but this couldn’t be further from the truth. It’s a simple fact that anyone can, and does, check the source code in an open project. I think this is good enough proof that, when there is a security problem, it’s not an issue hidden by a specific vendor, it’s something that can be validated by anyone. To further prove my case, 90%+ of all major ISPs, MSPs, SaaS and IaaS players in the world today have built and operated their core business on an hybrid OSS architecture.

“OSS offers "improved security" -25% of respondents rank it in the top three. Large enterprises with 5,000 or more employees ranked improved security as the No. 1 reason.” (Gartner Open-Source Software Adoption and Governance, Worldwide, 2014)

So is OSS always secure?

No - not at all, but the fact is that it’s not more insecure then closed code. All software has bugs, that’s the nature of the beast and anyone claiming the opposite is lying. The real question is how anyone can identify and confirm that it actually is a bug and who can help in fixing it? Again, a vibrant and very engaged open source community is a huge benefit to this always ongoing task.

Integrations and automations are a new risk factor

Two of the fastest growing areas of IT today are integration and automation. Big data and the need for analytics, in combination with the fact that most things today have got an IP address, basically requires that the guys at IT operations have to integrate and automate. This introduces a slew of new risks. We take software stacks or even complete applications and implement them in services and architectures that they were never built for. Just think about a multi-tenancy web service and all its underlying supporting applications, that in many cases were never built to be used for such an application. Sure, it works, but many times it needs tweaks and patches that will eventually get old or break.

Commercial OSS - best of both worlds

One of the benefits of using an commercial OSS vendor is that security is (or at least it should be) an integrated part of the development process. Using our own product op5 Monitor as a very easy example, it contains a large number of integrated applications and software stacks in order to deliver the overall features and functions. And as such, we have to make a lot of decisions from the beginning, when choosing to add a feature. Most times, we have multiple choices of OSS projects that can fulfill the task, and one of the most important things we consider is the security implications of project X or Y. Many times, we end up not choosing the “Very Cool Project” with all the bells and whistles, as it simply could not meet our security audit.

Test test and test again

Within our development process, we have multiple checkpoints, including both fully automated and manual checks like code review by a teammate before code check-in. And for every minor release, we use 3rd party security companies to manually test and attack our software for intrusion and other bad behavior.

Peter Anderson, Product manager at op5 has written a solution note, good reading if your interested in what and how we do things.

At the end of the day, IT security is very similar to taking a walk on ice - it’s not a question of IF the ice will break, it’s a matter of WHEN (even if takes all the way until Spring time, it will eventually break). What do you (or your vendor) do then?  

Next steps

Well, I’d like to suggest that you do three things:

  1. Make sure that you have a good and clear view of what software stacks, open or closed, you have installed. If you have OSS in your strategic services and they have been implemented by a vendor, ask the vendor or the consultancy company responsible for their statement.
  2. Make sure your software stacks are up to date, regardless if you're using pure OSS, commercial OSS or closed - keep them updated!
  3. Keep an eye on https://cve.mitre.org/, it’s a good place to start if you want to dig deeper in your software.

PS - if you're in Gothenburg next week, there’s an excellent event to attend - OWASP Day: See http://goo.gl/7dwrDo

Be safe / Jan  




















To view or add a comment, sign in

More articles by Jan Josephson

Others also viewed

Explore content categories