NZ Coat of Arms Security in the Government Sector
Protect - Detect - React
www.security.govt.nz

Navigation: Home > SIGS > Chapter 8

Chapter 8: Communications and Systems Security Management

Configuration and Incident Management

Configuration Management

Introduction

1. Communications and Systems security management is fundamental to the protection of the Confidentiality, Integrity, Availability, Authenticity, and Non-repudiation characteristics of information. It is also a key element in the implementation of Security Policy.

Certification and Accreditation

2. The formal validation of system security is achieved through a process of certification and accreditation.

3. All systems that handle classified information, or are particularly critical to a department's operation, will require accreditation. The establishment of departmental computer security policy and the conduct of informal system reviews should provide sufficient assurance of security for other systems.

4. Certification of an IT system is the confirmation that it meets all its stated security requirements. The certification process includes the development and maintenance of security documentation. It also involves confirmation by the system developers or administrators that the documentation is correct and complete and that the documented security architectures, mechanisms and processes have been implemented.

5. Accreditation follows on from certification. It is the process of verifying the system's security and formally authorising the system for operation. It involves an independent review of the certification documentation to ensure that the security measures meet the required level of security for the information and services managed by the system. It also involves site inspections to ensure that security has been implemented according to the documentation and appropriately for the environment. Once the verification process is complete, the accreditation authority will use the results to determine whether the system has approval to operate. The accreditation authority for a specific system is ultimately the Chief Executive of the department operating the system. However, the responsibility may be delegated to a member of the department's senior management group.

6. Configuration management or "configuration control" is a set of measures to keep system security, integrity and functionality from degrading when introducing new facilities or eliminating faults.

7. An organisations security plan may not work against new threats or ongoing changes in system configuration. Configuration management is fundamental to the continued strength of system security.

Configuration Control Board

8. Organisations should consider setting up a Configuration Control Board (CCB) to co-ordinate and approve changes to a system's baseline configuration. The CCB should have representatives from the following areas:

Procedures

9. All system changes require configuration management. These may include:

Software Control

10. Take care when changing operational software - seemingly minor changes may have significant, unexpected effects. Be especially careful to isolate "one-off" research-type programmes, which can subvert the system if uncontrolled. Consider controlling:

11. For more on configuration management, see GCSB publication NZSIT 105, Configuration Management.

Incident Management Procedures

System Monitoring

12. Organisations should set procedures to monitor system use, ensuring that users only perform authorised processes. Consider:

13. Accurate computer system clocks ensure the accuracy of audit logs, which may be needed for investigations or as evidence in legal or disciplinary cases. Where a computer or communications device uses a real-time clock, it should be set to an agreed standard such as Co-ordinated Universal Time (UTC) or local standard time. Clocks should be regularly checked and corrected against any variation from the standard.

Intrusion and Misuse Detection

14. Despite appropriate security measures, attacks on systems occur and succeed. Intrusion-detection products are recommended to detect and warn of attacks.

15. Intrusion-detection tools are like virus-detection products in that they must be regularly reviewed and kept up-to-date.

16. Network-based intrusion-detection products can detect a range of suspicious network activity, including:

17. Host-based intrusion-detection tools may also use the audit features of the host operating system to detect suspicious activity, including:

18. Network and host-based intrusion-detection tools may overlap, detecting the same attacks.

19. While intrusion-detection tools will not detect all attacks, and there may be false alarms, they significantly reduce the risk of undetected intrusions.

Intrusion-Response Scenarios

20. When an intrusion-detection tool detects a suspected attack, to prevent further attempts:

Protection against Malicious Software

21. There are many ways to exploit the vulnerability of computer software. The following can make unauthorised changes:

22. Organisations must know about and prevent the introduction of malicious software. Specific procedures might include:

Network Management

23. Access to computers and networks should be closely managed to:

consistently apply security measures across the information-systems infrastructure.

24. Procedural controls to achieve and maintain network security may include:

25. Organisations may need to interconnect or share computers or networks beyond traditional boundaries. The risk of unauthorised access and security breaches is greater for information passed across such networks and their computer systems. Security policies for networks that span organisational boundaries should consider additional controls:

Media Handling and Security

Protecting Storage Media

26. Organisations should develop and use procedures to protect all media, for example tapes, disks and system documentation.

27. Media should be protected against:

28. Classified information on media should be protected from unauthorised disclosure or modification during transport. (See Chapter 3 Annexes A to F).

29. Clearly defined procedures should be used to manage removable computer media, such as tapes and disks.All media should be marked and stored according to the most sensitive or highest-classified information it contains. Apply the handling procedures specified in Chapter 3 Annexes A to F.

30. Appropriately purge surplus media before disposing of or releasing from the department (see paragraph 40).

Labelling

31. Removable media, such as disks and back-up tapes, must be labelled clearly and distinctively, with the security classification on each item that contains material that is SENSITIVE, RESTRICTED or above.

Movement of Media

32. All movements of media in and out of an organisation should be recorded.

33. Media should be checked:

34. Privately owned media should be strictly controlled. As a general rule, private media should not enter systems in government organisations.

35. Organisations that process classified information should have a checking procedure, independent of the originator, to ensure that exported media contains only the information intended.

Back-Up

36. Adequate back-up facilities should be used so that all essential business data and software can be accessed or recovered after an incident. This may include a system failure, virus attacks, or a natural disaster. Back-up for each system should meet the requirements of the organisation's business continuity plan (see Chapter 1 paragraph 16).

Emergency Destruction

37. Organisations should have procedures in place for the emergency destruction of classified or sensitive information held in high-risk environments.

Disposal of Media

Sanitisation and Declassification

38. Sanitisation is the process of erasing as far as possible the information from media or equipment. The process of sanitisation does not automatically change the classification of the media or equipment. Note that sanitisation does not involve destroying the media or equipment.

39. Declassification is the removal of or reduction in the classification of the media or equipment. The decision to declassify should be preceded by an assessment of the risk of improper disclosure of any information remaining on the media or equipment, should declassification take place. In considering risk associated with declassification, it is important to take into account the resale value of the asset(s)(where the value is low it may be preferable to opt for destruction), the destination of any released media (and therefore the likelihood of compromise), the serviceability of the media which may directly relate to the resale value, and any contractual obligations.

40. Considerable information can be retrieved from computing equipment and media that has failed or outlived its purpose. The only totally reliable method of removing all traces of information from memory devices and magnetic media is physical destruction. However, some sanitisation methods can be a reliable alternative, in making the information too expensive to be worth recovering. Approved sanitisation procedures can be used to cleanse a device or media for disposal or reuse.

41. Media or equipment retains the security classification of the highest-classified information it has ever held until appropriately sanitised or declassified.

42. For more on sanitisation, see NZSIT207, Declassification of Storage Media.

Document and Media Destruction

43. Waste material that could contain official information must be disposed of securely, as defined in Chapter 4.

44. Approved ways of disposing of information-systems media, such as magnetic media, include:

45. Reformatting a hard or floppy disk does not necessarily overwrite its data - reformatting is not an approved means of sanitisation.

46. For more on document and media destruction, see NZSIT 207, Declassification of Storage Media.

Security of System Documentation

Protection of System Documentation

47. System documentation may contain a range of sensitive information and should be protected from unauthorised access by:

  1. physically securing it

  2. minimising its distribution

  3. disposing securely when it is superseded.

Security in Software Applications

48. Input data should be vetted in all key business systems.

49. Processing errors or deliberate acts can corrupt data that has been correctly entered into an application system. Systems should have validation checks to detect any such corruption. The specific controls needed depend on the application and the assessed impact of any corruption.

Operating Systems and Package Maintenance

50. All changes to operating systems software must be managed through strong configuration management processes.

51. Changes to original copies of systems software and standard commercial software should be discouraged. If necessary, changes should be made only to a clearly identified copy; the original software should be retained.

Protection of Development Suite and Test Data

52. Development and operational systems should be separated to reduce the risk of accidental changes or unauthorised access to operational software, processes and data. Developmental and operational software should be run in different operating environments.

53. Source code and configuration files should be protected from unauthorised viewing and changing. They should be managed under strict version control, with clear separation between operational and development versions. Source code should not be stored on operational systems, nor should it be freely available to information systems support staff who do not need access.

54. Testing data should be completed before implementation. Test data should be protected and controlled. System and acceptance testing usually requires much test data that mimics live data. The use of live databases containing personal information should be avoided.

Exchanges of Information and Software

Information and Software Exchange Agreements

55. Exchanges of information and software should be based on formal agreements, in line with any relevant legislation and licensing arrangements.

Security of Information in Transit

56. Procedures and standards should be set to protect information in transit, especially electronic data interchanges. One such mechanism is the Secure Electronic Environment (S.E.E.) for inter-governmental communications classified up to SENSITIVE. The State Service Commission's S.E.E. Mail network is an e-mail gateway to gateway encryption system.

Leased Lines and Public Networks

57. Organisations should consider the following security concerns in using leased lines or public networks to communicate between information systems that process classified information:

Internet Security

58. Government networks connected to public networks must be protected by appropriate security measures, even if processing only unclassified information. The main public network, the Internet, has become a widely used business tool; electronic mail (e-mail) and access to the World Wide Web are used more and more for business communications and transactions.

59. The Internet is vulnerable to:

60. Security policies should impose controls and processes to manage business or security risks from the Internet. These risks may include:

61. Where the appropriate security measures are in place, connection to the Internet is permissible for networks handling official information classified up to RESTRICTED or SENSITIVE.

62. Systems that process information classified CONFIDENTIAL or above must not be connected to the Internet unless specific security measures are used such as encryption products and gateways approved by the GCSB.

63. The minimum standards for Internet security in the New Zealand Government are at Annex A to this Chapter.

Telephone Security

64. No telephone conversation is free from the risk of interception:

65. Conversations classified CONFIDENTIAL or above must not be held over a telephone circuit unless it has end-to-end cryptographic protection. Consult the GCSB for advice on appropriate protective measures.

66. All staff should be briefed on the danger of using a telephone for classified conversations.

67. Callers may try to get classified information by falsely representing themselves (social engineering). Staff should be reminded of the need to properly identify all callers before giving any information. Where a caller cannot be satisfactorily identified, they can be asked for a call-back number, which can be authenticated.

68. Security vulnerabilities of telephone systems include monitoring of room audio carried on telephone cables through built-in system features, or deliberate tampering with hardware or software, even when the telephone's handset is "on-hook".

69. For comprehensive advice on security issues related to telephone systems, see GCSB Security Notice 2/97: Telephone Systems (included in NZSIT 109, Information Systems Security Notices).

Cellular Phone Security

70. Cellular phones (cellphones), both digital and analogue, should never be permitted in sensitive areas because:

71. Satellite phones have similar security issues to standard cellphones.

72. For more on the security of cellphones, see GCSB Security Notice 1/99: Cellular Telephones (in NZSIT 109).

Digital Cellphones

73. Digital cellphones (GSM and CDMA) have a lower probability of intercept than analogue cellphones (see paragraph 0). Within New Zealand only, digital cellphones may be used for transmission of information classified IN CONFIDENCE, SENSITIVE or RESTRICTED.

Analogue Cellphones and Cordless Telephones

74. Portable telephones (cellphones) and cordless telephones are generally vulnerable to intercept using inexpensive and readily available radio-scanning receivers.

Personal Electronic Devices

75. Personal Electronic Devices (PEDs) such as Personal Digital Assistants (PDAs) have further vulnerabilities so that potential risks increase from using them in or around areas where classified information may be discussed or processed. Some issues of concern are:

Audio Recording Capabilities: Some PEDs are capable of recording up to six hours of audio. Additionally, microphones may be capable of picking up normal office conversations from a distance in excess of 50 feet.

IR Ports: Data from the IR port of a PED can be intercepted at (or exercised from) significant distances.

76. The following minimum precautions should be observed:

Microphones: Site policies should preclude the introduction of audio recording equipment including PEDs with microphones into controlled spaces.

IR Ports: Any IR Port on a PED should be covered with an IR opaque metallic tape.

Passwords: The use of strong device passwords should be mandated, as the password may be the only mechanism that prevents an attacker from loading malicious code onto a PED.

77. Wireless-enabled personal electronic devices (WPEDs) such as e-mail or web-enabled cellphones, and wireless enabled palm-top computers, have the same set of vulnerabilities as Wireless LANs (WLANs) and must be handled accordingly (see Chapter 9).

78. Further advice on precautions for the use of PEDs is available from the GCSB.

Pagers

79. Information transmitted to a pager can be easily intercepted. Pagers must not be used to transmit classified information.

Answering Services

Care should be taken when using answerphones in offices handling classified information to ensure that classified messages are not left on them.

PABXs

80. PABXs generally have a dial-in facility for remote maintenance. This might allow a person distant from a secure site to gain system access.The remote maintenance facility of PABXs should be disabled.However, if used it should be physically or electronically isolated when not in use.

81. Dial in Subscriber Access (DISA) lines should be carefully managed.

Facsimile Transmission Security

82. Commercial facsimile (fax) systems that transmit and receive information over open communications channels are not secure. They are as vulnerable as telephone systems.

83. Additional security risks come from facsimile units that scan and print. They should not be connected simultaneously to both unclassified and classified systems.

84. For occasional use within New Zealand, facsimile may be used without encryption to transmit information classified IN CONFIDENCE, RESTRICTED or SENSITIVE.

85. For more on facsimile security, see the GCSB's INFOSEC Bulletin Number 21.

Transmission of Video and Video-Conferencing

86. Video-conferencing systems should be protected by encryption systems appropriate to the classification of material transmitted and to the transmission medium. Note that:

Security Requirements of Systems

87. Systems security must consider:

88. Security can depend on how a business process that supports an application or service is designed and implemented.

89. Before developing information systems, organisations should identify and agree on security needs. At the requirements phase of an information systems project, as part of the overall business case, all security needs including fallback arrangements should be:

Security in Application Systems

Evaluated Products

90. Evaluation offers a measure of assurance on the functionality and security features of a product .

91. To properly evaluate a product, the recommended evaluation standard is ISO/IEC 15408, otherwise known as the "Common Criteria" (CC) method. The use of CC:

92. New Zealand jointly manages, with Australia, the Australasian Information Security Evaluation Programme (AISEP). A number of companies are licensed as Australasian Information Security Evaluation Facilities. For more on the AISEP see http://www.aisep.gov.au

93. A mutual-recognition arrangement has been established among a number of countries, including the United States, Canada, Germany, France, the United Kingdom, Australia and New Zealand. Generally, each of the signatories agrees to accept evaluations carried out by another signatory.

94. CC specifies eight levels of security, known as Evaluation Assurance Level (EAL) 0 (lowest level) to EAL7 (highest).

95. For all security applications evaluated products should be used wherever possible.

96. For more on the Common Criteria Organisation, see http://www.commoncriteriaportal.org/.

Protecting Classified Information

97. GCSB should be consulted for advice on the security aspects of design and architecture for systems to be used for processing classified information.

Cryptographic Controls

Appropriate Grades of Encryption

98. For systems with information that requires confidentiality, authentication, integrity and protection in transit or on magnetic media, consider cryptography.

99. Cryptography, or "encryption", is the process of transforming information into an unintelligible form to safeguard its security and integrity. It uses an encryption algorithm and a secret cryptographic key.

10. Cryptography also can ensure:

101. While encryption can be a powerful tool, used carelessly it can:

102. The policy for cryptographic systems and techniques should account for business needs within and between departments.

103. For specialist advice on applying encryption and selecting cryptographic products, consult the GCSB.

104. The following table summarises national policy on encryption:

Security Classification

Grade of Cryptographic System Required

Within New Zealand

Outside New Zealand

TOP SECRET

High Grade [High-grade encryption products are government-furnished and approved for all classifications of information. They can only be procured through the GCSB.]

SECRET

CONFIDENTIAL

High Grade or Enhanced Grade [ Enhanced-grade encryption products have been:

  • evaluated
  • modified from commercial products to incorporate a government-provided encryption algorithm
  • approved for information classified up to CONFIDENTIAL.]

RESTRICTED or SENSITIVE

Encryption Required Across Public Networks

Encryption Required [Encryption products must be evaluated and approved by GCSB to transmit information classified up to SENSITIVE or RESTRICTED.]

IN CONFIDENCE

None Required But Assess Risk

UNCLASSIFIED

None Required

105. Before installing a system that varies from national policy, the government organisation must consult the GCSB.

Key Management

106. Strict rules protect the keys used with cryptographic systems for classified information. To protect Government information, keys must come directly from the GCSB or from a GCSB-approved system.

107. For more on key management, consult the GCSB.

Emanation Security Controls (TEMPEST)

108. The term TEMPEST covers the issue of compromise by electromagnetic emanations from information-processing equipment. Specifically, the emanations might have components that allow classified information to be recovered.

109. Current practice is to counter TEMPEST vulnerabilities following risk management techniques, applying countermeasures as needed.

110. Equipment designed or modified to reduce TEMPEST vulnerabilities is more expensive to purchase, install, and maintain than the original product, and generally not available until much later.

TEMPEST Countermeasures

111. TEMPEST countermeasures are not normally required for installations within New Zealand. However, consult the GCSB about TEMPEST countermeasures for facilities:

112. TEMPEST countermeasures are normally required at overseas New Zealand installations that process information classified CONFIDENTIAL or above.

113. For more on selecting appropriate TEMPEST countermeasures consult the GCSB.

Technical Security (TECSEC)

114. Technical security (TECSEC) is the protection against unauthorised access to official information by accidental or intentional oversight, overhearing or technical attack.

Technical Attack

115. A key defence against technical attack is strict access control. For example, in a room often used for classified conversations:

Inspection Services and Advice

116. The GCSB offers departments a technical security inspection service and specialist advice on TECSEC countermeasures.

Annex A - Minimum Standards for Internet Security in the New Zealand Government

Introduction

Why do we need Internet Security Standards?

1. The Internet is changing the way that citizens, government and business interact and collaborate with each other. Governments around the world, as part of electronic government initiatives, are taking advantage of the opportunities that the Internet provides for improving service delivery to citizens as well as improving the way governments work within their structures and functions.

2. The development of standards for use of the Internet across government will provide citizens with confidence that government systems provide adequate security and privacy safeguards.

About this Document

3. This document defines a set of policies and guidelines for Internet security, limited to the following five broad subjects:

4. The measures outlined in this document define the minimum standards required to provide an acceptable level of security in those subject areas for government systems connecting to the Internet.

5. It is not anticipated that Government sector organisations will tailor their own versions of these documents or produce detailed Statement of Compliance or Specified Departures documents for auditing purposes. However, they should ensure they can justify any departure from these best practices during an audit or following an incident.

6. The technical guidelines referenced here are evolving rapidly due to the progression of the underlying technology and products and the discovery of new vulnerabilities and attack methods on almost a daily basis. For this reason, only references to the recommended guides are provided here. The current version of the specific guidelines should be obtained when and as required.

7. The key words "must" and "should" are used as within Internet RFCs:

High Level Policies

8. The implementation of effective Internet security strategies involves:

9. In regard to Internet-connected systems, agencies must:

Information Security (IS) Management Standards

10. An IS management framework following AS/NZS ISO/IEC 17799 Code of Practice for Information Security Management (available from www.standards.co.nz) must be employed for all systems processing classified (including IN CONFIDENCE) information or hosting Government services. The individual security countermeasures defined in the standard should be considered but are not mandated.

11. IT security risks must be managed following the processes in either:

Internet Gateway Standards

12. All government networks that are attached to the Internet should be connected through a firewall.

13. Those systems that process information classified SENSITIVE or above must use firewalls that have been evaluated through the AISEP or a compatible scheme. They should be evaluated to a level of EAL4 (or ITSEC E3) or higher.

14. A network access policy should be defined and documented, and the firewall should be verified to comply with the policy.

15. CERT Co-ordination Center's Security Improvement Module 8: Deploying Firewalls (www.cert.org/security-improvement/) contains a set of best practices that should be considered when designing a firewall architecture and network access policy.

16. PCs, laptops, etc that are connected directly to the Internet should have personal firewall systems installed or - if possible - the operating system configured to provide equivalent functionality.

17. The addition of a firewall should also be considered when departments connect any two networks together that do not share a common security policy.

18. All security-relevant firewall software patches must be kept up to date.

19. Internet routers must be configured in accordance with RFC2827: Network Ingress Filtering (www.rfc.net/rfc2827.html) to reduce the risk of them being used in denial of service attacks against other sites.

20. Mail servers must be configured to prevent Open Relaying (ie. reject attempts to forward e-mail from non-departmental senders to non-departmental addresses). Guidance is available in RFC2505: Anti-spam Recommendations for SMTP MTAs (www.rfc.net/rfc2505.html).

Internet Server Configuration Standards

21. Internet servers (web, e-mail, news, DNS, etc) must never be located inside government networks without Internet firewall protection between them and computers on the internal network segments. They should preferably be located on De-militarised Zones (DMZ, eg. connected to a third interface on the firewall), so that the server is shielded from the Internet, but where compromise of the server would not result in access to the internal network.

22. Internet servers must be configured in accordance with the following guidelines:

All unnecessary services and networking protocols must be removed or disabled from the operating system.

All unnecessary programs, scripts, code, programme development systems and administrative utilities must be removed from the platform.

Security-relevant patches must be kept up to date.

One of the following guideline documents should be consulted for appropriate configuration of the server operating system:

SANS Step By Step operating system configuration guidelines (https://store.sans.org/); or

NSA Securing Windows 2000 (http://www.nsa.gov/snac/); or

Centre for Internet Security provides best practice benchmarks for configuring Solaris, Linux, or Windows 2000 systems (http://www.cisecurity.org).

23. System administrators should keep up with the SANS/FBI Top 20 Internet Security Vulnerabilities (www.sans.org/top20.htm) and manage the risks accordingly.

24. Administration of the system should be restricted to local access only or require strong authentication, refer to NZSIT 204, Authentication Services and Mechanisms (http://www.gcsb.govt.nz/nzsit/index.htm

Malware Protection Standards

25. All computers used for Government business with any communications to external systems (Internet, dial-in, CD access, etc) must operate appropriate anti-virus software.

26. Networks that process information classified SENSITIVE or higher, or that contain critical systems, must take particular care when permitting active code (eg. Java, ActiveX) to be run from untrusted sites on the Internet (e.g. other than *.govt.nz and trusted partners) or other uncontrolled networks. Agencies must put in place mechanisms to mitigate the risks and should consider completely disabling such functions from their computers.

27. Agencies should consider rejecting Internet cookies and script and macro languages if they are not required for business processes.

28. Most Internet browsers have the capability to add application extensions to the basic functionality (eg. when a .doc file is encountered Microsoft Word is activated to view the document). Many such extensions or plug-ins can be exploited to run malicious code on the browser computer, so qualified security staff must approve any application extensions before they are included in user Web browsers.

29. Users must be made aware of the potential risks inherent with opening or running attachments and executable content that has arrived unsolicited or originates from an untrusted source.

30. For more information on malicious software refer to NZSIT 208 : Dealing with Malicious Software.

Incident Detection and Handling

31. IT system security is never infallible, so measures must be in place to detect and react to system failure, misuse and unauthorised access. The exact nature of the detection systems and response processes will depend on the type of system and an assessment of the potential threats and impacts.

32. For systems processing Government information or hosting Government services, security-relevant events such as failed access attempts, security configuration changes, and changes to the user account database should be logged to another system.

33. File integrity checking systems should be considered to monitor critical files on such systems, and any connections with other networks should be monitored for intrusion attempts.

34. Procedures must be employed to monitor and react to the outputs and alerts generated by intrusion or misuse systems in a timely and appropriate manner.

35. The security configuration of each Internet connected system should be audited periodically to ensure it has not been inadvertently misconfigured or tampered with.

36. The SANS Incident Handling Step By Step Survival Guide (from https://store.sans.org/) provides an excellent basis for development of incident handling procedures.

37. Guidance on intrusion detection is available from the CERT Co-ordination Center in the form of Security Improvement Module 9: Detecting Signs of Intrusion, and Module 6: Responding to Intrusions (www.cert.org/security-improvement/).

Summarised List of Internet Security Standards

Function

Standard or System

Purpose

Status

Management

AS/NZS 17799

Information Security Management

Mandated

or

NZSIT 104

AS/NZS4360 plus HB231

Risk Analysis

Risk Management

Mandated

Internet Gateways

CERT/CC: Security Improvement Module 8

Best Practices for designing firewall architecture

Guidance
 

RFC2827

Router configuration

Mandated
 

RFC2505

Mail server configuration

Guidance

Internet Server Configuration

SANS: Step by Step

Operating System Configuration Guidelines

Guidance

or

NSA: Windows 2000 Security Recommendation Guides

Windows 2000 Configuration Guidelines

Guidance

or

Centre for Internet Security Solaris Benchmark

Security configuration guidance for hardening Linux, Solaris and Win NT operating systems

Guidance
 

NZSIT 204

System administration restrictions

Guidance

Malware Protection

NZSIT 208

Dealing with Malicious Software

Guidance

Incident Detection and Handling

SANS: Incident Handling Step-by-Step Survival Guide

Development of Incident Handling Procedures

Guidance

or

CERT/CC: Security Improvement Module 9

CERT/CC: Security Improvement Module 6

Guidance on Intrusion Detection

Responding to Intrusions

Guidance

[ Previous | Next ]

Top of pageHome | Search | Sitemap | About | IMPORTANT Notice

Comments, problems with the site?  Please report them to: security@dpmc.govt.nz 

Last Updated: 03-Nov-2004 10:50:35 a.m.