At the very least, to build a secure solution, you must have the following:
- Expertise You cannot secure software without people who understand it and have done it before
- Technology Many technologies are inherently insecure. To rely on them is to fail.
- Process You must implement checks and balances throughout the entire lifecycle of development
- Auditing Difficult problems require iterative review cycles - it won't be right the 1st or 2nd time
Expertise Requires Proper Experience
Securing solutions isn't about being smart or having years of programming experience. There is a credible study that shows experience in software is no indication of security ability: Being senior doesn't yield more security knowledge than being junior. A developer has to be properly trained in specific areas, and has to put that training into practice. For complex engineering tasks, pros with years of experience struggle. Look at Galloping Gertie and the Bay Bridge for some supporting evidence. Security is no different.
DefiniSec was built using a core team of people who have dedicated their careers to products and services securing information.
Some technologies are inherently insecure. OpenSSL taught industry a tough lesson with Heartbleed. Being open source offered an opportunity for security, but didn't guarantee it. The SSL protocol has its own shortcomings as well (certain versions of session resumption should probably be avoided altogether).
DefiniSec uses a minimal set of libraries and in core processing avoids ATL, MFC, OpenSSL (and SSL altogether), .NET, and others. We built our solution assuming attackers gain access to the very computers on which we protect data. This is very rare even for security products, though required in today's dynamics.
Developing secure software requires a process focused on insuring security is taken into consideration every step of the way - from requirements through managing a deployed instance of the technology through incident response. Microsoft publishes their Security Development Lifecycle model available for adaptation, and many companies sell their own methodologies along with software and components that aid in efficient application of proper controls. This includes data flow and threat modeling, attack surface reduction, secure coding, fuzz testing, and many other secure development tasks too vast to describe here. Without a team focused on security and backed by those with expertise and the controls to impose discipline across the board, the end result will be greatly misaligned with what you deserve.
DefiniSec's core team has adopted, customized, and deployed secure development processes and procedures in multiple organizations, both large and small, for teams using different coding methodologies (Agile, SCRUM, XP, Waterfall). Several of our team members specialize in secure coding, and have built and shipped software designed to help teams achieve better secure programming efficiency.
When you think you're ready to ship a product, penetration testing and security auditing should be used to insure that the team's blind spots are discovered and addressed. This is an ongoing process that isn't done once - teams have to repeatedly get outside validation. There are many companies providing these services, though we want to warn that many aren't qualified to do so.
At the RSA Conference this past year, we were talking to an emerging company in the test space touting their innovative new way of achieving results quickly. We asked for a typical campaign and pricing - the quote we were given was for four weeks with their top team finding three to four security defects. This isn't an indication of a proper audit.
In a past audit, we were working with a development team of five working over the course of a three-year grass-roots effort. The team was comprised of experienced security developers focused on designing and building secure software. The audit process was performed by one of the strongest teams available. In the first hour, auditors identified over a dozen critical issues to deal with. Over the next several days, the count jumped past fifty. This took another eight weeks of iterative fix/retest before the software was ready for final testing and release.
In another example, just this past week OpenSSL patched a critical vulnerability. Didn't the software just go through a formal audit? Yes. We don't know if this was something found by the auditors, or independent. It doesn't much matter - and it wouldn't be an indication of failure. These activities take iterations and time. The issue is evidence of a normal process catching up with years of development.
Our team at DefiniSec has been responsible for all aspects of securing software covered here, and many more. We've found that secure development methodologies are the exception, not the rule, for software in general. We've seen numerous companies emerge with claims of new, safe, secure ways of doing xyz only to find they don't have the expertise and insight to achieve effective results. When people wonder why we continue to see giant data breaches, understand that secure development isn't yet prioritized as it should be. Until that changes, we are going to see more of the same.
We designed SSProtect to secure your data despite these realities. This has taken a combined total of more than a few decades worth of experience. But no matter how you choose to protect yourself, choose something - and make sure when you do, you have a team that understands the basic aspects of creating secure solutions. Talk to our team or send firstname.lastname@example.org an email - even if we can't help you, we can give you an idea of who can.
This article was published July 16th, 2015