software security

Checkmarx CTO on new compiler-free vulnerability scanner

Recently, Checkmarx CTO Maty Siman filled me in on the new source code security scanner, Checkmarx Virtual Compiler. Designed to enable compiler-free, real-time source code vulnerability scanning, the tool promises to facilitate testing of code throughout the development process without compiler or operating system compatibility problems.

Virtual Compiler will be used by development teams “test uncompiled and unlinked code, their independent modules or any other application subsets in a desktop deployment that reinforces good security awareness and practices as the code is written,” said Siman.

Auditors and chief information security officers (CISOs) can benefit from being able to test code earlier in the software development lifecycle (SDLC), said Siman. They can also use Virtual Compiler to inspect legacy code.

Using source code analysis tools is a must for building secure software, according to SearchSoftwareQuality.com security expert Kevin Beaver. In his tip, The role of QA pros in software security, he wrote that source code vulnerability checkers “are essential for rooting out software vulnerabilities that would otherwise be next to impossible to find.” He names Checkmarx, QAInspect and Klocwork tools as good options.

Virtual Compiler solves some problems that static code analysis tools haven’t addressed previously, Siman said in our interview. Most major static code analyzers have only scanned post compilation and required buildable code. As a result, static code analysis required a complete, buildable project to run against. So, scans usually have to take place near the end of development, and repairs required going back and fixing code whose problems probably manifested themselves and possibly grew during development.

“Checkmarx Virtual Compiler eliminates the buildable code requirement by removing the dependency on compilation and linking for software testing,” said Siman. “It transforms code, whether freshly written or old legacy applications, into a form that contains structure and application flow properties. Testing is not dependent on having all modules complete, duplicating the development environment or creating a final build-test harness. Instead, scanning can take place early, and often, as the code is developed. Once scanning is complete, all code and flow properties are stored in a data base that can be interrogated for vulnerabilities.”

Checkmarx Virtual Compiler is part of a suite of products that can be purchased for onsite use or as a service. Prices for onsite usage start at $15,000.

Software security threats: Changing QA a must

Software quality assurance (QA) and software security teams have long been separate islands within development organizations. That division is giving data pirates carte blanche to compromise software, cyber-security industry veteran Barmak Meftah told me recently.

“Today, we are witnessing the greatest increase in cybercrime,” said Meftah, Fortify Software’s technology senior vice president. “Yet most organizations continue to bolt security on after the fact. Organizations need to build in security first, not layer it on later.”

Hackers have always exploited security vulnerabilities missed during development, but security experts worry the scope of attacks will increase. For instance, they think hackers will increase SQL injection attacks on Flash, JavaScript errors. Another unchecked threat is cross-site scripting, which is still rampant in the Web 2.0 world. “It’s literally on every site I view,” Web security consultant Kevin Beaver told me in another conversation.

Mehta and I talked about how this code-red software environment has pushed software security assurance to the forefront in 2009. He listed these reasons:

• Heightened executive pressure for software security: As
  software’s critical role in running business operations becomes apparent, non-technical executives have become increasingly interested in understanding broader approaches that manage risk, not technology.
• The need for a holistic platform for software security: Traditionally, companies have only been able to buy point products to secure applications during development, QA or in production. That doesn’t work now that data predators, who are continually becoming more sophisticated, use multiple methods to leverage software vulnerabilities to attack organizations. Reacting to this pressure, companies have been forced to adopt multi-prong approaches that include pen testing, static analysis, web application firewalls and so on.
• A business-driven focus on more security from development to production: Eliminating risk leads to preventative, not reactive, security testing. There’s a move from SDLC only to security teams are attempting to bring about significant cultural and process changes to elevate security awareness and governance across an organization.

Today, Mehta said, QA teams must pick up responsibility for security and work with development to make fixes. This is a marked change from the recent past, when QA and security managers have rarely crossed paths. “They have been different organizations with different objectives,” Meftah said. QA has focused on common use cases to uncover problems that typical users may encounter. Security has focused on abuse cases, hoping to uncover a corner case that could allow an adversary to penetrate and exploit a system.

Now, Mehta told me, QA and security teams have to cross the chasm to work on these issues and more together. QA involvement is key way to shift from a reactive security approach — such as patching and firewalls — towards a preventative approach that builds security in from the beginning.
This conversation left me wondering how many companies are pairing or have paired their QA and security teams and to what extent. Or, perhaps some QA and security managers believe they should continue as separate entities. I’d like to hear from you on this subject, either in comments below, or via email at  editor at searchsoftwarequality.com.

Better security through better visualization

I’m always excited when I stumble across an area which is an intersection of two of my favorite topics. Recently, I started reading Applied Security Visualization by Raffael Marty. In the book, Marty introduces the concepts and techniques of network visualization and explains how you can use that information to identify patterns in the data and possible emerging vulnerabilities and attacks. It’s the perfect merger of data visualization (a topic fellow SearchSoftwareQuality.com expert Karen Johnson has me hooked on) and security.

This morning, I stumbled across an ITworld article Marty published earlier this month on getting started with security visualization. In the article Marty provides three simple must-dos and don’ts:

The three “must-dos” from the article:

• Learn about visualization: It’s important for security people to understand the basics of visualization. Learn a bit about perception and good practices for generating effective graphs. Learn about which charts to use for which kinds of use cases and data. This is the minimum you should know about visualization.
• Understand your data: Visualization is not a magic method that will explain the contents of a given data set. Without understanding the underlying data, you can’t generate a meaningful graph and you won’t be able to interpret the graphs generated.
• Get to know your environment: I can be an expert in firewalls and know all there is to know about a specific firewall’s logs. However, if you give me a visualization of a firewall log, I won’t be able to tell you much or help you figure out what you should focus on. Context is important. You need to know the context in which the logs were generated. What are the roles of the machines on the network, what are some of the security policies, what type of traffic is normal, etc. You can use visualization to help understand the context, but there are things you have to know up front.

And the three “don’ts”:

• Don’t get scared: The topic of security visualization is a big one. You have to know a lot of things from visualization to security. Start small. Start with some data that you know well. Start with some simple use cases and explore visualization slowly.
• Don’t do it all at once: Start with a small data set. Maybe a few hundred log lines. Once you are happy with the results you get for a small data set, increase the size and see what that does to your visualization. Still happy? Increase the size some more until you end up with the complete data set.
• Don’t do it yourself: If you’re in charge of data analysis and you aren’t the data owner (meaning that you don’t understand the application that generates the data intimately well) you should get help from the data owner. Have the application developers or other experts help you understand the data and create the visuals together with you.

If you’d like to read more on the topic (and see some cool examples) check out Raffael Marty’s blog.

Does PCI compliance make your data secure? Nope.

Another week, another cascade of information pouring unintentionally out of another unwitting company — this time it is Heartland Payment Systems.

As a result, Heartland customers will get letters letting them know that they should watch out for unexpected transactions; hundreds of man hours are going to be spent understanding the circumstances of the breach; and already the inquisitors of information security are pounding keyboards mercilessly, pillorying the Heartland team for this most recent episode.

Heartland is reported to have been PCI-compliant. That’s the interesting nugget in this story and it’s one we have seen before. PCI compliance didn’t save Heartland from losing so much data that the company could more aptly be called ”Heartland Pay-out Systems” for the next several months, as it pays out clean-up, fines, and costs.

Assuming Heartland did what was asked by PCI auditors, and that it provided sufficient access for the assessor to do their job: if I were Heartland I would be really not happy. If there was some fundamental communication breakdown, I would be similarly displeased.

I mean, really, what is the purpose of issuing one of the most proscriptive standards on security if measurement of compliance with it is so meaningless? My information about this data breach comes from public sources and not from Heartland or their PCI assessors, but here is what I can glean:

1. Heartland was certified as PCI-compliant. (See the list of PCI-compliant service providers. Heartland is on Page 12.)

2. Part of PCI compliance includes section 3.4 which says that the credit card data must be encrypted anytime it is stored. Now, while some will argue that there should be a new requirement calling for encryption of internal networks (which does not exist in PCI currently), any entry-level programmer knows that as soon as I read my input for the credit card number, I am storing it, even if only in memory. (See the complete PCI DSS v1.2 standard.)

3. Malicious code — likely a sniffer – grabbed private unencrypted data (they called it “recorded data” which sounds a lot like like storage to me) off of the wire as the data was being sent for processing. (See here for one of many articles about the breach.)

So, Heartland wasn’t compliant, period, according to my read; but note that I am not a certified reviewer.

Is this their fault or their assessor’s? I have no idea, but I do believe that it is the responsibility of the assessor to have done this simple analysis and identified the weakness.

If Heartland was complicit in this, then I have no defense for them. If, however, in a business climate charged with specialization and outsourced expertise, they relied on their provider to help them validate that they had done enough, then the responsibility and the spotlight should be turned at least equally on the process and the people who gave them the useless rubber stamp.

Does being PCI-compliant make you secure? Nope. Not the same thing at all, but that isn’t the issue here.

Does thinking you are compliant when you are not even close create some substantial risk?

You bet.