Platt Perspective on Business and Technology

Monoculture and ecological diversity as a paradigm for modeling cyber risk – 3

Posted in business and convergent technologies, strategy and planning by Timothy Platt on October 3, 2011

A few months ago I posted the first two installments to a short series on this blog in which I challenged a basic and essentially automatic assumption that IT systems managers make – the role and value of systems uniformity wherever a system component can be replicated and standardized in doing so (see Monoculture and Ecological Diversity as a Paradigm for Modeling Cyber Risk – 1 and its follow-up Part 2.)

I noted pressures towards consistency and uniformity as a means to ease systems and resource maintenance and as a route to increased cost savings. I also noted how uniformity can create and spread risks by leaving larger subsystems and even entire IT systems vulnerable to single threats. And this series is, in substantial part about finding and pursuing an effective middle ground.

I said at the end of part 2 that I would be adding more to this series and here is my third installment. My immediate impetus for this was a recent conversation about standardization and virtualization, and I will be picking up on that as an organizing thread in what I write here. And my goal is to explore an important dynamic as it applies to this set of issues: standardization choke points.

• As noted in Part 2, any systems or systems resources that are built on internet connectivity or access models, or that are designed and built to run through standard online interfaces (e.g. web browsers) automatically start out requiring a great deal of standardization, and both within your specific IT systems and generically with regard to the outside world as well. Among other things, that means a would-be intruder is not going to have to do much if anything in the way of social engineering of your organization and systems to have a fairly good idea of what you do and how you do it operationally, and both as to how your core systems are organized and how they connect together and are accessed – at least to the level of basic protocols, scripting languages and security options.
• This leaves passwords and other more individual authentication tools and a number of other specific personalizations details that are deployed and maintained to (hopefully) limit access to those with legitimate access rights. And password systems are notoriously limited in security effectiveness, and even presumably reliable measures such as authentication certificates cannot be fully trusted (see Part 2.)

The basic trend in IT systems resources has been in the direction of increasing standardization, and in consistent, basic forms that fit together. And as cloud computing and virtualization have developed, this trend has only gained momentum. I have been posting on an ongoing basis on our rapidly emerging ubiquitous computing and communications capabilities and on how this is bringing all of us together as an increasingly connected and interconnected single community. There is a great deal of positive good to be said for that. I still, however, find myself thinking at times about the lessons learnable from agricultural monoculture, and especially where I delve into the issues that we are also facing of increased vulnerabilities to both cyber-crime and cyber-conflict.

I like to write postings and series in which I lay out basic issues and present an analytically developed approach for dealing with them. Here, the best I can do is to seek to provoke some thinking about a developing, emerging set of challenges. And for this posting my focus is on awareness, and as noted above, awareness of a single core point – standardization and consistency choke points.

• As you develop and set out to optimize your information management systems, where are you following standard and easily predictable basic patterns?
• Where do you have opportunity to customize and set apart core resources and capabilities?
• Where do you have opportunity and capability for adding in the security of systems variation, and where in that can you do this transparently and behind the scenes to your end users, and where would you require explicit end user participation and compliance?

I touched on the challenges of training and user practices before. Select, well considered security-enhancing technology implementation variations set up to wall off critical resource subsystems should be set up so as to be transparent where possible to routine, legitimate users. Here, and for the purpose of this discussion, consistency choke points are places in your system’s information storage, processing, transfer, presentation or usage where you only really have one possible approach to use. By way of example:

• If you use an Oracle database in your back-end systems you have to use their basic coding and setup protocols.
• If you use a standardized third party cloud service provider such as Amazon, you have to conform to their processes and their coding standards and solutions.
• And for virtualization, if you want this to work you are probably going to have a great deal of consistency within your systems and across many, most or all users for their virtualization builds and for how they access your virtualized resources. So if someone finds a way to compromise one user they are well on their way towards compromising any user in your system.

Know where you have essential and even required standardizations and the bottlenecks of access predictability that they create. Know where these are present but avoidable, as is the case way too often in how password protection systems are implemented by end users in practice, and where they are simply part of the basic framework you have to install. And for each and of both general types look for specific ways to add in security.

As a final thought here I note that few organizations add anything into the security layer in their http protocol stack and even when that is an option that has been available since the earliest days of http.

I will be coming back to this general topic area again in future postings. Meanwhile, you can find this and related postings in Business Strategy and Operations and its continuation page. I also recommend reviewing related postings in Ubiquitous Computing and Communications – everywhere all the time.

Tagged with:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: