As a security vendor, we work to better protect our customers by providing high-quality, innovative products built to ensure best security practices. But we’re also a company ourselves, in need of many of the same protections as our customers.
I’d be lying if I said that I’ve never woken up at night in a cold sweat worrying about how we can better protect ourcustomers and ourselves. What happens if someone breaches our company? What happens if someone breaches one ofour customers because of a failing in our product or our datacenter? What happens if I’m the one who opens a weaponized document containing malware that causes us to be breached? Actually, the last one doesn’t worry me so much because I like to think I know better. But what about an unsuspecting junior member of our staff? What if they cause us to get breached? How long would it take us to know? How quickly could we respond?
Like any high-growth company, we've had to seriously improve all of our security practices. I can’t describe in a single blog all of the security precautions, controls, products (yep, that’s right — we use other security vendors’ products to protect ourselves too!) and processes we have in place. Instead, I’m going to simply highlight some of the security controls we’ve put in place around our development, continuous build, and QA processes.
Fundamentally, security is best in layers. I sometimes call security a big onion. (I usually get the non-approving look from Marketing when I use that phrase, but I think you get the idea.) So over the last year we’ve rolled out a number of approaches to better secure our own products throughout the development lifecycle, and thereby provide a higher quality, more secure product for our customers.
Static Code Analysis Scanning
Our first big initiative was getting a handle on security best practices within our own product. To help us identify technical and logical security flaws within our product, we added static code analysis scanning (by way of Checkmarx CsSAST) to our software development lifecycle.
When implemented as part of a continuous build process, static code analysis scanning is an immensely powerful way of finding issues. Did we find things? Sure. Did we fix them? Yep.
Now we have the opportunity to find and fix issues with every code check-in and every time we build our product. Don’t get me wrong — this type of tooling doesn’t negate the need for good security chops on your development team, good security practices and keeping folks well trained, but it helps a lot.
Vulnerability Scanning
The next initiative was having the capability to scan our appliance for vulnerabilities. Nothing is worse as a product manager than that sinking feeling when a customer passes you a 50-page report of CVEs that need fixing in the next release — and the months of back-and-forth that follow, including discussions around whether certain medium-level vulnerabilities should be addressed and in what timeframe! We have some of the best product managers in the industry here at SecureAuth and I’d like to keep them, on top of needing to have our arms around managing any vulnerabilities and keeping our product and customers secure. So, enter vulnerability scanning via WhiteHat security.
Since we ship our product on hardened Windows Server-based appliances (we provide options for both physical and virtual machines), black box vulnerability scanning of our underlying hardened appliance and our application services is critical. This allows us to stay ahead of any OS and application-level vulnerabilities that may come up.
Penetration (Pen) Testing
I like to save the best for last: pen testing. I’m going to praise the vendor we work with here. Remember how I said that nothing is worse as a PM than getting a 50-page report on CVEs? There is. A 50-page pen test report from a customer and the follow-up calls with the security researchers to resolve them!
During my time at Mandiant, I was spoilt as a product manager in that we had some of the best pen testers in industry at our disposal to pen test our products before they shipped. Pen testing is immensely costly though, in both time and money. It’s a dark art more than a science, and I maintain that if Hogwarts had a cybersecurity program, pen testing would be the only course available.
Fortunately, there are crowd-sourced bug bounty programs. Very much like traditional bug bounty programs, they focus on pen testing vendor products and any associated infrastructure. The premise is simple: More sets of eyes are better than one. Oh, and these programs can be run continuously against your product, and they are very affordable. At SecureAuth, we use BugCrowd to manage our private pen testing programs against our products and against our datacenter that hosts our cloud services. It has been a great way to get access to vetted, high-quality security researchers, all of whom get to practice their dark art for the benefit of our products.
The Layered Approach Pays Off Again
Putting all of these processes and products in place is really helping SecureAuth deliver the most secure authentication products on the market. We keep our customers more secure by avoiding security holes in our product and staying on top of any vulnerabilities, and we get to challenge our customers’ pen testers when we work with them during the sales process. Fortunately, that doesn’t happen with every sale!
I know what you’re thinking: What about third-party component scanning, and the training, discipline and process of the dev team who make sure we’re in good shape? We do that too, but that’s another article for another day.
Keith Graham
CTO
