Newsletter Archive

27 Sep, 2007

SIFT Note 2007-03

Using Principles to Guide Information Security
SIFT was engaged late last year by DCITA on behalf of the IT Security Expert Advisory Group (ITSEAG) of the Trusted Information Sharing Network (TISN) to develop a range of papers which provide strategic guidance for the owners and operations of Australian critical infrastructure on the development of organisational information security programmes. The consulting engagement produced a set of reports similar to other TISN guidance publications including:

  • A detailed report
  • A summary for CEOs and boards of directors
  • A summary for CIOs and CISOs

These reports have now been released and are available from the TISN website www.tisn.gov.au and the DCITA website www.dcita.gov.au. Through consideration of a range of best practice information security standards, and identification of strategic needs of a sample of Australian critical infrastructure organisations through extensive workshopping - SIFT identified seven (7) basic Principles of Information Security that should "underpin the enterprise's strategy for protecting and security its information assets". The identified principles are:

  • Information Security Is Integral to Enterprise Strategy
  • Information Security Impacts on the Entire Organisation
  • Enterprise Risk Management Defines Information Security Requirements
  • Information Security Accountabilities Should be Defined and Acknowledged
  • Information Security Must Consider Internal and External Stakeholders
  • Information Security Requires Understanding and Commitment
  • Information Security Requires Continual Improvement

The principles are presented with a range of recommendations which provide further detailed guidance on how each principle can be applied within an organisation. The applicability of these principles and recommendations is discussed in a section entitled "Security Architecture Development" - where the recommendations are applied to various stages of The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM). For practicality, an easy of use "Principle Self-Assessment Checklist" is contained in the Appendices of the main report to better enable strategic decision makers to validate the deployment of the Principles within their enterprise. SIFT strongly recommends that all organisations seeking to develop a best practice information security regime consider the principles and recommendations contained in these papers. Further information: Secure Your Information - Full Report Secure Your Information - Advice for CEOs and Boards of Directors Secure Your Information�Advice for CIOs and CSOs The Trusted Information Sharing Network

Service Oriented Architecture (SOA): Attacking Discovery Services
The trend in enterprise information technology system design is towards the concept of service-oriented architecture (SOA) - where individual systems exchange information and utilise each other to perform specific processing. In this article 'Services' denote the set of functions which are made available by independent systems, which can be accessed without requiring knowledge of the system's underlying platform implementation. This shift towards seamless and interoperable services has resulted in a proliferation of service discovery mechanisms that allow systems to dynamically find and communicate with other systems. These mechanisms, which in turn are also services, include host discovery, service maps, directories and service descriptions. Mechanisms such as these typically provide detailed information required to utilise systems that are indexed and can provide an abundance of information to would-be attackers. In addition to the information disclosure aspects of service discovery mechanisms, attacks can also be launched against the mechanisms themselves. Increased reliance upon discovery services by legitimate users suggests that these mechanisms are becoming increasingly critical to the operation of businesses. In order for a client system to enumerate available services, often it must first utilise the discovery mechanism associated with that type of service. This may be performed manually by the end user or automatically by an operating system or application. By attacking this exchange, a malicious user may be able to subvert or tamper with communications in a manner that allows the compromise of one or both systems. A recent wireless attack illustrates this concept: researchers found that certain implementations of wireless device drivers were able to be attacked even before the system was connected to a wireless network. The flaw exists within the discovery component that allows the wireless device to search for available networks. Similar attacks have been demonstrated on Bluetooth devices. One such class of threat concentrates on attacking the service discovery mechanisms that facilitate access to business services instead of targeting the services themselves. For example, an attacker may choose to target a service directory that contains a database of the services available within an organisation. If access to this directory can be gained, the attacker will have access to detailed information about the available services such as their purpose, their location and how to utilise them. Additionally, the attacker is also in a position to launch attacks on legitimate client systems, such as workstations used by the organisation's employees, who connect to the directory in order to access the information required to make valid use of business services. Although this may not result in a direct compromise of business systems, it may provide an attacker with opportunities to compromise client systems and launch attacks through them against business systems. Within the application realm, analogous architectures exist in the form of directory and mapping services. Given that these services provide a centralised 'front door' to a number of other services, organisations that deploy service directories (e.g Microsoft Active Directory, Novell eDirectory) should be aware of the need to provide appropriate security to ensure that they are resilient to attack. Furthermore, client applications that automatically search for active services or directories also need to be protected against the discovery of malicious services created by attackers in an attempt to compromise client systems. This form of attack in the application domain mirrors the threat of rogue or 'evil twin' wireless access points in the network domain. By being aware of threats targeting communications that occur during service discovery, organisations can implement appropriate defences to protect both clients and servers. Effective countermeasures against attacks on discovery mechanisms may include the secure design and implementation of the directory application, the use of open protocols and standards and the restriction of system communications through the use of access control lists or firewall rules. Further information: Wi-Fi hacked in 'digital drive-by' Bluetooth Security Review

Security Governance: Accommodating Policy Exceptions
A Security Policy plays a critical role in information security assurance within organisations, and is often used to govern the protection of commercially sensitive information and assets. Although a carefully crafted set of policies will encompass the broad spectrum of security requirements within an organisation, it is unrealistic to assume one hundred percent compliance is possible one hundred percent of the time. Practically, it should be expected that policy exceptions can and will occur as there will be instances where circumstances and technology developments do not allow complete compliance. In order to accommodate such policy exceptions, it is necessary to develop an official procedure for granting exemption to policy components, which is to be followed in the event the risk of such policy exceptions is acceptable. Such a procedure should clearly identify the person(s) responsible for approving policy exceptions as well as describe the steps required to obtain an exemption. A policy exemption is typically established in three stages: application, review and approval:

  • The application stage involves the initial identification of a policy exception and the request for an exemption from the requirement to comply - either in the short term, or on a permanent basis.
  • The review stage consists of conducting a risk assessment of the identified exception in order to determine the likelihood and extent of adverse impacts of the exemption if granted.
  • The approval stage comprises the final signoff by the responsible parties that grants the exemption. A separate renewal stage may also be included in the procedure to facilitate exemption expiry and re-approval.

Perhaps the most important stage of the exemption process is the review stage, as the findings of the risk assessment will directly influence the outcome of the exemption application and potentially affect the security of an organisation's IT infrastructure. Optimally a complete risk assessment of the proposed exemption will evaluate the effects and impacts of approving the exemption along with any additional costs and other impacts that would accompany forced compliance. However, assessors are required to provide the assessment within the time constraints imposed by business objectives. Thus, the process is often subject to the professional judgment of the assessor. Nevertheless, the resulting analysis should be documented along with identified risk mitigation strategies and monitoring requirements. Once an exemption has been approved, it can be linked with the resulting change request to provide process transparency and traceability. Having a procedure to appropriately handle policy exceptions that incorporates an assessment of risks ensures that exemptions are granted only when the exception does not pose undue risk to the organisation. Furthermore, the clear definition of exemption details and required mitigating controls provides an enforceable scope. These features of a carefully defined exemption procedure enhance the ability for an organisation to handle policy exceptions whilst minimising risk. Further information: The SANS Security Policy Project

Understanding the Divide Between Functional and Security Requirements
It is widely understood within the software community that the requirements elicitation and definition process of a software project is critical to its success. The definition of software requirements that accurately reflect the needs of the business are essential for a software project to meet its objectives and deliver business benefits. While functional requirements analysis is a widely studied and well-understood discipline, the definition of security requirements is not. The majority of business analysts do not have adequate training or expertise in the security field, and this can lead to a significant disparity in the quality between functional and security requirements. This lack of quality in software security requirements is manifested in the form of security vulnerabilities and deficiencies that undermine information integrity and privacy. Incorrect or inappropriate requirements can lead to problems ranging from security mechanisms providing subtly different levels of protection than actually required to a complete failure in addressing the actual security requirements of an application. A major cause of this quality divide is the contrary mindset necessary to define security requirements. Due to the nature of application security, security requirements are derived in a fundamentally different manner to functional requirements. Where functional requirements analysis relies on use cases to identify workflows and specific business activities, security requirements analysis employ 'misuse cases' to identify threats and attacks. Functional requirements also stem from business goals, needs or wants, whereas security requirements are primarily derived from actions or outcomes that the business does not want to occur. As a result, the definition of security requirements involves analysis from a completely different perspective and requires detailed knowledge across the spectrum of security threats facing the application. A common error made in developing security requirements is that the author defines actual mechanisms, security designs or implementation details instead of pure requirements of what must be protected. This confusion between security requirements and security mechanisms may inadvertently constrain the use of appropriate security mechanisms as the implementation may have already been defined (potentially incorrectly) by the requirement. A comprehensive set of security requirements will lay the groundwork for the development of a secure application. At minimum, such a set of requirements will need to consider the following aspects of security:

  • Identification
  • Authentication
  • Authorisation
  • Integrity
  • Confidentiality
  • Non-repudiation
  • Accountability
  • Availability

A standard for communicating security requirements is provided in the Common Criteria for Information Technology Security Evaluation, which includes a detailed list of recommendations regarding security requirements as well as other topics such as security assurance and evaluation. Although the majority of software projects will not require security requirements to be documented in such a strict formalised manner, the Common Criteria is a useful resource for analysts in defining the specific security requirements of a project. Further information: Engineering Security Requirements Secure Programming for Linux and Unix Security Requirements Engineering: When Anti-requirements Hit the Fan Common Criteria for Information Technology Security Evaluation

This article is tagged in these categories

Security Architecture, Governance