Advocacy Agenda - Security

It is the Forum’s view that the proper application of security services and mechanisms, when based on a conscientiously developed security policy formed from a defined threat model and risk assessment, can provide the security architecture and design necessary to ensure the integrity reliability and availability of our nations Emergency and Critical Communications systems.

4.1 Security Considerations
The Forum advocates security is considered throughout the design, development and deployment of systems utilized for essential and critical communications. International and domestic terrorist organizations especially those supported by rogue nations, have access to resources that an enable damaging and potentially crippling attacks on our nation’s E&CC systems. The possible threats range from overt attacks on the physical components to insider attempts to subvert the operational software controlling the components of the systems. These threats may be present during the design and development, manufacturing or operational phases of a system, and in particular for the new nationwide LTE network planned for first responders.

The Wireless innovation forum has published a report outlining a process which identifies potential threats and vulnerabilities and leads to the development of security policies at the organizational, system and individual platform level.²⁰ These security policies specify the criteria and measures needed for protection and mitigation of designated threats throughout the entire lifetime of a system and its component elements.

The process includes identification of assets which require protection. These include but are not limited to information, security operating parameters and data, embedded software, hardware components and virtually any infrastructure component including dispatch centers, servers, routers relays, base stations and individual radio platforms. Threat and vulnerability analyses must tailor for each asset as is the risk assessment estimating the probability that any given threat/vulnerability may be realized. With this process completed then specific security measures and mitigation methods can be developed which can be applied to the design, manufacture and operation of the system and its various component elements. These security measures, methods and design requirements then form the basis of the various Organizational, System and Platform security policies which govern the design, manufacturing, operation and maintenance and decommissioning of the system and its components.

4.2 Avoid Security by Obscurity
The Forum advocates that Regulators' focus on development and application of policies and standards that enable communication systems and platforms to protect all sensitive information and data. A common misconception about security is that it is always enhanced through secrecy. In practice, some elements of a security framework should remain secret while others should not. An attempt to achieve security by keeping the methods confidential is often termed “security through obscurity.” History repeatedly has shown that “security through obscurity” often fails, typically because it precludes a broad and rigorous review that would uncover its flaws and enable experts to fix shortcomings.

Some obvious examples of what is required to remain secret in a security framework are keys, passwords, and biometric data that provide various forms of access control. For example, if a product based its security on publicly available cryptography for which there has been no known failure, then if a key is ever compromised, simply replacing the key may return security to its original state for all transactions going forward. ²¹

4.3 Open Source Security
The Forum advocates Regulators adopt a neutral policy on security of Open Source elements because these elements are, a priori, no less secure than proprietary approaches. While there is active debate on the security posture of open source software, considerable evidence exists that open source code typically is more secure than proprietary code. The reason is that open source code is exposed to a wide range of experts with an interest in the success of the software and the willingness to update it to correct identified flaws. Thus, it is important that any open source code used for Essential and Critical communication systems are actively supported and vetted by a forum of independent evaluators and contributors.

Some of the most successful security techniques in information and communications technology today are based on open source approaches. For example, most web-based e-commerce transactions today use a technique called Secure Socket Layer (SSL), which is also referred to as Transport Layer Security (TLS). The specification for SSL was vetted through the open processes of the Internet Engineering Task Force. IPSEC V.4 and V.6 are examples of other security protocols, which are essential to security on the internet and are mandated for use on systems used by US Government. Thus the Forum urges that Regulators should remain neutral with respect to open source security methods. Academic inquiry and industry discussion coupled with a market test is more likely to lead to the correct outcome with respect to the open source debate than regulatory intervention. ²²

4.4 Over the Air Software Reconfiguration
The Forum advocates regulators allow Over the Air software reconfiguration of software and radio platform operating parameters. Software defined radio technology affords many different opportunities for over the air configuration and control of radio platform operations. These range from the downloading of machine interpretable policies applicable to security, routing, Quality of Service, cognitive behavior as well as updates to platform operating system software and applications. Security methodologies and mechanisms exist to enable secure transmission of waveforms, policies and reconfiguration data.

The Wireless Innovation Forum recognizes the need for security in any download or other over the air operation of wireless devices and infrastructure. The Forum released the first report on security in 2002 and has since released three additional reports^23,24,25,26. These reports cover the broad issues relating to security for wireless devices employing SDR technology to specific requirements for downloading software and software provisioning.

In our latest report “Securing Software Configurable Communication Devices” specific services, methodologies and mechanisms are identified which applied in combination with others can provide the security necessary to ensure the integrity reliability and accuracy of the relevant over the air operation²⁷. Examples of applicable Services and Mechanisms can be found in Chapter 3 of this document include the interworking of mechanisms such as access control, authentication, integrity, encryption, software version control. The applications of these services as examples in these processes are replete throughout the document including chapters 3, 6 and 7.

-----

20 Securing Software Reconfigurable Communications Devices, WINNF-08-P-0013-V1.0.0

21 SDRF Petition for Reconsideration, SDRF-07-R-0012-V0.0.0, pg2

22 Ibid, pg 4 and 5

23 Report on Issues and Activity in the Area of Security for Software Defined Radio, SDRF-02-R-0003-V0.00, 1 September 2002

24 Requirements for Radio Software Download for RF Reconfiguration, SDRF-02-S-007-V1.0.0. 13 November 2002

25 SDR System Security, SDRF-02-P-0006-V1.0.0, November 2002

26 Security Considerations for Operational Software for Software Defined Radio Devices in a Commercial Wireless Domain, SDRF-04-P- 0010-V1.0.0, 27 October 2004

27 Securing Software Reconfigurable Communications Devices WINNF-08-P-0013-V1.0.0

[Return to main Advocacy Agenda page]

WINNF Advocacy Agenda WINNF-RC-0007-V1.2.0

Advocacy Agenda - Security

Login

Our Sponsors