PreprintPDF Available

Pillars of Information Security from the 'Software Engineering Manual of Style'

Authors:
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

Security is holistic not heuristic. The Pillars of Information Security (Figure 11) are such that they form a continuum, whereby, one cannot have one without its predecessors. For example, Accountability is of no use without Authenticity. Further, Authentication now includes four factors: Something your HAVE, ARE, KNOW & DO. NB: This pre-print extract is from the forthcoming 'Software Engineering Manual of Style, 3rd Edition: A secure by design, secure by default perspective for technical and business stakeholders alike.
Content may be subject to copyright.
Information Security Best Practices
The Pillars of Information Security
Security is holistic not heuristic. The Pillars of In-
formation Security (Figure 11) are such that they form
a continuum, whereby, one cannot have one without
its predecesors. For example, Accountability is of no
use without Authenticity. Just addressing injection at-
tacks will not make a software system as secure as can
be: one must address each of these pillars separately
and in their entirety to achieve complete security.
Not all systems require all pillars, but it is impor-
tant to make a conscious decision of the compromises
being made and the inherent risks associated with not
fully implementing each of these pillars.
See [6, Ch. 1.1: The Basic Components], [41, Ch. 1:
Security Goals], and [42, Ch. 1.1: Computer Security
Concepts] for more information.
Physical security: Securing the premises that
contains the equipment that houses your software
system.
Availability: refers to both a system’s ability
to respond to events in a timely manner, and it’s
security instrumentation stays in place so that an
SOC or NOC can rest assured the system has
remained up and in-place without being tampered
with physically.
System Integrity: Ensures that the software
system is free from deliberate or accidental unau-
thorised manipulation.
Data Integrity: When two parties exchange
data packets, they want to make sure a third
party has not tampered or interfered with the
data.
Data Condentiality: The assurance given to
software system users that their private or con-
dential information and the contents of data pack-
ets whether they are on temporary or perma-
nent storage will be kept secret.
Identication: Determining whom someone is
by way of a personal identier, so the software
system may verify their identity through Authen-
tication.
Authenticity/Authentication: The act of
verifying someone’s identity (See have, know, are,
do)
Authorization: Checking whether a user has
permission to perform some action.
Accountability: When authentication and au-
thorization are important, and somewthing goes
wrong or an erroneous transaction occurs, ac-
countability ensures you can identify the user re-
sponsible.
Data Privacy: The assurance given to software
system users that they can control what of their
information is collected, stored and disclosed.
Non-Repudiation: The design of a system in
such a way that parties cannot deny being in-
volved in a transaction that mught be the subject
of an accountability audit.
Immutability: The ability to recover the system
from System Integrity and Data Integrity viola-
tions or Accountability tampering through means
such as Reiser FS, VM Checkpoints, dual hot re-
dundancy, WORM drives & logle replayability.
1. Physical Security
2. Availability
3. System Integrity
4. Data Integrity
5. Data Condentiality
6. Identication
7. Authentication (have, are, know, do)
8. Authorization
9. Accountability
10. Data Privacy
11. Non-Repudiation
12. Immutability
complete
security
Figure 11: The Pillars of Information Security
Availability &Accountability are worth consider-
ing in tandem: long log retention is more impor-
tant than 24x7 monitoring. All monitoring teleme-
try instrumentation does not have 100% coverage, and
”Dwell Time” means most incursions aren’t picked up
(C) COPYRIGHT 2023, Andrew (AP) Prendergast. All rights reserved - @CompSciFutures / blog.andrewprendergast.com Page 61
instantly. Sure there are incidents that benet from
24x7 monitoring (if detected), but having reliable com-
plete consistent single source of truth audit controls
and detective controls where condentiality, authen-
ticity, integrity and availability are as close to perfect
as one can be is more important, as most threat hunt-
ing and forensic investigations are done post-hoc.
Availability can take the form of many things, in-
cluding kill switches, ping checks at the OS layer,
HTTP endpoint heartbeats at the application layer,
SNMP monitoring of networking, OS internals and
S.M.A.R.T. hardware, and of course logging instru-
mentation and SIEM telemetry falls into availability.
Referring to Figure 12 [43, Ch. 5: Security], when im-
plementing a kill switch, a system should still main-
tain enough instrumentation that the telemetry can
still be used to detect & audit other security events,
such as Physical Security breaches where a system is
physically taken out of a data rack temporarily, and
that System Integrity is still maintained whilst a kill
switch has been engaged.
What makes a SYSTEM insecure?
a) turning it ON
b) turning it OFF
Figure 12: The attack surface kill-switch riddle
It should also be noted that the entirety of a sys-
tem’s security should not rest on the cryptographic
strength of algorithms used for Data Privacy or Data
Integrity, as history shows that all hasing algorithms
and all cryptosystems eventually fall as computers be-
come faster and cryptography researchers are given
more time to test implementation weaknesses.
The elements of authenticity & authentication
Authenticity or Authentication is the task of ver-
ifying that the entity previously identied as part
of the Identication step in the Pillars of Informa-
tion Security is whom they say they are. There are
currently four possible factors that can be used to
achieve authentication, and it is considered current
best-practices that one uses at least two of these fac-
tors [41, 1.2: Authentication]:
Something that you HAVE/OWN: This
could be a software based TOTP/HOTP 2-
factor code in an authenticator app, or a FIDO-
compliant hardware key. Other examples are
smart cards and ATM cards.
Something that you ARE: This usually refers
to biometrics, the two most common being facial
recognition and ngerprint recognition.
Something that you KNOW: This is usually
a password, but could be any shared secret, such
as the answers to a series of challenge questions.
Something that you DO: This latest addition
usually refers to an authenticator all that displays
an authentication prompt which can only be ac-
cepted after accepting one or more of the previ-
ously mentioned factors, or it could be a simple
CAPTCHA (Completely Automated Public Tur-
ing test to tell Computers and Humans Apart)
test.
The benet of some DO implementations, such as
authenticator apps that display a challenge such
as answer {Approve, Decline}, or where one se-
lects a number from a list of 3-5 options, is that
it can be used to add temporality to all authen-
tication factors: the other factors (HAVE, ARE,
KNOW ) can only be made use of for the duration
that the DO factor/function is in an open state.
(C) COPYRIGHT 2023, Andrew (AP) Prendergast. All rights reserved - @CompSciFutures / blog.andrewprendergast.com Page 62
ResearchGate has not been able to resolve any citations for this publication.
ResearchGate has not been able to resolve any references for this publication.