 |
 |
 |
 |
| |
|||||
|
|
|
Home > News & Events > MITRE Publications > The MITRE Digest > | |||||||||||||||||||
Patterns Help Team "SEE" Improved Computer Security May 2003
The "museum scenario" is just one way a team of MITRE researchers in support of our Center for Enterprise Modernization (CEM) explains the need for enterprise owners—whether the head of a commercial business or the chief information officer of a government agency—to think about computer security from the top down. The research project, called Security for Enterprise Engineering, or SEE, is designed to provide a guide for incorporating security measures and controls into the foundations of information technology (IT) frameworks. (In the computer world, the term "security" encompasses data and system confidentiality, integrity, accountability, and availability.) In the beginning of a large IT project, "enterprise architectures" (EA) are created to help organizations put all their business information into an interoperable, understandable form. The word "architecture" refers to the fact that system and software engineers use blueprints and frameworks to guide the design, acquisition, and installation of systems, much as a conventional architect does when designing a physical structure. Many government agencies—such as the Internal Revenue Service and the Department of Defense—are required to develop formal enterprise architectures before launching long-term IT programs. One of CEM's core competencies is helping organizations develop and implement EAs. Because it's critical to think about how to build in security at the very beginning of any IT initiative, the MITRE team believes the time is right for an effort such as SEE. "The initial goal of SEE is quite practical: to compile a set of proven, accepted best practices for security decision support, based on a software-engineering concept called 'patterns,'" says Jody Heaney, a professional in information security and co-principal investigator on the project with colleague Duane Hybertson. "Patterns make it easier to explain security to engineers and designers who aren't security specialists." Patterns are akin to common medical symptoms: specific sets of symptoms point the way toward diagnosis and standard treatment. Similarly, patterns provide software engineers and information architects with sets of typical security "symptoms" likely to appear in a given business's system. Depending on the pattern, designers can build certain types of security measures into the system during the planning phase, rather than forcing the business or organization to continually play patch-and-catch-up later. Security from (A)ssurance to (Z)achman Once the SEE researchers decided to use patterns to make their concepts accessible to a wider audience, they needed a framework for capturing their ideas. "We looked at several possible frameworks for adding the security component," Heaney says. "But we found that each one eventually comes back to Zachman." "Zachman" is shorthand for the Zachman Framework for Enterprise Architecture, developed in the 1980s by John Zachman, a frameworks pioneer. Enterprise architects worldwide use the Zachman Framework to develop their information infrastructures. The basic framework consists of a grid of columns and rows that break key elements of the enterprise architecture process into "views" (for such things as data, function, and people) and stakeholder information (including the business owner and the system designer). The current Zachman Framework, however, lacks a security view."We like Zachman because it's general enough that you can use it for everything," Heaney says. "We saw it as a way for us to think about security—How do we address an entire enterprise's security issues?" Although adding a permanent new view to the official Zachman Framework isn't part of SEE's mission, it provides a readily accepted paradigm for the EA and security communities. "We use Zachman as a tool for our own thinking as well as our customers' thinking," Heaney explains. "But you could use other frameworks—such as the military's Department of Defense Architecture Framework or the U.S. government's Federal Enterprise Architecture Framework—to serve the same purpose." Business-driven Architectures Require Planning Making security accessible is vital for enterprise business owners as well as enterprise architects. Getting the enterprise business owner involved from the beginning helps designers and engineers decide what kind of resources to build into the system. In the earlier example, for instance, the enterprise business owner (such as the museum director or board of trustees) must make choices based on cost and potential harm to the museum's collections. Given that you don't want your database accessible to someone without authorization, some of the questions worth pondering include:
"Often, people don't really want to talk about security, but all of these questions are part of the planning process," Heaney says. "We don't expect nontechnical managers to understand all the details, but they need to think in terms of the overall business plan so the enterprise architect has a basis for technical decisions. "From the software engineer's point of view, it's a lot easier to come up with requirements for security once he or she knows what the business leaders are willing to apply resources against. The enterprise business owner may say his insurance covers losses, so don't put in too many expensive or inconvenient security measures. That's an enterprise decision, which must be made by the enterprise business owner." Communication on Many Levels Ironically, though the heart of SEE lies in communication between enterprise owners and architects, the MITRE team found early on that communication is just as important within the technical community. "This project requires strength in both security and software engineering," Heaney said. When she and Hybertson, an expert in computer architectures, began gathering a team of researchers in 2001, they quickly found knowledge and terminology gaps on both sides. The two groups shared knowledge and material throughout the project. "I'm really proud of being able to bring these groups together. Now we have to get all this information out to the broader community," Heaney adds. One big step in that direction will be the team's Security Patterns Handbook, which they plan to publish in the fall of 2003. At the very least, Heaney hopes the handbook will enable enterprise business owners to make their security choices from a position of strength. In addition, the SEE team is a major contributor and editor for a book on security patterns, a broader community effort under contract for publication by Wiley in 2004. "We can't create an entire set of patterns to address all security, but our goal is to lay the groundwork for others to follow," Heaney says. "We hope once a generic pattern approach is established, software experts in specific domains will take our ideas and use them for specific businesses, such as finance." Given MITRE's success in information security, including developing and managing the CVE (Common Vulnerabilities and Exposures) list used by IT professionals worldwide, it's not hard to imagine SEE expanding to include full sets of patterns for enterprise architectures, especially for the government. But whether or not SEE becomes as widely known as CVE, Heaney hopes government agencies and other organizations will consider using the MITRE security patterns handbook for a simple reason: security patches often don't solve problems and, in fact, may introduce unforeseen consequences. "It's more cost-effective to do security early," she says. "Apply more resources during design and it will cost less later. It's basic systems engineering." —by Alison Stern-Dunyak Related Information Articles and News
Technical Papers and Presentations Websites |
||||||||||||||||||||
| Page last updated: March 2, 2004 | Top of page |
Solutions That Make a Difference.® |
|
|
If
you run a museum specializing in precious gems, you might think "security"
begins and ends with gray-suited guards glaring at the visitors. But what
if the greatest vulnerability of the operation actually lies within your
computers? What if a dishonest employee with access to the museum's database
altered the size and weight records of the diamonds and emeralds? The
thief could then shave real carats off the jewels—with no one the
wiser. An eight-carat diamond could "become" a four-carat stone in the
computer records, while a two-carat gem in storage could just disappear
from the records (and the storage vault) entirely.