How to Structure the Information Security Function

Deciding how to organize an information security team and determining its resources are two threshold questions all organizations should address. This piece provides guidance from our Faculty on how to do both and explores the nuances that influence those decisions.

Structuring the Information Security Function

To right-size and structure your information security organization, you should consider:

• Determining what your worst information security risks are so the team can be sufficiently sized and resourced to deal with them. That determination should fully reflect input from executives, i.e., their worries concerning the confidentiality, integrity and availably (CIA) of data (the traditional definition of information security), and it will affect how the information security team is internally organized.
• The scope of information security. This is also an executive-level decision, and hence what the information security budget really covers.
• Deciding where the information security team should reside organizationally. What is the reporting structure of the infosec team? Again, that is an executive-level decision.

Determining Information Security Risks

Here are some key methods organizations can use to help determine information security risks:

Use a risk register to capture and manage information security risks.

Base the risk register on executive input. The process for populating the risk register should start with documenting executives’ key worries concerning the CIA of data. Note the emphasis on “worries” vs. “risks.” You are not seeking to find out what “risks” concern them; you just want to know their “worries.” This is analogous to a doctor asking a patient where it hurts, how bad the pain is and whether the pain is persistent or intermittent. The doctor does not expect the patient to determine what the disease is – just the nature and location of the pain.

Ensure risks can be traced back to leadership priorities. Once the “worries” are captured, the security team can convert them into information security risks. But the key is to have traceability between “risks” and “worries,” so when you talk about risks to the executives, you can relate them back to what they told you they were worried about.

Position the team and its resources to address the worst risks. Once all of the risks are documented and prioritized by severity, you should be in a position to ensure the security team’s organization and resources are suited to addressing the worst risks (lesser risks typically are just monitored and only get addressed if they get worse). This is a key point: If the information security team focuses on the worst risks, its organizational structure should reflect that focus. Organizational structure (or resource allocations) can change as the risks change over time.

Determine the Scope of Information Security

The following is a list of information security responsibilities. Important to note, not every security team must perform all of these, however, decision should be made – by team leadership and company executives – about which should be done, and which may be ignored or handled by other groups. Once it is determined which responsibilities will be handled by the information security team, you are able to design an organizational structure and determine resourcing needs, considering the risk register’s worst risks:

• Information security policy and standards development and management, including aligning policy and standards with the most significant enterprise risks, dealing with any requests to deviate from the policy and standards (waiver/exception request process), and providing authoritative interpretations of the policy and standards. A difficult part of creating policy and standards is defining the classification of information, and the types of controls or protections to be applied to each category. Ideally, each type of information has an information owner, who prepares a classification guide covering that information.
• Information security architecture, which covers the architecture of the network, resources and applications to ensure they all fit into a cohesive system that honors the requirements of the information security policy and standards for segmentation and configuration. This also includes the use of cloud services and cloud access security brokers (CASBs).
• Training and awareness, including tailoring training to job-specific requirements (e.g., ensuring software engineers are trained on the OWASP Top 10), testing of employees and contractors to verify they received and understood the training, and for the information security staff itself, defining professional development opportunities and helping ensure they are applied.
• Information security risk management, including proper assignment and execution of risk ownership and risk decision-making (i.e., every risk needs to have both an owner and a decision-maker).
• Identity and access management (IAM). This topic has many aspects to it, some of which may be done by infosec and others by business units and/or IT. Where you draw the lines influences resources and how complex this function is. Consider including IAM in the context of everything it covers for access to all resources, including the network and applications – i.e., IAM system definition, administration, management, role definition and implementation, user account provisioning and deprovisioning, user account recertification, user account reconciliation, and especially all aspects of highly privileged (admin) account management and use. The assumption is the role definition must be set by, or approved by, the business unit that owns the business process that uses that role.
• Software development life cycle (SDLC), which is sometimes called security engineering.
• Business continuity and disaster recovery (BC/DR). This is the “A” part of the CIA of data. It includes data backup and the establishment (by business process owners) of recovery point objectives and recovery time objectives for key business processes. Ideally, one should use ISO 22301 or similar methodology to do all of this.
• Data loss prevention (DLP), in the context of endpoints, servers, applications, etc.
• Anti-malware protection, in the context of endpoints, servers, applications, etc.
• Intrusion detection/prevention (IDS/IPS), for the network, servers and applications.
• Cryptographic key management, including encryption keys, asymmetric key pairs, etc. Complex environments usually have a key management officer who keeps a key inventory (NOT copies of the keys), including who controls each key, what the key rotation schedules are and who is responsible for rotating them.
• SIEM management. This includes integrating all “sensors” (IDS/IPS, logs, etc.) into the SIEM to have a full picture of network and application behavior over time, including efficient detection of anomalies or unauthorized attempts to exfiltrate data.
• Security infrastructure management to ensure it is properly integrated and functions smoothly. Infrastructure includes the SIEM, DLP, IDS/IPS, IAM system, etc., as well as security-focused network and application devices (e.g., hardware firewalls, web-application firewalls, etc.). This function is often called security operations.
• Patching for endpoints, servers, applications, etc. Actual patching is done, of course, by IT, but the information security team should define the process for determining the criticality of different patches and then ensure that process is executed, including having risk decision-makers sign off where patching is to be delayed for business reasons.
• Metrics, i.e., development and management of metrics relevant to the information security program and reporting those metrics to executives. This may include creating and managing appropriate dashboards.
• Determining program maturity. For example, the team could use the Capability Maturity Model System Security Engineering (CMM/SSE) approach described in ISO 21827 or something similar.
• Vulnerability scanning and penetration testing, including integration of results into the SIEM. This is usually part of security operations.
• Threat intelligence, including receiving threat intelligence data and integrating it into the SIEM; this can also include threat hunting and honeypots.
• Working with IT on ITIL processes, including change management and service management, to ensure information security aspects are covered.
• Working with audit, to ensure auditors understand enough about information security technology and risk management to be able to sensibly audit IT activities and to resolve any information security-related questions they may have.
• Privacy, including working with the chief privacy officer to ensure infosec policies and requirements are aligned with privacy obligations.
• Vendor and contractor management. This is especially relevant if vendors/contractors have access to sensitive information, networks or other resources.
• Physical security, including protecting physical access to assets, networks or information.

Whether infosec is responsible for some or all these functional areas depends on many factors, including organizational culture, geographic dispersal, centralized vs. decentralized operations, and so on.

InfoSec Tool Considerations

The above list covers functional areas, but there are, of course, tools within each area that may or may not be funded as security spending (vs. just routine IT spending). Generally, if a tool’s principal purpose is security, it should be considered as security spending. If the tool’s purpose covers a variety of needs, from security to business management (such as many IAM tools), then it should be considered IT spending, not security spending.

Security Operations

Security operations can be part of infosec, but it can also be considered part of the IT infrastructure or network group. It's not uncommon for IT infrastructure and network groups not wanting anyone besides themselves touching the devices that manage their network (including firewalls, routers, load balancers, etc.). The potential for errors and miscommunication (and outages) can be great.

If security operations is part of IT, whether it is insourced or outsourced, is usually a function of how much IT is insourced or outsourced. If network management is generally outsourced to a managed services provider (MSP), then security operations usually is too – to the same MSP or to a separate managed security services provider (MSSP).

Generally, smaller companies use a lot of MSP or MSSP resources, while larger companies do more in-house and only call on external resources for specialized functions and roles. Companies that use a lot of cloud resources may employ a CASB to help manage access to cloud resources – again, an outsourced function.

Information Security Team Structure

Although one size does not fit all, the infosec team's typically follow a structure similar to the following:

• Security GRC: This group handles policies, standards, training and awareness, risk management and similar topics. This is the principal group that interfaces with internal audit and the chief privacy officer. It has a compliance role, but is not the cop on the beat. That is the job of internal audit or a compliance officer separate from the infosec team.
• Infrastructure security: This group handles the security architecture function for the infrastructure as well as security operations activities, which usually include governance of operational security but not actually running the security infrastructure (firewalls, IDS, IPS, SIEM, etc.). That is the responsibility of the network and infrastructure group under the IT (i.e., network operations). This group also handles Active Directory (AD) security/group policy, plus setting security configuration for file shares (e.g., SharePoint) – i.e., anything that is part of the Windows infrastructure. But it would not decide who belongs in what groups. That should be determined by business process owners and information or document owners. And, implementing those settings in AD or file shares would be done by IT.
• Application security: This group handles security of applications, including IAM for those applications, as well as database security. It also handles SDLC process security governance (the actual SDLC process would be run by the process owner, which is the software development team, often under IT). But it would not make segregation-of-duties (SoD) determinations. The rules for SoD should be set by the relevant business process owners, such as finance, marketing, etc., who are also the application role owners. This would also be done in consultation with internal audit, the legal department and HR.
• Business support: This group focuses on outreach to business units and helping them understand and meet information security requirements and standards (or to document deviations, which can then be addressed on a case basis).
• Privacy: This group could potentially reside in the law department as well as within the information security function as it relates to the infosec responsibilities described in Figure 1 below.

Figure 1 provides a responsible-accountable-consulted-informed (RACI) chart for those four primary security groups, plus a privacy group. Wherever a security group is accountable for something, it means the group is accountable for the infosec oversight and governance of that something, not necessarily operational execution. For example, the infrastructure security team is “accountable” for server patching, so it oversees the security aspects of the patching process (e.g., setting rules for patch priority, ensuring those rules are covered in the ITIL change control/change management process run by IT and ensuring they are followed by the IT server management team), but infrastructure security does not actually do the patching.

Figure 1: Security Group RACI Chart

Information Security Team Resources

Let’s now focus on organizational size, resources and funding. Team size varies according to industry vertical, the scope of the infosec program and the risk appetite of executive leadership. Examples of security spending/funding as a percentage of IT spending/funding include:

Financial services/insurance might be about 6-10 percent. The range is given due to the uncertainties around scope and risk appetite. However, companies that do a higher proportion of business online may have a higher range. For example, a large financial services organization might spend around 12 percent because of this.

Retail could range from 4-6 percent, depending on online vs. brick and mortar. Online tends to be higher.

Manufacturing ranges typically sit between 2 percent and 4 percent.

Healthcare is very complex. Security spending depends on whether the company provides point-of-care” (e.g., a hospital or clinic), focuses on research and development or delivers material (pharmaceuticals, medical devices, etc.). Point-of-care enterprises have historically underfunded security spending, and have (over the past decade) increased spending to compensate, so their percentages tend to be in flux. At present, their spending usually falls in the 4-6 percent window. Healthcare companies that deliver material tend to have a security spending profile similar to manufacturing companies (2-4 percent). Those focused on research and development vary depending on their specific niche and whether they are a startup or a more established company (e.g., Biogen, Abbvie, Allergan, etc.). These companies spend generally from 2-6 percent.

Technology support or online services vary depending on clientele. If they mostly support financial services companies, their numbers could sit in that higher range (6-10 percent), but if they serve manufacturing companies, their numbers may be lower (2-4 percent).

Important to note, companies that recently experienced a serious breach or security incident have much higher security spending than the percentages cited above. Which begs the question: Do you have any breaches or security incidents which may be useful in making the case?

InfoSec Staffing Considerations

Previously, Gartner published a general, non-industry-specific metric that applies best to very large companies. And in this report, the recommendation was one information security full-time employee (FTE) per 1,000 employees.

While perhaps serviceable for large or enterprise-level organizations, this metric is less helpful for smaller companies because there are no economies of scale. Also, one element that adds to the cost of information security is the need to have distributed security resources available, which is a situation you may confront. Generally, you need resources wherever your assets (devices, endpoints, servers, network infrastructure) exist. If you operate nationwide, this can mean additional resources are needed proximate to your business locations.

Relationship of Information Security to IT

The information security team is often placed (organizationally) under the CIO with its “home” in the IT department, even though its responsibilities are broader than just cybersecurity (e.g., they cover protection of sensitive information in paper form too). Other companies place the team under the chief technology officer (CTO), chief financial officer (CFO) or chief risk officer (CRO). The key point is not the organizational location, but whether the CISO’s boss agrees information security is important and has the organizational clout to provide strong support. If the answer to both questions is yes, security is well-positioned to succeed.

Many business processes in IT intersect with what the information security team does. The clearest example is change management. Any changes to the IT environment should go through change control or change management, and infosec should have representation within the group that approves such changes. Additionally, IT often runs the IAM system, which is another area of intersection.

infosec and the IT should consider creating a division of responsibilities (DoR) document as to eliminate or lessen ambiguity or uncertainty where the respective responsibilities lie. To do this, IT should list all their business processes and functions, and work with infosec to determine what role(s) each team plays in those processes. Doing this may result in some surprises, but that is an important outcome. In fact, Figure 1 reflects a DoR, although the full DoR should have additional descriptive material explaining each row.

Setting Information Security Up for Success

To help ensure an information security team is organized and resourced for success, consider:

• Matching the "worries" of executive leadership to infosec risks. This is not easy to do, but the benefits more than compensate for the effort spent. Being able to relate what you are doing to the worries of the executives positions you favorably to overcome opposition.
• Being flexible. Settling exactly what the infosec program should cover is also not easy. Your company likely has a history of certain groups doing certain things. Trying to change that history (to more logically align security roles, for example) may be difficult. If that is the case within your organization, consider simply accepting the existing division of responsibilities (i.e., who does what) unless that places accountability with no authority. For example, if infosec is being held accountable for periodically re-certifying user accounts when that should be done by the business process or information owners, that is a problem that should be corrected. But in other more benign situations, if there are entrenched interests, consider accepting the status quo and save your ammunition for other battles.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.