“It’s okay everyone sucks at security”

At the same time I am most willing to learn more about security in order to become a better developer. For the first time I am attending a security conference, the AppSecEU 2011 in Dublin, Ireland.

The day started out with double breakfast, first at the hotel, second at the venue. The conference is really nice and reminds me alot of the many YACP’s I have attended over the years. The attendees seem very much to be practitioners and people involved with all aspects of security in their day jobs.

These were the talks I had set out to attend:

- Keynote: Brad Arkin (@bradarkin), Adobe
- Building a robust security plan by Narainder Chandwani, Foundstone
- The Buzz about Fuzz by Joe Basirico, Security Innovation
- Keynote: Smart phones, app-stores and HTML5 (ENISA) by Dr. Giles Hogben
- Python Basics for Web App Pentesters by Justin Searle
- Secure Coding Practices Quick Reference Guide by Keith Turpin, project leader. OWASP/Boeing
- OWASP AppSensor Project by Colin Watson

Here follows selections of my notes and some reflections on the different presentations.

Keynote: Brad Arkin, Adobe

Brad presented the Adobe Secure Product Lifecycle (SPLC). He started out by talking a bit about attackers and motivations and categorizing these and comparing these to criminals. This was a bit fuzzy to me, but I think I got the picture, his conclusion was anyway that we need super heroes with green lasers – not really.

Instead we should focus on:
- Hard work
- Repeatable and verifiable processes
- Security must be a priority in all stages of development

He mentioned that Adobe produced popular products and therefor could popularity be of interest to exploring attack vectors and exploits in Adobe products. This is a pattern we have observed before in the industry and therefor is makes sense.

He then went on a described Adobe’s Security Strategy. Which consists of a lot of different practices, I am not going to go over all of them, but here is a basic and non-exhaustive listing:

- Keep customers up to date, by simplifying updating and installation of Adobe software
- Safe and secure code (Adobe SPLC)
- External engagement, industry, partnerships, threat landscape modeling etc.
- Swift and decisive responses to security incidents are important
- Defensive coding and security testing and should be a part of general processes
- Features should be scrutinized using thread modeling
- Use the tools like compiler flags
- Static and dynamic analysis

Brad talked a lot about training and Adobes approach to training and certification was quite interesting, in general however it seemed that security awareness throughout Adobe was the main thing.

In addition he provided these resources:

- Security: http://adobe.com/security
- ASSET: http://blogs.adobe.com/asset
- PSIRT: http://blogs.adobe.com/psirt
- Adobe security on twitter @adobesecurity

Next I move on to ‘Building a Robust Security Plan’ by Narainder Chandwani, Foundstone

He talked about outlining a security plan and a several other resources like:

- knowledge repository
- a security impact profile

He had an elaborate point system he referred to, but did not present directly. It should be represented in his paper. In general the idea was to create a database of all your applications and classify them together with a security impact profile based on some of the following metrics:

- classification of data
- possible compliance issues
- exposure

Again knowledge and information was key factors and in general I could agree with Narainder Chandwani’s idea, but his generalized approach to security impact profiling should preferably be something more along the lines of either OWASP top-10 or similar work from ENISA.

I missed out on the fuzzing presentation at my local OWASP chapter in Copenhagen, so I thought this was a good chance to get some education in fuzz, so I went to see: The Buzz about Fuzz by Joe Basirico from Security Innovation.

There is not much too fuzzing as such. Fuzzing is all about attempting to break or misuse applications using generated malformed values. You can divide fuzzing into three categories:

- random fuzzing
- seeded fuzzing
- format aware fuzzing (a variation of seeded fuzzing)

You send a request, process the response, fuzz and then repeat.

Joe Basirico emphasized that input validation is first line of defense and mentioned that input comes from everywhere, like filesystems, database. So the classical user facing input validation might not suffice – a very interesting and thought provoking idea, which got me thinking.

Things to be aware of when doing fuzzing are:

- Control characters
- Encoding
- Checksums and verification blocks
- Compression
- Order and required sections

One should consider blacklisting vs. whitelisting input data to tighten the security on the first line of defense. I might get back to this topic later since I am trying to collect all my notes on defensive programming in an article.

He mentioned the following tools and resources:

- peach (search for peach fuzz)
- SPIKE
- www.fuzzing.org
- fuzzdb
- Github: WebFuzzer by Joe Basirico (Security Innovation)

A lot of good and practical information, which could result on more work on my side, since there are a lof of aspects from Joe’s presentation I would like to dive into.

After a lunch break, where I walked into town to find the local Mac store another keynote was scheduled.

Smart phones, app-stores and HTML5 (ENISA) by Dr. Giles Hogben

Dr. Hogben presented some work being done by ENISA in the smartphone area. Smartphones are very interesting from a security perspective, since they have all sort of sensors, IP and a lot of CPU power. Issues in regard to smartphones are both related to security and to privacy and a lot of aspects of these new technologies are using best practices from other technologies, but at the same time the many features and opportunities open up for new potential threats.

ENISA has produced a smartphone report together with OWASP. It lists:
- top 10 risks
- opportunities
- recommendations

Of all the smartphone developing companies in the world only one had not participated – Apple, not surprisingly, but a bit disappointing. Because iOS devices are by no means securer than other smartphones and considering the point from Brads keynote on Adobe’s popularity being a challenge for Adobe, Apple should consider participating in projects like the one done by ENISA.

In addition ENISA is working on a report and several other deliverables on HTML5.

In addition to analyzing the HTML5 specifications, the specifications had also been compared against one another and they suffered severely from underspecification. A point, which seem very much to be in line with the presentation by Bruce Lawson from Opera I saw at GOTO Copenhagen.

The HTML5 work is very much in progress, but it is still possible to chip in, see also: http://www.enisa.europa.eu/act/application-security

I then went to see: Secure Coding Practices Quick Reference Guide by Keith Turpin, project leader, OWASP/Boeing.

The Quick reference guide is a 17 page document developed by OWASP, it originates from Boing who turned over the ownership and copyright to OWASP. It aims to be technology agnostic and focusses on what to do, not how to do it.

Some of the aspects Keith Turpin highlighted was intended (requirements) vs. unintended (what the application actually can accomplish) functionality. The concept of restraining the allowed unintended functionality, was similar to the problem described by Joe Basirico (see the earlier section) and again this is something I am going to revisit in my write-up on defensive programming.

Keith Turpin made a point that we have to evaluate the whole stack and the environment of the application and applications, since operations and application management might, change the context in which our application operates and therefor the security aspect and thread modeling might have to consider different factors.

The Quick reference guide is in checklist format and is currently being revised to be come even more technology agnostic and hopefully the points will be enumerated using and overall enumeration guideline from OWASP so it will be easier to cross-reference between OWASP documents and external resources.

As a developer I found this talk very interesting and I am looking forward to examining the Secure Coding Practices Quick Reference Guide. I moved on in development mode and went to see: Python Basics for Web App Pentesters by Justin Searle

I do not have many notes from this talk, the presenter Justin Searle dissed Perl for no apparent reason, something I thought we were over years ago. He described how he did pentesting using Python and then referenced to a Google code project with all his templates. The only thing that bothered me about apart from the Perl thing was that he kept saying templates when he meant boilerplates.

The last talk of the day was: OWASP AppSensor Project by Colin Watson. This talk was off to a bumpy start. First the Apple computer Colin was using had issues getting the right resolution needed for the presentation, then Colin stated the following:

“If we do not know if we are under attack or whether we are being exploited we are doing security wrong”

It took me some time to understand what he actually meant and as he went through the presentation it all of a sudden made a lot of sense. The idea behind the AppSensor project is to do more application aware monitoring of in our applications so we can take countermeasures when something unexpected happens. The idea is to put detection point in key points in our application and then monitor these and take action when something unexpected occurs.

The counter measures and actions can be anything based on our application, context and circumstances.

- locking down user, functionality or application
- limiting access
- blocking IP
- alerting user / admin

I did not get all of the points listed by Colin noted down, but you get the picture. Colin mentioned something that was in line with Joe Basirico’s presentation about input. So if we put a detection point in the between our database and the application we can also measure when a user is retrieving an unexpected high number of records from the database. Joe Basirico emphasized that data from a database is also just input and it should not necessarily be trusted as is.

All in all a very educational day and I am looking very much forward to day 2 of the AppSecEU 2011 conference.

The first part of the iPhone road map is based on simple prototypes and applications being developed as part of the learning process of iPhone development and it’s related tools and techniques. It is my goal to release relevant parts and applications as Open Source as part of this process.

In addition to getting iPhone development as an integral part of our development capabilities, It is my hope to take this to a higher level in collaboration with new and existing clients extending logicLAB’s portfolio slowly.

Initial discussion with a new client have already taken place and I am in the process of creating a mock-up of the proposed project.

More information will follow on logicLAB’s venture into iPhone development as this progress.

jonasbn, logicLAB – Copenhagen