NSA Security Blackberry

The IPhone may look pretty, but the Sectera will kick its ass in a combat zone. If you took the IPhone to Afghanistan there is a good chance that the powdery, flower like sand would eat it its sexy smooth face and spit out a pitted, shiny, $400 dollar paper weight/Frisbee. If your going to combat and have a gritty, dirty critical mission, you’ll need something like the Sectera to keep up with you.

A look at the Sectera.

The Sectera is ruggedized in accordance with MIL-STD-810F. This means that it can be dropped, put in water, survive some level of vibration, humidity, temperature and dust.

More on the Sectera

The Sectéra® Edge™ smartphone converges secure wireless voice and data by combining the functionality of a wireless phone and PDA — all in one easy-to-use handheld device. Developed for the National Security Agency’s Secure Mobile Environment Portable Electronic Device (SME PED) program, the Sectéra Edge is certified to protect wireless voice communications classified Top Secret and below as well as access e-mail and websites classified Secret and below. The Sectéra Edge is the only SME PED that switches between an integrated classified and unclassified PDA with a single key press.

Features

* Versatile
o Secure and non-secure wireless phone, e-mail and web browsing
o Withstands rigors of both tactical and everyday environments
o Global roaming over GSM, CDMA or Wi-Fi* wireless networks
o Software upgradeable to VoIP
o Exchange secure e-mail with government personnel, including S/MIME BlackBerry® users
o IPv6 software upgradeable
* Easy-to-Use
o Familiar Microsoft® Windows® Platform
o Wireless desktop synchronization
o Separation of Classified and Unclassified applications
o One-touch switching between classified and unclassified PDA functions
* Advanced Security Features
o Secure wireless access to the SIPRNET and NIPRNET
o DoD PKI enabled Common Access Card (CAC) support
o Supports DoD 8100.2 requirements
o Type 1 encrypted storage of classified data
o Can be used inside closed areas with “SCIF-Friendly” feature

Popularity: 1% [?]

IA Control Typo: DCSQ-1 Unix SRR script

Alex of Le Blog d’Alex
had a good question:

Looking at Unix SRR scripts (January 08 release) I’ve found some PDI’s (vulnerabilities) corresponding to IA control number “DSCQ-1″, which I cannot find in DoD Instructions 8500.2 Feb 6 2003 (neither appears the DSxx Subject Area in table E4.T1.).

Do you know what Subject Area corresponds to DSxx? And what IA control is DSCQ-1?

I’ve googled for it and I can’t find anything neither.

If you answer, please would you mind answering also by email? Thanks by advance.

I don’t think there is a DSCQ. In fact there is no DSXX series of IA Controls. I think that is a typo in the Unix SRR script. A Unix guru security co-worker of mine has found other minor typo’s in the script as well as tons of false positives.

It looks like the script is actually refering to “DCSQ-1″. Looks like they swapped the “CS”

DCSQ-1 Software Quality

Software quality requirements and validation methods
that are focused on the minimization of flawed or malformed
software that can negatively impact integrity or availability
(e.g., buffer overruns) are specified for all software
development initiatives.
–DoD 8500.2

If this is not the case than I really don’t know what DCSQ could be.

Popularity: 5% [?]

Systems Data Exchange Matrix (SV-6)

Product Definition. The Systems Data Exchange Matrix specifies the characteristics of the system data exchanged between systems. This product focuses on automated information exchanges (from OV-3) that are implemented in systems. Non-automated information exchanges, such as verbal orders, are captured in the OV products only.

Product Purpose. System data exchanges express the relationship across the three basic architecture data elements of an SV (systems, system functions, and system data flows) and focus on the specific aspects of the system data flow and the system data content. These aspects of the system data exchange can be crucial to the operational mission and are critical to understanding the potential for overhead and constraints introduced by the physical aspects of the implementation.

Product Detailed Description. SV-6 describes, in tabular format, system data exchanged between systems. The focus of SV-6 is on how the system data exchange is implemented, in system-specific details covering periodicity, timeliness, throughput, size, information assurance, and security characteristics of the exchange. In addition, the system data elements, their format and media type, accuracy, units of measurement, and system data standard are also described in the matrix.

SV-6 relates to, and grows out of, OV-3. The operational characteristics for the OV-3 information exchange are replaced with the corresponding system data characteristics. For example, the Levels of Information Systems Interoperability (LISI) level required for the operational information exchange is replaced by the LISI level achieved through the system data exchange(s). Similarly, performance attributes for the operational information exchanges are replaced by the actual system data exchange performance attributes for the automated portion(s) of the information exchange.

On SV-6, each operational needline is decomposed into the interfaces that are the systems equivalents of the needline. SV-1 graphically depicts system data exchanges as interfaces that represent the automated portions of the needlines. The implementation of SV-1 interfaces is described in SV-2 (if applicable). The system data exchanges documented in SV-6 trace to the information exchanges detailed in OV-3 and constitute the automated portion(s) of the OV-3 information elements.

A partial format for the SV-6 matrix can be found in CJCSI 6212.01B, and that format is required for C4ISP development. However additions to the CJCSI 6212.01B matrix to meet program-unique needs should also be allowed.

More Examples of SV-6 at:

Ministry of Defense AF

Popularity: 4% [?]

Technical Standards Forecast

Product Definition. The Technical Standards Forecast contains expected changes in technology-related standards and conventions, which are documented in the TV-1 product. The forecast for evolutionary changes in the standards should be correlated against the time periods as mentioned in the SV-8 and SV-9 products.

Product Purpose. One of the prime purposes of this product is to identify critical technology standards, their fragility, and the impact of these standards on the future development and maintainability of the architecture and its constituent elements. Product Detailed Description. TV-2 lists emerging or evolving technology standards relevant to the systems covered by the architecture. It contains predictions about the availability of emerging standards, and relates these predictions to the Systems View elements and the time periods that are listed in the SV-8 and SV-9.

The specific time periods selected (e.g., 6-month, 12-month, 18- month intervals) and the standards being tracked should be coordinated with architecture transition plans (see SV-8). That is, insertion of new techno logical capabilities and upgrading of existing systems may depend on, or be driven by, the availability of new standards and products incorporating those standards. The forecast specifies potential standards and thus impacts current architectures and influences the development of transition and objective (i.e., target) architectures. The forecast should be tailored to focus on standards areas that are related to the purpose for which a given architecture is being described and should identify potential standards that will affect the architecture. If interface standards are an integral part of the technologies important to the evolution of a given architecture, then it may be convenient to combine TV-2 with SV-9. For other projects, it may be convenient to combine all the standards information into one document, combining TV-2 with TV-1.

TV-2 delineates the standards that will potentially impact the relevant system elements (from SV-1, SV-2, SV-4, SV-6, and OV-7) and relates them to the time periods that are listed in the SV-8 and SV-9. A system’s evolution, specified in SV-8, may be tied to a future standard listed in TV-2. A timed technology forecast from SV-9 is related to a TV-2 standards forecast in the following manner: a certain technology may be dependent on a TV-2 standard (i.e., a standard listed in TV-2 may not be adopted until a certain technology becomes available). This is how a prediction on the adoption of a future standard, as applicable to systems elements from SV-1, SV-2, SV-4, SV-6, and OV-7, may be related to standards listed in TV-1 through the SV-9. A template for TV-2 is not shown in this section. The same template shown in TV-1 may be used to describe TV-2.

Popularity: 3% [?]

Technical Standards Profile

TV-1.

Product Definition. The Technical Standards Profile collects the various systems standards rules that implement and sometimes constrain the choices that can be made in the design and implementation of an architecture.

Product Purpose. Primarily, this product is concerned with delineating systems standards rules and conventions that apply to architecture implementations. When the standards profile is tied to the system elements to which they apply, TV-1 serves as the bridge between the SV and TV.

Product Detailed Description. TV-1 consists of the set of systems standards rules that govern systems implementation and operation of that architecture. The technical standards generally govern what hardware and software may be implemented and what system data formats may be used (i.e., the profile delineates which standards may be used to implement the systems, system hardware/software items, communications protocols, and system data formats). TV-1 is constructed as part of a given architecture and in accordance with the architecture purpose. Typically, this will involve starting with one or more overarching reference models or standards profiles, such as OMB’s TRM [OMB, 2003], DoD TRM, or the Joint Technical Architecture (JTA) [DISA, 2002]. Using these reference models or standards profiles, the architect should select the service areas relevant to the architecture. The identification of relevant services within service areas subsequently points to agreed-upon standards. The source document used for identifying each standard must also be cited.

In most cases, especially in describing architectures with less than a Military Servicewide scope, TV-1 consists of identifying the applicable portions of the JTA and other existing technical standards guidance documents, tailoring those portions, as needed, in accordance with the latitude allowed in these guidance documents, and filling in any gaps. This process of tailoring standards guidance from higher level, more general guidance, is called creating a standards profile. For example, a DoD mission area might create a common mission-area standards profile using TV-1. Each program or project in that mission area would further refine this common profile to create its own standards profile. Care should be taken in the refinement process to ensure that systems compliant with the child profile would cont inue to be interoperable with systems compliant with the parent profile. If service-level JTA-like documents are used, then the relationship between the JTA and those documents must be stated. Some of the existing technical standards guidance documents are described in the Deskbook [see section on URRs in the Deskbook].

For a given domain, TV-1 may also state a common standard implementation for a particular standard, not just list the standard. Many standards can be implemented in compliant, but not interoperable ways, such as MIL STD 6016.

The standards are referenced as relationships to the systems, system functions, system data, hardware/software items or communication protocols in SV-1, SV-2, SV-4, SV-6, OV-7, and SV-11 products, where applicable. That is, each standard listed in the profile should be associated with the SV elements that implement or use the standard (e.g., SV-1, SV-2, SV-4, SV-6, OV-7 and SV-11 element standards, where applicable). Standards for OV-7 and SV-11 do not include system data standards such as naming conventions, attribute lists, and field types, but refer to the source for the data entities (e.g., DoD XML Registry), or the data modeling standard used (e.g., IDEF1X).

Popularity: 2% [?]

Physical Schema

SV-11

Product Definition. The Physical Schema product is one of the architecture products closest to actual system design in the Framework. The product defines the structure of the various kinds of system data that are utilized by the systems in the architecture. Product Purpose. The product serves several purposes, including (a) providing as much detail as possible on the system data elements exchanged between systems, thus reducing the risk of interoperability errors, and (b) providing system data structures for use in the system design process, if necessary.

Product Detailed Description. SV-11 is an implementation-oriented data model that is used in the Systems View to describe how the information requirements represented in Logical Data Model (OV-7) are actually implemented. Entities represent (a) system data flows in SV-4, (b) system data elements specified in SV-6, (c) triggering events in SV-10b, and/or (d) events in SV-10c.

There should be a mapping from a given OV-7 to SV-11 if both models are used. The form of SV-11 can vary greatly, as shown in Figure 5-40. For some purposes, an entityrelationship style diagram of the physical database design will suffice. References to message format standards (which identify message types and options to be used) may suffice for messageoriented implementations. Descriptions of file formats may be used when file passing is the mode used to exchange information. A Data Definition Language (DDL) (e.g., Structured Query Language [SQL]) may also be used in the cases where shared databases are used to integrate systems. Interoperating systems may use a variety of techniques to exchange system data and have several distinct partitions in their SV-11 with each partition using a different form. Standards associated with entities (e.g., entities are those defined in DoD XML Registry) are also documented in this product.

Popularity: 2% [?]

Operational Activity to Systems Function Traceability Matrix (SV-5)

Product Definition. Operational Activity to Systems Function Traceability Matrix is a specification of the relationships between the set of operational activities applicable to an architecture and the set of system functions applicable to that architecture.

Product Purpose. SV-5 depicts the mapping of operational activities to system functions and thus identifies the transformation of an operational need into a purposeful action performed by a system.

SV-5 can be extended to depict the mapping of capabilities to operational activities, operational activities to system functions, system functions to systems, and thus relates the capabilities to the systems that support them. Such a matrix allows decision makers and planners to quickly identify stovepiped systems, redundant/duplicative systems, gaps in capability, and possible future investment strategies all in accordance with the time stamp given to the architecture. SV-5 correlates capability requirements that would not be satisfied if a specific system is not fielded to a specific DoD unit.

Product Detailed Description. The Framework uses the terms activity in the OVs and function in the SVs to refer to essentially the same kind of thing-both activities and functions are tasks that are performed, accept inputs, and develop outputs. The distinction lies in the fact that system functions are executed by automated systems, while operational activities describe business operations that may be conducted by humans, automated systems, or both. Typical systems engineering practices use both of these terms, often interchangeably. However, given the Framework’s use of activities on the operational side and functions on the systems side, and the fact that operational nodes do not map one-to-one to systems nodes, it is natural that operational activities do not map one-to-one to system functions. Therefore, SV-5 forms an integral part of the eventual complete mapping from operational capabilities to systems requirements. SV-5 is an explicit link between the OV and SV. The capabilities and activities are drawn from OV-5, OV-6b, and OV-6c. The system functions are drawn from an SV-4. (SV-1 and SV-2 may also define system functions for identified systems.)

The relationship between operational activities and system functions can also be expected to be many-to- many (i.e., one operational activity may be supported by multiple system functions, and one system function may support multiple operational activities).

Popularity: 3% [?]

Systems Functionality Description (SV-4)

Product Definition. The Systems Functionality Description documents system functional hierarchies and system functions, and the system data flows between them. Although there is a correlation between Operational Activity Model (OV-5) or business-process hierarchies and the system functional hierarchy of SV-4, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Systems Function Traceability Matrix (SV-5), which provides that mapping.

Product Purpose. The primary purposes of SV-4 are to (a) develop a clear description of the necessary system data flows that are input (consumed) by and output (produced) by each system, (b) ensure that the functional connectivity is complete (i.e., that a system’s required inputs are all satisfied), and (c) ensure that the functional decomposition reaches an appropriate level of detail.

Product Detailed Description. SV-4 describes system functions and the flow of system data among system functions. It is the SV counterpart to OV-5. SV-4 may be represented in a format similar to data flow diagrams (DFDs) [DeMarco, 1979]. The scope of this product may be enterprise wide, without regard to which systems perform which functions, or it may be system specific. Variations may focus on intranodal system data flow, internodal system data flow, system data flow without node considerations, function to system allocations, and function to node allocations.

The system functions documented in the SV-4 may be identified using the Service Component Reference Model (SRM),20 or some other system function taxonomy, and correlated to SV-1 and SV-2 systems. System functions are not limited to internal system functions and can include Human Computer Interface (HCI) and Graphical User Interface (GUI) functions or functions that consume or produce system data from/to system functions that belong to external systems. The external system data sources and/or sinks can be used to represent the human that interacts with the system or external systems. The system data flows between the external system data source/sink (representing the human or system) and the HCI, GUI, or interface function can be used to represent human-system interactions, or system-system interfaces. Standards that apply to system functions, such as HCI and GUI standards, are also specified in this product.

Like OV-5, SV-4 may be hierarchical in nature and may have both a hierarchy or decomposition model and a system data flow model. The hierarchy model documents a functional decomposition. The functions decomposed are system functions.

Popularity: 2% [?]

Systems Communications Description

SV-2 Templates

Product Definition. The Systems Communications Description depicts pertinent information about communications systems, communications links, and communications networks. SV-2 documents the kinds of communications media that support the systems and implement their interfaces as described in SV-1. Thus, SV-2 shows the communications details of SV-1 interfaces that automate aspects of the needlines represented in OV-2.

Product Purpose. SV-2 can be used to document how interfaces (described in SV-1) are supported by physical media. This kind of communications media support information is critical in performing certain infrastructure and system acquisition decisions.

Product Detailed Description. SV-2 documents the specific communications links or communications networks (e.g., Intelink or Joint Worldwide Intelligence Communications System [JWICS]) and the details of their configurations through which systems interface. While SV-1 depicts interfaces between systems or systems nodes, SV-2 contains a detailed description of how each SV-1 interface is implemented (e.g., composing parts of the implemented interface including communications systems, multiple communications links, communications networks, routers, and gateways).

Communications systems (e.g., switches, routers, and communications satellites) are systems whose primary function is to control the transfer and movement of system data as opposed to performing mission application processing.

A communications link is a single physical connection from one system (or node) to another. A communications path is a (connected) sequence of communications systems and communications links originating from one system (or node) and terminating at another systems (or node).

A communications network may contain multiple paths between the same pair of systems. The term interface used in SV-1 and referenced in SV-2 represents an abstraction of one or more communications path(s).

The graphical presentation and supporting text for SV-2 should describe all pertinent communications attributes (e.g., waveform, bandwidth, radio frequency, and packet or waveform encryption methods). Communications standards are also documented in this product, where applicable.

Because SV-2 depicts the implementation details for the interfaces described in SV-1 by decomposing them into communications systems, communications links, and communications networks, it can present either internodal or intranodal versions. The internodal version details the communications links and/or communications networks that interconnect systems nodes (node edge to node edge) or specific systems (system-system from one node to other nodes). The intranodal version of SV-2 looks inside each of the represented nodes to illustrate the communications links between specific systems.

Popularity: 2% [?]

Logical Data Model

OV-7 Template

Product Definition. The Logical Data Model describes the structure of an architecture domain’s system data types and the structural business process rules (defined in the architecture’s Operational View) that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships. Product Purpose. OV-7 including the domain’s system data types or entity definitions, is a key element in supporting interoperability between architectures, since these definitions may be used by other organizations to determine system data compatibility. Often, different organizations may use the same entity name to mean very different kinds of system data with different internal structure. This situation will pose significant interoperability risks, as the system data models may appear to be compatible, each having a Target Track data entity but having different and incompatible interpretations of what Target Track means. An OV-7 may be necessary for interoperability when shared system data syntax and semantics form the basis for greater degrees of information systems interoperability, or when a shared database is the basis for integration and interoperability among business processes and, at a lower level, among systems.

Product Detailed Description. OV-7 defines the architecture domain’s system data types (or entities) and the relationships among the system data types. For example, if the domain is missile defense, some possible system data types may be trajectory and target with a relationship that associates a target with a certain trajectory. On the other hand, architecture data types for the DoDAF (i.e., DoDAF-defined architecture data elements, AV-2 data types, and CADM entities) are things like an operational node or operational activity. OV-7 defines each kind of system data type associated with the architecture domain, mission, or business as its own entity, with its associated attributes and relationships. These entity definitions correlate to OV-3 information elements and OV-5 inputs, outputs, and controls.

Although they are both called data models, OV-7 should not be confused with the CADM. OV-7 is an architecture product and describes information about a specific architecture domain. The CADM is not an architecture product. The CADM is a database design for a repository of DoDAF products and architecture data. CADM-based repositories can store architecture products, including Logical Data Models, from any DoDAF-based architecture project. Thus, the CADM addresses a structure for storing architecture data (e.g., instances of operational nodes and operational activities), while a Lo gical Data Model for missile defense, for example, might define architecture domain entities and relationships such as missile tracks and points of impact.

The purpose of a given architecture helps to determine the level of detail needed in this product. A formal data model (e.g., the Integrated Definition for Data Modeling [IDEF1X]) [FIPS 184, 1993] that is detailed down to the level of architecture domain system data, their attributes, and their relationships is required for some purposes, such as when validation of completeness and consistency is required for shared data resources. However, for other purposes, a higher- level conceptual data model of the domain of interest will suffice, such as a subject area model or an entity-relation model without attributes. The term logical data model is used here in this context, regardless of the level of detail the model exhibits.

The architecture data elements for OV-7 include descriptions of entity, attribute, and relationship types. Attributes can be associated with entities and with relationships, depending on the purposes of the architecture.

Popularity: 2% [?]

Written by elamb.security · Filed Under Assurance, architectural views 

Next Page »