Last updated: 10 Feb 2004
Quote HB321 Preface piii: "The vulnerability of today's information society is still not sufficiently realised: Businesses, administrations and society depend to a high degree on the efficiency and security of modern information technology. In the business community, for example, most of the monetary transactions are administered by computers in the form of deposit money. Electronic commerce depends on safe systems for money transactions in computer networks. A company's entire production frequently depends on the functioning of its data-processing system. Many businesses store their most valuable company secrets electronically. Marine, air, and space control systems, as well as medical supervision, rely to a great extent on modern computer systems. Computers and the Internet also play an increasing role in the education and leisure of minors. International computer networks are the nerves of the economy, the public sector and society. The security of these computer and communication systems is therefore of essential importance. European Commission 1998"
Quote - ACSI33 Ch3 301: "Risk management is a methodology for
comprehensively and systematically managing risks in an organisation.
Risk management provides a framework to help keep obstacles,
opportunities and ultimate goals clearly in sight."
Hence the purpose of "Risk Management" is to reduce likelihood of
asset compromise.
Points noted are taken from SA HB321 section 3 Intro p7.
Quote above from OLD ACSI33 HB3 301.
Standards exist to provide guidance as to best practice. But Information Security standards use is still not high. The most cited standards were the International standard 17799 and AS/NZS 7799.2:2003. Also cited were the DSD standard ACSI33, Standards Australia supplement HB 231 to AS/NZS 4444, and the Internet RFC 2196. These are all good sources which organisation should use. Note - the various Australian & International standards are ONLY available for purchase, and are not free online.
This is the new(ish) International standard for IT security management,
subsuming the earlier national standards. cf to ISO9000.
Originally created by British govt, publ in Feb 1995, but other concerns
(eg Millenium bug) meant not much attention initially. Revised May99,
incl formal accreditation scheme and support tools, led to greater interest.
Hence is now a key resource for anyone concerned with information security.
To quote from its section 1 - Scope:
"This standard gives recommendations for information security management
for use by those who are responsible for initiating, implementing or
maintaining security in their organization. It is intended to provide
a common basis for developing organizational security standards and
effective security management practice and to provide confidence in
inter-organizational dealings. Recommendations from this standard should
be selected and used in accordance with applicable laws and regulations."
nb. this standard like most official standard publications is not freely
available, but must be purchased (follow links in refs below). Any
organisation serious about IT security ought to buy this standard and
associated handbooks such as HB231.
Here is the list of major sections in 17799, taken from its Contents table.
Quote AS7799.2 1. Scope: "This standard specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented ISMS within the context of the organizations overall business risks. It specifies requirements for the implementation of security controls customized to the needs of individual organizations or parts thereof (see Annex B which provides informative guidance on the use of this standard). The ISMS is designed to ensure adequate and proportionate security controls that adequately protect information assets and give confidence to customers and other interested parties."
Quote: 1 - Scope:
"This Standard provides a generic guide for the establishment and
implementation of the risk management process involving establishing
the context and the identification, analysis, evaluation, treatment,
communication and ongoing monitoring of risks."
Quote: 2 - Application:
"Risk management is the term applied to a logical and systematic
method of establishing the context, identifying, analyzing, evaluating,
treating, monitoring and communicating risks associated with any
activity, function or process in a way that will enable organizations
to minimize losses and maximize opportunities."
HB231 contains some more specific guidance about the information security risk management process for the majority of organisations. It is referenced by ACSI33 which we'll be using, as well as providing a more general form of guidance for non-govt/defence organisations. Was originally a supplement to AS/NZS 4444.1/2, recent errata has changed all references to the replacement AS/NZS ISO/IEC 17799 and AS/NZS 7799.2.
ACSI33 is a key standard on Government IT Security. Compliance with it is mandatory for many government activities, and for everyone else it provides a useful guide of issues to consider. Note that ACSI33 is undergoing a major revision, due for release at the Security In Government (SIG) Conference in Mar 2004, which aligns it more closely with the standards listed above, as well as AG's Protective Security Manual.
Here compare the risk assessment frameworks from AS4360 and AS7799.2. The above points for AS4360 are taken from HB321 Fig 3.2 p9. This is the general framework which is then refined and specialised in IT specific risk management, as detailed in ISO17799 et al. Contrast with the framework in AS7799.2 (cf HB231 Table 3.1).
Now consider the risk assessment process as detailed in the Final Draft of ACSI 33 Part 3 Ch 3 (nb. section numbers may change between this and final released version).
Determining assets, both tangible and intangible, for an organisation is the first critical step in the risk analysis process. An asset is anything an organisation can attach a value to, and hence requires protection. Determining what constitutes an asset, assigning a value to it, and determining who "owns" it, is something that has to be done with the people in the organisation.
Examples from HB321 section 3.4.1 p12: info assets, paper docs, software assets, physical assets (incl h/w), marketing assets, services. Note that HB231 4.1.6.1 Structured identification of information assets provides a longer list of possible asset categories.
Here discuss the process of identifying risks/threats (note both terms used in different places). Definitions from HB231 3.4.
HB231 4.2 provides lists of tools and techniques which can help. Information on likelihood of these various types of threats is something a good IT risk analyst needs to bring in. Would use published sources of information, such as the AusCERT Computer crime surveys, (Aus)CERT advisories and lists of known problems, SANS Top 20 lists, plus interviews with people in org/industry on their experiences, esp wrt insider problems. See also HB231 App B which has a list of vulnerabilities to consider.
This list taken from ACSI33 P3-323.
| If the consequences would | Then an appropriate consequence rating is |
|---|---|
| threaten the survival of not only the program but also the agency, possibly causing major problems for clients and for a large part of the Australian Public Service | extreme |
| threaten the survival or continued effective function of the program or project and require top level management or ministerial intervention | very high |
| not threaten the program but would mean that the program could be subject to significant review or changed ways of operating | medium |
| threaten the efficiency or effectiveness of some aspect of the program but would be dealt with internally | low |
This table from ACSI33 P3-325 is based on ratings in AG PSM.
Harm estimation needs to be done in conjunction with the asset owners.
Need to emphasise that are considering the harm to the organisation as
a whole, as a consequence of the threat to an asset being realised.
Historically there seems to be a tendency to overestimate
harm values in the context of the wider organisation and the effect on it,
so care is needed to assume realistic values!
| If a risk | Then an appropriate likelihood rating is |
|---|---|
| is expected to occur in most circumstances | almost certain |
| will probably occur in most circumstances | likely |
| might occur at some time and may be difficult to control due to some external influences | possible |
| could occur some time | unlikely |
| may occur only in exceptional circumstances | rare |
This table from ACSI33 P3-327 is based on ratings in AG PSM.
Note that the threat likelihood estimation is a measure of
the likelihood of a real exploit of an identified vulnerability
(being the specific threat in this row of the table), which causes
actual harm to the specific asset identified. Emphasise that
historically there seems to be a tendency to overestimate,
and care is needed to assume realistic values!
| Likelihood | Consequences | ||||
|---|---|---|---|---|---|
| Extreme | Very high | Medium | Low | Negligible | |
| Almost certain | H | H | H | S | M |
| Likely | H | H | S | S | M |
| Possible | H | H | S | M | L |
| Unlikely | H | S | M | L | L |
| Rare | S | S | M | L | L |
This table from ACSI33 P3-331 combines the threat likelihood and consequence to determine the overall risk rating of a specific threat.
| High | requiring detailed research and management planning at an executive level |
|---|---|
| Significant | requiring senior management attention |
| Moderate | manageable by specific monitoring or response procedures |
| Low | manageable through routine procedures |
This detail the values in the table above, taken from ACSI33 P3-330
Now determine risk management priorities in order to determine where effort needs to be focused.
Now need to determine an appropriate cost-effective response to unacceptable risks. This may mean redirecting resources to where most needed, changing aspects of system, or even accepting a higher level of risk because its not worth paying more to reduce it.
Above points are taken from HB321 section 4.5.3.1.
Here excerpt from the example provided inline in the ACSI33 Part 3 Ch 3 TRA Template - early draft, final version not yet on DSD web site. nb. provided own Risk Rating values since none were supplied ;-)