Comments (6)

By Mark Curphey, January 24, 2012

If you are a regular reader of this blog you should know I am working on a book for O’Reilly called Practical Software Security. It’s in the early stages and evolving as we start to get into the details. You can sign up to get notifications of progress here.

There are five main sections:

• Introduction
• Security Concepts
• Languages & Frameworks (was called Tools & Technologies)
• Building a Software Security Program
• Engineering Scenarios

In the Security Concepts section we will introduce developers to things like cryptography, authentication, authorization and then in the Languages & Frameworks sections we will cover the security features available and how to use them properly for the popular development technologies. In the engineering scenarios well get to code level guidance of how to pull it all together to solve real world problems that all developers face like securing a REST API or creating a federated authentication system.

I am delighted that we have been able to recruit a fantastic list of subject matter experts to write and review the Languages & Frameworks section of the book. I will be writing the Security Concepts section (and the Ruby on Rails section) and the following folks will be writing or reviewing:

• HTML5 (and friends) – Mark Curphey
• Java – Pravir Chandra
• .NET – David Rook (Security Ninja + Microsoft MVP for Developer Security)
• JavaScript (Client + Node) – Gareth Heyes (The Spanner) with Rey Bango as a core reviewer (JQuery Core Team Member)
• Ruby on Rails – Mark Curphey with Heiko Webers (wrote the official Rails security guide) as a core reviewer
• PHP – Mike DeLibero with Chris Shiflett (wrote the O’Reilly PHP Security book) as a core reviewer
• iOS & Android – Dan Cornell
• Identity – Gunnar Peterson

Note: we will be doing C / C++ as there is still so much being produced but haven’t yet locked on that author and we will be figuring out how to deal with things like Spring or Cake (and where to draw the line).

In the Building a Software Security Program section we organize the section into People, Process & Tools. Justin Collins (author of Brakeman Scanner) is going to write the static code analysis section in Tools and Tasos Laskos (author of Arachni) will write about how dynamic web application scanners work. Many other tools will of course be covered! I will be writing extensively about integrating Agile practices and using TDD / BDD techniques and tools. I probably won’t start on this section until March / April. I am hoping we will have the Security Concepts section and the Languages & Frameworks section complete by the end of February so we can open up a site for a much broader set of reviewers (invite only but register to get on the invite request list here) around March.

OK, now to set up the git repo for the contributing authors, create a README.md for them and kick off the discussion about we want to structure things. Gentlemen start your engines!

Edits : 1/25 – Added HTML5 (and friends), 1/25 – Added Gunnar Peterson to Identity

Comments (0)

By Mark Curphey, January 18, 2012

Kudos to Niel Matatall for writing guard-brakeman. Neil has taken an open source static analysis tool, brakeman scanner and integrated it with the guard framework, a Ruby DSL for creating file-change events. Guard is typically used to automatically run the test suite as soon as a developer modifies any source code files and provides visual notifications on pass or fail conditions. What Neil has done is simple but I think very powerful which is why I think he deserves public kudos. When a developer adds guard-brakeman to his guard configuration any time he/she makes a change to his application the security tests will automatically run. TDD developers don’t commit code until all tests pass and so he has effectively provided an easy way to push security back up the chain for developers following TDD. It’s that one stage further back than running static analysis before a commit. The only place further back up the chain left to explore is intelli-sense type security advice in the editor.

We need more people doing more things like this in my opinion. Simple, elegant and effective. Kudos to Neil!

Comments (3)

By Mark Curphey, January 17, 2012

Create Local Repository from an Existing Local Project

Comments (6)

By Mark Curphey, January 16, 2012

The Practical Software Security book will have five main sections *subject to change and a work in progress of course*. To recap the book is being aimed at pure developers (not security people) and aiming to be a single book developers and development teams need for their security knowledge. Those five main sections are:

• Introduction
• Security Concepts
• Tools & Technologies
• Building a Software Security Program
• Engineering Scenarios

I want to syncronize the book so that the generic security advice in the security concepts section is then made specific in the tools & technologies section and then further builds with code level samples in the engineering scenarios section. For example in the “Security Concepts” section there is a sub-section on cryptography in which we describe the key concepts and types of cryptography, how those types of cryptography works and when certain types of cryptography can and should be used. In the “Tools & Technologies” and technologies section we will cover a security overview of major development frameworks such as Java, JavaScript and PHP in which I want help the developers know how to implement those cryptographic concepts described earlier in their scoped framework and describe important cryptographic libraries and what they support.

I would love to hear peoples opinions about the “security frame” I plan to use (see below). The frame will be used to tie together the sections of the book. I have been using this (or a variant of it) for many years and it has always worked for me. J.D.Meier used a similar one in Building Secure ASP.NET Applications (I was a reviewer of this back in 2006).

• Cryptography
• Authentication
• User Management
• Authorization
• Configuration Management
• Audit and Logging
• Data Validation
• Data Security (in transport & storage)
• Session Management
• Error Handling

Does it work for you?

Is it missing any sections?

Would you add any sections?

At the end of the day it is just a taxonomy and over the years doing things like OASIS WAS and similar projects, I have concluded that more important than the taxonomy is using any taxonomy consistently. No taxonomy will ever work for everyone, I just want to make sure this works for the majority. Please throw darts at this. Ask me where I would put x or y or z. If I don’t have a good answer I have a problem!

Cheers!

Mark

Comments (0)

By Mark Curphey, January 15, 2012

I think this is a really exciting time to be living. The pace of technology advances are so fast that things I could only imagine as a child (or dismissed even a few years ago as pure science-fiction) are actually coming true. We take so much amazing technology for granted and don’t appreciate it. I now use Siri to send texts and check the traffic while in my car, my iPad is used by the children to talk to their grand-mother in the UK using video conference (Skype) as if it’s “normal”,  my wife sometimes tracks me using “where are my friends” on our iPhone’s to have a hot cup of tea ready for me when I walk in the door from a tough day at work and I often scan my food using the Daily Burn to determine the calories and nutrients. I could go on and on and on.

The commonality with much of the software I have grown to love is that it is more often than not first created by people who wanted to solve a specific problem and this is the main reason I am so excited to see the Learn to Code movement take off. CodeYear.com has seen over half a million people set a New Year resolution to learn to code including New York’s Major, Michael Bloomberg. The scheme sends prospective developers a weekly set of tasks via email that have started with basic JavaScript lessons.

If you try to view the world as “a glass half-full” then you will, like me, be excited to think about the great software that will be created by a broad range of people that will be able to put their ideas into prototypes and production services in the future. The amount of  ideas for unique software trapped in the brains of 500,000 people is a significant number to bet that some will become staples that many of us will use and rely on tomorrow. Realistically of course only a proportion of those that sign up will continue on the course (like any new years resolution) and a much smaller proportion will actually ship anything. Of that proportion an even smaller number will ship something that might be considered a killer app but with a starting funnel of 500,000 its hard to imagine their won’t be some real success stories.

Over the last few weeks I have seen several tweets from “security people” questioning the type of developers that this movement will produce. They were of course inferring that an army of new and inexperienced developers will result in a sea of insecure code. It maybe a valid concern but the security industry is notoriously “glass half-empty” or pessimistic. I keep circling back to two points.

The first is that “security < performance < functionality”. Many security people will argue to death that this isn’t valid but I am yet to agree with any arguments. “It is hard to convince a man of something if his salary depends on him not understanding it.” – Upton Sinclair. If you don’t have a functional product then you will by definition not attract users. 100% of nothing is nothing and so even if we see thousands of apps with swiss cheese style security holes, if they don’t attract users it won’t matter in the big picture.

The second point follows is closely related. Those products that will gain users will almost definitely be written by those talented people that had a dormant gift for software. These people will also seek out and incorporate security and performance into their software. I don’t think anyone should stereo-type these new developers. I will bet serious money that some of tomorrows rock-star developers are office workers, farmers or grocery store shelf-stackers today. I learnt that lesson when we moved to France for a year in 2006. The Brit’s are notoriously poor at foreign languages and it is certainly true that many British people living in France can utter little more than “der baget” or “der beer”. However some people from electricians to young kids pick up French at such a pace that they become fluent in no time. The electrician re-wiring our house was such an example and we put my 6 year old (at the time) straight into the local school where he became so fluent in 3 months that the local farmer didn’t know he was British! Bear in mind in the South West of France they have a strong regional accent (Touloussian) so that is no minor feat.

I think the security industry should embrace the Learn To Code movement as a great opportunity to provide software security training to a new breed of developers.

I am on the look out for a good developer to create a set of code based online training like codecademy.com that we can release for free on the seconauts community when we launch.  If you are a good Rails developer and interested then do let me know!

Comments (0)

By Mark Curphey, October 13, 2011

An interesting quote from a Google (ex Amazon) engineer on the relative importance of accessibility over security

https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

“But I’ll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.”

Comments (1)

By Mark Curphey, September 24, 2011

My OWASP AppSec USA 2011 slides are now online (slideshare below) and PDF (16.3 mb) here. The video of me delivering the talk can be found here.

Comments (0)

By Mark Curphey, August 4, 2011

Today I was chatting to an intern about web security and we got onto a discussion about validating the authenticity of a binary download from the web. I drew the following diagram on my white-board that I thought I would share.

The first diagram (top left) describes how most web-sites include the hash or digest of the binary alongside the file. The intent is for the user to be able to download the binary, run it through a digest algorithm, compare the result with that displayed on the site.

The second (bottom left) diagram shows the problem with this approach. If an attacker is able to modify the web site then he can change the binary (or the link to the binary) and the digest.

The third diagram (top right) shows that the innocent user is now downloading a new binary. He can indeed check the digest but if it was changed to match the new file (a Trojan file for instance) then all she is doing is validating that it is in-fact the Trojan file the attacker wanted you to download.

The fourth digram (bottom right) shows that how this type of scheme can be improved when the digest is stored in a second site. While improved because the attacked now needs to deface two sites instead of one, its obviously not infallible.

Signed software is an improvement over this but is also prone to social engineering issues and as I once heard “knowing who sent the letter bomb isn’t that useful”!

Comments (2)

By Mark Curphey, July 17, 2011

I have decided to throw myself back into the software security fray and start a new OWASP project. I recently dabbled with getting involved in OWASP again through some current projects but for various reasons didn’t find a fit with my personal interests and thought that there maybe a way to have a bigger impact. I kept hearing that little voice from Dinis Cruz ‘if you don’t like what’s there today either change it or create your own’ so after some careful thought I decided to start a new project. I have always thought OWASP can be giant lab to try things and if an experiment fails no one gets hurt (well maybe your ego) so what do I have to loose!

For the last few years I have been more involved in building software than securing it albeit some of that software was indeed security software to help software security. I ran a team that built static code analysis tools (CAT.NET) and web protection libraries and for the last 18 months have run a team that builds a very highly volume web site that is not related to security. When security is no longer your sole focus you definitely view the world with a different lens and relate to security in a different way. It’s something you must (should) do rather than something you always want to do. Security will always be in my DNA so probably always have a higher order bit for me than the average software developer but at the end of the day it is just another attribute I need to think about much like performance, reliability, maintainability and code quality. Jon Willander has talked about in the context of complexity and I have often used a slide in talks showing:

security < performance < functionality

For some time I have mentally partitioned security tools as able to be divided on one dimension into two categories; those for security people and those for developers. In an ideal world I can imagine we could probably theorize that the tools should be one of the same but by way of example I think there are testing tools that a security researcher would want to look under the hood and into every nook and crevice and tools where a developer wants to know he’s done his due diligence. Developers need fast, repeatable, easy to use, low noise tools that produce actionable results and integrate seamlessly into their development process. That last point is key. For example tracking detailed security bugs in a separate tool maybe fine for security folks who want ultimate control of the data but for a development team it is essential they are managed in the development teams issue management system. If you want to add some form of automated security code review into a development process it is probably essential it can run as part of the integration testing or build verification testing etc. There are of course many security tool touch-points that a developer might hit and Andre Gironda provided some valuable food for thought when I was first thinking about this. I originally planned to call this project SIDE for Security IDE and look at better integration of security tools into IDE’s but the scope is and should be far wider. How do we integrate security into Continuos Integration (CI) environments, how do we integrate security into Agile management tools (Bryan Sullivan built an SDL Agile template for Team Foundation Server when he was at MSFT), behavior Driven Development and we need code quality tools to also be able to generate security quality reports. These are just a few early ideas (see backlog below) and I am still hoping we will be able to do some significant IDE integration / enhancement work as part of the project.

So here is my high level plan (of course subject to change)

1. Goal – Improve the adoption, efficiency and effectiveness of security tools in the end-to-end software development process.

2. Scope – Core project team to create an open source reference implementation of an end-to-end development environment that embeds security tools into the process. This may include developing or extending tools to fill gaps or configuring and adopting existing tools. Use only free open source tools in the reference implementation but show how commercial tools could be used. Probably settle on a P1 stack of Eclipse, Git, Jenkins, and an maybe ScrumDo (GPL) along with an open source issue management system.

3. How – Use Agile planning to build a backlog (of ideas). Run the project like any Agile software project (probably scrum) by grooming and prioritizing the backlog, creating a set of iterations and releases and running a set of sprints. If we can attract a set of developers to contribute we can operate daily stand-ups (I fancy using Google + hang-outs for this). Eat our own dog-food and be recursive in the way we adopt the reference model!

4. When – Paulo Coimbra will be setting up a mailing list and wiki page this week.

I will tweet @curphey and on Google + when the lists and pages are set up but all thoughts are welcome and of course if you are interested in participating do let me know.

By the way I know the acronym. You just can’t take life to seriously. Can you imagine T-shirts at a conference with “Got OWASP STD?”. Security Transmitted Disease of course!

Comments (1)

By Mark Curphey, February 23, 2011

There is a lot of good chatter about what I have learned is being called OWASP 4.0. A fourth generation project no doubt! I posted here and Michael Coates posted here which seems to be stimulating some good debate.

Ahead of meeting Dinis Cruz for what will undoubtedly be too much beer tonight I wanted to jot down a few thoughts on how we could organize OWASP 4.0. There are only so many beer mats you can assemble into meaningful diagrams in a brewery! This is very similar to Michael Coates excellent suggestions but with some subtle and I think important differences.

First I think its important to have a community for people who are engaged in planning and managing software security. These people range from the CSO’s to the scrum masters. There are a lot of important topics not covered at OWASP to day ranging from broad sweeping like application security scorecards and metrics to detailed issues such as how to estimate security during Agile planning.

Second I think its important to have a community for the architects and software developers. In this track you would cover the software design issues such as how to to AuthN and AuthZ, how to design secure WS*’s etc as well as code level implementation topics.

Test should cover the traditional security testing but also include topics aligned to the much bigger and more mature software QA discipline.

Finally Operate would be for those whose primary role is in deploying, monitoring and defending against attacks. There are really important topics in deployment and monitoring that I don’t think are well represented today.

The taxonomy or nomenclature is both trivial and actually very important. People who are consuming content (educational, documentation or tools) need to be able to easily identify with their role and navigate to material that they relate to. There clearly needs to be co-ordination across the verticals and over-lap may occur but for the most part projects should fit.

Across each of the sub-communities you would have a collection of high value projects that could generally fit into people (or education projects), Process & Documentation projects and Tools / Technology projects. Coding guidelines for Ruby for instances would fit into the Design & Dev community under the Process & Documentation bucket. App HoneyPots would be in the Operate community under the monitoring focus area.

Some communities would have more of a bias to build tools (Design & Dev and Test for example) and others move of a bias on documentation and process (Plan & Manage).

Underpinning the buckets is a need for commonality and reuse. This is where guiding principles fit, taxonomies and definitions. This ensures some degree of uniformity across the OWASP community.

There are some obvious gaps such as where do browsers fit and what about R&D / security researchers? Security researchers would scare most software QA people IMHO but I don’t have any magical suggestions.

I will follow-up tomorrow with a detailed post of what I would specially drive inside the Design & Develop community. That would include a set of GitHub repo’s, a CI environment and a set of AWS instances to start with. Dev’s need dev stuff to code with!