I recently had some discussions with business leaders
(C-level executives) on ITSM vendor solutions at some recent regional and
national Information Security events. One of the topics that came up
specifically was their perception of effectiveness on their business and
how those vendors responded to those needs. First of all, I want to make it
clear this is not meant to highlight deficiencies in solutions, make
product enhancements or to endorse any specific vendor. The intended audience
for this discussion is directed specifically at business decision makers and
those who support 500-10000 endpoints.
Now, I realize that Spiceworks started as a grassroots
effort by evangelists like myself over a decade ago. I watched as vendors then entered the fold of the community, and the community
expanded to include IT Service Providers, jack-of-all-trades IT pros and the
yearly frequent fresh meat that enters the workforce each year. However, as I
look back 5 and even 10 years, what has changed? Why did it change and for
whom? What differentiates Spiceworks from the vendors in this competitive space
and does it meet business needs to the Spiceworks slogan, "It's everything
IT"?
Is Spiceworks “Everything IT” or just, "everything IT,
minus the business"?
At these events, I meet a ton of
folks from the "account executive - aka vendor sales", the
"people executive - aka recruiter", the "marketing executive aka
advertising" and others. The discussion however became quite interesting
as I turned the specific focus at the event to "executives with a
financial and fiduciary responsibility to the organization". An example
would be a CIO/CTO, some of these were Director level and above (VP/SVP/EVP)
and albeit a few also included some that had CEO/President. What I mean by
fiduciary responsibility here in this context is, while you might be a CEO - are
you publicly traded? Are you required to file financials? Are there regulatory
matters at the heart of your organization, made mandatory that you must adhere
to?
If not, Spiceworks isn't listening to the right
audience. In fact, IT rarely reciprocates its needs back to the business in a
means that executives can measure and understand, especially the large end of what is SMB today. IT talks happen at all levels
and this conversation was no different. Initially, the conversation wasn't even
around this topic but rather than aligning IS/IT needs to the business, then
evolved into risk, threats and eventually how organizations are addressing
them. In fact, this topic should be right at the heart of every IT professional
but many times, I find that somewhere down the line of business divestures, M&A's,
reorganizations and so on that the people, processes and technologies needed
and required to align IT to the business - went out the window long before the
executives realized something was missing to begin with. After speaking on this
topic in person, I’ve decided to bring back to the table one of the key points
that came up when we began to discuss the basics of all information security
programs - risk and the organizational capabilities to address it. This key
point was specifically the CSC's or Critical Security Controls of the
Cybersecurity Framework and respective changes published in 2014 - a result of
US Executive Order 13636 (Sec 7) that mandated the Director of NIST to
collaborate with industry leaders to establish a voluntary Cybersecurity framework.
The resulting framework established these CSC's and was also published by NIST
in 2015. Much of this framework can be loosely defined below from Chapter 2 of
SP 800-53.
- Identify-
Develop the organizational understanding to manage Cybersecurity risk to
systems, assets, data, and capabilities.
- Protect
– Develop and implement the appropriate safeguards to ensure delivery of
critical infrastructure services.
- Detect
- Develop and implement the appropriate activities to identify the
occurrence of a Cybersecurity event.
- Respond
– Develop and implement the appropriate activities to take action
regarding a detected Cybersecurity event.
- Recover
– Develop and implement the appropriate activities to maintain plans for
resilience and to restore any capabilities or services that were impacted
due to a Cybersecurity event.
Now at this point, I
speculate many of you are starting to wonder, how does this tie into ITSM? How
does any of this tie into IT (for the system/network/middleware admins, service
desk staff, endpoint teams and the various others that might end up as IT)?
Excellent question, let's get right to it then. The
first Common Security Control or CSC1 that any reasonable auditor or
Information Security professional (usually those in compliance or risk, but in
my case - management) must address is:
Inventory of
Authorized and Unauthorized Devices
"Actively
manage (inventory, track, and correct) all hardware devices on the network so
that only authorized devices are given access, and unauthorized and unmanaged
devices are found and prevented from gaining access."
This is the very first control that is defined and
required for any organization's Information Security initiatives. Any ITSM
solution should provide this as part of a common requirement. This control is
not just a technological control – meaning it is not specific to any vendors
technology and the driver of this control, should not be the users of it. For
some that do not have any clue as to what I am referring to, let's back up to
that model on people, processes and technologies that I discussed earlier and
add something for the Spiceworks reader to understand the control
"drivers" that make these and all controls measurable. These drivers
are:
- The
People driver focuses on the staffing levels, skills and knowledge needed
to perform the control
- The
Processes driver focuses on the need for well defined, documented and
broadly understood processes needed to perform the control
- The
Technology driver focuses on the amount of automation, systems and/or
tools needed to perform the control.
Now that we've defined how these drivers impact any
organization capabilities overall, let's expand on how these drivers are
weighted when we discuss "Information Security" at the executive
level. These are:
- Primary
drivers are ones that shape the control; the choices made in the design of
this driver will determine the requirements of the other drivers.
- Secondary
drivers are those key to the success of the control, although the
requirements for this driver are defined by the Primary driver.
- Supportive
drivers are those necessary for effectiveness of the control, however, the
requirements for this driver defined by the Primary and Secondary drivers.
Now we are getting
into the bread and butter of the business, the organizations needs and straight
into why I started this discussion. Spiceworks has added features over the
years. At first, it was more or less a service desk ticketing system, then came
on more features starting with some form of asset management all converging at
the time when the smartphone (or at least what many of you now think of one as)
came into existence, the community itself also came about not shortly
thereafter and the rest is what exists of this solution today. I'll be frankly
honest here. I've used many vendors and each has their strengths and weaknesses
and I do admit, I'm a little partial to this product because I helped shape it
from the beginning. However, I do not play favorites when it comes down to
getting business done and getting it done right. Integrity is everything and I
don't endorse anything that can't meet the needs that executive staff expect
from someone in my position of authority and responsibility.
Moving on, I've given
some of you a fast crash course in security governance and risk but let's just
briefly define what ITSM is (Spiceworks is an ITSM solution) and its goals
(taken from TechTarget) are:
" IT
Service Management is a general term that describes a strategic approach for
designing, delivering, managing and improving the way information technology
(IT) is used within an organization. The goal of every IT Service Management
framework is to ensure that the right processes, people and technology are in
place so that the organization can meet its business goals."
That's a great
definition and one that Spiceworks and its many community members will swear up
and down to. However, we've totally taken a step back from the business over
the years as we examine the drivers of this control in any business
organization. Remember where I just discussed those people, processes and
technologies along with their drivers?
Well, if we quickly list those and their drivers we can map
them below as:
People | Processes | Technology
Supportive | Secondary | Primary
If you don't see
anything already wrong with how Spiceworks is falling short here from the above
mapping, let me highlight it for you. Any ITSM solution (which should be
aligned to the business goals first and foremost), should have an asset
management system and one that meets the needs of any business size or type.
That IS the technology control and is PRIMARY driver in an organizations
selection of any ITSM and asset management solution. The processes are
secondary, these are highly important and are essentially defined (or limited)
by the solution itself. The last part is the Spiceworks user, that's correct -
you're a supportive driver (indeed as we have influenced the product solution
for years) but your voice simply does not have the weight desired nor required
to ensure any organization's business goals are met when it comes to ITSM and
if Spiceworks can meet business goals. As crazy as that may sound to you, it is
indeed true. View it from COBIT, ITIL or Six Sigma - it's all the same when we
go to an executive board to demonstrate the value in spending let's say 10m on
implementing a solution that aligns with the business.
A technology asset inventory database is the primary
technology needed for implementation of CSC1. The technology asset inventory
database should be capable of maintaining information about all of the
authorized assets that constitute the organization’s technology environment and
anything that is allowed to connect to those technology assets. An asset
inventory database is a foundational technology in the implementation of CSC1
and is an essential element of the detective control objectives. Today, I still
follow Spiceworks and recently were tasked with assisting a very large
organization implementing an Information Security program, in addition I was
also asked by several well-known editorial columns in putting together a group
of "community" based, well-established vendor solutions that any
organization could use in implementation and maturation of a cyber security
program. I found several vendors, some totally ready for organizations ready to
grow with their solution and others, where I identified deficiencies in several
areas. A key point for all of the vendors besides having a mature solution, was
scalability to the business. I asked Spiceworks specifically on this topic so
they should not be surprised with this article or its comments. I've always
been very pleased with their staff, I've rarely met anyone that wasn't
receptive to rational feedback where it made business sense. In this case, I
actually found the solution fell seriously short.
In summary, the topic hit this table hard, with some
executives stating, "We run Spiceworks for managing our IT". Then
came the discussions on, "How do you currently measure the risk of those
organizational assets within that one platform?"
The executives didn't have an answer, some even
called on me to ask what my organization was doing. We asked Spiceworks about
their asset management, change management and external reporting requirements -
a core requirement that any knowledgeable PMP will likely evaluate from the
PMBOK when selecting an ITSM and asset management vendor solution. At this
point, Spiceworks stated that its assets are stored in a SQLlite database, with
no API available, no means of reasonable expectation that those assets can be
autonomously extracted for any meaningful use outside of their platform. This
was the most insane response I possibly could have expected. Did Spiceworks
plan this properly on their roadmap? Was Spiceworks even considering that
larger organizations would eventually need to scale beyond a single small
instance to a clustered, high availability solution (perhaps one that is air
gapped - Francis and I discussed this long ago when the concept of the MyWay solution was proposed)?
At the end of the day, the last mile of delivery - as we
refer to this in Information Security is you, the reader
likely in a system or network admin role, maybe endpoint or service desk roles.
Chances are, smaller organizations began their foray into the world of
addressing cyber incidents with security as an afterthought - reporting to IT
instead of "working with IT, HR, Legal, Compliance, Risk and the executive
teams". Now that a decade has past, I've read many posts where some users
reported they had 10000 endpoints and yet I am entirely baffled that something
so simple and core to the solution was left as an afterthought. Do you and your
organization face challenges in managing and securing your assets, do you have
another asset management system that not only documents any changes made to any
asset but also shares those same details with Spiceworks?
I'm curious to know if some of you have
found a way to "work outside the Gordian knot" that Spiceworks holds your
organization within.
Council on CyberSecurity. (2014). Critical Controls. Retrieved May 9, 2015, from Council on CyberSecurity: http://www.counciloncybersecurity.org/critical-controls/
Council on Cybersecurity. (n.d.). About Us. Retrieved September 20, 2015, from Council on Cybersecurity: http://www.counciloncybersecurity.org/about-us/
Council on CyberSecurity. (n.d.). CSC-5. Retrieved Sep 15, 2015, from SANS.org: https://www.sans.org/media/critical-security-controls/CSC-5.pdf
Edwards, J. (2011). A Process View of Knowledge Management: It Ain't What you do, it's the way That you do it. Electronic Journal of Knowledge Management, 9(4), 297-306.
National Institute of Standards and Technology. (2015, July 8). Welcome. Retrieved October 15, 2015, from Cybersecurity Framework: http://www.nist.gov/cyberframework/
Obama, B. (2013, February 12). Executive Orders. Retrieved October 15, 2015, from the White House: https://www.whitehouse.gov/the-press- office/2013/02/12/executive-order-improving-critical-infrastructure- cybersecurity
