![[Chaco] Soluciones de Seguridad – Nicolás Pérez, Giux](https://cdn.slidesharecdn.com/ss_thumbnails/8-120705112239-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Hp Fortify Pillar
- 1. HP Fortify Application Security Name Title EnterpriseSecurity © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 2. The problem © Copyright2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 3. Cyber attackers aretargeting applications Applications Hardware Networks Intellectual Security Measures Property • Switch/Router security • Firewalls Customer • NIPS/NIDS Data • VPN • Net-Forensics • Business Anti-Virus/Anti-Spam • DLP Processes • Host FW • Host IPS/IDSTrade • Vuln. Assessment tools Secrets 3 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 4. Application security challenges In-house development Securing legacy Certifying new applications Demonstrating releases compliance Procuring secure software Outsourced Commercial Open source 4 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 5. Today’s approach >expensive, reactive IT deploys the bad software 2 Somebody builds bad software 1 We are breached or pay to have someone 3 tell us our code is bad We convince & pay the developer 4 to fix it 5 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 6. Why it doesn’twork 30x more costly to secure in production 30X 15X Cost 10X 5X 2X Requirements Coding Integration/ System Production component testing testing After an application is released into Production, it costs 30x more than during design. Source: NIST 6 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 7. The solution © Copyright2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 8. The right approach> systematic, proactive Embed security into SDLC development process 1 2 Leverage Security Gate to validate resiliency of internal or external In-house Outsourced Commercial Open source code before Production 3 Monitor and protect software Improve SDLC policies running in Production This is application security 8 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 9. HP Fortify SoftwareSecurity Center Identifies and eliminates risk in existing applications and prevents the introduction of risk during application development, in-house or from vendors. • Protects business critical applications from advanced cyber attacks by removing security vulnerabilities from software IN-HOUSE OUTSOURCED • Accelerates time-to-value for achieving secure applications • Increases development productivity by enabling security to be built into software, rather than added on after it is deployed COMMERCIAL OPEN SOURCE • Delivers risk intelligence from application development to improve operational security 9 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 10. Minimizing risk, drivingbusiness agility Application security benefits • Reduce risk with • Deliver • Meet government • Build a security minimal effort measurable and industry culture and operational business and compliance throughout your costs strategic value regulations organization 10 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 11. Competitive differentiators We enable companies to build a holistic application security program from the ground up to secure all their software from development to production— regardless of who and where it is developed, and whatever device, form factor or environment it is running on. Breadth: the most Depth: 492 unique Services: expert guidance complete software security vulnerability categories to custom-tailor and solution with static, discovered across 21 integrate software security dynamic and hybrid testing, programming languages and into your unique along with collaborative over 750,000 individual development, testing and remediation and proactive platform and framework production environments SDLC governance. APIs. 11 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 12. Summary: HP FortifySoftware Security Center Comprehensive application security solutions That proactively identifies and eliminates the immediate risk in legacy 1 applications, as well as the introduction of systemic risk during application development 2 To ensure that all software is trustworthy and in compliance with internal and external security mandates Scaling to protect all your business-critical desktop, mobile and cloud 3 applications 4 Available on-premise or on-demand, and with managed services 12 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 13. Real world example: HeartlandSystems © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 14. Heartland cybercrime case 1. Sometime in 2007: Albert Gonzalez and 2 Russian co-conspirators gained access to Heartland systems through a personnel application 2. Attackers injected code into data processing network and installed a sniffer malware that was able to see credit card numbers and other details. 3. After being alerted by Visa and MasterCard of suspicious card transactions activity, Heartland called U.S. Secret Service and hired two breach forensics teams to investigate 4. Jan 20, 2009: Breach reported by Heartland • At least 650 financial institutions affected • 94M credit records stolen • Fines levied to banks > $6M • Total cost of damages / loss > $140M 5. At the time, the Heartland breach was the largest identity theft case ever 14 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 15. How HP Fortifycan help 1 2 3 Use SCA to ensure that Use WI to simulate Use SSC to build every single line of code attacks against web security into any is developed securely, applications in Staging application in whether internal or from and to continuously scan development and 3rd party or built for the the application in production from the desktop, cloud or mobility Production ground up 15 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 16. Thank you © Copyright2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Editor's Notes
- #2 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.
- #3 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…
- #4 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.
- #5 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?
- #6 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.
- #7 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.
- #9 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.
- #10 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.
- #14 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.
- #15 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.