Globalization

One of the keys to globalization came ca 1970 with the international standardization of the shipping container. Much of our economy and standard of living depends on the ability for China to ship me insane things like free McDonalds Happy Meal toys or a 20lb iron anvil at virtually no cost. Low shipping costs are part of the equation that makes it easier for me to buy goods from China than it does a craftsman making similar quality goods down the street.

Brent tipped me off to the exploration of undersea cables in his recent post.

Old farts like me remember a time before there even was an internet. But as this map of the world's undersea cables points out, there is 1.5tbps (that's Terabytes per second) going through the world's undersea cables for Internet usage alone. The world has certainly got smaller in my life time.

I wrote earlier about Zen and the Art of Design and how we seem to be getting better at considering the user experience in design work. This is good because globalization means that we can no longer lead as a manufacturing country (due to the shipping container) or as a software construction shop (due to the internet). We need to compete with superior design, since the "labor" playing field was leveled a long, long time ago--and we don't have the bodies for it.

Design and the Art of Motorcycle Maintenance

For years I’ve advocated John Pirsig’s “Zen and the Art of Motorcycle Maintenance” to any engineer who will listen. Pirsig’s philosophical rant has a lot to say about quality and craftsmanship that provides deep thinking to the mechanic and the programmer alike. Most recently some design discussions came up that reminded me of Prisig’s book.

In Zen and the Art of Motorcycle Maintenance, Pirsig debates the philosophical differences between classical Western philosophy and Eastern thought (thus the “Zen”). He presents several examples to create hypothetical distinctions between Western and Eastern approaches to craftsmanship, design, and, of course, motorcycle maintenance.

In the conflict between Greek Classical philosophy and the Eastern philosophies Pirsig claims that, “Truth won and Good lost.” His argument says the Greeks put Western thought on a path in which our desire for truth blinds our ability to appreciate that which is truly good.

This video on design, Experience Is The Product is what made me remember Pirsig’s point. In Zen.., Pirsig points out the fundamental connection between a quality product, the end user and the product’s creator. He argues that an emotional tie exists between them that is deeply satisfying to all. And that this process is difficult if not impossible in the framework of classical reasoning (and indirectly, classical methods of engineering).

As the video points out there are current examples of good design that take the above experienced based approach. I think these efforts would please Pirsig.

More on Holistic Security (and non-functional requirements)

See Brent's comments to my post on designing security into products towards the bottom.

As Brent says, "..making the security properties explicit, you can make sure they carry all the way to code." That's what's often missing, some up-front thought and explicit goals, which can have quite an influence on the code.

Like performance criteria, this is one of the mostly non-functional areas that deserve architectural consideration. The caveat is, like performance and other non-functional targets, you can rarely figure it all out ahead of time. But rather need to do some thinking early, develop and test theories, rinse and repeat. That's the only way you're going to get a clean implementation that meets the goals. It's also the only way you're going to get a deep enough understanding of the cost/benefit and opportunity costs involved to tease out the appropriate architectural decisions. For example, tying your product to some Public Key Infrastructure might sound great until you try it and figure out how complex it can become..

Then there's a quantitative issue of how much thinking you're going to do up front. BUFD methods would say all of it. Agility minded methods would say much less. I think there's a middle ground to be found for nearly all projects, lest you get painted into a corner.

Point is, this is an area you must set goals and be sure to keep them in the process throughout development.

A Holistic Approach to Security in Product Development

Our company's entire product line is becoming increasingly IP based. This means that our systems are more interconnected with the customer’s IT environment than they were before. Customers are well aware of the security risks to their networks and systems. So we have to respond aggressively to ensure that our products fit well within a variety of secure environments.

I'm working on a Product IT Security Program designed to respond to a number of challenges.

First, no product and no network is 100% secure. This is why modern security practices not only focus on the security features of a given device or network, but also on the change management and processes that will ensure continued security as new threats emerge.

Second, the environments into which our IP products are being deployed are an increasingly complex ecosystem of third party products, a variety of network topologies and many software integrations. These factors create difficulties for security that require we do our part to ensure that our devices are secure, and that the fit within the customer’s security expectations.

So my goal is to proactively define security objectives for our products. This allows us to design and build products that meet these objectives--leaving nothing to chance. We seek to assure customers and our sales partners that our products are secure and work with them to accommodate their needs in special environments and circumstances that require additional high security.

My approach has been to survey the IT security landscape and collect the best practices from a number of well-defined standards. I'm confident that these security techniques will fit within most all customer compliance requirements, from HIPAA to Sarbanes-Oxley, to various international, government and Department of Defense requirements.

There exists a number of standards that provide detailed security vulnerabilities to be mitigated against. These include vulnerability lists from groups such as Open Web Application Security Project (OWASP), MITRE Corporation, SANS (SysAdin, Audit, Network, Security) Institute, as well as the vulnerabilities built into network and security scanners such as Tenable Network Security’s Nessus scanner.

This vulnerability knowledge will allow us to execute the development practices to design security into our products.

• Begin with a clear process for handling source code and software artifacts within the development organization
  
• Start with reviews early in product development to assure that the fundamental design of the system will not violate security best practices
  
• Do code reviews of software during development with explicit tests of security vulnerabilities
  
• Analyze threat models within the context of a decomposition of the system’s architecture.
  
• Run security checks as part of our quality criteria during product testing to ensure that no known vulnerabilities are slipping through the cracks.
  

Of course, shipping the most secure systems do no good if new vulnerabilities are found after deployment. To mitigate against this ensure that the user can keep their systems up-to-date for new security threats. And factor in the need for the customer to include anti virus software on deployed systems. This allows the customer to utilize their own best practices for maintaining a secure environment into which the products seamlessly fit.

In advance of security accreditation that the customer may require of their deployed IT systems, I'm focused on the Payment Card Industry - Data Security Standard (PCI-DSS) as a framework to target. While our products rarely directly manage customer financial or credit card information, these products are widely deployed in Point of Sale environments and throughout financial institutions. The PCI-DSS frameworks allows us to be one step ahead in the accreditation process so our products will integrate well within this most secure environment. From PCI-DSS, accreditation in other environments should not be a problem for our customers.

The point is to "put a stake in the ground" with a holistic approach to product security that will provide a starting point to discussions with customers with high security requirements, and will provide proactive answers to assuage customer concerns.