ITEC854 Information Security

Management
Week 8 – Information Classification and Exposures

"No printing is permitted of this book.

This book cannot be given to someone else.
This book cannot be read aloud." — License terms for Adobe ebooks.
Course map

• Week 8: Information Classification

• Week 9: Hacking and your ISMS, Quiz 2 (covers material in weeks 5-8
inclusive)
• Week 10: Forensics & Evidence
• Week 11: Incident response
• Week 12: Privacy Review/How-not-to case study
• Week 13: Open discussion forum, Industry Examination preparation
Week 13 presentation

• Presentations will now be both Saturday and Sunday, you only need to come
to one session, Saturday AM, Saturday PM or Sunday
Start Saturday Sunday

08:30

09:00

09:30

10:00

10:30 BREAK BREAK

11:00

11:30

12:00

12:30

13:00 LUNCH

14:00

14:30

15:00

15:30

16:00

16:30
Practical deliverables WEEKS 8-12
Practical deliverables

• Components in light
blue should be
created and/or
refined before week
12
• No fixed weekly
tasks but lectures
inform your process
• Practical work is
now independent
Week 7 deliverables comments

• Peer assessment due by 1200 30-SEP-2019, by that time 133 people had
not submitted
• By 2359 20-SEP-2019, 85 people had not submitted
• By 1200 today, 1-OCT-2019, 33 people had not submitted
• Final marks will not be given until all peer assessments are received

• General comments - most groups are not:

• Explaining in any detail how they arrived at their information assets
• Explaining how they arrived at their information classification
• Using information classification linked to business sensitivity
• Using consistent terminology between WWMD, Consequence Matrix
and Risk Appetite
• Defining a Risk Appetite
• Explaining their scenarios any many don’t link the scenarios to the
TRAs and/or BCP
• Using realistic review frequencies in WWMD
Outline

• What is information classification

• How to classify information
• Policies and Procedures
• Perils of over or under classifying information
• Information exposures
• An interesting implementation…
• https://www.digital.nsw.gov.au/sites/default/files/NSW%20Government
%20Information%20Classification%20Labelling%20and%20Handling
%20Guidelines%20V.2.2_0%20%283%29.pdf
What is information classification

• The objective is to ensure that

information assets receive an
appropriate level of protection
• Information should be classified
to indicate the need, priorities
and degree of protection
• Information has varying degrees
of sensitivity and criticality - some
items may require an additional
level of protection or special
handling
• An information classification
system should be used to define
an appropriate set of protection
levels, and communicate the
need for special handling
measures
How to classify information

Guidelines
• Must be business oriented –
classifications must be
reasonable and
implementable
• Classified information can be
described in terms of integrity
or availability – confidentiality
is, of course, a given!
• A classification often has a
“use by” date – or may be
driven by events, such as
public release
How to classify information…

Classification and de-classification

• Anyone can classify
information
• Only the original classifier can
alter or remove the
classification
• Procedures must exist to
monitor the process
• Information classification
stagnation must be managed
How to classify information…

Information labelling and handling

• Classified information must be labelled to ensure
compliance with procedures
• Physical and electronic information have different
requirements
• Information transformation can cause problems for
classification
• Physical state transformation, such as electronic to physical
• Content transformation, such as updating with higher
classification content
Information Security Policy

• A policy document should be approved by management, published and

communicated, as appropriate, to all employees
• It should state management commitment and set out the organisation’s
approach to managing information security
• As a minimum, the following guidance should be included:
Information Security Policy…

• a definition of information security, its overall objectives and scope and

the importance of security as an enabling mechanism for information
sharing
• a statement of management intent, supporting the goals and principles of
information security
• a brief explanation of the security policies, principles, standards and
compliance requirements of particular importance to the organisation, for
example:
• compliance with legislative and contractual requirements
• security education requirements
• prevention and detection of viruses and other malicious software
• business continuity management
• consequences of security policy violations
• a definition of general and specific responsibilities for information security
management, including reporting security incidents
• references to documentation which may support the policy, e.g. more
detailed security policies and procedures for specific information systems
or security rules users should comply with
Perils of over or under classifying
information
Under-classification
• CIA lost or compromised
• Financial risk
• Inability to maintain an effective ISMS
• Too much information available to too many people
Perils of over or under classifying
information…
Over-classification
• Difficulty in managing information
• Policy operation is ignored
• TRA becomes unmanageable as too many assets show a high risk rating
• Users become complacent as all information appears to have a similar
classification
Information exposures

• Credit card entities having all credit card details exposed

due to faulty access controls (not a classification failure)
• Patient medical records found on rubbish dump (not a
classification failure)
• Credit card information passed on to a third party (not a
classification failure)
• Financial records used within a business for a different
purpose
• Sensitive email sent unencrypted
• Paper files lost or destroyed
• Confidential information accessed on a common use
computer
• Legal information sent out in a brief of notes
Security by design

There are several approaches to security in computing, sometimes a

combination of approaches is valid:
1. Trust all the software to abide by a security policy but the
software is not trustworthy (this is computer unsecurity).
2. Trust all the software to abide by a security policy and the
software is validated as trustworthy (by tedious branch and path
analysis for example).
3. Trust no software but enforce a security policy with mechanisms
that are not trustworthy (again this is computer unsecurity).
4. Trust no software but enforce a security policy with trustworthy
mechanisms.
Many systems unintentionally result in the first possibility.
• Approaches one and three lead to failure
• Since approach two is expensive and non-deterministic, its use is
very limited
• Because approach number four is often based on hardware
mechanisms and avoid abstractions and a multiplicity of degrees of
freedom, it is more practical
• Combinations of approaches two and four are often used in a
layered architecture with thin layers of two and thick layers of four.
Security by design…

There are myriad strategies and techniques used to design security systems.
There are few, if any, effective strategies to enhance security after design.
One technique enforces the principle of least privilege to great extent, where an
entity has only the privileges that are needed for its function. That way even if
an attacker gains access to one part of the system, fine-grained security
ensures that it is just as difficult for them to access the rest.
Security by design…

The design should use "defence in depth",

where more than one subsystem needs to
be violated to compromise the integrity of
the system and the information it holds.
• Defence in depth works when the
breaching of one security measure
does not provide a platform to
facilitate subverting another
• Also, the cascading principle
acknowledges that several low
hurdles does not make a high hurdle
• So cascading several weak
mechanisms does not provide the
safety of a single stronger
mechanism
Security by design…

• Subsystems should default to secure settings, and wherever possible should

be designed to "fail secure" rather than "fail unsecure" (see fail safe for the
equivalent in safety engineering).
• Ideally, a secure system should require a deliberate, conscious,
knowledgeable and free decision on the part of legitimate authorities in order
to make it unsecure.
Security by design…

In addition, security should not be an all or nothing issue.

• The designers and operators of systems should assume that security
breaches are inevitable.
Full audit trails should be kept of system activity, so that when a security breach
occurs, the mechanism and extent of the breach can be determined.
• Storing audit trails remotely, where they can only be appended to, can
keep intruders from covering their tracks.
Finally, full disclosure helps to ensure that when bugs are found the "window of
vulnerability" is kept as short as possible.
Computer security models

Access control list (ACL)

• An ACL is a list of permissions attached to an object. The list specifies
who or what is allowed to access the object and what operations are
allowed to be performed on the object.
• In a typical ACL, each entry in the list specifies a subject and an
operation: for example, the entry (Alice, delete) on the ACL for file XYZ
gives Alice permission to delete file XYZ.
• In an ACL-based security model, when a subject requests to perform an
operation on an object, the system first checks the list for an applicable
entry in order to decide whether or not to proceed with the operation.
Computer security models…

Multi-level security (MLS)

• The application of a computer
system to process information with
different sensitivities (i.e. classified
information at different security
levels), permit simultaneous access
by users with different security
clearances and needs-to-know, and
prevent users from obtaining
access to information for which they
lack authorisation
• MLS allows easy access to less-
sensitive information by higher-
cleared individuals, and it allows
higher-cleared individuals to easily
share sanitised documents with
less-cleared individuals
Computer security models…

Role-based access control (RBAC)

• This an approach to restricting system access to
authorised users. It is an alternative approach to
mandatory access control (MAC) and discretionary
access control (DAC)
• Prior to the development of RBAC, MAC and DAC
were considered to be the only known models for
access control: if a model was not MAC, it was
considered to be a DAC model, and vice versa.
• Within an organisation, roles are created for various
job functions. The permissions to perform certain
operations ('permissions') are assigned to specific
roles
• Members of staff (or other system users) are
assigned particular roles, and through those role
assignments acquire the permissions to perform
particular system functions
• Unlike context-based access control (CBAC), RBAC
does not look at the message context (such as
where the connection was started from)
• Since users are not assigned permissions directly,
but only acquire them through their role (or roles),
management of individual user rights becomes a
matter of simply assigning the appropriate roles to
the user, which simplifies common operations such
as adding a user, or changing a user's department
Computer security models…

• Lattice-based access control (LBAC) is a complex

method for limiting information access based on any
combination of objects (such as resources,
computers, and applications) and subjects (such as
individuals, groups or organisations)
• In this type of control model, a lattice is used to
define the levels of security that an object may have,
and that a subject may have access to. That is, we
define a partial order on the security levels, in such a
way that any two security levels always have a
greatest lower bound (meet) and least upper bound
(join)
• If two objects A and B are combined to form another
object C, that object is assigned a security level
formed by the join of the levels of A and B, and if two
subjects need to jointly access some secure data,
their access level is defined to be the meet of the
subjects' levels
• A subject is allowed to access an object only if the
security level of the subject is greater than or equal
to that of the object, in the partial order defining the
lattice
• LBAC is known as a more specific set of access
control restrictions and is more general than role-
based access control (RBAC)
Computer security models…

Bell-LaPadula model
• This was developed by David Elliott Bell and Len LaPadula in 1973 to formalize
the U.S. Department of Defense (DoD) multilevel security (MLS) policy
• The model is a formal state transition model of computer security policy that
describes a set of access control rules which use security labels on objects and
clearances for subjects
• Security labels range from the most sensitive, e.g., "Top Secret", down to the least
sensitive, e.g., "Unclassified" or "Public."
• The Bell-LaPadula model is an example of a model where there's no clear
distinction of protection and security
• The Bell-LaPadula model focuses on data confidentiality and access to classified
information, in contrast to the Biba Integrity Model which describes rules for the
protection of data integrity
Computer security models…

Biba model
• This was developed by Kenneth J.
Biba in 1977, is a formal state
transition system of computer security
policy that describes a set of access
control rules designed to ensure data
integrity
• Data and subjects are grouped into
ordered levels of integrity - the model
is designed such that subjects may
not corrupt data in a level ranked
higher than the subject, or be
corrupted by data from a lower level
than the subject
• In general the model was developed
to circumvent a weakness in the Bell-
LaPadula Model which only address
data confidentiality