On the road to a better security blueprint

The linking of threat management and EA design could yield huge potential benefits.

Threat management involves identifying information technology system vulnerabilities and prescribing security measures to address them, so it would seem to be an ideal fit with enterprise architecture (EA).

After all, the purpose of EA is to design an organization’s business processes to better meet its mission and strategic goals, and a big part of that is identifying IT systems to help support and improve those business processes. The two disciplines are intrinsically linked: Without effective IT security, technology is more of a hindrance to efficient agency operations than a help.

It would also appear that there are sufficient policy directives for pairing EA and threat management. For example, the Office of Management and Budget requires federal agencies to include security as part of the EA progress reports they have to file each year.

And the Federal Information Security Management Act (FISMA), the principal driver for agency IT security efforts, requires a risk-management approach, which could flow naturally from an EA’s identification of critical data, IT systems and business processes.

However, experts say that despite the huge potential benefits of linking them, threat management and EA design rarely come together in practice. The reasons for this disconnect vary, though the obstacles blocking a closer link are hardly insurmountable, they say.

For example, tying FISMA more explicitly to an EA would give agencies a way to manage their IT security consistently over the long term that would better match their evolving business needs, said Chris Parker, chief executive officer of 4Front Security.

Instead, “FISMA is driven solely by the [current] need to secure IT,” Parker said. “Its requirements are open to interpretation, and they are not tied to agency business processes.” A separate hurdle is getting all the stakeholders working together. It is already difficult encouraging business managers and IT staff to hammer out an EA together. Involving IT security experts, who often work separately from the mainline IT staff, is yet another challenge.

“Many of the EA frameworks outside of the [military] world don’t discuss security at any practical level,” said Jan Popkin, chief strategist at Telelogic and a longtime player in the government EA arena. “But for it to be effective, you need a common ontology so that everyone understands what security means in [an EA] context.”

EA traditionally has been the province of the business side of the organization, and security has been added on after the IT architecture has been determined, he said. The goal should be for earlier and better collaboration among the business, general IT employees and IT security staffs.

Leaving security considerations out of the early stages of EA development can lead to costly mistakes, said Michael Farber, a vice president of Booz Allen Hamilton. If security people are not involved, then threat mitigation is not likely to be a central factor in the crafting of the EA. That raises the risk of making investments in what could ultimately be the wrong IT architecture for the business mission, he said.

“I’ve seen instances where funds were paid out and people thought they had met the security requirements but then had to go back and redo the whole thing because they hadn’t thought things through at the beginning,” Farber said.

Nipping problems in the bud
Rolling risk assessment into EA development from the start can yield major payoffs, both in the short term through immediate risk reduction and in the long term as agency missions and supporting IT systems evolve, said Roy Isbell, vice president of global government consulting services for the security vendor Symantec.

In developing the EA, officials could identify the threat profiles of all the business assets the EA describes. Then they could use a standard such as FISMA to select the proper security controls, Isbell said.

“Agencies would have to implement those controls and maintain them,” he said. “But they would also have an iterative process that provides a feedback loop for the risk assessment process.”

Such an approach probably would have identified the potential for problems like the recent one at the Department of Veterans Affairs, which lost control of information when a laptop computer that an employee had taken home was stolen, said Mark Perry, vice president of global security transformation services at Symantec.

The biggest challenge in using threat analysis to devise an appropriate enterprise protection program lies in assessing the value of the data, business processes and IT systems that need safeguarding, said Tim Braithwaite, a faculty member at the Federal Enterprise Architecture Certification (FEAC) Institute.

Knowing the value of those assets is particularly important in convincing agency executives to spend money on security, he said. However, scant efforts have been made to demonstrate the value IT contributes to improving business processes. IT security spending is in an even worse position, typically viewed grudgingly as a way to plug only the most obvious holes.

“The value of what IT does for the world is not understood,” Braithwaite said. “It’s never been truly analyzed, and the tools have not been provided to involve executives and other managers in the discussion.”

Braithwaite has devised a method for assessing value and risk called the Security Knowledge Framework, a derivative of the well-known Zachman Framework used in EA.

Braithwaite’s framework applies a positive worth to the various elements of an operation and calculates the penalty involved in not having what’s needed to support particular business activities.

There’s value to the business in having quality and timely data whose integrity is assured, for example. On the other hand, an operation will be negatively affected by not having data that can be trusted or is compromised in some way. Those calculations are tied directly to the security of the IT systems the organization uses.

Yet most organizations do not conduct this kind of exercise, leaving their efforts at IT security stuck in a reactive rather than a proactive mode.

If any part of the government will soon be using threat management and EA to ensure security it is the military. With the Defense Department’s focus on network-centric warfare and the Global Information Grid, security is a necessity to ensure the flow of information to warfighters.

That makes security an equal partner from the outset, said Jim Granger, technical director at the Navy Cyber Defense Operations Command.

However, cooperation among the players doesn’t always happen naturally, even in the Navy, he said. Those who favor security and those who favor easier access to systems are continually at odds. Granger hopes that as people are made more aware of security needs through mandated information assurance training, they will be more receptive to incorporating security and risk mitigation into all IT processes.

He also thinks it will become easier to standardize security-related processes because of the growing availability of enterprise-level security tools.

“Most definitely, I do believe that security and threat management will become standard components of EA in the future,” he said.

Think security early and oftenIndustry best practices dictate that you model your threats and responses at various layers of the enterprise architecture, said Michael Farber, a vice president at Booz Allen Hamilton.

As you apply risk mitigation based on that information, you will identify gaps in threat responses, he said.

If organizations don’t approach threat mitigation this way, they risk drafting enterprise architecture schematics or writing procurement requirements that don’t adequately account for security needs, he said.

— Brian Robinson

Plan of actionIt takes a fair amount of coordination to improve an agency’s information technology security posture by linking threat management with enterprise architecture (EA) planning. Specifically:

  • Definitions of terms used to describe vulnerabilities and threat mitigation are critical. That means that people in all areas of the operation — from mission managers to IT staff — must be involved in developing terms. Most security people will be in operational roles and won’t be involved in setting enterprise systems requirements, but they will need to be involved in defining risk-management terms.

  • The Achilles’ heel of any IT infrastructure is that no one person will know how all systems work and a process will have to be developed to integrate the expertise of people who may not be used to speaking with each other about these issues.

  • Many people may seem to be paying attention to threat management, but it’s likely they are focused narrowly on meeting requirements mandated by the Federal Information Security Management Act. It will take an active awareness campaign to switch their focus to EA.

  • It will generally be easier to teach IT people about the business aspects of EA than to teach business people about IT technicalities, so agencies should target their education efforts accordingly.

— Brian Robinson