Balance Confidentiality, Integrity and Availability in a Security Program

6 minute read

For many years now, IT security has been defined as a function that protects the confidentiality, integrity and availability of enterprise data. It is often 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:

  • Implementing 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

  • 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.

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.

This is an excerpt from an article that appears on FOCUS Magazine online.

You Might Also Like
Join our Newsletter

Stay up to date with the latest and greatest from our monthly newsletter

About the Author
Popular Today