I responded to the presentations about “Rugged DevOps” with the question, “Can I join if I think that ‘Rugged DevOps’ is (or should be) a tautology?” I wasn’t trying to be a smart aleck. I do want to join. I greatly admire the work the Rugged DevOps folks have done so far. I think it’s valuable and important. Just as with “DevSecOps”, though, I’m concerned with the notion of “Rugged” as an add-on to DevOps. It implies that non-rugged DevOps is acceptable. It also risks giving the impression that ruggedness = security. Should systems that are highly secure but low in scalability or availability be any more acceptable than the other way around? To me, security is (or should be) integral to both Dev and Ops.
From the Ops perspective:
- If your site is slow or unavailable, customers are unhappy
- If your users’ passwords get stolen because of a misconfigured firewall, customers are unhappy
From the Dev perspective:
- If your site is buggy or slow because of bad code, customers are unhappy
- If your users’ credit cards get stolen because of insecure code, customers are unhappy
DevOps is about delivering quality software service to customers. It needs to account for all aspects of service delivery. On the Internet, security is simply another aspect.
Security as an integral concern DOES NOT mean DevOps teams have no dedicated security professionals. Nor does it necessarily mean there is no CISO. I’ve previously posted about the agile fallacy of obsessive generalization, and the reality of teams of T-Shaped People. Integrating security into DevOps means that development and ops specialists need to care about and appreciate security and security specialists. And vice versa.
User-Centered IT brings together all the specialties needed to deliver digital services: Dev + Ops + QA + Marketing + Design…+ Security. User-Centered IT thinks in terms of customers’ complete service interactions. Along with functionality and usability, customers care about performance, scalability, availability, and security. In other words, customers expect software services to be rugged. Ruggedness therefore must be an inherent concern of the entire delivery team, including design and marketing.
Why does design need to care about about security in particular?
On a remedial level, if you don’t ask users to enter a new password twice, they risk immediately “forgetting” it and having to retrieve it. In addition to generating customer dissatisfaction right at the front of service adoption lifecycle, this design “solution” encourages weaker, easier-to-type passwords, thus subtly compromising security. On a more advanced level, if someone like Chris Hoff isn’t sure how to de-authorize access from a lost iPad to his Twitter account, then how can we expect ordinary users even to know they need to do it?
Why does marketing need to care about security?
Security breaches generate customer dissatisfaction, cost the service provider time and money, and degrade brand trust.Several InfoSec professionals have told me that they don’t think “the business” really cares about breaches. Someone, however, has decided it’s worth spending money on a lawyer to sue LinkedIn and force them to care. The comment has been made that, after a major breach, “the company’s stock price doesn’t go down”. I suspect that, rather than reflecting customer’s attitudes about security, it reflects providers’ lack of understanding that they really are in the service business, and they’ve just delivered extremely poor service.
User-Centered IT aligns digital service practices with the full range of customer’s service expectations. Concern for ruggedness, including security, is built in. To the extent that DevOps addresses part of the User-Centered IT equation, it must in my opinion treat security as inseparable from other aspects of ruggedness. It must also treat ruggedness as inseparable from other aspects of service.