Information security professionals are often perceived as difficult to work with because they are viewed as the group that says “no.” A common sentiment from other professionals is that anyone who wants a project killed or delayed should talk to the information security team. However, this bad reputation is often a self-inflicted wound. Information security professionals do not always feel that they are being listened to because of the risk decisions made by the enterprise for which they work. This may cause information security professionals to overreact when they are given a chance to insert security into a process, which can lead to setting unrealistic spending objectives for both man-hours and financial costs. At times, these professionals feel that they only see results when they utilize coercive security measures (e.g., conducting a phishing awareness campaign that requires termination of employees who fail, or using an audit to circumvent the software development life cycle [SDLC] planning process by moving control implementation to immediate action rather than prioritizing it against other items). Armed with these security measures, security professionals proceed with the implementation of new technologies and new procedures at a breakneck pace. This often outpaces their teams’ capabilities to adjust to the change, which may cause inefficiencies, slow down business processes, and lead to immature control implementations.
These issues are the reason security professionals often have a bad reputation—they have forgotten that they are a support function. They are meant to support the organization’s goals, but they sometimes constrain them unnecessarily. When this happens, information security becomes known as the dreaded team of “no.” Risk is no longer categorized for assessment and remediation but rather used as a weapon to prevent action. These constraints do not support the enterprise and instead support a concept of complete avoidance. Worse still are the consequences when security professionals focus only on compliance, providing limited to no effective security solutions beyond what achieves a check mark. In their relentless pursuit of results, information security professionals may inadvertently be damaging relationships, which paradoxically deviates from what should ideally be their goal. The primary objective of information security professionals should be to cultivate a harmonious collaboration with IT, DevOps, developers, and all other stakeholders within their organization. Effective collaboration, rooted in clear and open communication, is not only crucial for the seamless operation of the organization but also essential to instill a sense of fulfillment and the satisfaction of a job well done.
Strengthening Relationships Through Collaboration
How can security leaders collaborate effectively with administrators, engineers, developers, and their associated management teams? Communication is a great place to start. Security operations center (SOC) analysts, security managers, and chief information security officers (CISOs) cannot just hand data to administrators, DevOps engineers, vice presidents of development, chief information officers (CIOs), IT directors, helpdesk personnel, IT operations teams, and marketing teams and expect miracles. It isimportant to take the time to analyze the data before collaboration. It is key to bring the enterprise’s other functional areas actionable information along with the raw data and to be humble enough to understand that they may be busy and need time to engage with the data. An easy way to begin this process is to initiate collaboration using the tools with which they are familiar. Instead of diving into the most challenging tasks, it is beneficial to begin with simpler tasks that can pave the way for successful outcomes. Consulting with the teams, individuals, managers, and executives that are impacted—and those that are about to be assigned tasks—and inquiring about what new work can be accommodated within their current commitments is valuable. It shows that information security respects the schedules to which others have committed and demonstrates a respect for all the planning that goes into the SDLC, roadmaps, and project schedules. Once the security team’s respect for the other functional areas is established, a pathway to trust, collaboration, and cooperation can be established. This helps frame the security team as a part of the leadership team, rather than as a disruptor of business processes. It also encourages a willingness to engage with the security team and schedule the security objectives.
Once the security team’s respect for the other functional areas is established, a pathway to trust, collaboration, and cooperation can be established.It is critical to ensure that proper communication and relationships are maintained with the human resources (HR), supply chain, and legal departments. Security as a support function relies on these areas of the organization and impacts their outcomes. For example, personnel security controls are rarely implemented directly by the information security team; instead, this task is done either by someone responsible for physical security or by HR. Ensuring that vendor third-party risk is assessed works only if the procurement or supply chain teams are involved. Breach disclosures and contractually obligating vendors to adhere to security requirements require the legal team. IT often implements both controls and incident response procedures for information security.
In these cases, IT operations, whether traditional or DevOps, are like the other areas, in that they have predefined communication lines. They have their own timelines for when they need to receive security-relevant information. Their policies impact both the information security policies and how controls are implemented.
To facilitate more effective communication, a management committee can be formed to direct both the security and IT departments. This committee should include executives or leaders from each group comprising the stakeholders with which security and IT professionals must collaborate. This way, the committee can help IT and security teams understand business objectives. Regular communication within the committee enables security and IT to collaborate on initiatives that contribute to achieving business objectives. Although some tasks may potentially delay noncritical IT and security work, it is important to keep in mind that as long as the enterprise is successful, there will always be another opportunity to work on side projects.
Barriers Vary by Enterprise
Large, medium, and small enterprises each face their own unique challenges. Effective communication, trust, and building on success are key factors in ensuring that dialogue exists between leadership and that security serves its function in promoting and assisting in achieving the organization’s objectives.
Large Enterprises
In large enterprises, there are typically multiple environments, a hybrid cloud, several development teams, an enterprise IT operations team, multiple DevOps teams, security operations at multiple tiers, network operations, and engineering teams. The true challenge in this scenario is the sheer volume of data that is produced by the different teams, tools, and processes. Multiple regulatory and compliance environments are aligned with business practices for specific teams. Often, no one wants to use the information security team’s tools to communicate; everyone wants to use the tools to which they are accustomed. Because of this, communication can suffer, which can lead to slow change and difficult adjustment. Although unified communications can prevent this, many times those efforts are ignored or used only as required. Information security professionals need to focus on results. To do so, it is often best to use the tools that the other functional areas use in their day-to-day work. This might mean utilizing JIRA for DevOps and ServiceNow for IT operations. Accepting the additional work may be required to enable security initiatives to continue.
Facing this scenario, it is easy to see why the US government chose to go the route of assigning an information systems security officer (ISSO)/information systems security manager (ISSM) for each system it assesses.1 ISSOs and ISSMs serve as the middlemen between the enterprise centralized security team and the systems developers, owners, and operators. They are dedicated security professionals with roles assigned to specific systems. This approach enables them to engage various functional areas and subject matter experts (SMEs) in specific use cases for specific systems. The ISSOs and ISSMs are able to navigate the complexities of viewing security holistically, which makes things much more tactical. However, this is resource-intensive, as sufficient staff are also required to examine security from a holistic view. Because of the increased staffing need for specific systems, the result is that only half the work toward overcoming the barriers between security and the organization is complete. This is true whether the titles used are ISSO/ISSM or more commercially neutral titles. CISOs need to ensure that the ISSO/ISSM or similar role understands security and not simply the tasks associated with security compliance. Otherwise, the enterprise falls out of risk-managed security and into a compliance push, which can have negative impacts both on security and how the security team is viewed by other functional areas.
Even in large enterprises, there are often no security professionals assigned to specific environments or systems. This means that staff typically complete tasks in aggregate across all environments but lack a detailed understanding of each individual environment. Information security professionals attempting to address specific concerns, vulnerabilities, weaknesses, and risk need to rely on the nonsecurity experts in the environment, because they are the ones who possess detailed knowledge of their respective areas. It is essential for both groups to rely on each other for a comprehensive and effective security outcome. Engagement in discussions on what a security objective, outcome, event, or vulnerability remediation means is important. The nonsecurity SMEs should be engaged with the results, rather than merely having the results handed to them. They all have schedules to which they must adhere, and security teams must engage in inserting their requirements within specific groups’ existing methods.
In large organizations, there are likely experts in each of the critical areas and technologies that security impacts, and there is every reason to make use of their expertise. If possible, informal meetings can be held to discuss the various systems that are being assessed. Teams should make time to review roadmaps from development and the project management office (PMO) to understand what is taking place now, in the near future, and later. This is helpful for determining when it may be appropriate to accept small amounts of risk so that security is not a burden.
Medium Enterprises
Medium enterprises are where many security professionals find themselves throughout their careers. These types of enterprises are likely where the most variation occurs concerning the environment and the security program due to the profit margin variations in funding security. For example, a US$50 million enterprise could have four times the security budget of a US$300 million enterprise. Revenues, profits, products, industries, and associated compliance requirements all have an outsized impact on medium enterprises and help determine the makeup of the information security program. Like all enterprises, the security program of a medium-sized enterprise consists of people, processes, tools, and technologies. Essentially, it encompasses everyone and everything that assists in running a security program or information security management system (ISMS). The ISMS includes those performing security functions, whether they are SMEs in other functional areas or part of the security team itself. The ISMS is also made up of specific auditable processes and procedures in which the security team and other functional areas take part. The various technologies that require operational support and adherence to proper configuration are also included. With widely differing outcomes and funding levels, it is difficult to say where exactly a medium enterprise’s barriers between IT, security, and business will be. Assumptions will need to be made to determine how they can be overcome.
If a medium enterprise has a dedicated security team, it should meet separately with the IT operations or DevOps team, developers, and departments such as HR, legal, and procurement to bring the groups together to represent the enterprise. A committee should be established to address all the stakeholders as a unified body. Attempting to move things forward solely through the committee is likely to cause delays and problems. This is why communication with each stakeholder is key. Everyone must be involved in the process so that the committee can run in an informed manner. Within the organizational structure, it is likely that functional areas will still be controlled and influenced greatly by specific stakeholders based on their own objectives and interests. If the security team addresses and supports these interests as part of a collaborative effort, the stakeholders will be more likely to offer their support for security objectives.
Consider an example in which a specific sort of audit will assist a sales team in selling either all of an organization’s products or a specific product. The stakeholder that controls sales may make this one of its largest priorities. It might be easy to consider immediately implementing the requirements and determining how quickly the audit could be performed. But in this example, security needs to involve several stakeholders. Sales teams do drive the ability of the enterprise to recognize revenue and should be able to provide requirements to the security team; however, moving blindly down an audit path leads to a checklist attitude toward compliance and poor implementation of security controls. Instead, the security team should engage with IT, DevOps, development, HR, and any other impacted group within the organization. Then the known gaps can be determined and a full gap analysis can be built prior to establishing a timeline to commence the audit. Once the level of effort is understood, the security team should work with the sales team and other stakeholders to assess what the enterprise’s priorities are and determine how to fit the audit into that reality. This will ideally prevent compliance merely for compliance purposes and ensure that a maturing security program grows from a sales initiative.
Small Enterprises
The advantage of small enterprises is that there are fewer teams with which to coordinate, and the information security team’s ability to intimately know the specifics of the environment is enhanced due to its simplicity. The challenge is that there are no large groups that can be relied on to assist in implementing the security program. A small organization’s security program may be maintained in a less mature manner than the programs of larger organizations. This is simply due to fewer resources. The funding levels for technology and staff are often limited by an organization’s size. Therefore, security professionals within small organizations should become comfortable with risk-based decisions and a moderate to high risk tolerance, because there may not be enough resources to implement best practices. In fact, attempting to achieve best practices may put small enterprises at risk, as there are often not enough staff to operate the required tools and services. Within a small enterprise, the environment may be limited to an office space, remote offices, and a single cloud environment.
Resource and capability challenges are inevitable, especially when there is no dedicated HR team and HR responsibilities are outsourced. In such scenarios, security may fall under IT as an additional assigned duty. If an organization is aiming to grow, separation of duties may be years away—or never a reality at all if the organization is, by its nature, designed to remain small. Based on standard guidelines, it might seem impossible to build a security program due to the inability to conform to requirements. This is misleading. A security program can be established, maintained, and matured; it will simply be different from a program that would exist at a larger entity.
To achieve an effective security program, it is necessary to maximize resources—not only security resources, but the resources of other areas that perform a security function. Some security functions may need to be shifted to the IT team or a managed security service provider (MSSP) or managed service provider (MSP). Keeping security objectives in mind is critical because novel ways to achieve goals may need to be created. For example, consider how vulnerability management can be effectively implemented in a resource-constrained environment.
While there are many enterprises that offer full vulnerability management tool suites, they are expensive and could be outside the budget of smaller organizations. For US enterprises, it is possible to at least perform external vulnerability scanning via the US Department of Homeland Security Cybersecurity and Infrastructure Security Agency.2 The next step is to look for an internal scanning capability. Many organizations may select an open-source tool such as OpenVAS to perform scanning, but that requires open ports and a system dedicated to performing as the scanner. An organization that uses an MSP or MSSP is likely providing an endpoint detection and response (EDR) solution for laptops. Security professionals, specifically those responsible for the security strategy of the organization, should consider asking the IT team, MSP, or MSSP for the vulnerability data found within the EDR solution. This covers the laptops and other endpoints being utilized by the organization. For cloud environments, native scanning tools are often inexpensive and very effective. CloudOps, DevOps, IT, and the MSP can perform scans when they are unlikely to cause issues with operations and provide the results to information security for analysis. Information security then needs to take the data and enrich it sufficiently to make actionable information that can be provided to CloudOps, DevOps, the IT team, or the MSP to remediate findings. It is critical for the information security team to provide that enrichment at this stage, as it represents the value added from security to the other functional areas regarding vulnerability management. Enrichment might be simply paring down the total vulnerabilities from the raw results or highlighting the most vulnerable systems or the vulnerabilities that are publicly available. It may mean that vulnerabilities with known exploits are the only information security details out for resolution. Ultimately, what matters is that information security teams are able to draw data from each source to provide value through analysis.
Conclusion
The barriers that exist between information security teams and other areas of an enterprise often stem from the information security teams themselves. They come from lacking engagement and communication with the other functional areas of the business, viewing security as an isolated goal, and believing that security is only performed by the information security team. Information security is performed as a cross-functional effort throughout the enterprise. The goal of the CISO and accompanying security professionals is to support the organization and its identified goals. Expressing items in light of risk is helpful, but the key is making sure that communication is flowing. The information security team must become a group that is seen as assisting the enterprise. When another functional area reaches out to the information security team, there should be no fear of hearing “no.” As with most areas within an enterprise, a sense of customer service will go a long way.
Endnotes
1 Department of Homeland Security, Information Systems Security Officer (ISSO) Guide, Version 10, USA, 16 September 2013, https://www.dhs.gov/sites/default/files/publications/Information%20System%20Security%20Officer%20%28ISSO%29%20Guide.pdf?external_link=true
2 Cybersecurity and Infrastructure Security Agency, “CISA Vulnerability Scanning,” USA, https://www.cisa.gov/resources-tools/resources/free-cybersecurity-services-and-tools
Kenneth Abbott, CISA, CISM, CRISC, CISSP, CLOUD+, CSSP, PCIP
Is senior director and chief information security officer (CISO) at Ubicquia. He has 23 years of experience..
