Trends and Findings Over the last few years, we have identified a number of common features and trends in system security, malicious attacks, and general web application testing. Of these, a number of the security testing issues are of some interest and can be addressed over time through a targeted approach. In the last 18 months we have performed incident response and incident management for a relatively significant number of large clients. Through this, it is apparent that approximately 50% of the compromises that have taken place have done so through application level attacks. In general terms, the root cause of the attacks were: 1. Vendor provided software (including both off the shelf and custom) having a number of insecurities and software vulnerabilities which the customer was unaware of 2. A single misconfiguration resulting in a full compromise indicating a lack of a defence in depth strategy and implementation Other points we have observed are that: Server and Operating System level attacks are tending to plateau, with larger companies significantly worse than smaller companies in managing both vulnerabilities and insecurities. There were relatively few zero-day attacks; most attacks were the result of automated tool scanning attacks. The detection of attacks was in the main abysmal, with the compromises only being detected as a result of aberrant behaviour by systems. We have also performed a huge amount of network and application intrusion testing (penetration testing) over the last few years, with a number of emerging trends: Infrastructure level testing is seeing a reduction in insecurities, largely due to improved trends around vulnerability management. A web application deployment by a fresh (new) client is likely to have a significant number of web application security issues, with everything from exposed databases through to SQL injection level attacks being possible. Further testing over time indicates that a relationship with a security company for source security testing purposes results in a reduction of insecurities in the web applications. The bigger they are, the harder they fall. There appears to be a defined trend towards the larger companies having a higher number of insecurities, particularly in the web application space. The root cause of this is unclear; however there is a relationship with outsourcing, and the need for a large organization to secure everything. This also applies to smaller companies; however the smaller companies tend to have significantly less infrastructure to worry about. Certainly we have seen vulnerability management and analysis starting to be applied within organizations; however it is only really the network, operating system, and server levels that are being worked on by most companies. This is largely based around the notion that vulnerability scanning and remediation products and services are maturing in this space. Certainly while there are maturing tools in the application security testing space, they are still quite reactive, and will take a number of years to be both mature and mainstream. From the vulnerability research and analysis that we have been performing, it is apparent that application development is still poor in terms of security. Not all of this can be blamed directly on the developers; with so much pressure to get product out the door, security is often given a back seat. We also need to focus on training our software developers to code securely but we are presently doing an abysmal job at it. A number of the application layer security vulnerabilities we are seeing in both off the shelf and open source systems are merely new instances already well known vulnerabilities. How long have we known about buffer overflows and SQL injection issues? So why are we still seeing them? For further discussion around some of this, see Brett Moores Ruxcon presentation on same bug, different app. As a final note for this section, as an organisation we are really excellent at application testing and source code analysis, but really hate being the ones that break a system 2 days before it is scheduled to go live. The stats are there; design security in at early phases of the project, and the cost and impact of remediation is much less than trying to fix it when you are just about to roll it out, and dramatically cheaper than trying to fix it once in production. We are starting to see a trend towards compliance and security assurance climbing the systems development life cycle value chain. Long may it continue! COTS So who tests vendor products (Common Off The Shelf) for web application security issues before they are rolled into production environments? Particularly where it has previously been deployed into other client sites? Really? How many of you review source code security in code developed by your outsourcer and / or development team? We have seen the good and the bad in this space. In a number of cases we have tested and broken web applications that are in widespread use around the world, and have found them seriously lacking. This is not necessarily just a plug for how good we are; it is more an indictment on the lack of application security testing performed by other companies that have purchased and implemented these products. Really guys, some of the attacks and exploits were just plain basic The message really is to at least do a source code review where possible, or an application intrusion test where you can. COTS systems are not automatically secure simply as a result of how widely they are deployed. If you are concerned about the security of a product, get the developers to release the source code to you for assurance and testing. Based on our findings, at least 20-30% of web applications (either COTS provided or outsourced) have significant vulnerabilities. What about your outsourced application development? Of course you do realize that you are accountable for poor software security and are performing source code audits appropriately when code is delivered? Seriously though, there is a real lack of due diligence in reviewing delivered systems at either the application or source code level, for which we believe the primary reason is a lack of applied accountability, and (up until recently) this stuff hasnt necessarily been cheap to test. The other big issue that we find is a general lack of security testing standards, and security standards in application development. Products and tools are getting to the point where it is possible now to perform reasonable compliance checks and security audits against vendor / outsourcer provided systems without the inherent costs associated with manual source code audits. Measure their performance! Accountability is not something that can be outsourced easily, and reasonable practice is to ensure that your contract with your vendor / outsourcer at least includes your expectactions of web coding standards and practices (or at least review and scrutinize theirs), and to perform some form of compliance checking of these standards against the delivered code. How otherwise do you know whether the delivered application is secure? Blind trust and faith? Open Source There has been some significant debate over the security of either closed or open source systems and it is clear that, in the web application security space particularly, there does not appear to be any significant differences. From our code reviews using CodeScan, the numbers of issues found in COTS products and Open Source appear on the surface to be similar. Across Open Source applications that we have tested with CodeScan, we are finding all of the common suspects; Cross Site Scripting is rampant, and SQL Injection is still there to degrees that are kind of interesting. And these systems are deployed and exploited globally. We will be releasing advisories and statistics against our vulnerability findings in open source web applications, particularly in the ASP and PHP space shortly, so watch this space! A couple of really interesting issues arise from the use of Open Source applications. While it is an important way to place useful applications into the online space, it is apparent that the degree of security scrutiny placed on the web applications is insufficient. In the main, contributors to these projects are focused on the application functionality and features, and security issues do not get the level of attention or audit that is warranted. A part of cause for this has been a lack of compliance or automated tools that can provide a quick return on the problem; that was one of the driving forces behind our developing CodeScan for our own use in automating some of the source code analysis. The other really interesting issue that arises from the Open Source community is that a high proportion of development teams globally use cut and paste techniques to include functionality into their own application development. This has the advantage of enabling relatively quick software / web application developments to occur, but the other edge of the sword is that it may also duplicate potentially insecure code. How many people really perform source code audits against the code they are importing to determine that they are not actually importing vulnerabilities into their application at the same time as they bring in functionality? Tools and Trends Proactive vs. reactive; bugs need to be squashed in development. There are a number of vendors, including ourselves, that are moving away from the more traditional reduction of exposures and issues and more into the prevention of vulnerabilities being developed in systems in the first place. Application vulnerability testing can be applied to production applications, and additional tools implemented to control the visibility and exploitation of software vulnerabilities (intrusion detection / prevention, application aware firewalls, patch management systems, etc), but these are all still reactive in nature. If you are trying to fix software security issues, why not develop it to be secure in the first place? Security At The Source is the only true proactive measure that is going to result in secure systems over time. Addressing security at the source code level with static compile time code inspection systems is likely to be one of the big emerging trends over the next 2-3 years. Security policy driven testing is also emerging as a requirement trend. We are continuously seeing drivers in being able to test easily for standard and custom security policy in web application development. Why should customers put up with code that doesnt even comply with either their own or their developers policies for secure development? There is also a big trend away from static application testing prior to production toward incorporating security testing and compliance measurement throughout the software development lifecycle. There have been a number of studies done that identify this specifically, and the cost for repair of bad code in production systems has been proven as high. "It is about 40-100 times more expensive to fix problems in the maintenance phase of a program than in the design phase." There is also a strong tendency now to look at how security can be designed in, and tested as a part of the overall software test environment. Why not start testing code security at the prototype phase? Problems and issues associated with the design are a lot easier to pick up and rectify at that stage. We have seen (anecdotally) significant reductions in the cost of early security testing vs. testing at the ready to go live state. All too often the testing at the end will anyway result in a we will fix the security in the next version or similar lame excuse, with the security issues either not being addressed, or being exploited in the production state. Not great, but the situation definitely is improving. Compliance management is probably going to be the next big driver for software compliance. Already we have seen more and more onerous regulations controlling auditing and reporting (Basel II, Sarbanes - Oxley) and privacy (Gramm Leach Blilley, HIPAA, Australian Privacy Act), ISO 17799, and commerce (MasterCard / Visa AIS program) are driving the adoption of comprehensive IT best practice guidelines, which have as a core the reliable audit and measurement of compliance with minimum baselines. As an example, the MasterCard SDP looks to testing of OWASP Top 10 vulnerabilities in bespoke or custom web applications. This trend is likely to continue, with compliance driving a number of behavioural changes within organizations and software development. Final Summary Today, in this environment, existing vulnerability scanning methods, including manual reviews, are just not going to cut it. Right now, as security professionals, we worry about these problems. As the new and emerging laws settle into established practice, look for security to embed itself firmly with quality assurance staff, application designers, and eventually the programmers themselves, to become more involved in managing software security and ensuring compliance. |
