Centralizing Enterprise Security Operations and Management

Jeff Ahlerich of Looking Glass Systems looks at transcending the politics

Fulfilling the risk management and regulatory compliance obligations with consistency in today's vastly disparate and complex IT enterprise environments has challenged CIO's to rethink the approach to operating their security posture. Internally consolidating and centralizing Information Security management functions has become a popular model for better combating what has become a relentless onslaught of vulnerabilities, and those who seek to exploit them for profit. Whether it's an "Army of One" position in a two hundred seat company, or a team of a dozen Security Analysts staffing a 24x7x365 SOC facility protecting a 200,000 seat, globally networked organization; The constant barrage of cyber threats today demands a well orchestrated, diligently maintained, and extremely nimble posture. It is no longer sensible to simply farm out security responsibilities to distributed system administrators and "hope for the best". Disparately applied processes, unilateral prioritizations, and daunting system administrator workloads, lead to an uneven (and oftentimes negligent) execution of security measures across the enterprise.

For example, you may have a Systems Administrator (Paul) in the Seattle Sales and Marketing branch office. Paul allocates ample time to monitor for and address security issues that develop within his environment; he is diligent in his approach and is not too overwhelmed with his regular duties to dedicate time to security related matters. Then you have the more typical Systems Administrator (David) in Denver's Operation Center. David, by no fault of his own is understaffed, overwhelmed, and simply doesn't dedicate much time to maintaining his network segments security posture. In each case, neither Paul nor David is specialized in the field of Information Security. This is a major problem in and of itself of course (like a general practice physician treating a broken leg; he can maybe get the job done but it's not what he's been trained to do). The bigger trouble with approaching Enterprise Security Management in this fashion is the inevitable neglect and inconsistencies that are bound to occur as a result.

This issue is among the principal reasons why consolidating security operations within the enterprise makes a great deal of sense. However, while on paper the ROI, TCO, and operational efficiency gains calculus make centralization a fairly simple and straightforward justification process, in practice many organizations that have adopted and implemented the model fail to realize the grand vision or yield the improvements that the IT security centralization models promised to deliver in the first place.

Diverse Stakeholders and Predictable Opposition

There is obviously no single reason for a centralized security initiative to fail on its promises. We can point to the multitude of usual suspects as potential culprits; poor integration of disparate security systems, overly complex or poorly designed and implemented infrastructure, deficiently trained or outright unqualified Analysts, or simply too much poorly correlated event data with not enough automation and/or manpower to sort through it. All of these issues are valid and absolutely do contribute to failed or ineffectual implementations of the model. However, let's turn the spotlight onto a root cause that is oftentimes overlooked and under analyzed — Enterprise IT politics and concept opposition.

Centralizing Information Security operations in the large, complex and diverse Enterprise can be a contentious process. Just when you think you've got your all the stakeholders on board - a mutiny breaks out in the field or a peer IT management division finds that key elements of the initiative conflicts with their own agenda. The process of security centralization is itself predisposed for conflict, and the first step towards a successful transition is to understand that the reasons for this are largely human nature.

If an entity is going to go though the effort and cost of transitioning to a centralized posture to better mitigate the overall risk exposure of its enterprise, then the staff hired to perform these operational duties must be afforded a certain level of trust and authority to be truly effective. This is not to say that the specialized security personnel need to employ heavy-handed tactics to get the job done effectively, nor do they need unrestricted keys to the kingdom. What they do need, however, are adequate levels of authority with the appropriate oversight measures in place. An effective centralized Security Program is able and empowered to respond to actionable intelligence nimbly and without undue restrictions, or "red tape" when a legitimate threat to information presents itself, and is kept from overstepping its bounds via programmatically implemented limitations and transparency - checks and balances, if you will.

What we oftentimes find in practice, however, is that while a great deal of time, money, and effort is invested to establish trust relationships for Security personnel (clearances, background checks, etc) individuals assigned the duty of safeguarding the enterprise from cyber threats are typically not leveraged to their full extent due to entrenched opposition and the turf battles that ensue once a centralized program enters its serious planning and implementation stages. In other words, the ideal centralization models drawn up on paper are oftentimes degraded and adopted in a manner that will appease the entrenched interests of peer IT groups who notionally believe that the program represents a threat to their ability to manage and/or control their own environments.

Whether it's a NOC manager who won't allow a security entity to effect changes on network infrastructure without imposing significant red tape processes, a conflict with the Desktop Support group over an endpoint remediation prescription that requires "unauthorized" system configuration modifications or patches, or the influence of a remote Field Site Systems Administrator who is loathe to provide any outside access to "his systems". In each case, the resistance of the peer IT group to fully embrace the centralized security concept can lead to the program implementation being undermined before it gets off the ground. Security Operations organizations face these kinds of entrenched interests every which way they turn when it comes to matters of implementing proactive protection mechanisms or responsive remediation operations. Oftentimes the result can be the centralized SOC entity being reduced to an incident detection and reporting center only. And because of prevalent political opposition involved with providing SOC entities access to the distributed networks/systems, a myriad of more passive (read: politically viable) enterprise security monitoring solutions have cropped up operating at the network layer - Network Intrusion Detection Systems (NIDS) being the best example.

The analysis of a real world example where this type of political compromise exacerbated an otherwise manageable security incident illustrates why this issue is so critically in need of address. A SOC Analyst, through his Security Event Management dashboard, detected the potential outbreak of a virus happening within a sizable enterprise branch office department. The events he was observing were primarily generated from a signature based Network Intrusion Detection sensor deployed within this remote segment of the network. For politically driven reasons, the SOC personnel in this instance had no direct access (even read-only) to the potentially affected endpoint systems in this environment, or to the network switch infrastructure that could be utilized to isolate affected endpoint systems on a quarantined VLAN.

In other words, this SOC entity had no way to independently susceptible to the outbreak, or

1) validate that the events detected were in fact authentic (i.e. NOT false positives, which NIDS are notorious for producing);

2) determine which additional endpoints in this segment were also potentially

3) do anything to efficiently mitigate / remediate the problem. The SOC's hands were tied, and their official protocol filled with air gap processes, which delayed action.

The end result of this incident was that the virus failed to be contained, and it spread rapidly outside of the branch office throughout the entire enterprise within a couple of days. This SOC organization did not have the authority or technical capability to act independently on the actionable intelligence at hand, and could do nothing but watch the virus spread like wildfire on their consoles and launch emails and phone calls to the distributed IT resources in the field. Finally, when all was said and done it took about a month to clean up the damage and restore the enterprise to normal functions. Thousands of man-hours were spent on the effort to remediate affected systems, and productivity of the core business mission was severely impacted.

Imagine a Fire Chief watching over a dry forest as a lightening storm breaks out overhead. He's got his fire truck but no hose or water. His team of Firefighters is in position to take aggressive and necessary measures, but their hands are completely tied by political protocols. Instead, the only recourse is to start radioing to Policemen and Paramedics dispersed throughout the forest, ask them to suspend their present duties, and come rapidly to the scene of the lightening strikes to become temporary Firefighters themselves; asking them to execute tasks that they were not trained to perform, do not have any desire to perform, do not have the right tools to perform, and cannot perform without their regular, mission critical duties taking a back seat.

The principle idea behind centralized Security Operations is to put in position a group of able specialists to respond nimbly upon aggregated and correlated event data that is spawned by an accurate, well-tuned detection infrastructure. While a good deal of technology exists to allow for such centralization programs to be as effective as advertised, more times than not it's the people and politics that become the bottlenecks. Whether they are openly and vocally opposed to the concept, or more passive aggressive by nature - distributed, localized IT Administrators, and even NOC and Desktop Support organizations commonly go into protection mode when faced with the prospect of a centralized security initiative. A common feeling amongst these groups is that yielding to centralized security will either create more chaos for them, or that they'll get into trouble for doing something wrong as it relates to their legacy security measures. It's a combination of a classic resistance to change from the status quo, and a protectionist mindset. Warranted or not, it's 100% human nature.

Power to the People&and the Software!

It's not all bad news for centralization advocates who find their plans mired by difficult political circumstances. Solving the opposition problem is best accomplished when security management platforms at the center of the architecture design are

a) easy to adapt, integrate and deploy,

b) offer flexible and granular role-based access controls with audit trail facilities,

c) address not one or a small handful of specific security issues, but a more comprehensive security management lifecycle, and

d) is capable of automating human repeatable workflow processes. Let's examine each requirement in more detail.

Easy to adopt, integrate and deploy: The reality today is that the SOC Analyst talent pool is smaller than the market demand, and the turn over for such positions is quite high. As soon as the really talented individuals become proficient in their Security Analyst role, they are typically promoted out of operations and into the more lucrative and sought after security engineering or architect based positions. Due to the combination of budgetary constraints and talent pool limitations, it is not uncommon for SOC personnel, in even the most security conscious organizations, to be recruited straight from help desk / desktop support positions, or brought on from outside with little security operations experience. Because turn over is high, pay scales are low, and frankly, the skill set many SOC managers must settle for can be sub par, security management platforms need to be intuitively designed to the extent that an Operator / Analyst new to the role can sit down in front of his console and pick it up in hours / days with very little training vs. the weeks / months and intense training it typically takes to become adequately proficient with most of today's available solutions.

1 2 Page 1
Page 1 of 2
22 cybersecurity myths organizations need to stop believing in 2022