Comments (3)

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 21, 2012

I just found this online

Video streaming by Ustream

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 (2)

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 (2)

By Mark Curphey, December 30, 2011

At this time of year many people look towards diet experts and the diet industry to shed a few pounds. My wife is no exception. The trend in the UK among her friends (we live in the US but are British) seems to be the Dukan Diet. You can go online and answer a few questions and magically it will tell you your “ideal weight”.

For fun we submitted the same results to the UK (http://www.dukandiet.co.uk/) and US ( http://www.dukandiet.com/) versions of the site and to our surprise found that the US site gave an ideal weight that was 7lbs more than the UK site (130 lb for the US vs 123 lb for the UK). She is already at the US ideal weight! We submitted a support ticket suggesting they might have a bug and got back the mail below.

“Due to the American diet, we have adjusted our True Weight a little bit as it may be harder to stabilize and maintain a lower True Weight. People who eat in France or the UK can take advantage of fresher and healthier ingredients (no hormones, no pesticides, etc.) as opposed to their American peers.”

While we have Whole Foods, and farmers markets (we get a organic vegetable box delivered weekly) it is indeed MUCH harder to eat well in the US. It’s all about quantity and not quality, there is sadly little general awareness of where your food comes from, people accept highly processed food as “normal” and even seemingly healthy choices like many Whole Foods own brands are stuffed with evaporate cane juice. Organic cane juice is still refined sugar!

Come on Americans, it really is time for a real food revolution. I am tired of seeing all the over-weight people on the streets, all the junk food in restaurants and stores and the lack of awareness about where your food comes from.

I plan to now post regularly on healthy eating.

Comments (3)

By Mark Curphey, December 18, 2011

A major part of the Practical Software Security book will be a collection of discrete guidance topics covering design and implementation of end-to-end scenarios that most modern development teams will face. Over time we expect to expand on the scenarios in the book and probably maintain an online repository (including technology specific versions).

I just started building an initial list of scenarios and would love input on important scenarios you think we should cover. My initial list is below.

- Managing Sensitive Data
- Practical Cryptographic Key Management
- Federated Authentication (OAuth & FaceBook Connect)
- Designing User Management Systems (passwords, password resets & profile management)
- Authorization Models
- Avoiding Input Validation Vulnerabilities
- Connecting Web Services Across the Internet
- Safely Storing Data on a Client (Browser + Mobile)
- Preventing Bots and Making Sure Your Users are Humans
- Signing Code and Distributing Applications
- Setting up a Cloud Deployment Environment

Cheers!

Mark

Comments (4)

By Mark Curphey, December 17, 2011

There are two very exciting side-projects that I have started brewing.

The first is that I have agreed to write a book with my friend Bill Hau called “Practical Software Security”. We have signed a contract for the book to be published by O’Reilly in late Summer 2012.

The second is that we have agreed with O’Reilly that we will release the book online for free from day one under a Creative Commons license as the seed for a new security community that we are going to launch. We expect that community to be called “Seconauts”; if Astronauts explore space then Seconauts explore security!

The Book – For a long time I have wanted to write a book on software security that was targeted firmly and squarely at software developers and software development teams. Security books are generally written by security people and I think for security people. When a software development team decides to include security into their development process they need to understand a wide array of topics including code level security, infrastructure security (which these days often means cloud security), security concepts like identity and cryptography and of course security management issues like the Payment Card Industry standards. They need to determine how best to apply security practices, security technologies and security tools into their (typically) established development process; conscious that it should not make them less effective or less efficient at their primary goal of building great features and shipping those features to users as fast and as often as they can.

Today I believe that software security guidance is largely offered by people that have limited real-world experience or working knowledge of how software development teams actually work (especially modern agile teams). They operate with a lense strongly focused towards the viewpoints of a security centric brain. Put another way, they live and breath security and have an interest in software development, as opposed to living and breathing software development and having a healthy interest in security. To make it worse security culture is still deeply rooted in “hacking”, something clearly evident if you attend a security conference and observe the “handles” and “street” language describing issues. This cultural mismatch often results in developers dismissing the security industry and messages coming from it as ‘sabre-rattling’.

The book we are writing is intended to be the only security book a development team would need to buy to implement an end to end security program as part of their development process and to solve the common security related scenarios they will face. That is certainly not to say it will cover all security information they will need to know but will hopefully provide all of the core knowledge they need and empower them to find and digest anything else they need to understand.

We have literally just started wiring in the writing process but the current table of content looks like this:

- Foreword
- Introduction
- Security Concepts
- Tools and Technologies
- Building a Software Security Program
- Securing Common Scenarios Across Mobile, Web and the Cloud

Foreword
The foreword will be written by a very well known software development person (not a security person). Enough said!

Introduction
The introduction will set up the business case for security including a set of case studies, a discussion of security as a software quality attribute and security as a business enabler. The section will likely conclude with two sections, “know your enemy” and “know the attack vectors” in which the reader would learn about the types of attackers and the types of attacks they use.

Security Concepts
This section will provide a ‘200 level’ education on the important security concepts that members of a development team should understand in order to make informed decisions. Starting with a overview of cryptography covering symmetric and asymmetric algorithms the section would then describe how cryptography can be used to solve real-world problems such as protecting data in transport and storage and digitally signing messages and would cover important cryptographic systems such as SSL and signing code. It would discuss identity in the context of authentication and authorization, covering types of authentication and with a special emphasis on federated models. It would cover models for authorization describing the pro’s and con’s to consider with each approach. It will cover auditing and logging, security monitoring and close with a solid discussion on data validation. These sections will all tie back to the common attacks described in the previous main section.

Tools and Technologies
This section would provide a jump-start into understanding the security features that can be used in web, mobile and cloud technology stacks, along with any useful security extensions or related technologies.

- Fundamentals : HTTP, mobile device carrier networks and infrastructure security like web servers and firewalls.
- Web : Java, PHP, Ruby on Rails, .NET, JavaScript, Node.js etc.
- Mobile : the major mobile operating systems of Android and iOS.
- Cloud : platform as a service using Amazon Web Services, Heroku and Google App Engine for examples.

Building A Software Security Program
This section will provide project leaders and development managers a blue-print to build and manage their own software security program. Starting with requirements, design & planning and a description of how to implement security into application architecture we will then cover secure coding, testing and QA, ‘DevOps’, security standards and regulations, education and awareness, dealing with 3rd parties like vendors partners and auditors and finally outsourcing. The section will also discuss tools for security including the obvious security code analysis type tools but also specifically focusing on adapting common development tools like Behavior Driven Development tools towards security tasks. The section will end with detailed description on how security fits into modern agile and test driven development practices and how security metrics (like “Coder Metrics”) can be used to drive continuous improvement.

Securing Common Scenarios Across Mobile, Web and the Cloud
The final section is expected to be the largest in the book and will be a section that describes recommended solutions to common scenarios that most development teams encounter. We think it would be prudent to ‘ask the crowd’ to help us define a prioritized set of scenarios but we would expect them to include things like the 10 examples below.

1. Storing personal data
2. Managing credit cards
3. User Registration
4. Password Reset Systems
5. Security of REST API’s
6. Exposing web services end-points across the Internet
7. Preventing bots and making sure users are humans
8. Signing mobile code
9. Setting up a cloud deployment environment
10. Consuming upstream data from an untrusted 3rd party

I will be inviting a number of people I rest and consider subject matter experts to contribute to the book in various ways.

As I mentioned the book will be released for free online (we of course want you to buy the Kindle and paperback versions) as the seed material or a new security community we are going to start. That community will be called Seconauts and will be very different from current communities. We don’t all of the community model worked out but it is fair to say it will draw heavily from observing OWASP. I want to stress that it will be very different from OWASP in many ways. For a start it will focus on a small number of high quality projects that support a clear project roadmap. The development of projects and some discussion forums will be “invite only” model and we will be working on a system of community recognition. We certainly don’t have all the details worked out yet but there will be a community points system that will not only allow people to earn points for activity (we we recognize the actual people doing the work), but it will also allow peers to rank contributions and for all contributions but be tied to the social graph of how that person became part of the community. Thats a long winded way of saying the community recognition system will encourage A players to invite A players, penalize B players that invite C players and ensure that those that actively participate and whose work is highly regarded get the recognition they deserve. Designing that is going to be fun!

We have partnered with Mike DeLibero (awesome developer) to build out the first part of our community site that will be a discussion system using Ruby on Rails to support a limited set of people we will be inviting to provide ongoing feedback on the book manuscript. We have the early part of that system running now (it’s based on an existing open source project) and expect to have a working beta in March. This will allow us to have online forums and an integrated mailing list and will take the manuscript (being written in markdown) and process it regularly into html, pdf and .epub formats for review by those initial community members. I doubt well have the community points system in place for the initial book review but it’s definitely our intention that these reviewers will earn points for their review activity and then seed the community by inviting others to join when the time is right. I definitely want to find a way to continue to develop a patterns repository expanding the scenarios both in terms of the types of scenarios and specialized versions of them (i.e. how to sign mobile code on X technology and Y technology). I hope we will eventually host a weekly video show, a rolling news blog, conference and series of workshops but one step at a time. You can follow @seconauts now although it won’t be active until the new year.

I am passionate about the book and passionate about creating a different type of security community, so it’s a fun an exciting time.

Cheers!

Mark

Comments (0)

By Mark Curphey, November 6, 2011

This week I decided to invest my personal time moving forward in thinking about a new type of security community and not invest any more personal time in OWASP. This post is about some thoughts for a potential new model for a different sort of security community but before I get to that I want to make sure I am crystal clear about my feelings for OWASP.

I started OWASP when I was running a corporate software security program (at Charles Schwab in San Francisco) and am very proud to have had an opportunity to take that first small step of seeding an internet idea for openly sharing knowledge and collaborating together that other people picked up and ran with to make it what it is today. I think OWASP is awesome in many different ways and has accomplished a great deal. There is no debate that it has been “the” popular community project for application security for the last decade and has a vibrant and thriving following today. It’s raised awareness among the security industry of the relative importance of application security and developed software projects and documentation projects that are cherished by the security community.

At the same time I think OWASP has not been successful in raising the awareness of the relative importance of security with developers and has not developed software projects or documentation projects that are cherished by the development community. I have tried to prod, push and poke at the OWASP community to get it to change direction and evolve towards the vision I have always had (and where I think OWASP could have a bigger impact) but it has become evident that that is counter to what the “community” wants. There is of course absolutely nothing wrong with a big global community where the swarm takes the project in a certain general direction. It’s certainly one type of community model where there are significant benefits around “economies of scale” such as the ability to attract large numbers of people to attend conferences, sponsorship, media attention and access to a diverse range of people to participate.

There are also significant disadvantages that are probably not un-similar challenges that large companies face (and yes I know all about this). If they are not careful big organizations loose focus, loose touch with their customers and become bureaucratic and slow. They loose the magic they once had and stop focusing on producing a relatively small number of high quality products in favor of keeping the momentum going. If the swarm becomes a mass of brownian motion then it doesn’t matter how fast each atom is moving if it’s all going in random directions. I think OWASP is trying to be everything to everyone and a “Jack of All Trades is a Master of None”. There were several straws that broke the camels back for me in the last few weeks including adopting SourceForge to manage projects (a solution to developers that is what MySpace is to teenagers), the project committee endorsing community projects that have very little security value or relevance to software security (really, a database of favicons and malware ?) and a set of aspirations and plans on impacting frameworks that I think will struggle with credibility among the framework providers. In short I don’t think OWASP is set up or currently able to effectively impact the relative importance of security among developers and my personal opinion of it’s culture is that I don’t see how it can now adapt to fill that void. I have opinions on how things will turn out: at the same time I genuinely hope my opinions are dead wrong.

Summary: OWASP is an interesting successful security project with stacks of stuff going on for security people but is just not for me. I want to be part of a developer centric security project where the focus is on a small number of high quality projects and where there is a clear sense of values and direction. I want something different.

So the obvious question is “What would that community look like?”.

When thinking about models for better communities there are a number of things that I would now place importance on. It’s very interesting to study some of the emerging communities like Forrst and look at established software projects like Ruby on Rails and Apache.

Managed Membership – The most important thing is working with people that share common values, interests, standards and philosophies. Of course there will always be differences but I mean “common” around themes (like quality and scope) and not details. Communities grow organically so as new people join, the gene pool changes a little each time and over time changes a whole lot. If you don’t have a model on how to mange the gene pool of your project its possible that Type-X people will invite Type-Y people who in turn invite Type-Z people and before you know it you don’t relate to the vast majority of the community. Kevin Rose spoke about this about changes like the that happened as he grew Digg. Managed membership ensures that you attract similar people and continue to work with people that share the common values, interests, standards and philosophies. Forrst is an excellent community for designers and developers that has built a membership model to do just this. They initially require users to be invited. Existing members have limited numbers of invites so are insented to using them carefully. Members are referenced from their GitHub account as a low form of “he/she is a developer and I can see his public work”. The model is certainly not perfect and I could see lots of opportunity to improve it (introduce a star to the community and you take some of the credibility etc.) but I now strongly believe that some form of managed membership is a good thing.

Strong Leadership – Steve Jobs proved it works and there is a re-birth in the appreciation for strong leaders. I think that a strong leader can set out a vision, working models and standards and catalyze a community to deliver magic within a strong framework. It’s not dictatorial but directional. If you look at the Ruby on Rails community as an example, while there are a number of core members, DHH is a strong leader who makes bold decisions (like integrating Merb). I have grown a real appreciate for the phrase “In all of your towns and all of your cities, you will never find a statue celebrating committees”. Committees and the Internet age are not natural bed fellows!

Audience & Engagement – A community audience is not necessary the community itself and I would go as far as to say that there is often danger in the community being the bulk of the audience. If the core Rails team just built tools for themselves I doubt you would see the adoption of Rails among average developers. How many core rails developers use scaffolding themselves as an example? Of course there is nothing wrong with building things for yourself, in-fact “scratching your own itch” is a superb strategy in many cases but I think a software security community has to have key representatives from the big frameworks and technology companies (browsers and run-times) as well as a working good representation from the major online sites like FaceBook, Amazon, Google etc. It MUST understand and work directly with its audience. The irony of engagement of course is often the very people you would like to be engaged are probably the very people that don’t have time, a cycle that you need to break early. In talking off-line with friends some have suggested that an engagement model where community members (see above) meet at a summit, share priorities and agree on projects (see below) which are then developed as focused workshops would allow many people to work on projects in balance with their day jobs.

Focus & Quality – You can’t be everything to everyone. As Gunnar Peterson says “if you defend everywhere you defend nowhere”. I think it’s key to decide on a few key projects and double down your effort on making sure that you apply the right resource to make the right projects successful.

In some ways I wish timing were different as I have many things going on right now (demanding current job, potential start-up next year, considering writing a book “Software Security for Teams: End to End Security for Software Developers” this winter and much more) but if someone were to start another security community I would hope they would do it something like this.

1. Have a strong leader

2. Build a site with a solid membership model and good discussion facilities (like Forrst)

3. Organize a “Security Summit” and invite 20 – 30 people whose views you value to deliver a 10 min TED style talk. Everyone delivers their version of “The biggest challenges in software security today and how I would make a significant impact on them in a year”.

4. Find a sponsor whose logo would appear on each talk broadcast on YouTube to pay for the summit itself.

5. Give all summit members a single equal vote (can’t vote for your own ideas of course) and pick the top three projects. This becomes the Community Top 3 Issues for the year and the projects annual roadmap.

6. Appoint strong project leaders and allow each summit member to nominate two additional workshop attendees (subject matter experts).

7. Run week long quarterly workshops where all summit members and workshop attendees create deliverables (documents or software).

8. Release all work at the end of the year (or before if fully complete and of high quality) as open source, unimcumbered by copyrights and patents.

Rinse and repeat.

Food for thought!