• An Introduction & Brief History (I swear I will not start with a caesar cipher or ROT13!)
• Symmetric Key Cryptography (Private Key Cryptography)
• Asymmetric Key Cryptography (Public Key Cryptography)
• Digest Algorithms (Hash Functions)
• Digital Signatures, Non-Repudiation & MAC’s
• Digital Certificates, SSL & PKI PGP & S/MIME
• The Promise of Quantum Cryptography
• Key Management
• Cryptographic Standards
• Why Cryptography Often Fails
• A Word About Crypto Snake-Oil

What else does a developer need to understand (or be able to look up ) ?

The list is managed by MailChimp so you can always un-subscribe and I will only ever be sending one email a week.

It’s very simple. A few static pages with a sign-up form (that points to MailChimp), and an archives page. I used Heroku and wrote a little Rack app to publish the static pages.  git push heroku master and it’s all ready to rock and roll! Doesn’t get easier than that. Code is on github as I suspect when I have some more time I will build something more sophisticated.

If you have news you would like included then mail me at news.desk@softwaresecurityweekly.com

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

Video streaming by Ustream

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

Create Local Repository from an Existing Local Project

• 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

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!

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.

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