Friday, March 23, 2012
Rugged Software – Telling Your Security Story
First, read John Wilander’s post about the Rugged Summit
In my opinion, a Rugged software organization builds applications, services, infrastructure, business processes, and people that expect to be attacked. The organization gathers intelligence and understands the types of threats and adversaries targeting them and intentionally includes strategic solutions within every layer to resist, detect, respond, and recover from those attacks.
I also think that a Rugged software organization should share important aspects of this philosophy in the context of their products and services. One possible form is the “Security Story”. The Security Story is a public facing narrative showcasing how and why the organization chooses to be resilient. This could include statements describing the types of issues that the software and infrastructure is designed to protect against, the controls and countermeasures in place, the process by which the organization validates these controls are effective, and the results.
A great non-software example is the Apple Supplier Responsibility page (originally pointed out by one of the other Rugged Summit attendees). Apple clearly defines its values and expectations, how it ensures its suppliers adhere to those expectations, and their results. Customers can view this information and decide whether they want to do business with Apple based on whether their values match up with the company’s expectations and fulfillment with said expectations.
There are many similar examples in the software industry. One of those examples is CrashPlan’s “/security” page, Security FAQ, and in depth description of its file encryption options. CrashPlan shows very plainly the types of concerns they considered in the development of their data backup service as well as the controls put in place to address them. Additionally, they provide specific details about the implementation. All of these help a customer decide whether CrashPlan’s data security vision matches or exceed their own, and whether the vendor can back up their claims with some evidence (in this case, the evidence is details about the implementation, but some kind of verification might be even more convincing).
As we become more and more dependent upon “smart meters” to deliver reliable energy to our homes and businesses, USB or Bluetooth enabled health care devices within our bodies to sustain life, or mobile devices to organize and run our lives, we must have the ability to seek out and select the product, solution, or company that will protect us the best. Whether you’re a business owner buying software, a CTO contracting for outsourced software development, or an individual looking for a safe backup solution, we all deserve to have Rugged software!
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
Interesting post. I think that one of the problems with public narratives regarding security is providing accurate information that's actually meaningful to the users of the service.
The crashplan links you provided are actually a good example of this. One of the key differentiators that they mention for the crashplan+ service on those pages is the use of 448-bit keys instead of 128-bit.
From a cryptographic perspective that difference is meaningless, 128-bit keys are (assuming the implementation is fine) not feasibly breakable with current technology, so there's no security advantage to using 448-bit keys (AFAIK anyway).
One supposition that could be made there is that there was a marketing drive for a "bigger number" for the + plan, but it illustrates the tension between marketing a service and provide accurate information about things like security...
Hi Rory,
I agree. Many of the security pages say rather silly things to the effect of "We use 128-bit encryption, so everything is fine". In the near future, I hope that companies in similar sectors would all produce these security narratives and then a consumer, buyer, or outsourcer could compare them all together. The vendor with more meaningful details would then attract more potential customers. Those customers would also need to consider price, maintainability, reputation, and a whole host of other issues. But, at least security would be considered during the buying decision. It could even become a differentiator for a vendor!
Post a Comment