on_track

Keeping IT Security Decision-Making on Track

Spice IT

by |

It’s easy to see why IT security suffers from an inferiority complex. On the one hand, if there are security incidents, IT security is incompetent or ineffective. On the other, if there aren’t security incidents, we often get complacent, and IT security seems less necessary. In either case it becomes all too easy to de-prioritize security efforts, or to think of security simply as a cost of doing business and work to minimize that cost.

Just as importantly, without guidance, it’s hard to know what to do with security. If an organization has a limited amount of money—is it better off spending it on Data Loss Prevention or Mobile Device Management? Clearly they’re both areas of risk, but how should we decide what to do first? And these aren’t the only security needs competing for our attention!

Back in 1997, Eric S. Raymond presented an influential talk (later a book) entitled The Cathedral and the Bazaar in which he described two models for the development of free software. The Cathedral model, in which development on a project is performed by a relatively small group of individuals, and the Bazaar model, in which anyone is free to contribute ideas or features. Each, he observed, has its strengths and weaknesses.

A similar observation can be made for the allocation of IT security decision-making responsibility. In some organizations, security authority is centralized within a dedicated security group. In others, various IT units (typically, server, network, desktop, software development, etc.) are responsible for security as it pertains to their specific spheres of influence. These are both viable models but, as might be expected, they each come with some baggage. Regardless of which model an organization follows (or if it borrows aspects from each), the key to long-term success is periodic sanity-checking.

The Architectural Approach to IT Security

Some organizations orient their security efforts around a centrally-maintained framework. Common examples include NIST Special Publiction 800-53, and the ISO/IEC 27000-series. The basic goal with these efforts is to ensure that each aspect of the organization’s security gets the attention it deserves. Security technologies and workflows are organized so that they harmonize with the control objectives specified in the framework, and this helps the organization eliminate redundant efforts, and ensure that various functional teams are working towards the same overall goals.

Comprehensive architectures are also prized by organizations where compliance is a major factor, because the frameworks behind them provide ready-made audit points. A security architecture helps to motivate an organization, because the goals are clear. It facilitates the organized delegation of duties, and the creation of documentation needed in order to put a security program onto a path of continuous improvement.

One danger with the architectural approach is that those leading the effort may tend to operate in a vacuum. Simply having a vision for security, or even detailed documentation, does not offer much by way of practical protection. If the central planning effort isn’t supplemented by collaboration with subject matter experts, the organization runs the risk of overlooking important areas of risk, especially when it comes to details of implementation. An architectural security framework is a great help for setting big-picture direction, but security is often a game of details, and most frameworks offer little specific guidance about the technologies or tools an organization might rely on to accomplish its security objectives. A great deal has been written about the difference between compliance and security, and the same observation can be made about comprehensive security architectures: merely addressing all of the areas specified by a security framework does not guarantee that they have been handled in the most effective way possible for the organization in question.

The Many-Hands Approach to IT Security

At the other end of the spectrum, security is part of nearly everything that goes on in IT, and some organizations distribute security responsibility amongst the various functional units. Thus, the network infrastructure team is responsible for locking down switches and routers, providing network segmentation, VPN connectivity, and other protection related to the compartmentalization, filtering, and delivery of network traffic. The desktop team is responsible for endpoint anti-malware protection, laptop hard drive encryption, and so on.

This approach can work, especially in smaller shops, if the various groups take their security duties seriously, have solid engineering fundamentals, and communicate well. It is this last point that most frequently undermines distributed security efforts. Without any unifying guidance, teams can find themselves at cross-purposes, or put the organization at risk because they have assumed that some threat vector was being handled by another group. It’s not rare, for example, for security concerns to crop up just as a new application is going live: the developers have trouble explaining to the server team what components need to be installed, and the server team has trouble explaining to the firewall manager what ports need to be open between the DMZ and back-end systems, and the net result can be chaotic.

Nevertheless, this approach does have one distinct advantage: decisions about the security of each platform are in the hands of those who know the most about them.

Figuring Out What To Do

Many organizations incorporate elements of each of these approaches, even though they tend to lean in one direction or the other. Nevertheless, either of these approaches runs the risk of getting off course, and neither provides consistently good answers to the question “what should we do next?” The architectural approach can lack agility, especially if the pursuit of the framework takes on a life of its own, instead of being a tool for the management of risk. The many-hands approach basically punts on the question of an overarching vision for security. In either case, competing priorities can arise, without any obvious way to break a deadlock.

Security assessment is the tool that provides organizations with concrete next-step guidance. Basically, an assessment serves two ends:

  • Ensuring that when an organization invests in a security measure (whether in terms of dollars or effort), they are addressing a practical real-life risk, and not just a theoretical source of worry
  • Ensuring that those risks are prioritized, so that the organization can address the most critical matters first before moving on to others

By giving an organization a current snapshot of where its greatest risks lie, and by providing best-practices solutions to those problems, periodic security assessments help keep security programs focused on their mission and aligned with the current threat environment. For more information about what forms a security assessment can take, what benefits it can offer, and how best to organize an assessment for your organization, we invite you to download a series of whitepapers on the topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>