Cатсн²² (in)sесuяitу / ChrisJohnRiley

Circumventing common Pitfalls when auditing sourcecode for Security vulnerabilities Aljosha Judmaier & David White

The awful truth

There is no magical patch that will make everything secure

Vendors don’t tell the full story

Security is rarely considered in the development process

Tools are useful, but only in the right hands

Security tools rarely prevent developers from make security mistakes

Often the term security refers to the use of security features

But in reality these default measures can be easily bypassed

Security Features vs. Secure Features

Security features may or may not be enough to protect an application

Secure Features are secure by their very definition

Vulnerabilities that are found late in the development process cost more than those found earlier in development.

Faults found later on are also less likely to be fixed due to time/cost.

So what is a “security problem”

Something that affects the output or the input in a negative way (in regards to the CIA triangle)

Even small things can be a big problem when put in the right context

Secure Development Life-Cycle

• Plan
• Design
• Implement
• Test / Acceptance
• Deployment
• Compliance Checking
• (Security Feedback ?)

The process should be flexible enough to take input from each stage and go back to an earlier stage to correct issues/faults discovered

Security, Threat Modeling and the SDLC

Take a diagram of your software architecture and mark all points where possible attacks/security issues could be an issue.

This doesn’t need to be in a specific structure, maybe it could be as simple as a brainstorming session on a whiteboard

Important to take into consideration all possible inputs and draw specific trust boundaries

Good baseline for risk management

Useful as a way to express ideas and possible vulnerabilities to management

Performance indicators

• Experience
• External Personel
• Small Teams

The only valid measurement of code quality… WTFs/minute

Tools vs Humans

Type of vulnerabilities is important for comparisons

Tools: Known vulnerabilities

Human: More intelligence behind testing

Clever Tools

Not all tools are dumb scanners however.

Examples:

• Pixy (TU Wien)
• WALER (TU Wien)
• SECoverer

Root cause

Bad code is written by… developers!

By understanding the environment developers work in to develop code.

With that understanding, you can incorporate tools and checks into the already present processes and systems.

Automate the process of QA and development communicating to transfer the correct information at the correct time and to the correct people.

SECoverer

A security workbench built on-top of Eclipse (multi-platform)

By building on-top of an already used interface, it allows for support for any programming language supported in Eclipse

Allows for collaboration with development and QA as it uses the same underlying platform

Unified open analysis platform (static and dynamic)

Provides monitoring and reporting for security issues and code coverage

Integrates with bug tracking systems

Open APIs for easy integration with external systems

Is it open-source

No…

Demonstration versions are available however

Planned open-source component to support the Analyzer Module Interface

• Talk overview –> HERE
• Pixy –> 
  http://pixybox.seclab.tuwien.ac.at/pixy/
  
• SECoverer Code analysis framework –>
  http://http://www.secoverer.com/