Securing Computing Environment
Alexander Liss
Event
Investigation Point of View
Simple,
Reliable, Layered, and Modular
Fallacy
of Reliance on Obscurity
Software
Security and Reliability
Application
Design Implications
Access
Segmentation in Computer
Segmentation
of Application Set
Distributed
vs. Centralized Solutions
Security
- Reliability Contradiction
Storage
and Generation of Secrets
Distributed
vs. Centralized Approach
Securing
of Computing Environment poses challenges, which can be met only with a clear
policy. We offer here an approach to setting such policy based on security
structuring, specialization and dynamic restructuring according to learnt new
threats.
While
it is desirable to have 100% digital security of an entire Computing
Environment, such goal is not achievable and pursuing of it is self-defeating.
From the other hand, some security layers can be fortified to a level, which
can be assumed 100% secure, and neglecting such possibility is denying oneself
powerful security tools.
It
is important to choose properly the scope of analysis, when one is setting
security policy, because digital security even cannot be defined in isolation
from physical security and business as a whole.
A
consistent approach to security is defining it as a part of business' risk
management strategy. With this approach it is possible to get a grasp on
security priorities of different areas of Computing Environment, magnitude of
potential losses in a case of a security events (security breaches, mistakes
creating security vulnerabilities, etc.) and potential resources available for
security fortification.
Barriers
of digital security are only evolving elements in a security system, which in
turn is an only evolving element in an ongoing process of protecting the
Computing Environment and business interests as a whole.
Security
measures are set based not on a clear and obvious theory, but rather from a
growing knowledge of potential attacks and vulnerabilities and successful
defensive strategies. They are often annoying, get on the way of normal
business activity and require perpetual review and retraining of affected
personnel.
Increasingly,
protection of Computing Environment requires specialization in narrow areas as
physical security, network security, cryptographic measures, etc. Lack of
understanding between specialists in different areas can create security
weaknesses. Hence, Computing Environment has to be clearly segmented from
security point of view and this segmentation should be simple, stable and well
known to all specialists involved with security issues.
One
should not be seduced with opportunities to achieve additional level of
protection through obscuring this segmentation or through creating
non-segmented convoluted security system, which is difficult to analyze by
potential attacker. The attacker always has an advantage in a perpetual
tag-of-war between attackers and defenders of Computing Environment: an
attacker has to find only one hole in existing environment open for
experimentation, defenders have to protect from opening a hole in unknown
future Computing Environment. Hence, defenders have to simplify their work through
a consistent security structuring of Computing Environment.
Security
specialists need a common language, a common system of goals, which allows
consistent combining of their efforts into an evolving, functioning security
system. This can be set differently. Following provides one variant of such
language and system of goals, which proved to be effective.
The
goal of an automated security system cannot be providing 100% security, as it
is described above. It should be setting the stage for acting of non-automated
protection procedures.
Such
non-automated protection procedures are:
·
Security
event investigation,
·
Setting
new internal security procedures and ultimately reorganization of security
system
·
Internal
enforcing of security measures
·
Engagement
of law enforcement
·
Engagement
of judicial system and other social structures.
The
security system should make engagement of non-automated procedures as rare as
possible, but in case such engagement is needed it should prepare conditions,
that it is as fast and as effective as possible.
This
is a clear goal, and from its point of view effectiveness of security
procedures can be measured.
During
an investigation of a security event it is important to be able to define with
a good degree of comfort that particular elements of the Computing Environment
are not compromised. This determination along saves time and efforts during the
investigation. This is not an easy task, because an attacker is not a random
event but a driven adversary looking for potential holes in unexpected places.
Usually,
such elements, on which we can rely, are elements specially developed as
elements of the security system. Hence, they must be extra secure themselves.
Hence they have to be extra reliable - an unreliable element creates unforeseen
circumstances and an opportunity for an attack. Hence, they have to be well
tested. Hence, they have to be simple.
Cryptographic
elements of security system can be such reliable elements, if they are set
properly (cryptographic procedures have no known attacks against them, their
implementation has no known attacks against it as buffer overflow, sizes of
keys are chosen sufficiently large, random numbers are properly generated,
secret keys are properly protected etc.).
There
is one additional argument for proper fortification of cryptographic element of
the security system - breach of them rarely can be detected and an attacker
often can explore such breach with impunity.
Hence,
cryptographic elements of the security system has to be fortified to a degree,
that in case of security event investigation one can exclude them from analysis
practically immediately.
Design
of the security system (and its frequent redesign) requires unusual approach
reserved to highly reliable systems. It requires unusual level of attention to
rarely occurring events, because it is a routine way of attacking the system by
instigating rarely occurring events.
This
requires a tedious enumerating of various events occurring during installation
of hardware, operation systems, other software, own applications, development,
debugging, testing, fallback, emergency responses, etc. The positive side of it
- it allows designing of measures, which minimally interfere with everyday or
rare emergency activities of personnel.
This
should be a major goal in designing of the security systems - minimal
interference with usual business activities of personnel. It is important not
only from business point of view (otherwise introduction of a security system
carries large unaccounted overhead), but also from purely security point of
view. Experience shows, that personnel consistently circumvents security
measures, which get on the way of their activities or worse threatens their
income. Hence, security measures have to by minimally inconvenient and should
never be linked with any non-security related measures (time accounting,
company resources usage, etc.).
Beyond
elements of the security system, on which we can rely as unbroken during an
investigation of a security event, are security measures, which can be broken,
but which breach requires time and resources and we hope to catch an attempt of
such breach in action or at least after action and counteract it with
non-automatic security procedures.
Such
measures are implemented in packets and their effectiveness is evaluated in
packets and not separately.
A
crucial factor in deciding to use a packet of security measures is an ability
to detect any breach of such packet of measures. If there is a known
surreptitious attack against such packet, which can be launched with reasonable
resources and in a reasonable timeframe, the attack, which defenders cannot
detect, then such packet should not be deployed at all. Deployment of such
packet increases complexity of security system and hence complicates a security
event investigation and it creates a false sense of security, which can be
dangerous on its own.
From
the other hand, one should not neglect to implement packets of security
measures to protect even seemingly unimportant areas of Computing Environment,
because Computing Environment open to attacks, especially open to
unsophisticated attacks, which require only widely available knowledge and
tools and small amount of time, tempt even people without criminal tendencies
to try them. Hence, neglecting to protect Computing Environment is even
irresponsible from general social point of view.
This
is a matter of fact that knowledge needed to launch an attack, is spreading
fast. New tools of attack are becoming more sophisticated, more automated and
ever cheaper. Computing resources available to attackers are growing fast -
they are more powerful and less expensive. Even resources of the Internet in
many cases can be gathered surreptitiously to launch an attack.
This
means that defenders of Computing Environment should perpetually reevaluate
effectiveness of packets of security measures and they should discard packets,
which can be attacked with reasonable amount of resources and in a reasonable
period of time.
The
actual bound - "a reasonable amount of resources and a reasonable period
of time", is different in different business setting, and it can be and should
be quantified. The defenders of Computing Environment should monitor how
characteristics of their packets of security measures are changing in time in
relation to this bound.
Usually
packets of security measures are organized in security layers. From the first
glance this seems counterproductive - if an attacker has information of the
layered structure of security system, then it is easier to launch an attack.
However, defenders and attackers share common knowledge of principles of
security, they have similar education and there is not too many security
measures to choose from, hence we have to assume that an attacker can guess
pretty well the structure of about any security system. Organizing a security
system in layers does not fortifies it, but simplifies investigation in a case
of a security event and simplifies its designing and testing and it supports
specialization of defenders of Computing Environment. Hence, it is highly
recommended to use a layered structure of security system.
From
arguments above, it is clear that a security system has to be simple, highly
reliable, layered, and divided on modules according to specialization of
defenders.
In
setting up requirements for a particular security system one take in
consideration the probabilities of particular types of an attack, especially
insider attacks. There is a tendency to assume that external attacks on low
value targets are of low probability and insiders are loyal and will not attack.
This argumentation is flawed, because there are other reasons, why an attack
can be launched - curiosity, bragging rights, revenge, challenge, etc. It is
important to set defensive measures protecting low value targets and protecting
against insider attacks. As usual, the extend of these measures is defined by
overall cost of their setting, maintenance and overhead caused by them in other
areas of the business.
There
is a tendency to rely on obscurity in security systems. How much obscurity is
not a main security tool one can learn from cryptography. Currently, a normal
approach to cryptographic methods includes requirements that a method cannot be
broken with reasonable resources and in a reasonable time when an adversary
knows everything about it, except its secret keys. Only methods, which can pass
this test, can be reasonably used, and their use is already obscured as an
additional security feature.
This
approach became a necessity with advent of computing power and research
available to potential adversaries, against which a cryptographic protection is
designed.
The
field of "digital" security arrived to similar circumstances -
ability of adversaries to gather information and make a large number of trial
attacks on the system is so immense, that "obscurity" is not a
protection but rather an invitation. In addition, it creates a false sense of
security, which can be more dangerous than attacks themselves.
Securing
of Computing Environment is not limited to implementation of a security system.
Software (network, operation system, applications, etc.) has to be fortified
also.
There
is a wide spread misconception that security and reliability of software are
kind of unrelated. This is false.
First
of all, unreliable software has states, which are unaccounted for and cannot be
reasonably anticipated. The combinations of a few unreliable software modules
bring the number of combined "unaccounted" states to the level, which
changes the functionality of the system in a substantial way. While, this
hidden functionality is not used in ordinary operations, it can and often is
used by attackers. Because it is unaccounted, it hardly can be blocked by
defenders of Computing Environment.
Some
events associated with an attack can actually happen without an attack, because
of misunderstanding of developers, communicating parties, software operators,
etc.
A
"buffer overflow" attack is a case in point. In this attack a
reliability weakness - an ability to store more data than space allocated for
it, is turned by attackers into a security flaw - they force software to crash
and launch a program of their choosing.
This
is also true with a Denial-of-Service attack, where high load caused by one
group of users prevents another group from being served. This issue has to be
addressed on the system design stage.
Hence,
fortifying software from security point of view should always include
improvement of software reliability. From the other hand, software design and
implementation taking in consideration all these reliability issues
automatically produce secure software, which is fortunate, because it is
difficult to describe and monitor compliance for security related requirements
and it is much easier to describe them in reliability terms.
Some
misconceptions related to network segmentation and its security implications
are wide spread also.
First,
it is important to define security segmentation of the network, because it is
possible that a security segment includes a few network segments.
There
are boundaries between different security segments, which data traffic has to
cross to go from one segment to another. Boundaries are internal - between
internal segments and external - between an internal segment and an external
segment, as the Internet. Obviously, an external boundary has its specifics,
for example there are perpetual probing connection attempts from the Internet,
which routinely map all ports, at which the segment's applications are
accepting connections. Hence there are external-facing segments - segments,
which have at least one external boundary.
External
boundaries usually are protected with firewalls. It is important to protect
with firewalls internal boundaries also (this is one of the reasons, why we
need a concept of security segment in addition to the concept of network
segment).
Internal
segments do not have an external boundary; external segments have at least one
external boundary.
External
Segments (Demilitarized Zone - DMZ), require special monitoring, because they
are first targets of an attack. They house simple applications, which relay
traffic to applications running on internal segments and use internal segments
to store data. Locally, data is stored only temporarily, usually as a copy of
data stored in an internal segment.
Internal
Segments can be differentiated by a minimal number of hoops the traffic from an
external segment has to make through other fully internal segments until it
reaches a given one. Some specialists think that this can be used on its own to
strengthen security, but this is not so. It is not more secure to have two
firewalls instead of one, and an attack is launched through passing data, which
is not blocked by a firewall. Security segments are differentiated with the
security quality of software allocated to different segments.
There
are applications, especially user-facing applications, which have to provide
broad and ever expending functionality (as a mail client).
These
applications cannot be of high security level, because many new features are
often rarely used and poorly tested and often security implications of their
introduction are unclear.
To
deal with this situation one has to create a special network segment (or
segments), where such applications can be located. This protects applications
located in internal segments in case of a compromise of a broad functionality
application.
The
security of a security segment as a whole is defined by a "weakest
link" - by software of lowest security quality, because an attacker can
find it and compromise an entire segment. Hence, in a security segment, one
would expect to find software of about the same security quality (with
exception of some software common to many security segments, which could be of
high security quality). At least, this is a state to which a security segment
should arrive through perpetual improvement of security quality of its
"weakest links".
Traffic
between a security segment of high security quality and low security quality
should be treated the same way as traffic between internal and external
segments. Minimal number of ports should be available for connection attempts
(open in firewall). For each such port, it should be an active application
listening on it (that malicious software can't use it), it is desirable for any
traffic crossing the boundary to be encrypted and authenticated.
If
this is a case, then a firewall serving such boundary, has very little to do
and it should not be sophisticated - it should be simple and highly secure.
In
a highly secure segment, all communication between processes is encrypted and
authenticated, temporary files created by a process at least have a Message
Authentication Code (MAC) to prevent their malicious modification, data shared
between processes and between instances of the same process (restarts) is
stored in a protected database, not administrative processes do not have
administrator (root) access rights.
Note
that highly secure segments are expensive to create and to manage and they can
cause difficulties of operating, hence their use should be minimized. They should
be reserved for security system, some management systems, which can affect
crucial functioning of the Computing Environment, and systems, which compromise
could cause highly adverse business consequences.
Often,
they require special measures of physical protection in addition to measures
used for other segments.
Encryption
of inter process communication impedes traffic monitoring capabilities. This
can be mitigated with extensive logging and remote reporting.
Sometimes
a security segment is setup ad hock, as an afterthought. This can create
security vulnerability.
As
a general rule, the security system should be designed and maintained as a
system and not as a conglomerate of security packets. This is especially true
about security segments set to house centralized management software
(configuration, backup, runtime display and control, etc.). As a rule, such
segments should be of high security quality, because they are "sweet"
targets of attacks.
A
distributed application can have its modules (processes) placed in different
network security segments, hence it has to support optional encrypted
communication between its modules.
The
idea of limiting access rights of processes, which are not a part of operating
system administration, should be taken further to provide higher granularity of
protection of different computing systems sharing resources of the same
computer. Ideally, it should be possible to divide computer resources into
segments that operation in the computer looks like operations of a network of
its segments. Some operating systems provide such capability, but they are
expensive and their maintenance is expensive. Segmentation of access rights and
assigning a segment of rights to a system using computer's resources provides a
barrier between systems that compromise of one system does not lead to
compromise of others.
A
set of applications (distributed and local to a computer) running in the
networked environment has to be segmented according to security requirements.
This segmentation is done to simplify security management - there are only a
few uniform types of security requirements for applications and each
application is associated with such type.
Security
requirements for a particular application are defined as a combination of
requirements of network, computer and application security type.
For
example, in a high-level application security type, all communication between
modules (processes) of an application should be authenticated and encrypted, in
addition to encryption of communication crossing a security boundary.
Practically,
there are only a few applications, which warrant additional security
requirements and a number of application security types should be small.
By
its nature, security systems require centralized solutions - a small number of
trusted specialists using a small number of devices assure security of the
establishment. However, centralized systems have an inherent security flaw -
they have single points of failure, which are reliability and security
weakness.
While
centralized elements seem to be unavoidable in security systems (with proper
duplication and fail-over and contingency measures), it is desirable to have
security systems with minimal reliance on such elements. This can be done for
example through a design, where reporting and control is done in a distributed
manner, but a copy of reports is sent to a centralized location.
Security
decisions are prompted by an event triggered from such centralized location,
but they are made based on information retrieved after such event using
distributed elements of the system. Control actions are taken using distributed
elements also. Such verification of information and additional authentication
built into control applications should have additional security benefits.
There
is a known method of running applications, which improves their overall
reliability - applications are stopped and restarted anew at regular intervals.
Better yet, the entire set of processes running in a computer including its
operation system is restarted at regular intervals. This brings the system into
a familiar state, where experience shows no failures.
Going
further - the entire data (code, configuration data, application data, etc.)
used by a computer is reloaded from a special well-maintained location.
This
approach sometimes is a necessity from security point of view, especially reloading
of code and configuration data. A sophisticated attack can change
surreptitiously code or configuration data and use this for future attacks.
In
the case of 24/7 operations, it means that design should incorporate the
possibility of taking down applications without interruption of service (the
other instance of an application should take over in such a case).
Depending
on security requirements, such refresh can be partial or full, or it can be a
combination - partial refresh at shorter intervals and full refresh at longer
intervals.
Such
refresh raises issues of protection of the "special well-maintained
location" and procedures of data reloading, though. It is better to have
such data segmented and different segments stored in different locations, that
failure of one such segment does not prevent refresh on other segments (same
issue of balancing distributed and centralized approach in design of security
systems).
Cryptographic
secrets come with contradicting each other problems of secrets protection and
secrets restoration. Duplication of data to be able to restore it, poses a
serious problem in the case of secrets - in the process of duplication and
storing in other location, secrets can be revealed.
Fortunately,
many cryptographic secrets do not need to be replicated - they are recreated in
the case of loss.
Such
secrets are private keys used in Public Key Systems for signing or for exchange
of a secret key (used in encryption of communication, as in SSL). In the case
of loss of such secret, a new secret is generated and special steps of
"secret certification" and possibly distribution of a new public key
associated with this new private key are made.
Because
introduction of a replacement cryptographic secret can be a long procedure, it
is desirable to have a backup secret and an automatic fall-over procedure to
use this backup secret, when an original secret is unavailable.
In
the case of secret compromise, a compromised secret is removed from the use and
an automatic fall-over allows seamless operation.
There
are some schemes, which require storage of private keys used for
"communication secret key exchange" for potential decryption of
communicated data in the future. These schemes are highly inconvenient because
of the need to store securely private keys. Security requirements of such
storing are very high and it is expensive. Much more practical is storing
unencrypted communicated data in a protected storage. Stored data can be
segmented and security requirements of such storing are lower.
Durable storing of secrets poses a special problem, because:
·
a
user with administrator rights can access them
·
one
time compromise of cryptographic secrets creates a hard to detect security
weakness for the duration of secret's validity (cryptographic secrets expire,
as a rule).
Generation
of cryptographic secrets poses another difficult problem. A cryptographic
secret should be cryptographically random (unpredictable). Such data is very
difficult to generate using software. One way or the other a good generator of
cryptographic secrets relies on hardware, preferably on a special cryptographic
hardware module.
Note
that generation and storing of cryptographic secrets should be an explicit part
of a design of a system using cryptography.
Code
handling storage, retrieval and generation of cryptographic secrets is a part
of the security system even when it is embedded in some application and it
requires rigorous security and reliability analysis and testing. It can be
implemented in a form of a library or stand-alone process.
Storage
of cryptographic secrets is protected with means of operating system - there is
no gain in encrypting them.
In
a distributed approach, each application has its own storage and generator of
secrets protected accordingly to rights of this application.
In
a centralized approach, there is a highly protected storage of secrets and
access to secrets and secret generation is provided through a special process.
At every access request, this process (secrets manager) checks requester's
rights. This checking can be customized.
Such
storage can be one or a few per computer or one or a few per a security
segment, especially when there is a separate mechanism supporting encrypted
communication between processes, which does not use this storage of secrets.
Note that even in a centralized approach it could be a few centralized storages
and associated processes. A few storages can be used to increase the
reliability of the system. While different storages should store different
secrets, a user-process should be able to use these secrets interchangeably.
A
centralized approach is especially useful, when it is embedded in an operating
system. Also, if there methods of data protection, which security is higher,
than one provided by other methods, and which are available only to an
administrator, then a centralized storage of secrets managed by an
administrator provides higher level of protection of secrets.
Deployment
of special cryptographic hardware often yields itself to such centralized
approach.
With
proper design, many cryptographic secrets do not need to be accessed by an
application directly. The application needs data to be encrypted, decrypted,
hashed, signed, signature verified, etc. and it does not need to know secrets.
This means that a special layer providing these services and communicating with
secrets storage and generation facility insulates the application from details
of cryptographic procedures. This layer is useful from many points of view -
security, reliability, application management, code management, etc.
Complexity
of Computing environment, diversity of the group of its users and the speed of
change to which both are a subject, brought a situation, where systems guarding
data exchange (authentication, authorization, access control, etc.) cannot be
simple and deterministic, and have to resemble flexible security systems
deployed in other areas, as systems guarding access to funds in banks, access
to secure areas in buildings, etc.
Flexible
user authentication system should work with a set of authentication devices
(password, token, third party confirmation, etc.), make requests for additional
authentication devices, when given devices are insufficient and make decisions
based on probability, that presented set of devices is sufficient for a given access
request. Quality of devices should be assessed dynamically, based on
information perpetually gathered by specialized systems and queried by the
Transaction Guarding System at each request.
Authentication
of server applications and server computers and their networks should be
separate from user authentication. Deployment of operator authentication
instead of a specialized server authentication brings unjustifiable security
weaknesses and difficulties in establishment of coordinated security management
of servers.
In
a flexible Transaction Guarding System, servers (applications, computers, etc.)
should be able to present proofs of belonging to particular security segments.
For example, a server process should be able to present a proof that it belongs
to a server application of a particular application security segment and it is
running in a computer from a particular network security segment. Similar to
authentication of users, it should be possible to present different sets of
authentication devices to prove server's access rights. This is needed for
reliability of systems with Transaction Guarding enabled - if one way of
proving is not available, then alternative one can be used.
A
request for service (for example for data from a database) can be originated by
a user or by a server, or even a few users and servers can be interpreted as a
"collective" originator. While a request traverses the system before
it reaches the servers it goes through a few servers working in different
security conditions. The server's reply again traverses a few servers until it
reaches its recipients (which can be a few). A compromise of any of
·
Request
originators,
·
Traversed
servers by a request
·
Server
·
Traversed
servers by replies
·
Reply
recipients
can cause a security
breach.
Even
more complex situation can happens in other transaction and communication
schemas (as public-subscribe schemas, for example)
Hence,
a comprehensive Transaction Guarding System should provide ability to:
·
Collect
security related data from all participants in its creation, consumption and
traversing
·
Make
access decisions based on all such collected data.
These
data can be large and its structure can be complex. This is a main reason, why
deployment of such comprehensive Transaction Guarding System is rare.
Above
described segmentation can be very useful in limiting its size and simplifying
its structure. With small number of potential network, computer and application
segments, such description is reasonably small, access control checks can be
reasonably fast and efforts needed to setup and maintain access rules can be
contained.
Basic
layers of a Transaction Guarding System are associated with:
·
Computer
·
Network
They
are independent and decentralized, setting and updating their rules requires
physical access to the computer.
They
specify
·
Which
internal users and processes in a computer can access which resources
(including network communication devices)
·
Which
external entities can communicate with which internal processes and what kind
of proof they have to provide.
On
top of them there is an inevitably centralized layer. It has to be centralized
to facilitate efficient setting and updating of access rules and efficient
monitoring and audit.
This
centralized layer is a security weakness and it should be organized properly to
mitigate security risks, which come with it. Note that in the case of a
Transaction Guarding System, an ability to misdirect the traffic through
changes in DNS database or an ability to compromise a database, where access
rules are stored, could lead to a serious attack.
Because
of its weakness, this layer requires special means of protection. They cannot
rely on hardware protection directly - basic layers already utilize it, hence
they have to rely on cryptography.
Protection
of cryptographic secrets should be delegated to basic layers.