iGouge

Infomation Assurance Enterprise Architecture

Our lead experience comes from being a key partner of the Navy-EDS team since 2001. We have supported the information assurance team for the Navy Marine Corps Intranet (NMCI). Our cybersecurity team has been involved in several enterprise information assurance architecture projects.

Note (an earlier blog posting has a list of specific projects).

Both government and industry are moving toward more formal development and documentation of Enterprise Architectures (EAs) based on Enterprise Architecture Frameworks. The purpose of a framework is to insure that all elements of the enterprise – including IA – are adequately addressed. This completeness is important since EAs are used as the basis for Information Technology (IT) management and investment decisions. (Please note: the use of enterprise architecture in the government/DOD sense also may include more traditional C4I architectures. The line between IT and C4I is fading, so TechTeam can also include their past C4I expertise).

The purpose of an EA is to insure that IT (or C4I) effectively supports the needs of the business or mission. It follows that the IT IA element in the enterprise architecture must be linked to the enterprise Business/mission needs.

IA must also be effective. Effective IA within an enterprise architecture depends on both
integration and separate analyzability of IA elements. IA elements of the enterprise architecture must be linked to other elements of the architecture (integration), because IA elements do not
exist in isolation. IA elements must also be viewable independently, because otherwise the
effectiveness of the IA solution cannot be determined.

Today IA is not being effectively addressed in most developed frameworks and EAs. What
usually happens is one of two approaches. Frequently the IA aspects of a system are designed
and analyzed separately from the rest of the architecture, and are therefore not well integrated,
leading to a potential for new vulnerabilities. Alternatively, the IA aspects are designed
implicitly into the architecture so that they cannot be extracted, and they are therefore not
separately analyzable. The need to link IA aspects to business needs is often overlooked in both
approaches.

Part of the problem is the lack of a compendium of IA knowledge immediately useful to
enterprise engineers who are not IA specialists.

We can provide the IA Specialist that is needed by a project office or architecture development team.

Current practice segregates IA engineering from the remainder of engineering of a system or enterprise, such that IA engineers are obliged to address all aspects of IA.

A shortage of qualified IA engineers means that IA issues cannot be properly addressed or integrated into decisions made at planning, policy, and business design levels of the enterprise. Thus, there is a need for practical guidance on how enterprise engineers not qualified as IA engineers can include IA in architectures. Developing such guidance should be possible because a significant portion of day-to-day IA work is routine and well understood by IA engineers, even though it is not understood by non-IA engineers.

More specifically, the objectives of having Cybersecurity part of your architecture team are to:

• Capture knowledge of routine, best practice solutions to standard IA problems across the full
range of enterprise engineering levels of abstraction

• Integrate the IA solutions into a total IA view that spans all levels of abstraction

• Show how this IA view is integrated into the currently used enterprise views

• Make individual best practice IA solutions and the integrated IA view available in a
representation accessible to engineers who are not IA specialists

• Provide guidance to engineering practitioners for applying the best practice IA solutions

4. Potential benefits of the TechTeam Cybersecurity approach

Most organizations and enterprises are building architectures and using enterprise frameworks
today but there is no common approach to analyzing and defining IA in these architectures and
frameworks. The architecture team does not know what to capture in enterprise frameworks and architectures for IA.

Using a cybersecurity team, the potential benefits include enhancing the ability of system architects to address IA in enterprise frameworks and architectures in two ways.

First, our IA engineering and past expertise results should help engineers address the need for IA early in the development process. In general, frameworks promote commonality by specifying a set of architecture products, but IA aspects have not yet been addressed. Architecture is a way to trace IA to business needs.

Second, our staff augmentation should help to address the shortage of skilled personnel in the IA area. Today, IA staff are called upon as soon as the topic arises even though there are many basic areas that could be addressed by enterprise engineering staff.

If our addition to the team enables system engineers to solve routine IA problems, the IA staff can be used to provide support for unique problems and to ensure all areas are addressed for completeness.