When I think back at the security situation at Microsoft back around 2002 when Bill Gates released his famous Trustworthy Computing (TwC) memo, our software industry was frail at best. What followed has been over a decade of improvements in software security and security engineering as a discipline. From process to tools. From attitudes to insights. I have been privileged to be part of that and really learn from some great leaders like Michael Howard and Gary McGraw on the subject.
I am talking about security as in “threats,” not “features.” Kaseya has had a strong history in delivering security features to help increase endpoint security through antivirus, anti-malware, patch management and policy-based IT that hardens the endpoints that we manage. In this post though, I want to introduce you to the work we have been doing inside of Kaseya to focus on the threat landscape by delivering stronger security engineering inside of our company. It is hugely different, and comes down to some core beliefs that has become part of our corporate DNA.
For those that don’t know, just over a year ago Kaseya bought Scorpion Software, which was a company I founded and led as chief security architect. We had a strong foundation in security engineering, as demonstrated in many of the solutions we brought to market. From strong authentication used to protect everything from baby bottles to bombs, to single sign-on and password management solutions to solve the obvious problem with passwords that others ignore, writing resilient code to stand up against malicious threat actors while delivering security features has been part of how we do things. It’s the ying to the yang of software engineering as a security discipline. When I joined Kaseya as part of the acquisition, it became part of my job to enhance an already maturing development process with stronger security engineering principles and practices. And you can see some of that effort in many of the changes that have gone on in our software.
But absolute security is a myth. With enough money and motive, anything can be breached. For as good as we get in reducing the attack surface of our code, there will always be new attack vectors we can learn from and allow us to get better. You see this in any software company that matures and takes a dominant position in the market. As you get bigger, you become a bigger target. Microsoft has seen this far too frequently compared with Apple, mostly because Windows is a more dominant operating system. We see this in the browser wars. IE and Chrome see far more attacks than Opera or Firefox. And we see this in databases like Oracle vs SQL Server vs things like Postgres. All software has flaws. How we address it — well, that’s what defines us.
This is where a combination of responsible disclosure and an asserted effort to learn from defects reported give us an opportunity to continuously strengthen our code base. And here at Kaseya, we pride ourselves in how strong our engineering discipline has become, especially in the last few years.
A perfect example of this was a recent vulnerability (CVE-2015-6922 ) that was reported through the HP Zero Day Initiative. Through responsible disclosure we had an opportunity to investigate an issue and consider an entire new class of vulnerability that wasn’t previously disclosed. We educated our entire engineering group on what to look for, and then we didn’t just fix the issue originally reported, we went deeper to understand the risks to our code and ensured we understood and addressed the issue everywhere else that was appropriate.
Then our security response processes kicked in. We prepared a permanent patch fix and retroactively tested it across all versions we support that were at risk. We notified our install base that a security fix was coming to give them a window to plan to apply the patch. We distributed the patch and ensured key customers (including our own cloud servers) applied it before the vulnerability was disclosed, giving us time to properly safeguard all our customers. And then the vulnerability was disclosed to the public.
We hold ourselves to a higher standard than most. We are in good company with organizations like Cisco, CheckPoint and Microsoft who have all built similar processes to address such issues. Anyone that says they are invulnerable to security issues doesn’t understand software security at all. What defines us is in how we architect, engineer and respond to security defects as they come up. And how we build security engineering into all our new work. You can see that in much of the new stuff that has or is just coming to market. Like the threat modeling that is now conducted as part of our agile development workflow. The strengthening of the authentication and authorization subsystem with industry standards like SAML, OAuth 2.0 and TOTP. You can see that in some of the security hardening of our use of SQL we did last year. You can see it in the web application firewall components we have tuned that reduces the attack surface of our RMM platform. You can see that in the role based access control system built right into Kaseya VSA. You can see it in our investments in identity and access management that drives a universal directory of people, devices and applications. If you look closely, you can see it in almost everything we do. Maybe that was one of the reasons I was promoted to CTO recently. Security isn’t an afterthought inside of Kaseya anymore. It’s part of who we are.
The question is… are others in our industry being this responsible? It’s one thing to say they are. It’s entirely different to live and breath it. So ask them. Just what is their code of conduct in regards to security engineering? Do they have dedicated security engineers? Do they conduct security testing? Do they have dedicated security triage and response? Do they have a discipline and DNA of building the most secure IT management platform in the world?
We do. And we are just getting started.