Is Your Software Secure?

Is Your Software Secure?

Taking a proactive, multilayered approach to software development and building security at every step will result in the most secure apps.

By Lana Gates

The topic of software security garnered much attention over the past year, the most notorious cases being Edward Snowden’s leaks about the National Security Administration’s spying on the general public, and Target’s security breaches of 70 million contacts and 40 million debit and credit card accounts. 

Security breaches continue to make headlines as more business is conducted online on software systems spanning the globe, giving hackers more possible entry points. Add to that the rise of distributed denial-of-service attacks—rendering systems unusable for their intended users, mobile malware, and insider threats, and you have a timid public when it comes to secure applications (apps). 

Believe it or not, the state of software security is much better now than it was 10 years ago. Today, most people in the software business know they should be making their apps secure. "The days of getting things out fast and skipping security were 10 years ago—not so much today," says Gary McGraw, CTO, Cigital, a software security consulting firm based in Washington, D.C. McGraw has been bringing software security to the forefronts of company executives’ minds since the early 2000s. In fact, he wrote the first book on the topic—Software Security: Building Security In—in 2000. 

McGraw is proud of the fact that software is in better shape today than it was decades ago. The worldwide security technology and services market was targeted to reach $67.2 billion in 2013, according to market research firm Gartner, an 8.7 percent growth rate over the previous year. Research firm IDC expected the security and vulnerability management market to top $4 billion in 2013, and forecast the number to exceed $6 billion in 2017. Software security "will be a bigger percentage of computer security every year until the growth rate changes," says McGraw.

So if it’s such a big market, meaning there are plenty of tools and solutions out there for building secure software, why is software security still headlining news reports for negative reasons? What’s really coming to light in the media, McGraw says, centers around the retail industry. 

"Most of the retailers in the news are approaching security in the old paradigm," he explains, "securing the network and worried about whether servers are set up properly. The problem is they built their point-of-sale system out of software, and nobody determined if that software was secure."

Part of that could be attributed to inadequate app development processes. The 2013 Trustworthy Computing Survey, commissioned by Microsoft and carried out by ComScore, found that, although security is a top priority for the majority of app developers worldwide, it’s not a priority for 42 percent of them. (See Fig. 1.) In the U.S., however, 72 percent of developers do take app security into consideration, the report revealed. 

Minimum Security MeasuresMost app developers know it’s easy to inadvertently introduce tens of thousands of bugs into software that can lead to security problems. On top of that, you can have design flaws. McGraw refers to all of these issues as the "bug parade." The key to secure software, he believes, is not to create those problems in the first place. 

That may be easier said than done, but "there are three really important activities that should be in every software development lifecycle (SDLC): code review with a static analysis tool, architectural risk analysis, and penetration testing," he says. 

A static analysis tool—also referred to as source code analysis or white box testing—examines software at the source code level in the coding or requirements phase of the SDLC to find bugs in the code. One of the most popular tools for this, McGraw points out, is Hewlett-Packard’s (HP) Fortify Static Code Analyzer, which finds security vulnerabilities and provides helpful hints on how to rid the code of them. 

Other options include Static Source Code Analysis with CodeSecure from Armorize Technologies—now part of Proofpoint, Static Code Analysis from Checkmarx, Cigital’s SecureAssist, Coverity’s Code Advisor—recently acquired by Synopsys, IBM’s Security AppScan, Klocwork’s Insight, Parasoft’s Test products, Source Patrol from Pentest, Veracode from Veracode, and a collection of open-source tools. 

"If you don’t have a static analysis tool, you are way behind," advises McGraw.

Static code analysis on its own is not enough to prevent security breaches. In addition to that, it’s important to perform architectural risk analysis or assessment—sometimes referred to as threat modeling or vulnerability assessment—in the SDLC’s design phase. This step involves looking for flaws in the software architecture. "It’s not about a bug, but about design problems that make your software broken even if it were perfectly implemented," explains McGraw.

Tools to aid in analyzing architectural risk include CAST Software’s Architecture Checker, Cigital’s Architecture Analysis service, Coverity Architecture Analyzer, Lumension Scan, McAfee’s Network Architecture Assessment service, Security Innovation’s Architecture & Design Review service, Sourcefire’s—now part of Cisco—Pre-deployment Architecture Assessment Service, and a handful of open-source apps.

It’s also important to perform penetration testing in the verification phase. This step occurs once the software is complete, when simulated attacks are carried out against it. This should not be the only security measure used, cautions McGraw. "You should not start with penetration testing, because when you find problems, it’s very expensive to fix them. That’s because penaetraion testing happens late in the software development process."

Several companies offer security products. Acunetix offers Web Vulnerability Scanner to test Web apps for vulnerabilities. Cenzic has a collection of tools for performing penetration testing on cloud, Web, hybrid, and mobile apps. Core Security provides penetration testing through its Impact Professional product. Companies offering penetration testing services include Cigital, Denim Group, and Security Innovation. And, as with every category, open-source solutions are available as well.

A Multilayered ApproachGlobal healthcare company Aetna, headquartered in Hartford, CT, uses all of these essential security activities—which McGraw refers to as "touch points"—and more, according to Jim Routh, CISO, Aetna.

Routh’s team, which refers to the measures as controls, carries out component lifecycle management, where they employ a tool that scans for vulnerabilities in open-source libraries. "It allows us to choose which libraries to make available to app developers," he explains. 

These are a new breed of tool, says McGraw, that are built directly into the editor a developer uses in the integrated development environment. "It stops the developer from typing the wrong thing," he says. "Instead of finding a bug when they thought they were done, they find it just when they’re getting started."

Although many people think open-source software is free from bugs, that’s not always the case, points out Routh. "About 26 percent of the most commonly downloaded open-source components have high risk of vulnerabilities," he says.

Vendors of component lifecycle management tools include CAST Software, Cigital, Sonatype, and White Source Software, and McGraw notes that these types of tools are becoming more popular.

For static analysis, rather than an industrial type of tool, "I choose to do it in a distributed way that is easier for developers to use, with educational context or abilities that allow them to interpret results," says Routh. Although not as robust as an industrial tool, his choice prioritizes results based on vulnerability.

Another touch point Aetna employs is threat modeling in the app development—or design—phase. This is where an experienced information security architect works with app designers as they’re designing the functionality, and thinks of potential threats, says Routh. Then the designers and security architect change the design of the data flow accordingly to alleviate any possible threats.

The next step, dynamic analysis, takes place in the quality assurance phase. Where static analysis looks at code from the inside out, dynamic analysis looks at it from the outside in, explains Routh. "It’s part of quality testing that mimics what a hacker would do in a browser interface."

Dynamic analysis tools include HP QAInspect and WebInspect, IBM Security AppScan Enterprise Dynamic Analysis Scanner, Intel Thread Checker, Parasoft Insure++ and Jtest, and Veracode DynamicDS.

Then there’s a Web app firewall (WAF)—an automated tool that sits outside the Web server. "It operates like a proxy that Internet traffic goes through. It has rules-based technology that filters out certain types of bad behavior," notes Routh. "App behavior that’s normal, it allows. But behavior that’s bad—like what a hacker would do—it prevents."

Makers of WAFs include Akamai, Barracuda Networks, Cisco, CloudFlare, Dell, F5 Networks, Fortinet, Imperva, Sophos, and Trustwave.

McGraw warns that a WAF by itself is not enough to make apps secure.

AggregationRouth says that he needs all of these controls in place to keep his company’s software secure. "You need multiple layers," he says, adding, "we have key performance indicators for every single layer that tell us the effectiveness of the controls in place, and then we make adjustments."

For example, if a vulnerability shows up in the penetration testing phase that wasn’t discovered through the previous controls, then Routh’s team goes back and adjusts the static rules to prevent that from happening.

He and McGraw both touch on the fact that developers and security teams are starting to collaborate on software development as a way to move security efforts up earlier in the SDLC process.

He notes that developers really want to do the right thing. "They love to build stuff that people use, and have their software fielded in the world. If you can help them do their job better and teach them how to do it right, they generally react well to that."

A perfect example of this is the Building Security in Maturity Model (BSIMM), which McGraw, one of its co-creators, defines as a tool for measuring your SDLC. "It’s not a methodology," he’s quick to point out. "It will tell you how well you’re doing with your software security initiative, but it will not tell you what to do."

"You can’t really figure out what you should be doing unless you can measure what you are doing," he adds. The measurement tool includes data from 67 companies’ software security initiatives, and impacts the work of 272,000 developers, notes McGraw. 

Although the BSIMM presents real-world data from real companies, not everyone is sold on its benefits. WhiteHat Security, for instance, stated in its 2013 Web Site Security Statistics Report, "unfortunately, the observed data provides zero indication that the activities actually work. By work, we mean do they reduce vulnerability volume, speed up time-to-fix, improve remediation rates, and of course decrease the occurrence and severity of Web site breaches. The observations in the study are not paired with outcomes. As such, BSIMM could actually represent firms that organizations should not be like if they want to keep from getting hacked."

Third PartyAetna’s security team uses the BSIMM to understand the maturity level associated with the controls in place by third-party developers. Routh knows how many of the 67 companies involved are performing which security activities. "When choosing a third-party vendor to build or host a product that has information protection risk, we develop an understanding of the maturity of security controls in their development processes," he explains. "It’s essentially a process maturity tool."

Another security measure Aetna employs in third-party development is binary static analysis—which loads binary code through a portal, hosted by a third party, that scans the software for vulnerabilities or defects.

"The details on the defects are shared with the vendor, and a summary of the test results is shared with us. This is a way of testing software for defects without giving access to the source code," notes Routh, who leads the Third Party Software Security Working Group for the Financial Services Information Sharing and Analysis Center.

A component library for open source, like what Routh mentioned in traditional software development, is also used with third parties. 

Mobile SecurityDeveloping secure software for mobile environments is a whole different animal than developing for the Web, notes Routh. "For example, mobile software is distributed as binaries running on the consumer device. This provides an opportunity to access information about the device configuration and the user behavior," he explains. "This information can be used to improve a user experience in how the mobile app performs, while it can also capture information that could be used in a way to cause privacy concerns."

The privacy line or threshold is different for mobile, points out Routh. "The mobile app developer needs to know what the privacy policy is for the firm publishing the mobile app," he says. "They also have to decide what consumer mobile ‘ecosystem’ controls are required." 

A potential threat in this playing field is reverse engineered apps that are re-released as malware-infected, real-looking versions that can wreak havoc when downloaded. Another is parasites, when a brand-looking app actually contains malicious code and monitors the user’s SMS messages, for example, applying a keyword filter to texting. When a keyword is entered, the user receives a targeted ad, or spam. 

Market OutlookThanks to all of these controls, software is much more secure today than it was 10 years ago. But developers must take a proactive approach to building secure apps to keep it that way.

McGraw is certain that the news will continue to report on security breaches. This is due to the fact that a lot of firms in different verticals—such as retail, medical informatics, and hospitality—have not fixed their systems yet, he says. 

They will make their systems more secure out of necessity. And as a result, "the market is going to get bigger faster because the large vendors know what to do and are doing it," he notes. New verticals will add to that. SW
Apr2014, Software Magazine