David S. Read

I am happy to report that I have been awarded the Certified Information Systems Security Professional (CISSP) by the International Information Systems Security Certification Consortium [(ISC)²]^a.

I started pursuing the certification in mid-2009, got serious about studying early this year (2010), took the exam in late April, was notified that I passed and had my background endorsed in May, had to update my resume for an auditor in early June and was awarded the CISSP designation at the end of June.

I felt that this certification was important both professionally and personally.

Professionally, the certification serves as a validation that I have a solid and broad understanding of information systems’ security.  People who have worked with me know that I have been focused on IS security for many years.

Whether performing security-centered code reviews, fixing flawed implementations or teaching designers and developers how to improve the security of their systems, I have been on a mission to mentor and train people to observe effective security practices and principles.  I’ve also had operational responsibility for system infrastructures.  With that experience I was able to pass GIAC’s GSEC and Red Hat’s RHCE exams several years ago.

Personally, the process of studying and passing the exam allowed me to pursue and attain a non-trivial goal.  I am enrolled and taking classes toward my master’s degree, but completing that work will require several more years of part time attendance.  Setting and achieving intermediate goals helps to keep me focused and learning.

If you are wondering what the CISSP is all about, please read on.

(more…)

Encapsulation, one of Object Orientation’s (OO) “Big Three” (or four if you include composition), is the concept most often forgotten when I ask an interview candidate to define the key tenants of OO.  Giving the benefit of the doubt, perhaps it is considered “obvious” and hence not necessarily related to OO design in the person’s mind.  Once I bring it up though, there is usually agreement that it is an important aspect to achieving significant value from OO design.

Classically, encapsulation, also called information hiding, “serves to separate the contractual interface of an abstraction and its implementation.”¹ The idea is that the user of the functionality only knows about the public interface (contractual interface) and has no knowledge, nor any ability to tie itself, to the implementation.  The implementation includes both data representation and, effectively, algorithm.

Many times I’ll get an alternate definition; essentially the respondent will define encapsulation as, “as an approach which allows an object’s behavior to be called without the caller having knowledge of how the behavior is implemented.”  This seems very close to the classical definition but misses the key point of “contractual interface.”

I could argue that when any method is called the caller doesn’t have knowledge of how the method is implemented; it just gets a value back.  The missing aspect, the key aspect, is the constraint regarding which methods the caller may call, e.g. the public interface.

What started me on this topic was a recent conversation with a peer regarding read-only objects.  Before I get into specifics, let me baseline the traditional encapsulation approach in a typical object.

(more…)

As I read more and more about the Toyota debacle I’m struck by an apparently myopic management drive to cut costs.  In the case of Toyota it appears that cost cutting extended into quality cutting.  A company once known for superb quality had methodically reduced that aspect of their output.  This isn’t just conjecture; it seems that people inside the company had been aware of a decline in quality due to a focus on reducing costs.¹ Is there a general lesson to consider?

I believe the failure is one of misplaced focus. The focus when Toyota began cutting costs was to remove waste.  That waste could be found throughout their manufacturing processes.  Wasted materials, productivity, tooling, and equipment were all identified as Toyota’s management and workers struck out on a journey to reduce waste and improve productivity.  They ushered in a set of practices that others would soon adopt.

Head back to the 1950′s and you’ll find Taiichi Ohno² hard at work addressing myriad manufacturing shortcomings at Toyota.  Mr. Ohno is really the father of lean manufacturing and just-in-time inventory management.  He didn’t name them as such.  He was just trying to remove waste from the entire manufacturing process.  By the late 1990′s these concepts had become standard operating procedure at many firms.

It makes sense that a business would focus on reducing waste.  Although it may require effort to remove waste without reducing productivity, overall one would expect a leaner process to have an overall efficiency gain.  It would also seem that quality does not benefit from waste.  After many years of experience with these principles, companies have found that an approach of using only the resources that are needed when they are needed provides a sound basis for their operations.  So what happened at Toyota?  They apparently went beyond cutting waste.

(more…)