Hi, my name is [Name]. I work as a [Title/ Role] at HP, in the Enterprise Security Products business unit. Today, I’ll be talking about application security and why governments and modern enterprises need it. What is application security? Simply put, it is about ensuring that every single line of code is secure and every single software application– whether it is built for the desktop, cloud or mobile device— is safe from cyber attackers and hackers. The goal here is about eliminating exploitablesecurity risk in software at the application code level, making it immune to attack even if intruders get past perimeter defenses.
Why is there a problem, and why do you need application security?Like all organizations, you’ve undoubtedly, invested a lot of time and money attempting to insulate and protect your assets. Your networks are protected – firewalls are in nearly every devices that connects to a network. Your servers are protected, thanks to advances in intrusion prevention systems. But your software applications are still largely unprotected and vulnerable.Companies believed that if you protect the perimeter (network and server), the software will be unreachable and therefore not breachable. However, that has not proven to be the case: software is the New Entry Point.Let’s take a look at how…
In today’s information-centric world, Hackers are after data and business logic, which they can manipulate and control. You’re talking about stealing your Intellectual Property, your Customer Data (credit card, SSN, address, etc.), Business Processes and Trade Secrets. With software, protecting one point in the system is not sufficient. The whole pathway to the data must be secure. If there is any vulnerability along that path, then the entire system is vulnerable. Hackers are ingenious in discovering new pathways. Years ago, they started at the network and hardware levels, but we have been successful in handling the problem (grayed out area), now they are going right to the app layer.This can be useful in explaining things like why encryption is not going to help you with app sec.
As a CISO or Security Exec, you’ve got a myriad of challenges when considering the risk of your software.First, legacy systems. These systems were built in a different era – For manylegacy applications, security was sufficient for their time and place of creation. With the up tick in devices utilizing technologies likeService Oriented Architecture (SOA) to increase access and scope, these systems are being put into scenarios they were not designed for. These systems and millions of lines of code have be scanned and scrubbed. They have to be secured.The second part of the challenge, is preventing more insecure code from beingdeveloped and introduced.This is what we mean when we say “build security in”. As a CISO (security executive), how can you ensurethat new releases don’t continually introduce additional risk through software vulnerabilities? Particularly when the threat landscape changes constantly -- with new threats being identified nearly every day. In2009 over 5700 software vulnerabilities were reported and tracked by the vulnerabilities database at NIST. Vulnerabilities reported in the first half of 2010 show that the this year will most likely increase over 2009. And that is only a fraction of the vulnerabilities -- these are just the known and reported vulnerabilities. 2010data suggests that over one third of the software vulnerabilities are from 3rd party applications - including commercially purchased, contracted and open source code. “This analysis clearly identifies vulnerabilities from third-party programs to be almost exclusively responsible for the increasing [vulnerability count] trend observed since 2007," “This year, third-party flaws are predicted to outnumber first-party flaws by two-to-one.” Secunia Half Year Report 2010 (download PDF).Additionally…..there is increased pressure externally from changes in compliance regulations and from internal audit policies and practices. Just responding to compliance mandates can turn into a never-ending cycle and ultimately not ensure that your code is more secure.So, who own software security?
How did we get here? There’s always been a communication/ collaboration gulf between Security and Development. These 2 teams don’t normally work together; they don’t even belong in the same group.Typically, Security receives code to deploy. You trust that the application you were given (whether developed in house, outsourced, open sourced, or commercial) is fully tested and secured. In many cases, you don’t have the time, skills or authority to stop that application deployment. So you end up rolling it out, not knowing whether the code is secure or not until it’s breached.
How expensive is this approach? According to an NIST study, the cost of fixing software increases substantially further along the Software Development Lifecycle (SDLC). It costs 30x more to fix security issues after a breach in Production than to build security into your code at the beginning during Design.
How do we fix this, how do we ensure that only secure software is deployed? Ideally, security should be built into software during the Design phase. Many times, it’s not possible. A pragmatic approach is to put a Security Gate in place before the software is deployed into Production. Before you rollout any application, you must first determine whether it is resilient and secure. If you look at the Development cycle, you have Engineers who develop the code and then QA who test the functionality, i.e. a Software Quality Assurance (SQA) role. The gap right now is that there’s no one comparable in Security. Do you have someone who performs a Software Security Assurance (SSA) role? No! Just as Development has QA to keep them honest, Security needs someone or something in a similar QA capability.
Fortify gives you advanced technologies to ensure your applications are secure. Fortify inspects applications at the source code level (static testing) and while they are running (dynamic testing). Fortify supports more languages than any other application security vendor with significant strengths in the area of mobile application security. But it’s not just built for custom applications, Fortify and determine if vulnerabilities exist in commercial, custom and open source activities. And even more differentiated, Fortify can be delivered as a software you purchase or as a service. With unmatched flexibilityand depth of coverage, Fortify ensures you have a world class application security program in place.
The method used to compromise Heartland’s network was ultimately determined to be SQL injection. Code written eight years ago for a web form allowed access to Heartland’s corporate network. This code had a vulnerability that (1) was not identified through annual internal and external audits of Heartland’s systems or through continuous internal system-monitoring procedures, and (2) provided a means to extend the compromise from the corporate network to the separate payment processing network. Although the vulnerability existed for several years, SQL injection didn’t occur until late 2007…. the intruders spent almost six months and many hours hiding their activities while attempting to access the processing network, bypassing different anti-virus packages used by Heartland. After accessing the corporate network, the fraudsters installed sniffer software that was able to capture payment card data, including card numbers, card expiration dates, and, in some cases, cardholder names as the data moved within Heartland’s processing system. SQL Injection was the primary entrance. The affected applications had been audited several times – but to weak PCI standardsIt existed for several years. Heartland Payment Systems: Lessons Learned from a Data Breach Julia S. Cheney, January 2010 Federal Reserve Bank of PhiladelphiaHeartland's computer network was compromised sometime in 2008, when a hacker installed sniffer malware that was able to see credit card numbers and other details. It is unknown how long the sniffer software was active or how much card data was captured. The Heartland breach, because it involved the use of a sniffer, made it hard to detect, says Dave Taylor, head of the PCI Knowledge Base. "It is a type of passive attack (meaning it just watches traffic over a network node, rather than modifying the traffic). Since they don't communicate or interact with other systems, they are hard to detect."The sniffer, also referred to a network analyzer, would be programmed to look for a pattern in the text (a 16-digit number in this case), and then copy any related content to a file, which then - somehow -- had to be communicated to the thieves. "That's hard, since I assume the server where the sniffer resides would not be connected to the Internet," Taylor says.Hackers were able to break into Heartland's systems and collect unencrypted data on payment card transactions that the company processed on behalf of its merchant clients. Merchants at about 250,000 locations, including retail stores, gas stations and hotels, use Heartland's services. Heartland does not know how long the hackers were able to steal credit card information or how many cards were affected.Once inside the corporate networks, the gang conducted reconnaissance to find credit and debit card numbers and other information. The group used sniffer programs to steal the data, and would communicate via instant message while attacks were in progress and advise each other as to how to navigate the corporate networks to find data, authorities said. At the time of the Heartland incident, the company processed millions of credit and debit card transactions daily. Beginning on or about Dec. 26, 2007 , the company was hit with a SQL injection attack on its corporate network that resulted in malware being placed on its payment processing system and the theft of more than 130 million credit and debit card numbers and corresponding card data. After being alerted by Visa(r) and MasterCard(r) of suspicious activity surrounding processed card transactions, Heartland enlisted the help of several forensic auditors to conduct a thorough investigation into the matter. Last week, the investigation uncovered malicious software that compromised data that crossed Heartland's network. SEC, FTC Investigating Heartland After Data Theft. Federal agencies, including the U.S. Federal Trade Commission and the U.S. Securities and Exchange Commission, have begun investigating Heartland Payment Systems following a massive data breach at the payment processing company.Court documents filed in connection with Monday's indictment spelled out how Gonzalez and his accomplices used SQL injection attacks to break into Heartland's systems and those of the other companies. Once they gained access to a network, the attackers then planted sophisticated packet-sniffing tools and other malware to detect and steal sensitive payment card data flowing over the retailer's networks.In SQL injection attacks, malicious hackers can take advantage of poorly coded Web application software to introduce malicious code into a company's systems and network. The vulnerability exists when a Web application fails to properly filter or validate the data a user might enter on a Web page -- such as when ordering something online. An attacker can take advantage of this input validation error to send a malformed SQL query to the underlying database to break into it, plant malicious code or access other systems on the network. Large Web applications have hundreds of places where users can input data, each of which can provide an SQL injection opportunity.According to Wysopal and others, there are several measures companies can take to limit their exposure to SQL injection vulnerabilities. One involves a code review of all Web applications to identify input validation errors. Companies need to identify such coding flaws and ensure that a Web form only accepts legitimate input. Web application firewalls can also be useful in protecting against SQL injection attacks, though they must be tuned properly to automatically block malicious traffic while permitting legitimate traffic to get through.
Heartland's computer network was compromised sometime in 2008, when a hacker installed sniffer malware that was able to see credit card numbers and other details. It is unknown how long the sniffer software was active or how much card data was captured. The Heartland breach, because it involved the use of a sniffer, made it hard to detect, says Dave Taylor, head of the PCI Knowledge Base. "It is a type of passive attack (meaning it just watches traffic over a network node, rather than modifying the traffic). Since they don't communicate or interact with other systems, they are hard to detect."The sniffer, also referred to a network analyzer, would be programmed to look for a pattern in the text (a 16-digit number in this case), and then copy any related content to a file, which then - somehow -- had to be communicated to the thieves. "That's hard, since I assume the server where the sniffer resides would not be connected to the Internet," Taylor says.Hackers were able to break into Heartland's systems and collect unencrypted data on payment card transactions that the company processed on behalf of its merchant clients. Merchants at about 250,000 locations, including retail stores, gas stations and hotels, use Heartland's services. Heartland does not know how long the hackers were able to steal credit card information or how many cards were affected.Once inside the corporate networks, the gang conducted reconnaissance to find credit and debit card numbers and other information. The group used sniffer programs to steal the data, and would communicate via instant message while attacks were in progress and advise each other as to how to navigate the corporate networks to find data, authorities said. At the time of the Heartland incident, the company processed millions of credit and debit card transactions daily. Beginning on or about Dec. 26, 2007 , the company was hit with a SQL injection attack on its corporate network that resulted in malware being placed on its payment processing system and the theft of more than 130 million credit and debit card numbers and corresponding card data. After being alerted by Visa(r) and MasterCard(r) of suspicious activity surrounding processed card transactions, Heartland enlisted the help of several forensic auditors to conduct a thorough investigation into the matter. Last week, the investigation uncovered malicious software that compromised data that crossed Heartland's network. SEC, FTC Investigating Heartland After Data Theft. Federal agencies, including the U.S. Federal Trade Commission and the U.S. Securities and Exchange Commission, have begun investigating Heartland Payment Systems following a massive data breach at the payment processing company.Court documents filed in connection with Monday's indictment spelled out how Gonzalez and his accomplices used SQL injection attacks to break into Heartland's systems and those of the other companies. Once they gained access to a network, the attackers then planted sophisticated packet-sniffing tools and other malware to detect and steal sensitive payment card data flowing over the retailer's networks.In SQL injection attacks, malicious hackers can take advantage of poorly coded Web application software to introduce malicious code into a company's systems and network. The vulnerability exists when a Web application fails to properly filter or validate the data a user might enter on a Web page -- such as when ordering something online. An attacker can take advantage of this input validation error to send a malformed SQL query to the underlying database to break into it, plant malicious code or access other systems on the network. Large Web applications have hundreds of places where users can input data, each of which can provide an SQL injection opportunity.According to Wysopal and others, there are several measures companies can take to limit their exposure to SQL injection vulnerabilities. One involves a code review of all Web applications to identify input validation errors. Companies need to identify such coding flaws and ensure that a Web form only accepts legitimate input. Web application firewalls can also be useful in protecting against SQL injection attacks, though they must be tuned properly to automatically block malicious traffic while permitting legitimate traffic to get through.
