Rejuvenating the Infrastructure

The lack of agility of the infrastructure, especially the data center and systems programming/ administration is so obvious that the nascent DevOps movement has arisen to combat this perceived deficiency.  Much of that movement’s visible contribution has focused on automation and tools (e.g., Chef, Puppet, cfengine, Nagios) rather than on frameworks or processes.  Not surprising, given the talent for coding of many of the DevOps advocates.

There are other obstacles:

The Data Center values stability of the environment, and resists change; change is seen as a risk, not as any form of added value.  In general, perhaps especially for larger IT shops, other than changes due to bug fixes or security patches, the data center is isolated from positive aspects of application and environmental changes.  New metrics could provide a more flexible approach along the lines of increased Business Value (BV).  Some places, especially those along ITIL lines, may use a metric for risk as part of Change Control, but I have not heard of a corresponding one for enhanced BV.  That BV metric could be a 1 to 5 scale, or a set of numeric guidelines.

Much of the effort of the infrastructure is about process, with solutions well defined.  The challenges are more along the lines of:

–       Sheer scope of tasks, as the whole enterprise may be involved, with associated risk of that dimension.

–       Interdependencies

–       Complexity

–       Volume of work (especially with sharp peaks)

–       Lack of teams

For volume, automation and tools can help; one should also investigate frameworks like  Kanban, limiting the work in progress at any moment.

The lack of teams in infrastructure remains a source of concern for me.  Teams, behaving as teams, not just silos of individuals with common product-oriented expertise.  For example, a group of system administrators each with distinct separate sets of servers to manage, with no or little collaboration between members of the group, is not a team. The situation not only deprives the company and the participants of the benefits of a team approach, but reinforces the sense of isolation and endless repetition of upgrades and patches.

In my prior blog post on Skill-Centric Teams, a key point is that teams can be created across functional silos, basing them on the shared skills and challenges.  While there are distinct differences between a UNIX system administrator, the Windows counterpart, and their mainframe brethren, but there is so much in common, including, but not limited to:

–       Issues of change management

–       Communication with developers

–       Application development (AD) support methodologies or frameworks

Application development infrastructure support frameworks deserve a separate post.


Database Vulnerabilities and NoSQL

Information Security professionals state that perimeter security alone is not sufficient; just having network firewalls is not enough to secure your environment.  Both devices and people can circumvent perimeter security.  Devices:  how would you discover if a wireless router was placed on your network?  People:  do you ever use consultants, temps or contract workers?

There are many ways DB’s are vulnerable, with new ones occurring with new features and new releases.  How current is your DB on security patches? Did any of your DB installs create demo or sample databases?  While those don’t have sensitive data, they do represent security exposures.

At a recent chapter meeting of a web application security group, OWASP, some vendors were present.  Chatting with one, Application Security ( ), I was glad to learn about a tool that deals with database vulnerabilities, DbProtect.  I’m sure it has competitors with similar functions, but to me, not an InfoSec specialist, it was very impressive, covering most of the common distributed DB’s.

While the mainstream relational DB’s have tools to help address vulnerabilities, the newer NoSQL data solutions do not, yet are subject to many of the same types of vulnerabilities.  Use of MongoDB, CouchDB, Riak, Redis, Hadoop, MapReduce, etc. continues to rapidly grow.  And these are being used in more business-critical applications, or with sensitive data.

Even if used for non-critical applications and non-sensitive data, they still can present a risk, for some may have accounts with privileged access to the critical DB’s, the relational ones; or they may provide elevated access to the operating system.

If you’re using a NoSQL DB, check with your vendor for security assurance tools, or at least some recommendations for those.  Make inquiries of existing DB security vendors;  even if they don’t currently have a suitable tool, they might respond to market demands and create one.

Even if insufficient when compared to commercial products, in the absence of a suitable tool, consider creating a tool, script or checklist to seek common vulnerabilities. Change passwords to any DB default accounts, and use strong passwords (not ones that might appear in a dictionary.) Check for vendor patches frequently.  Keep posted about security exploits against that specific DB.  Something like a Google Alert using a string based upon the DB name (e.g. Sybase) and “security exploit” could bea s good starting point.  Keep learning about DB security.