Effective security governance

Published: 2017-05-01
Last Updated: 2017-05-01 18:22:39 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
2 comment(s)

According to the Carnegie Mellon University (CMU) Software engineering Institute (SEI), there are 11 characteristics for effective security governance:

  • Enterprise-wide issue: Security is managed as an enterprise issue, horizontally, vertically, and cross-functionally throughout the organization in every level.
  • Leaders are accountable: Executive leaders understand their accountability and responsibility with respect to security for the organization, for their stakeholders, for the communities they serve, and for the protection of critical national infrastructures as well as economic and national security interests
  • Viewed as business requirement: Security is viewed as a business requirement that directly aligns with strategic goals, enterprise objectives, risk management plans, compliance requirements, and top-level policies.
  • Risk-based: Determining how much security is enough is based upon the risk exposure an organization is willing to tolerate, including compliance and liability risks, operational disruptions, reputational harm, and financial loss.
  • Roles, Responsibilities, and Segregation of Duties Defined: Security roles and responsibilities for business leaders are denoted by separate lines of reporting and a clear delineation of responsibilities that consider segregation of duties, accountability, and risk management.
  • Addressed and Enforced in Policy: Security requirements are implemented through well-articulated policies and procedures which are supported by people, procedural, and technical solutions including controls, training, monitoring, and enforcement.
  • Adequate Resources Committed: Key personnel, including IT and security staff, have adequate resources, authority, and time to build and maintain core competencies in enterprise security
  • Staff Aware and Trained: All personnel who have access to digital assets understand their daily responsibilities to protect and preserve the organization’s security posture
  • A Development Life Cycle Requirement: Security requirements are addressed throughout all system/software development life cycle phases including acquisition, initiation, requirements engineering, system architecture and design, development, testing, operations, maintenance, and retirement.
  • Planned, Managed, Measurable, and Measured: Security is considered an integral part of normal strategic, capital, and operational planning cycles.
  • Reviewed and Audited: The board risk and audit committees conduct regular reviews and audits of the Enterprise Security Program (ESP).

From these criteria we can conclude:

  • How can you ensure non-IT people will not click into a spear-phishing URL or plug in an unknown USB just to check its content? Information security training and awareness are a MUST for every employee.
  • Budgets are smaller everytime and risks are bigger and broader. Information security solutions are composed of people, process, governance and technology, not just technology. You need to find innovate ways to keep a cost-effective relation when implementing the controls needed in your risk treatment plan.
  • Risk maps need to be kept updated. If you use information security risk maps appliable to your industry and won't build your own maps, you will eventually miss a critical risk and it will cost you big time and resources to control it.
  • Information Security must be a requirement for every project in the organization, not just the IT ones. This is vital for digital transformation efforts.
  • Information Security is management system that has many actors inside an organization. There is a main team that leads all the efforts and need to have the adequate amount of resources to make sure the treatment plan is up to date.
  • Information security reports to management need to be done in business writing. If the information security efforts can reflect how they are improving business performance, they are going to the right direction.


[1] https://resources.sei.cmu.edu/asset_files/TechnicalNote/2007_004_001_14837.pdf

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
e-mail: msantand at isc dot sans dot org

2 comment(s)


expected responses to my commentary yesterday
While this is excellent guidance, it is only the start. Call it GRC 101 (Governance, Risk Management and Compliance).

Enterprise must have pervasive and invasive GRC throughout.

Leaders are not just accountable: they must lead. Everyone is accountable is some fashion. This should be explored within a matix of Accountability, Responsibility, Consulting, Informed (ARCI); this sometimes called a RACI Chart or Responsibility Assignment Matrix. Training and Awareness is a small part of this. The ARCI enumerates and visualizes roles and responsibilities from the CEO down to the front-line staff. This must be correlated to the Work Breakdown Structures (WBS) or Org chart.

Budget issues in InfoSec require anyone with security responsibilities (Accountability and Responsibility in the above referenced matrix) to have planning skills – budget, resource, etc. That also involves what I call “Translating InfoSec to Management” (© Brett Osborne 2014-2017). InfoSec must speak on Management’s level or surely fail. Technically, every mitigation and POA&M must have Cost-Benefit factored (that’s what the ‘M’ in POA&M represents).

Risk management is GRC’s middle name. This also will likely involve the Translations I noted above. Risk needs to be assessed and calculated, preferably Quantitative (or as close to quantitative as possible). This can be simplified by taking your Compliance efforts from documentation to data. There are a few applications in this space, such as RSA Archer and several used in the US Government. If you can’t afford the applications, I have built equivalent functionality in SharePoint. I’m sure anyone with SharePoint or database experience can probably do a sufficient job. Back to RM – if your Compliance is digital/quantitative/automated, then you can provide quantitative information about Risk. These InfoSec results must fall within Management’s appetite. (Note that your Management may have one or more other definitions of Risk depending on context).

As you reinforce the above points (and more), all corners of the organization will start bringing InfoSec in to their activities. Get the Program Managers to include your risk analysis in their risk catalog (or just get them to use a risk catalog….). Security becomes integrated in the SDLC. Security is included at the start of all projects and through those projects.

This all becomes mutually beneficial. InfoSec has many commonalities with Quality Management. The organization improves quality (naturally) by improving the organization’s maturity (see Capability Maturity Model Integration (CMMI) or ISO9000 series). How does InfoSec play in this? InfoSec promotes quality by promoting good policies and procedures, by promoting repeatability. CMMI, for example, starts at low end with reacting to problems, to defining processes, to quantitatively managing, and, at top, process (continuous) improvement.

InfoSec in entirety is represented by all roles in your ARCI chart. There are several common way to organize senior security management. The key role is the CISO (sometimes called Information Security Manager). The CISO sets the InfoSec culture for the organization. The CISO sometimes reports to CIO or similar role; sometimes to the CEO or to a Chief of Internal Audit or Risk Manager depending on the organization. Regardless of chain of command, the CISO must have the ear of the Board (or similar leadership group). One recommendation is to leverage a role called Risk Executive (in FISMA) as a “GRC Committee” (like a Board of Directors can sometimes have a “Risk Committee”), comprised of CIO, CEO, etc. which is chaired by the CISO. That way the CISO is naturally in front of management from every part of the organization. As a rhetorical example, the CISO would direct the CIO to prepare Contingency plans (for IT), and would direct the CEO (at least designate as Accountable) to prepare Continuity Plans.

Diary Archives