If you’re a current or former University of California, Berkeley student, and have taken advantage of the on-campus health services at some point in the past ten years, you may want to check your credit report. The university today announced that it has discovered a massive data theft involving 160,000 current and former UC Berkeley students.
An audit of the Web applications connected to air-traffic control networks found hundreds of critical vulnerabilities in the software and documented dozens of cyber incidents that continue to be unresolved, auditors stated in a report to the Federal Aviation Administration released this week.
During the investigation, auditors from the Office of the Inspector General for the U.S. Department of Transportation and accounting firm KPMG found 763 high-risk security issues in the Web servers set up to deliver information to the public and to FAA employees. The investigation also discovered more than 3,000 other vulnerabilities, according to the report (pdf). The vulnerabilities include incorrectly configured Web applications and software with known security issues that were not regularly patched.
Payment card industry compliance is confusing for many ecommerce merchants. But it potentially affects every merchant that accepts credit cards payments. Failure to understand the PCI compliance standards could result in higher merchant account fees and fines from the credit card issuers.
Merchants oftentimes have similar general questions on PCI compliance. We posed some of them to Tim Erlin, principal product manager for nCircle, a security consulting and compliance firm that offers PCI-related services, among other compliance services. Those questions, and his answers, are below.
What is PCI?
Erlin: “PCI generally refers to the Payment Card Industry Data Security Standard, or the PCI DSS. This standard was developed by the PCI Security Standards Council, which is a consortium of the major credit card brands (Visa, Mastercard, American Express, and Discover). It represents the combination of two previous separate programs: the Visa Cardholder Information Security Program (CISP) and MasterCard’s Site Data Protection program (SDP). The goal of the PCI DSS is to specify a common standard for protecting cardholder data from compromise.”
How does PCI compliance affect my ecommerce business?
Erlin: “If you accept credit cards as a form of payment, you are required to be compliant with the PCI DSS. In most cases, smaller merchants can achieve compliance by using compliant shopping carts and payment gateway services. If, however, you choose to collect and store credit card data as part of your business, you’ll need to carefully consider the requirements of the PCI DSS.”
“Larger volume merchants (more than 20,000 credit card transactions annually) will need to complete some specific validation requirements to demonstrate compliance with the PCI DSS. The requirements range from filling out a self-assessment questionnaire to an onsite audit from a qualified auditor. You can find out more details about merchant levels here.”
Where can I learn more about PCI?
Erlin: “The PCI Security Standards Council is the authoritative source for information. You can find their website at http://www.pcisecuritystandards.org. You can also look to the card brands themselves for additional information.”
My annual sales are very small. Do I still have to comply with PCI?
Erlin: “Every merchant that accepts credit cards must comply with PCI, but smaller merchants often achieve compliance by using compliant services. If you don’t store, transmit or process any credit card data, then your systems are out of scope for PCI DSS compliance.”
How do I know if my ecommerce business is PCI compliant?
Erlin: “Do you store, transmit or process credit card data? If the answer is yes, then you are required to fill out a self-assessment questionnaire to demonstrate PCI compliance. You may be required to perform other work to demonstrate compliance depending on your merchant level.”
“If you do not store, transmit or process credit card data, but do accept credit cards through a payment gateway or merchant account provider, then you should validate whether your providers are PCI compliant.”
What happens if my business is not PCI compliant?
Erlin: “If your business is not PCI compliant there are various measures that the card brands can take, ranging from warnings and monetary fines to revoking your ability to process transactions entirely. More importantly, the PCI DSS allows you to assure your customers that you’re protecting their credit card data appropriately.”
If my business is PCI compliant, does it reduce my insurance liability?
Erlin: “Generally, no. If you’re not compliant and experience a breach, however, you can be open to legal action from the affected customers.”
Will PCI compliance reduce my business’s merchant account fees?
Erlin: “This isn’t generally the case. In fact, it can increase the cost. Merchant account providers have to demonstrate their own PCI compliance, and they can and have passed that cost onto their customers.”
Where can I find a list of shopping carts and hosts that are PCI compliant?
Erlin: “Unfortunately, there is no single list of compliant shopping carts, hosts or other providers. However, because PCI compliance is a basic requirement for accepting credit card payments, all of the most common hosted shopping carts are PCI compliant. Choose the shopping cart that has the features and functions you need, then validate that their service is PCI compliant.”
United States: American Recovery & Reinvestment Act Significantly Impacts HIPAA
14 March 2009
Article by Debra Bogo-Ernst, Rebecca Eisner Jeffrey P. Taft, and A. John P. Mancini
Originally published March 12, 2009
Keywords: American Recovery & Reinvestment Act, ARRA, Health Insurance Portability and Accountability Act, HIPAA, HITECH Act, Covered Entities, Business Associates, direct liability
The American Recovery & Reinvestment Act of 2009 (ARRA), signed into law on February 17, 2009, includes significant changes to the Health Insurance Portability and Accountability Act of 1996 (HIPAA). More specifically, Title XIII of ARRA, known as the Health Information Technology for Economic and Clinical Health (HITECH) Act, greatly expands the HIPAA obligations of “Covered Entities” and “Business Associates.”
Direct Liability for Business Associates in Certain Circumstances
Previously, Business Associates — persons who perform any function or activity involving the use or disclosure of Protected Health Information on behalf of a Covered Entity — were not directly liable for HIPAA violations. Instead, Business Associates had the potential for contractual liability to Covered Entities through contracts known as Business Associate Agreements. The HITECH Act now imposes direct civil and criminal penalties on Business Associates for certain security and privacy violations under HIPAA.
Under the HITECH Act, the majority of the HIPAA Security Rule now directly applies to Business Associates in the same manner as it applies to Covered Entities. For example, Business Associates will now be required to implement and maintain certain security policies and procedures, appoint a security officer and provide related training.
In addition, the HITECH Act imposes new Privacy Rule-related obligations on Business Associates. More specifically, the HITECH Act provides that Business Associates may use and disclose Protected Health Information only to the extent that such use or disclosure complies with certain requirements in Business Associate Agreements. Effectively, by way of this statutory tie to certain contractual provisions, Business Associates must directly comply with aspects of the Privacy Rule.
The HITECH Act specifically requires that Business Associate Agreements be modified to incorporate the new Security Rule and Privacy Rule requirements.
New Notification Requirements
Covered Entities and Business Associates alike will be subject to new notification requirements. For example, within 60 calendar days of discovering a breach of “unsecured” Protected Health Information (including breaches that should reasonably have been known), Covered Entities must notify:
Individuals with respect to a breach of their information;
“Prominent media outlets serving a State or jurisdiction” if more than 500 residents of such State or jurisdiction are affected; and
The Secretary of the Department of Health and Human Services (Secretary).
The Secretary will post a list of each Covered Entity involved in a breach of “unsecured” Protected Health Information concerning more than 500 individuals on the Department of Health and Human Services’ web site.
Enforcement Expanded to State Attorneys General
The HITECH Act empowers state attorneys general to bring civil actions in federal court if they have “reason to believe” that “one or more of the residents of that State has been or is threatened or adversely affected” by a violator for injunctive relief or statutory damages as well as attorneys’ fees. Previously, the Secretary had the sole right to enforce HIPAA through her delegations to the Centers for Medicare & Medicaid Services (Security) and the Office of Civil Rights (Privacy).
Increased Penalties and Compensation for Harmed Individuals
The new legislation significantly increases the existing civil monetary penalties for each violation. Civil penalties now generally range from $100 to $50,000 per violation, with caps of $25,000 to $1.5 million for all violations of a single requirement in a calendar year. The severity of the penalties is based upon the violator’s knowledge: from no knowledge (and by exercising reasonable diligence would not have known) of violation, to reasonable cause for the violation, to willful neglect. The Secretary is required to impose penalties for “willful neglect” violations. Within three years of the HITECH Act, the Secretary must establish, via regulation, a methodology for providing a percentage of any civil monetary penalty or monetary settlement collected with respect to such offense to any harmed individual.
The effective dates for the HITECH Act changes to HIPAA vary. For example, the increased penalty provisions are effective immediately. In contrast, other provisions will be effective within a year of the legislation (i.e., February 2010) or after related regulations are published.
There are many other provisions of the HITECH Act that will affect the HIPAA obligations of Covered Entities and/or Business Associates
via United States, IT & Telecoms, American Recovery & Reinvestment Act Significantly Impacts HIPAA – Mayer Brown – 14/03/2009, Information Security & Risk Management, Information Technology Law, Data Protection, Pharmaceutical, Healthcare & Life Sciences, Healthcare.
The recently enacted economic stimulus law includes new requirements for how companies must notify people of breaches to their protected health information. Some experts say the rules could lead to federal breach notification requirements for other types of data.
Health data experts are still studying provisions in the $787 billion spending law that will expand what health care-related businesses are required to do when they discover unsecured, protected medical data has been breached.
The law gave the Health and Human Services Department 60 days to issue guidance on the types of technologies and methodologies that should be used to make protected health information secure — unusable, unreadable or indecipherable to unauthorized people.
Under the new law if a health care provider, health plan administrator or health care clearing house covered under the Health Insurance Portability and Accountability Act (HIPAA) has a breach to the personal medical data it holds which is not secured in the way HHS recommends, that organization will have to notify within 60 days each person whose data is believed to have been compromised. Companies that work with those entities that handle the medical data will also have to notify the company they work for if a breach is believed to have occurred on their watch.
“It is a big change in terms of the scope of the laws…and it now establishes a federal standard so regardless of what state you do business in, if you do business in the health industry, you are likely to be subject to these breach requirements,” said Kathryn Roe, an attorney focused on health care with the firm Neal, Gerber and Eisenberg in Chicago.
Federal lawmakers have made several recent attempts to pass national data notification requirements for data breaches of all kinds, but thus far those efforts have stalled and states have promulgated their own requirements. Without a national rule for data breach notifications, more than 40 states have developed their own data breach notification requirements.
Lisa Sotto, head of the privacy and information management practice at law firm of Hunton and Williams and an expert on privacy and data security, said the current situation is complex because data breaches rarely affect residents of just one state and laws often differ.
“I think what could happen here is this could set the bar and become the standard of data compromises of other types of sensitive personal data,” Sotto said.
The new law, only applicable to protected medical data, requires that individuals affected by the breach are notified in writing and that local news media are alerted of the breach in cases where more than 500 people are believed to have been affected. The provisions also require the companies to notify HHS of any breach and to do so immediately if it involved 500 people or more. HHS will post on its Web site a list of the HIPAA-covered entities involved in the breach if the problem reaches the threshold of 500 people having been involved.
Pam Dixon, executive director of the public research group World Privacy Form, said the law was also significant because it includes requirements for organizations not covered under HIPAA. She added that the law was an acknowledgment that certain kinds of data need more protection.
Regardless of how they are made, breach notifications, to the extent possible, will have to include:
* A description of what happened, including when the breach occurred and when it was discovered.
* A description of the types of unsecured protected health information that was breached.
* The steps individuals should take to protect themselves against potential harm from the breach.
* A description of what the covered entity involved is doing to investigate the breach, mitigate losses and prevent future breaches.
HHS also was given one year to submit to Congress what will be the first of an annual report on medical data breaches that have occurred and what was done in response to them. The department also was given 180 days to disseminate interim final regulations to enact the law’s requirements.
It’s a gross oversimplification of an utterly staggering technical and social challenge, and he knows it as well as anyone, but it’s hard to argue with PCI Security Standards Council General Manager Bob Russo’s assertion that when it comes to improving electronic data security and related matters of individual privacy, “something is much better than nothing.”
Since the massive, potentially record-breaking security breach at Heartland Data Systems in late January, the Payment Card Industry Security Standards Council and its DSS Data Security Standard have been put under a microscope and criticized for foisting on companies an impractical IT security mandate that detractors say does not actually meet its goal of making it harder for companies that handle credit and debit card data to be fleeced similarly to Heartland.
Some highly respected security researchers and practitioners have come out since the Heartland robbery and questioned the viability of the entire DSS effort, perceived as being out of touch with real-world IT environments and insufficient to help organizations avoid exploitation. A handful have gone as far as saying it actually makes the process even harder.
And after all, here’s a Tier 1 company that’s likely had to push to abide by the technological and process-oriented stipulations required under the PCI Standard as much and as long as any other, and it just got positively hammered.
However, visiting Boston on a media tour organized to share some new elements of the PCI Council’s larger plans the week of Feb. 23, Russo and new PCI Security Standards Council Chairman Lib de Veyra — an executive at and appointee of JCB International Credit Card — made a lot of credible points. Mostly, because they firmly recognized the reality that no standard is perfect and that DSS as it exists is only a first step in a long evolutionary process.
Not to be misinterpreted, the PCI Council is satisfied with what it’s put in place thus far, given the challenge at hand, Russo and de Veyra said.
The parts of DSS that need to be tweaked to address the vast diversity of infrastructure and applications employed by all the retailers, merchants and processors, as well as all the techniques utilized by attackers, will be addressed by taking feedback directly from the very companies that must comply with the standard, the PCI Council representatives said. And truthfully that has been at the very least a consistent message of the organization all along.
A number of powerful banking, retail, technology and government players are also involved in the PCI Advisory Board.
And the Heartland incident, as well as those reported at other companies that have been at some time certified as PCI compliant, including TJX Companies and Hannaford Brothers, in no way proves that the standard is clearly lacking in some specific area, they said.
The PCI leaders said in addition to having not yet shared specific details with the Council of exactly how they were individually victimized by fraudsters, the fact that these companies were at one time judged to be in conformity with DSS in no way guarantees that they were at the time they were attacked.
“Just because a company gets a clean bill of health today doesn’t mean they can’t be infected tomorrow,” de Veyra said. “Organizations are making configuration changes and broadening adoption of technologies like wireless all the time; the guidelines in DSS are something that you have to continue to monitor and maintain all the time.”
And many of the Council’s initiatives, including plans to launch two new standards aimed at improving embedded security features, or “host security modules,” built into card data transaction processing hardware, and regulations for UPTs (unattended payment terminals) such as gas pumps and ticketing kiosks, will help push the entire industrywide process forward, they said.
The PCI Security Standards Council will also continue to push DSS overseas, in Europe and APAC specifically, where the guideline has faced some resistance from card handlers. But the effort launched by the world’s largest card companies — American Express, Discover, JCB, MasterCard and VISA – remains undaunted in its pursuit, PCI’s chief spokespeople said.
“Addressing the criticism comes down to communication; once we have enough information from companies like Heartland to truly examine what happened, we can understand how it relates to DSS,” de Veyra said. “And working with all the companies on our Advisory Board, meeting with them and incorporating their feedback over time, will be the most important aspect of maturing the standards.”
Another new element of DSS will be a technological tool, a sort of stripped-down PCI diagnostic application provided by the Council to offer organizations still getting started with the standard a more “prioritized approach to DSS.”
The Prioritized Approach tool will help companies track their ability to meet basic milestones of achieving compliance with DSS, the representatives said. The first three steps — preventing the improper storage of electronic data, securing the network perimeter and securing applications — have obviously been proven hard to accomplish for many organizations, and some might argue most or even all.
But most importantly, the idea is to promote gradual coalescence of a world where every company affected by the PCI mandate has at least greatly augmented and formalized its approach to, if not its execution of, securing electronic data, the leaders said.
“No standard is ever going to completely stop what we’re seeing right now with cyber-crime, but the reaction we’ve seen to PCI after some of these incidents like Heartland has been absolutely unfair, because we don’t even know if they were compliant,” Russo said.
In terms of whether incidents like the breaches at Heartland, TJX and Hannaford Brothers have damaged public perceptions of DSS, the industry veteran said, as in any case, there is no shortage of opinions.
“You can sit there and look at it from one side and say, you have this standard but these incidents have still happened, and that proves something isn’t working,” Russo said. “But what you don’t know at the same time is, If we didn’t have DSS as it stands in place, how many more of these incidents might we have had?”
I’m sure that there are valid criticisms of various aspects of PCI — some very smart people have spent time voicing their questions already.
But, I’m curious to know whether they’d agree at the end of the day that something is better than nothing.
Matt Hines has been following the IT industry for over a decade as a reporter and blogger, and has been specifically focused on the security space since 2003, including a previous stint writing for eWEEK and contributing to the Security Watch blog. Hines is currently employed as marketing communications manager at Core Security Technologies, a Boston-based maker of security testing software. The views expressed herein do not necessarily represent the views of Core Security, and neither the company, nor its products and services will be actively discussed in the blog. Please send news, research or tips to SecurityWatchBlog@gmail.com.
A new survey shows 44 percent of the wireless devices used by retailers are vulnerable to attacks by data thieves. And that’s the good news. A year ago, the same Motorola survey showed 85 percent of retailers were sitting targets for drive-by data attacks. New PCI standards phasing out Wireless Equivalent Protocol–the weakest form of encryption this side of no encryption at all–may hold the key to improved retailer wireless security.
The good news: A new survey shows retailers are beefing up their wireless security. The bad news: The same survey shows 44 percent of the wireless devices used by retailers are sitting targets for data thieves, suffering from weak encryption, data leakage, misconfigured access points and outdated access point firmware.
While that 44 percent number may seem shockingly high, Richard Rushing of Motorola’s Enterprise Mobility unit points to last year’s results that found 85 percent of retailers’ wireless devices were begging to be compromised.
“Retailers nationwide are improving wireless security, as quantified by the significant drop in vulnerable wireless devices that were discovered during this year’s monitoring efforts,” said Rushing, Motorola’s senior director of information security for mobile devices. “However, a significant majority of retailers are still susceptible to a network intrusion—a sign that wireless security remains an afterthought for many.”
The Motorola survey conducted by Rushing included a review of wireless data security at more than 4,000 stores in some of the world’s busiest shopping cities, including Atlanta; Boston; Chicago; Los Angeles; New York; San Francisco; London; Paris; Seoul, South Korea; and Sydney, Australia. While 68 percent of the sites were using some form of encryption for their laptops, mobile computers and bar-code scanners, 25 percent of those were still using outdated WEP (Wired Equivalent Protocol) deployments, the weakest protocol for wireless data encryption.
Click here for a glossary of wireless security terms.
Altogether, Motorola discovered almost 8,000 APs, with 22 percent of them misconfigured. Another 10 percent of the AP’s SSIDs (Service Set Identifiers) were poorly named, which makes it relatively easy for potential data thieves to zero in on the store’s identity. More than 32 percent of retailers had unencrypted data leakage, while 34 percent had encrypted data leakage.
“As wireless exploded over the last few years, retailers had a bunch of devices that connected to the [store’s] network,” Rushing said. “Then, you didn’t have people who knew both wireless and security. The security model is just coming into play the last two to three years.”
Rushing said one of the more overlooked security issues with large retailers is the cookie-cutter approach to wireless technology. By using the same technology, configuration, security and/or naming conventions at all retail locations, vulnerabilities repeat themselves across the entire store chain, rendering them susceptible to attacks.
“The bad guys had a huge head start,” Rushing said. “We’ve caught up with them, but we’re not necessarily ahead of them.”
Helping the retailers play catch-up are companies like Motorola and Aruba Networks. Both have recently introduced wireless enterprise security product lines that store, process, transmit and protect wireless data, including credit card information.
Also pushing the retailers to greater wireless security is the Payment Card Industry council, which issues requirements for security management, policies and procedures. With PCI members including VISA, American Express, Discover Financial Services and MasterCard Worldwide, the council leverages the standards to force retailers to improve their wireless security.
If a breach happens, retailers not deploying PCI security standards run the risk of losing the ability of processing customers’ credit and debit cards or incurring fines or restrictions on the use of customers’ cards. Both Motorola’s and Aruba’s enterprise wireless security systems are PCI-compliant.
Included in the PCI’s newest standards is a prohibition against new WEP deployments in the Cardholder Data Environment beyond March 31, 2009, and a requirement of the elimination of WEP from the CDE beyond June 30, 2010.
“Retailers are moving away from WEP more and more,” Rushing said. “Things are now moving in a different direction. It’s all becoming more mature. You have to deploy layered secured security.”
Still, 44 percent of retailers’ wireless devices are susceptible to unwelcome intrusions.
“If you’ve looked at wireless as long as I have, the shock goes away,” Rushing said. “It’s certainly better than it was, but, in my opinion, it’s a wonder there haven’t been more data thefts.”
Download this Free Book: Get the Facts on PCI Compliance and Learn How to Comply with the PCI Data Security Standard
Complying with the PCI Data Security Standard may seem like a daunting task for merchants. This book is a quick guide to understanding how to protect cardholder data and comply with the requirements of PCI – from surveying the standard’s requirements to detailing steps for verifying compliance.
PCI Compliance for Dummies arms you with the facts, in plain English, and shows you how to achieve PCI Compliance. In this book you will discover:
* What the Payment Card Industry Data Security Standard (PCI DSS) is all about
* The 12 Requirements of the PCI Standard
* How to comply with PCI
* 10 Best-Practices for PCI Compliance
* How QualysGuard PCI simplifies PCI compliance
The high cost of finding and patching application flaws is well known. Wouldn’t it be cheaper to write secure code in the first place?
One of the fastest growing areas in the software security industry is source code analysis tools, also known as static analysis tools. These tools review source code (or in Veracode’s case, binary code) line by line to detect security vulnerabilities and provide advice on how to remediate problems they find – ideally before the code goes into production. (See How to Evaluate and Use Web Application Scanners for tools and services that search for vulnerabilities as an outside attacker might.)
The entire software security market was worth about $300 million in 2007, according to Gary McGraw, CTO at Cigital, Inc., a software security and quality consulting firm in Dulles, VA. McGraw estimates that the tools portion of that market doubled from 2006 to 2007 to about $180 million. About half of that is attributable to static analysis tools, which amounted to about $91.9 million, he says.
And no wonder; according to Gartner, close to 90% of software attacks are aimed at the application layer. If security were integrated earlier in the software development lifecycle, flaws would be uncovered earlier, reducing costs and increasing efficiency compared with removing defects later through patches or never finding them at all, says Diane Kelley, founder of Security Curve, a security consultancy in Amherst, N.H. “Although there is no replacement for security-aware design and a methodical approach to creating more secure applications, code-scanning tools are a very useful addition to the process,” she says.
Despite the high degree of awareness, many companies are behind the curve in their use of static analysis tools, Kelley says, possibly due to the big process changes that these tools entail.
Key decisions in source code analysis
1) Should you start with static tools or dynamic tools or use both?
In addition to static analysis, which reviews code before it goes live, there are also dynamic analysis tools, which conduct automated scans of production Web applications to unearth vulnerabilities. In other words, dynamic tools test from the outside in, while static tools test from the inside out, says Neil McDonald, an analyst at Gartner.
Many organizations start with dynamic testing, just to get a quick assessment of where their applications stand, McDonald says. In some cases, the groups that start this initiative are in security or audit compliance departments and don’t have access to source code. The natural second step is to follow up with static analyzers, enabling developers to fix the problems found by dynamic analysis tools. Some companies continue using both, because each type yields different findings.
An important differentiator between the two types is that static analyzers give you the exact line of code causing the problem, while dynamic analyzers just identify the Web page or URL causing the issue. That’s why some vendors offer integration between the two types of tools.
According to the chief scientist at a large software vendor, dynamic assessment tools “tend to be brute force,” he says. “You have to hit every parameter to find the vulnerabilities, whereas static tools investigate the whole landscape of the application.” He recently chose a code scanner from Ounce Labs, after outsourcing the work to Cigital since 2006. He became interested in application security whencustomers began requiring PCI DSS certification. He plans to add in dynamic testing in the future, but the static analysis tool is the cornerstone of his application security program.
2) Do you have the source code?
Most static analyzers scan source code, but what happens if you want to analyze third-party software or code written so long ago that you only have the executable? In that case, Veracode, Inc. offers binary code scanning through a software as a service platform. “A vendor may not be willing to give you source code, but they will give you executables or binary,” Kelley says.
At the Federal Aviation Administration, Michael Brown, director of the Office of Information Systems Security, says he chose to use Veracode’s services this year because of the amount of vendor-written code the FAA anticipated to use as a result of its modernization of the national airspace system. Brown says he wanted to ensure the code was not only functionally correct and of high quality but also secure. He wanted a service rather than a tool to reduce the need for training. So far, the results have been eye-opening, he says. “A lot of the code didn’t really take security into account,” he says. “There were cases of memory leaks, cross-site scripting and buffer overflows that could have been a cause for concern.”
3) What do you currently use for software quality?
Some tool vendors, such as Coverity, Inc., Klocwork, Inc., Parasoft Corp. and Compuware Corp., originated in the quality-testing arena and have added security capabilities vs. vendors like Ounce and Fortify Software, Inc., which were solely designed for security. It’s worthwhile to check into the quality tools you already use to see if you can leverage the existing relationship and tool familiarity. You should also consider whether it’s important to your organization to have the two functions merged into one tool in the long term, McDonald says. (See Penetration Testing: Dead in 2009? for more on the interplay of quality assurance and vulnerability detection.)
Source code analysis tools: Evaluation criteria
— Support for the programming languages you use. Some companies support mobile devices, while others concentrate on enterprise languages like Java, .Net, C, C++ and even Cobol.
— Good bug-finding performance, using a proof of concept assessment. Hint: Use an older build of code you had issues with and see how well the product catches bugs you had to find manually. Look for both thoroughness and accuracy. Fewer false positives means less manual work.
— Internal knowledge bases that provide descriptions of vulnerabilities and remediation information. Test for easy access and cross-referencing to discovered findings.
— Tight integration with your development platforms. Long-term, you’ll likely want developers to incorporate security analysis into their daily routines.
— A robust finding-suppression mechanism to prevent false positives from reoccurring once you’ve verified them as a non-issue.
— Ability to easily define additional rules so the tool can enforce internal coding policies.
— A centralized reporting component if you have a large team of developers and managers who want access to findings, trending and overview reporting.
Do’s and Don’ts of source code analysis
DON’T underestimate adoption time required. Most static analysis projects are initiated by security or compliance, not developers, who may not immediately embrace these tools. Before developers get involved, McDonald suggests doing the legwork on new processes; planning integration with other workflows like bug-tracking systems and development environments; and tuning the tool to your unique coding needs. “Don’t deploy to every developer at once,” he adds. “Ideally, you’ll get someone who wants to take on a competency role for security testing.”
The chief scientist at the large software vendor has developed an application security awareness program that includes training on common vulnerabilities, through podcasts and videocasts. Once he builds up awareness, he’ll educate developers on secure coding standards. To complete the circle, he’ll introduce Ounce’s static code analysis tool to enforce the standards and catch vulnerabilities “so it’s a feedback loop,” he says. (See Rob Cheyne Pushes for Developer Security Awareness for a look at a similar agenda.
DO consider using more than one tool. Collin Park, senior engineer at NetApp, says the company uses two code analysis tools: Developers run Lint on their desktops, and the company uses Coverity each night to scan all completed code. “They catch different things,” he explains. NetApp began using these tools when its customer base shifted to enterprise customers who had more stringent requirements. While Coverity is better at spotting vulnerabilities such as memory leaks, LINT catches careless coding errors that developers make and seems to run faster on developer desktops, Park says.
According to Kelley, organizations typically implement static analyzers at two stages of the development process: within the development environment, so developers can check their own code as they’re writing, and within the code repository, so it can be analyzed at check-in time. The chief scientist uses this method. “In the first scan, if the engineer takes every finding and suppresses them, a milestone scan will catch those and generate a report,” he says.
DO analyze pricing. Vendors have different pricing strategies, McDonald says. For instance, while all continuously add information to their libraries about the latest vulnerabilities, some charge extra for this, while others include it in the maintenance fee, he says. In addition, some vendors charge per seat, which can get expensive for large shops and may even seem wasteful for companies that don’t intend to run the scanner every day, while others charge per enterprise license. Additionally, some vendors charge for additional languages, while others charge one price for any language they support, McDonald says.
DO plan to amend your processes. Tools are no replacement for strong processes that ensure application security from the beginning, starting with defining requirements, which should focus on security as much as functionality, according to Kelley. For instance, a tool won’t tell you whether a piece of data should be encrypted to meet PCI compliance. “If a company just goes out and buys one of these tools and continues to do everything else the same, they won’t get to the next level,” she says.
The chief scientist says it’s also important to determine what will happen when vulnerabilities are found, especially because the tools can generate thousands of findings. “Does the workflow allow them to effectively analyze, triage, prioritize or dispose of the findings?” he says. He is working with Ounce to integrate the system better with his current bug-tracking system, which is Quality Center. “It would be great to right-click on the finding to automatically inject it into the bug-tracking system,” he says.
At NetApp, Park has reworked existing processes to ensure developers fix flagged vulnerabilities. As part of doing a code submit, developers do a test build, which must succeed or it can’t be checked in. Then, when they check in code, an automated process starts an incremental build. If that build fails, a bug report is filed, complete with the names of developers who checked in code before the last build. “Developers are trained to treat a build failure as something they have to look at now,'” Park says.
NetApp also created a Web-based chart that’s automatically updated each night, to track which managers have teams that were issued Lint or Coverity warnings and whether they were cleared.
DO retain the human element. While the tools will provide long lists of vulnerabilities, it takes a skilled professional to interpret and prioritize the results. “Companies don’t have time to fix every problem, and they may not need to,” Kelley says. “You have to have someone who understands what is and is not acceptable, especially in terms of a time vs. perfection tradeoff.'”
The chief scientist calls this “truly an art form” that requires a competent security engineer. “When the tool gives you 10,000 findings, you don’t want someone trying to fix all those,” he says. “In fact, 10,000 may turn out to just be 500 or 100 vulnerabilities in actual fact.”
Park points out an instance where the Coverity tool once found what it called “a likely infinite loop.” On first glance, the developer could see there was no loop, but after a few more minutes of review, he detected something else wrong with the code. “The fact that you get the tool to stop complaining is not an indication you’ve fixed anything,” Park says.
DON’T anticipate a short scan. NetApp runs scans each night, and because it needs to cover thousands of files and millions of lines of code, it takes roughly 10 hours to complete a code review. The rule of thumb, according to Coverity, is for each hour of build time, allow for two hours for the analysis to be complete. Coverity also enables companies to do incremental runs so that you’re not scanning the entire code base but just what you’ve changed in the nightly build.
DO consider reporting flexibility. At the FAA, Brown gets two reports: an executive summary that provides a high-level view of vulnerabilities detected and even provides a security “score,” and a more detailed report that pinpoints which line of code looks troublesome and the vulnerability that was detected. In the future, Brown would like to build into vendor contracts the requirement that they meet a certain security score for all code they develop for the FAA.
DON’T forget the business case. When Brown first wanted to start reviewing code, he met with some pushback from managers who wanted a defined business need. “You’ve got program managers with schedules to meet, and they can view this as just another bump in the road that’s going to keep them from making their milestones,” he says.
Brown created the business case by looking to independent sources like Gartner and Burton Group for facts and figures about code vulnerability, and he also ran some reports on how much time the FAA was dedicating to patch management.
The chief scientist justified the cost of the Ounce tool by taking the total cost of the product and comparing that to the effort involved in a manual review. “With millions of lines of code, imagine how many engineers it would take to do that, and by the way, we want to do it every week,” he says. “The engineers would fall down dead of boredom.”
Mary Brandel is a freelance writer based outside of Boston.