Intelligence Sub Menu:
Benefits by Industry:
Key Interest Areas:
Information For:
SIFT Training Schedule
 SIFT is an "Australian Government Endorsed Supplier" of information security and information risk management services.
|
SIFT Note Library
SIFT Note 2007-01 - 24 Jan 07
Software 'Bugs' – The Need For Root-Cause Analysis
Creating functional and successful software products is itself a significant achievement. To further complicate this task, the market is increasingly placing additional demands on the security of all software products. An example of this trend is Microsoft’s Trusted Computing Initiative and the overall drive towards a more secure platform.
Software developers are now seen as having a responsibility to react in a timely manner when security flaws are uncovered. One aspect of acting responsibly with regards to security has been highlighted by recent vulnerabilities in Oracle software. A vulnerability was reported to Oracle by security researcher David Litchfield. Oracle eventually collaborated with Litchfield to fix the flaw and a patch was released.
Days later a so called ‘0-day’ exploit was posted to the SecurityFocus public vulnerability disclosure mailing list Bugtraq. The published code exploited an identical flaw in a related component of software that was not fixed by the patch released by Oracle. Hence, Oracle customers were left exposed to a critical vulnerability for which there was no official workaround. Such a scenario is not uncommon in the industry today.
As a responsible vendor, what should an organisation do once it has fixed a vulnerability in a software product?
Given a vulnerability in any software product, whether internal, commercial-off-the-shelf (COTS) or outsourced, the first action taken by the developer post-fix should be to conduct a root-cause analysis. A number of questions should be answered by this analysis:
- What caused the vulnerability?
- Is the flaw specific to a function within the application or is it broader?
- Does the vulnerability fit into a ‘class’ of flaw?
- What characteristics define its presence?
- How could it have been avoided?
Once answers to these questions are known, processes can be developed and deployed to identify similar flaws. Such processes can be automated or manual but must be repeatable. Once a test type is identified it is recommended it be executed on a regular basis, including prior to every release to ensure such flaws are never reintroduced. Testing for previous flaws is commonly known as regression testing.
Furthermore, findings of the analysis can be integrated into the development and design phases in the form of coding and design standards. Catching bugs earlier in the software lifecycle will ultimately save resources that are better applied elsewhere.
It is apparent that software security is not a linear process and cannot be restricted to reactive patching tactics. Rather, vendors should seek to proactively improve quality and decrease spending by applying experience gained in creating the initial “fix” to resolve similar problems that may be present throughout a product. While brand perception is unlikely to be significantly damaged by a single vulnerability, repeating the same mistakes may have significant consequences to the company’s reputation.
Further information:
Re: Recent Oracle exploit is _actually_ an 0day with no patch
BCM: The Importance of 'Horizontal' Co-operation
Management and staff buy-in has become the mantra of contemporary organisations when implementing change. Management buy-in is obviously required to achieve the necessary funding of a change initiative and also to drive the change by ensuring it is a significant priority. Staff buy-in is required to turn the strategic level objectives into physical and visible practices. Achieving buy-in from both groups is often difficult for change agents to negotiate and manage.
The implementation of an IT Business Continuity Management (BCM) programme is faced with similar challenges. In order to achieve their objectives, business continuity and IT managers are required to take a whole-of-organisation approach, and this approach needs the support of executive management and staff. In particular, they must seek the support of peers in other business units (such as production or accounting and finance) in order to promote the acceptance of IT BCM strategies by all levels of the organisation.
Using the valuable experience gained in many organisations, strategies have been developed that will help to ensure the success of any BCP programme.
Best practice organisations often develop a working group, a separate business unit or an umbrella body to encompass the BCM function. Regardless of structural configuration, the BCM leadership needs to be, as far as possible, unaffected by the influence of other business units and reporting directly to the CEO helps to achieve this. The need to understand organisational politics should always be considered. In addition to a requirement for vertical co-operation of executive management and operational staff, there is the distinct need to garner horizontal support from leaders of individual business units.
Any BCM implementation can draw lessons from John Kotter’s best practice principles for organisational change. In Kotter’s model, the key to successful change is the development of a coalition of influential change agents with representation from the entire organisation. By eliciting support from these “peers”, organisational BCM efforts not only guarantee a more speedy adoption from operational staff, but also help to ensure that important matters are brought to the attention of and addressed by senior management sooner.
The HR department usually has expertise in developing strategies for empowering people for change, as well as the resources to manage individual roles and responsibilities within IT BCM scenarios. By encouraging HR departments to include BCM responsibilities within job descriptions and incorporate the necessary BCM training into the staff induction process, a BCM-aware culture can result.
The buy-in of the finance department is critical to addressing the financial arrangements required for the BCM programme, and IT is critical for aligning business requirements to the technical requirements, facilitating improved resilience. By seeking the opinions of these business unit leaders early, BCM managers are able to work with a more functionally acceptable set of assumptions.
Divergent political views often create the biggest impediment to achieving successful change in organisations. In order to help organisations to develop a robust IT BCM capability, the buy in of key business units is pivotal to the speed at which the process evolves. As IT and HR already retain an enterprise view, their expertise is particularly useful in the pursuit of whole-of-organisation IT BCM. So next time an urgent IT BCM matter must be addressed, instead of approaching the CEO right away, it may be more efficient to first approach the HR director or the CFO and get them onside from the outset.
Further information:
Reframing Organisations – Artistry, Choice and Leadership, L. G, Bolman and T. E, Deal
NIST Log Management Guide: A Synopsis
The lack of practical guidance on log management has driven the US National Institute of Standards and Technology (NIST) to develop the Guide to Computer Security Log Management. Targeted towards administrators, security teams, and those responsible for logging related duties, it is designed to assist organisations in understanding and effectively managing real-world logging infrastructure.
The security need for log management is driven partly as a ‘detection’ mechanism on the assumption that at some point protection mechanisms will fail; and partly as a ‘black box’ with which to reconstruct events after the fact. Routine inspection and analysis of logs will help identify incidents, policy violations, fraudulent activity, operational problems and assist in forensic activities. The challenge faced by management in this area is that logs are delivered in many different formats and are generated by a vast number of sources.
To address these and other log management issues, NIST makes the following recommendations:
- Establish policies and procedures for log management
- Prioritise log management appropriately throughout the organisation
- Create and maintain a secure log management infrastructure
- Provide appropriate support for all staff with log management responsibilities
- Establish standard log management processes for system-level administrators
Log Management Infrastructure
A log management infrastructure must typically perform a number of core functions such as log parsing, analysis, archiving, and integrity checking. NIST suggests a three tier architecture with a separate logging network as the most suitable approach:
- Tier 1 - Log generation
- Tier 2 - Centralised log consolidation and storage
- Tier 3 - Centralised log monitoring
Two leading industry standard approaches exist for log management software; Syslog and Security Event Management software (SEM). While Syslog is the de-facto standard, it was conceived with functional rather than security goals in mind and may require customisation to achieve the necessary security objectives.
Organisation-Level Log Management Processes
While setup of logging infrastructure lays the initial ground work; well defined management processes are required for continued success. These include:
- Definition of roles and responsibilities
- Creation of feasible logging policies
- Division of responsibilities between system level and organisation level administrators
- Ongoing analysis of log data
- Regular audits of log management activities
Policies can then be put in place for log generation, transmission, storage, disposal and analysis. It should be noted that these must conform to organisational information classification and data handling policies. Passive and active testing may be used to validate these processes.
System-Level Log Management Procedures
The Log Management guide also recommends system and network administrators be given appropriate guidance on:
- Configuring the log sources including log generation, storage and security
- Providing ongoing support for logging operations
- Performing analysis of log data
- Initiating appropriate responses to identified events
- Managing the long-term storage of log data
Finally, a number of practical recommendations are provided for enhancing log handling activities:
- Limit access to log files
- Avoid recording unnecessary sensitive data
- Protect archived log files
- Secure the processes that generate the log entries
- Configure log sources to behave appropriately under error conditions
- Secure the transport of log data
As many organisations continue to have logs collecting without being subject to any analysis, aggregation or review, the NIST Log Management Guide is a timely support for organisations to extract value from the data they are already collecting.
Further information:
NIST Special Publication 800-92: Guide to Computer Security Log Management
Top
|
|
SIFT Team Delivering 3 Presentations at Ruxcon!
21 Nov 08
The Ruxcon information security conference is once again being held in Sydney on the 29th to the 30th of November. The not-for-profit conference is regarded throughout Australia and the world as one of the leading information security research events.
more...
SIFT in 2008 BRW Fast 100
20 Nov 08
In the second half of 2008, SIFT was recognised for our rapid and consistent growth through inclusion in the 2008 BRW Fast 100.
more...
|
