A 24x7x365 Secure
Government Internet (Portal) Infrastructure
Gavin Longmuir
gavin@longmuir.net
7 October 2001
Information Warfare: it’s a topic that is coined in the media with
greater and greater regularity. It immediately raises images of highly trained
hackers or operators with computers and artificial intelligences doing battle
over our major infrastructure systems.
Recorded history can show that targets in any conflict will not always
be of any direct military significance, and are more demoralising for the
populus in their nature. The hysteria generated from possible destruction
relating to the y2k bug can give a brief insight on how dependent the populus
perceives itself to have become. There is sufficient human involvement in most
infrastructure control processes, that physical attack is more likely to
disrupt critical infrastructure than a logical attack. This has been evidenced
by the 11 September 2001 terrorism attacks in the USA.
The most notable hacker events of today are website defacements, the
publication of private or personal information, and denial of service attacks.
This form of activism (or ‘hacktivism’[1]) is now becoming the most
predominate characteristic of Information Warfare. The OECD Guidelines for the
Security of Information Systems[2] state the following:
The objective
of security of information systems is the protection of the interests of those
relying on the information systems from harm resulting from failure of:
- availability
-
confidentiality, and
- integrity
Where:
"availability"
means the characteristic of data, information and information systems being
accessible and usable on a timely basis in the required manner;
"confidentiality"
means the characteristic of data and information being disclosed only to
authorised persons, entities and processes at authorised times and in the
authorised manner;
"integrity"
means the characteristic of data and information being accurate and complete
and the preservation of accuracy and completeness.
A 24x7x365 Secure Government Internet (Portal) Infrastructure, needs to
be able to deliver High Availability (Reliability of Services), Confidentiality
and Privacy, and Integrity of Service (the Information).
This paper will focus on availability issues associated with designing
and managing an Internet provided portal for Government, but will briefly
discuss portal integrity. The integrity of information provided by agencies to
be published the portal site by webmasters, particularly out-sourced
publishers, will not be covered here. While the censorship of content by
external parties is an availability issue it is beyond the scope of this paper.
Also confidentiality issues are not approached here, questions that should be
addressed in relation to personal information/data are protection against loss,
unauthorised access and usage, modification and disclosure.
A secure highly available Government Internet portal needs to not only
ensure availably of the resources but to ensure the integrity of the resources
and prevent opportunities for malicious misuse of the resource.
There are various threats to providing a 24x7x365 Internet Service.
Physical threats can include: Earthquake, Flooding, Lighting, Power Failure,
Fire, and Theft. Some logical threats are: Maintenance Errors, Software
Failures, Unauthorised Usage, Malicious Usage, Graffiti, and Overloading of CPU
or Network Resources. Some are visual and easily noticed (availability), while
others could remain unnoticed and can effect confidence (integrity) of the site.
Firstly this paper will address availability issues, followed by brief
look at integrity issues for the portal. The proposed portal is for Australian
Government usage and thus will meet current Australian Government IT security
guidelines from the National Office for the Information Economy
(NOIE)[3] 7, Attorney-General’s Department[4], and the Defence
Signals Directorate (DSD)[5]
[6] [7]. Lastly a Threat Risk Assessment
(TRA) for the portal environment will be performed and counter-measures
proposed to manage the resultant risk.
Building a Security High
Availability Environment
If the portal is to carry information which one day could be considered
as vital as the emergency telephone ‘000’ service, then service downtime is
going to be important.
Some defensive mechanisms[8]
that are to be used to ensure high available in the portal environment against
an assailant or any other crisis related events are:
-
preventative (by usage of secure systems and locations)
-
deterrence (by legalisation, alarms and forensics)
-
detection, indications and warnings (by IDS monitoring, CERT alerts)
-
responsive, and emergency preparedness (by containment, recovery)
Physical Security –
Computer Rooms
An antagonist could steal equipment, which could mean more than just the
lost of a physical asset but the lost of the even more valuable information
contained within the equipment. This could range from classified personal data,
to configuration information of the portal, to portal statistical/log
information. Also this opponent could by an act of sabotage or perhaps a chance
event like a lighting strike could destroy or severely cripple equipment.
The DSD’s Gateway Certification Guide6
and Australian Communications-Electronic Security Instructions 33 (ASCI 33)5
handbook 14 deal with physical security for computer rooms and workstations,
which were developed with involvement from Australian Security Intelligence
Organisation’s (ASIO) T4 Protective Security Group. The portal environment will
be contained within sited computer rooms. Four security standards are defined
for computer rooms labelled CR1 to CR4, with CR1 being the highest. Only the
CR4 standard is unclassified and publicly available, the others are available
to suitable agencies on request.
These standards include access control measures, such as physical
barriers, alarm systems, secure storage containers, use of endorsed locks and
other equipment, physical design of room, and a UPS system to supply a minimal
number of hours of onsite operation. A Security Equipment Catalogue of endorsed
and approved items is also available from ASIO T4.
The resulting standard required will depend on the security
classification of information/data within the portal and how publicly
accessible is the portal’s location(s). The Protective Security Manual4 Part E ‘Physical Security’
states that an agency security advisor should contact ASIO for a threat assessment
if physical threats are deemed to require such. It also states that certification
of the intruder alarm system must be undertaken by ASIO’s T4.
Environmental conditions will be examined for any of the portal’s
possible locations, such as not placing the computer room against external
walls, and ensuring that physical access points including items such as air
ducts and roof/floor titles are secured. All perimeter entry points will be
augmented in such a manner that entry is only via an authorised ‘key’ or if
unauthorised access has been gained it results in evident visible damage.
Firewalls
Logical network access controls are implemented within the environment
to monitor incoming and outgoing network packets between network segments, they
determine whether these packets should be allowed to enter or leave network
segments. Policies on allowable traffic flows can be based on packet header
information (such as source IP address, destination IP address, IP protocol,
and service/port number), or deeper into the protocol stack (via application or
security proxies) to perform a greater number of checks or service restriction
or even content filtering. These gateways or firewalls can also provide access
based on user authentication or during authorised time periods. Firewalls can
also act as an end-point to an encrypted VPN.
Firewalls are implemented at control or security enforcing points of the
network. Their objective is to provide controlled access between networking
environments or security domains. Typically a firewall is used to protect
internal trusted systems and servers from the external untrusted environment,
to keep intruders and malicious code out, and to keep sensitive information
inside.
These security-enforcing devices have verbose logging and reporting
apparatus. It is also envisaged that all devices within the portal environment
have logical access controls via userid and password (or similar) procedures.
The use of VPNs with the portal will not be undertaken as the security
domain is effectively extended to other systems and networks. These systems and
networks are most likely not under the same level of security.
Intrusion and Misuse
Detection
With the usage of access control points (firewalls) and network and host
based intrusion detection systems (NIDS and HIDS), current and past activity
are to be monitored. With knowledge of the normal operations of the
environment, any unusually or damaging events can be prevented before damage
occurs or at least alert staff to vulnerabilities that could exist. The usage
of these logs will provide legal forensic evidence for any prosecution of
intruder or staff exploitations of the portal.
NIDS and HIDS detection is based on expert understandings of ‘patterns’
associated with typical activity and exploit usage. These patterns are
signature based and can be likened the to apparatuses that allow virus
detectors work. They also have the same failings of be being limited to how
fresh the signatures in use are. Most NIDS systems will allow manual pattern
creation, but how many experts are on staff?
While HIDS detection is limited to a singular system perspective it
doesn’t entirely rely on a signature database, but on low-level system
activity. Additional
resources are monitored such as file ownership, permissions, and checksums,
system sockets, processes, logs, and audit logs. Placement of the NIDS would be
in key points of the network. HIDS would be placed on critical systems within
the portal. The greater number of sensors the better, not only to detect the
success or failure of an attacking event, but to also detect misconfiguration
of the environment or the effects of malicious software.
While anomaly detection software exists, development and operations
staff are able over time to profile the normal operations of services within
the portal environment. This can be assisted by the use of manual or automated
correlation between the distributed monitoring foundation of NIDS, HIDS,
firewall logs, and even raw router statistics.
Like virus checkers, reliance on a single vendor or open source product
doesn’t give you 100% coverage. IDS systems cannot observe all possible events.
Placement of the IDS is critical, the event could occur on a non-monitored
network, the IDS itself could be non-functional or under DoS attack itself. The
IDS may not understand the protocol in use and is unable see encrypted traffic.
A more basic issue would be exceeding its maximum event bandwidth limit[9].
SSL and Intrusion
Detection
Encrypted protocols are also blind spots for NIDS (typical examples
include SSL and IPSec). The use of HIDS on the end points of such tunnels is
essential. Alternatively a dedicated load-sharing device (with optional
hardware accelerator) could terminate the tunnel and redirected the now
unencrypted traffic to the web farm, all under a NIDS view.
Vulnerability Monitoring
Network and host vulnerability monitoring of the portal will be done to
ensure that the security enforcing functions are correctly configured. These
assessment tools check for vulnerabilities by mimicking hacker activity. This
should be done after every major configuration change and at ‘constant
irregular periods’, to ensure that the scanned environment remains consistent.
Automating a scan for 6 am every second day, can allow others to take advantage
of the noisy logging environment and be obscured from normal view. These
scanners also need to be updated consistently as new vulnerabilities are
discovered.
Vulnerability checking also extends to the physical world. Such as
checks on building access points, filing of documentation, vetting of staff,
and general staff training and security awareness.
Security Awareness and
Training
It should be noted that physical and logical security mechanisms fail
sooner if they are implemented in an undemanding way or are supported by
inadequately trained staff. Staff must understand their responsibilities for
security and why it is enforced4. Operations staff will also have an understanding the
security enforcing functions of the environment along with the functionality of
devices within the portal. Simply reading a vendor manual and using to it
provide a security schema is not sufficient[10].
Building It Secure –
Evaluated Products
DSD’s ACSI 335 and the Gateway Certification Guide6 outline a methodology to protecting information
assets from unauthorised access. Building a secure environment requires the use
of evaluated or trusted systems. An evaluated system has sufficient security
and integrity measures in place to ensure that information assets are
protected. For a system to be successfully evaluated a number of criteria are
used to test the functionality of the system. These criteria describe, the
strength of the security system, the security features provided, confidence in
system design, and confidence in systems implementation.
DSD has a list of evaluated products that agencies can use with
confidence; this list of called the Evaluated Products List (EPL), and publicly
availability. Where possible devices within the portal environment will be
sourced from entries on this list.
Avoiding Single Points of
Failure
A basic availability mantra is to avoid single points of failure. An
obvious answer is to provide multiple geographic separate sites containing
cluster servers, with multiple Internet carrier connections. The solution also
has to be scalable, reliable, and secure. Time to prove that security is not an
obstacle to availability.
Traffic load balancing or management tools[11]
have been around for some time. It is well known that no single computer is big
enough to service a popular web service (or at least it’s peak loads). By using
clustering or load balancing horizontal scalability is cheaply provided as well
as providing for individual system failures. Failover/High availability
functions are now available in most networking devices (including firewalls).
Increasing the number of servers that traffic is redirected to, will also
increase the service availability. Content replication between the servers is
managed by other mechanisms (and is possibility an integrity issue).
Use of multiple sites gives confidence in minimising the impact of
disasters or site outages on the service. Distribution of traffic to multiple
sites can be as basic as DNS round-robin rotation, or user selected DNS domain
in alternative top-level domains, to complicated distribution algorithms based
on geographical localisation, site load, and traffic bandwidth costs. Bandwidth
costs also have to be considered when looking at replication between sites.
Calculating Availability
The replication of components within the proposed portal environment
increases availability. Any single point of failure within the portal environment
reduces the entire availability of the portal. Most manufactures provide
availability information on their devices. The availability of a device can be
calculated by measuring the mean time to failure and mean time to restore. The
mean time to restore also includes detection, analysis, and repair of the
problem.
Table 1: Number of 9’s; Uptime and Downtime[12]
|
Number of Nines |
Availability Percentage |
Minutes of
Uptime per Year |
Minutes of
Downtime per Year |
Annual Downtime |
|
1 |
90 |
473,364 |
52,596 |
36.5 days |
|
2 |
99 |
520,700.4 |
5,259.6 |
3.5 days |
|
3 |
99.9 |
525,434.0 |
525.96 |
8.5 hours |
|
4 |
99.99 |
525,907.4 |
52.596 |
1 hour |
|
5 |
99.999 |
525,954.7 |
5.2596 |
5 minutes |
|
6 |
99.9999 |
525,959.5 |
0.52596 |
32 seconds |
|
7 |
99.99999 |
525,959.9 |
0.052596 |
3.1 seconds |
# - Based on 365.25 days in a year
Equation 1: Calculation for Serial Availability12
Given a single firewall with availability of 99% (3.5 days annual
downtime), protecting a single server with availability of 99%, will give an
end-to-end availability of 98.01% (7.2 days annual downtime).
Equation 2: Calculation for Parallel Availability12
Thus given a single server has a availability of 99%, introducing a
second parallel server with identical configuration (neglecting replication
availability), will give 99.99% availability (1 hour annual downtime).
Diagram 1: The Basic
Portal Design, showing Duplication Regions
Providing availability in the portal environment with traffic management
devices will require the introduction of this equipment at every opportunity.
At the border (most likely implemented as multiple routers to multiple
carriers), before and after gateways (routers and/or firewalls), in front of
the web server ‘farm’, and between any data backend (local or remote) if
required.
Please refer to Diagram 1 on page 9, the basic portal design, with
duplication of all devices apart from the traffic management device. Assume all
components in the basic portal design have 99% availability and both Internet
carriers also have 99% availability, then the basic portal availability can be
calculated as 97.98% (7.3 days annual downtime). Thus when introducing these traffic management devices within the portal environment
another single point of failure is introduced, therefore they must have their
own standby-redundant fail-over mechanisms. Appliance based devices are
preferred over software clusters for this reason. The portal availability when
redundant management devices are used is 99.95% (4.4 hours annual downtime).
All other references to traffic management devices within the portal
environment assume that they are deployed as a redundant pair.
Another imperative issue is to ensure that each of the redundant devices
has to have no more than 50% of the total network load should one of the other
devices fail. Failure of one device shouldn’t fail the other due to
overloading.
To increase the availability of the portal beyond these assumed values
is not likely due to the serial connecting nature of control access devices
such as firewalls. Adding a second site would increase the portal availability
to 99.99998% (6.3 seconds annual downtime).
Remember this is all based on the assumption that all devices within the
environment have 99% availability (3.5 days annual downtime), and that all
network management devices are redundant and thus have 99.99% availability.
What if the database backend for dynamic data has low availability, or
the service application is very buggy; lets assume availability of 90% (36.5
days annual downtime)? A single portal site would have 89.96% availability
(36.7 days annual downtime) for that service, and two sites would have an
availability of 98.99% availability (3.7 days annual downtime). The
introduction of a third portal would give 99.90% availability (8.5 hours annual
downtime).
Load-balancing Firewalls
Depending on the level of ‘filtering’ enforced by the firewall, it could
be seen as a traffic bottleneck. A load-balancing feature has been introduced
into many of the commercial firewalls on the market. These load balancers come
in some basic permutations[13]
– those that use synchronous or asynchronous in state (or connection table)
updates, and either software based or hardware based implementations. Software
implementation doesn’t scale to large numbers. Hardware implementations don’t
pass node information, like CPU and memory utilisation.
Interesting these solutions are all vender specific. If the information
to be provided/protected behind these firewalls is deemed to require greater
protection, such as Highly Protected then multiple serial evaluated firewalls
of differing manufacture are required6.
Introducing load-balancing traffic management devices in front of these
serial-paired firewalls creates very scalable disparate firewall containers.
While state information can’t pass between such containers the traffic
management device can predict load based on immediate pass history.
Availability figures change with the introduction of yet another device, and of
course the security enforcement function of the portal is increased. The
‘segment’ between the disparate firewalls within each container becomes a key
point within the portal network and will be viewed as potential NIDS monitoring
point.
Denial of Service Attacks
But what about Denial of Service (DoS) and Distributed DoS attacks? An
analysis of backscatter from Distributed DoS attacks highlights the use of
malformed network protocol packets[14].
Data floods are also a very common attack mechanism1.
Multiple sites and defence in depth is required. Most modern networking
devices have limited defensive facilities build within them, and will be
configured to reduce effects. Firewalls, routers and network traffic management
devices now offer very sophisticated DoS minimisation defences. Defences
include logical access filtering, SYN flood throttling, connection rate
throttling, and data rate throttling. The greatest defence to DoS attacks is
redundancy. The portal is distributing connections between sites, and also
within a site.
Incident Handling
Another defensive mechanism that will be used to support the portal is
incident handling. Responsive counter-measures, and emergency preparedness by
staff is essential, for event containment, and recovery. Procedural plans and
management controls are required for incidents such as; failure of (physical or
logical) security enforcing functions, failure of systems, and lost of a
service.
Issues to be scrutinised are:
-
identification and analysis of the event
-
formal reporting procedures and resultant actions documented in detail
-
confirmation of systems and information integrity
-
communications and reporting to affected service delivering agencies
and/or investigative audit personnel
-
authorisation requirements for ‘emergency’ actions
-
collection and integrity of audit logs and other evidence used for
forensics (and if warranted legal action)
The objective of these procedures is to form an incident management
plan, parts of which will also form part of the business continuity plan (a
more encompassing version of the traditional disaster recovery plan).
How to ensure the
Integrity of an information resource?
So what is integrity? Ensuring that malicious tampering or fabrication
hasn’t occurred by authorised or unauthorised personnel. Ensuring that
information, software and hardware is changed in a specified and authorised
manner. Certify the recovery or protection of data from rogue (or
unaccountable) functionality in an application, or from a mechanical fault of
the storage device.
How to tell a fake?
If a intruder was able to retrieve sensitive information from the portal
not only is there a serious security penetration but a further issue arises,
has the information been tampered with, or malicious code been placed. Either
of these outcomes could have also occurred, but it has to be proved; otherwise
the consequences of the event have the same effect. The use of digital
signatures can be used to verify the content of data files; certainly they will
be used against vital system files. While the use of signed web certificates
gives a guarantee destination (DNS hijacking aside), it doesn’t give a hint of the
integrity of the sites content. Traffic management devices can remotely
checksum site content and enact appropriate measures.
Quality Management – Back
to Basics
The use of change control, peer review, and extensive testing procedures
will be mandated and will provide consistency and integrity to the portal
environment. Change control procedures ensure the all changes are authorised,
documented, tested, rollback mechanism provided, and that a reassessment of the
threats and risks involved is completed. These processes are to be formally
documented and enforced.
Depending on the nature of the informational service, backups in this
highly redundant and replicated environment may not be required or essential;
backups of the sourced/original data must exist and managed.
Development and testing of application software should be done in
non-production environments to ensure that unknown side effects from software
changes go through their normal development cycle and that critical production
data is not incorrectly manipulated.
Government Guidelines, the need for a Threat and Risk Assessment (TRA)5
The basic premise of DSD’s methodology is that risk is dependent on the
threat likelihood and consequence estimation.
For firewall environments the TRA is based on the general portal
architecture - not on applications hosted within the site, although each
application/service within the environment should have a TRA as specified in
ACSI 335 Handbook 3.
Risk Assessment
Methodology
The outlined Security Risk Assessment Methodology
provided in ACSI 33 and the Gateway Certification Guide, is a stepped approach
that should lead to management policies and procedures (which are re-inputted
into the assessment). The methodology can be summarised as: Asset
Identification Ø Threat to the Asset (Estimation) ØThreat
Likelihood Ø Harm,
if realised Ø (Resultant) Risk Assessment Ø Required Risk (Estimation) Ø
Counter-measure Priority Rating Ø Countermeasures (Policy,
Procedures, and Design) Ø Identification (and
Acceptance) of Residual Risk.
Asset Identification
ACSI 33 Handbook 3's Security Risk Management Process, proposes a
guideline of five major groupings to help identify assets:
· Confidentiality
of Information
· Availability of
Resources and Services
· Integrity of
Information
· Equipment,
including Software
· Staff
AS/NZS 4444.1-1999[15]
outlines four categories for asset identification:
· Information
Assets
· Software Assets
· Physical Assets
· Services
The OECD Guidelines for the Security of Information Systems2 harm/failure groupings are:
· Availability
· Confidentiality
· Integrity
For the basis of the asset identification component of risk management,
all of the above or anything similar are guidelines only. As the portal will be
a generalistic environment a course level identification of assets is required.
For the process of identification the following categories have been chosen:
· Accountability
(a component of Confidentiality)
· Availability
(which includes Access Control)
· Integrity (of
Physical, Information, Hardware, and Software Environments)
Accountability Assets
· Misuse of data
and systems by external users
· Use of portal
services by Government staff or developers
· Administration/operations
staff in their management of the environment
Availability Assets
· Hosted
Government data/information resources and supporting systems
· Loss of portal
environment supported service(s)
· Loss of a
critical hardware component(s) of the portal environment
· Loss of a
critical software component(s) of the portal environment
· Trained knowledgeable
portal administration/operations staff
· Controlled
access to hosted Government data/information resources and supporting systems
· Controlled
access to a critical hardware component(s) of the portal environment
· Controlled
access to a critical software component(s) of the portal environment
· Controlled
access to the portal security enforcing services
Integrity Assets
· Loss or
corruption of Government data/information resources and supporting systems
· Configuration
of the portal environment infrastructure
· Protection of
government data while in transit over communications lines
· Protection of
information relating to the secure configuration of the portal environment
The relevant risk tables from ASCI 33 are reproduced here, before the
presentation of the portal TRA.
Table 2: Threat Likelihood Rating5
|
Negligible |
Unlikely to occur |
|
Very Low |
Likely to occur two/three times every five years |
|
Low |
Likely to occur once every year or less |
|
Medium |
Likely to occur once every six months or less |
|
High |
Likely to occur once per month or less |
|
Very High |
Likely to occur multiple times per month or less |
|
Extreme |
Likely to occur multiple times per day |
Table 3: Consequence Estimation Rating5
|
Insignificant |
Will have almost no impact if threat is realised. |
|
Minor |
Will have some minor effect on the asset value. Will not require any
extra effort to repair or reconfigure the system. |
|
Significant |
Will result in some tangible harm, albeit only small and perhaps only
noted by a few individuals or agencies. Will require some expenditure of
resources to repair (eg "political embarrassment"). |
|
Damaging |
May cause damage to the reputation of system management, and/or
notable loss of confidence in the system's resources or services. Will
require expenditure of significant resources to repair. |
|
Serious |
May cause extended system outage, and/or loss of connected customers
or business confidence. May result in compromise of large amounts of
Government information or services. |
|
Grave |
May cause system to be permanently closed, and/or be subsumed by
another (secure) environment. May result in complete compromise of Government
agencies. |
Table 4: Resultant Risk5
|
|
|
Consequence
Estimation |
|||||
|
|
|
Insignificant |
Minor |
Significant |
Damaging |
Serious |
Grave |
|
Threat
Likelihood |
Negligible |
Nil |
Nil |
Nil |
Nil |
Nil |
Nil |
|
Very Low |
Nil |
Low |
Low |
Low |
Medium |
Medium |
|
|
Low |
Nil |
Low |
Medium |
Medium |
High |
High |
|
|
Medium |
Nil |
Low |
Medium |
High |
High |
Critical |
|
|
High |
Nil |
Medium |
High |
High |
Critical |
Extreme |
|
|
Very High |
Nil |
Medium |
High |
Critical |
Extreme |
Extreme |
|
|
Extreme |
Nil |
Medium |
High |
Critical |
Extreme |
Extreme |
|
Table 5: Countermeasure Priority Rating5
|
Nil |
0 |
|
Low |
1 |
|
Medium |
2 |
|
High |
3 |
|
Critical |
4 |
|
Extreme |
5 |
The aim of DSD’s Threat Risk Assessment (TRA) is to provide a framework,
not only to identify risks to information resources, but also to prioritise
where mechanisms need to be further developed via the proposed counter-measures
(weather they be either hardware/software related or procedural).
The entries in the table below are a guide only – all possible threats
haven’t been covered. By applying risk management techniques areas that require
greater resources to reduce risk have been identified for the 24x7x365 Government
portal, those with a counter-measure(s) priority rating exceeding 4 (Critical)
have been highlighted.
Table 6: The 24x7x365
Government Portal TRA
|
Asset Identification |
Threat to the Asset |
Threat Likelihood |
Harm, if threat is realised |
Resultant Risk |
Required Risk |
Counter-measure(s) Priority Rating |
|
Accountability of misuse of
data and systems by external users |
Details relating to an
individual misusing the service(s) are NOT provided to the relevant
investigative authorities |
Medium |
Significant |
Medium |
Low |
1 |
|
Accountability of misuse of
portal services by Government staff or developers |
Details relating to an
individual misusing the service(s) are NOT provided to the relevant
investigative authorities |
Medium |
Damaging |
High |
Low |
2 |
|
Accountability of administration/operations
staff in their management of the environment |
Details relating to an
individual misusing the service(s) are NOT provided to the relevant
investigative authorities |
Low |
Serious |
High |
Nil |
3 |
|
Availability
of hosted Government data/information resources and supporting systems |
Unavailable or restricted by
a communications overload (DoS attack) on the resource |
High |
Serious |
Critical |
Nil |
4 |
|
Unavailable or restricted by
a loss of a telecommunications carrier link |
Negligible |
Damaging |
Nil |
Nil |
0 |
|
|
Unavailable or restricted due
to errors and omissions in the administration of the services and support
hosts |
Low |
Significant |
Medium |
Nil |
2 |
|
|
Inadvertent power outage due to accidental tampering with distribution
system(s) |
Low |
Grave |
High |
Low |
2 |
|
|
Damage to or corruption of
data/information storage media |
Low |
Significant |
Medium |
Nil |
2 |
|
|
Loss of portal environment
supported service(s) |
Unavailable or restricted by
a communications overload (DoS attack) on the service |
High |
Serious |
Critical |
Nil |
4 |
|
Unavailable or restricted by
a loss of a telecommunications carrier link |
Negligible |
Damaging |
Nil |
Nil |
0 |
|
|
Unavailable or restricted due
to errors and omissions in the administration of the services and support
hosts |
Low |
Significant |
Medium |
Nil |
2 |
|
|
Loss of a critical hardware
component(s) of the portal environment |
Operator or equipment
maintenance error |
Low |
Damaging |
Medium |
Nil |
2 |
|
Equipment failure |
Low |
Significant |
Medium |
Nil |
2 |
|
|
Unauthorised modification |
Low |
Damaging |
Medium |
Nil |
2 |
|
|
Theft |
Negligible |
Significant |
Nil |
Nil |
0 |
|
|
Loss of a critical software
component(s) of the portal environment |
Operator maintenance error |
Low |
Damaging |
Medium |
Nil |
2 |
|
Unauthorised modification |
Low |
Damaging |
Medium |
Nil |
2 |
|
|
Expiring of software licences
or certificates |
Very Low |
Significant |
Low |
Nil |
1 |
|
|
Trained knowledgeable portal
administration/operations staff |
Poor levels of service
through insufficient numbers of suitable qualified, vetted and aware
operations staff |
Low |
Significant |
Medium |
Nil |
2 |
|
Controlled access to hosted
Government data/information resources and supporting systems |
Compromise of Government
data/information through unauthorised access to resources |
Low |
Significant |
Medium |
Nil |
2 |
|
Compromise of Government
data/information through unauthorised access to other Government resources
via trusted communication resources |
Very Low |
Significant |
Low |
Nil |
1 |
|
|
Controlled access to a
critical hardware component(s) of the portal environment |
Unauthorised physical access
to a critical component by an individual other than authorised operators and
maintenance personnel |
Very Low |
Damaging |
Low |
Nil |
1 |
|
Unauthorised physical access
to a critical component by an individual occupying positions of trust who may
bear a grudge against the Government |
Very Low |
Grave |
Medium |
Nil |
2 |
|
|
Controlled access to a
critical software component(s) of the portal environment |
Compromise of the security
enforcing functions through unauthorised configuration changes |
Low |
Significant |
Medium |
Nil |
2 |
|
Controlled access to the
portal security enforcing services |
Unauthorised
access/modification to security enforcing functions by unauthorised
individuals or processes |
Very Low |
Serious |
Medium |
Nil |
2 |
|
Loss or corruption of
Government data/information resources and supporting systems |
Integrity and confidence of
Government data /information and systems loss by corruption of data or
service through malicious data (embedded viruses, worms and Trojans) |
High |
Significant |
High |
Nil |
3 |
|
Social engineering attack on
Government staff or developers |
Low |
Serious |
High |
Nil |
3 |
|
|
Integrity of government data
/information and systems loss by resource ‘annotation’ |
High |
Serious |
Critical |
Nil |
4 |
|
|
Unavailable or bogus service
from IP service hijacking or infiltration |
High |
Serious |
Critical |
Nil |
4 |
|
|
Loss of confidentiality of
sensitive data, by publication of information sourced from Government data/information
and systems located within the portal environment |
Medium |
Damaging |
High |
Nil |
3 |
|
|
Misconfiguration of a portal
component through poor configuration control |
Low |
Damaging |
Medium |
Nil |
2 |
|
|
Deliberate and unauthorised
modification of a portal component by a malicious source |
Medium |
Serious |
High |
Nil |
3 |
|
|
Compromise of the portal
security functions and support systems by corruption of data or service
through introduction of malicious data (embedded viruses, worms and Trojans) |
Low |
Serious |
High |
Nil |
3 |
|
|
Compromise of a portal
component through failure to apply an bug patch or upgrade recommended by the
component's developer |
Medium |
Damaging |
High |
Nil |
3 |
|
|
Unauthorised disclosure of
information relating to the configuration of the portal (such as security
enforcing functions, data flow and network configurations) |
Low |
Serious |
High |
Nil |
3 |
|
|
Protection of government data
while in transit over communications lines |
Compromise of Government data
/information via tapping or interception of Government communications lines to
the portal |
Very Low |
Damaging |
Low |
Nil |
1 |
|
Protection of information
relating to the secure configuration of the portal environment |
Unauthorised disclosure of
information relating to the configuration of the portal (such as operational
procedures, backup schedules, names of critical/authoritative staff) |
Medium |
Significant |
Medium |
Nil |
2 |
Counter-measures
NEED to outline resultant
objectives/procedures etc… from the high rating results only. (Policy,
Procedures, and Design)
END OF DOCO SUMMARY HERE