Background

Earlier this year I published Web Application Security: Exploitation and Countermeasures for Modern Web Applications.

I was lucky enough to have this book published by O’Reilly Media, the largest technical book publisher in the USA. You may know them by the animal sketches on the cover of each book.

When I got started with the itch to write this book, I knew nothing about technical book publishing so I decided I would write a blog post incase any other aspiring authors want to learn how the system works.

Purpose

I decided I wanted to write Web Appliction Security because I couldn’t find any books that met the following criteria:

• Teach Web Application Security (as in the full application stack, not just one part)
• Well Organized, Easy to Read
• Offensive and Defensive viewpoints
• Modern, covering the latest vulnerability types within the last 5 years

Literally go to Google or Amazon and try to find another book that meets those criteria. You have a couple books like the Hacker’s Handbook which cover a lot of content, but cover it more like a dictionary of attacks - it’s not a good format for beginners, very few could read it cover to cover.

There are also some books like Web Application Security a Beginners Guide, which is a good book but isn’t modern and suffers again from being very difficult to read from cover to cover.

Even if you take a $3,000 SANS course you are taught with legacy technology, old versions of Apache, PHP, etc. This isn’t what new Web Applications are built on top of.

So if I had to summarize I wanted to write this book because when I was learning web application security I literally couldn’t find any good resources you could read cover to cover and come out with a solid understanding of how to attack and defend modern web applications.

I kept these things in mind when writing my pitch.

Pitch

As an unknown wanna-be author, it’s a bit difficult to break into the industry.

I knew I wanted to publish a book, but the book wasn’t written yet. So I developed a short pitch that I emailed out to a number of my favorite publishers.

The pitch basically summarized the purpose of the book above, but also included how I planned on marketing the book as well as some information on the length of the book, type of code samples, languages, frameworks, etc.

I think I sent my pitch to 6 major publishers, got responses from three and had two that where interested in publishing the book for me.

Market Research

Both of the publishers that where interested in the book requested market research prior to agreeing to publish for me.

They had me collect a list of the following:

• Size of Web App Security Occupation (#)
• Web App Security Occupation Growth Rate Estimate Annually (%)
• Security related trends, aka what % of attacks are targetting this surface area
• Top countries where Web App Security is a career
• Average spending income of people in this field, or looking to transition to this field
• A list of direct competitor books
• A list of indirect competitor books
• Evaluation of if similar material is being taught in other formats (eCourse, University, etc.)

Collecting the information was a bit difficult, due to lack of good sources - but after it was collected both publishers where interested in writing up a contract.

One publisher told me they actually had already planned on expanding their application security book offerings, so I imagine this is just a due diligence exersize to some extent since the publishers already have some idea of what books they want.

Contract

Drafting a contract is the next stage. After having my pitch and market research approved the publisher I chose moved me into contract drafting stage.

I was able to negotiate an advance, which I was happy with - mostly because it showed me the publisher was serious about working with me. I was not able to negotiate on my royalty rate, but where I to publish another book I definitely would negotiate harder for that to be increased.

The hardest part of the contract drafting was the tenative table of contents and page count. I assembled a number of topics I wanted, and tried to estimate the length of each - but estimating length for something unwritten is quite difficult.

I was informed that the ToC and page count could change, if my editor approved - which is good because I now realize why some books seem to be “fat” - they add in un-needed fluff to meet their contractual page count agreement.

Luckily my editor turned out to be great, and was totally onboard with cutting out fluff and negotiating on behalf of me so that I could create the most streamlined experience possible. We eventually cut pages and even whole chapters multiple times to make the book flow and read better.

I signed on the dotted line eventually and started writing.

Writing

O’Reilly let me know that I could write my book in MS Word if I wanted (eww), or try their new in-house software called Atlas.

Atlas was great to work with as it supported a templating language (ASCIIDOC) so I didn’t have to fight with Word’s terrible behind-the-scenes XML-based formatting.

Atlas was also capable of converting my writing to many formats, sizes and devices - as well as letting me preview what it would look like fresh from the printer. I used this feature probably thousands of times making sure the pages ran together nicely without awkward mid-paragraph breaks, or funny image positioning.

The actual writing itself looked like this:

1. Agree with Editor on Topic of Chapter
2. Write Chapter
3. Get Feedback from Editor
4. Incorporate Feedback

After several chapters in a row where complete, I would re-read the book from start to finish to make sure it flowed well and could be easily read by my target audience. In total, I re-read the entire book somewhere around 50 times.

It was exhausting, but my goal was to make a book that you could read cover to cover - so I felt it was required.

After finishing the entire book, it was passed to an editing team that spent about a month working on finding typographic issues - typos, grammar bugs, etc.

Afterwards, it was read by an internal reviewer to make sure it flowed smoothly.

Next, it was reviewed by a number of industry experts (6 or 7 I believe) from various software companies in order to audit the technical content.

Finally, the book was ready to publish and begin printing.

As far as time consumption went, every Tuesday and Wednesday after work I started working on the book at 6:00PM and finished at 10:00PM. This went on for 18 months from start to finish.

I used timers and my calendar so that I could be very strict about my time usage, because I worried I wouldn’t be able to release the book in the timeframe dictated in my contract if I didn’t. I only missed one or two days in that entire period of time, which I am very proud of - but in retrospect I think while I was very efficient it was also incredibly draining. If allowed, next time I would push out the release date to 2.5 years instead of 1.5.

In total, it took about 650 hours to write and publish the book.

Marketing, Distribution & Promotion

Originally, I expected that as an author I would focus on writing the best security book ever - and my publisher would focus on marketing the book for me.

Little did I know, authors are actually expected to do most of the marketing! Surprise!

That was probably my least favorite part of the process, and the reason I would require a higher royalty rate if I where to write a future book.

I decided to go with the flow and continue trying my best though, so I scheduled a number of speaking events at security conferences to promote my book - but than Covid-19 hit.

In the end, most of my marketing ended up just being word of mouth. Luckily, I had a handful of security professionals reach out to me that really liked the book - and several of them promoted it at their companies or their classrooms. I think this helped sales quite a bit.

I did build a marketing webpage as my publisher suggested - but it hasn’t got a lot of hits and no one has really promoted it so it’s just sitting there lost in the endless hordes of data stored on the internet.

As far as distribution goes, O’Reilly did a great job. They got the book on Amazon, Barnes and Noble, Borders, and tons of smaller web and physical bookstores. Covid-19 definitely hurt my physical book store sales, but again nothing anyone could do about that.

Lastly, O’Reilly did a great job and within 6 months of the book being out was able to close a bulk deal with a large tech company - to date this deal has made up most of my readers and revenue.

Closing Thoughts

Obviously, writing a book is a difficult and time consuming experience. Writing a good book is even more difficult and time consuming. It’s likely that any software engineer or security engineer could make more money consulting/contracting. However, writing a book did have it’s perks.

While their where restrictions, I got to have a bunch of creative freedom and control over the content - which really made the process enjoyable.

I also got to work with some really good editors, and eventually technical reviewers. This was fun, and lead to a bunch of cool networking opportunities with people who do the same things as me but at different companies.

It was definitely a stressful time in my life, balancing a full-time job and two days per week of four hours of writing.

Ultimately, I wrote the book to help people who where in the same position as I was in at one point in time - trying to learn modern web app security with no good resources available. I am very happy with the results from that perspective.

I’d suggest any aspiring tech author to strongly consider why they want to write a tech book. It probably won’t make you famous, nor will it make you rich. So definitely consider doing it, but only if you have other motives like helping others or a joy of writing.

I might write another book someday, but I am planning on taking some time off to enjoy nature and get back to my more relaxing hobbies.