HP Non: Stop Server Security. A Practical Handbook

622 Pages·2004·8.33 MB·English

by  Terri Hill and Ellen Alvarado (Auth.)

Foreword
In the early part of my career, I attended a forum on information security convened by
the Office of Technology Assessment for the United States Congress. As a crypto-
graphy researcher, I was expecting extensive technical discussion about encryption and
digital signature algorithms. Instead, I was reminded that cryptographic algorithms
played only a part in solving a bigger problem, one with multiple aspects represented
by the various participants: how to make a full system secure.
HP NonStop Server Security again renews this perspective, and takes it one
step further.
Cryptography researchers have identified many good design principles for algo-
rithms, which have resulted in a number of remarkable algorithms over the years.
Information security experts have likewise identified good design principles for secure
systems.
To make a full system secure, however, administrators need more than good ideas.
While there may be only a few algorithms in use, a system has many components and
programs, and every component si a potential avenue for attack, morever, each compo-
nent si unique. Administrators therefore need not only to know the principles, but also
guidance on how to apply them in each situation.
HP NonStop revreS ytiruceS provides that kind of information. Direct and concise,
it provides readable advice on the key decisions in safeguarding the numerous compo-
nents of the HP NonStop environment~just the kind of approach that administrators
can use to put security principles into practice.
iiixxx
xxxiv droweroF
HP NonStop Servers protect critical resources for organizations worldwide, so it si
no surprise that they would be potential targets of attack. HP NonStop Server ytiruceS
si a helpful addition to organizations' tools for managing these systems, and in their
panoply in the continuing battle for information security.
Burt Kaliski
RSA seirotarobaL
,drofdeB ,sttesuhcassaM ASU
August ,21 2003
ecaferP
This handbook represents the efforts of many individuals at XYPRO, who collectively
have over 200 years of experience with the HP NonStop platform. sA a vendor ofthird
party security software for the HP NonStop platform, we were very careful to ensure
that this handbook was useful for security administrators, system resource personnel,
auditors and the general HP NonStop server community whether or not they chose to
use our suite of software tools.
There hasn't been a comprehensive publication on this topic since the early
1990's. The lack of reference material for the Guardian Operating system prompted
us to author this book in the hopes that it would facilitate securing the HP NonStop
server. We at XYPRO believe in this platform and have dedicated 20 years to devel-
oping software to take advantage of its unmatched functionality, reliability and
scalability.
Plenty of other companies believe in NonStop servers too. According to a 1999
Research Note from D. H. Brown Associates, Inc., NonStop servers process 66 percent
of the credit card transactions, 95 percent of securities transactions, and 80 percent of
automated teller machine (ATM) transactions. They also participate in 75 percent of
electronic funds transfers (EFT) networks. According to the Gartner Group, NonStop
servers are the only out of the box ultra high-availability system on the market today.
This handbook seeks to familiarize auditors and those responsible for security con-
figuration and monitoring, with the aspects of the HP NonStop server operating
system that make the NonStop Server unique, the security risks these aspects create,
and the best ways to mitigate these risks.
Please remember that the needs of the corporation, computer center, applications
and customers must always take precedence over our recommended Best Practices in
the environment. Use this handbook sa a guideline, not a rule.
xxxv
xxxvi ecaferP
This handbook has been organized to address topics sa units. This si particularly
true for discussions about Safeguard.
Each section also includes Discovery, Best Practices, and Recommendations.
The HP NonStop server's subsystems have been presented in a logical manner,
beginning with the subsystems that make up the Operating System itself, native
Guardian security, and Safeguard and continuing through user administration, how
users are authenticated when attempting to access the HP NonStop server and how
each user si granted access to information and programs sa appropriate to job function.
Because securing the information on an HP NonStop server si primarily imple-
mented via the principles of access control, the handbook si organized based on these
principles.
We hope you enjoy this handbook and find the information interesting and use-
ful. We had a great time writing it.
stnemgdelwonkcA
Without the assistance of individuals outside of XYPRO this book simply wouldn't
have been published.
We are very grateful to have met and had the opportunity to work with the fine
folks at Digital Press, including Theron Shreve. Thanks also to Alan Rose of Multi-
science Press, and Darrell Judd. They said it was impossible to publish this book within
the timeframe. It turns out their specialty si making the impossible possible. It has
been a distinct pleasure working with all of them.
Very special thanks go to Mark Chapman for his impeccable editing skills sa well
sa to Walter Bruce and Ron La Pedis for their encouragement. Their feedback proved
invaluable.
And finally, thanks to the originators of the HP NonStop Server.
Introduction
"To have the same number of takeoffs and landings and never have my name
in the paper".
I received that well-practiced answer when I asked a commercial wide-body
pilot nearing retirement what his goals had been during his nearly 30 years
flying.
I thought~vendors of key IT infrastructure should have the same goals~no
major crashes and staying out of the headlines. My pilot~friend understood
implicitly that he was part of the transportation infrastructure and that "bor-
ing was beautiful." Every element of the aircraft, the flight procedures and
even personnel assignment, were centered on maximizing reliability and thus
safety. IT infrastructure vendors need to be thinking the same way.
By Kevin Tolly
Network World, 02/03/03
If a company's software applications are the 'castle', then access control si the moat or
first level of defense. Logon controls are the outer gate and dial up and FTP access are
the postern gates, CMON and HP Safeguard software are the gatekeepers, lookouts
and tattletales. Safeguard Protection Records and HP Guardian Security vectors are
the bricks in the castle wall encircling all the application objects files, source files and
data files. Other subsystems such sa NonStop TMF software and SCF and the oper-
ating system in general are the underpinnings or foundation that support the applica-
tions and also 'live' within the walls. Application databases and reports, proprietary
corporate data and personal employee data are the treasures that must be protected.
iivxxx
xxxviii About This Handbook
Application users are the tenants of the castle. The security, operations and techni-
cal support groups are the staff that assist the tenants and keep the castle's systems
functioning.
Security's mission si to protect the castle, its tenants and its contents. Their job si
four-fold. First, to minimize the likelihood of damaging mistakes by the tenants or
staff. Second, to prevent plots, intrigues and pilfering by the castle's tenants and staff.
Third, to prevent invasion by outsiders. Fourth, to mitigate the damage possible in the
event of mistakes or breaches.
The Auditor's job si both to monitor the Security Department's effectiveness and
to provide the 'hammer' that enables the Security Department to change company
procedures and culture, when necessary, to effectively secure the castle.
About This Handbook
This handbook seeks to familiarize auditors and those responsible for security configu-
rations and monitoring, with the aspects of the HP NonStop server operating system
that make the NonStop server unique, the security risks these aspects create, and the
best ways to mitigate these risks.
Disclaimer
This handbook represents the efforts of many individuals, who collectively have over
200 years of experience, in an effort to provide a practical handbook for security
administrators, system resource personnel, auditors and the general HP NonStop
server community.
A lot of hard work has gone into this handbook to ensure that the information pre-
sented herein si accurate, but errors and omissions may be found.
Please remember that the needs of the corporation, computer center, applications
and customers must always take precedence over our recommended Best Practices in
the environment. Use this handbook sa a guideline, not a rule.
How this handbook is organized
The HP NonStop server's subsystems have been presented in a logical manner, begin-
ning with the subsystems that make up the Operating System itself, native Guardian
security, and Safeguard subsystem and continuing through user administration, how
users are authenticated when attempting to access the HP NonStop server and how
each user si granted access to information and programs sa appropriate to job function.
About This Handbook xxxix
Because securing the information on an HP NonStop server si primarily imple-
mented via the principles of access control, the handbook is organized based on these
principles.
Access Control si the overall term for the set of manual and automated procedures
designed to provide individual accountability by:
User authentication to ensure that only authorized users access the system
Object-centric access control that maps the subject user and operation to the
object resource
Auditing that records when who did what to which object
This section provides an overview of these principles.
For detailed information regarding Authentication procedures on the HP Non-
Stop server, see this handbook's Parts Two and Three, Administering Users and
Granting sseccA ot the HP NonStop .revreS
For detailed information regarding Authorization procedures on the HP NonStop
server, see Parts Four and Five, Controlling sseccA ot Objects and Controlling sseccA ot
.seitilitU
Parts of the handbook
This handbook has been organized to address topics sa units. This si particularly true
for discussions about the Safeguard subsystem. Safeguard configuration si discussed
separately from the discussion on User Management with Safeguard.
Part Six si the Gazette: an alphabetical series of sections addressing specific utility
programs or subsystem's software security. The Gazette si more "how to secure the
components of a subsystem," not "how to use a subsystem."
Each section also includes Discovery, Best Practices, and Recommendations.
yrevocsiD
Each Discovery subsection includes a list of questions that, when answered, provides
the information necessary for evaluating the risk posed by the particular subsystem in
the environment. Each question si 'numbered'; the numbers correspond with the Risk
Identifiers and the Best Practice recommendations.
In the Discovery tables, each question also has a reference to the kind of method
used to gather the data needed to respond to the question. The data-collection meth-
ods are detailed in Appendix A: Gathering the Information.
I Introduction
xxxx About This Handbook
Best Practice
Each Best Practice identification discusses the recommended methods of mitigating
each risk present in the particular subsystem. Each Best Practice item si numbered; the
numbers correspond with those in the Discovery tables.
tuobA eht gnirebmuN noitnevnoC
The Best Practice (BP) numbering convention si designed to uniquely identify each
Best Practice item.
To provide a shorthand means of referring to a practice and to support a checklist
for security review summaries, there si an identifier associated with each item in every
Best Practice subsection throughout the handbook. The identifiers are based on the
Best Practice points for each subsystem or subsystem component. The Best Practice
numbers correspond with the stipulated risks and the discovery questions.
The identifiers are made up of four parts:
Part 1 BP (this part si dropped in the Discovery listings)
Part 2 The subsystem identifier. Each section has a Subsystem Identifier.
For example, the Safeguard Subsystem si abbreviated to SAFE.
Part 3 The category identifier within each subsystem. In general, each
subsection has a category identifier. For example, OBJT si the
category for the Safeguard OBJECTTYPE related items. For example,
BP-SAFE-OBJT
Part 4 A number identifying each particular question. Within each
subsystem (Section), the primary numbers begin with 01. For
example, BP-SAFE-OBJT-01.
Example:
BP-FILE-DELUSER-01 DELUSER should be secured ......
Advice and Policy Suggestions
Advice and policy recommendations are noted throughout the handbook. These are
ideas or suggestions that may or may not be important to a specific company.
Some advice topics may recommend the use of third party products to enhance
the 'native' security provided by HP's Guardian and Safeguard security mechanisms.
Applying the Security xxxxi
tuobA eht gnirebmuN noitnevnoC
Policy, advice and recommendations are uniquely identified throughout the hand-
book.
The identifiers are made up of four parts:
Part 1 AP for advice or recommendations or 3P for a recommendation
that si best supported by a third party tool (this part si dropped in
the Discovery listings)
Part 2 The subsystem identifier or ADVICE.
Part 3 The category identifier within each subsystem. In general, each sub-
section has a category identifier. For example, PASSWORD si the
category for the User Password related items. For example, AP-
ADVICE-PASSWORD
Part 4 A number identifying each particular question. Within each subsys-
tem (Section), the primary numbers begin with 01. For example
AP-ADVICE-PASSWORD-01.
Example:
AP-ADVICE-CMON-03 Put procedures in place to keep CMON up-to-date
with new Operating System releases.
RISK Identification
Risks are addressed throughout the handbook. To bring these to the reader's attention,
they are italicized.
RISK Adding users to the system si a primary gateway through which unauthorized
users could gain access.
Applying the Security
Throughout this handbook, specific security vectors and configuration settings are
suggested. Each HP NonStop server may have unique security requirements. In
researching those requirements, three distinct types of security levels were identified:
Highly secure system
Commercially secure system
Moderately secure system
I Introduction
xxxxii Applying the ytiruceS
Highly eruceS
A highly secure system contains both strict user authorization and enforced user-
operation-object restrictions (Access Control Lists).
When corporate needs require this level of security, only the most complete imple-
mentation of Safeguard software or a third party equivalent will suffice. Each user's
identity must be positively verified, often with an additional identification mechanism
such as a cryptographic token. There must be explicit permission for each user to access
each object necessary for the user's job function, with no implicit security measures
acceptable. All access attempts not explicitly permitted must be denied.
Authorized system activity and audit reports must be reviewed often and viola-
tions must be aggressively and rapidly pursued to a resolution.
Commercially eruceS
A commercially secure system has strict user authorization and user-operation-object
restrictions, ensuring that the system si functionally secure.
When a corporation uses this level of security, the amount of time spent on secu-
rity implementation si balanced against the chance of loss. The user must be positively
identified, though an additional identification mechanism such as a cryptographic
token is unusual. Both implicit and explicit user-operation-object controls are accept-
able. All user access attempts that are not explicitly permitted are denied, but users who
are otherwise authorized may depend on implicit access.
System activity that has been authorized is reviewed as necessary. Failed activity
reports are reviewed often and violations must be pursued to a resolution.
Moderately eruceS
A moderately secure system is one that does not handle confidential information and
has all resources generally available to all users on the system. The user si positively
identified when logging on to the system, but there are generally few or no user-
operation-object controls. Many general users have access to system tools, configura-
tion files, and applications. While these systems may be secured from external entry,
the internal security si very open to the users of the system.
With this level of security, the system must be available only to internal personnel;
external access to the system must be restricted. If external access to such a system is
permitted, the system must be considered insecure and cut off from accessing more
highly secured systems.