Event and Slides

Introduction

Welcome to Start with Security.  My name is Ian and I’m here to introduce you to some of the free materials that have been produced by OWASP, a non-profit organization dedicated to addressing the security of software.

The mission of OWASP is to make the challenges of making application security more accessible and surmountable for everyone.

This talk is intended as a brief overview of the tools and resources that OWASP has produced and hopefully you will be encouraged to investigate them further and make use of them to improve your codebase, development organization, and your users experience.

Before we go into how we should spend the time on building security into development and startup processes, let’s briefly talk about why we should.

The Challenge of Secure Software

The antipatterns of treating code hygiene or design mistakes as an optional feature request or bolt-on effort after development is largely completed; that the rush to market is worth the risk of underachieving in data protection measures. This vacuum creates a market opportunity for crime and mischief; the less effort required for the attacker to exploit, the lower the bar to entry.

What do I mean by an antipattern?  A common pattern of behavior that even those with the best of intentions can fall into that decreases/reduces project productivity and accumulating technical debt that will need to be addressed at some future point.

Typically in application development, the functional prototype generally becomes the production environment and then the cost of correcting design and business logic problems becomes greater with time. Without attention, this leads to the behavior of piecemeal and ineffective efforts to correct this after the fact.  This means that mistakes that are made are generally long lived and, once the problem is realized, can make the cure appear more painful than the condition.

[[ Attacker Schedule ]]

Technical adversaries have a disproportionate amount of time and resources to dedicate to attacking your code and infrastructure.  The can afford to be single minded on offense.

[[ Threat Agents ]]

An attacker only needs one method of attack to succeed to accomplish their goals.  It might take a while to find, but without the ability to detect and react to their efforts, they are likely to be successful without a comprehensive method to address their threat.

[[ Iceberg ]]

Even with the best of after-the-fact ad-hoc efforts, a large codebase is not created overnight and can present a great variety of flaws that can be of use to an attacker.  The only way to address them coherently that has any real chance of concurrent success is by consistent proactive action.

Addressed By Proactive Action

It’s far more cost effective to plan and test for security functionality (in design and unit test) instead of trying to make corrections down the line.

So how do you do it?  There are a lot of different methodologies and everyone says they’re an expert, so how do you pick the most cost efficient and easiest to implement strategy for bringing your efforts under the best practice tent from all of the others?

I’m here to introduce you to one of the best ways using open materials which are free and accessible to all created by a nonprofit organization of volunteers dedicated to this mission.

OWASP Materials

In an effort to simplify the difficult tasks ahead of most people, such as those here in this room, OWASP has produced a great deal of mature work product which is available for free.  These four projects describe common problems (or antipatterns) which are present in the application landscape.

OWASP Links

OWASP Top Ten – The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.  Understanding what the most common problems are and how they arise is often the first step in addressing them in a meaningful way.

OWASP Top Ten Privacy Risks

OWASP Mobile Top Ten – addressing problems found on mobile platforms

OWASP top ten mapped to the web hacking incident database

SQL Injection Example

This remains a common example of how you can get everything right in your environment but a single flaw can allow an attacker to collect valuable data from your application or platform.

OWASP Proactive Controls

Verify for Security Early and Often: In many organizations security testing is done outside of development testing loops, following a “scan-then-fix” approach. The security team runs a scanning tool or conducts a pen test, triages the results, and then presents the development team a list of vulnerabilities to be fixed.

Security testing needs to be an integral part of a developer’s software engineering practice. You need to verify security early and often, whether through manual testing, or preferably, automated methods.

Integrating unit tests and design considerations in agile processes can convert these tests output into reusable proactive controls. This has the opportunity to save considerable time as whole classes of problems can be eliminated from the codebase and their re-appearance prevented in the future.

The rest are important as well, but due to time considerations, I’ll just briefly describe them and then return to focus on this key topic.

Parameterizing queries helps address SQL injection and is a part of many security frameworks and can help prevent the theft of your entire production database.

Encoding data can help against a variety of attacks, especially injection.

Validating inputs:  Any data which is directly entered by, or influenced by, users should be treated as untrusted. An application should check that this data is both valid before using it in any way.

Authentication and identity are very big topics covering the process of verifying that an individual or an entity is who it claims to be and that the session remains valid.

Authorization (Access Control) is the process where requests to access a particular feature or resource should be granted or denied. It should incorporate mandatory control checks, denying access by default, the principle of least privilege, and should occur server-side (not client-side).

Protect data in transit and at rest using encryption and local access controls.

Logging and alerting is not only important for troubleshooting, but can also be employed to forward the cause of business analytics, intrusion detection, and forensics.

Error and Exception Handling is not usually very exciting, but can lead to problems if not addressed with sufficient care.

Frameworks and libraries leverage mature and (hopefully) well tested existing efforts so that you don’t have to develop solutions to complicated problems from scratch.

I’ll briefly revisit these as they are key points.

OWASP ASVS

The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.  It can be a helpful reference in implementing testing.

As mentioned in the control of utilizing frameworks and libraries, the advantages of employing good works of others adds a lot of value and time savings in leveraging a mature tested codebase for these functions.

Examples:

If you’re coding in .NET and want to prevent cross site scripting in your application, you can make calls to the anti-cross site scripting library

If you have a java codebase and want to make your application more resilient to attack, you could utilize the security features in the Spring framework

Not only can you save time in not remaking the wheel in employing features of your chosen frameworks, but getting to know security frameworks that match the technology you are utilizing will drastically reduce the difficulty to implement safer functionality.

https://en.wikipedia.org/wiki/Comparison_of_web_frameworks

Finding code hygiene and design/logic flaws can be challenging if this activity is outside of your day to day experience, but there is training (both self-instruction and formal), software of various capabilities to assist, and ample reference materials to get you started.

This is why this art and craft is usually called a developer maturity program; improving developers to avoid classic mistakes and the ability to write software free of typical productivity antipatterns yielding a codebase that is hardened by default.

Authentication Logic Example

Here we have an example of going beyond basic assurance when an application is engaging in a higher risk activity, in this example, accessing the local filesystem.  So not only is a valid user and role tested, but also that the user and role is not invalid.

Maturity Models

This is a high level representation of the domains of the OWASP Software Assurance Maturity Model.  I mention this because establishing the maturity of startups at exit, and in many other situations, is becoming commonplace.  This is a entire talk in its own right, but I wanted to mention it before I concluded.

Thanks