Fulfilling the risk management and regulatory compliance obligations with consistency in today’s vastly disparate and complex IT enterprise environments has challenged CIOs 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 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 susceptible to the outbreak, or 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.
Flexible and Granular RBAC with audit trail facilities: An accessible platform that enables the Central entity and diverse groups of IT administrators throughout the enterprise to collaborate is a most effective solution. It is important that such platforms include granular role-based access levels while also providing accountability and central oversight mechanisms. Such solutions make politically motivated compromises to an ideal Enterprise Security model more acceptable, and essentially can assist in building the case for increasing SOC staff responsibilities. When set up properly, even in a model where the SOC entity has no endpoint remediation authority, an Analyst can effectively communicate remediation prescriptions for detected vulnerabilities or incidents out to the staff that are responsible for such functions. Furthermore, when an audit trail is included in the equation, demonstrative data becomes available for trending how effective and efficient (or not) various IT entities are in their remediation activities.
The platform must also address the entire security management lifecycle vs. solving a single, focused security issue. How effective is a SIEM implementation or Vulnerability Management Platform if operators cannot use them to 1) proactively affect security configuration parameters down to endpoints, or 2) respond in real-time to legitimate threats detected? These systems are terrific at telling you how many hundreds of severe security vulnerabilities may exist in your enterprise, but they offer little to no operational capability when it comes to actually affecting the endpoint security posture. What you’re left with is a mountain of report data enumerating a litany of potential vulnerabilities in your enterprise with suggested courses of action to mitigate them – but that’s where they stop. It’s then left entirely up to the security operations team to figure out how to get everything fixed with yet another toolset or air gap processes. Furthermore, the implementation of such tools removes all plausible deniability regarding enterprise security awareness – there is now likely to be a legal or compliance obligation to fix all the issues these applications have uncovered.
Automating human repeatable workflow processes is what information systems do best. Automation should be leveraged where possible to provide better orchestrated, efficient, and accurately performed configuration management policy dissemination, as well as reactive remediation responses. The air gap processes so prevalently found in the security management programs today, are the unnecessary choke points that counteract so much of the good intent that went into developing a well-planned security program in the first place. Any time the flowchart must rely on people to communicate and physically act, it simply takes more time, and will be less consistently performed. Security Management platforms must introduce more automation for these functions in the next generation.
In the “real world” example provided earlier, our Security Analyst’s hands were politically tied, and he could not perform remediation activities (even if he had the technology to do it). Recall that in this common example, the SOC Analysts were just that-Analysts only. They had no operational authority of any consequence as it related to actual preventative endpoint security posture maintenance or remediation. Their job was to drink from the fire hose of aggregate security event data and to separate authentic incidents from false positive events. Their job was to formulate remediation prescriptions for affected devices, to hunt down the appropriate system administrators for such devices, and to disseminate the developed remediation prescriptions. Finally, their job was to follow up with these individuals until it could be verified that the remediation activity had been successfully applied.
Imagine if an enterprise security management platform were in place that could facilitate and control the delegation of specific roles and the collaboration across these groups, as well as authorize and track activities among individuals and groups of systems with intuitive ease and simplicity.
Conclusion
In a perfect world (and typically as drawn up on paper) centralization of the enterprise security operations function is straightforward to implement – and it generally is, until you factor in the human elements. In reality, transitioning to the centralization model will always face certain operational challenges from potentially impacted interests for a variety of reasons. These interests respond to centralized security management models with a predictable reluctance to support the implementation due to a perceived threat of reduced control over their environments, or simply a natural resistance to change.
The Centralized Enterprise Security model should not be characterized as a false panacea by any means because of these challenges. Instead, it should be understood that the model is a politically ambitious one to achieve, and why. For these initiatives to have the best chance at realizing the efficiency and/ or effectiveness gains they promised to deliver in concept – the solutions adapted at their core must be in a position to accommodate. The security management platform at the root of their design must promote organizational cooperation, for only by leveraging platforms with such capabilities can politically motivated barriers be easily overcome. Empowering and accommodating not only the central security entity, but also any other IT organization with significant interests at stake, promotes inclusion, cooperation, and enables the centralized security model to be a success.
When IT organizations are empowered, encouraged, and held accountable to positively affect the enterprise security posture with an intuitive and powerful management platform that coordinates and distributes individual responsibilities effectively, and under control – half the battle is won. By adapting a management platform that offers a pragmatic method to assess distributed endpoint systems without disruption by providing an accurate security posture awareness; proactively protect endpoint systems in a coordinated, organized fashion through scalable group policy deployments; detect authentic incidents in real time without flooding operations with oceans of false positives; and respond immediately, effectively, and in scalable (automated when appropriate) fashion down to the affected endpoints. A Unified Endpoint Security Management platform, as described, is a catalyst for overcoming the political obstacles that inherently exist, and provides a clear path for a vastly improved enterprise security posture and the always sought after improvements to the return on investment.
Jeff Ahlerich is Vice President and Co-Founder of Looking Glass Systems.
