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

Improving your Secure SDLC ( SSDLC ) with Prevoty

February 2015

How adding real-time application security

dramatically decreases vulnerabilities


Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The application security problem . . . . . . . . . . . . . . . . . . . . . . . . 4

Why hackers have moved to the application layer . . . . . . . . . . . . . . . . . 6

Top application security threats . . . . . . . . . . . . . . . . . . . . . . . . . 7

SSDLC overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Why implementing an SSDLC can be challenging . . . . . . . . . . . . . . . . . 10

Introducing prevoty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

High-level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

High performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Application security monitoring . . . . . . . . . . . . . . . . . . . . . . 14

Runtime protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Developer security toolkit . . . . . . . . . . . . . . . . . . . . . . . . 14

How prevoty helps an SSDLC . . . . . . . . . . . . . . . . . . . . . . . . . 15

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Table of Contents

AbstractGartner estimates that 70% of all hacks happened at the application layer in 2013 - 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

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 un-remediated is perceived to be small

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:

The Application Security Problem

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

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.

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.

Improving your Secure SDLC ( SSDLC ) with PrevotyImproving your Secure SDLC ( SSDLC ) with Prevoty

5

Why hackers have moved to the application layerWe 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.

Dynamic

Built in-house& externally

Distributed

Database

InternalEmployees

VPN

Firewall incl. WAFs

ExternalEmployees

Cloud, Web Services, Partner Apps, SAML

User Generated

Content

External Data Services

Mobile & Multi-device

Users

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

Top application security threatsThe 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

SSDLC OverviewWhen 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 emails. 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:

Design· Architecture & Design Reviews · Threat Modeling

Coding· Write & Remediate App · Best Practices

Testing· Static Code Analysis (SCA) · Dynamic App Security Testing (DAST)

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

Why implementing an SSDLC can be challengingThere 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

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

Introducing PrevotyAt 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.

Dynamic

Built in-house& externally

Distributed

Database

InternalEmployees

VPN

Firewall incl. WAFs

ExternalEmployees

Cloud, Web Services, Partner Apps, SAML

User Generated

Content

External Data Services

Mobile & Multi-device

Users


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

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, non-malicious) payloads to the application, so the application will always run successfully -- even when under attack.


High-level Architecture

12

Applications call the Prevoty security engine via the Prevoty API. This function is instrumented inside the application itself in one of two ways:


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, round-trips 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.


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

13

Implementation


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).

Application Security Monitoring

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.

Runtime Protection

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

Developer Security Toolkit

14

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.


How Prevoty helps an SSDLCThe 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:

15


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.

ProcessUsing 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 problemUsing 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


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.


SummaryPrevoty 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 visitinfo.prevoty.com

17

Documents

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