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.

Context

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.

Clarity

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.

Goals

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.

Event Investigation Point of View

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

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 Specifics

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.

Invisible Security

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.).

Packets of Security Measures

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.

Perpetual Adjustment

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.

Simple, Reliable, Layered, and Modular

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.

Do Not Tempt

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.

Fallacy of Reliance on Obscurity

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.

Software Security and Reliability

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.

Network Segmentation

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.

Security Boundary

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

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

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.

Broad Functionality Segment

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.

"Weakest Link" Consequences

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".

Inter Segment Communication

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.

Highly Secure Segments

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.

Systemic Approach

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.

Application Design Implications

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.

Access Segmentation in Computer

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.

Segmentation of Application Set

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.

Distributed vs. Centralized Solutions

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.

Refresh

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

Security - Reliability Contradiction

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.

Audit Support

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.

Storage and Generation of Secrets

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.

Distributed vs. Centralized Approach

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.

Crucial Protection Layer

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.

Transaction Guarding

Flexible Systems

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.

Authentication of Users

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 Servers

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.

Authorization of a Set

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.

Layered Structure

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.

Defense of Centralized Layer

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.