15.07.16 - Pretend Security

Shortly after we published this article, SC Magazine reported that thousands of vulnerabilities were found in government systems (reference since removed). This brought to our attention a report by the Office of the Inspector General showing shortcomings that may have been a part of the OPM data breach. Compare this with the information we shared in our personal Auditing experiences as we tie this article's concepts together at the end.

Securing applications, systems, services, and technologies (henceforth referred to as solutions) is probably more complicated than it seems even to those that don't understand it. Any company that says they have a new, safer, more secure way to do something yet doesn't have anyone with security experience on their founding team, executive staff, or advisory board, is doomed to fail. Here are some reasons why.

Requirements

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.

Technology

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).

Common libraries bring lots of functionality, but also lots of bugs. They are targeted by attackers because of their widespread use. Companies exist with the sole purpose of breaking these technologies and gaining access to systems. They sell their exploits for upwards of $100,000 each, and vendors aren't notified of the flaws. These 0-day exploits are very dangerous because there is no fix for the problem. In 2013, the NSA spent $25M purchasing 0-day exploits. Do you really think a couple guys good at crypto with a web browser, some javascript, and gmail are going to hide you from the NSA? Guess again.

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.

Process

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.

Auditing

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.

Perspective

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.

Conclusion

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 support@definisec.com an email - even if we can't help you, we can give you an idea of who can.