by James E. Gilbert
March
9, 2012
Introduction
In
virtually every arena of security, the mantra has become
“defense-in-depth.” The objective is not
to rely on a single line of defense for protection but rather multiple layers
of security to delay or deter an adversary.
This approach ensures that a single failed component will not leave the
entire organization vulnerable. Although
this concept often applies to physical security, computers and their operating
systems are no different in this regard.
It is just as crucial, if not more, to employ a layered strategy to
protect operating systems. If a
cyberattack has the ability to reach “the system's foundation, it can render
almost any form of system or application security useless” (MILS, 2011). Administrators should consider a variety of
defensive measures to protect their systems and networks beginning with the
system development life cycle though when the units are put into use. This approach should begin by choosing
systems with purposely designed security functionality such as operating
systems with Multiple Independent Levels of Security (MILS) architecture or
Trusted Platform Modules (TPM). According to Carnegie Mellon's Computer Emergency Response Team (CERT), security built in is more secure, stable, and cost
effective. Rather than having to fix
operational vulnerabilities post-implementation, the same organization can take
the time to choose a system with security functionality deliberately built into
the system’s core. In one example, CERT
identified a project which experienced numerous security flaws in the
design. Had the problems been resolved
early on, the cost to the company would have been $500,000. Since the requirement problems were not
discovered until the end of the project, the cost skyrocketed to $2.5 million
(CERT, 2012). A robust security policy should also address
a procedure for auditing user activity to ensure security features and
authentication practices are being correctly enforced and not
circumvented. These defense measures
possess both advantages and disadvantages however. It is incumbent upon the organization’s
system administrator to choose effective security solutions based on ease of
implementation and associated management issues. The following paper outlines these aspects as
well as provides a ranking of the highlighted defense mechanisms with rationale
supporting the recommendations.
MILS
“Standard
commercial operating systems were not built for security” (MILS, 2011). Too often the system development life cycle
(SLDC) fails to include security activities in the initial requirements
planning and design phases. Although
including security features after the system or program is completed provides
some measure of security, it is not the ideal outcome. According to the technology research company
Gartner, a 50 percent reduction in vulnerabilities in pre-production software
has the potential to eliminate 75 percent of incident response costs (Cheng,
2007). Even though implementing these
security features throughout the design of the operating system requires
planning and forethought, the process has been shown to return enormous
dividends, both in terms of money and security.
As result of these factors, systems with built-in security have become
more popular.
MILS
architecture represents an innovative approach to operating system
security. Rather than relying on
concepts found in the Bell-LaPadula model, the system employs four primary
security policies: “Information Flow,
Data Isolation, Periods Processing, and Damage Limitation” (MILS, 2011). As a result of the ability to separate
security components into distinct and convenient elements, MILS architecture
possesses the ability to protect the system from a variety of
cyberattacks. Advantages to this
approach are numerous. Objective
Interface Systems (OIS), a company that markets this product, touts hardware
reduction, increased security, and fewer design flaws among its many
benefits. A major disadvantage to this
system however would be the relatively high cost to some organizations. Although companies that market these systems
insist that development costs are lower than upgraded commercial off-the-shelf
(COTS) alternatives, this is relative to EAL-7 certified solutions. For organizations that do not require high
assurance systems, MILS architecture may prove cost prohibitive.
Implementation
of securely designed operating systems is relatively straightforward. Due to the ability to separate security
components into manageable pieces, MILS-based architecture provides a
streamlined platform for high assurance systems. A management issue related to the employment
of secure operating systems however has been the tremendous effectiveness of
this approach. As more and more
organizations implement this solution for operating systems and software in general,
attackers have begun to find ways to circumvent the process.
Due
to the relative success of this approach, hackers and crackers have moved away
from attacking the operating systems directly and instead focused their efforts
on hardware vulnerabilities. This
provides a new set of management considerations for organizations employing
secure operating systems. It
necessitates a holistic approach to security in general encompassing an overall
strategy. Groups should not look at
secure operating systems as the sole silver bullet for system defenses. Rather, this security mechanism should be
viewed as just one layer to an information security strategy that also employs
hardened hardware, software, and personnel.
Trusted Platform Module
Another
embedded security mechanism is the Trusted Platform Module (TPM). TPM is a cryptoprocessor designed as a
hardware component mounted to the motherboard.
The TPM acts as a secure core with the capacity to provide “secure
storage, secure reporting of platform configuration measurements, and cryptographic
key generation” (Goodrich & Tamassia, 2010, p. 482). Since its initial release, this product has
shown to be a promising solution for increasing the security of computers and
their core operating systems. The
configuration of a typical operating system is one of defense mechanisms that
have been bolted on post-production.
Software patches and antivirus programs address emerging vulnerabilities
in a purely reactionary fashion. As
cyberattacks continue to escalate in both number and sophistication, the
community has sought a more proactive solution.
This in turn has created the necessity for embedded security
features. In addition to the
cryptographic functionality the TPM chips offers, this solution also provides
tamper-resistant protection. This ensures that operating systems are not only
defended against software attacks but hardware and physical ones as well.
The
secure storage and cryptographic capabilities of each TPM chip is derived from
“a unique RSA private key burned into the hardware at the time of production”
(Goodrich & Tamassia, 2010, p. 482).
Similar to the MILS configuration, the TPM is a security solution with
embedded defensive features deliberately built into the design. In “safety-critical functions or financial
transactions” where personal data is at risk, this type of approach is highly
recommended (Aaraj, Raghunathan, & Jha, 2008, p. 8-2). TPM however offers an additional benefit in
that as a hardware solution, the chip offers a tamper-resistant
configuration. Similar to MILS, TPM is
an expensive alternative to traditional operating systems. In addition the chip is somewhat bulky and
must be specially designed for the operating system it will be mounted to. If the requirement however is to maintain a
high assurance system, embedded technology such as TPM is proven to be a more
secure and less expensive route than upgraded COTS systems.
The
ease of implementing the TPM chip is similar to considerations for the MILS
architecture. This solution is an
embedded design; the chip is physically attached to the motherboard and has
specific processing and power limitations associated with it. Not every commercially available machine has
the ability to adapt this chip. Even
with these limitations, the enhanced security this approach offers has inspired
a variety of vendors to incorporate this mechanism into a wide variety of
desktops, laptops, and servers. Computer
companies as wide ranging as Dell, LG, and Toshiba now offer TPM integration on
their machines.
Although
the TPM chip is designed to be tamper-resistant, it is not impervious to
physical attack. A 2010 experiment
conducted by security researcher Christopher Tarnovsky proved that it was
indeed possible to recover unencrypted data from the chip. In his research, Tarnovsky utilized a
technique known as “microprobing” to physically recover unencrypted data from a
TPM chip. Using acid to meticulously
remove the outer shell of the microprocessor, Tarnovsky was able to expose the
chip’s core and recover secure data from the TPM. Although effective, this technique required
technical skill, months of work, and physical access to the device (Goodrich
& Tamassia, 2010). This attack
illustrates is the need for management to provide a layered defense for information
systems incorporating not only technical security but physical defenses as
well.
Auditing
Auditing,
one of the key elements of access control, is the process of reviewing “whether
adequate controls have been enabled in the operating system” (Sayana, 2003, p.
2). Every operating system (OS) has a
number of security features which can be disabled or varied based on
organizational or administrative requirements.
Because the level of security of these features can be varied, it is
incumbent upon the system’s administrator to vigilantly and regularly ensure
they are functioning appropriately. The
process of auditing ensures that OS security is properly enabled and that
“parameters have been set to values consistent with the security policy of the
organization” (Sayana, 2003, p. 2). This
function also helps guarantee that individual users have appropriate access to
system resources. Auditing is so
integral to the defense of an OS that both the Orange Book and Common Criteria
include this concept as a primary component of system security. Section C2 of the Department of Defense’s
Trusted Computer System Evaluation Criteria, also known as the Orange Book,
specifies that audit capabilities be included in systems designed for this
level of defense (Department of Defense, 1985).
Even after the Department of Defense moved to the Common Criteria, an
emphasis on auditing was still included in the technical evaluation guide. In the Common Criteria, operating systems are
evaluated based on “security audit automatic response, data generation,
analysis, audit review, event selection, and event storage” (Common Criteria,
2009).
The
major advantages to auditing are availability and ease of implementation. Virtually all operating systems have the
ability to provide system administrators with some form of an audit file. In addition, there are multitudes of software
programs security professionals can employ to provide a more detailed or
alternate view of audit-related information.
OS auditing can be tailored in any number of ways to suit various
organizational requirements. Commonly
examined parameters include rules such as password aging, length, history, and
number of unsuccessful login attempts.
System administrators can also use this technique to audit file and
print servers as well as networks. Due
to the interconnections of information systems, all nodes should be viewed as
potential risks to the operating system.
Auditing can detect unauthorized services running on a network or
inappropriate user access to print servers.
The
primary disadvantage to auditing is the amount of time needed to conduct a
proper evaluation. Although many
software applications offer a great deal in the realm of automated
functionality, proper OS auditing still requires a human being to interpret the
results. This necessitates a significant
investment in IT man-hours. In addition,
some audits have the potential to require outside expertise. According to Sayana, it is recommended that
organizations with web servers or firewalls seek expert auditing assistance
(Sayana, 2003). In this case, the
required financial expenditure associated with professional IT auditors might
prove too high for some organizations.
The
implementation of security auditing requires a system administrator with an
intimate knowledge of the various features of the OS and users on the
system. In addition to knowing which
services are authorized and what security parameters are enabled, it is also
useful to obtain a list of user IDs and map individual permissions to their
authorized data resources (Sayana, 2003).
The more an administrator knows of the operating system, its security
parameters, and the authorized users and programs, the more complete the audit
will be.
Management
issues involving auditing entail potential disruption to the organization and
its employees. In addition to the
individual required to conduct the audit, there may be lost man-hours due to an
interruption in normal business activities.
When detailed audits occur, activities outside the norm must be
resolved. This can involve time spent
questioning users as well as downtime for system resources until the issue is
resolved. For any successful auditing
activities, it is important that there be managerial level support for the
endeavor.
Ranking
Although
discussing the advantages and disadvantages of various OS security measures is
important, it is also useful to provide a quantitative measure of their
relative use. Having a specific number
ranking for each security mechanism provides a transparent tool for managerial
decision-making. The following discusses
the relative benefits and weaknesses of three OS security measures: MILS, TPM,
and Auditing. These three mechanisms
have been assessed based on their comparative advantages, disadvantages, ease
of implementation, and related managerial issues. A number ranking has been assigned for each
category (3-Good, 2-Better, 1-Best) as well as an overall score based on the
stated criteria.
Advantages
All
three defense mechanisms provide some level of increased OS security. And although it is difficult to exactly
compare hardware solutions such as MILS and TPM with auditing, there are some
inherent advantages to each. Both MILS
and TPM offer embedded security features.
Purposely designed mechanisms on both systems ensure fewer design
flaws. Although built-in security has
proven to be a significant protection for operating systems, auditing provides
a security feature for virtually every system.
Due to its availability and ease of implementation, auditing is
estimated to be the most advantageous of the three discussed security
mechanisms. While MILS architecture also
provides the added benefit of hardware reduction, TPM has the advantage of
possessing a tamper-resistant form factor.
For this reason, TPM is ranked second best.
Advantages
|
|
Audit
|
1
|
TPM
|
2
|
MILS
|
3
|
Disadvantages
Similar
to the rankings provided for the advantage’s category, each of the three
aforementioned security measures also possess inherent weaknesses. Although embedded security characteristics
like those found in TPM and MILS are better suited for overall defense, this
security comes at a cost. Unless an
organization’s mission necessitates a high assurance or EAL7 system, both
security solutions may prove cost prohibitive.
Auditing on the other hand is a purely scalable security mechanism. All operating systems have some method to
audit files and virtually any system administrator can accomplish some level of
this task. Comprehensive assessments or
audits of complex systems however may require outside expertise, which may
expend significant amounts of both time and financial resources. Given these
criteria, auditing is ranked best due to its overall applicability to a variety
of operating systems. Due to the
processing and power consumption limitations associated with TPM chips, this
mechanism is ranked last.
Disadvantages
|
|
Audit
|
1
|
MILS
|
2
|
TPM
|
3
|
Ease of Implementation
Before
any organization decides on a security measure, leadership must consider the
ease of incorporating the solution into current configurations. In this regard, MILS and TPM have an advantage
in that both are straightforward systems with embedded security features. Although TPM chips do possess power
consumption and processing limitations, there is also a software solution
available. With this implementation, TPM
functions are executed using software “in a protected execution domain on the
embedded processor itself” (Aaraj et al., 2008, p. 8-2). This translates into a potentially easier
implementation. Moreover, because there
are already a number of commercially available products offering TPM
protection, this solution is ranked first.
Although system auditing may not be difficult, done correctly it does
require a dedicated IT or security professional with a detailed knowledge of
the organization. In many small
businesses, retaining such an individual can become too expensive. For this reason, auditing is ranked
last.
Ease
of Implementation
|
|
TPM
|
1
|
MILS
|
2
|
Audit
|
3
|
Management Issues
The
last criterion to evaluate is the potential management related implications
associated with each defense mechanism.
Because both MILS and TPM are hardware related, they represent a
hardened operating system. Although this
is better for OS security, it in turn has led attackers to seek less defended
points of entry into computer systems.
As a result, management must ensure their organizations employ a
multilayer security plan incorporating physical and personnel security as well
as technical. Due to a fairly recent and
successful attack on the TPM chip, the MILS architecture is ranked best in this
category. Although auditing does not
possess the same management limitations as MILS or TPM, there can be potential
organizational disruptions associated with this security feature. Thorough audits often involve resolving
issues, which in turn can cause system downtime and interruptions to normal
business activities. For this reason,
auditing is ranked last.
Management
Issues
|
|
MILS
|
1
|
TPM
|
2
|
Audit
|
3
|
Conclusion
After
calculating the rankings from four factors (advantages, disadvantages, ease of implementation,
and management issues), it is clear that all three security mechanisms
discussed in this paper have their individual merits and specific uses. Combining the four categories, TPM and
auditing were tied for the best defensive measure while MILS architecture came
in a close second with only a one point difference. A review of the individual tools indicates
that each one has benefits and potential limitations associated with them. As a result, it can be inferred that the most
effective means of protecting an operating system is a defense-in-depth
approach incorporating a combination of security solutions.
Overall
Ranking
|
|
Audit
|
1
(8)
|
TPM
|
1
(8)
|
MILS
|
2
(9)
|
References
Aaraj,
N., Raghunathan, A., & Jha, N. K. (2008). Analysis and design of a
hardware/software trusted platform module for embedded systems. ACM Transactions on Embedded Computing
Systems, 8(1), 8-8-31, doi:10.1145/1457246.1457254
CERT
Spotlight: Building security in from the ground up. CERT. Retrieved from http://www.cert.org/
Cheng,
K. H. (2007). Baking in security during
the systems development life cycle. The
Journal of Defense Software Engineering, March, 22-25. Retrieved from https://buildsecurityin.us-cert.gov/bsi/1183-BSI/version/18/part/4/data/0703Cheng.pdf?branch=main&language=default
Common
Criteria for Information Technology Security Evaluation. (2009). Retrieved from
Department
of Defense. (1985). Trusted Computer System Evaluation Criteria. Retrieved from
http://csrc.nist.gov/publications/history/dod85.pdf
Goodrich,
M. T. & Tamassia, R. (2010). Introduction to computer security.
Boston, MA: Pearson Education.
McAfee
Labs. (2011). 2012 threats prediction. McAfee.
Retrieved from
MILS:
Multiple Independent Levels of Security. (2011). Objective Interface Systems (OIS). Retrieved from
http://www.ois.com /Products/mils-technical-primer.html
Sayana,
A. (2003). Auditing OS and database controls. Information Systems Control Journal, 3, p. 1-3. Retrieved from http://www.isaca.org/Journal/Past-Issues/2003/Volume-3/Documents/jpdf033-AuditingOSandDBControls.pdf
No comments:
Post a Comment