July 22, 2011

Twitter Feed

  —A look at Twitter feed service.

Found a cool service that automatically publishes new blog posts to your Twitter account. Check out Twitter Feed.

2018-05-09:

Twitter Feed is no longer in service. I moved my feed to dlvr.it.

2018-06-09:

Moved my Twitter feed to IFTTT.

July 17, 2011

The Accidental Creative (Book Review)

  —A book review on Todd Henry's book Accidental Creative.

I am currently reading Todd Henry’s new book The Accidental Creative. I have been a subscriber to his podcast (also called The Accidental Creative) for several months and pre-ordered the book as a result of what Todd had to say during those podcasts that preceded the publication of his book. His podcasts are engaging and always left me with something to think about. A few prompted more investigation into the topics he discussed. They are definitely worth checking out.

In truth, I wasn’t entirely convinced that the book would be a worthwhile read but ultimately decided to purchase it because I admired the quality of the messaging Todd created around the book—if you enjoy a good marketing campaign it is worthwhile to look at how Todd marketed this book. There was something about the consistency and creativity behind the messaging in the podcasts that resonated with me. It left me with the impression that the quality of information in the book would be high even if that content turned out to be a repeat of the podcasts.

I am happy to say that the book has not disappointed. The podcasts complement, rather than repeat, what is in the book. Reading Todd’s book has provided me more insightful and thought provoking material on creativity.

The bulk of the book describes a framework that Todd says will help sustain creativity over the long term. I love frameworks because of the consistency they provide and because of the insight they can provide if you aren’t dogmatic when applying them. Todd’s framework was refreshing because it is well rounded and brings together elements that he says positively affect your ability to sustain creativity over the long term. I haven’t seen an approach like Todd’s associated with creativity before—much of what I have read on creativity has come from Edward de Bono.

I like a couple of Edward’s books but his focus on thinking and creativity uses an entirely different approach from Todd’s. Todd does quote Edward in one of the chapters so it is possible that Edward’s work influenced Todd’s. I view Edward’s books as being focused more on methods that improve your thinking and therefore your creativity whereas Todd’s book takes more of a whole life approach that addresses sustainability. You could liken Edward’s approach as the building blocks and Todd’s as a way to leverage those building blocks consistently over the long term.

I won’t describe Todd’s framework other than to say that it held two valuable insights for me—there are many other insights in the book but these two were the most valuable for me. The first insight was the idea around the use of his framework with other frameworks. The second was how to create relationships to improve your creativity.

In the former, Todd mentions using his framework with other frameworks. He makes some comments on his use of David Allen’s Getting Things Done but doesn’t go into detail on how to integrate the two frameworks. It was encouraging to find that Todd uses Getting Things Done and that the ideas in his book could be integrated into Getting Things Done. One of Todd’s podcasts includes a discussion with David Allen on using Getting Things Done to improve creativity. That podcast is an excellent resource to get yourself thinking about how David’s ideas and creativity work together.

In the later, Todd devotes a whole chapter to the value of relationships and provides concrete ideas on how to get more value out of your relationships to improve your creativity. I like the ideas presented in this chapter because one of the things I’ve struggled with increasing the diversity of my own network and engendering discussions with people who share the same interests and level engagement in the things that really fascinate me. I’m not convinced that I’ll use the AC Circle idea but I certainly think that this is a valuable way to approach the problem. AC Circles is a program that encourages people to meet and discuss ideas related to improving and maintaining their creativity.

I am interested in hearing from anyone that has started or participated in a circle as described in the chapter on relationships. This is an area of the framework that I recognize as valuable but also recognize as potentially difficult to carry out—I can see it working well in something like a writing workshop or in a team where people share a common idea around the need to being creative but I currently lack the insight into how to apply this effectively.

I think the key value provided by this book is the framework Todd provides for sustaining your creativity. Like many of these types of frameworks two things are apparent: you can pick and choose elements you want to lesser effect or you can embrace the framework and try and achieve the full benefit of it. You choose.

Overall, the book is an enjoyable and easy read that focuses on what you need to apply in order to sustain your creativity. Like all frameworks they are only as valuable as the amount of effort you put into them. I haven’t started applying his ideas yet, but I am encouraged by what I’m reading and looking forward to finishing the book and learning more of his approach.

The Accidental Creative: How to Be Brilliant at a Moment's NoticeThe Accidental Creative: How to Be Brilliant at a Moment's Notice by Todd Henry
My rating: 5 of 5 stars



View all my reviews

January 5, 2011

Software Preservation Group

  —A look at the original LISP paper.

In A non-hierarchical approach to object oriented programming, Pascal Costanza provides a pointer to the original paper, a copy of which is available from the Software Preservation Group. If you are interested in original papers or understanding the history of your favourite programming language then the Software Preservation Group is the place to go.

The original documentation and papers from John McCarthy are available under the LISP 1.5 Family.

December 29, 2010

Selecting a Coding Standard for PCI DSS

  —A look at coding standards for PCI DSS.

In “What About the Confused Deputy” I point out that PCI DSS requires industry best practices, information security, code reviews and secure coding practices be incorporated into an organization’s Software Development Life Cycle (SDLC). PCI DSS suggests using OWASP for web applications but it does not provide guidance for addressing custom applications.

What industry best practices and standards are appropriate for the development of custom applications? For secure coding practices, the first place I looked was the CERT Secure Coding Initiatives. CERT defines secure coding standards for several commonly used programming languages.

The clearest explanation of how to use CERT’s Secure Coding Standards is the document describing the MITRE CWE and CERT Secure Coding Standards. The Mitre Common Weakness Enumeration (CWE) is a measurable set of software weaknesses that includes categories for architectural, design, low level coding and design errors. 

The CWE includes different views of these software weaknesses. One view, CWE-734 enumerates the weaknesses addressed by the CERT C Secure Coding Standards. Adherence to the secure coding standard will avoid these weaknesses. CWE-734 also provides insight into weaknesses not addressed by the CERT C Secure Coding Standard. This insight can be used to identify weaknesses that may need to be addressed elsewhere in the SDLC.

The CWE also provides views for the OWASP Top Ten. See CWE-711, −629 and −809.

December 19, 2010

What About the Confused Deputy?

  —A look at CSRF and PCI DSS requirements.

In Spoofing Google search history with CSRF, Jeremiah Grossman shows how to create a CSRF (Cross Site Request Forgery) using the Google Web Service. Fortunately, his example is educational rather than destructive. An analysis of the blog entry’s source code reveals a single HTML statement as the primary culprit for delivering the CSRF. CSRF is so prevalent that PCI DSS includes explicit requirements to address it.

In PCI DSS, Requirement 6.5.5 states that all web applications must be developed using secure coding practices that prevent CSRF. The testing procedure for this requirement seeks to ensure that web applications do not reply on authorization credentials and tokens automatically submitted by browsers.

The guidance for this requirement introduces the notion that a CSRF is as powerful as the web application it attacks. I don’t like the language in the guidance. It implies that CSRF is constrained in a way that is difficult to quantify. The text in PCI DSS may have its origin in the A5 entry for CSRF in the WASP 2007 Top Ten. The A5 entry says, “CSRF can be as powerful as the web application that it attacks”. This is not in the OWASP 2010 Top Ten description on CSRF. But I digress.

CSRF is an example of the Confused Deputy problem. The Confused Deputy problem involves a computer program that is innocently fooled by some other party into misusing its authority. In CSRF, the browser is the Confused Deputy.

Since PCI DSS has explicit requirements and guidance for preventing CSRF it seems natural to look at how PCI DSS addresses the Confused Deputy problem in general. Part of the answer lies in Requirement 6.3 and Requirement 6.3.7.

Requirement 6.3 talks in general terms about a Software Development Life Cycle (SDLC) based upon industry best practices and incorporating information security throughout the SDLC. Requirement 6.3.7 provides guidelines for dealing with custom applications and public facing web applications. It requires a review of custom applications prior to release. It suggests (but does not require) having individuals knowledgable in code review techniques and secure coding practices to review these custom applications. In the case of web applications it provides a reference to OWASP.

Aside from the browser the responsibility for preventing other Confused Deputies is delegated to unnamed industry standards, information security, code reviews and secure coding techniques embedded within a SDLC. Is CSRF singled out because there are well understood ways to prevent this attack or because PCI DSS takes a prioritized approach to addressing security vulnerabilities?

In The Prioritized Approach To Pursue PCI DSS Compliance, Requirements 6.3 and 6.3.7 are allocated to Milestone 3. Milestone 1 removes unneeded authentication data and limits data retention. Milestone 2 controls the points of access used for most compromises.

If the data doesn’t exist it isn’t at risk, so placing Milestone 1 before 3 is the right way to go. Placing Milestone 2 before Milestone 3 limits access to the system, thereby increasing the protection provided to the internal and perimeter networks. This leaves the relative priority of a browser and another Confused Deputy up for debate. The requirements for addressing these are in Milestone 3 and the standard doesn’t define relative priority for requirements within a milestone.

The relative priority of protecting against a Confused Deputy comes down to a risk assessment of the likelihood of the Confused Deputy being discovered and exploited. OWASP provides a method for developing a risk assessment. Using this risk assessment method, a browser has a greater likelihood of being exploited than a custom application whose existence may not be known, all other risk factors considered equal. If the application is not custom then a risk assessment is still appropriate.


Notes:

The link to version 1.2 of the Prioritized Approach to PCI DSS has been replaced with a new link. Version 1.2 has been superceeded by revised documents. The requirements and milestones in this article remain unchanged.