Improving your Secure SDLC ( SSDLC ) with Prevoty. How adding real-time application security dramatically decreases vulnerabilities

Transcription

1 Improving your Secure SDLC ( SSDLC ) with Prevoty How adding real-time application security dramatically decreases vulnerabilities February 2015

2 Improving your Secure SDLC ( SSDLC ) with Prevoty Table of Contents Abstract The application security problem Why hackers have moved to the application layer Top application security threats SSDLC overview Why implementing an SSDLC can be challenging Introducing prevoty High-level architecture Implementation High performance Application security monitoring Runtime protection Developer security toolkit How prevoty helps an SSDLC Summary

3 Improving your Secure SDLC ( SSDLC ) with Prevoty Abstract Gartner estimates that 70% of all hacks happened at the application layer in becoming the main attack surface for hackers. The dynamic and distributed nature of modern applications together with the increased sophistication of the attacks has rendered perimeter security ineffective and best practice for organizations is to find ways to build more security directly into the applications themselves. This has led many organizations to implement some form of a Secure Software Development Lifecycle (SSDLC). While there is no doubt that adoption of an SSDLC will improve application security to some extent, unfortunately real life implementations of a SSDLC can be extremely challenging and expensive and at least a distraction for application developers. This paper will outline Why the distributed and dynamic nature of today s applications makes hackers lives easier The biggest security threats for applications A brief overview of a Secure Software Development Lifecycle (SSDLC) Why implementing an SSDLC can be challenging for many organizations and, importantly, how using Prevoty can enable enterprises to realize: Rapid remediation of existing application vulnerability backlogs Quicker time to market for applications and features without the risk of introducing new vulnerabilities Protection from future XSS, SQL injection and CSRF zero-day attacks 3

4 Improving your Secure SDLC ( SSDLC ) with Prevoty The Application Security Problem The increase of public security breaches and data leakage has put enterprises in a challenging position with respect to dealing with application security. CIOs and CISOs now more than ever need to manage the trade-off between the value to their business stakeholders of releasing new applications rapidly versus releasing more secure applications in a less timely manner. Whilst the majority of enterprises understand the value in using a Secure SDLC (SSDLC) methodology to develop more secure applications, many struggle with the reality of fixing vulnerabilities identified during the testing process in addition to trying to anticipate the unknown threats coming from previously unknown hacks (known as zero-day attacks). So we end up in a difficult situation with unpleasant cost-benefit-risk decisions: do we allow existing applications to remain un-remediated? Should we still release new applications with known and potentially unknown vulnerabilities? There are four main parts to this application security problem: Existing backlog of vulnerabilities Most enterprises have a backlog of vulnerabilities for their existing published applications that is leaving their organizations exposed. There can be a number of reasons for this, including: The applications were released prior to a threat being identified and the organization simply does not have the time, capability or money to fix them The vulnerabilities identified include too many false positives whereby a fix would actually mess up the application usability The risk associated with leaving the vulnerabilities unremediated is perceived to be small Vulnerabilities introduced in new application development Agile development methodologies have become almost standard for enterprise application development and business requirements are driving more rapid application releases. This means that the time required to fix all identified vulnerabilities is often short and sometimes 4

5 Dealing with zero-day attacks Previously unknown threats, known as zero-day attacks, are unquestionably the most dangerous type of threats. Static (SAST), Dynamic (DAST) and Interactive (IAST) Application Security Testing tools rely on past definitions and patterns of previously known threats to operate successfully. So how do your application developers prevent attacks that have never been seen before? In addition, whenever the security community identifies a new zero-day, the whole process of application remediation needs to start all over again for every potentially affected application. Application developers are not security experts In order to attempt to stay ahead of hackers, security professionals need to spend a lot of their working lives monitoring the state of the art in terms of publicly available knowledge around vulnerabilities. It takes a thief to catch a thief. Developers were not hired to do this, they don t have the time to do this and their skillsets are not best placed to implement mitigations against complex attacks. Sifting through lists of vulnerabilities, many of which can be false positives and attempting to fix what they can without breaking the application functionality using the limited security knowledge that they have is about the best that can be expected. 5

6 Why hackers have moved to the application layer We used to think of an application as a binary or single host deployment. This simplistic model has grown into something much larger and more complex. An application today is the collection of services and processes that allow an end user or another application to perform a series of logically grouped actions. An application isn t just a single host anymore. Cloud, Web Services, Partner Apps, SAML Mobile & Multi-device External Data Services Users Firewall incl. WAFs VPN Database Dynamic User Generated Content External Employees Internal Employees Built in-house & externally Distributed Today, an application is at the hub of information sharing. It facilitates requests and collects data from internet, intranet and extranet users and sources. To put this in perspective, we re talking about applications making use of cloud computing and storage, partner applications, RSS feeds, API calls to external services, accessed by both untrusted and mobile devices, and the applications themselves being built including a lot of open source and even pre-compiled software with who-knows-what inside. 6

7 Top application security threats The top attacks that external facing and B-2-B applications face today are cross-site scripting (XSS), SQL injection and cross-site request forgery (CSRF). Cross Site Scripting XSS is the ability to execute JavaScript in a client s browser (including mobile web and hybrid apps). This can be a reflected or persisted attack. A reflected attack is experienced by individual users whereas a persisted attack affects all users. In either case, an attacker can grab credentials, drop malware/ shells and steal information. And don t forget brand defacement we ve seen cases of persisted XSS that has political messages from third world countries and activist groups. SQL injection SQL injection is the ability to execute unauthorized queries against a database. This allows an attacker to not just tamper but also exfiltrate sensitive information like Personal Identifiable Information (PII). Cross-Site Request Forgery CSRF is the ability to perform an attack on a user without them even knowing to hijack a session and/or steal a user s identity. It basically takes advantage of applications that don t securely manage a user s state changing activity when using a particular feature. As hackers become more sophisticated, we re now seeing how these attacks can be chained to cause a lot of damage. For instance, XSS can be used to steal an administrator s credentials, leading to the opportunity for SQL injection to execute malicious queries to steal things like user names and passwords or credit card information. 7

8 SSDLC Overview When we talk about SSDLC In the security and application development community most trace its origins to Microsoft s Security Development Lifecycle. This was put into overdrive at the behest of Bill Gates in one his more controversial company s. Microsoft realized that they had to bake security into their development lifecycle. The entire Windows division shut down and everyone focused on security. As organizations outside of Microsoft embraced the concepts around building security, the term SSDLC started to emerge. There is no standard that defines exactly what is included in an SSDLC, but based on experience of working with many enterprise customers, the following is a realistic high-level view of what is typical: Coding Write & Remediate App Best Practices Testing Static Code Analysis (SCA) Dynamic App Security Testing (DAST) Design Architecture & Design Reviews Threat Modeling Deployment Server Config Review Network Config Review Vulnerabilities List Delivered to Developers Security efforts are applied into all phases of the typical SDLC: In the Requirements phase, security teams get involved in early product conversations to build an initial risk assessment. Design involves threat modeling and identifying risks in the architecture and what resources could be compromised In the Coding process developers use secure coding libraries and follow best practices to ensure that they are doing things like input, query and token validation and may use SAST tools to identify possible vulnerabilities. In the Testing phase, developers, QA and security teams may use SAST, DAST and IAST tools, fuzzers and also penetration test the application. When potential vulnerabilities and/or bugs are found, then the results are delivered back to the development team. Finally the product is eventually released to pre-production where it undergoes configuration and networking review prior to the move to production. 8

9 Why implementing an SSDLC can be challenging There are many reasons why organizations struggle to implement an effective SSDLC. These include: Time Applications are at the heart of an enterprise s business. It is normal for there to be significant pressure on the app dev team from the business to release new applications and new features. Importantly, all of the results of the testing phase using software tools and security team don t actually fix anything all they do is deliver a list of possible vulnerabilities back to the developers who have to attempt to fix prior to release or remediate after release, again dragging them away from new development activities. Therefore, it s no surprise that adding more security can be seen as slowing down the release process and have a direct negative impact on business results. Expertise Implementing the basics in terms of input validation to avoid XSS is pretty much standard practice for enterprise application developers. However, the expertise to write code that can defend against more sophisticated attacks requires a deep knowledge of the arcane world of security and hackers and the vast, vast majority of developers were not hired with this expertise. Resources Building security into all phases of the SDLC requires resources both in terms of people and technology that many organizations struggle to afford. Even those organizations in the fortunate position to have large security budgets still tend to see a disproportionate amount of spending on network and perimeter based security based on the traditional (and now outdated) enterprise security model. 9

10 False Positives! One of the most painful aspects of a developer s life when dealing with a list of potential vulnerabilities is wasting time dealing with false positives parts of the application that match a pattern that may allow an exploit. but in fact is a necessary part of the code required to make the application function as required. Process On the positive side, having everybody think about security is always a good thing. Having more proactive security thinkers is great for a company. However, on the negative side, in the majority of organizations nobody really knows where to start or if they are doing enough or even too much. It s hard to find the delicate balance between application / feature development and doing things securely. If developers are under too much time pressure or don t have the expertise to build secure applications, then the value of threat modeling and risk assessment is nil. SSDLC is about embracing a methodology that drives the technology and ultimately the business. It s something that has to be practiced and tuned along the way. The goal is to reduce the friction and time for developers to build applications security. But in reality, most organizations don t practice vanilla SSDLC as they don t have the resources or don t have the methodology. They end up forking it into their own model for their own business, which is fine if there are controls to verify that it s working. 10

11 Introducing Prevoty At Prevoty we fundamentally believe that application security should be done from within the application and NOT at the perimeter. But we also know that having developers build security into applications is extremely hard, time-consuming and ultimately a huge resource drain. So we created a RASP (Runtime Application Self-Protection) technology that allows security to be built into applications automatically. Cloud, Web Services, Partner Apps, SAML Mobile & Multi-device External Data Services Users Firewall incl. WAFs VPN Database Dynamic User Generated Content External Employees Internal Employees Built in-house & externally Distributed Applications call the Prevoty security engine either from inside the application itself via an SDK or via the application s technology framework (e.g. Java,.NET). By being within the flow of application execution, the Prevoty engine not only understands syntax but also context. 11

12 High-level Architecture All real-time analysis and prevention is performed by the Prevoty Security Engine. Our approach is not predicated on past definitions and signatures, regular expressions, taint analysis or learning. Instead, we are focused on understanding and preventing malicious intent. The security engine understands syntax as well as context - e.g. cross-site scripting (XSS) executes in a browser, SQL injection happens in the database engine, etc. For effective security, a combination of language analysis and context is paramount. By strictly enforcing content and language we are not subject to zero-day attacks in the same way that either a traditional regex/signature based or a learning-based behavioral analysis are. When something malicious is identified, the security engine alerts via the Prevoty console and/or via a SIEM or logging tool. In protection mode, the Prevoty security engine always returns secured (cleaned, nonmalicious) payloads to the application, so the application will always run successfully -- even when under attack. 12

13 Implementation Applications call the Prevoty security engine via the Prevoty API. This function is instrumented inside the application itself in one of two ways: Prevoty Plug-ins Installed via a single command script, Prevoty Plug-ins provide a mechanism for existing applications to call the security engine without requiring any changes to the applications themselves. Prevoty SDKs Prevoty SDKs are available for all common languages, including Java, C#, PHP. Ruby, Python, and Node.js. The SDKs allow developers to quickly add Prevoty security to their applications, with a single API call made whenever analysis is required (e.g. GET and POST requests). High Performance The Prevoty security engine has been developed with performance in mind. It is not a proxy; it does not intercept every request or every GET or POST request parameter calls to the engine are only made when analysis is required. Requests process in less than one tenth of a millisecond. The only performance impact is the cost of an API call whenever a payload is being processed. With Prevoty s secure cloud-based service, roundtrips typically take around 50-60ms. When deployed on-premise, the engine can be positioned either at the app server tier or the web server tier whichever makes sense for the enterprise s topology. This configuration typically results in round-trips of only 2-3ms. 13

14 Application Security Monitoring The Prevoty security engine alerts security teams in real-time. Prevoty comes with its own Console but can also deliver real-time updates to SIEMs and log management tools such as IBM QRadar, HP ArcSight and Splunk. Additionally, Prevoty can integrate with syslog or other logging tools. The payloads contain all the relevant KPIs and analytics on a transactional level. In this way, Prevoty can also help companies that do root cause analysis (RCA). Runtime Protection Real-time protection capabilities include data exfiltration prevention, content sanitization, token & session id management, and Man-in-the-Middle (MitM) protection. Security policy management is centrally managed across all applications, regardless of application type. Developer Security Toolkit In addition to monitoring and protection functions, Prevoty SDK s include additional security services for developers, including: Cryptography Typed data validation Spam and profanity filters 14

15 How Prevoty helps an SSDLC The SSDLC with Prevoty is not slowed down by the endless recurring loop of finding and fixing vulnerabilities: Design Arch & Design Reviews Threat Modeling Coding Write application Include Prevoty API calls Testing SCA DAST Deployment Server Config Review Network Config Review Building Prevoty into the lifecycle helps alleviate all the main SSDLC implementation pain points: Time Including the Prevoty SDK in an application is simple and calling the engine is literally one line of code wherever analysis is required in the business logic. Using a Prevoty framework integration for.net or java is even quicker. And once this small effort has been done once, there is no need to come back and remediate the application again. Expertise Secure coding is tough. The vast majority of application developers are not security experts. Building in Prevoty means that they don t have to be. Prevoty has been designed to make the experience easier and more effective for developers to build applications securely. The SDKs are simple, intuitive and predictable wrappers around a REST API. Resources Developers can focus on new application and feature development. Security teams can focus on other the many other security challenges facing the enterprise. 15

16 False Positives! Administration of the Prevoty engine primarily constitutes setting up appropriate configurations to ensure that the appropriate analysis takes place based on the application context. When this matches the business logic, false positives are eliminated. Process Using Prevoty makes the process of releasing secure code much more lightweight and much less open to individual interpretations of security best practices by developers, increasing the efficacy of the SSDLC. How Prevoty solves the application security problem Using Prevoty technology solves the issues related to the top application security threats: Existing backlog of vulnerabilities Prevoty frameworks for Java and.net can be applied instantly and deliver an immediate dramatic reduction in vulnerabilities without the requirement of having to change or recompile any of the applications. For more granularity and for applications written in other languages, Prevoty SDKs allow existing applications to be quickly and easily instrumented without having to have deep knowledge of the business logic. Vulnerabilities introduced in new application development Including Prevoty as a standard part of the application development process means that developers will automatically release highly secure code without the risk of releasing applications with new vulnerabilities. 16

17 Dealing with zero-day attacks Because the Prevoty engine is based on contextual analysis and not past definitions or learning, it doesn t matter whether an attack has been seen before or not. Any applications using Prevoty are already protected against zero-day XSS, SQL injection and CSRF protection. Application developers are not security experts All a developer needs to know how to do is to call a REST API and the Prevoty engine will automatically deliver all the expertise required to protect the application. Summary Prevoty provides a radical new real-time application security capability, enabling applications to protect themselves. Prevoty works inside the application itself and the analysis engine is smart enough to actively prevent anything malicious from executing inside the application. In addition to providing active defense and real-time application threat intelligence, Prevoty s technology can dramatically reduce the time and costs associated with releasing secured code as part of a Secure SDLC (SSDLC): Rapid remediation of existing application vulnerability backlogs Quicker time to market for applications without the risk of introducing new vulnerabilities Protection from future XSS, SQL injection and CSRF zero-day attacks Prevoty. Application Security That Works. To request a live demo, start a free trial or simply get more information, please visit info.prevoty.com 17