A formalized architecture diagrams how To handle the changing threat and regulatory environments.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Every so often, something beastly crosses the desk of an enterprise security manager. Be it a digital disaster or a new regulatory mandate, these nasties have transformed a CISO's professional existence into a series of policy and process adjustments, and reallocations of resources.
Any measure of standardization and repeatability becomes a welcome ally in warding off the effects of a shift in the threat or regulatory environment.
Jim Brockett takes heed, but isn't fazed, by the sophistication of new phishing schemes or insider threats. Shifts in the landscape mean the senior vice president and CIO of Washington Trust Bank, a $3.5 billion regional commercial bank in the Pacific Northwest, reaches for the virtual blueprints of his security architecture. These steps are the foundation of his enterprise's security program, the pillars upon which customer and proprietary data is kept safe and auditors and the board of directors are satisfied.
Brockett, his security teams and application developers, four years ago laid out the underpinnings of the bank's architecture. They established four areas of concentration overarching enough that they remain tried and true to this day. Underneath those four umbrellas is where the tweaks and transitions are made when a new threat or regulatory requirement commands attention.
"It's important to have a talk about it and get it written down," Brockett says. "You're hit with a lot of different best practices, products and processes. Does it fit under one of our [steps]? If not, we don't do it."
Gartner analyst Tom Scholtz estimates that a little more than half of the Global 2000 have formalized their security architectures and successfully integrated them with the enterprise architecture.
"The more explicit driver for a security architecture is the need to become more consistent in your terminology, language, strategy, modeling and tools. A large part of what you're trying to achieve is the avoidance of duplication and get to the point where you leverage and reuse as much as possible," Scholtz says. "Formalizing an architecture demonstrates to stakeholders that the organization is serious about security."
|Draw It Out|
Blueprinting your architecture? Here's what it might look like.
The tools for creating a virtual blueprint of your security architecture are likely on your desktop already.
"I heard from an enterprise architecture colleague that the most common tool is called EVP--Excel, Visio and PowerPoint," says Gartner analyst Tom Scholtz. "It typically takes on the form factor of a set of models, templates and principles on a combination of things like spreadsheets, Word documents, PowerPoint designs, diagrams and visual workflows [created in Visio]."
Keeping it to these familiar formats facilitates the constant tweaks an architecture will require.
"The structure should be in a consistent format and hierarchy," Scholtz says, "so that you can use it at different levels of planning."
Four Pillars, One Architecture
FFIEC compliance is the latest challenge for Washington Trust. A Dec. 31, 2006 deadline mandated that banks conduct risk assessments of their online banking infrastructure and remediate any shortcomings, especially in the areas of strong authentication for consumers. Banks are spending millions on compliance with FFIEC, yet those with formalized architectures are taking on less water than those without a spelled-out strategy. They're able to roll in these requirements and beef up existing procedures without major overhauls. A periodic tweak of an existing architecture heads off compliance and threat anxiety.
"Because of regulatory changes and laws like FFIEC and Gramm-Leach-Bliley, there was a lot of regulatory guidance that set precedent on IT best practices," Brockett says. "The thing I keep saying is that being in compliance isn't good enough. Every year there are projects and accomplishments that improve security and mitigate risks that exist. We want to get better at that every year."
In 2003, the Washington Trust board of directors approved an architecture that addresses risk from a business point of view, rather than strictly from a technical standpoint. Brockett's team, in conjunction with security and a risk management committee, identified four areas of concentration to best combat the changing threat environment, address regulatory demands, and manage vendors and systems:
- Information security
- Vendor management
- Business continuity/disaster recovery
- Information and systems integrity
"What we've had in place--this four-pillar framework--does not change. It's static. The changes are made within each pillar to monitor, measure and improve risk management," Brockett says. "We tweak and fine-tune components of the program as the threat environment evolves."
For example, under information security, user and consumer electronic security banking policies are spelled out. Applications and IT infrastructure profiles are detailed here, and IT resources are inventoried. Reporting and monitoring procedures are explained, as are user account administration procedures and profile maintenance.
With the architecture blueprinted, Brockett can prioritize threats and address them in a standardized, repeatable way that not only deals with today's problems, but lays a foundation for heading off tomorrow's problems.
"Where we tend to have most vulnerabilities is with internal threats--people with legitimate authorization and access to systems and potentially defrauding us via legitimate access. That's where we are spending a lot of our time," Brockett says.
Brockett's biggest step toward countering employee fraud was an endpoint security deployment (Cisco Clean-Access) that determined device integrity and forced policy on deficient devices. Washington Bank also monitors insider activity (NextSentry's ActiveSentry) on the desktop.
The bank's architecture also includes its disaster recovery and business continuity plans, focusing on recovery information for each application and infrastructure component, plan testing and maintenance schedules, and notification procedures, among other components.
Information and systems integrity puts in print change-management policies, including system configurations and coding. It also spells out who is authorized to make systems changes, when those changes may be made and with whose approval. Database profiles, change logs, system maintenance and the systems development lifecycles are stored here as well.
Brockett's teams went so far as to blueprint policies for dealing with vendors, including the business risks posed by each vendor relationship. To help execute on the blueprints, Brockett has engaged business leaders to act as liaisons between IT and a business unit. These risk coordinators have no formal secu-rity backgrounds, but have responsibility in coordinating, implementing and communicating the security program drawn up in the architecture. The coordinators' performance is measured and bonuses are handed out based on effectiveness.
"The benefit is that it gets everyone talking the same language," Brockett says of the bank's security architecture. "By having a documented framework, it gets everyone understanding where things fit and what we're trying to do."
|What To Do|
Blueprinting your architecture? Here's what it might look like.
Don't Fixate on Format
Focusing on the architecture itself to the detriment of solving problems isn't productive. Security architecture is a means to an end, not an end.
Architecture is not a one-off activity. It's a living document, not just a vision.
This is a continuous process; allocate full-time people to do architecture.
Board review and approval enables upper management to prioritize security.
Take It to the People
Appoint business unit managers as liaisons between security office and users.
Sources: Gartner, Washington Trust Bank, SABSA
Used to be that security architectures were technical reference guides under which a security program is executed. But much the same way the responsibilities of a CISO are evolving to include risk management and an understanding of the business, architectures are similarly evolving.
As with the approach Washington Trust Bank adopted, many security architectures now include policy structures, process information and information models.
"Architectures can be a continuous set of models and templates that evolve and are used on a much more opportunistic basis where the main objective is to avoid reinventing the wheel with every new project," Gartner's Scholtz says. "You're able to formalize decisions and principles, so that the next time you develop a similar application, for example, you're not reinventing the wheel."
Many organizations take a contrary approach where the architecture represents a desired state, and gap analyses are conducted to determine what new initiatives need to be undertaken to reach that desired state. "This is a common approach with enterprise architectures, for example," Scholtz says.
Ultimately, a security architecture must integrate as seamlessly as possible with the overall enterprise architecture, especially with the rapidly evolving threat and regulatory landscapes. This necessary integration makes it almost impossible to design a standalone enterprise security architecture. "It's impractical to do a 35-year plan," Scholtz says. "You have to be more dynamic."
Architectures are blueprints that not only explain an enterprise's technology roadmap, but the controls--processes, policies and technology--to satisfy an auditor.
Scholtz says most architectures are built on three levels:
Conceptual, where abstract goals and models are laid out. This is the high-level vision of the architecture, where processes and designs are modeled, and trust levels mapped out.
Logical, where those goals are applied against the environment and available resources, and alternatives are discussed. This is where organizational, informational and logical design models are blueprinted.
Implementation, where the conceptual and logical levels are carried out. Here the architecture is tweaked as ripples in the environment warrant. Security applications, infrastructure and services are architected at this level; data is classified and the security organization as a whole is architected.
Each level accounts for a business, information and technical viewpoint, Scholtz says.
"This is the time when you get to a position where you have the flexibility to adapt to new risks and changing environmental factors, but do it in a way so as you get as much reuse and repeatability as possible," Scholtz says. "A real benefit of an architectural approach is that you formalize and externalize learning and experience. With environmental changes in IT risk and volatility, the more you get to this point, the more you don't have to address everything as a new solution or initiative."
The secret sauce, however, is in how to best integrate with the enterprise architecture. Overcoming a language barrier is the first step, Scholtz says.
"Enterprise architecture guys talk a language different than typical security guys," Scholtz says. "When a security guy talks about a service or domain, he's talking about something different than when an EA guy talks about a service or domain."
The onus is on security to learn enterprise architecture principles and develop a security architecture that structurally aligns as close as possible, Scholtz says. Some forward-thinking enterprises have folded security architecture teams into the overall enterprise architecture organization. Most, however, operate in isolation from infrastructure-planning teams, application developers and systems integration specialists.
Washington Trust Bank's Brockett takes it a step further, not only integrating his operations with the overall enterprise architecture, but ensuring his teams are in sync with the bank's risk management function--the operational risk coordinator.
"You can't operate in an environment where you're adversarial with the audit or regulatory function. It can't--and won't--work if you get to the point where the audit group is not risk focused," Brockett says.
Security-specific architecture blueprints exist that organizations can use as a template for their environments; several tackle architecture strictly from a business point of view.
SABSA, or the Sherwood Applied Business Security Architecture, is a model that considers business requirements, then assures those requirements are met strategically and conceptually, as well as in design and management of an architecture.
"Unless the security architecture can address this wide range of operational requirements and provide real business support and business enablement, rather than just focusing upon security, then it is likely that it will fail to deliver what the business expects and needs," says John Sherwood, developer of the SABSA model.
Sherwood's model implores security architects to always think in terms of the business, and gird themselves for the scrutiny of those who shun strategic architecture for solely technical.
SABSA is a layered model with six different views of an architecture: contextual, conceptual, logical, physical, component and operational. The contextual view is a description of the business context under which security systems are built, while the conceptual view defines the principles and concepts that guide the logical and physical views. The component view assembles the products and begins the integration within security and the overall enterprise architecture. Finally, the operational view executes and maintains the previous concepts. However, this view needs to be interpreted in detail at each of the other five layers, Sherwood says.
Looking for a security architecture framework? A few templates are a click away.
SABSA (Sherwood Applied Business Security Architecture)
Information Security Forum (ISF)
Department of Defense Architecture Framework (DoDAF)
Zachman Institute for Framework Advancement (ZIFA)
SABSA is not your only option as far as risk-oriented architectures go.
The Information Security Forum (ISF) standard also addresses security from a business perspective, and is a reference on how to architect security into systems management, critical business applications, installations, networks and development.
The ISF standard compiles best practices and lays out how to best measure the effectiveness of a program via its Information Security Status Survey.
The Department of Defense Architecture Framework (DoDAF) is another popular blueprint on which an enterprise can model its security architecture.
DoDAF is a military-grade security architecture, and it guides not only military strategy, but business processes and procedures. It too is broken into separate views: operational, systems, technical standards and an overarching view.
These established frameworks, along with homegrown architecture models, should enable enterprises not only to counter today's issues, but lay down a foundation for warding off future threats and inevitable regulatory changes.
"Use your architectural frameworks to do future planning," Scholtz says. "Treat IT risk as an architecture problem."