IT Focus Area: security
May 6, 2015
Security within IT: A Risky Proposition?
Far too many enterprises are building a house of cards by insisting that information technology (IT) alone should manage IT-related risks. As competitive pressures consistently push the organization to “do more with less”, the disproportional investment in people and processes that are expected to support the new technologies being introduced or changed often increases IT-related risks present in the organization. To truly improve this situation, changes to the organizational structure itself may be needed to ensure that resources are available that can identify, articulate and manage IT-related risks throughout the organization.
How Does the Organizational Structure Affect IT Risk Management?
For many years now, IT security has been defined as a function that protects the confidentiality, integrity and availability of enterprise data, and often is displayed in the form of a triangle to reinforce the idea that while you can skew one of the three elements, the other two still remain. In organizations with a non-existent or minimally implemented security function (i.e. accountability for the security function assigned as a secondary role to an operationally-focused IT leader) there is often a disproportionate focus on availability versus confidentiality and integrity. In today’s threat environment, information security simply cannot be a hobby for team members within IT – responsibility and accountability for managing IT risks needs to be assigned as someone’s full-time job. Conversely, in organizations that place too much focus on integrity and confidentiality, the IT Security team is often seen as an obstruction that furthers the perceived gap between IT and the business operations they support. A well-designed security program strikes the proper balance between confidentiality, integrity and availability by developing and refining the organization’s ability to manage risk.
Envisioning the Target State
The need for enterprise risk management principles to be adopted within IT is not a new concept and is well documented by frameworks provided by both the National Institute of Standards and Technology (NIST) and the International Standards Organization (ISO). Unfortunately, for teams that are already stretched beyond capacity, finding the time to develop and execute a transformation strategy that extends well beyond IT may seem an impossible task, even with the help of a framework.
If we are going to deliver a meaningful response to the board member that asks how the security breach du jour will be prevented, we need to get to the point where risk management is tightly integrated into every aspect of IT through provision of the following:
Published standards for each of the services provided within the IT function
Integration with key change management processes so that exceptions to standards can be identified and the associated risks managed
Continuous auditing of the entire IT environment to identify exceptions to standards and to provide an ongoing mechanism to uncover new areas of risk
Skilled resources across multiple disciplines that can accurately assess and articulate the risk of non-compliance with established standards to other key stakeholders throughout the enterprise
Known risks tracked in a central repository available to all functional leaders throughout the enterprise
Known risks reviewed by appropriate levels of IT and business leadership on a periodic basis for remediation, acceptance or temporary exception
Actionable metrics that can be used to communicate the trend of both positive and negative changes to leading risk indicators
While many organizations have security programs that provide these functions, fewer companies have taken the step to formalize the alignment between their operational practices and desired risk posture. When thinking about your own organization, do you have documented standards to communicate your organization's security posture?
During the course of an implementation project, the security function would likely be asked to assist with questions like:
Does this vendor need to use multi-factor authentication when connecting to the network?
Should IT own a user account that is used for testing an application or should the business requester of that account be assigned as its owner?
Do all systems need to have file system auditing enabled for success and failure or only a subset?
For many organizations, the answers to these questions are understood by those within the Information Security function, but are not formalized in a way that can be communicated and consumed by other teams.
Managing Standards Compliance: The Risk Registry and the Risk Acceptance Process
If a server is not patched or an employee ID is not associated with a test account, what impact does that truly have on the organization? To accurately answer such questions, resources within the organization are needed that can accurately assess and articulate the risk of a non-standard implementation from both a technical and business vantage point. Once the risk is understood, it needs to be tracked in a repository – which can be as simple as a spreadsheet or as elaborate as a governance, risk and compliance platform. Risks in the repository then need to be reviewed by key stakeholders, which ideally would consist of a steering committee comprised of leaders from each of the key areas (both technical and non-technical) within the organization. The steering committee would then make a recommendation to the executive leadership team as to whether the risk should be addressed through remediation efforts, temporarily accepted awaiting implementation of existing planned initiatives or permanently accepted as a risk. Once the processes and procedures associated with assessing, tracking and accepting risks are defined, the organizational design would be modified to formalize the existence of the risk assessment team and risk management steering committee.
Ongoing Risk Management Processes: Process Integration is Key
For some organizations, risk assessment is an annual process that is performed solely to meet a regulatory requirement. While this may meet the bright line requirements established through regulation, the spirit of these requirements is really to ensure that organizations begin the journey toward managing risk throughout their daily activities. With a proper apparatus in place to manage known risks, the organization can more easily evaluate how well the current IT environment conforms to their defined set of standards. Ideally this is accomplished through both wide-scale audits of the environment as well as through integration of assessments within key change management processes.
Such process integration can take various forms, including:
implementation of a quality control step to ensure that a newly created Active Directory group has an owner assigned that will authorize changes to group membership;
executing a vulnerability scan prior to releasing a server or application into production;
implementing a toolset that will report and alert upon high-risk changes in firewall rules;
daily reconciliation of user accounts across disparate systems to identify missed terminations; or
daily reconciliation of asset inventories against endpoint client lists to ensure coverage.
Careful consideration needs to be given as to whether it makes sense for the risk assessment and audit functions to be part of the IT organization. While there are arguments to be made both for and against moving risk management out of IT, the answer to where such a function belongs in your organization is often a function of organizational culture and maturity. If the culture of your organization tends toward poor collaboration and limited cooperation between functions, this might preclude the use of steering committees and other governance models needed to facilitate cross-functional interactions once IT risk management moves beyond the CIO.
Metrics: An Ideal Vehicle to Communicate the Need for Action
Far too many organizations spend a great deal of time preparing reports that require the reader to have an in-depth understanding of the content in order to analyze its meaning. Worse yet, some executive dashboards or scorecards lead the reader to draw improper conclusions about the data being presented. Presenting a senior leader or board member with a dashboard showing the number of production servers with Critical, High, Medium and Low vulnerabilities each month does not truly convey the risk present in the organization. Instead, showing that it takes an average of 95 days for a resource constrained business unit's development team to test and approve patches for a critical application better articulates the risk and makes it clear what action might need to be taken.
To this end, a good set of actionable, risk-based metrics can help justify required expenditure for people, process and technology, but the organizational design also needs to account for the resources required to define and report on these metrics over time. Some metrics are quite easy to produce, whereas others (such as service level compliance and mean time calculations) can take a substantial level of effort to define and manage, which has a downstream impact on resource allocation within the organization as well.
Are You Organized for Success?
As with any strategic initiative, the ability to arrive at this level of maturity takes vision, careful planning, executive leadership support and coordination over an extended period of time. It also requires resources to be positioned throughout the organization that can make risk management part of the corporate culture, and that often requires changes to the organizational design itself.