December 2016 edition

Notices
This information was developed for products and services offered in the US.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative
for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not
intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or
service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate
and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this
document does not grant you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
United States of America
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein;
these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an
endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those
websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it believes appropriate without incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other
claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those
products.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible,
the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to
actual people or business enterprises is entirely coincidental.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many
jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.
© Copyright International Business Machines Corporation 2016.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
V11.0
Contents

TOC

Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Unit 1. Introduction to IT system security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
What is IT system security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Threats to IT systems (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Threats to IT systems (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Threats to IT systems (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Technical controls in IT system security(1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Technical controls in IT system security(2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Technical controls in IT system security(3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
System security coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
System security risk management (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36
System security risk management (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Case study: Context setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42
Case Study: Analysis of IT Department’s System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
Case study: Threat analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46
Case study: Security measures in place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-49
Case study: Vulnerability analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-55
Case study: Vulnerability mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-59
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-63
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-64
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-65
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-66
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-67

Unit 2. Operating System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Operating System & Changing Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Why OS is Hard to Secure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Securing Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Key Security Features (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Key Security Features (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Operating system history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Security in Ordinary Operating SystemsUNIX (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Security in Ordinary Operating SystemsUNIX (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Security in Ordinary Operating SystemsWindows (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
Security in Ordinary Operating SystemsWindows (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Server Operating System Security Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
Workstation Operating SystemSecurity Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
Mobile Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Threats of Mobile Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38
Threats of Mobile Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Lab: Tripwire SecureCheq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
Installation (Step -1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Installation (Step - 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45

© Copyright IBM Corp. 2016 iii

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Contents

TOC Installation (Step - 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46

Installation (Step - 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
Installation (Step - 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48
Installation (Step - 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49
Installation (Step - 7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Installation (Step - 8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51
Starting the Scan (Step - 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52
Starting the Scan (Step - 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
Starting the Scan (Step - 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
Starting the Scan (Step - 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-55
About the tool window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
About the tool window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
SecureCheq Summary Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
System aspects covered in scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59
System aspects covered in scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-60
System aspects covered in scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61
System aspects covered in scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-62
System aspects covered in scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-66
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-69
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-71
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-72
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-74
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-75
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-77
SecureCheq Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-78
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-80
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-81
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83

Unit 3. Endpoint Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
What is Endpoint Security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Pillars of Endpoint Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Endpoint Security in BYOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Endpoint Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Driver influence endpoint security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Driver influence endpoint security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
Challenges of Endpoint Security (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Challenges of Endpoint Security (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Endpoint Security Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Gartner’s Magic Quadrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Quadrant Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28
Evaluation Criteria Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30
Vendor Strengths and Limitations (1 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
Vendor Strengths and Limitations (2 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35
Vendor Strengths and Limitations (3 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38
Vendor Strengths and Limitations (4 of 6 ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42

© Copyright IBM Corp. 2016 iv

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Contents

TOC Vendor Strengths and Limitations (5 of 6 ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46

Vendor Strengths and Limitations (6 of 6 ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
Case Study 1: Palo Alto Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53
Case Study 2: Trend Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64

Unit 4. Application Server Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Application Server Security Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
SSL Keys and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Need of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Introduction to Oracle Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Security architecture of oracleapplication server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Oracle HTTP Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Oracle application server portal security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Oracle Application Server Security Best Practices(1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Oracle Application Server Security Best Practices(2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Oracle Application Server Security Best Practices(2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
Web Application Server Security best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
Introduction of mobile application server security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Introduction to OWASP ( 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
Introduction to OWASP ( 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Mobile Application Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
Identifying and protecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
Formidable App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Security Testing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37
Real-Time Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44

Unit 5. Database Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Introduction to Database Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Architecture for Database Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Database attacks,security & lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Need of Database Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Database Server threats & countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Acquiring Database and Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Securing Open Source Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Steps for Securing Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Best Practices to secure database server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
Security checklist (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Security checklist (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31
Database Security Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Database Security Program Design (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37
Database Security Program Design (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47

© Copyright IBM Corp. 2016 v

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Contents

TOC Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48

Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49

Unit 6. IT System Security Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Identification of risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Organizational Assets Used in Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Identifying assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Threat Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Prioritizing System Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Prepare for Selecting Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Initial Security Control Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Apply Scoping Guidance (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Apply Scoping Guidance (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Analyzing System Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Planning for security in the system lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Applying Operational Controls (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Applying Operational Controls (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Contingency Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Maintenance controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Data integrity/validation controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
Implementing Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36
Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-39
Important security considerations (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41
Important security considerations (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-43
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-49
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50

Appendix A. Review answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

© Copyright IBM Corp. 2016 vi

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Trademarks

TMK

Trademarks
The reader should recognize that the following terms, which appear in the content of this training
document, are official trademarks of IBM or other companies:
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide.
The following are trademarks of International Business Machines Corporation, registered in many
jurisdictions worldwide:
AIX® Approach® BigFix®
DB™ DB2® Domino®
Express® Insight™ Lotus Notes®
Lotus® Notes® Power®
QRadar® Tivoli® Trusteer®
Intel is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United
States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT and Windows Vista are trademarks of Microsoft Corporation in
the United States, other countries, or both.
Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of
Oracle and/or its affiliates.
UNIX is a registered trademark of The Open Group in the United States and other countries.
VMware and the VMware "boxes" logo and design, Virtual SMP and VMotion are registered
trademarks or trademarks (the "Marks") of VMware, Inc. in the United States and/or other
jurisdictions.
Trusteer Apex™ is a trademark or registered trademark of Trusteer, an IBM Company.
Other product and service names might be trademarks of IBM or other companies.

© Copyright IBM Corp. 2016 vii

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Course description

pref

Course description
IT Systems Security

Purpose
This course will provide you an insight into the aspects of IT system security. The book is segregated into six
theory chapters and one lab unit. The first unit introduces the need of IT system security, the technical
controls involved, and the expanse of system security. The second unit introduces some threats faced by
operating system, highlights their evolving nature, and provides an insight into the security guidelines for
various operating systems. In the third unit, you will get to know about the prime threats that drive the need of
endpoint security solutions. The fourth unit uses the case of Oracle application server to expose various
application server threats and acquaints to necessary countermeasures. Fifth unit gives an overview of
various database security mechanisms and the practices of database administrator in securing a database
server. Sixth unit introduces various tools, techniques and processes involved in securing an IT system and
how these processes complement each other in implementation of system security. Final unit covers the lab
aspect of the course, which emphasize on the identification of vulnerabilities of an operating system and the
practices to be undertaken to mitigate them.

Important

This course consists of several independent modules. The modules, including the lab exercises, stand on
their own and do not depend on any other content.

Audience
The audience of this course is Bachelor of Technology (B. Tech) Students, who are pursuing 6th Semester.

Prerequisites
This course is designed keeping in view of the engineering students with basic knowledge of the subject.

Objectives
• To appreciate the need and coverage of IT System Security
• To tackle security issues faced by modern operating systems
• To follow security guidelines
• To identify the components of endpoint security
• To deploy endpoint security solutions
• To recognise attacks on application servers
• To take countermeasures on application server attacks
• To device methodology of securing open source databases
• To gain insight on the processes involved in the application of system security
• To address the security vulnerabilities in the Windows operating system

© Copyright IBM Corp. 2016 viii

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Unit 1. Introduction to IT system

security
Overview
This unit provides an insight on the background, need and coverage of IT system security.

How you will check your progress

• Checkpoint

© Copyright IBM Corp. 2016 1-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Unit objectives IBM ICE (Innovation Centre for Education)

IBM Power Systems

After completing this unit, you should be able to:

• Get an overview of IT system security
• Understand need of IT system security
• Get familiar with technical controls in IT system security
• Gain insight on system security risk management
• Understand transformation trends

© Copyright IBM Corporation 2016

Figure 1-1. Unit objectives

© Copyright IBM Corp. 2016 1-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

What is IT system security? IBM ICE (Innovation Centre for Education)

IBM Power Systems

• IT system security covers everything from prevention, detection and response to improper
access from within and outside an organization, to protect information and systems
• As the critical importance of IT systems grows daily, so does the volume of targeted attacks,
internal fraud and other security risks from which IT systems need to be defended.
• Elements of IT system security
– Vulnerability
– Threat
– Risk
– Exposure
– Countermeasure or Safeguard
– The Relation Between the Security Elements

© Copyright IBM Corporation 2016

Figure 1-2. What is IT system security?

Security is defined, in general terms, as the state of being secure i.e. free from danger. The objective is to
provide or acquire protection against harmful elements, that might be intentionally created or unintentionally
released in systems.
Broadly speaking, IT system security covers everything from prevention, detection and response to improper
access from within and outside an organization, to protect information and systems. A little leniency in
application of security can result in grave consequences. For example, if the access control mechanism is not
maintained properly, it might result in improper access resulting in damage, alteration or misuse of
information and the systems. It is never wise to assume that an IT system is completely secure, irrespective
of the product, service or security measure deployed.
A layered approach to security is often found in place at organizations. It helps track the security of
operations across multiple facets:
• Physical Security: Protection of physical items; maintenance of appropriate authorization to restricted
(operations sensitive areas)
• Personnel Security: Protection of individual(s) who have access to systems and operations
• Operations Security: Protection of the information or details pertaining to operations of organization
• Communications Security: Protection and maintenance of communications technology and media
• Network Security: Protection of networking components and connections
• Information Security: Protection of confidentiality, integrity and availability of information assets, via the
application of policy, education, training and awareness, and technology

© Copyright IBM Corp. 2016 1-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
As the technology is getting smarter, enterprise-wide networks and virtual private networks (VPNs) are being
increasingly used by organizations to link their systems which also increases their exposure on the internet.
Corporate networks are becoming more and more vulnerable as hackers are succeeding to continuously
come up with new ways of attacking them. The security market is being pushed even higher as the
innovations continue to present themselves. But with the exponential growth, there have been increasing
needs of enterprise class security. Wireless client devices, like Wi-Fi VoIP handsets are the frontrunners for
this need of security. Organizations are finally willing to invest in some serious security measures and are
slowly losing their faith on traditional ways to stop viruses and malware. Increased service reliability is the
most important payback respondents expect from managed security service.
Goals of IT System Security
Information Technology systems are generally defined by all of a company's data and the material and
software resources that allow a company to store and circulate this data. IT systems are essential to
companies and must be protected. IT security generally consists in ensuring that an organization's IT
systems and software resources are used only for their intended purposes.
IT security generally is comprised of five main goals:
• Integrity: guaranteeing that the data are those that they are believed to be
• Confidentiality: ensuring that only authorized individuals have access to the resources being
exchanged
• Availability: guaranteeing the system's proper operation
• Non-repudiation: guaranteeing that an operation cannot be denied
• Authentication: ensuring that only authorized individuals have access to the resources
Elements of IT System Security
Vulnerability
▪ It is a software, hardware, or procedural weakness that may provide an attacker the open door he is
looking for to enter a computer or network and have unauthorized access to resources within the
environment
▪ Vulnerability characterizes the absence or weakness of a safeguard that could be exploited. For
example, a service running on a server, unpatched applications or operating system software,
unrestricted modem dial-in access, an open port on a firewall, lack of physical security etc.
Threat
▪ Any potential danger to information or systems.
▪ A threat is a possibility that someone (person, software) would identify and exploit the vulnerability
▪ The entity that takes advantage of vulnerability is referred to as a threat agent. For example, a threat
agent could be an intruder accessing the network through a port on the firewall
Risk
▪ Risk is the likelihood of a threat agent taking advantage of vulnerability and the corresponding
business impact
▪ Reducing vulnerability and/or threat reduces the risk
▪ For example, if a firewall has several ports open, there is a higher likelihood that an intruder will use
one to access the network in an unauthorized method
Exposure
▪ An exposure is an instance of being exposed to losses from a threat agent
▪ Vulnerability exposes an organization to possible damages
▪ For example, if password management is weak and password rules are not enforced, the company is
exposed to the possibility of having users' passwords captured and used in an unauthorized manner

© Copyright IBM Corp. 2016 1-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Countermeasure or Safeguard
▪ It is an application or a s/w configuration or h/w or a procedure that mitigates the risk
▪ For example, strong password management, a security guard, access control mechanisms within an
operating system, the implementation of basic input/output system (BIOS) passwords, and
security-awareness training
The Relation Between the Security Elements
▪ For example, if a company has antivirus software but does not keep the virus signatures up-to-date,
this is a vulnerability. The company is vulnerable to virus attacks
▪ The threat is that a virus will show up in the environment and disrupt productivity
▪ The likelihood of a virus showing up in the environment and causing damage is the risk
▪ If a virus infiltrates the company's environment, then vulnerability has been exploited and the
company is exposed to loss
▪ The countermeasures in this situation are to update the signatures and install the antivirus software
on all computers
The analysis and management of risk usually has to be modified if a system is installed in a vehicle or is
portable, such as a laptop computer. The system in a vehicle will share the risks of the vehicle, including
accidents and theft, as well as regional and local risks.
Portable and mobile systems share an increased risk of theft and physical damage. In addition, portable
systems can be "misplaced" or left unattended by careless users. Secure storage of laptop computers is
often required when they are not in use.
If a mobile or portable system uses particularly valuable or important data, it may be appropriate to either
store its data on a medium that can be removed from the system when it is unattended or to encrypt the data.
In any case, the issue of how custody of mobile and portable computers are to be controlled should be
addressed. Depending on the sensitivity of the system and its application, it may be appropriate to require
briefings of users and signed briefing acknowledgments.

© Copyright IBM Corp. 2016 1-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Threats to IT systems (1 of 3) IBM ICE (Innovation Centre for Education)

IBM Power Systems

# Category of Threat Examples

1 Compromises to intellectual property Piracy, copyright infringement

2 Software attacks Viruses, worms, macros, denial of service

3 Deviations in quality of service ISP, power, or WAN service issues from service providers

4 Espionage or trespass Unauthorized access and/or data collection

© Copyright IBM Corporation 2016

Figure 1-3. Threats to IT systems (1 of 3)

Threats to IT Systems
1. Compromises to intellectual property
The term “intellectual property” refers to the ownership of ideas and control over the virtual representation
of those ideas. The creation or support of the development of intellectual property is found to be
integrated with business operations of organizations. It is mandatory that proper credit to the source is
included when their intellectual property is being used by a second party, regardless of the presence of
any royal payments or permissions.
Many organizations create, or support the development of, intellectual property (IP) as part of their
business operations. Intellectual property is defined as “the ownership of ideas and control over the
tangible or virtual representation of those ideas. Use of another person’s intellectual property may or may
not involve royalty payments or permission, but should always include proper credit to the source.”
Intellectual property can be trade secrets, copyrights, trademarks, and patents. The unauthorized
appropriation of IP constitutes a threat to information security. Employees may have access privileges to
the various types of IP, and may be required to use the IP to conduct day-to-day business.
The most common IP breach is the unlawful use or duplication of software-based intellectual property,
more commonly known as software piracy. Many individuals and organizations do not purchase software
as mandated by the owner’s license agreements. Because most software is licensed to a particular
purchaser, its use is restricted to a single user or to a designated user in an organization. If the user
copies the program to another computer without securing another license or transferring the license, he
or she has violated the copyright. Software licenses are strictly enforced by a number of regulatory and

© Copyright IBM Corp. 2016 1-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
private organizations, and software publishers use several control mechanisms to prevent copyright
infringement.
A number of technical mechanisms - digital watermarks and embedded code, copyright codes, and even
the intentional placement of bad sectors on software media - have been used to enforce copyright laws.
The most common tool, a license agreement window that usually pops up during the installation of new
software, establishes that the user has read and agrees to the license agreement.
Another effort to combat piracy is the online registration process. Individuals who install software are
often asked or even required to register their software to obtain technical support or the use of all
features. Some believe that this process compromises personal privacy, because people never really
know exactly what information is obtained from their computers and sent to the software manufacturer.
2. Deliberate software attacks
Deliberate software attacks occur when an individual or group designs and deploys software to attack a
system. Most of this software is referred to as malicious code or malicious software, or sometimes
malware. These software components or programs are designed to damage, destroy, or deny service to
the target systems. Some of the more common instances of malicious code are viruses and worms,
Trojan horses, logic bombs, and back doors.
Virus
A computer virus consists of segments of code that perform malicious actions. This code behaves very
much like a virus pathogen that attacks animals and plants, using the cell’s own replication machinery to
propagate the attack beyond the initial target. The code attaches itself to an existing program and takes
control of that program’s access to the targeted computer. The virus-controlled target program then
carries out the virus’s plan by replicating itself into additional targeted systems. Many times users
unwittingly help viruses get into a system. Opening infected e-mail or some other seemingly trivial action
can cause anything from random messages popping up on a user’s screen to the complete destruction of
entire hard drives of data. Just as their namesakes are passed among living bodies, computer viruses
are passed from machine to machine via physical media, e-mail, or other forms of computer data
transmission.
When these viruses infect a machine, they may immediately scan the local machine for e-mail
applications, or even send themselves to every user in the e-mail address book. One of the most
common methods of virus transmission is via e-mail attachment files. Most organizations block e-mail
attachments of certain types and also filter all e-mail for known viruses. In earlier times, viruses were
slow-moving creatures that transferred viral payloads through the cumbersome movement of diskettes
from system to system. Now, computers are networked, and e-mail programs prove to be fertile ground
for computer viruses unless suitable controls are in place.
The current software marketplace has several established vendors, such as Symantec Norton Anti-Virus
and McAfee VirusScan, that provide applications to assist in the control of computer viruses. Among the
most common types of viruses are the macro virus, which is embedded in automatically executing macro
code used by word processors, spread sheets, and database applications, and the boot virus, which
infects the key operating system files located in a computer’s boot sector.
Worms
Named for the Tapeworm in John Brunner’s novel The Shockwave Rider, a worm is a malicious program
that replicates itself constantly, without requiring another program environment. Worms can continue
replicating themselves until they completely fill available resources, such as memory, hard drive space,
and network bandwidth. Code Red, Sircam, Nimda (“admin” spelled backwards), and Klez are examples
of a class of worms that combines multiple modes of attack into a single package. Newer worm variants
are found to contain multiple exploits that can use any of the many predefined distribution vectors to
programmatically distribute the worm. The Klez virus, delivers a double-barrelled payload: it has an
attachment that contains the worm, and if the e-mail is viewed on an HTML-enabled browser, it attempts
to deliver a macro virus. News-making attacks, such as MS-Blaster, MyDoom, and Netsky, are variants of
the multifaceted attack worms and viruses that exploit weaknesses in the leading operating systems and
applications. The complex behavior of worms can be initiated with or without the user downloading or
executing the file. Once the worm has infected a computer, it can redistribute itself to all e-mail addresses

© Copyright IBM Corp. 2016 1-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
found on the infected system. Furthermore, a worm can deposit copies of itself onto all Web servers that
the infected system can reach, so that users who subsequently visit those sites become infected. Worms
also take advantage of open shares found on the network in which an infected system is located, placing
working copies of the worm code onto the server so that users of those shares are likely to become
infected.
Trojan Horses
Trojan horses are software programs that hide their true nature and reveal their designed behavior only
when activated. Trojan horses are frequently disguised as helpful, interesting, or necessary pieces of
software, such as readme.exe files often included with shareware or freeware packages. Unfortunately,
like their namesake in Greek legend, once Trojan horses are brought into a system, they become
activated and can wreak havoc on the unsuspecting user.
Back Door or Trap Door
A virus or worm can have a payload that installs a back door or trap door component in a system, which
allows the attacker to access the system at will with special privileges. Examples of these kinds of
payloads include Subseven and Back Orifice.
Polymorphic Threats
One of the biggest challenges to fighting viruses and worms has been the emergence of polymorphic
threats. A polymorphic threat is one that over time changes the way it appears to antivirus software
programs, making it undetectable by techniques that look for preconfigured signatures. These viruses
and worms actually evolve, changing their size and other external file characteristics to elude detection
by antivirus software programs.
Virus and Worm Hoaxes
As frustrating as viruses and worms are, perhaps more time and money is spent on resolving virus
hoaxes. Well-meaning people can disrupt the harmony and flow of an organization when they send group
e-mails warning of supposedly dangerous viruses that don’t exist. When people fail to follow
virus-reporting procedures, the network becomes overloaded, and much time and energy is wasted as
users forward the warning message to everyone they know, post the message on bulletin boards, and try
to update their antivirus protection software.
3. Deviations in quality of service
An organization’s IT system depends on the successful operation of many interdependent support
systems, including power grids, telecom networks, parts suppliers, service vendors, and even the
janitorial staff and garbage haulers. Any one of these support systems can be interrupted by storms,
employee illnesses, or other unforeseen events. Deviations in quality of service can result from incidents
such as a backhoe taking out a fiber-optic link for an ISP. The backup provider may be online and in
service, but may be able to supply only a fraction of the bandwidth the organization needs for full service.
This degradation of service is a form of availability disruption. Irregularities in Internet service,
communications, and power supplies can dramatically affect the availability of information and systems.
Internet Service Issues
In organizations that rely heavily on the Internet and the World Wide Web to support continued
operations, Internet service provider failures can considerably undermine the availability of information.
Many organizations have sales staff and telecommuters working at remote locations. When these offsite
employees cannot contact the host systems, they must use manual procedures to continue operations.
When an organization places its Web servers in the care of a Web hosting provider, that provider
assumes responsibility for all Internet services as well as for the hardware and operating system software
used to operate the Web site.
Communications and Other Service Provider Issues
Other utility services can affect organizations as well. Among these are telephone, water, wastewater,
trash pickup, cable television, natural or propane gas, and custodial services. The loss of these services
can impair the ability of an organization to function. For instance, most facilities require water service to

© Copyright IBM Corp. 2016 1-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
operate an air-conditioning system. If a wastewater system fails, an organization might be prevented
from allowing employees into the building.
Power Irregularities
Irregularities from power utilities are common and can lead to fluctuations such as power excesses,
power shortages, and power losses. This can pose problems for organizations that provide inadequately
conditioned power for their IT system equipment. When voltage levels spike (experience a momentary
increase), or surge (experience a prolonged increase), the extra voltage can severely damage or destroy
equipment. Equally disruptive are power shortages from a lack of available power. A momentary low
voltage or sag, or a more prolonged drop in voltage, known as a brownout, can cause systems to shut
down or reset, or otherwise disrupt availability. Complete loss of power for a moment is known as a fault,
and a lengthier loss as a blackout. Because sensitive electronic equipment - especially networking
equipment, computers, and computer-based systems - are vulnerable to fluctuations, controls should be
applied to manage power quality. With small computers and network systems, quality power-conditioning
options such as surge suppressors can smooth out spikes.
4. Espionage or trespass
Espionage or trespass is a well-known and broad category of electronic and human activities that can
breach the confidentiality of information. When an unauthorized individual gains access to the
information an organization is trying to protect, that act is categorized as espionage or trespass.
Attackers can use many different methods to access the information stored in an IT system. Some
information gathering techniques are quite legal, for example, using a Web browser to perform market
research. These legal techniques are called, collectively, competitive intelligence. When information
gatherers employ techniques that cross the threshold of what is legal or ethical, they are conducting
industrial espionage.
Acts of trespass can lead to unauthorized real or virtual actions that enable information gatherers to enter
premises or systems they have not been authorized to enter. Controls sometimes mark the boundaries of
an organization’s virtual territory. These boundaries give notice to trespassers that they are encroaching
on the organization’s cyberspace. Sound principles of authentication and authorization can help
organizations protect valuable information and systems. These control methods and technologies
employ multiple layers or factors to protect against unauthorized access. The classic perpetrator of
espionage or trespass is the hacker. Hackers are “people who use and create computer software [to]
gain access to information illegally.” Hackers are frequently glamorized in fictional accounts as people
who stealthily manipulate a maze of computer networks, systems, and data to find the information that
solves the mystery or saves the day. Television and motion pictures are inundated with images of
hackers as heroes or heroines. However, the true life of the hacker is far more mundane. In the real
world, a hacker frequently spends long hours examining the types and structures of the targeted systems
and uses skill, guile, or fraud to attempt to bypass the controls placed around information that is the
property of someone else.
There are generally two skill levels among hackers. The first is the expert hacker, orelite hacker, who
develops software scripts and program exploits used by those in the second category, the novice or
unskilled hacker. The expert hacker is usually a master of several programming languages, networking
protocols, and operating systems and also exhibits a mastery of the technical environment of the chosen
targeted system. Expert hackers are extremely talented individuals who usually devote lots of time and
energy to attempting to break into other people’s systems. Once an expert hacker chooses a target
system, the likelihood that he or she will successfully enter the system is high. Fortunately for the many
poorly protected organizations in the world, there are substantially fewer expert hackers than novice
hackers. Expert hackers, dissatisfied with attacking systems directly, have turned their attention to writing
software. These programs are automated exploits that allow novice hackers to act as script kiddies -
hackers of limited skill who use expertly written software to attack a system - or packet monkeys - script
kiddies who use automated exploits to engage in distributed denial-of-service attacks. The good news is
that if an expert hacker can post a script tool where a script kiddie or packet monkey can find it, then
systems and security administrators can find it, too. The developers of protection software and hardware
and the service providers who keep defensive systems up to date also keep themselves informed of the

© Copyright IBM Corp. 2016 1-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
latest in exploit scripts. As a result of preparation and continued vigilance, attacks conducted by scripts
are usually predictable and can be adequately defended against.
There are other terms for system rule breakers that may be less familiar. The term cracker is now
commonly associated with an individual who cracks or removes software protection that is designed to
prevent unauthorized duplication. With the removal of the copyright protection, the software can be easily
distributed and installed. The terms hacker and cracker in current usage denote criminal intent.
A phreaker hacks the public telephone network to make free calls or disrupt services. Phreakers grew in
fame in the 1970s when they developed devices called blue boxes that enabled free calls from pay
phones. Later, red boxes were developed to simulate the tones of coins falling in a pay phone, and finally
black boxes emulated the line voltage. With the advent of digital communications, these boxes became
practically obsolete. Even with the loss of the colored box technologies, phreakers continue to cause
problems for all telephone systems.

© Copyright IBM Corp. 2016 1-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Threats to IT systems (1 of 3) IBM ICE (Innovation Centre for Education)

IBM Power Systems

# Category of Threat Examples

5 Forces of nature Fire, flood, earthquake, lightening

6 Human error or failure Accidents, employee mistakes

7 Information extortion Blackmail, information disclosure

Missing, inadequate, or incomplete Loss of access to systems due to disk drive failure without
8 controls organizational policy or proper backup and recovery plan organizational policy or
planning planning in place

© Copyright IBM Corporation 2016

Figure 1-4. Threats to IT systems (1 of 3)

5. Forces of nature
Forces of nature, force majeure, or acts of God can present some of the most dangerous threats,
because they usually occur with very little warning and are beyond the control of people. These threats,
which include events such as fires, floods, earthquakes, and lightning as well as volcanic eruptions and
insect infestations, can disrupt not only the lives of individuals but also the storage, transmission, and use
of information. Some of the more common threats in this group are listed here.
Fire
In this context, usually a structural fire that damages a building housing computing equipment that
comprises all or part of a system, as well as smoke damage and/or water damage from sprinkler systems
or firefighters. This threat can usually be mitigated with fire casualty insurance and/or business
interruption insurance.
Flood
An overflowing of water onto an area that is normally dry, causing direct damage to all or part of the
system or to the building that houses all or part of the system. A flood might also disrupt operations
through interruptions in access to the buildings that house all or part of the system. This threat can
sometimes be mitigated with flood insurance and/or business interruption insurance.
Earthquake
A sudden movement of the earth’s crust caused by the release of stress accumulated along geologic
faults or by volcanic activity. Earthquakes can cause direct damage to all or part of the IT system or, more
often, to the building that houses it, and can also disrupt operations through interruptions in access to the

© Copyright IBM Corp. 2016 1-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
buildings that house all or part of the IT system. This threat can sometimes be mitigated with specific
casualty insurance and/or business interruption insurance, but is usually a separate policy.
Lightning
An abrupt, discontinuous natural electric discharge in the atmosphere. Lightning usually directly
damages all or part of the IT system and/or its power distribution components. It can also cause fires or
other damage to the building that houses all or part of the IT system, and disrupt operations by interfering
with access to the buildings that house all or part of the IT system. This threat can usually be mitigated
with multipurpose casualty insurance and/or business interruption insurance.
Landslide or mudslide
The downward sliding of a mass of earth and rock directly damaging all or part of the IT system or, more
likely, the building that houses it. Land- or mudslides also disrupt operations by interfering with access to
the buildings that house all or part of the IT system. This threat can sometimes be mitigated with casualty
insurance and/or business interruption insurance.
Tornado or severe windstorm
A rotating column of air ranging in width from a few yards to more than a mile and whirling at destructively
high speeds, usually accompanied by a funnel-shaped downward extension of a cumulonimbus cloud.
Storms can directly damage all or part of the IT system or, more likely, the building that houses it, and can
also interrupt access to the buildings that house all or part of the IT system. This threat can sometimes be
mitigated with casualty insurance and/or business interruption insurance.
Hurricane or typhoon
A severe tropical cyclone originating in the equatorial regions of the Atlantic Ocean or Caribbean Sea or
eastern regions of the Pacific Ocean (typhoon), traveling north, northwest, or northeast from its point of
origin, and usually involving heavy rains. These storms can directly damage all or part of the IT system
or, more likely, the building that houses it. Organizations located in coastal or low-lying areas may
experience flooding. These storms may also disrupt operations by interrupting access to the buildings
that house all or part of the IT system. This threat can sometimes be mitigated with casualty insurance
and/or business interruption insurance.
Tsunami
A very large ocean wave caused by an underwater earthquake or volcanic eruption. These events can
directly damage all or part of the IT system or, more likely, the building that houses it. Organizations
located in coastal areas may experience tsunamis. Tsunamis may also cause disruption to operations
through interruptions in access or electrical power to the buildings that house all or part of the IT system.
This threat can sometimes be mitigated with casualty insurance and/or business interruption insurance.
Electrostatic discharge (ESD)
Usually, static electricity and ESD are little more than a nuisance. Unfortunately, however, the mild static
shock we receive when walking across a carpet can be costly or dangerous when it ignites flammable
mixtures and damages costly electronic components. Static electricity can draw dust into clean-room
environments or cause products to stick together. The cost of ESD-damaged electronic devices and
interruptions to service can range from only a few cents to several millions of dollars for critical systems.
Loss of production time in information processing due to ESD impact is significant. While not usually
viewed as a threat, ESD can disrupt IT systems, but it is not usually an insurable loss unless covered by
business interruption insurance.
Dust contamination
Some environments are not friendly to the hardware components of IT systems. Because dust
contamination can shorten the life of IT systems or cause unplanned downtime, this threat can disrupt
normal operations.
Since it is not possible to avoid force of nature threats, organizations must implement controls to limit
damage, and they must also prepare contingency plans for continued operations, such as disaster
recovery plans, business continuity plans, and incident response plans.

© Copyright IBM Corp. 2016 1-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
6. Human error or failure
This category includes acts performed without intent or malicious purpose by an authorized user. When
people use IT systems, mistakes happen. Inexperience, improper training, and the incorrect assumptions
are just a few things that can cause these misadventures. Regardless of the cause, even innocuous
mistakes can produce extensive damage.
For example, a simple keyboarding error can cause worldwide Internet outages: In April 1997, the core of
the Internet suffered a disaster. Internet service providers lost connectivity with other ISPs due to an error
in a routine Internet router table update process. The resulting outage effectively shut down a major
portion of the Internet for at least twenty minutes. It has been estimated that about 45 percent of Internet
users were affected. In July 1997, the Internet went through yet another more critical global shutdown for
millions of users. An accidental upload of a corrupt database to the Internet’s root domain servers
occurred. Since this provides the ability to address hosts on the net by name (i.e., eds.com), it was
impossible to send e-mail or access Web sites within the .com and .net domains for several hours. The
.com domain comprises a majority of the commercial enterprise users of the Internet.
One of the greatest threats to an organization’s information security is the organization’s own employees.
Employees are the threat agents closest to the organizational data. Because employees use data in
everyday activities to conduct the organization’s business, their mistakes represent a serious threat to the
confidentiality, integrity, and availability of data - even relative to threats from outsiders. This is because
employee mistakes can easily lead to the following: revelation of classified data, entry of erroneous data,
accidental deletion or modification of data, storage of data in unprotected areas, and failure to protect
information. Leaving classified information in unprotected areas, such as on a desktop, on a Web site, or
even in the trash can, is as much a threat to the protection of the information as is the individual who
seeks to exploit the information, because one person’s carelessness can create a vulnerability and thus
an opportunity for an attacker. However, if someone damages or destroys data on purpose, the act
belongs to a different threat category. Much human error or failure can be prevented with training and
ongoing awareness activities, but also with controls, ranging from simple procedures, such as requiring
the user to type a critical command twice, to more complex procedures, such as the verification of
commands by a second party. An example of the latter is the performance of key recovery actions in PKI
systems. Many military applications have robust, dual-approval controls built in.
7. Information Extortion
Information extortion occurs when an attacker or trusted insider steals information from a computer
system and demands compensation for its return or for an agreement not to disclose it. Extortion is
common in credit card number theft. For example, Web-based retailer CD Universe was the victim of a
theft of data files containing customer credit card information. The culprit was a Russian hacker named
Maxus, who hacked the online vendor and stole several hundred thousand credit card numbers. When
the company refused to pay the $100,000 blackmail, he posted the card numbers to a website, offering
them to the criminal community. His website became so popular he had to restrict access.
Another incident of extortion occurred in 2008 when pharmacy benefits manager Express Scripts, Inc. fell
victim to a hacker who demonstrated that he had access to seventy-five customer records and claimed to
have access to millions. The perpetrator demanded an undisclosed amount of money. The company
notified the FBI and offered a $1 million reward for the arrest of the perpetrator. Express Scripts notified
the affected customers, as required by various state information breach notification laws. Express Scripts
was obliged to pay undisclosed expenses for the notifications, as well as for credit monitoring services
that the company was required by some state laws to buy for its customers.
8. Missing, inadequate, or incomplete organizational policy or planning
Missing, inadequate, or incomplete organizational policy or planning makes an organization vulnerable to
loss, damage, or disclosure of information assets when other threats lead to attacks. Information security
is, at its core, a management function. The organization’s executive leadership is responsible for
strategic planning for security as well as for IT and business functions - a task known as governance.

© Copyright IBM Corp. 2016 1-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Threats to IT systems (3 of 3) IBM ICE (Innovation Centre for Education)

IBM Power Systems

# Category of Threat Examples

Missing, inadequate, or incomplete Network compromised because of absence of firewall

9
controls controls

10 Sabotage or vandalism Destruction of systems or information

11 Theft Illegal confiscation of equipment or information

12 Technical hardware failures or errors Equipment failure

13 Technical software failures or errors Bugs, code problems, unknown loopholes

14 Technological obsolescence Antiquated or outdated technologies

© Copyright IBM Corporation 2016

Figure 1-5. Threats to IT systems (3 of 3)

9. Missing, inadequate, or incomplete controls

Missing, inadequate, or incomplete controls - that is, security safeguards and information asset
protection controls that are missing, misconfigured, antiquated, or poorly designed or managed - make
an organization more likely to suffer losses when other threats lead to attacks. For example, if a small
organization installs its first network using small office/home office (SOHO) equipment (which is similar to
the equipment you might have on your home network) and fails to upgrade its network equipment as it
becomes larger, the increased traffic can affect performance and cause information loss. Routine security
audits to assess the current levels of protection help to ensure the continuous protection of organization’s
assets.
10. Sabotage or vandalism
This category of threat involves the deliberate sabotage of a computer system or business, or acts of
vandalism to either destroy an asset or damage the image of an organization. These acts can range from
petty vandalism by employees to organized sabotage against an organization. Although not necessarily
financially devastating, attacks on the image of an organization are serious. Vandalism to a website can
erode consumer confidence, thus diminishing an organization’s sales and net worth, as well as its
reputation. Compared to Web site defacement, vandalism within a network is more malicious in intent
and less public. Today, security experts are noticing a rise in another form of online vandalism, hacktivist
or cyber activist operations, which interfere with or disrupt systems to protest the operations, policies, or
actions of an organization or government agency.

© Copyright IBM Corp. 2016 1-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
A much more sinister form of hacking is cyberterrorism. Cyberterrorists hack systems to conduct
terrorist activities via network or Internet pathways. Governments are developing security measures
intended to protect the critical computing and communications networks as well as the physical and
power utility infrastructures.
11. Theft
The threat of theft - the illegal taking of another’s property, which can be physical, electronic, or
intellectual - is a constant. The value of information is diminished when it is copied without the owner’s
knowledge.
Physical theft can be controlled quite easily by means of a wide variety of measures, from locked doors to
trained security personnel and the installation of alarm systems. Electronic theft, however, is a more
complex problem to manage and control. When someone steals a physical object, the loss is easily
detected; if it has any importance at all, its absence is noted. When electronic information is stolen, the
crime is not always readily apparent. If thieves are clever and cover their tracks carefully, no one may
ever know of the crime until it is far too late.
12. Technical hardware failures or errors
Technical hardware failures or errors occur when a manufacturer distributes equipment containing a
known or unknown flaw. These defects can cause the system to perform outside of expected parameters,
resulting in unreliable service or lack of availability. Some errors are terminal - that is, they result in the
unrecoverable loss of the equipment. Some errors are intermittent, in that they only periodically manifest
themselves, resulting in faults that are not easily repeated, and thus, equipment can sometimes stop
working, or work in unexpected ways.
13. Technical software failures or errors
Large quantities of computer code are written, debugged, published, and sold before all their bugs are
detected and resolved. Sometimes, combinations of certain software and hardware reveal new bugs.
These failures range from bugs to untested failure conditions. Sometimes these bugs are not errors, but
rather purposeful shortcuts left by programmers for benign or malign reasons. Collectively, shortcut
access routes into programs that bypass security checks are called trap doors and can cause serious
security breaches.
14. Technological obsolescence
Antiquated or outdated infrastructure can lead to unreliable and untrustworthy systems. Management
must recognize that when technology becomes outdated, there is a risk of loss of data integrity from
attacks. Management’s strategic planning should always include an analysis of the technology currently
in use. Ideally, proper planning by management should prevent technology from becoming obsolete, but
when obsolescence is manifest, management must take immediate action. IT professionals play a large
role in the identification of probable obsolescence.
As Internet use is increasing, more and more companies are opening their IT system to their partners and
suppliers. Therefore, it is essential to know which of the company's resources need protecting and to control
system access and the user rights of the IT system. The same is true when opening company access on the
Internet.
Moreover, because of today's increasingly nomadic lifestyle, which allows employees to connect to IT
systems from virtually anywhere, employees are required to carry a part of the IT system outside of the
company's secure infrastructure.
Risk in terms of security is generally characterized by the following equation:
Risk = Threat * Vulnerability / Counter measure
The threat represents the type of action that is likely to be of harm, whereas vulnerability (sometimes called
flaws or breaches) represents the level of exposure to threats in a particular context. Finally, the
countermeasure is all of the actions implemented to prevent the threat.
The countermeasures to be implemented are not only technical solutions but also include user training and
awareness as well as a clearly defined rules.

© Copyright IBM Corp. 2016 1-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
In order to secure a system, the potential threats must be identified so as to identify and anticipate the
enemy's course of action. Therefore, the goal of this report is to provide an overview of possible hacker
motivations, categorize them and give an idea of how they work in order to better know how to limit the risk of
intrusion.
Needs for information technology systems security and trust can be formulated in terms of several major
requirements:
• Data confidentiality - controlling who gets to read information in order to keep sensitive information from
being disclosed to unauthorized recipients - e.g., preventing the disclosure of classified information to an
adversary
• Data integrity - assuring that information and programs are changed, altered, or modified only in a
specified and authorized manner - e.g., preventing an adversary from modifying orders given to combat
units so as to shape battlefield events to his advantage
• System availability - assuring that authorized users have continued and timely access to information
and resources - e.g., preventing an adversary from flooding a network with bogus traffic that delays
legitimate traffic such as that containing new orders from being transmitted
• System configuration - assuring that the configuration of a system or a network is changed only in
accordance with established security guidelines and only by authorized users - e.g., detecting and
reporting to higher authority the improper installation of a modem that can be used for remote access

© Copyright IBM Corp. 2016 1-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Technical controls in IT system security

(1 of 3) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Identification and Authentication

– Identification and Authentication Based on Something the User Knows
• Passwords
• Cryptographic Keys
– Identification and Authentication Based on Something the User Possesses
• Memory Tokens
• Smart Tokens
– Identification and Authentication Based on Something the User Is

© Copyright IBM Corporation 2016

Figure 1-6. Technical controls in IT system security(1 of 3)

Identification and Authentication

For most systems, Identification and Authentication is the first line of defense. Identification and
Authentication is a technical measure that prevents unauthorized people (or unauthorized processes) from
entering a computer system.
Identification and Authentication is a critical building block of computer security since it is the basis for most
types of access control and for establishing user accountability. Access control often requires that the system
be able to identify and differentiate among users. For example, access control is often based on least
privilege, which refers to the granting to users of only those accesses required to perform their duties. User
accountability requires the linking of activities on a computer system to specific individuals and, therefore,
requires the system to identify users.
Identification is the means by which a user provides a claimed identity to the system. Authentication is the
means of establishing the validity of this claim. IT systems recognize people based on the authentication data
the systems receive. Authentication presents several challenges: collecting authentication data, transmitting
the data securely, and knowing whether the person who was originally authenticated is still the person using
the computer system. For example, a user may walk away from a terminal while still logged on, and another
person may start using it.
There are three means of authenticating a user's identity which can be used alone or in combination:
• Something the individual knows (a secret e.g., a password, Personal Identification Number (PIN), or
cryptographic key)
• Something the individual possesses (a token e.g., an ATM card or a smart card); and

© Copyright IBM Corp. 2016 1-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
• Something the individual is (a biometric e.g., such characteristics as a voice pattern, handwriting
dynamics, or a fingerprint)
While it may appear that any of these means could provide strong authentication, there are problems
associated with each. If people wanted to pretend to be someone else on a computer system, they can
guess or learn that individual's password; they can also steal or fabricate tokens. Each method also has
drawbacks for legitimate users and system administrators: users forget passwords and may lose tokens, and
administrative overhead for keeping track of Identification and Authentication data and tokens can be
substantial. Biometric systems have significant technical, user acceptance, and cost problems as well.
Identification and Authentication Based on Something the User Knows
The most common form of Identification and Authentication is a user ID coupled with a password. This
technique is based solely on something the user knows. There are other techniques besides
conventional passwords that are based on knowledge, such as knowledge of a cryptographic key.
Passwords
In general, password systems work by requiring the user to enter a user ID and password (or
passphrase or personal identification number). The system compares the password to a previously
stored password for that user ID. If there is a match, the user is authenticated and granted access.
Benefits of Passwords: Passwords have been successfully providing security for computer
systems for a long time. They are integrated into many operating systems, and users and system
administrators are familiar with them. When properly managed in a controlled environment, they can
provide effective security.
Problems with Passwords: The security of a password system is dependent upon keeping
passwords secret. Unfortunately, there are many ways that the secret may be divulged. All of the
problems discussed below can be significantly mitigated by improving password security, as
discussed in the sidebar. However, there is no fix for the problem of electronic monitoring, except to
use more advanced authentication (e.g., based on cryptographic techniques or tokens).
i. Guessing or finding passwords: If users select their own passwords, they tend to make them
easy to remember. That often makes them easy to guess. The names of people's children, pets,
or favorite sports teams are common examples. On the other hand, assigned passwords may be
difficult to remember, so users are more likely to write them down. Many computer systems are
shipped with administrative accounts that have preset passwords. Because these passwords are
standard, they are easily "guessed." Although security practitioners have been warning about
this problem for years, many system administrators still do not change default passwords.
Another method of learning passwords is to observe someone entering a password or PIN. The
observation can be done by someone in the same room or by someone some distance away
using binoculars. This is often referred to as shoulder surfing.
ii. Giving passwords away: Users may share their passwords. They may give their password to a
co-worker in order to share files. In addition, people can be tricked into divulging their
passwords. This process is referred to as social engineering.
iii. Electronic monitoring: When passwords are transmitted to a computer system, they can be
electronically monitored. This can happen on the network used to transmit the password or on
the computer system itself. Simple encryption of a password that will be used again does not
solve this problem because encrypting the same password will create the same cipher text; the
cipher text becomes the password.
iv. Accessing the password file: If the password file is not protected by strong access controls,
the file can be downloaded. Password files are often protected with one-way encryption so that
plain-text passwords are not available to system administrators or hackers (if they successfully
bypass access controls). Even if the file is encrypted, brute force can be used to learn
passwords if the file is downloaded (e.g., by encrypting English words and comparing them to the
file).
Passwords Used as Access Control: Some mainframe operating systems and many PC
applications use passwords for restricting access to specific resources within a system. Instead of

© Copyright IBM Corp. 2016 1-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
using mechanisms such as access control lists, access is granted by entering a password. The
result is a proliferation of passwords that can reduce the overall security of a system. While the use
of passwords as a means of access control is common, it is an approach that is often less than
optimal and not cost-effective.
Cryptographic Keys
Although the authentication derived from the knowledge of a cryptographic key may be based
entirely on something the user knows, it is necessary for the user to also possess (or have access to)
something that can perform the cryptographic computations, such as a PC or a smart card. For this
reason, we have discussed the protocols in the Smart Tokens section. However, it is possible to
implement these types of protocols without using a smart token. Additional discussion is also
provided under the Single Log-in section.
Identification and Authentication Based on Something the User Possesses
Although some techniques are based solely on something the user possesses, most of the techniques
described in this section are combined with something the user knows. This combination can provide
significantly stronger security than either something the user knows or possesses alone.
Objects that a user possesses for the purpose of Identification and Authentication are called tokens. This
section divides tokens into two categories: memory tokens and smart tokens.
Memory Tokens
Memory tokens store, but do not process, information. Special reader/writer devices control the
writing and reading of data to and from the tokens. The most common type of memory token is a
magnetic striped card, in which a thin strips of magnetic material is affixed to the surface of a card
(e.g., as on the back of credit cards). A common application of memory tokens for authentication to
computer systems is the automatic teller machine (ATM) card. This uses a combination of something
the user possesses (the card) with something the user knows (the PIN).

Some computer systems authentication technologies are based solely on possession of a token, but
they are less common. Token-only systems are more likely to be used in other applications, such as
for physical access.
Benefits of Memory Token Systems: Memory tokens when used with PINs provide significantly
more security than passwords. In addition, memory cards are inexpensive to produce. For a hacker
or another would-be masquerade to pretend to be someone else, the hacker must have both a valid
token and the corresponding PIN. This is much more difficult than obtaining a valid password and
user ID combination (especially since most user IDs are common knowledge).
Another benefit of tokens is that they can be used in support of log generation without the need for
the employee to key in a user ID for each transaction or another logged event since the token can be
scanned repeatedly. If the token is required for physical entry and exit, then people will be forced to
remove the token when they leave the computer. This can help maintain authentication.
Problems with Memory Token Systems: Although sophisticated technical attacks are possible
against memory token systems, most of the problems associated with them relate to their cost,
administration, token loss, user dissatisfaction, and the compromise of PINs. Most of the techniques
for increasing the security of memory token systems relate to the protection of PINs. Many of the
techniques discussed in the sidebar on Improving Password Security apply to PINs.
i. Requires special reader: The need for a special reader increases the cost of using memory
tokens. The readers used for memory tokens must include both the physical unit that reads the
card and a processor that determines whether the card and/or the PIN entered with the card is
valid. If the PIN or token is validated by a processor that is not physically located with the reader,
then the authentication data is vulnerable to electronic monitoring (although cryptography can be
used to solve this problem).
ii. Token loss: A lost token may prevent the user from being able to log in until a replacement is
provided. This can increase administrative overhead costs. The lost token could be found by

© Copyright IBM Corp. 2016 1-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
someone who wants to break into the system, or could be stolen or forged. If the token is also
used with a PIN, any of the methods described above in password problems can be used to
obtain the PIN. Common methods are finding the PIN taped to the card or observing the PIN
being entered by the legitimate user. In addition, any information stored on the magnetic stripe
that has not been encrypted can be read.
iii. User Dissatisfaction: In general, users want computers to be easy to use. Many users find it
inconvenient to carry and present a token. However, their dissatisfaction may be reduced if they
see the need for increased security.
Smart Tokens
A smart token expands the functionality of a memory token by incorporating one or more integrated
circuits into the token itself. When used for authentication, a smart token is another example of
authentication based on something a user possesses (i.e., the token itself). A smart token typically
requires a user also to provide something the user knows (i.e., a PIN or password) in order to
"unlock" the smart token for use.
There are many different types of smart tokens. In general, smart tokens can be divided three
different ways based on physical characteristics, interface, and protocols used. These three
divisions are not mutually exclusive.
Physical Characteristics: Smart tokens can be divided into two groups: smart cards and other
types of tokens. A smart card looks like a credit card, but incorporates an embedded
microprocessor. Smart cards are defined by an International Standards Organization (ISO) standard.
Smart tokens that are not smart cards can look like calculators, keys, or other small portable objects.
Interface: Smart tokens have either a manual or an electronic interface. Manual or human interface
tokens have displays and/or keypads to allow humans to communicate with the card. Smart tokens
with electronic interfaces must be read by special reader/writers. Smart cards, described above,
have an electronic interface. Smart tokens that look like calculators usually have a manual interface.
Protocol: There are many possible protocols a smart token can use for authentication. In general,
they can be divided into three categories: static password exchange, dynamic password generators,
and challenge-response.
- Static tokens work similarly to memory tokens, except that the users authenticate themselves to
the token and then the token authenticates the user to the computer.
- A token that uses a dynamic password generator protocol creates a unique value, for example,
an eight-digit number, that changes periodically (e.g., every minute). If the token has a manual
interface, the user simply reads the current value and then types it into the computer system for
authentication. If the token has an electronic interface, the transfer is done automatically. If the
correct value is provided, the log-in is permitted, and the user is granted access to the system.
- Tokens that use a challenge-response protocol work by having the computer generate a
challenge, such as a random string of numbers. The smart token then generates a response
based on the challenge. This is sent back to the computer, which authenticates the user based
on the response. The challenge-response protocol is based on cryptography.
Challenge-response tokens can use either electronic or manual interfaces.
There are other types of protocols, some more sophisticated and some less so. The three types
described above are the most common.
Benefits of Smart Tokens: Smart tokens offer great flexibility and can be used to solve many
authentication problems. The benefits of smart tokens vary, depending on the type used. In general,
they provide greater security than memory cards. Smart tokens can solve the problem of electronic
monitoring even if the authentication is done across an open network by using one-time passwords.
i. One-time passwords: Smart tokens that use either dynamic password generation or
challenge-response protocols can create one-time passwords. Electronic monitoring is not a
problem with one-time passwords because each time the user is authenticated to the computer,
a different "password" is used. (A hacker could learn the one-time password through electronic
monitoring, but would be of no value.)

© Copyright IBM Corp. 2016 1-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
ii. Reduced risk of forgery: Generally, the memory on a smart token is not readable unless the
PIN is entered. In addition, the tokens are more complex and, therefore, more difficult to forge.
iii. Multi-application: Smart tokens with electronic interfaces, such as smart cards, provide a way
for users to access many computers using many networks with only one log-in. In addition, a
single smart card can be used for multiple functions, such as physical access or as a debit card.
Problems with Smart Tokens: Like memory tokens, most of the problems associated with smart
tokens relate to their cost, the administration of the system, and user dissatisfaction. Smart tokens
are generally less vulnerable to the compromise of PINs because authentication usually takes place
on the card. (It is possible, of course, for someone to watch a PIN being entered and steal that card.)
Smart tokens cost more than memory cards because they are more complex, particularly
challenge-response calculators.
i. Need reader/writers or human intervention: Smart tokens can use either an electronic or a
human interface. An electronic interface requires a reader, which creates additional expense.
Human interfaces require more actions from the user. This is especially true for
challenge-response tokens with a manual interface, which require the user to type the challenge
into the smart token and the response into the computer. This can increase user dissatisfaction.
ii. Substantial Administration: Smart tokens, like passwords and memory tokens, require strong
administration. For tokens that use cryptography, this includes key management.
Identification and Authentication Based on Something the User Is
Biometric authentication technologies use the unique characteristics (or attributes) of an individual to
authenticate that person's identity. These include physiological attributes (such as fingerprints, hand
geometry, or retina patterns) or behavioral attributes (such as voice patterns and hand-written
signatures). Biometric authentication technologies based upon these attributes have been developed for
computer log-in applications.
Biometric authentication is technically complex and expensive, and user acceptance can be difficult.
However, advances continue to be made to make the technology more reliable, less costly, and more
user-friendly.
Biometric systems can provide an increased level of security for computer systems, but the technology is
still less mature than that of memory tokens or smart tokens. Imperfections in biometric authentication
devices arise from technical difficulties in measuring and profiling physical attributes as well as from the
somewhat variable nature of physical attributes. These may change, depending on various conditions.
For example, a person's speech pattern may change under stressful conditions or when suffering from a
sore throat or cold. Due to their relatively high cost, biometric systems are typically used with other
authentication means in environments requiring high security.

© Copyright IBM Corp. 2016 1-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Technical controls in IT system security

(2 of 3) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Logical Access Control

– Access Criteria
• Passwords
• Access Control Lists
• Encryption
• Constrained User Interfaces
• Security Labels
– Policy: The Impetus for Access Controls
• Memory Tokens
• Smart Tokens
– Technical Implementation Mechanism
• Internal Access Controls
• External Access Controls
– Administration of Access Controls
• Centralized Administration
• Decentralized Administration
• Hybrid Approach
– Coordinating Access Controls

© Copyright IBM Corporation 2016

Figure 1-7. Technical controls in IT system security(2 of 3)

Logical Access Control

On many multiuser systems, requirements for using (and prohibitions against the use of) various computer
resources vary considerably. Typically, for example, some information must be accessible to all users, some
may be needed by several groups or departments, and some should be accessed by only a few individuals.
While it is obvious that users must have access to the information they need to do their jobs, it may also be
required to deny access to non-job-related information. It may also be important to control the kind of access
that is afforded (e.g., the ability for the average user to execute, but not change, system programs). These
types of access restrictions enforce policy and help ensure that unauthorized actions are not taken.
Access is the ability to do something with a computer resource (e.g., use, change, or view). Access control is
the means by which the ability is explicitly enabled or restricted in some way (usually through physical and
system-based controls). Computer-based access controls are called logical access controls. Logical access
controls can prescribe not only who or what (e.g., in the case of a process) is to have access to a specific
system resource but also the type of access that is permitted. These controls may be built into the operating
system, may be incorporated into applications programs or major utilities (e.g., database management
systems or communications systems), or may be implemented through add-on security packages. Logical
access controls may be implemented internally to the computer system being protected or may be
implemented in external devices.
Logical access controls can help protect:
• operating systems and other system software from unauthorized modification or manipulation (and
thereby help ensure the system's integrity and availability)

© Copyright IBM Corp. 2016 1-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
• the integrity and availability of information by restricting the number of users and processes with access;
and
• confidential information from being disclosed to unauthorized individuals
Access Criteria
In deciding whether to permit someone to use a system resource logical access controls examine
whether the user is authorized for the type of access requested. (Note that this inquiry is usually distinct
from the question of whether the user is authorized to use the system at all, which is usually addressed in
an identification and authentication process.)
The system uses various criteria to determine if a request for access will be granted. They are typically
used in some combination. Many of the advantages and complexities involved in implementing and
managing access control are related to the different kinds of user accesses supported.
Identity
It is probably fair to say that the majority of access controls are based upon the identity of the user
(either human or process), which is usually obtained through identification and authentication. The
identity is usually unique, to support individual accountability, but can be a group identification or can
even be anonymous. For example, public information dissemination systems may serve a large
group called "researchers" in which the individual researchers are not known.
Roles
Access to information may also be controlled by the job assignment or function (i.e., the role) of the
user who is seeking access. Examples of roles include data entry clerk, purchase officer, project
leader, programmer, and technical editor. Access rights are grouped by role name, and the use of
resources is restricted to individuals authorized to assume the associated role. An individual may be
authorized for more than one role, but may be required to act in only a single role at a time.
Changing roles may require logging out and then in again, or entering a role-changing command.
Note that use of roles is not the same as shared-use accounts. An individual may be assigned a
standard set of rights of a shipping department data entry clerk, for example, but the account would
still be tied to that individual's identity to allow for auditing.
Location
Access to particular system resources may also be based upon physical or logical location. For
example, in a prison, all users in areas to which prisoners are physically permitted may be limited to
read-only access. Changing or deleting is limited to areas to which prisoners are denied physical
access. The same authorized users (e.g., prison guards) would operate under significantly different
logical access controls, depending upon their physical location. Similarly, users can be restricted
based upon network addresses (e.g., users from sites within a given organization may be permitted
greater access than those from outside).
Time
Time-of-day or day-of-week restrictions are common limitations on access. For example, use of
confidential personnel files may be allowed only during normal working hours and maybe denied
before 8:00 a.m. and after 6:00 p.m. and all day during weekends and holidays.
Transaction
Another approach to access control can be used by organizations handling transactions (e.g.,
account inquiries). Phone calls may first be answered by a computer that requests that callers key in
their account number and perhaps a PIN. Some routine transactions can then be made directly, but
more complex ones may require human intervention. In such cases, the computer, which already
knows the account number, can grant a clerk, for example, access to a particular account for the
duration of the transaction. When completed, the access authorization is terminated. This means
that users have no choice in which accounts they have access to, and can reduce the potential for
mischief. It also eliminates employee browsing of accounts (e.g., those of celebrities or their
neighbours) and can thereby heighten privacy.
Service Constraints

© Copyright IBM Corp. 2016 1-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Service constraints refer to those restrictions that depend upon the parameters that may arise during
use of the application or that are pre-established by the resource owner/manager. For example, a
particular software package may only be licensed by the organization for five users at a time. Access
would be denied for a sixth user, even if the user were otherwise authorized to use the application.
Another type of service constraint is based upon application content or numerical thresholds. For
example, an ATM machine may restrict transfers of money between accounts to certain dollar limits
or may limit maximum ATM withdrawals to $500 per day. Access may also be selectively permitted
based on the type of service requested. For example, users of computers on a network may be
permitted to exchange electronic mail but may not be allowed to log in to each others’ computers.
Common Access Modes
In addition to considering criteria for when access should occur, it is also necessary to consider the
types of access, or access modes. The concept of access modes is fundamental to access control.
Common access modes, which can be used in both operating or application systems, include the
following:
- Read access provides users with the capability to view information in a system resource (such as
a file, certain records, certain fields, or some combination thereof), but not to alter it, such as
delete from, add to, or modify in any way. One must assume that information can be copied and
printed if it can be read (although perhaps only manually, such as by using a print screen function
and retyping the information into another file).
- Write access allows users to add to, modify, or delete information in system resources (e.g., files,
records, programs). Normally user have read access to anything they have write access to.
- Execute privilege allows users to run programs.
- Delete access allows users to erase system resources (e.g., files, records, fields, programs).
Note that if users have write access but not delete access, they could overwrite the field or file
with gibberish or otherwise inaccurate information and, in effect, delete the information.
Other specialized access modes (more often found in applications) include:
- Create access allows users to create new files, records, or fields.
- Search access allows users to list the files in a directory.
Of course, these criteria can be used in conjunction with one another. For example, an organization
may give authorized individuals write access to an application at any time from within the office but
only read access during normal working hours if they dial-in. Depending upon the technical
mechanisms available to implement logical access control, a wide variety of access permissions and
restrictions are
possible. No discussion can present all possibilities.
Policy: The Impetus for Access Controls
Logical access controls are a technical means of implementing policy decisions. Policy is made by a
management official responsible for a particular system, application, subsystem, or group of systems.
The development of an access control policy may not be an easy endeavour. It requires balancing the
often-competing interests of security, operational requirements, and user-friendliness. In addition,
technical constraints have to be considered.
A few simple examples of specific policy issues are provided below; it is important to recognize, however,
that comprehensive system-specific policy is significantly more complex.
▪ The director of an organization's personnel office could decide that all clerks can update all files, to
increase the efficiency of the office. Or the director could decide that clerks can only view and update
specific files, to help prevent information browsing.
▪ In a disbursing office, a single individual is usually prohibited from both requesting and authorizing
that a particular payment be made. This is a policy decision taken to reduce the likelihood of
embezzlement and fraud.
▪ Decisions may also be made regarding access to the system itself.

© Copyright IBM Corp. 2016 1-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Technical Implementation Mechanism
Many mechanisms have been developed to provide internal and external access controls, and they vary
significantly in terms of precision, sophistication, and cost. These methods are not mutually exclusive
and are often employed in combination. Managers need to analyze their organization's protection
requirements to select the most appropriate, cost-effective logical access controls.
Internal Access Controls
Internal access controls are a logical means of separating what defined users (or user groups) can or
cannot do with system resources. Five methods of internal access control are discussed below,
namely, passwords, access control lists, encryption, constrained user interfaces, and labels.
Passwords
Passwords are most often associated with user authentication. However, they are also used to
protect data and applications on many systems, including PCs. For instance, an accounting
application may require a password to access certain financial data or to invoke a restricted
application (or function of an application).
Password-based access control is often inexpensive because it is already included in a large
variety of applications. However, users may find it difficult to remember additional application
passwords, which, if written down or poorly chosen, can lead to their compromise.
Password-based access controls for PC applications are often easy to circumvent if the user has
access to the operating system (and knowledge of what to do).
Access Control Lists
Access Control Lists (ACLs) refer to a register of:
1) the types of access that have been permitted
2) users (including machines, groups, processes) possessing permission to use a specific
system resource
Capability and flexibility are two considerably variable factors in ACLs. Some only allow
specifications for certain pre-set groups (e.g., owner, group, and world) while more advanced
ACLs allow much more flexibility, such as user-defined groups. A particular group or individual
can be denied access by ACLs that are more advanced. Depending upon the technical
implementation of controls, a more advanced ACL would mean that access can be at the
discretion of the individual user, or the policymaker (which are in turn implemented by the
security administrator).
Encryption
Another mechanism that can be used for logical access control is encryption. Encrypted
information can only be decrypted by those possessing the appropriate cryptographic key. This
is especially useful if strong physical access controls cannot be provided, such as for laptops or
floppy diskettes. Thus, for example, if information is encrypted on a laptop computer, and the
laptop is stolen, the information cannot be accessed. While encryption can provide strong
access control, it is accompanied by the need for strong key management. Use of encryption
may also affect availability. For example, lost or stolen keys or read/write errors may prevent the
decryption of the data.
Elementary ACLs
Elementary ACLs (e.g., "permission bits") are a widely available means of providing access
control on multiuser systems. In this scheme, a short, predefined list of the access rights to
files or other system resources is maintained.
Owner, group, and world concepts are what elementary ACLs are based on. For every one of
these, a set of access modes (typically chosen from read, write, execute, and delete) is
specified by the owner (or custodian) of the resource. The creator is usually the owner;
however, the project administrators are automatically assigned ownership of resources in

© Copyright IBM Corp. 2016 1-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
some cases irrespective of the creator’s identity. All privileges for resources are often with
the file owners.
Apart from assigning privileges to the owner, a named group of users is identified and each
resource is associated with it. Modes of access can be granted to the members of this group.
However, the non-members, i.e. the rest of the users of the system do not enjoy any such
privileges. The user groups can be arranged as per their projects or departments, or basis
any other distinction parameter. For example, groups may be established for members of the
Personnel and Accounting departments. The system administrator is normally responsible
for technically maintaining and changing the membership of a group, based upon input from
the owners/custodians of the particular resources to which the groups may be granted
access.
As the name implies, however, the technology is not particularly flexible. It may not be
possible to explicitly deny access to an individual who is a member of the file's group. Also, it
may not be possible for two groups to easily share information (without exposing it to the
"world"), since the list is predefined to only include one group. If two groups wish to share
information, an owner may make the file available to be read by "world." This may disclose
information that should be restricted. Unfortunately, elementary ACLs have no mechanism to
easily permit such sharing.
Advanced ACLs
Like elementary ACLs, advanced ACLs provide a form of access control based upon a
logical registry. They do, however, provide finer precision in control.
Advanced ACLs can be very useful in many complex information sharing situations. They
provide a great deal of flexibility in implementing system-specific policy and the security
requirement of functional managers can be met as they allow room for customization. There
is also a challenge of their management owing to the increased flexibility. Security
administrators can get confused over the inconsistency of rules that determine access in
face of conflicting ACL entries. In order to ensure their correct use, these systems should be
coupled with training upon their introduction.
Constrained User Interfaces
Often used in conjunction with ACLs are constrained user interfaces, which restrict users' access
to specific functions by never allowing them to request the use of information, functions, or other
specific system resources for which they do not have access. Three major types exist:
1) Database views
2) menus, and
3) physically constrained user interfaces
User access to data contained in a database is restricted by data base views. There can be
cases when a user just needs some fields of a record or just some records in the database and
not need all the data in the database. But it might be necessary to allow that user to the
database. To address such complex access requirements, views can be used based on the
contents of a field. Let us take an example of a hypothetical situation where the database records
are being maintained by clerks. A range of clients is assigned to the clerks. The range of clients
is assigned based on their last names (for e.g., A-D, E-H). Now, using the first letter of the last
name, user access can be granted by view, instead of granting a user access to all records.
A form of access control, closely modelling the operating mechanism of an organization, is
provided by constrained user interfaces. It is often seen that the users’ ability to use the
application system or operating system directly is restricted by administrators. Users are only
allowed to execute commands provided, in the form of a menu, by the administrator. The system
commands invoked by the user can be limited through restricted shells. Errors can be reduced
and the system is made easier to use by using menus and shells.

© Copyright IBM Corp. 2016 1-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
User’s abilities can also be limited by physically constrained user interfaces. A common example
is an ATM machine. There is no alphabetic keyboard present and there are only a limited number
of physical buttons to select options is provided by it.
Security Labels
A security label is a designation assigned to a resource (such as a file). Labels can be used for a
number of purposes. This includes specifying protective measures, controlling access, or
indicating additional handling instructions. This designator, once set, cannot be changed.
Labels are assigned to user sessions, when used for access control, and only those users can
initiate sessions that are assigned some specific labels. Only a restricted number are thus able to
initiate sessions. The output of the session is labelled using the labels of the session and labels
of the files accessed ensuring that the information is protected.
Though being a very reliable and strong access control method, labels can be rendered inflexible
and their administration can sometimes be costly. Unlike permission bits or access control lists,
labels cannot ordinarily be changed. Since labels are permanently linked to specific information,
data cannot be disclosed by a user copying information and changing the access to that file so
that the information is more accessible than the intentions of the original owner. By removing
users' ability to arbitrarily designate the accessibility of files they own, opportunities for certain
kinds of human errors and malicious software problems are eliminated. In the example above, it
would not be possible to copy Organization Proprietary Information into a file with a different
label. This prevents inappropriate disclosure, but can interfere with legitimate extraction of some
information. Labels are well suited for consistently and uniformly enforcing restriction son
access, but their usage can be deterred by the expensive administration and flexibility issues.
External Access Controls
External access controls are a means of controlling interactions between the system and outside
people, systems, and services. External access controls use a wide variety of methods, often
including a separate physical device (e.g., a computer) that is between a network and a system
which is being protected.
Port Protection Devices
Fitted to a communications port of a host computer, a port protection device (PPD) authorizes
access to the port itself, prior to and independent of the computer's own access control functions.
A PPD can be a separate device in the communications stream, or it may be incorporated into a
communications device (e.g., a modem). PPDs typically require a separate authenticator, such
as a password, in order to access the communications port.
Secure Gateways/Firewalls
Often called firewalls, secure gateways block or filter access between two networks, often
between a private network and a larger, more public network such as the Internet, which attract
malicious hackers. Secure gateways allow internal users to connect to external networks and at
the same time prevent malicious hackers from compromising the internal systems.
Some secure gateways are set up to allow all traffic to pass through except for specific traffic
which has known or suspected vulnerabilities or security problems, such as remote log-in
services. Other secure gateways are set up to disallow all traffic except for specific types, such
as e-mail. Some secure gateways can make access-control decisions based on the location of
the requester. There are several technical approaches and mechanisms used to support secure
gateways.
Because gateways provide security by restricting services or traffic, they can affect a system's
usage. For this reason, firewall experts always emphasize the need for policy. This enables
appropriate officials to take decision on balancing the operational needs and security of the
organization.
In addition to reducing the risks from malicious hackers, secure gateways have several other
benefits. They can reduce internal system security overhead, since they allow an organization to

© Copyright IBM Corp. 2016 1-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
concentrate security efforts on a limited number of machines. (This is similar to putting a guard
on the first floor of a building instead of needing a guard on every floor.)
A second benefit is the centralization of services. A secure gateway can be used to provide a
central management point for various services, such as advanced authentication, e-mail, or
public dissemination of information. Having a central management point can improve service
and reduce system overhead.
Host-Based Authentication
Instead of referring to the identity of the user making access request, host-based authentication
uses the identity of the host from where the request is initiated, to grant access. Host-based
authentication is used by many network applications to check if access is allowed or not. Under
certain circumstances it is fairly easy to masquerade as the legitimate host, especially if the
masquerading host is physically located close to the host being impersonated. However, there
are security measures available to protect against misuse of some host-based authentication
systems.
Administration of Access Controls
One of the most complex and challenging aspects of access control, administration involves
implementing, monitoring, modifying, testing, and terminating user accesses on the system. These can
be demanding tasks, even though they typically do not include making the actual decisions as to the type
of access each user may have. Decisions regarding accesses should be guided by organizational policy,
employee job descriptions and tasks, information sensitivity, user "need-to-know" determinations, and
many other factors.
There are three basic approaches to administering access controls: centralized, decentralized, or a
combination of these. Each has relative advantages and disadvantages. Which is most appropriate in a
given situation will depend upon the particular organization and its circumstances.
Centralized Administration
Using centralized administration, one office or individual is responsible for configuring access
controls. As users' information processing needs change, their accesses can be modified only
through the central office, usually after requests have been approved by the appropriate official. This
allows very strict control over information, because the ability to make changes resides with very few
individuals. Account of each user can be easily monitored and in case an individual leaves the
organization, it is easy to close all accesses pertaining to that particular user. Since not many
individuals oversee the process, consistent and uniform procedures and criteria are usually not
difficult to enforce. However, when changes are needed quickly, going through a central
administration office can be frustrating and time-consuming.
Decentralized Administration
In decentralized administration, the owners or creators of the files, (often the functional manager)
directly control the access. This keeps control in the hands of those most accountable for the
information, most familiar with it and its uses, and best able to judge who needs what kind of access.
This may lead, however, to a lack of consistency among owners/creators as to procedures and
criteria for granting user accesses and capabilities. Also, when requests are not processed centrally,
it may be much more difficult to form a system-wide composite view of all user accesses on the
system at any given time. Different application or data owners may inadvertently implement
combinations of accesses that introduce conflicts of interest or that are in some other way not in the
organization's best interest. It may also be difficult to ensure that all accesses are properly
terminated when an employee transfers internally or leaves an organization.
Hybrid Approach
A hybrid approach combines centralized and decentralized administration. One typical arrangement
is that central administration is responsible for the broadest and most basic accesses, and the
owners/creators of files control types of accesses or changes in users' abilities for the files under
their control. The main disadvantage to a hybrid approach is adequately defining which accesses
should be assignable locally and which should be assignable centrally.

© Copyright IBM Corp. 2016 1-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Coordinating Access Controls
It is vital that access controls protecting a system work together. At a minimum, three basic types of
access controls should be considered: physical, operating system, and application. In general, access
controls within an application are the most specific. However, for application access controls to be fully
effective they need to be supported by operating system access controls. Otherwise access can be made
to application resources without going through the application. Operating system and application access
controls need to be supported by physical access controls.

© Copyright IBM Corp. 2016 1-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Technical controls in IT system security

(3 of 3) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Cryptography
– Basic Cryptographic Technologies
• Secret Key Cryptography
• Public Key Cryptography
• Hybrid Cryptographic Systems
• Key Escrow
– Uses of Cryptography
• Data Encryption
• Integrity
• Electronic Signatures
• User Authentication

Distinct features Secret key cryptography Public key cryptography

Number of keys Single key Pair of keys

Types of keys Key is a secret One key is private, and one key is public
Disclosure and modification for private keys
Protection of keys Disclosure and modification
and modification for public key
Relative speeds Faster Slower

© Copyright IBM Corporation 2016

Figure 1-8. Technical controls in IT system security(3 of 3)

Cryptography
Cryptography is a branch of mathematics based on the transformation of data. It provides an important tool
for protecting information and is used in many aspects of computer security. For example, cryptography can
help provide data confidentiality, integrity, electronic signatures, and advanced user authentication. Although
modern cryptography relies upon advanced mathematics, users can reap its benefits without understanding
its mathematical underpinnings.
Basic Cryptographic Technologies
There are two basic types of cryptography: secret key systems (also called symmetric systems) and
public key systems (also called asymmetric systems). Both types of systems offer advantages and
disadvantages. Often, the two are combined to form a hybrid system to exploit the strengths of each
type. To determine which type of cryptography best meets its needs, an organization first has to identify
its security requirements and operating environment.
Secret Key Cryptography
In secret key cryptography, two (or more) parties share the same key, and that key is used to encrypt
and decrypt data. As the name implies, secret key cryptography relies on keeping the key secret. If
the key is compromised, the security offered by cryptography is severely reduced or eliminated.
Secret key cryptography assumes that the parties who share a key rely upon each other not to
disclose the key and protect it against modification.
Public Key Cryptography

© Copyright IBM Corp. 2016 1-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Whereas secret key cryptography uses a single key shared by two (or more) parties, public key
cryptography uses a pair of keys for each party. One of the keys of the pair is "public" and the other
is "private." The public key can be made known to other parties; the private key must be kept
confidential and must be known only to its owner. Both keys, however, need to be protected against
modification. Public key cryptography is particularly useful when the parties wishing to communicate
cannot rely upon each other or do not share a common key.
Hybrid Cryptographic Systems
Public and secret key cryptography have relative advantages and disadvantages. Although public
key cryptography does not require users to share a common key, secret key cryptography is much
faster: equivalent implementations of secret key cryptography can run 1,000 to 10,000 times faster
than public key cryptography.
To maximize the advantages and minimize the disadvantages of both secret and public key
cryptography, a computer system can use both types in a complementary manner, with each
performing different functions. Typically, the speed advantage of secret key cryptography means that
it is used for encrypting data. Public key cryptography is used for applications that are less
demanding to a computer system's resources, such as encrypting the keys used by secret key
cryptography (for distribution) or to sign messages.
Key Escrow
Because cryptography can provide extremely strong encryption, it can thwart the government's
efforts to lawfully perform electronic surveillance. For example, if strong cryptography is used to
encrypt a phone conversation, a court-authorized wiretap will not be effective. To meet the needs of
the government and to provide privacy, the federal government has adopted voluntary key escrow
cryptography. This technology allows the use of strong encryption, but also allows the government
when legally authorized to obtain decryption keys held by escrow agents.
Uses of Cryptography
Cryptography is used to protect data both inside and outside the boundaries of a computer system.
Outside the computer system, cryptography is sometimes the only way to protect data. While in a
computer system, data is normally protected with logical and physical access controls (perhaps
supplemented by cryptography). However, when in transit across communications lines or resident on
someone else's computer, data cannot be protected by the originator's logical or physical access
controls. Cryptography provides a solution by protecting data even when the data is no longer in the
control of the originator.
Data Encryption
One of the best ways to obtain cost-effective data confidentiality is through the use of encryption.
Encryption transforms intelligible data, called plaintext, into a unintelligible form, called cipher text.
This process is reversed through the process of decryption. Once data is encrypted, the cipher text
does not have to be protected against disclosure. However, if cipher text is modified, it will not
decrypt correctly.
Both secret key and public key cryptography can be used for data encryption although not all public
key algorithms provide for data encryption.
To use a secret key algorithm, data is encrypted using a key. The same key must be used to decrypt
the data. When public key cryptography is used for encryption, any party may use any other party's
public key to encrypt a message; however, only the party with the corresponding private key can
decrypt, and thus read, the message.
Since secret key encryption is typically much faster, it is normally used for encrypting larger amounts
of data.
Integrity
In computer systems, it is not always possible for humans to scan information to determine if data
has been erased, added, or modified. Even if scanning were possible, the individual may have no
way of knowing what the correct data should be. For example, "do" may be changed to "do not," or

© Copyright IBM Corp. 2016 1-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
$1,000 may be changed to $10,000. It is therefore desirable to have an automated means of
detecting both intentional and unintentional modifications of data.
While error detecting codes have long been used in communications protocols (e.g., parity bits),
these are more effective in detecting (and correcting) unintentional modifications. They can be
defeated by adversaries. Cryptography can effectively detect both intentional and unintentional
modification; however, cryptography does not protect files from being modified. Both secret key and
public key cryptography can be used to ensure integrity. Although newer public key methods may
offer more flexibility than the older secret key method, secret key integrity verification systems have
been successfully integrated into many applications.
When secret key cryptography is used, a message authentication code (MAC) is calculated from and
appended to the data. To verify that the data has not been modified at a later time, any party with
access to the correct secret key can recalculate the MAC. The new MAC is compared with the
original MAC, and if they are identical, the verifier has confidence that the data has not been modified
by an unauthorized party.
Public key cryptography verifies integrity by using of public key signatures and secure hashes. A
secure hash algorithm is used to create a message digest. The message digest, called a hash, is a
short form of the message that changes if the message is modified. The hash is then signed with a
private key. Anyone can recalculate the hash and use the corresponding public key to verify the
integrity of the message.
Electronic Signatures
An electronic signature is a cryptographic mechanism that performs a similar function to a written
signature. It is used to verify the origin and contents of a message. For example, a recipient of data
(e.g., an e-mail message) can verify who signed the data and that the data was not modified after
being signed. This also means that the originator (e.g., sender of an e-mail message) cannot falsely
deny having signed the data.
Today's computer systems store and process increasing numbers of paper-based documents in
electronic form. Having documents in electronic form permits rapid processing and transmission and
improves overall efficiency. However, approval of a paper document has traditionally been indicated
by a written signature. What is needed, therefore, is the electronic equivalent of a written signature
that can be recognized as having the same legal status as a written signature. In addition to the
integrity protections, discussed above, cryptography can provide a means of linking a document with
a particular person, as is done with a written signature. Electronic signatures can use either secret
key or public key cryptography; however, public key methods are generally easier to use.
Cryptographic signatures provide extremely strong proof that a message has not been altered and
was signed by a specific key. However, there are other mechanisms besides cryptographic based
electronic signatures that perform a similar function. These mechanisms provide some assurance of
the origin of a message, some verification of the message's integrity, or both.
- Examination of the transmission path of a message: When messages are sent across a
network, such as the Internet, the message source and the physical path of the message are
recorded as a part of the message. These can be examined electronically or manually to help
ascertain the origin of a message.
- Use of a value-added network provider: If two or more parties are communicating via a third
party network, the network provider may be able to provide assurance that messages originate
from a given source and have not been modified.
- Acknowledgment statements: The recipient of an electronic message may confirm the
message's origin and contents by sending back an acknowledgement statement.
- Use of audit trails: Audit trails can track the sending of messages and their contents for later
reference.
Simply taking a digital picture of a written signature does not provide adequate security. Such a
digitized written signature could easily be copied from one electronic document to another with no

© Copyright IBM Corp. 2016 1-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
way to determine whether it is legitimate. Electronic signatures, on the other hand, are unique to the
message being signed and will not verify if they are copied to another document.
Secret Key Electronic Signatures
An electronic signature can be implemented using secret key message authentication codes
(MACs). For example, if two parties share a secret key, and one party receives data with a MAC
that is correctly verified using the shared key, that party may assume that the other party signed
the data. This assumes, however, that the two parties trust each other. Thus, through the use of
a MAC, in addition to data integrity, a form of electronic signature is obtained. Using additional
controls, such as key notarization and key attributes, it is possible to provide an electronic
signature even if the two parties do not trust each other.
Public Key Electronic Signatures
Another type of electronic signature called a digital signature is implemented using public key
cryptography. Data is electronically signed by applying the originator's private key to the data.
(The exact mathematical process for doing this is not important for this discussion.) To increase
the speed of the process, the private key is applied to a shorter form of the data, called a "hash"
or "message digest," rather than to the entire set of data. The resulting digital signature can be
stored or transmitted along with the data. The signature can be verified by any party using the
public key of the signer. This feature is very useful, for example, when distributing signed copies
of virus-free software. Any recipient can verify that the program remains virus-free. If the
signature verifies properly, then the verifier has confidence that the data was not modified after
being signed and that the owner of the public key was the signer.
User Authentication
Cryptography can increase security in user authentication techniques. Instead of communicating
passwords over an open network, authentication can be performed by demonstrating knowledge of a
cryptographic key. Using these methods, a one-time password, which is not susceptible to
eavesdropping, can be used. User authentication can use either secret or public key cryptography.

© Copyright IBM Corp. 2016 1-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

System security coverage IBM ICE (Innovation Centre for Education)

IBM Power Systems

© Copyright IBM Corporation 2016

Figure 1-9. System security coverage

Operating System Security

Operating system security (OS security) is the process of ensuring OS integrity, confidentiality and
availability. OS security refers to specified steps or measures used to protect the OS from threats, viruses,
worms, malware or remote hacker intrusions. OS security encompasses all preventive-control techniques,
which safeguard any computer assets capable of being stolen, edited or deleted if OS security is
compromised.
OS security encompasses many different techniques and methods which ensure safety from threats and
attacks. OS security allows different applications and programs to perform required tasks and stop
unauthorized interference.
OS security may be approached in many ways, including adherence to the following:
• Performing regular OS patch updates
• Installing updated antivirus engines and software
• Scrutinizing all incoming and outgoing network traffic through a firewall
• Creating secure accounts with required privileges only (i.e., user management)
Endpoint Security
Endpoint security is a client/server information security (IS) methodology for protecting a corporate network
through focusing on network devices (endpoints) by monitoring their status, activities, software, authorization
and authentication.

© Copyright IBM Corp. 2016 1-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Security software is installed on any endpoint device, as well as network servers. Such software may include
antivirus, antispyware, firewall and a host intrusion prevention system (HIPS).
For management and IT security personnel, endpoint security is an increasingly critical element for corporate
networks as more employees and authorized outsiders (like business partners, consultants, customers and
clients) are granted network access through the Internet and/or a variety of mobile devices
Endpoint security is evolving with technological advances. Security elements now include intrusion protection
and prevention, as well as behavior blocking software to monitor endpoint device activities for unsanctioned
applications or malicious intent.
Some complex endpoint security programs focus on user device authentication. As a user attempts to login,
credentials are validated, and the device is scanned for compliance with corporate policies, which may
include a scan for unauthorized software (such as games and peer-to-peer applications), updated virtual
private network (VPN), antivirus software, a firewall, mandatory corporate software and an approved
operating system (OS). Devices that don't meet such corporate policies may be granted limited access or
quarantined. This is known as network access control (NAC), which is used to unify many elements of
endpoint security technology. When access is provided, it is often according to the user’s profile. For
example, a human resources (HR) employee may be given only general access to a network and HR
department files.
Application Server Security
Many threats to an application server come from within an organization because application servers should
be isolated from Internet access. The main threats to an application server are:
• Network eavesdropping
• Unauthorized access
• Viruses, Trojan horses, and worms
Database Server Security
Database servers are a prime target for attackers. The database server must be secured against internal,
external, network level, and application level attacks. A secure database server includes a hardened SQL
Server 2000 installation on top of a hardened Windows 2000 / Windows Server 2003 installation, coupled
with secure network defenses provided by routers and firewalls.
There are many ways to attack a database. External attacks may exploit configuration weaknesses that
expose the database server. An insecure Web application may also be used to exploit the database. For
example, an application that is granted too much privilege in the database or one that does not validate its
input can put your database at risk.
An attacker can target and compromise a database server in a number of ways by exploiting a variety of
configuration and application level vulnerabilities. The main threats to a database server are:
• SQL injection
• Network eavesdropping
• Unauthorized server access
• Password cracking

© Copyright IBM Corp. 2016 1-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

System security risk management (1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• The process of risk assessment involves following activities:

– determining the assessment's scope and methodology
– collecting and analyzing data
– interpreting the risk analysis results

The interrelationship of vulnerabilities, threats, and assets

© Copyright IBM Corporation 2016

Figure 1-10. System security risk management (1 of 2)

Risk is the possibility of something adverse happening. Risk management is the process of assessing risk,
taking steps to reduce risk to an acceptable level and maintaining that level of risk. Though perhaps not
always aware of it, individuals manage risks every day. Actions as routine as buckling a car safety belt,
carrying an umbrella when rain is forecast, or writing down a list of things to do rather than trusting to memory
fall into the purview of risk management. People recognize various threats to their best interests and take
precautions to guard against them or to minimize their effects.
Both government and industry routinely manage a myriad of risks. For example, to maximize the return on
their investments, businesses must often decide between aggressive (but high-risk) and slow-growth (but
more secure) investment plans. These decisions require analysis of risk, relative to potential benefits,
consideration of alternatives, and, finally, implementation of what management determines to be the best
course of action.
While there are many models and methods for risk management, there are several basic activities and
processes that should be performed. In discussing risk management, it is important to recognize its basic,
most fundamental assumption: computers cannot ever be fully secured. There is always risk, whether it is
from a trusted employee who defrauds the system or a fire that destroys critical resources. Risk
management is made up of two primary and one underlying activities; risk assessment and risk mitigation are
the primary activities and uncertainty analysis is the underlying one.
Risk assessment, the process of analyzing and interpreting risk, is comprised of three basic activities:
1. determining the assessment's scope and methodology
2. collecting and analyzing data

© Copyright IBM Corp. 2016 1-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
3. interpreting the risk analysis results
Determining the Assessment's Scope and Methodology
The first step in assessing risk is to identify the system under consideration, the part of the system that
will be analyzed, and the analytical method including its level of detail and formality.
The assessment may be focused on certain areas where either the degree of risk is unknown or is known
to be high. Different parts of a system may be analyzed in greater or lesser detail. Defining the scope
and boundary can help ensure a cost-effective assessment. Factors that influence scope include what
phase of the life cycle a system is in: more detail might be appropriate for a new system being developed
than for an existing system undergoing an upgrade. Another factor is the relative importance of the
system under examination: the more essential the system, the more thorough the risk analysis should be.
A third factor may be the magnitude and types of changes the system has undergone since the last risk
analysis. The addition of new interfaces would warrant a different scope than would installing a new
operating system.
Methodologies can be formal or informal, detailed or simplified, high or low level, quantitative
(computationally based) or qualitative (based on descriptions or rankings), or a combination of these. No
single method is best for all users and all environments.
How the boundary, scope, and methodology are defined will have major consequences in terms of
a. the total amount of effort spent on risk management
b. the type and usefulness of the assessment's results
The boundary and scope should be selected in a way that will produce an outcome that is clear, specific,
and useful to the system and environment under scrutiny.
Collecting and Analyzing Data
Risk has many different components: assets, threats, vulnerabilities, safeguards, consequences, and
likelihood. This examination normally includes gathering data about the threatened area and
synthesizing and analyzing the information to make it useful.
Because it is possible to collect much more information than can be analyzed, steps need to be taken to
limit information gathering and analysis. This process is called screening. A risk management effort
should focus on those areas that result in the greatest consequence to the organization (i.e., can cause
the most harm). This can be done by ranking threats and assets.
A risk management methodology does not necessarily need to analyze each of the components of risk
separately. For example, assets/consequences or threats/likelihoods may be analyzed together.
Asset Valuation: These include the information, software, personnel, hardware, and physical assets
(such as the computer facility). The value of an asset consists of its intrinsic value and the near-term
impacts and long-term consequences of its compromise.
Consequence Assessment: The consequence assessment estimates the degree of harm or loss that
could occur. Consequences refers to the overall, aggregate harm that occurs, not just to the near term or
immediate impacts. While such impacts often result in disclosure, modification, destruction, or denial of
service, consequences are the more significant long-term effects, such as lost business, failure to
perform the system's mission, loss of reputation, violation of privacy, injury, or loss of life. The more
severe the consequences of a threat, the greater the risk to the system (and, therefore, the organization).
Threat Identification: A threat is an entity or event with the potential to harm the system. Typical threats
are errors, fraud, disgruntled employees, fires, water damage, hackers, and viruses. Threats should be
identified and analyzed to determine the likelihood of their occurrence and their potential to harm assets.
In addition to looking at "big-ticket" threats, the risk analysis should investigate areas that are poorly
understood, new, or undocumented. If a facility has a well-tested physical access control system, less
effort to identify threats may be warranted for it than for unclear, untested software backup procedures.
The risk analysis should concentrate on those threats most likely to occur and affect important assets. In
some cases, determining which threats are realistic is not possible until after the threat analysis is begun.

© Copyright IBM Corp. 2016 1-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Safeguard Analysis: A safeguard is any action, device, procedure, technique, or other measure that
reduces a system's vulnerability to a threat. Safeguard analysis should include an examination of the
effectiveness of the existing security measures. It can also identify new safeguards that could be
implemented in the system; however, this is normally performed later in the risk management process.
Vulnerability Analysis: A vulnerability is a condition or weakness in (or absence of) security
procedures, technical controls, physical controls, or other controls that could be exploited by a threat.
Vulnerabilities are often analyzed in terms of missing safeguards. Vulnerabilities contribute to risk
because they may "allow" a threat to harm the system.
Likelihood Assessment: Likelihood is an estimation of the frequency or chance of a threat happening.
A likelihood assessment considers the presence, tenacity, and strengths of threats as well as the
effectiveness of safeguards (or presence of vulnerabilities). In general, historical information about many
threats is weak, particularly with regard to human threats; thus, experience in this area is important.
Some threat data -- especially on physical threats such as fires or floods -- is stronger. Care needs to be
taken in using any statistical threat data; the source of the data or the analysis may be inaccurate or
incomplete. In general, the greater the likelihood of a threat occurring, the greater the risk.
Interpreting Risk Analysis Results
The risk assessment is used to support two related functions: the acceptance of risk and the selection of
cost-effective controls. To accomplish these functions, the risk assessment must produce a meaningful
output that reflects what is truly important to the organization. Limiting the risk interpretation activity to
the most significant risks is another way that the risk management process can be focused to reduce the
overall effort while still yielding useful results. If risks are interpreted consistently across an organization,
the results can be used to prioritize systems to be secured.

© Copyright IBM Corp. 2016 1-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

System security risk management (2 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Risk mitigation: Selection and implementation of security controls

– Selecting safeguards
– Accept residual risk
– Implementing controls and monitoring effectiveness
– interpreting the risk analysis results

© Copyright IBM Corporation 2016

Figure 1-11. System security risk management (2 of 2)

Risk mitigation involves the selection and implementation of security controls to reduce risk to a level
acceptable to management, within applicable constraints. Although there is flexibility in how risk assessment
is conducted, the sequence of identifying boundaries, analyzing input, and producing an output is quite
natural. The process of risk mitigation has greater flexibility, and the sequence will differ more, depending on
organizational culture and the purpose of the risk management activity.
Selecting Safeguards
A primary function of computer security risk management is the identification of appropriate controls. In
designing (or reviewing) the security of a system, it may be obvious that some controls should be added
(e.g., because they are required by law or because they are clearly cost-effective). It may also be just as
obvious that other controls may be too expensive (considering both monetary and nonmonetary factors).
For example, it may be immediately apparent to a manager that closing and locking the door to a
particular room that contains local area network equipment is a needed control, while posting a guard at
the door would be too expensive and not user-friendly.
In every assessment of risk, there will be many areas for which it will not be obvious what kind of controls
are appropriate. Even considering only monetary issues, such as whether a control would cost more
than the loss it is supposed to prevent, the selection of controls is not simple. However, in selecting
appropriate controls, managers need to consider many factors, including:
▪ organizational policy, legislation, and regulation
▪ safety, reliability, and quality requirements
▪ system performance requirements

© Copyright IBM Corp. 2016 1-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
▪ timeliness, accuracy, and completeness requirements
▪ the life cycle costs of security measures
▪ technical requirements
▪ cultural constraints
One method of selecting safeguards uses a "what if" analysis. With this method, the effect of adding
various safeguards (and, therefore, reducing vulnerabilities) is tested to see what difference each makes
with regard to cost, effectiveness, and other relevant factors, such as those listed above. Trade-offs
among the factors can be seen. The analysis of trade-offs also supports the acceptance of residual risk.
This method typically involves multiple iterations of the risk analysis to see how the proposed changes
affect the risk analysis result.
Another method is to categorize types of safeguards and recommend implementing them for various
levels of risk. For example, stronger controls would be implemented on high-risk systems than on
low-risk systems. This method normally does not require multiple iterations of the risk analysis.
As with other aspects of risk management, screening can be used to concentrate on the highest risk
areas. For example, once could focus on risks with very severe consequences, such as a very high
dollar loss or loss of life or on the threats that are most likely to occur.
Accept Residual Risk
At some point, management needs to decide if the operation of the computer system is acceptable, given
the kind and severity of remaining risks. Many managers do not fully understand computer based risk for
several reasons:
a. the type of risk may be different from risks previously associated with the organization or
function
b. the risk may be technical and difficult for a lay person to understand
c. the proliferation and decentralization of computing power can make it difficult to identify key
assets that may be at risk
Risk acceptance, like the selection of safeguards, should take into account various factors besides those
addressed in the risk assessment. In addition, risk acceptance should take into account the limitations of
the risk assessment. Risk acceptance is linked to the selection of safeguards since, in some cases, risk
may have to be accepted because safeguards are too expensive (in either monetary or nonmonetary
factors).
Implementing Controls and Monitoring Effectiveness
Merely selecting appropriate safeguards does not reduce risk; those safeguards need to be effectively
implemented. Moreover, to continue to be effective, risk management needs to be an ongoing process.
This requires a periodic assessment and improvement of safeguards and re-analysis of risks. The risk
management process normally produces security requirements that are used to design, purchase, build,
or otherwise obtain safeguards or implement system changes.
Uncertainty Analysis
Risk management often must rely on speculation, best guesses, incomplete data, and many unproven
assumptions. The uncertainty analysis attempts to document this so that the risk management results can be
used knowledgeably. There are two primary sources of uncertainty in the risk management process
• a lack of confidence or precision in the risk management model or methodology
• a lack of sufficient information to determine the exact value of the elements of the risk model, such as
threat frequency, safeguard effectiveness, or consequences
The risk management framework presented here is a generic description of risk management elements and
their basic relationships. For a methodology to be useful, it should further refine the relationships and offer
some means of screening information. In this process, assumptions may be made that do not accurately

© Copyright IBM Corp. 2016 1-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
reflect the user's environment. This is especially evident in the case of safeguard selection, where the
number of relationships among assets, threats, and vulnerabilities can become unwieldy.
The data are another source of uncertainty. Data for the risk analysis normally come from two sources:
statistical data and expert analysis. Statistics and expert analysis can sound more authoritative than they
really are. There are many potential problems with statistics. For example, the sample may be too small,
other parameters affecting the data may not be properly accounted for, or the results may be stated in a
misleading manner. In many cases, there may be insufficient data. When expert analysis is used to make
projections about future events, it should be recognized that the projection is subjective and is based on
assumptions made (but not always explicitly articulated) by the expert.

© Copyright IBM Corp. 2016 1-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Case study: Context setting IBM ICE (Innovation Centre for Education)
IBM Power Systems

• A hypothetical IT Department in the Ministry of Electronics and Information Technology and

how it is dealing with IT security issues in its operating environment.
• Identification of assets
– System components owned and operated by IT Department
– Contracting and procurement documents
– Internal correspondence
– Draft resolutions
– Other day-to-day business documents, memos, and reports

© Copyright IBM Corporation 2016

Figure 1-12. Case study: Context setting

Introduction
Let us take an example of a hypothetical IT Department in the Ministry of Electronics and Information
Technology and how it is dealing with IT security issues in its operating environment. It will follow the
evolution of IT Department's initiation of an assessment of the threats to its security system all the way
through to IT Department's recommendations for mitigating those risks. Considering the real world scenario,
there are numerous system security solutions. However, there is no single solution that can solve security
problems in different environments. And the solution presented in this case study does not apply to all
environments as well.
Situational Context
There is information with IT Department that comprise different kinds of assets deemed valuable enough and
worth protecting. IT Department's systems play a key role in transferring Government funds to individuals in
the form of paychecks; hence, financial resources are among the assets associated with IT Department's
systems. The assets are identified as
• System components owned and operated by IT Department
• Contracting and procurement documents
• Internal correspondence
• Draft resolutions
• Other day-to-day business documents, memos, and reports

© Copyright IBM Corp. 2016 1-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Apart from the aforementioned tangible assets, there are intangible items such as reputation of the
organization and the faith of its employees that personal information will be handled with care and proper
remuneration will be provided.
There is a new management team brought in owing to a recent change in the directorship of IT Department.
A new Chief Information Officer was appointed who in turn appointed a Computer Security Program
Manager. The Computer Security Program Manager started conducting a comprehensive risk analysis to
assess the security program of IT Department from an effectiveness and compliance point of view. Risk
assessments done before, applicable internal control reports and threat studies were drawn forth by this
analysis. There was a timetable for periodic reassessments established by Computer Security Program
Manager.
The wide-area network and mainframe were not treated as assets in the risk assessments as they are owned
and operated by external organizations. IT Department’s personnel, buildings, and facilities were also
excluded from the scope of risk analysis. After carrying out risk analysis, there were specific threats identified
to IT Department’s assets. The risk assessment team reviewed IT Department’s safeguards against those
threats, vulnerabilities against policies and actions recommended for the mitigation of risks.

© Copyright IBM Corp. 2016 1-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Case Study: Analysis of IT Department’s System IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Analysis of IT Department’s System

– System Architecture
– System Operational Authority/Ownership
– System Applications

System Architecture
© Copyright IBM Corporation 2016

Figure 1-13. Case Study: Analysis of IT Department’s System

Analysis of IT Department’s Systems

The distributed systems and networks at IT Department consist of components (including those operated by
other organizations).
System Architecture
There are personal computers (PC’s) provided to IT Department’s staff (clerical, technical and
managerial). Each PC is provided with hard-disk and floppy drives.
All systems are connected to a Local Area Network (LAN) that allows user to share and exchange
information. LAN server, a more powerful system, is the central component of LAN. This LAN server acts
as intermediary between PCs on the network. It also provides a large volume of disk storage to enable
information sharing. There are various shared application programs included in the disk space.
In order to secure information on the network, the user access is limited to various files and programs on
the server. Logical access controls are provided by the LAN server via elementary access control lists.
These controls are applied on potentially sharable information.
System users are supposed to log into the server and provide authentication details in order to
successfully login and execute program on the server or initiate a session. One of the applications
supported by the server is electronic mail (e-mail), which can be used by all PC users. Other programs
that run on the server can only be executed by a limited set of PC users.
Several printers, distributed throughout IT Department's building complex, are connected to the LAN.
Users at PCs may direct printouts to whichever printer is most convenient for their use.

© Copyright IBM Corp. 2016 1-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Since IT Department must frequently communicate with industry, there is an Internet connection provided
via a router by LAN. The router is a network interface device that translates between the protocols and
addresses associated with the LAN and the Internet. The router also performs network packet filtering, a
form of network access control, and has recently been configured to disallow non - e-mail (e.g., file
transfer, remote log-in) between LAN and Internet computers.
The LAN server also has connections to several other devices.
▪ A modem pool is provided so that IT Department's employees on travel can "dial up" via the public
switched (telephone) network and read or send e-mail. To initiate a dial-up session, a user must
successfully log in. During dial-up sessions, the LAN server provides access only to e-mail facilities;
no other functions can be invoked.
▪ A special console is provided for the server administrators who configure the server, establish and
delete user accounts, and have other special privileges needed for administrative and maintenance
functions. These functions can only be invoked from the administrator console; that is, they cannot
be invoked from a PC on the network or from a dial-up session.
▪ A connection to a government agency X.25-based wide-area network (WAN) is provided so that
information can be transferred to or from other agency systems. One of the other hosts on the WAN
is a large multiagency mainframe system. This mainframe is used to collect and process information
from a large number of agencies while providing a range of access controls.
System Operational Authority/Ownership
Network Affairs, a unit within IT Department is responsible for the management and operation of system
components. This group includes the PCs, LAN, server, console, printers, modem pool, and router. The
WAN is owned and operated by a large commercial telecommunications company that provides WAN
services under a government contract. The mainframe is owned and operated by a federal agency that
acts as a service provider for IT Department and other agencies connected to the WAN.
System Applications
Systems on IT Department's LAN are used for data manipulation, word processing and applications like
spreadsheet and project management tools. There is a question to the confidentiality and integrity of data
(which is mostly sensitive with the mentioned tasks).
The mainframe also provides storage and retrieval services for other databases belonging to individual
agencies. For example, several agencies, including IT Department, store their personnel databases on
the mainframe; these databases contain dates of service, leave balances, salary and W-2 information,
and so forth.
In addition to their time and attendance application, IT Department's PCs and the LAN server are used to
manipulate other kinds of information that may be sensitive in terms of integrity or confidentiality,
including personnel-related correspondence and draft contracting documents.

© Copyright IBM Corp. 2016 1-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Case study: Threat analysis IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Threats posed to different assets of IT Department

– Payroll fraud
– Payroll errors
– Interruption of operations
– Disclosure or brokerage of information
– Network-related threats

Examples of Threats to IT Department Systems

Potential Threat Probability Impact
Accidental Loss/release/disclosure of sensitive information Medium Low/Medium
Accidental destruction of information High Medium
Loss of information due to virus contamination Medium Medium
Misuse of system resources Low Low
Theft High Medium
Unauthorized access to telecommunication resources Medium Medium
Natural disaster Low High

© Copyright IBM Corporation 2016

Figure 1-14. Case study: Threat analysis

Threats Analysis
Different kind of threats are posed to different assets of IT Department. These threats vary significantly in
terms of probability of occurrence and the potential impact they offer to produce. There is promising way to
predict the occurrence of a threat. Estimation have been made by IT Department and the risk assessment
authors to get a more accurate prediction. This estimation is based on the combined study of historical data
and new trends stimulated by emerging technologies (e.g., external networks).
Payroll Fraud
As for most large organizations that control financial assets, attempts at fraud and embezzlement are
likely to occur. Historically, attempts at payroll fraud have almost always come from within IT Department
or the other agencies that operate systems on which IT Department depends. Although IT Department
has thwarted many of these attempts, and some have involved relatively small sums of money, it
considers preventing financial fraud to be a critical computer security priority, particularly in light of the
potential financial losses and the risks of damage to its reputation with Congress, the public, and other
federal agencies.
Attempts to defraud IT Department have included the following:
▪ Submitting fraudulent time sheets for hours or days not worked, or for pay periods following
termination or transfer of employment. The former may take the form of over-reporting compensatory
or overtime hours worked, or underreporting vacation or sick leave taken. Alternatively, attempts
have been made to modify time sheet data after being entered and approved for submission to
payroll.

© Copyright IBM Corp. 2016 1-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
▪ Falsifying or modifying dates or data on which one's "years of service" computations are based,
thereby becoming eligible for retirement earlier than allowed, or increasing one's pension amount.
▪ Creating employee records and time sheets for fictitious personnel, and attempting to obtain their
paychecks, particularly after arranging for direct deposit.
Payroll Errors
Of greater likelihood, but of perhaps lesser potential impact on IT Department, are errors in the entry of
time and attendance data; failure to enter information describing new employees, terminations, and
transfers in a timely manner; accidental loss or corruption of time and attendance data; or errors in
interagency coordination and processing of personnel transfers.
Errors of these kinds can cause financial difficulties for employees and accounting problems for IT
Department. If an employee's vacation or sick leave balance became negative erroneously during the
last pay period of the year, the employee's last paycheck would be automatically reduced. An individual
who transfers between IT Department and another agency may risk receiving duplicate paychecks or no
paychecks for the pay periods immediately following the transfer. Errors of this sort that occur near the
end of the year can lead to errors in W-2 forms and subsequent difficulties with the tax collection
agencies.
Interruption of Operation
Interruptions to facilities; such as power, air conditioning, LAN or WAN connectivity; lasting upto a whole
working day, are frequent during the entire year. This is because the physical plant and the building
facilities are several years old and are in the process of repair or renovation. Operations are interrupted
by severed network or power cables, natural disasters (storms, fire, floods, etc.) and equipment
malfunctions. There is also likelihood of an outsider or a resentful employee with malicious intentions to
disrupt processes that are time-critical, such as payroll management. It can be made possible by deleting
system accounts, changing configurations of access controls, injecting malware in systems, or physically
damaging/sabotaging system equipment. These interruptions can hinder the time and attendance data to
be processed properly and forwarded to the mainframe.
Disclosure or Brokerage of Information
There could also be threats of disclosure of sensitive/valuable information and can have a low to high
potential impact depending upon the nature of information involved. The growing market for information
pertaining to employees of an organizations is what’s stimulating this threat. It is not necessary that the
information is accessed and disclosed using illegitimate means. There are employees who have
legitimate access to the information master employee database and they may attempt the sale of this
information to private investigators or other organizations.
Network-Related Threats
Systems inside IT Department are connected to three external networks.
a. Internet
b. The Interagency WAN
c. The public-switched (telephone) network
These networks pose as a source of security risks. However, they are necessary for the agency’s
operations. IT Department cannot terminate connectivity as it is essential to IT Department’s mission and
to the productivity of its employees.
Most of the threats, involving the “human-error” factor has its source as one of the insiders. However, IT
Department has also sought to protect its assets from outsiders. These attacks differ in terms of objectives
and propose a wide spectrum of risks that includes unauthorized use of services and assets, unauthorized
disclosure or modification of information, or unauthorized denial of services.
Now, the current situation is bleak. IT Department has detected that its systems were being tried upon to be
penetrated by outsiders. This happened every time before IT Department was establishing its current set of
network safeguards in each of the past few years. Not all of these attacks came from the Internet. But those
which succeeded did not actually hack into the systems. But penetrated by learning or guessing user account

© Copyright IBM Corp. 2016 1-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
passwords. While in some cases, significant amounts of data were either deleted or corrupted by the
attacker, mostly, that was not the case. So, it was concluded that since data wasn’t manipulated in any way,
the attacker just browsed through the database. The absence of sufficient logging auditing capabilities made
it impossible to track attacker activities. This would make it hard to accurately measure the extent of
penetration.

© Copyright IBM Corp. 2016 1-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Case study: Security measures in place IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Security measures in place at the IT Department

– Protection against payroll fraud and errors: time and attendance application
– Protection against unauthorized execution
– Protection against payroll errors
– Protection against accidental corruption or loss of payroll data
– Protection against interruption of operations
• Network affairs contingency planning
• Division contingency planning
– Protection against disclosure or brokerage of information
– Protection against network-related threats
– Protection against risks from non–it department systems

© Copyright IBM Corporation 2016

Figure 1-15. Case study: Security measures in place

Security Measures in Place

The system resources owned and operated by IT Department are maintained, administered and controlled by
Network Affairs. The login IDs and passwords on multiuser IT Department systems, like the LAN server, can
be established only by System Administrator. A written authorization is required from the department
supervisor for IT Department’s employees and contract personnel to access the multiuser system.
All relevant security policies and procedures are communicated, by Network Affairs, with new users. The new
users are required to complete following tasks before their system account is activated:
1. Attend a security training and awareness course
2. Sign an acknowledgement form to indicate that they have a non-ambiguous understanding of
their security responsibilities
IT Department expects the authorized users to comply with password selection and security procedures (e.g.,
periodically changing passwords) and not share the secret login ID and password assigned to them. The
automated access control mechanisms on IT Department’s systems are to be used effectively by users
creating sensitive data, in order to reduce the risk of exposure to unauthorized individuals.
Protection Against Payroll Fraud and Errors: Time and Attendance Application
The time and attendance application plays a major role in protection of systems against risks related to
payroll fraud and errors. Since the time and attendance application is a component of a larger automated
payroll process, many of its functional and security requirements have been derived from both
government-wide and IT Department-specific policies related to payroll and leave. For example, IT

© Copyright IBM Corp. 2016 1-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Department must protect personal information in accordance with the Privacy Act. Depending on the
specific type of information, it should normally be viewable only by the individual concerned, the
individual's supervisors, and personnel and payroll department employees. Such information should also
be timely and accurate.
Each week, employees must sign and submit a time sheet that identifies the number of hours they have
worked and the amount of leave they have taken. The Time and Attendance Clerk enters the data for a
given group of employees and runs an application on the LAN server to verify the data's validity and to
ensure that only authorized users with access to the Time and Attendance Clerk's functions can enter
time and attendance data. The application performs these security checks by using the LAN server's
access control and identification and authentication (Identification and Authentication) mechanisms. The
application compares the data with a limited database of employee information to detect incorrect
employee identifiers, implausible numbers of hours worked, and so forth. After correcting any detected
errors, the clerk runs another application that formats the time and attendance data into a report, flagging
exception/out-of-bound conditions (e.g., negative leave balances).
Department supervisors are responsible for reviewing the correctness of the time sheets of the
employees under their supervision and indicating their approval by initialling the time sheets. If they
detect significant irregularities and indications of fraud in such data, they must report their findings to the
Payroll Office before submitting the time sheets for processing. In keeping with the principle of
separation of duty, all data on time sheets and corrections on the sheets that may affect pay, leave,
retirement, or other benefits of an individual must be reviewed for validity by at least two authorized
individuals (other than the affected individual).
Protection Against Unauthorized Execution
Only users with access to Time and Attendance Supervisor functions may approve and submit time and
attendance data - or subsequent corrections thereof - to the mainframe. Supervisors may not approve
their own time and attendance data.
Only the System Administrator has been granted access to assign a special access control privilege to
server programs. As a result, the server's operating system is designed to prevent a bogus time and
attendance application created by any other user from communicating with the WAN and, hence, with the
mainframe.
The time and attendance application is supposed to be configured so that the clerk and supervisor
functions can only be carried out from specific PCs attached to the LAN and only during normal working
hours. Administrators are not authorized to exercise functions of the time and attendance application
apart from those concerned with configuring the accounts, passwords, and access permissions for clerks
and supervisors. Administrators are expressly prohibited by policy from entering, modifying, or
submitting time and attendance data via the time and attendance application or other mechanisms.
Protection against unauthorized execution of the time and attendance application depends on
Identification and Authentication and access controls. While the time and attendance application is
accessible from any PC, unlike most programs run by PC users, it does not execute directly on the PC's
processor. Instead, it executes on the server, while the PC behaves as a terminal, relaying the user's
keystrokes to the server and displaying text and graphics sent from the server. The reason for this
approach is that common PC systems do not provide Identification and Authentication and access
controls and, therefore, cannot protect against unauthorized time and attendance program execution.
Any individual who has access to the PC could run any program stored there.

Another possible approach is for the time and attendance program to perform Identification and
Authentication and access control on its own by requesting and validating a password before beginning
each time and attendance session. This approach, however, can be defeated easily by a moderately
skilled programming attack, and was judged inadequate by IT Department during the application's early
design phase.
Recall that the server is a more powerful computer equipped with a multiuser operating system that
includes password-based Identification and Authentication and access controls. Designing the time and
attendance application program so that it executes on the server under the control of the server's

© Copyright IBM Corp. 2016 1-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
operating system provides a more effective safeguard against unauthorized execution than executing it
on the user's PC.
Protection Against Payroll Errors
The frequency of data entry errors is reduced by having Time and Attendance clerks enter each time
sheet into the time and attendance application twice. If the two copies are identical, both are considered
error free, and the record is accepted for subsequent review and approval by a supervisor. If the copies
are not identical, the discrepancies are displayed, and for each discrepancy, the clerk determines which
copy is correct. The clerk then incorporates the corrections into one of the copies, which is then
accepted for further processing. If the clerk makes the same data-entry error twice, then the two copies
will match, and one will be accepted as correct, even though it is erroneous. To reduce this risk, the time
and attendance application could be configured to require that the two copies be entered by different
clerks.
In addition, each department has one or more Time and Attendance Supervisors who are authorized to
review these reports for accuracy and to approve them by running another server program that is part of
the time and attendance application. The data are then subjected to a collection of "sanity checks" to
detect entries whose values are outside expected ranges. Potential anomalies are displayed to the
supervisor prior to allowing approval; if errors are identified, the data are returned to a clerk for additional
examination and corrections.
When a supervisor approves the time and attendance data, this application logs into the interagency
mainframe via the WAN and transfers the data to a payroll database on the mainframe. The mainframe
later prints paychecks or, using a pool of modems that can send data over phone lines, it may transfer the
funds electronically into employee-designated bank accounts. Withheld taxes and contributions are also
transferred electronically in this manner.
The Director of Personnel is responsible for ensuring that forms describing significant payroll-related
personnel actions are provided to the Payroll Office at least one week before the payroll processing date
for the first affected pay period. These actions include hiring, terminations, transfers, leaves of absences
and returns from such, and pay raises.
The Manager of the Payroll Office is responsible for establishing and maintaining controls adequate to
ensure that the amounts of pay, leave, and other benefits reported on pay stubs and recorded in
permanent records and those distributed electronically are accurate and consistent with time and
attendance data and with other information provided by the Personnel Department. In particular,
paychecks must never be provided to anyone who is not a bona fide, active-status employee of IT
Department. Moreover, the pay of any employee who terminates employment, who transfers, or who
goes on leave without pay must be suspended as of the effective date of such action; that is, extra
paychecks or excess pay must not be issued.
Protection Against Accidental Corruption or Loss of Payroll Data
The same mechanisms used to protect against fraudulent modification are used to protect against
accidental corruption of time and attendance data - namely, the access-control features of the server and
mainframe operating systems.
Network Affairs's nightly backups of the server's disks protect against loss of time and attendance data.
To a limited extent, IT Department also relies on mainframe administrative personnel to back up time and
attendance data stored on the mainframe, even though IT Department has no direct control over these
individuals. As additional protection against loss of data at the mainframe, IT Department retains copies
of all time and attendance data on line on the server for at least one year, at which time the data are
archived and kept for three years. The server's access controls for the on-line files are automatically set
to read-only access by the time and attendance application at the time of submission to the mainframe.
The integrity of time and attendance data will be protected by digital signatures as they are implemented.
The WAN's communications protocols also protect against loss of data during transmission from the
server to the mainframe (e.g., error checking). In addition, the mainframe payroll application includes a
program that is automatically run 24 hours before paychecks and pay stubs are printed. This program
produces a report identifying agencies from whom time and attendance data for the current pay period
were expected but not received. Payroll department staff are responsible for reviewing the reports and

© Copyright IBM Corp. 2016 1-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
immediately notifying agencies that need to submit or resubmit time and attendance data. If time and
attendance input or other related information is not available on a timely basis, pay, leave, and other
benefits are temporarily calculated based on information estimated from prior pay periods.
Protection Against Interruption of Operations
Network Affairs Contingency Planning
There is a need to develop a contingency plan that contains all the procedures and facilities to be
turned upon in case of disruption of normal use of IT Department’s PCs, LAN, server, printers, router
and other system equipment, due to natural disasters, physical plant failures, or equipment
malfunctions. This plan is developed and maintained by Network Affairs.
The reliability of applications on the aforementioned resources is used to settle priority levels in the
contingency plan. If the automated functions are found to be temporarily degraded, these
applications are automatically suspended. Network Affairs personnel have identified system software
and hardware components that are compatible with those used by two nearby agencies. IT
Department has signed an agreement with those agencies, whereby they have committed to
reserving spare computational and storage capacities sufficient to support IT Department's
system-based operations during an emergency for a few days.
A written approval from Network Affairs Manager is required for any communication devices or
network interfaced to be connected to IT Department’s systems. The Network Affairs staff is
responsible for installing all known security-related software patches in a timely manner and for
maintaining spare or redundant PCs, servers, storage devices, and LAN interfaces to ensure that at
least 100 people can simultaneously perform word processing tasks at all times.
In order to protect data against accidental loss or corruption, LAN server disks are backed up after
end of the day every day. The backup is taken on magnetic tapes and the tapes are transferred to
another agency every week for storage. PC users are expected to adhere to IT Department’s policies
and backup any significant data in their storage on a weekly basis. Network Affairs also strongly
encourages them to store significant data on the LAN server instead of on their PC's hard disk so that
such data will be backed up automatically during Network Affairs's LAN server backups.
Network Affairs maintains an inventory of approximately ten fully equipped spare PC's, a spare LAN
server, and several spare disk drives for the server, to prevent more limited computer equipment
malfunctions from interrupting routine business operations,. Network Affairs also keeps thousands of
feet of LAN cable on hand. If a segment of the LAN cable that runs through the ceilings and walls of
IT Department's buildings fails or is accidentally severed, Network Affairs technicians will run
temporary LAN cabling along the floors of hallways and offices, typically restoring service within a
few hours for as long as needed until the cable failure is located and repaired.
To protect against PC virus contamination, IT Department authorizes only System Administrators
approved by the Network Affairs Manager to install licensed, copyrighted PC software packages that
appear on the Network Affairs-approved list. PC software applications are generally installed only on
the server. (These stipulations are part of an IT Department assurance strategy that relies on the
quality of the engineering practices of vendors to provide software that is adequately robust and
trustworthy.) Only the Network Affairs Manager is authorized to add packages to the approved list.
Network Affairs procedures also stipulate that every month System Administrators should run
virus-detection and other security-configuration validation utilities on the server and, on a spot-check
basis, on a number of PCs. If they find a virus, they must immediately notify the agency team that
handles computer security incidents.
The audit logs generated by the server are reviewed by Network Affairs. Network Affairs also
identifies audit records that are an indicative security violations and reports them to the Incident
Handling team. These duties are assigned by the Network Affairs Manager to requisite members of
the staff and it is ensured that that these duties are implemented effectively.
Network Affairs Manager assessed adverse circumstances and the IT Department’s Director
receives recommendation from Network Affairs Manager based on the assessment. This plays as a
major factor for the Director in judging the gravity of circumstances and what set of procedures in the
contingency plan are to be called upon.

© Copyright IBM Corp. 2016 1-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Division Contingency Planning
The contingency plans are developed and maintained by IT Department’s divisions individually.
These plans identify critical business operations, system resources and their dependency on
applications, and the tolerance of these functions in terms of maximum acceptable periods of
interruption. Division head ensures that the contingency plan is adequate and all the associated
support activities are ample.
An application owner is designated for each major application used by multiple divisions. This
application owner is generally a chief of a single division, who then also becomes responsible for
addressing that particular application in the contingency plan. The designated official also
coordinates with other divisions using that application.
The contingency plan of Network Affairs plan needs not to be duplicated if a division relies solely on
the resources maintained by Network Affairs. The division instead reviews the adequacy of Network
Affairs’s contingency plan. In case there is a discrepancy in matching the adequacy with the needs of
the division, the division can reach out to the Network Affairs Director. If there are resources or
services with the division’s dependency on them that do not fall under Network Affairs’s resources,
the division is responsible for developing its own contingency plan. It has to also ensure that
adequate protection is provided against service disruptions by the contingency plans of other
organizations.
Protection Against Disclosure or Brokerage of Information
IT Department's protection against information disclosure is based on a need-to-know policy and on
personnel hiring and screening practices. The need-to-know policy states that time and attendance
information should be made accessible only to IT Department employees and contractors whose
assigned professional responsibilities require it. Such information must be protected against access from
all other individuals, including other IT Department employees. Appropriate hiring and screening
practices can lessen the risk that an untrustworthy individual will be assigned such responsibilities.
The need-to-know policy is supported by a collection of physical, procedural, and automated safeguards,
including the following:
▪ Time and attendance paper documents are must be stored securely when not in use, particularly
during evenings and on weekends. Approved storage containers include locked file cabinets and
desk drawers - to which only the owner has the keys. While storage in a container is preferable, it is
also permissible to leave time and attendance documents on top of a desk or other exposed surface
in a locked office (with the realization that the guard force has keys to the office). (This is a judgment
left to local discretion.) Similar rules apply to disclosure-sensitive information stored on floppy disks
and another removable magnetic media.
▪ Every IT Department PC is equipped with a key lock that, when locked, disables the PC.
▪ When information is stored on a PC's local hard disk, the user to whom that PC was assigned is
expected to
- lock the PC at the conclusion of each work day and
- lock the office in which the PC is located.
▪ Extensive features, for controlling access to files, are provided by the access controls of LAN server
operating system. There are group-oriented controls and with their aid, System Administrator assign
teams of users to specific named groups. This allows the group members to access sensitive files
that cannot be accessed by non-members. As per their requirement of access to files, users can be
assigned to different groups.
▪ There is security awareness training conducted for all system users to get an understanding of the
importance of protecting passwords.
Protection Against Network-Related Threats
The safeguards currently at place at the external networks are new. They use filtering mechanism to
screen out unauthorized interactions. This is done by funnelling all traffic to and from external networks
through two interfaces. This basically helps to restrict the kinds of external network interactions.

© Copyright IBM Corp. 2016 1-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Router is able to distinguish email packets from other packets as it is specified by the internet protocols
that the information travelling from the internet carries an indicator of the type of service being used or
requested to process the information. Since router’s job is to translate the protocols associated with the
LAN and the Internet, it is able to identify email packet quite distinctively. Network Affairs configures the
router to discard all packets, except those associated with e-mail. Network Affairs personnel believe that
the router effectively eliminates Internet-based attacks on IT Department user accounts because it
disallows all remote log-in sessions, even those accompanied by a legitimate password.
The LAN server enforces a similar type of restriction for dial-in access via the public-switched network.
The access controls provided by the server's operating system have been configured so that during
dial-in sessions, only the e-mail utility can be executed. (IT Department policy, enforced by periodic
checks, prohibits installation of modems on PCs, so that access must be through the LAN server.) In
addition, the server's access controls have been configured so that its WAN interface device is
accessible only to programs that possess a special access-control privilege. Only the System
Administrator can assign this privilege to server programs, and only a handful of special-purpose
applications, like the time and attendance application, have been assigned this privilege.
Protection Against Risks from Non–IT Department Systems
There are systems and components that are owned by other organizations which IT Department cannot
control directly. This poses undue risks to IT Department’s systems. To deal with such potential risks, IT
Department has developed a policy that states that explicit permission is to be obtained from OCG
Manager and application owner before a system component, controlled and operated by organizations
other than IT Department, is used to process, store, or to transmit IT Department information. There
could be a need of a written commitment from the controlling organization stating that the information of
IT Department going through its systems will be safeguarded and they will be responsible for upholding
its value. This written commitment would be necessary to get permission to use such system
components.

© Copyright IBM Corp. 2016 1-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Case study: Vulnerability analysis IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Vulnerabilities analysis (reported by the risk assessment team)

– Vulnerabilities related to payroll fraud
• Falsified time sheets
• Unauthorized access
• Bogus time and attendance applications
• Unauthorized modification of time and attendance data
– Vulnerabilities related to payroll errors
– Vulnerabilities related to continuity of operations
• Network affairs contingency planning
• Division contingency planning
• Virus prevention
• Accidental corruption and loss of data
– Vulnerabilities related to information disclosure/brokerage
– Network-related vulnerabilities

© Copyright IBM Corporation 2016

Figure 1-16. Case study: Vulnerability analysis

Vulnerabilities Analysis (Reported by the Risk Assessment Team)

Risks exposed by the risk assessment team was found to be occurring due to the following reasons:
1. Individuals failing to comply with policies and procedures
2. Use of automated mechanisms with questionable assurance arising from the way of their
development, testing, implementation, or maintenance
Policies and procedures for protection against disclosure and brokerage of sensitive information, interruption
of operations, unauthorized access to data by outsiders and payroll fraud and errors were found to have more
specific vulnerabilities.
Vulnerabilities Related to Payroll Fraud
Falsified Time Sheets
The primary safeguards against falsified time sheets are review and approval by supervisory
personnel, who are not permitted to approve their own time and attendance data. The risk
assessment has concluded that, while imperfect, these safeguards are adequate. The related
requirement that a clerk and a supervisor must cooperate closely in creating time and attendance
data and submitting the data to the mainframe also safeguards against other kinds of illicit
manipulation of time and attendance data by clerks or supervisors acting independently.
Unauthorized Access

© Copyright IBM Corp. 2016 1-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
There are several “password-sniffer” programs available that can capture passwords when it is being
broadcasted over the LAN after a user enter the password to the server during Identification and
Authentication. This makes password vulnerable to be easily intercepted by any PC connected to the
LAN. The password could also be intercepted, before being transmitted to the server, by a malicious
program planted on a system. The captured passwords can be misused by an unauthorized
individual to run the time and attendance application.
Bogus Time and Attendance Applications
The server's access controls are probably adequate for protection against bogus time and
attendance applications that run on the server. However, the server's operating system and access
controls have only been in widespread use for a few years and contain a number of security-related
bugs. And the server's access controls are ineffective if not properly configured, and the
administration of the server's security features in the past has been notably lax.
Unauthorized Modification of Time and Attendance Data
Protection against unauthorized modification of time and attendance data requires a variety of
safeguards because each system component on which the data are stored or transmitted is a
potential source of vulnerabilities.
First, the time and attendance data are entered on the server by a clerk. On occasion, the clerk may
begin data entry late in the afternoon, and complete it the following morning, storing it in a temporary
file between the two sessions. One way to avoid unauthorized modification is to store the data on a
diskette and lock it up overnight. After being entered, the data will be stored in another temporary file
until reviewed and approved by a supervisor. These files, now stored on the system, must be
protected against tampering. As before, the server's access controls, if reliable and properly
configured, can provide such protection (as can digital signatures, as discussed later) in conjunction
with proper auditing.
Second, when the Supervisor approves a batch of time and attendance data, the time and
attendance application sends the data over the WAN to the mainframe. The WAN is a collection of
communications equipment and special-purpose computers called "switches" that act as relays,
routing information through the network from source to destination. Each switch is a potential site at
which the time and attendance data may be fraudulently modified. For example, an IT Department
PC user might be able to intercept time and attendance data and modify the data enroute to the
payroll application on the mainframe. Opportunities include tampering with incomplete time and
attendance input files while stored on the server, interception and tampering during WAN transit, or
tampering on arrival to the mainframe prior to processing by the payroll application.
Third, on arrival at the mainframe, the time and attendance data are held in a temporary file on the
mainframe until the payroll application is run. Consequently, the mainframe's Identification and
Authentication and access controls must provide a critical element of protection against unauthorized
modification of the data.
With some prior cautions, the data stored on the server gets an acceptable protection (from
unauthorized modification) by the server’s access controls. According to the risk assessment, since
IT Department has only cursory information about the service provider’s personnel security practices,
and IT Department possesses no authority over its operations on the WAN, a WAN-based attack,
that involves collusion between an employee of IT Department and an employee of the WAN service
provider should not be entirely dismissed.
The greatest source of vulnerabilities, however, is the mainframe. Although its operating system's
access controls are mature and powerful, it uses password-based Identification and Authentication.
This is of particular concern, because it serves a large number of federal agencies via WAN
connections. A number of these agencies are known to have poor security programs. As a result,
one such agency's systems could be penetrated (e.g., from the Internet) and then used in attacks on
the mainframe via the WAN. In fact, time and attendance data awaiting processing on the mainframe
would probably not be as attractive a target to an attacker as other kinds of data or, indeed, disabling
the system, rendering it unavailable. For example, an attacker might be able to modify the employee

© Copyright IBM Corp. 2016 1-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
data base so that it disbursed paychecks or pensions checks to fictitious employees.
Disclosure-sensitive law enforcement databases might also be attractive targets.
The intruders can find it very difficult to break into an application after they have already broken into
one. This is because the access control is deemed to be strong enough provided fairly good
protection.
Vulnerabilities Related to Payroll Errors
IT Department's management has established procedures for ensuring the timely submission and
interagency coordination of paperwork associated with personnel status changes. However, an
unacceptably large number of troublesome payroll errors during the past several years has been traced
to the late submission of personnel paperwork. The risk assessment documented the adequacy of IT
Department's safeguards, but criticized the managers for not providing sufficient incentives for
compliance.
Vulnerabilities Related to Continuity of Operations
Network Affairs Contingency Planning
The risk assessment commended IT Department for many aspects of Network Affairs's contingency
plan, but pointed out that many Network Affairs personnel were completely unaware of the
responsibilities the plan assigned to them. The assessment also noted that although IT
Department's policies require annual testing of contingency plans, the capability to resume IT
Department's computer-processing activities at another cooperating agency has never been verified
and may turn out to be illusory.
Division Contingency Planning
The risk assessment reviewed a number of the application-oriented contingency plans developed by
IT Department's divisions (including plans related to time and attendance). Most of the plans were
cursory and attempted to delegate nearly all contingency planning responsibility to Network Affairs.
The assessment criticized several of these plans for failing to address potential disruptions caused
by lack of access to computer resources not managed by Network Affairs and non-system resources,
such as buildings, phones, and other facilities. In particular, the contingency plan encompassing the
time and attendance application was criticized for not addressing disruptions caused by WAN and
mainframe outages.
Virus Prevention
The risk assessment found IT Department's virus-prevention policy and procedures to be sound, but
noted that there was little evidence that they were being followed. In particular, no Network Affairs
personnel interviewed had ever run a virus scanner on a PC on a routine basis, though several had
run them during publicized virus scares. The assessment cited this as a significant risk item.
Accidental Corruption and Loss of Data
After the risk assessment, it was concluded that though the safeguards deployed by IT Department
offered protection against accidental corruption and loss of time and attendance, they were not
adequate against other kinds of data. There was an informal audit conducted as the part of risk
assessment which covered about a dozen systems and users in the agency and it was concluded
that though many users were storing significant data on their servers, there was no provision of
backup.
Vulnerabilities Related to Information Disclosure/Brokerage
In order to protect information about its employees, IT Department takes a more conservative approach.
Protection of mainframe was the primary focus of risk assessment as large collections of data are prone
to information brokerage.
It was concluded in the risk assessment that due to IT Department’s lack of compliance with its own
policies, there were significant, but avoidable, information brokering vulnerabilities present. There was no
procedure followed for securely storing time and attendance documents. Not all of the PCs were routinely
locked and were found to be left logged into LAN server overnight. This left the data prone to malicious
individuals who could have browsed or copied time and attendance information.

© Copyright IBM Corp. 2016 1-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
It was also found in the risk assessment report that the information received from or sent to server was
prone to eavesdropping by other systems connected to the LAN. The information transmitted over the
LAN is without any encryption and by its innate property, LAN hardware broadcasts information to all of
the connection points on the LAN cable. This might leave an opportunity open for a prospective
information broker.
The IT Department’s mainframe was owned by an external agency which made the employee master
database (being part of the mainframe) a target for illicit acts, fraudulent modifications information
brokering by employees of external agency. The same threats are in place if an outsider manages to
penetrate the mainframe.
Network-Related Vulnerabilities
The risk assessment concurred with the general approach taken by IT Department, but identified several
vulnerabilities. It reiterated previous concerns about the lack of assurance associated with the server's
access controls and pointed out that these play a critical role in IT Department's approach. The
assessment noted that the e-mail utility allows a user to include a copy of any otherwise accessible file in
an outgoing mail message. If an attacker dialled in to the server and succeeded in logging in as an IT
Department employee, the attacker could use the mail utility to export copies of all the files accessible to
that employee. In fact, copies could be mailed to any host on the Internet.
The assessment also noted that the WAN service provider may rely on microwave stations or satellites
as relay points, thereby exposing IT Department's information to eavesdropping. Similarly, any
information, including passwords and mail messages, transmitted during a dial-in session is subject to
eavesdropping.

© Copyright IBM Corp. 2016 1-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Case study: Vulnerability mitigation IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Vulnerability mitigation
– Mitigating payroll fraud vulnerabilities
– Mitigating payroll error vulnerabilities
– Mitigating vulnerabilities related to the continuity of operations
– Mitigating threats of information disclosure/brokering
– Mitigating network-related threats

© Copyright IBM Corporation 2016

Figure 1-17. Case study: Vulnerability mitigation

Vulnerability Mitigation
Mitigating Payroll Fraud Vulnerabilities
To remove the vulnerabilities related to payroll fraud, the risk assessment team recommended the use of
stronger authentication mechanisms based on smart tokens to generate one-time passwords that cannot
be used by an interloper for subsequent sessions. Such mechanisms would make it very difficult for
outsiders (e.g., from the Internet) who penetrate systems on the WAN to use them to attack the
mainframe. The authors noted, however, that the mainframe serves many different agencies, and IT
Department has no authority over the way the mainframe is configured and operated. Thus, the costs
and procedural difficulties of implementing such controls would be substantial. The assessment team
also recommended improving the server's administrative procedures and the speed with which
security-related bug fixes distributed by the vendor are installed on the server.
After input from Network Affairs security specialists and application owners, IT Department's managers
accepted most of the risk assessment team's recommendations. They decided that since the residual
risks from the falsification of time sheets were acceptably low, no changes in procedures were necessary.
However, they judged the risks of payroll fraud due to the interceptability of LAN server passwords to be
unacceptably high, and thus directed Network Affairs to investigate the costs and procedures associated
with using one-time passwords for Time and Attendance Clerks and supervisor sessions on the server.
Other users performing less sensitive tasks on the LAN would continue to use password-based
authentication.
While the immaturity of the LAN server's access controls was judged a significant source of risk, Network
Affairs was only able to identify one other PC LAN product that would be significantly better in this

© Copyright IBM Corp. 2016 1-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
respect. Unfortunately, this product was considerably less friendly to users and application developers,
and incompatible with other applications used by IT Department. The negative impact of changing PC
LAN products was judged too high for the potential incremental gain in security benefits. Consequently,
IT Department decided to accept the risks accompanying use of the current product, but directed
Network Affairs to improve its monitoring of the server's access control configuration and its
responsiveness to vendor security reports and bug fixes.
IT Department concurred that risks of fraud due to unauthorized modification of time and attendance data
at or in transit to the mainframe should not be accepted unless no practical solutions could be identified.
After discussions with the mainframe's owning agency, IT Department concluded that the owning agency
was unlikely to adopt the advanced authentication techniques advocated in the risk assessment.
Network Affairs, however, proposed an alternative approach that did not require a major resource
commitment on the part of the mainframe owner.
The alternative approach would employ digital signatures based on public key cryptographic techniques
to detect unauthorized modification of time and attendance data. The data would be digitally signed by
the supervisor using a private key prior to transmission to the mainframe. When the payroll application
program was run on the mainframe, it would use the corresponding public key to validate the
correspondence between the time and attendance data and the signature. Any modification of the data
during transmission over the WAN or while in temporary storage at the mainframe would result in a
mismatch between the signature and the data. If the payroll application detected a mismatch, it would
reject the data; IT Department personnel would then be notified and asked to review, sign, and send the
data again. If the data and signature matched, the payroll application would process the time and
attendance data normally.
IT Department's decision to use advanced authentication for time and attendance Clerks and
Supervisors can be combined with digital signatures by using smart tokens. Smart tokens are
programmable devices, so they can be loaded with private keys and instructions for computing digital
signatures without burdening the user. When supervisors approve a batch of time and attendance data,
the time and attendance application on the server would instruct the supervisor to insert their token in the
token reader/writer device attached to the supervisors' PC. The application would then send a special
"hash" (summary) of the time and attendance data to the token via the PC. The token would generate a
digital signature using its embedded secret key, and then transfer the signature back to the server, again
via the PC. The time and attendance application running on the server would append the signature to the
data before sending the data to the mainframe and, ultimately, the payroll application.
Although this approach did not address the broader problems posed by the mainframe's Identification
and Authentication vulnerabilities, it does provide a reliable means of detecting time and attendance data
tampering. In addition, it protects against bogus time and attendance submissions from systems
connected to the WAN because individuals who lack a time and attendance supervisor's smart token will
be unable to generate valid signatures. (Note, however, that the use of digital signatures does require
increased administration, particularly in the area of key management.) In summary, digital signatures
mitigate risks from a number of different kinds of threats.
IT Department's management concluded that digitally signing time and attendance data was a practical,
cost-effective way of mitigating risks, and directed Network Affairs to pursue its implementation. (They
also noted that it would be useful as the agency moved to use of digital signatures in other applications.)
This is an example of developing and providing a solution in an environment over which no single entity
has overall authority.
Mitigating Payroll Error Vulnerabilities
After reviewing the risk assessment, IT Department's management concluded that the agency's current
safeguards against payroll errors and against accidental corruption and loss of time and attendance data
were adequate. However, the managers also concurred with the risk assessment's conclusions about
the necessity for establishing incentives for complying (and penalties for not complying) with these
safeguards. They thus tasked the Director of Personnel to ensure greater compliance with
paperwork-handling procedures and to provide quarterly compliance audit reports. They noted that the
digital signature mechanism IT Department plans to use for fraud protection can also provide protection
against payroll errors due to accidental corruption.

© Copyright IBM Corp. 2016 1-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
Mitigating Vulnerabilities Related to the Continuity of Operations
The assessment recommended that Network Affairs institute a program of periodic internal training and
awareness sessions for Network Affairs personnel having contingency plan responsibilities. The
assessment urged that Network Affairs undertake a rehearsal during the next three months in which
selected parts of the plan would be exercised. The rehearsal should include attempting to initiate some
aspect of processing activities at one of the designated alternative sites. IT Department's management
agreed that additional contingency plan training was needed for Network Affairs personnel and
committed itself to its first plan rehearsal within three months.
After a short investigation, IT Department divisions owning applications that depend on the WAN
concluded that WAN outages, although inconvenient, would not have a major impact on IT Department.
This is because the few time-sensitive applications that required WAN-based communication with the
mainframe were originally designed to work with magnetic tape instead of the WAN, and could still
operate in that mode; hence courier-delivered magnetic tapes could be used as an alternative input
medium in case of a WAN outage. The divisions responsible for contingency planning for these
applications agreed to incorporate into their contingency plans both descriptions of these procedures and
other improvements.
With respect to mainframe outages, IT Department determined that it could not easily make
arrangements for a suitable alternative site. IT Department also obtained and examined a copy of the
mainframe facility's own contingency plan. After detailed study, including review by an outside
consultant, IT Department concluded that the plan had major deficiencies and posed significant risks
because of IT Department's reliance on it for payroll and other services. This was brought to the attention
of the Director of IT Department, who, in a formal memorandum to the head of the mainframe's owning
agency, called for a high-level interagency review of the plan by all agencies that rely on the mainframe,
and corrective action to remedy any deficiencies found.
IT Department's management agreed to improve adherence to its virus-prevention procedures. It agreed
(from the point of view of the entire agency) that information stored on PC hard disks is frequently lost. It
estimated, however, that the labor hours lost as a result would amount to less than a person year - which
IT Department management does not consider to be unacceptable. After reviewing options for reducing
this risk, IT Department concluded that it would be cheaper to accept the associated loss than to commit
significant resources in an attempt to avoid it. Network Affairs volunteered, however, to set up an
automated program on the LAN server that e-mails backup reminders to all PC users once each quarter.
In addition, Network Affairs agreed to provide regular backup services for about 5 percent of IT
Department's PCs; these will be chosen by IT Department's management based on the information
stored on their hard disks.
Mitigating Threats of Information Disclosure/Brokering
IT Department concurred with the risk assessment's conclusions about its exposure to
information-brokering risks, and adopted most of the associated recommendations.
The assessment recommended that IT Department improve its security awareness training (e.g., via
mandatory refresher courses) and that it institute some form of compliance audits. The training should
be sure to stress the penalties for noncompliance. It also suggested installing "screen lock" software on
PCs that automatically lock a PC after a specified period of idle time in which no keystrokes have been
entered; unlocking the screen requires that the user enter a password or reboot the system.
The assessment recommended that IT Department modify its information-handling policies so that
employees would be required to store some kinds of disclosure-sensitive information only on PC local
hard disks (or floppies), but not on the server. This would eliminate or reduce risks of LAN
eavesdropping. It was also recommended that an activity log be installed on the server (and regularly
reviewed). Moreover, it would avoid unnecessary reliance on the server's access-control features, which
are of uncertain assurance. The assessment noted, however, that this strategy conflicts with the desire
to store most information on the server's disks so that it is backed up routinely by Network Affairs
personnel. (This could be offset by assigning responsibility for someone other than the PC owner to
make backup copies.) Since the security habits of IT Department's PC users have generally been poor,
the assessment also recommended use of hard-disk encryption utilities to protect disclosure-sensitive

© Copyright IBM Corp. 2016 1-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty
information on unattended PCs from browsing by unauthorized individuals. Also, ways to encrypt
information on the server's disks would be studied.
The assessment recommended that IT Department conduct a thorough review of the mainframe's
safeguards in these respects, and that it regularly review the mainframe audit log, using a query
package, with particular attention to records that describe user accesses to IT Department's employee
master database.
Mitigating Network-Related Threats
The assessment recommended that IT Department:
▪ require stronger Identification and Authentication for dial-in access or, alternatively, that a restricted
version of the mail utility be provided for dial-in, which would prevent a user from including files in
outgoing mail messages;
▪ replace its current modem pool with encrypting modems, and provide each dial-in user with such a
modem; and
▪ work with the mainframe agency to install a similar encryption capability for server-to-mainframe
communications over the WAN.
As with previous risk assessment recommendations, IT Department's management tasked Network
Affairs to analyze the costs, benefits, and impacts of addressing the vulnerabilities identified in the risk
assessment. IT Department eventually adopted some of the risk assessment's recommendations, while
declining others. In addition, IT Department decided that its policy on handling time and attendance
information needed to be clarified, strengthened, and elaborated, with the belief that implementing such a
policy would help reduce risks of Internet and dial-in eavesdropping. Thus, IT Department developed
and issued a revised policy, stating that users are individually responsible for ensuring that they do not
transmit disclosure-sensitive information outside of IT Department's facilities via e-mail or other means. It
also prohibited them from examining or transmitting e-mail containing such information during dial-in
sessions and developed and promulgated penalties for noncompliance.

© Copyright IBM Corp. 2016 1-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
1. IT Security goal of “Non-repudiation” guarantees
A. an operation cannot be refuted
B. only authorized personnel can have access to systems and no one else
C. non availability of system to unauthorized people
D. system’s proper operation
2. In what category would a software fall if it provides a way to an unauthorized individual access to
resources within the IT system environment
A. Threat
B. Risk
C. Vulnerability
D. Based on the resources involved, it can be a threat or a vulnerability
3. What threat does a “phreaker” pose to an organization’s IT system?
A. Disrupt services involving public telephone network
B. Injecting a malware in the IT network
C. Remove software protection
D. None of the above

© Copyright IBM Corporation 2016

Figure 1-18. Checkpoint

© Copyright IBM Corp. 2016 1-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
4. Which of the following is not true about a memory token?
A. Memory tokens process information after storing it
B. A magnetic striped card is an example of memory token
C. Production of memory tokens is costly
D. Both B and C
5. Which of the following is a function(s) of a constrained user interface?
A. Help user to implement system-specific policy with flexibility
B. Assign privileges to the owner of a system
C. Restrict users' access to specific functions
D. Both A and B
6. Which of the following statements is true for secret key cryptography?
A. Secret key cryptography uses a single key shared by two (or more) parties
B. Secret key cryptography relies on keeping the key secret
C. Secret key cryptography is relatively faster than public key cryptography
D. All of the above

© Copyright IBM Corporation 2016

Figure 1-19. Checkpoint

© Copyright IBM Corp. 2016 1-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
7. Choose the correct alternative from the following
Assertion (A): Password-based access control is often inexpensive
Reason (R): It is already included in a large variety of applications
A. Both A and R are true and R is the correct explanation of A
B. Both A and R are true but R is NOT the correct explanation of A
C. A is false but R is true
D. Both A and R are false
8. Encryption can be used in IT system security as a mechanism for
A. logical access control for systems
B. protecting information when it is being transmitted over a network
C. Both A and B
D. Only B
9. Which of the following is NOT a means of authenticating a user's identity?
A. A token e.g., an ATM card or a smart card
B. Handwriting dynamics
C. A Personal Identification number
D. None of the above

© Copyright IBM Corporation 2016

Figure 1-20. Checkpoint

© Copyright IBM Corp. 2016 1-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
10. Which of the following is a drawback of smart tokens
A. They need reader/writers or human intervention
B. They require strong Administration
C. All of the above
D. Both C and D

© Copyright IBM Corporation 2016

Figure 1-21. Checkpoint

© Copyright IBM Corp. 2016 1-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 1. Introduction to IT system security

Uempty

Unit summary IBM ICE (Innovation Centre for Education)

IBM Power Systems

Having completed this unit, you should be able to:

• Get an overview of IT system security
• Understand need of IT system security
• Get familiar with technical controls in IT system security
• Gain insight on system security risk management
• Understand transformation trends

© Copyright IBM Corporation 2016

Figure 1-22. Unit summary

© Copyright IBM Corp. 2016 1-67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Unit 2. Operating System Security

Overview
This unit provides knowledge about the security issues faced by modern operating systems and how they
can be mediated

How you will check your progress

• Checkpoint

© Copyright IBM Corp. 2016 2-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Unit objectives IBM ICE (Innovation Centre for Education)

IBM Power Systems

After completing this unit, you should be able to:

• Get to know the threats that are faced by operating systems and how they are evolving
• Understand key security features of operating systems
• Get an insight on the security guidelines for server and workstation operating systems
• Get familiar with threats in various mobile operating systems

© Copyright IBM Corporation 2016

Figure 2-1. Unit objectives

© Copyright IBM Corp. 2016 2-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Operating System & Changing Threats IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Introduction of Changing Threats

– Basics of Operating Systems & changing threats
– Formal security mechanisms in operating system

© Copyright IBM Corporation 2016

Figure 2-2. Operating System & Changing Threats

Operating systems:
Operating systems are the software that provides access to the various hardware resources (e.g. CPU,
memory, and devices) that comprise a computer system. Any program that is being run on a computer
system has instructions executed by that computer’s CPU, but these programs may also require the use of
other peripheral resources of these complex systems. Consider a program that allows a user to enter her
password. The operating system provides access to the disk device on which the program is stored, access
to device memory to load the program so that it may be executed, the display device to show the user how to
enter her password, and keyboard and mouse devices for the user to enter her password. Ofcourse, there
are now a multitude of such devices that can be used seamlessly, for the most part, thanks to the function of
operating systems. Operating systems run programs in processes.
The challenge for an operating system developer is to permit multiple concurrently executing processes to
use these resources in a manner that preserves the independence of these processes while providing fair
sharing of these resources. Originally, operating systems only permitted one process to be run at a time (e.g.,
batch systems), but as early as 1960, it became apparent that computer productivity would be greatly
enhanced by being able to run multiple processes concurrently. By concurrently, we mean that while only one
process uses a computer’s CPU at a time, multiple other processes maybe in various states of execution at
the same time, and the operating system must ensure that these executions are performed effectively. For
example, while the computer waits for a user to enter her password, other processes may be run and access
system devices as well, such as the network. These systems were originally called time sharing systems, but
they are our default operating systems today. To build any successful operating system, we identify three
major tasks. First, the operating system must provide various mechanisms that enable high performance use
of computer resources.

© Copyright IBM Corp. 2016 2-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
Operating systems must provide efficient resource mechanisms, such as file systems, memory management
systems, network protocol stacks, etc. that define how processes use the hardware resources. Second, it is
the operating system’s responsibility to switch among the processes fairly, such that the user experiences
good performance from each process in concert with access to the computer’s devices. This second problem
is one of scheduling access to computer resources. Third, access to resources should be controlled, such
that one process cannot inadvertently or maliciously impact the execution of another. This third problem is the
problem of ensuring the security of all processes run on the system. Ensuring the secure execution of all
processes depends on the correct implementation of resource and scheduling mechanisms. First, any correct
resource mechanism must provide boundaries between its objects and ensure that its operations do not
interfere with one another. For example, a file system must not allow a process request to access one file to
overwrite the disk space allocated to another file. Also, file systems must ensure that one write operation is
not impacted by the data being read or written in another operation. Second, scheduling mechanisms must
ensure availability of resources to processes to prevent denial of service attacks. For example, the algorithms
applied by scheduling mechanisms must ensure that all processes are eventually scheduled for execution.
Security becomes an issue because processes in modern computer systems interact in a variety of ways,
and the sharing of data among users is a fundamental use of computer systems. First, the output of one
process may be used by other processes. For example, a programmer uses an editor program to write a
computer program’s source code, compilers and linkers to transform the program code into a form in which it
can be executed, and debuggers to view the executing processes image to find errors in source code. In
addition, a major use of computer systems is to share information with other users. With the ubiquity of
Internet-scale sharing mechanisms, such as e-mail, the web, and instant messaging, users may share
anything with anyone in the world. Unfortunately, lots of people, or at least lots of email addresses, websites,
and network requests, want to share stuff with you that aims to circumvent operating system security
mechanisms and cause your computer to share additional, unexpected resources. The ease with which
malware can be conveyed and the variety of ways that users and their processes may be tricked into running
malware present modern operating system developers with significant challenges in ensuring the security of
their system’s execution. The challenge in developing operating systems security is to design security
mechanisms that protect process execution and their generated data in an environment with such complex
interactions.
As we will see, formal security mechanisms that enforce provable security goals have been defined, but
these mechanisms do not account or only partially account for the complexity of practical systems. As such,
the current state of operating systems security takes two forms: (1) constrained systems that can enforce
security goals with a high degree of assurance and (2) general-purpose systems that can enforce limited
security goals with a low to medium degree of assurance. First, several systems have been developed over
the years that have been carefully crafted to ensure correct (i.e., within some low tolerance for bugs)
enforcement of specific security goals. These systems generally support few applications, and these
applications often have limited functionality and lower performance requirements. That is, in these systems,
security is the top priority, and this focus enables the system developers to write software that approaches
the ideal of the formal security mechanisms mentioned above. Second, the computing community at large
has focused on function and flexibility, resulting in general-purpose, extensible systems that are very difficult
to secure. Such systems are crafted to simplify development and deployment while achieving high
performance, and their applications are built to be feature-rich and easy to use. Such systems present
several challenges to security practitioners, such as insecure interfaces, dependence of security on arbitrary
software, complex interaction with untrusted parties anywhere in the world, etc. But, these systems have
defined how the user community works with computers. As a result, the security community faces a difficult
task for ensuring security goals in such an environment. However, recent advances are improving both the
utility of the constrained systems and the security of the general-purpose systems.
Changing Threats:
In order to mitigate different threats, operating systems have evolved from being run on stand-alone
computers to highly optimised and networked computers. Some 30 years ago, internal users accessing data
and computing time, that they were not entitled to, posed threats to shared stand-alone mainframes used by
large organization and universities. 20 years ago, operating systems started supporting a wide range of
applications and network connectivity. By this time, an increasing community of hackers and curious external
individuals as well as some internally connected users started proffering new threats around the exchange of

© Copyright IBM Corp. 2016 2-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
malicious data or network access. This was a major effect of the increasing connectivity. 10 years ago, the
integration and dependence of operating system on the networks of globally connected organizations made
online applications for confidential data vulnerable to threats from serious criminals and activists who had
access to computing resources and network reach to internet. The threats extended further that have brought
about the need for the operating systems to upgrade their defenses.
With the developments in technology and the advent of cloud, there have been increasing trends of operating
systems being deployed onto storage resources and shared public computation in cloud data centers. This,
in turn, has attracted attacks against collocated operating systems and their hosting platforms and hence
rendering the protection of data and availability of services ineffective.
The number of types and potential network attacks against hosting platforms have increased significantly with
the devices being connected to a variety of public networks and other devices owing to the increased
availability of wireless networks.
Miniaturisation of technology has brought threats of physical theft for small devices (such as mobile phones)
and has left large quantities of sensitive data vulnerable
There have been advancements at the malicious side of internet with threats becoming more advanced and
capable raising in organizations. These advanced malware and the possibility of threats like potential
interception of communications between platforms and cloud data centers creates a necessity for operating
systems to develop mitigations and other security controls.

© Copyright IBM Corp. 2016 2-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Why OS is Hard to Secure? IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Explaining why the Operating system is hard to secure

– OS not able to find themselves prone attacks
– Multiple peripherals can be externally connected through interfaces, such as integral devices
– Unlike USB driver and hardware devices developed by the hardware manufacturers, etc.

© Copyright IBM Corporation 2016

Figure 2-3. Why OS is Hard to Secure?

Why OS is Hard to Secure?

With the evolving threat landscape, operating systems have had to upgrade their security controls and, but at
the same time there have been significant challenges coming forward for operating systems to generate
appropriate response against these threats.
10 years ago, Microsoft Windows became vulnerable to a multitude of network based attacks because of its
ubiquity and market dominance. At this time, most organizations were moving their services and
communications online using Microsoft’s operating system.
As the network surface of the operating system opened up to the Internet, there were increasing discoveries
of the type and range of vulnerabilities and a rapid increase in the exploitation. Operating systems, such as
UNIX, did not find themselves prone to these attacks. However, these attacks enabled Microsoft to secure its
operating systems and software by significantly enhancing the software development and assurance
process. Thus, operating systems could support and rely on increased connectivity to networks and multiple
peripherals. Multiple peripherals can be externally connected through interfaces, such as integral devices
(such as graphics card) or USB. The software required to interface these peripheral devices and network of
devices could operate in privileged mode within the operating system. This way, they could access
resources, such as processor memory, directly. An attacker is able to gain full control of the operating system,
via a crafted USB device, owing to the vulnerabilities within USB device drivers in the operating system.
Unlike USB driver (which tends to be a part of the operating system software), software drivers for graphic
and network devices are developed by the hardware manufacturers. This creates a challenge when these
software are integrated into the operating system as there is a question mark on the “assurance of integrity”
of these software.

© Copyright IBM Corp. 2016 2-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
With growing network connectivity and increasing hardware performance, the functionality of operating
systems has also increased in order to take advantage the aforementioned surges. This has brought some
new challenges as the size and complexity of operating systems has increased significantly. This, in turn, has
also increased the cost and difficulty invested in the examination of operating systems for security issues and
vulnerabilities.
Because of the increase in complexity codes are re-used at different times and if there is a vulnerability in the
code used from a code base believed to be “trusted”, the code re-used in the future leads to propagation of
vulnerabilities. There was an incident where a code base of Linux was re-used in Android which was believed
to have a previously known vulnerability. The vulnerability, which allowed the privileges of a local user to be
escalated (i.e. beyond their restricted user privileges to system privileges), was replicated in Android.
Today, there are multiple applications allowed for a desktop or smartphone that allows users to accommodate
and use application befitting their requirements. The user has control over the functionality and choice over
what application to use. This rich flexible environment provided enabled operating systems to increase
protection for itself, its resources and all users from various application vulnerabilities.

© Copyright IBM Corp. 2016 2-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Securing Operating Systems IBM ICE (Innovation Centre for Education)

IBM Power Systems

• How to secure operating system and its models:

– Trust Model
– Threat Model

© Copyright IBM Corporation 2016

Figure 2-4. Securing Operating Systems

Securing Operating Systems

As the security issues were being identified in operating systems, there were also advances made towards
the designing building and hardening operating system security. This includes standards being created for
operating systems (such as Common Criteria scheme), which allowed a wider variety of operating systems to
be evaluated against certain “protection standards”. This helped in defining threats and security goals of the
operating system being evaluated.
In response to increasing security threats and vulnerabilities discovery, there have been high security
operating systems being developed by the industry. In response to the incident mentioned before, Microsoft
felt the need to improve its security by rapidly re-engineering its security architecture and security assurance
approach to enable users, using their software, to deal with increasing security threats and growing size and
complexity of the code.
Open source communities have also sought steps to develop a full secure operating system or enhance
specific security features of an operating system. This varies with the functionality provided by different
operating systems, for example,
operating systems such as seL4 are highly assured minimal operating systems developed for mobile and
embedded devices, while others such as TrsutedBSD provide full functionality needed of a server
environment.
There have been consistent goals for a secure operating system established for almost every
community:

© Copyright IBM Corp. 2016 2-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
• Ensuring that the operating system is able to separate users and access to resources by following a
defined policy.
• Ensuring that a trusted execution path is followed. “Trusted” means that there are no vulnerabilities that
might affect the operating system’s ability to separate users and access to resources, such as memory,
files, I/O and processes.
It has become mandatory to attend to threats originating in mobile and embedded devices with development
of more sophisticated operating systems. The steps towards security include securing device data in the
event of theft or loss, or validating that the software has not been tampered in case an unidentified party
gains physical access to device.
The ideal goal of operating system security is the development of a secure operating system. A secure
operating system provides security mechanisms that ensure that the system’s security goals are enforced
despite the threats faced by the system. These security mechanisms are designed to provide such a
guarantee in the context of the resource and scheduling mechanisms. Security goals define the requirements
of secure operation for a system for any processes that it may execute. The security mechanisms must
ensure these goals regardless of the possible ways that the system maybe misused (i.e. is threatened) by
attackers. The term “secure operating system” is both considered an ideal and an oxymoron. Systems that
provide a high degree of assurance in enforcement have been called secure systems, or even more
frequently “trusted” systems. However, it is also true that no system of modern complexity is completely
secure. The difficulty of preventing errors in programming and the challenges of trying to remove such errors
means that no system as complex as an operating system can be completely secure. Nonetheless, studying
how to build an ideal secure operating system is useful in assessing operating systems security.
Trust Model
A system’s trust model defines the set of software and data upon which the system depends for correct
enforcement of system security goals. For an operating system, its trust model is synonymous with the
system’s trusted computing base (TCB). Ideally, a system TCB should consist of the minimal amount of
software necessary to enforce the security goals correctly. The software that must be trusted includes the
software that defines the security goals and the software that enforces the security goals (i.e., the operating
system’s security mechanism). Further, software that bootstraps this software must also be trusted. Thus, an
ideal TCB would consist of a bootstrapping mechanism that enables the security goals to be loaded and
subsequently enforced for lifetime of the system. In practice, a system TCB consists of a wide variety of
software. Fundamentally, the enforcement mechanism is run within the operating system. As there are no
protection boundaries between operating system functions (i.e., in the typical case of a monolithic operating
system), the enforcement mechanism must trust all the operating system code, so it is part of the TCB.
Further, a variety of other software running outside the operating system must also be trusted. For example,
the operating system depends on a variety of programs to authenticate the identity of users (e.g., login and
SSH). Such programs must be trusted because correct enforcement of security goals depends on correct
identification of users. Also, there are several services that the system must trust to ensure correct
enforcement of security goals. For example, windowing systems, such as the X Window System, perform
operations on behalf of all processes running on the operating system, and these systems provide
mechanisms for sharing that may violate the system’s security goals (e.g., cut-and-paste from one application
to another). As a result, the X Window Systems and a variety of other software must be added to the system’s
TCB. The secure operating system developer must prove that their systems have a viable trust model. This
requires that: (1) the system TCB must mediate all security-sensitive operations; (2) verification of the
correctness of the TCB software and its data; and (3) verification that the software’s execution cannot be
tampered by processes outside the TCB. First, identifying the TCB software itself is a nontrivial task for
reasons discussed above. Second, verifying the correctness of TCB software is a complex task. For
general-purpose systems, the amount of TCB software outside the operating system is greater than the
operating system software that is impractical to verify formally. The level of trust in TCB software can vary
from software that is formally-verified (partially), fully-tested, and reviewed to that which the user community
trusts to perform its appointed tasks. While the former is greatly preferred, the latter is often the case. Third,
the system must protect the TCB software and its data from modification by processes outside the TCB. That
is, the integrity of the TCB must be protected from the threats to the system. Otherwise, this software can be
tampered, and is no longer trustworthy.
Threat Model

© Copyright IBM Corp. 2016 2-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
A threat model defines a set of operations that an attacker may use to compromise a system. In this threat
model, we assume a powerful attacker who is capable of injecting operations from the network and maybe in
control of some of the running software on the system (i.e., outside the trusted computing base). Further, we
presume that the attacker is actively working to violate the system security goals. If an attacker is able to find
a vulnerability in the system that provides access to secret information (i.e., violate secrecy goals) or permits
the modification of information that subjects depend on (i.e., violate integrity goals), then the attacker is said
to have compromised the system. Since the attacker is actively working to violate the system security goals,
we must assume that the attacker may try any and all operations that are permitted to the attacker. For
example, if an attacker can only access the system via the network, then the attacker may try to send any
operation to any processes that provide network access. Further, if an attacker is in control of a process
running on the system, then the attacker will try any means available to that process to compromise system
security goals. This threat model exposes a fundamental weakness in commercial operating systems (e.g.,
UNIX and Windows); they assume that all software running on behalf of a subject is trusted by that subject.
For example, a subject may run a word processor and an email client, and in commercial systems these
processes are trusted to behave as the user would.
However, in this threat model, both of these processes may actually be under the control of an attacker (e.g.,
via a document macro virus or via a malicious script or email attachment). Thus, a secure operating system
cannot trust processes outside of the TCB to behave as expected. While this may seem obvious, commercial
systems trust any user process to manage the access of that user’s data (e.g., to change access rights to a
user’s files via chmod in a UNIX system). This can result in the leakage of that user’s secrets and the
modification of data that the user depends on. The task of a secure operating system developer is to protect
the TCB from the types of threats described above. Protecting the TCB ensures that the system security
goals will always be enforced regardless of the behavior of user processes. Since user processes are
untrusted, we cannot depend on them, but we can protect them from threats. For example, secure operating
system can prevent a user process with access to secret data from leaking that data, by limiting the
interactions of that process. However, protecting the TCB is more difficult because it interacts with a variety of
untrusted processes.
A secure operating system developer must identify such threats, assess their impact on system security, and
provide effective countermeasures for such threats. For example, a trusted computing base component that
processes network requests must identify where such untrusted requests are received from the network,
determine how such threats can impact the component’s behavior, and provide countermeasures, such as
limiting the possible commands and inputs, to protect the component. The secure operating system
developer must ensure that all the components of the trusted computing base prevent such threats correctly.

© Copyright IBM Corp. 2016 2-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Key Security Features (1 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Defining the various features of security

– Access control
– Network protection

© Copyright IBM Corporation 2016

Figure 2-5. Key Security Features (1 of 2)

Access control
Operating system, at its core, has the ability to administer control over access to system information and
resources. This is done in order to mitigate threats as well as minimize the possibility of any accidental
damage by the users. The need to prevent a poorly implemented application, that can access the private
data of users stored in the memory, is as important as the need to prevent inadvertent download of malware
through a browser and installing unwanted spying software. So, apart from being an obvious security feature,
controlling access to confidential files of multiple users on a shared system is just as important.
Apart from unauthorized users being able to access files, another facet of this threat is files being accessed
by processes or machines to resources including memory, networks, data files, peripherals, etc. It is ensured
by access control, lying at the heart of operating systems, that only legitimate users and processes are
allowed to access the resources and they use only those resources that have been entitled to them.
Access controls differ from one operating system to another. Though, in layman’s terms, access is the ability
to read from, write to, or execute a file, operating systems, such as Microsoft Windows, provide richer access
operations that provides the option to acquire ownership of or even delete a data type.
When there are a large number of users and there is a need to store a wide range of permitted operations for
those users and access to an even larger number of resources, it itself builds into a tricky task. It would
require to check and store every time an individual user request access to a resource, creating practical
difficulties.
There are principles that are well established to ensure secure control access and its proper practical
implementation:

© Copyright IBM Corp. 2016 2-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
• It has to be ensured that there exists a trusted mechanism to first decide and then enforce the rights of
the user (requesting access to a resource) along with designated rights of the resource requested. This
capability is called as the reference monitor.
• When these rights are being enforced, it has to be made sure that there are no vulnerabilities present in
the enforcement capability. It must be free from any modifications or tampering done beforehand. This
concept is referred to as the Trusted Computing Base.
• A trusted path must be followed while the enforcement happens. This minimizes the possibility of
interruption of execution path by malicious processes or users. This concept is known as the Trusted
Path.
These capabilities are implemented to perfection by only a few operating systems. There is a security
reference monitor in Microsoft Windows that mediates the requests (for access to resources or files)
generated by users. Based on the operations attempted by the user, it also generates audit messages.
Additionally, there is no possibility of interception of password and user credentials by any other installed
application (that could be a malware) as there is a prioritised and trusted execution path provided for the
console logon (Ctrl+Alt+Del). Capability for Mandatory Access Control (MAC) and support for reference
monitor have also been added in UNIX versions, such as SELinux or TrustedBSD. Most files fall under a
scheme known as Discretionary Access Control, according to which the ownership of most files lies with one
user who grants or deny access to other users.
Secure operating systems (including those implementing a reference monitor) are required to protect files for
a lot of reasons. Other than following standard policy, there is also a mandatory need of maintaining integrity
of files, which is achieved by avoiding modification of files that could render them corrupted and avoiding
misuse of the file by a malware or a naïve user. Additionally, and on similar lines, an access policy has to be
enforced that ensures that the access remains in denial stage, when an external user is granted access to a
file (which might be containing classified intelligence) until the clearance of the user is enhanced and the file
sensitivity is relegated.
Apple iOS operating system has built upon the TrustedBSD MAC framework the capability to limit access to
objects in its operating systems. There are a couple of policies a process for application control that helps
maintain file integrity. Applications are enable for only a specific system resources and their access is limited
to only those resources. For example, if an application cannot connect to the Internet, it is because of the
restrictions imposed by the operating system.
Network protection
With most users finding it mandatory to communicate with each other and while accessing applications and
data, most of the operating systems are deployed in highly networked environments. Before the advent of the
more sophisticated operating systems, network that connected the users were believed to be trustworthy as
the files that were being shared. These networks connected organizations on trusted or in-house networks.
Nowadays, we have devices that are highly mobile being connected over untrusted and public networks (for
e.g., the Internet). So, to counter this problem, operating systems adapted and the developers started to
embed security features (such as firewalls, network encryption and network access protection) onto their
operating systems.
As the operating systems witnessed the amalgamation of the Internet in their operations, there was a peak
increase in vulnerabilities being reported in various operating systems. Windows and UNIX systems were
found to have faults in the most basic protocols being used by operating systems for propagation of data.
Vulnerabilities were also found in the services offered by the operating systems. This vulnerability included
memory overflow caused by malformed messages followed by execution of malicious instructions or
sensitive memory being accessed and data transmitted to an attacker. Flaws in protocols included
vulnerabilities present in the implementation of network protocols.
Many operating systems were compelled to have firewalls build for reducing the possibility of malicious
individuals from accessing network services and unauthorized applications. Firewalls also helped the
operating systems to limit the number of external connections to allow successful connections to be made
only to trusted resources especially those directly on the Internet, outside the assured protection of
organizational framework.

© Copyright IBM Corp. 2016 2-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
More secure protocols (such as TLS/SSL and WPA2) have found to be supported by operating systems over
time which has enabled connections to individual systems (using Public Key Cryptography (PKI) for
encryption and mutual authentication and networks) and to organizational networks over the internet. The
operating system and its general security health can be identified through the mutual authentication done in
PKI. This means that it is assured that the operating system is not compromised and it would not be
contributing in propagation of any malware before it gets access to a corporate network. This scheme is
known as Network Access Protection.

© Copyright IBM Corp. 2016 2-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Key Security Features (2 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Defining the various features of security

– Malware protection

© Copyright IBM Corporation 2016

Figure 2-6. Key Security Features (2 of 2)

Malware protection
Users’ requirements to access and exchange application and files have been increasing. This has led to an
increase in the means of exchange including social media platforms, web portals and messaging systems.
Parallelly, the issue of malware has also caught a steep upslope. Most of the cyber security attacks have had
been a result of a malicious file being received from an email or a website.
▪ Application Verification and Control
It is always possible that a careless or a malicious user causes potential damage to the core
operating system code and data of other users and applications. Most operating systems tend to
maintain user’s privileges to access resources quite different from those of an administrator. This is
done as a principle to secure resources from being damages by a malware.
Operating systems, such as Microsoft Windows and Apple iOS, use techniques that verify the code
within an application for its authenticity; that whether it has been modified or from a trusted source.
This is unlike the operating systems where identity of the user or the group who owned the code was
to identify the authenticity of the code i.e. whether it was acceptable to execute or not. The modern
operating systems judge the code by matching the fingerprint or “hash” of the application to be
executed with the cryptographically signed hash. This hash is obtained by extraction from a
certificate from a trusted authority that came with the application. For example, this mechanism is
implemented by Apple iOS. Apple’s operating system enforces all applications from the app store.
There is no provision to install applications from external sources. The application on the Apple app
store are signed by Apple after verifying their integrity from a security perspective.

© Copyright IBM Corp. 2016 2-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
Operating systems have also evolved in the means by which they assess and control the execution
of files. They have extended their mechanism such that the access can be granted or denied based
upon the attributes of file (such as time/date of creation, version, location in the file system) and the
identity of the user requesting to access the file. Microsoft Windows’ Applocker is an application that
follows this identity-file attribute mechanism to grant access to other applications/resources.
It is also possible that an application being executed and the execution process might get
compromised even after the application is granted permission of execution. For example, content
downloaded from browser or mail reader might start executing malware on the system that can
compromise operating system security. Operating systems make the use of cryptographic
mechanisms by the following methods:
- Protection of a list of capabilities that an application may require such that the operating system
is aware of any additional capabilities being requested (for e.g., network, GPS) after it was
launched. It is possible that a malware might attempt to turn on the microphone and camera. This
step prevents that from happening.
- A code signing mechanism can be used. It ensures that application has not been compromised
by the signed application code being checked by the operating system while the process is being
loaded into the memory.
▪ Application Separation: Sandboxing
The technique of sandboxing is used to provide a form of isolation to an application to ensure that the
functionality of the application is “boxed-in” (limited), such that the ability of the application to access
other running applications, or the memory or network resources of other applications. This method
can be applied using different approaches.
In one of these approaches, a hypervisor is sought which provides a “container” to separate out and
execute multiple operating systems on a common platform. Whole operating system is virtualized
and run on a hypervisor which summaries the hardware environment for the platform. While this
approach protects applications on the same hardware irrespective of the operating system, it does
not offer any protection to other applications in the same operating system.
It can also be seen that a vulnerable application, for e.g. a browser, has a built-in sandbox protection
which can limit the ability of code required to be executed on the operating system.
Another case is that the application can be constrained to a single process space. This way the
application is allowed to be executed within its own context and operating system maintains that
access to shared system resources are defined before the installation and execution of application.
Application Execution
There is a possibility of application being exploited by attackers using the user supplied input. Buffer overrun
is the most common form of attacks in the which the input supplied by user end up to be written directly to the
operating systems and application memory (normally used to store application execution code, temporary
and global data) without any prior verification of its integrity. The attacker, using this vulnerability of data going
in without any check, takes control of the application execution by supplying sufficient data and manipulating
the stack pointer. The attacker, rather than simply execute the application, executes the data and code they
have written to the memory within the application context.
To secure themselves from such attacks, application data is marked as non-executable by the operating
systems. This makes it difficult for the attacker to execute any data that he/she manages to write into the
memory. However, attackers have found a way around this solution. They use a technique called “return
to-lib-c/return orientated programming” in which they use already loaded and existing code and libraries off
the operating system. This code is referenced in a sequence in which they attempt to execute their desired
function which allows them to work their way around the non-execution of overwritten data or the
non-availability of space to fit in all of the malicious instructions.
A technique of address space layout randomization is used by operating systems to mitigate this attack. This
reduces the ability of the attacker to guess and access predictable software codes by randomizing memory
locations in which the executable code and libraries are loaded.

© Copyright IBM Corp. 2016 2-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
Physical Theft
The very simplest and oldest of threats i.e. theft and physical access of the device has raised ears with the
recent advent of mobile devices and the technology in hand and the widespread Internet connectivity. Unlike
20 years ago, when it would have taken a crane to move systems of online platforms from a building, these
systems are now in the reach of a pickpocket. Access to the device can provide access to significant
resources and data as the capacity of operating systems to access online services and store locally on smart
devices has been increased significantly.
Operating systems have found protection using following ways:
• Operating systems can now encrypt individual data files and also the data stored in the memory.
Applications and data can be protected from other users and processes in case an individual gains
access to device for a short period.
• Data on devices is protected against subsequent copying in case the device gets stolen. This is done by
encrypting all the data present on the device.
Since cryptographic operations can consume too much power and prove to be costly, hardware encryption
mechanisms are used in the aforementioned approaches, which are simply built into many chips/processors.
For example, in Apple iOS use an application processor which stores for every individual device, a unique
cryptographic key. This key is never accessed by the operating system directly and is used to sign and
encrypt data other in encryption routines. This key is never accessed or disclosed and is embedded into the
application processor during the time of manufacture. Similarly, in Microsoft Windows, Bitlocker is designed
to use a tamper-proof hardware chip (Trusted Platform Module) which stores encryption key material.

© Copyright IBM Corp. 2016 2-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Operating system history IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Brief histories abut different operating systems

– Unix
– Window

© Copyright IBM Corporation 2016

Figure 2-7. Operating system history

UNIX History
UNIX is a multiuser operating system developed by Dennis Ritchie and KenThompson at AT&T Bell Labs.
UNIX started as a small project to build an operating system to play a game on an available PDP-7 computer.
However, UNIX grew over the next 10 to 15 years into a system with considerable mindshare, such that a
variety of commercial UNIX efforts were launched. The lack of coherence in these efforts may have limited
the market penetration of UNIX, but many vendors, even Microsoft, had their own versions. UNIX remains a
significant operating system today, embodied in many systems, such as Linux, Sun Solaris, IBM AIX, the
various BSD systems, etc. Bell Labs was a member of the Multics consortium. However, Bell Labs dropped
out of the Multics project in 1969, primarily due to delays in the project. Ken Thompson adapted some of the
ideas of Multics when he initiated the construction of a system that was named as a pun on the Multics
system, UNICS (UNIplexed Information and Computing Service). Eventually and mysteriously, the system
was renamed UNIX, but the project had begun. UNIX gained mindshare for a number of reasons. Ritchie
rewrote UNIX in his new programming language C which enabled UNIX to be the first portable operating
system. This enabled the development of a UNIX community, since lots of people could run UNIX on a variety
of different hardware. Next, an application program interface was designed for UNIX which enabled
programmers to write application easily, without resorting to assembly language, and these applications ran
across the variety of UNIX-supported platforms. Finally, UNIX was truly simplified when compared to Multics.
While UNIX adopted many Multics principles, such as hierarchical file systems, virtual memory, and
encrypted passwords, UNIX was far simpler. UNIX aimed for a small base program called the kernel with a
standard interface to simplify the development of applications. As a result, the code size of UNIX (at the time)
was smaller than Multics, UNIX performed better, and UNIX was easier to program and administer.

© Copyright IBM Corp. 2016 2-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
As a streamlined descendant of Multics, UNIX adopted several of the Multics security features, such as
password storage, protection ring usage, access control lists, etc., but most were streamlined as well. Since
UNIX was not a government-funded project like Multics, it was built with different security goals in mind. For
UNIX, the goal was to develop a common platform (e.g., devices and file system) that could be shared by
several users. As a result, the security problem became one of protection, where the goal is to protect the
users’ data from inadvertent errors in their programs. However, protection does not ensure that secrecy and
integrity goals (i.e. security) can be achieved. Security enforcement requires that a system’s security
mechanisms can enforce system security goals even when all the software outside the trusted computing
base is malicious. Thus, when UNIX systems were connected to untrusted users via the Internet, a variety of
design decisions made for protection no longer applied. The ordinary UNIX security mechanisms are not
capable of enforcing the requirements of a secure operating system. A variety of efforts have aimed to extend
or replace the insecure mechanisms for ordinary UNIX systems with mechanisms that may achieve the
requirements of a secure operating system.
Windows History
The history of the Microsoft Windows operating system goes back to the introduction of MS-DOS, which was
the original operating system for IBM personal computers introduced in 1981. MS-DOS was constructed from
the Quick and Dirty Operating System (QDOS) built by Tim Paterson that Microsoft purchased from his
employer Seattle Computer Products. QDOS was itself based on an early microcomputer operating system
called the Control Program for Microcomputers (CP/M). Compared to other operating systems of the time,
such as Multics and UNIX, MS-DOS was a very limited system. It was not a true multitasking system, and did
not use many of the features of the x86 processor. Over the next 20 years, Microsoft made improvements to
MS-DOS to support more efficient and flexible use of the x86 hardware. Windows was originally a GUI for
MS-DOS, but its visibility soon led to using its name for the subsequent operating systems that Microsoft
released. Early Windows systems were based on various versions of MS-DOS, but MS-DOS became less
fundamental to the later “Windows 9x” systems. A second, independent line of systems based on the NT
kernel emerged starting with the Windows NT 4.0. In 2000, the Windows systems derived from the original
MS-DOS codebase were discontinued. At this point, the Windows brand of operating systems dominated the
desktop computing market and spanned most computing devices, but the lack of focus on security in
Windows operating systems was becoming a significant limitation in these systems. As the initial focus of the
Windows operating system was on microcomputer platforms envisioned for a single user and disconnected
from any network, security was not a feature of such systems. Users administered their systems, uploading
new programs as they were purchased. However, the emergence of the world-wide web made connecting
Windows computers to the network fundamental to its use, and the networked services that users leveraged,
such as email, web clients, easy program download, etc., introduced vulnerabilities that the Windows
systems were not designed to counter. The usability model of Windows as an open, flexible,
user-administered platform, plus its ubiquity, made it an easy target for attackers. Further, Microsoft was slow
to address such threats. In 2000, features were nearly always enabled by default, leading to world-wide
compromises due to Windows vulnerabilities (e.g. Code Red and variants). Microsoft has focused with some
success on reducing its vulnerabilities through better code development practices, code analysis tools , and
more secure configuration settings. However, improvements in the security features of the Windows
operating systems have been less effective. The Windows 2000-based access control system is complex and
largely unused, the Windows operating system trusted computing base is extremely large (50 million lines of
source code in the operating system alone), and recent security enhancements for Windows Vista are both in
sufficient to provide complete integrity protection and so invasive as to be unpopular.

© Copyright IBM Corp. 2016 2-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Security in Ordinary Operating Systems

UNIX (1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the few security systems in UNIX

– UNIX Protection System
– UNIX Authorization

© Copyright IBM Corporation 2016

Figure 2-8. Security in Ordinary Operating SystemsUNIX (1 of 2)

UNIX Security
A running UNIX system consists of an operating system kernel and many processes each running a program.
A protection ring boundary isolates the UNIX kernel from the processes. Each process has its own address
space, that defines the memory addresses that it can access. Modern UNIX systems define address spaces
primarily in terms of the set of memory pages that they can access. UNIX uses the concept of a file for all
persistent system objects, such as secondary storage, I/O devices, network, and inter-process
communication. A UNIX process is associated with an identity, based on the user associated with the
process, and access to files is limited by the process’s identity. UNIX security aims to protect users from each
other and the system’s trusted computing base (TCB) from all users. Informally, the UNIXTCB consists of the
kernel and several processes that run with the identity of the privileged user, root or super-user. These root
processes provide a variety of services, including system boot, user authentication, administration, network
services, etc. Both the kernel and root processes have full system access. All other processes have limited
access based on their associated user’s identity.
UNIX Protection System
UNIX implements a classical protection system, not the secure protection system. A UNIX protection system
consists of a protection state and a set of operations that enable processes to modify that state. Thus, UNIX
is a discretionary access control (DAC) system. However, UNIX does have some aspects of the secure
protection system. First, the UNIX protection system defines a transition state that describes how processes
change between protection domains. Second, the labelling state is largely ad hoc. Trusted services associate
processes with user identities, but users can control the assignment of permissions to system resources (i.e.,
files). In the final analysis, these mechanisms and the discretionary protection system are insufficient to build

© Copyright IBM Corp. 2016 2-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
a system that satisfies the secure operating system requirements. A protection state describes the operations
that the system’s subjects can perform on that system’s objects. The UNIX protection state associates
process identities (subjects) with their access to files (objects). Each UNIX process identity consists of a user
ID (UID), a group ID (GID), and a set of supplementary groups. These are used in combination to determine
access. All UNIX resources are represented as files. The protection state specifies that subjects may perform
read, write, and execute operations on files, with the standard meaning of these operations. While directories
are not files, they are represented as files in the UNIX protection state, although the operations have different
semantics (e.g. execute means search for a directory). Files are also associated with an owner UID and an
owner GID which conveys special privileges to processes with these identities. A process with the owner UID
can modify any aspect of the protection state for this file. Processes with either the owner UID and group GID
may obtain additional rights to access the file as described below. The limited set of objects and operations
enabled UNIX designers to use a compressed access control list format called UNIX mode bits, to specify the
access rights of identities to files. Mode bits define the rights of three types of subjects: (1) the file owner UID;
(2) the file group GID; and (3) all other subjects. Using mode bits authorization is performed as follows:
First, the UNIX authorization mechanism checks whether the process identity’s UID corresponds to the owner
UID of the file, and if so, uses the mode bits for the owner to authorize access. If the process identity’s GID or
supplementary groups correspond to the file’s group GID, then the mode bits for the group permissions are
used. Otherwise, the permissions assigned to all others are used.
The UNIX protection system is a discretionary access control system. Specifically, this means that a file’s
mode bits, owner UID, or group GID may be changed by any UNIX processes run by the file’s owner (i.e. that
have the same UID as the file owner). If we trust all user processes to act in the best interests of the user,
then the user’s security goals can be enforced. However, this is no longer a reasonable assumption.
Nowadays, users run a variety of processes, some of which maybe supplied by attackers and others may be
vulnerable to compromise from attackers, so the user will have no guarantee that these processes will
behave consistently with the user’s security goals. As a result, a secure operating system cannot use
discretionary access control to enforce user security goals. Since discretionary access control permits users
to change their files owner UID and group GID in addition to the mode bits, file labelling is also discretionary.
A secure protection system requires a mandatory labelling state, so this is another reason that UNIX systems
cannot satisfy the requirements of a secure operating system.
UNIX processes are labelled by trusted services from a set of labels (i.e. user UIDs and group GIDs) defined
by trusted administrators, and child processes inherit their process identity from their parent. This mandatory
approach to labelling processes with identities would satisfy the secure protection system requirements,
although it is rather inflexible. Finally, UNIX mode bits also include a specification for protection domain
transitions, called the setuid bit. When this bit is set on a file, any process that executes the file with
automatically perform a protection domain transition to the file’s owner UID and group GID. For example, if a
root process sets the setuid bit on a file that it owns, then any process that executes that file will run under the
root UID. Since the setuid bit is a mode bit, it can be set by the file’s owner, so it is also managed in a
discretionary manner. A secure protection state requires a mandatory transition state describe all protection
domain transitions, so the use of discretionary setuid bits is insufficient.
UNIX Authorization
The UNIX authorization mechanism controls each process’s access to files and implements protection
domain transitions that enable a process to change its identity. The authorization mechanism runs in the
kernel, but it depends on system and user processes for determining its authorization queries and its
protection state. For these and other reasons described in the UNIX security analysis, the UNIX authorization
mechanism does not implement a reference monitor. UNIX authorization occurs when files are opened, and
the operations allowed on the file are verified on each file access. The requesting process provides the name
of the file and the operations that will be requested upon the file in the open system call. If authorized, UNIX
creates a file descriptor that represents the process’s authorized access to perform future operations on the
file. File descriptors are stored in the kernel, and only an index is returned to the process. User processes
present their file descriptor index to the kernel when they request operations on the files that they have
opened.
UNIX authorization controls traditional file operations by mediating file open for read, write, and execute
permissions. However, the use of these permissions does not always have the expected effect: (1) these
permissions and their semantics do not always enable adequate control and (2) some objects are not

© Copyright IBM Corp. 2016 2-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
represented as files, so they are unmediated. If a user has read access to a file, this is sufficient to perform a
wide-variety of operations on the file besides reading. For example, simply via possession of a file descriptor,
a user process can perform any ad hoc command on the file using the system calls ioctl or fcntl, as well as
read and modify file metadata. Further, UNIX does not mediate all security - sensitive objects, such as
network communications. Host firewalls provide some control of network communication, but they do not
restrict network communication by process identity.
The UNIX authorization mechanism depends on user-level authentication services, such as login and sshd,
to determine the process identity (i.e., UID, GID, and supplementary groups). When a user logs in to a
system, her processes are assigned her login identity. All subsequent processes created in this login session
inherit this identity unless there is a domain transition. Such user-level services also need root privileges in
order to change the identity of a process, so they run with this special UID. However, several UNIX services
need to run as root in order to have the privileges necessary to perform their tasks. These privileges include
the ability to change process identity, access system files and directories, change file permissions, etc. Some
of these services are critical to the correct operation of UNIX authorization, such as sshd and passwd, but
others are not, such as inetd and ftp. However, a UNIX system’s trusted computing base must include all root
processes, thus risking compromise of security critical services and the kernel itself.
UNIX protection domain transitions are performed by the setuid mechanism. setuid is used in two ways: (1) a
root process can invoke the setuid system call to change the UID of a process4 and (2) a file can have its
setuid mode bitset, such that whenever it is executed its identity is set to the owner of the file. In the first case,
a privileged process, such as login or sshd, can change the identity of a process. For example, when a user
logs in, the login program must change the process identity of the user’s first process, her shell, to the user to
ensure correct access control. In the second case, the use of the setuid bit on a file is typically used to permit
a lower privileged entity to execute a higher privileged program, almost always as root. For example, when a
user wishes to change her password, she uses the passwd program. Since the passwd program modifies the
password file, it must be privileged, so a process running with the user’s identity could not change the
password file. The setuid bit on the root-owned, passwd executable’s file is set, so when any user executes
passwd, the resultant process identity transitions to root. While the identity transition does not impact the
user’s other processes, the writers of the passwd program must be careful not to allow the program to be
tricked into allowing the user to control how passwd uses its additional privileges.
UNIX also has a couple of mechanisms that enable a user to run a process with a reduced set of
permissions. Unfortunately, these mechanisms are difficult to use correctly, are only available to root
processes, and can only implement modest restrictions. First, UNIX systems have a special principal nobody
that owns no files and belongs to no groups. Therefore, a process’s permissions can be restricted by running
as nobody since it never has owner or group privileges. Unfortunately, nobody, like all subjects, has others
privileges. Also, since only root can do a setuid only a superuser process can change the process identity to
nobody. Second, UNIX chroot can be used to limit a process to a subtree of the file system. Thus, the process
is limited to only its rights to files within that subtree. Unfortunately, a chroot environment must be setup
carefully to prevent the process from escaping the limited domain. For example, if an attacker can
create/etc/passwd and /etc/shadow files in the subtree, she can add an entry for root, login as this root, and
escape the chroot environment (e.g. using root access to kernel memory). Also, a chroot environment can
only be setup by a root process, so it is not usable to regular system users. In practice, neither of these
approaches has proven to be an effective way to limit process permissions.

© Copyright IBM Corp. 2016 2-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Security in Ordinary Operating Systems

UNIX (2 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the few security systems in UNIX

– UNIX Security Analysis
– UNIX Vulnerabilities

© Copyright IBM Corporation 2016

Figure 2-9. Security in Ordinary Operating SystemsUNIX (2 of 2)

UNIX Security Analysis

If UNIX can be a secure operating system, it must satisfy the secure operating system requirements.
However, UNIX fails to meet any of these requirements.
1. Complete Mediation: How does the reference monitor interface ensure that all security sensitive
operations are mediated correctly?
The UNIX reference monitor interface consists of hooks to check access for file or inode permission on some
system calls. The UNIX reference monitor interface authorizes access to the objects that the kernel will use in
its operations. A problem is that the limited set of UNIX operations (read, write, and execute) is not
expressive enough to control access to information. UNIX permits modifications to files without the need for
write permission (e.g. fcntl).
2. Complete Mediation: Does the reference monitor interface mediate security-sensitive operations on all
system resources?
UNIX authorization does not provide complete mediation of all system resources. For some objects, such as
network communications, UNIX itself provides no authorization at all.
3. Complete Mediation: How do we verify that the reference monitor interface provides complete mediation?
Since the UNIX reference monitor interface is placed where the security - sensitive operations are performed,
it difficult to know whether all operations have been identified and all paths have been mediated. No specific
approach has been used to verify complete mediation.

© Copyright IBM Corp. 2016 2-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
4. Tamperproof: How does the system protect the reference monitor, including its protection system, from
modification?
The reference monitor and protection system are stored in the kernel, but this does not guarantee
tamper-protection. First, the protection system is discretionary, so it may be tampered by any running
process. Untrusted user processes can modify permissions to their user’s data arbitrarily, so enforcing
security goals on user data is not possible.
Second, the UNIX kernel is not as protected from untrusted user processes as the Multics kernel is. Both use
protection rings for isolation, but the Multics system also explicitly specifies gates for verifying the legality of
the ring transition arguments. While UNIX kernels often provide procedures to verify system call arguments,
such procedures are may be misplaced.
Finally, user-level processes have a variety of interfaces to access and modify the kernel itself above and
beyond system calls, ranging from the ability to install kernel modules to special file systems (e.g., /proc or
sysfs) to interfaces through netlink sockets to direct access to kernel memory (e.g., via the device
file/dev/kmem). Ensuring that these interfaces can only be accessed by trusted code has become
impractical.
5. Tamperproof: Does the system’s protection system protect the trusted computing base programs?
In addition to the kernel, the UNIX TCB consists of all root processes, including all processes run by a user
logged in as a root user. Since these processes could run any program, guaranteeing the tamper - protection
of the TCB is not possible. Even ignoring root users, the amount of TCB code is far too large and faces far too
many threats to claim a tamperproof trusting computing base. For example, several root processes have
open network ports that may be used as avenues to compromise these processes. If any of these processes
is compromised, the UNIX system is effectively compromised as there is no effective protection among root
processes.
Also, any root process can modify any aspect of the protection system. As we show below, UNIX root
processes may not be sufficiently trusted or protected, so unauthorized modification of the protection system,
in general, is possible. As a result, we cannot depend on a tamperproof protection system in a UNIX system.
6. Verifiable: What is basis for the correctness of the system’s TCB? Any basis for correctness in a UNIX
system is informal. The effectively unbounded size of the TCB prevents any effective formal verification.
Further, the size and extensible nature
of the kernel (e.g. via new device drivers and other kernel modules) makes it impractical to verify its
correctness.
7. Verifiable: Does the protection system enforce the system’s security goals?
Verifiability enforcement of security goals is not possible because of the lack of complete mediation and the
lack of tamperproofing. Since we cannot express policy rich enough to prevent unauthorized data leakage or
modification, we cannot enforce secrecy or integrity security goals. Since we cannot prove that the TCB is
protected from attackers, we cannot prove that the system will be remain able to enforce our intended
security goals, even if they could be expressed properly.
UNIX Vulnerabilities
A secure operating system must protect its trusted computing base from compromise in order to implement
the reference monitor guarantees as well. In this section, we list some of the vulnerabilities that have been
found in UNIX systems over the years that have resulted in the compromise of the UNIX trusted computing
base. This list is by no means comprehensive. Rather, we aim to provide some examples of the types of
problems encountered when the system design does not focus on protecting the integrity of the trusted
computing base.
Network-facing Daemons
UNIX has several root (i.e. TCB) processes that maintain network ports that are open to all remote parties
(e.g., sshd, ftpd, sendmail, etc.), called network-facing daemons. In order to maintain the integrity of the
system’s trusted computing base, and hence achieve the reference monitor guarantees, such process must
protect themselves from such input. However, several vulnerabilities have been reported for such processes,
particularly due to buffer overflows, enabling remote attackers to compromise the system TCB. Some of

© Copyright IBM Corp. 2016 2-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
these daemons have been redesigned to remove many of such vulnerabilities (e.g., Postfix as a replacement
for send mail and privilege-separated SSH), but a comprehensive justification of integrity protection for the
resulting daemons is not provided. Thus, integrity protection of network facing daemons in UNIX is
incomplete and ad hoc. Further, some network - facing daemons, such as remote login daemons (e.g. telnet,
rlogin, etc.) ftpd, and NFS, puts an undo amount of trust in the network. The remote login daemons and ftpd
are notorious for sending passwords in the clear. Fortunately, such daemons have been obsoleted or
replaced by more secure versions (e.g. vsftpd for ftpd). Also, NFS is notorious for accepting any response to
a remote file system request as being from a legitimate server. Network-facing daemons must additionally
protect the integrity of their secrets and authenticate the sources of remote data whose integrity is crucial to
the process.
Rootkits
Modern UNIX systems support extension via kernel modules that may be loaded dynamically into the kernel.
However, a malicious or buggy module may enable an attacker to execute code in the kernel, with full system
privileges. A variety of malware packages, called rootkits, have been created for taking advantage of kernel
module loading or other interfaces to the kernel available to root processes. Such rootkits enable the
implementation of attacker function and provide measures to evade from detection. Despite efforts to detect
malware in the kernel, such rootkits are difficult to detect, in general.
Environment Variables
UNIX systems support environment variables, system variables that are available to processes to convey
state across applications. One such variable is LIBPATH whose value determines the search order for
dynamic libraries. A common vulnerability is that an attacker can change LIBPATH to load an
attacker-provided file as a dynamic library. Since environment variables are inherited when a child process is
created, an untrusted process can invoke a TCB program (e.g., a program file which setuid’s to root on
invocation) under an untrusted environment. If the TCB process depends on dynamic libraries and does not
set the LIBPATH itself, it may be vulnerable to running malicious code. As many TCB programs can be
invoked via setuid, this is a widespread issue.
Further, TCB programs may be vulnerable to any input value supplied by an untrusted process, such as
malicious input arguments. For example, a variety of program permit the caller to define the configuration file
of the process. A configuration file typically describes all the other places that the program should look for
inputs to describe how it should function, sometimes including the location of libraries that it should use and
the location of hosts that provide network information. If the attack can control the choice of a program’s
configuration file, she often has a variety of ways to compromise the running process. Any TCB program
must ensure their integrity regardless of how they are invoked.
Shared Resources
If TCB processes share resources with untrusted processes, then they may be vulnerable to attack. A
common problem is the sharing of the /tmp directory. Since any process can create files in this directory, an
untrusted process is able to create files in this directory and grant other processes, in particular a TCB
process, access to such files as well. If the untrusted process can guess the name of TCB process’s /tmp file,
it can create this file in advance, grant access to the TCB process, and then have access itself to a TCB file.
TCB processes can prevent this problem by checking for the existence of such files upon creation (e.g., using
the O_CREAT flag). However, programmers have been prone to forget such safeguards. TCB process must
take care when using any objects shared by untrusted processes.
Time-of-Check-to-Time-of-Use (TOCTTOU)
Finally, UNIX has been prone to a variety of attacks where untrusted processes may change the state of the
system between the time an operation is authorized and the time that the operation is performed. If such a
change enables an untrusted process to access a file that would not have been authorized for, then this
presents a vulnerability. The attack was first identified by Dilger and Bishop who gave it the moniker
time-of-check-to-time-of-use attacks or TOCTTOU attacks. In the classical example, a root process uses the
system call access to determine if the user for whom the process is running (e.g. the process was initiated by
a setuid) has access to a particular file /tmp/X. However, after the access system call authorizes the file
access and before the file open, the user may change the binding between the file name and the actual file
object (i.e., inode) accessed. This can be done by change the file /tmp/X to a symbolic link to the target file

© Copyright IBM Corp. 2016 2-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
/etc/shadow. As a result, UNIX added a flag, so the open request could prevent traversal via symbolic links.
However, the UNIX file system remains susceptible to TOCTTOU attacks because the mapping between file
names and actual file objects (inodes) can be manipulated by the untrusted processes. As a result of the
discretionary protection system, the size of the system TCB, and these types of vulnerabilities, converting a
UNIX system to a secure operating system is a significant challenge. Ensuring that TCB processes protect
themselves, and thus protect a reference monitor from tampering, is a complex undertaking as untrusted
processes can control how TCB processes are invoked and provide inputs in multiple ways: network,
environment, and arguments. Further, untrusted processes may use system interfaces to manipulate any
shared resources and may even change the binding between object name and the actual object.

© Copyright IBM Corp. 2016 2-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Security in Ordinary Operating Systems

Windows (1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the few security systems in Windows

– Windows Protection System
– Windows Authorization

© Copyright IBM Corporation 2016

Figure 2-10. Security in Ordinary Operating SystemsWindows (1 of 2)

Windows Protection System

The Windows 2000 protection system, like the UNIX protection system, provides a discretionary access
control model for managing protection state, object labelling, and protection domain transitions. The two
protection systems manly differ in terms of flexibility (e.g. the Windows system is extensible) and expressive
power (e.g. the Windows system enables the description of a wider variety of policies). Unfortunately, when
we compare the Windows protection system to the definition of a secure protection system, we find that
improvements in flexibility and expressive power actually make the system more difficult to secure.
Specifically, the Windows protection system differs from UNIX mainly in the variety of its objects and
operations and the additional flexibility it provides for assigning them to subjects. When the Windows 2000
access control model was being developed, there were a variety of security systems being developed that
provided administrators with extensible policy languages that permitted flexible policy specification, such as
the Java 2 model. While these models address some of the shortcomings of the UNIX model by enabling the
expression of any protection state, they do not ensure a secure system. Subjects in Windows are similar to
subjects in UNIX. In Windows, each process is assigned a token that describes the process’s identity.
A process identity consists of user security identifier (principal SID, analogous to a UNIX UID), a set of group
SIDs (rather than a single UNIX GID and a set of supplementary groups), a set of alias SIDs (to enable
actions on behalf of another identity), and a set of privileges (ad hoc privileges just associated with this
token). A Windows identity is still associated with a single user identity, but a process token for that user may
contain any combination of rights. Unlike UNIX, Windows objects can belong to a number of different data
types besides files. In fact, applications may define new data types, and add them to the active directory, the
hierarchical name space for all objects known to the system. From an access control perspective, object
types are defined by their set of operations. The Windows model also supports a more general view of the

© Copyright IBM Corp. 2016 2-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
operations that an object type may possess. Windows defines up to 30 operations per object type, including
some operations that are specific to the data type. This contrasts markedly with the read, write, and execute
operations in the UNIX protection state. Even for file objects, the Windows protection system defines many
more operations, such as operations to access file attributes and synchronize file operations. In addition,
application may add new object types and define their own operations.
The other major difference between a Windows and UNIX protection state is that Windows supports arbitrary
access control lists (ACLs) rather than the limited mode bits approach of UNIX. A Windows ACL stores a set
of access control entries (ACEs) that describe which operations an SID (user, group, or alias) can perform on
that object. The operations in an ACE are interpreted based on the object type of the target object. In
Windows, ACEs may either grant or deny an operation.
Thus, Windows uses negative access rights, whereas UNIX does not, generating some differences in their
authorization mechanisms.
Windows Authorization
Windows authorization queries are processed by a specific component called the Security Reference Monitor
(SRM). The SRM is a kernel component that takes a process token, an object SID, and a set of operations,
and it returns a boolean result of an authorization query. The SRM uses the object SID to retrieve its ACL
from which it determines the query result.
Because of the negative permissions, the way that the SRM processes authorization queries is more
complicated than in the UNIX case. The main difference is that the ACEs in an ACL are ordered, and the
ACEs are examined in that order. The SRM searches the ACEs until it finds a set of ACEs that permits the
operation or a single ACE that denies the operation. If an ACE grants the necessary operations, then the
request is authorized. However, if a deny ACE is encountered that includes one of the requested operations,
then the entire request is denied.
Mediation in Windows is determined by a set of object managers. Rather than a monolithic set of system calls
to access homogeneous objects (i.e. files) in UNIX, each object type in Windows has an object manager that
implements the functions of that type. While the Windows object managers all run in the kernel, the object
managers are independent entities. This can be advantageous from a modularity perspective, but the fact
that object managers may extend the system presents some challenges for mediation. We need to know that
each new object manager mediates all operations and determines the rights for those operations correctly.
There is no process for ensuring this in Windows. In Windows, the trusted computing base consists of all
system services and processing running as a trusted user identity, such as Administrator. Windows provides
a setuid-like mechanism for invoking Windows Services that run at a predefined privilege, at least sufficient to
support all clients. Thus, vulnerabilities in such services would lead to system compromise.
Further, the ease of software installation and complexity of the discretionary Windows access control model
often result in users running as Administrator. In this case, any user program would be able to take control of
the system. This is often a problem on Windows systems. With the release of Windows Vista, the Windows
model is extended to prevent programs downloaded from the Internet from automatically being able to write
Windows applications and the Windows system, regardless of the user’s process identity. While this does
provide some integrity protection, it does not fully protect the system’s integrity. It prevents low integrity
processes from writing to high integrity files, but does not prevent invocation, malicious requests, or spoofing
the high integrity code into using a low integrity file. Windows also provides a means for restricting the
permissions available to a process flexibly, called restricted contexts.
By defining a restricted context for a process, the permissions necessary to perform an operation must be
available to both the process using its token and to the restricted context. That is, the permissions of a
process running in a restricted context are the intersection of the restricted context and the process’s normal
permissions. Since a restricted context may be assigned an arbitrary set of permissions, this mechanism is
much more flexible than the UNIX option of running as nobody. Also, since restricted contexts are built into
the access control system, it is less error-prone than chroot. Nonetheless, restricted contexts are difficult for
administrators to define correctly, so they are not used commonly, and not at all by the user community.

© Copyright IBM Corp. 2016 2-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Security in Ordinary Operating Systems

Windows (2 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the few security systems in Windows

– Windows Security Analysis
– Windows Vulnerabilities

© Copyright IBM Corporation 2016

Figure 2-11. Security in Ordinary Operating SystemsWindows (2 of 2)

Windows Security Analysis

Despite the additional expressive power offered by the Windows access control model, it also does not
satisfy any of the reference monitor guarantees either. Although Windows can express any combination of
permissions, it becomes more difficult to administer. In my informal polls, no users use the Windows
permission model at all, whereas most at least were aware of how to use the UNIX model (although not
always correctly). Windows is effectively no more or less secure than ordinary UNIX - they are both insecure.
1. Complete Mediation: How does the reference monitor interface ensure that all securitysensitive
operations are mediated correctly?
In Windows, mediation is provided by object managers. Without the source code, it is difficult to know where
mediation is performed, but we would presume that object managers would authorize the actual objects used
in the security-sensitive operations, similarly to UNIX.
2. Complete Mediation: Does the reference monitor interface mediate security-sensitive operations on all
system resources?
Object managers provide an opportunity for complete mediation, but provide no guarantee of mediation.
Further, the set of managers maybe extended, resulting in the addition of potentially insecure object
managers. Without a formal approach that defines what each manager does and how it is to be secured, it
will not be possible to provide a guarantee of complete mediation.
3. Complete Mediation: How do we verify that the reference monitor interface provides complete mediation?
As for UNIX, no specific approach has been used to verify complete mediation.

© Copyright IBM Corp. 2016 2-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
4. Tamperproof: How does the system protect the reference monitor, including its protection system, for
modification?
Windows suffers from the same problems as UNIX when it comes to tampering. First, the protection system is
discretionary, so it may be tampered by any running process. Untrusted user processes can modify
permissions to their user’s data arbitrarily, so enforcing security goals on user data is not possible. Since
users have often run as Administrator to enable ease of system administration, any aspect of the protection
system may be modified. Second, there are limited protections for the kernel itself. Like UNIX, a Windows
kernel can be modified through kernel modules. In Microsoft Vista, a code signing process can be used to
determine the certifier of a kernel module (i.e., the signer, not necessarily the writer of the module). Of
course, the administrator (typically an end user) must be able to determine the trustworthiness of the signer.
Security procedures that depend on the decision-making of users are often prone to failure, as users are
often ignorant of the security implications of such decisions. Also, like UNIX, the Windows kernel also does
not define protections for system calls (e.g.,Multics gates).
5. Tamperproof: Does the system’s protection system protect the trusted computing base programs?
The TCB of Windows system is no better than that of UNIX. Nearly any program may be part of the Windows
TCB, and any process running these programs can modify other TCB programs invalidating the TCB. Like
UNIX, any compromised TCB process can modify the protection system invalidating the enforcement of
system security goals, and modify the Windows kernel itself through the variety of interfaces provided to TCB
processes to access kernel state. Unlike UNIX, Windows provides APIs to tamper with other processes in
ways that UNIX does not. For example, Windows provides the Create Remote Thread function, which
enables a process to initiate a thread in another process. Windows also provides functions for writing a
processes memory via Open Process and Write Process Memory, so one process can also write the desired
code into that process prior to initiating a thread in that process. While all of these operations require the
necessary access rights to the other process, usually requiring a change in privileges necessary for
debugging a process (via the Adjust Token Privileges). While such privileges are typically only available to
processes under the same SID, we must verify that these privileges cannot be misused in order to ensure
tamper-protection of our TCB.
6. Verifiable: What is basis for the correctness of the system’s trusted computing base?
As for UNIX, any basis for correctness is informal. Windows also has an unbounded TCB and extensible
kernel system that prevent any effective formal verification.
7. Verifiable: Does the protection system enforce the system’s security goals?
The general Windows model enables any permission combination to be specified, but no particular security
goals are defined in the system. Thus, it is not possible to tell whether a system is secure. Since the model is
more complex than the UNIX model and can be extended arbitrarily, this makes verifying security even more
difficult.
Windows Vulnerabilities
Not surprisingly given its common limitations, Windows suffers from the same kinds of vulnerabilities as the
UNIX system. For example, there are books devoted to constructing Windows root kits. Here we highlight a
few vulnerabilities that are specific to Windows systems or are more profound in Windows systems.
The Windows Registry
The Windows Registry is a global, hierarchical database to store data for all programs. When a new
application is loaded it may update the registry with application specific, such as security-sensitive
information such as the paths to libraries and executables to be loaded for the application. While each
registry entry can be associated with a security context that limits access, such limitations are generally not
effectively used. For example, the standard configuration of AOL adds a registry entry that specifies the name
of a Windows library file (i.e. DLL) to be loaded with AOL software. However, the permissions were set such
that any user could write the entry.
This use of the registry is not uncommon, as vendors have to ensure that their software will execute when it is
downloaded. Naturally, a user will be upset if she downloads some newly-purchased software, and it does not
execute correctly because it could not access its necessary libraries. Since the application vendors cannot
know the adhoc ways that a Windows system is administered, they must turn on permissions to ensure that

© Copyright IBM Corp. 2016 2-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
whatever the user does the software runs. If the registry entry is later used by an attacker to compromise the
Windows system, that is not really the application vendor’s problem - selling applications is.
Administrator Users
We mentioned in the Windows security evaluation that traditionally users ran under the identity Administrator
or at least with administrative privileges enabled. The reason for this is similar to the reason that broad
access is granted to registry entries: the user also wants to be sure that they can use what function is
necessary to enable the system to run. If the user downloads some computer game, the user would need
special privileges to install the game, and likely need special privileges to run the device - intensive game
program. The last thing the user wants is to have to figure out why the game will not run, so enabling all
privileges works around this issue. UNIX systems are generally used by more experienced computer users
who understand the difference between installing software (e.g. run sudo) and the normal operation of the
computer. As a result, the distinction between root users and sudo operations has been utilized more
effectively in UNIX.
Enabled by Default
Like users and software vendors, Windows deployments also came with full permissions and functionality
enabled. This resulted in the famous Code Red worms which attacked the SQL server component of the
Microsoft IIS web server. Many people who ran IIS did not have an SQL server running or even knew that the
SQL server was enabled by default in their IIS system. But in these halcyon times, IIS web servers ran with
all software enabled, so attackers could send malicious requests to SQL servers on any system, triggering a
buffer overflow that was the basis for this worm’s launch. Subsequent versions of IIS are now “locked down”,
such that software has to be manually enabled to be accessible.

© Copyright IBM Corp. 2016 2-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Server Operating System Security Guidelines IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Here are the guidelines for server operating security system

– Installation & Configuration
Function Static ports
– OS Hardening Browsing UDP:137,138
– Disabling unwanted services and protocols DHCP Lease UDP:67,68
DHCP Manager TCP:135
Directory Replication UDP:138 TCP:139
DNS Administration TCP:139
DNS Resolution UDP:53
Event Viewer TCP:139
File Sharing TCP:139
Logon Sequence UDP:137,138 TCP139
NetLogon UDP:138
Pass Through Validation UDP:137,138 TCP:139
Performance Monitor TCP:139
PPTP TCP:1723 IP Protocol:47
Printing UDP:137,138 TCP:139
Registry Editor TCP:139
Server Manager TCP:139
Trusts UDP:137,138 TCP:139
User Manager TCP:139
WinNT Diagnostics TCP:139
WinNT Secure Channel UDP:137,138 TCP:139
WINS Replication TCP:42
WINS Manager TCP:135
WINS Registration TCP:137
© Copyright IBM Corporation 2016

Figure 2-12. Server Operating System Security Guidelines

Server Operating System Security Guidelines

System Administrators verify that already installed Servers & guidance for new server setup and general
topics required for setting up a server in secure environment. Follwinf steps can be taken in order to assure
the integrity of OS. The steps mentioned are OS independent.
Installation & Configuration
The installation should be carried out from the original media, supplied by the vendor. The OS hardening
should be done following the steps listed in the guidelines provided by the vendor for this purpose. This
includes installation of patches, disabling of unwanted ports, etc. Care should be taken to match the release
of patches with the OS version number.
OS Hardening
Patches
One of the most important tasks of the System Administrator (SA) is to keep the most current patches for the
OS and application software installed on a server. Many of these patches fix security vulnerabilities that are
well known to intruders. There are two types of patches in general viz. Service Packs and Hotfixes. Installing
these patches in order is important. Service Packs must be installed before the Hotfixes.
• Service packs are used to patch a wide range of vulnerabilities and bugs. The latest service pack that
has been tested to work in one’s environment should always be applied after installing the operating
system. Service packs are cumulative; users need to install the latest Service Pack.

© Copyright IBM Corp. 2016 2-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
• Hotfixes are released more frequently than service packs and are meant to patch a more specific
problem. Not all hotfixes may be needed for a particular system. Before installing these fixes on critical
systems or installing them on a large number of devices, hotfixes should be tested to ensure that there is
no conflict with other third party drivers.
Disabling unwanted services and protocols
Only required network services should be installed in the server. There are many default services with the
standard OS software. Depending upon the role of server one should load only required network services,
like on a mail server DNS service is not required.
Disable unneeded network protocols, as each installed protocol takes server resources. Only essential
protocols should be loaded on the server. Each network protocol should be configured for security settings,
like in case of TCP/IP protocol only essential ports should be enabled. For example, on MS Windows NT
Server disable inbound and outbound traffic to the external connections for TCP and UDP ports 135, 137,
139 and UDP port 138. Blocking these ports prevents potential intruders from gathering useful information
such as computer names, usernames, and services running on those computers.
Security scanner tools like NMAP, NESSUS should be run to know which ports or services are currently open
or running on the server. Any unwanted port/service should be stopped.

© Copyright IBM Corp. 2016 2-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Workstation Operating System

Security Guidelines IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Here are the guidelines for workstation operating security system

– Installation & Configuration
– OS and Application S/W Hardening

© Copyright IBM Corporation 2016

Figure 2-13. Workstation Operating SystemSecurity Guidelines

Workstation Operating System Security Guidelines

The word "workstation" is used in this module to mean the combination of the hardware, operating system,
application software, and network connection.
Workstations must be configured and used in a secure manner. To secure a workstation, a staged approach
is recommended for implementation of security practices in the following areas:
• Planning and executing the deployment of workstation.
• Configuring workstation to help make them less vulnerable to attack.
• Maintaining the integrity of deployed workstation.
• Improving user awareness of security issues.
Installation and Configuration
OS and Application S/W Hardening
• OS media should be procured only from an authorised vendor of the manufacturer.
• To patch up the vulnerabilities and loopholes of the OS, install all the latest service packs, security
patches, hot-fixes, OS updates, etc. as available and applicable for this version at the time of installation.
These patches/updates etc. are available from the vendors as well as from their websites.
• Boot on “OS banner” should be disabled, if possible.
• Initially, all the ports should be closed/disabled and may be enabled/opened as and when required.

© Copyright IBM Corp. 2016 2-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
• Turn off all network services that are not needed.
• Define how long the computer or application can be used. Create a mandatory automated logoff policy
based on inactivity or time of day.
• Disable application features that expose vulnerability through configuration changes.
• Control access to settings, control panels and run functions. Define who has access to applications by
location, time of day or time period.

© Copyright IBM Corp. 2016 2-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Mobile Operating Systems IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Explaining the various mobile Operating systems

– Android Mobile OS
– Apple Mobile OS
– Java ME
– Symbian
– Windows Phone

Operating System Common Structure

© Copyright IBM Corporation 2016

Figure 2-14. Mobile Operating Systems

Mobile OS Security and Threats

The internet, used by ourselves in all areas of our daily lives, has shown a great improvement in recent years.
Accordingly, the devices to connect this virtual environment have undergone a great change and the use of
mobile devices has quite increased. Almost all communication and processes can be carried out through the
mobile tools (documents, social network, online shopping etc.) facilitating the daily life. The increase in this
number, however, brings along some security problems.
The unknown Wi-Fi settings, accepting all unidentified applications, connecting to untrusted sites and
downloading applications from such sites can be listed as the major ones of these problems. It is of great
importance that certain safety precautions should be taken for the mobile tools in which private information
and documents of the users are stored. This study examines the operating systems of the most-preferred
mobile tools and the threats towards these operating systems and provides detailed information about them.
Mobile Operating Systems Versus Computer Operating Systems
Operating systems (OS) are the software-based interfaces necessary for users to manage, use and operate
the hardware units. If the hardware to be managed is portable device such as Smart Phone, Tablet PC, PDA
etc., the operating systems of such devices developed to enable these devices to run

as a personal computer are also called Mobile Operating System (Mobile OS). The number of mobile devices
is increasing day by day thanks to their portability, ease of use and the increase in their features with the
advancing technology. With this increase, great development and changes have occurred in the operating
system preparing the ground for meeting the demands of users.

© Copyright IBM Corp. 2016 2-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
Android Mobile OS
As an open-source code operating system, Android is a Linux-based mobile OS and is developed by Google.
Android uses Linux version 2.6 for the core system services such as security, memory management, process
management, network stack and driver model. In addition, it serves as abstraction layer between the core,
hardware and software stack created using the C programming language and other layers. Abstraction layer
includes timing and libraries. The timing contains the core libraries providing functionality in the basic libraries
created using the Java programming language. These libraries work according to their functions in a virtual
machine (Dalvik Virtual Machine) for each Android application. It offers a wide, rich and innovative
opportunity to the developers for top-level applications used by various components of the Android system
such as Libraries, Media Libraries and 3D libraries. Moreover, Android offers a wide variety of free and
available features such as device hardware, access location information, constantly running background
services, timing warning systems and adding notifications to the status bar. All applications are written using
the Java programming language.
Apple Mobile OS
First developed in 2007 by Steve Jobs, the founder of Apple, iOS is a mobile operating system used only in
Apple-branded products (iPhone, iPod, iPad) for now. In analogy with the other operating systems, iOS
architecture is built on four platforms integrated with each other. The first platform, Cocoa Touch, provides the
basic infrastructure used by the applications. For example; it constitutes the layer written using C language
providing an object-oriented support for file management, network operations and more. This layer includes
Map Kit, iAD, Game Kit, Events (Touch), View Controllers and UIKit. The Media Layer constitutes the section
that enables using Audio, Animation video and Image formats (JPEG, PNG, TIFF) and documents. Core
Services (Core OS) the third layer-, Core operating system and the core service layers contain iPhone
OSspecific basic interfaces for low-level data types, startup services, network connection and accesses.
These interfaces are usually C-based and core-centered and they offer technologies involving SQLite and
POSIX threads as well as access to UNIX sockets. The Media Layer which constitutes the last layer of Apple
iOS, however, contains the basic technologies used for 2D and 3D drawings and audio and video support.
This layer contains C-based technologies such as OpenGL ES, Quarts and Core Audio. In addition, there is
an Objective-C based animation engine and a core Animation application in this layer.
In addition to all these features, Apple Cloud Computing allows direct installation of all information and
documents thanks to its iCloud system allowing data storage and in the context of mobile application
development, Apple's iCloud system (2013 Apple Inc.) explores the limitations that may occur.
Java ME
Java Platform Micro Edition (JavaME or formerly J2ME) operating system was designed by Sun
Microsystems for mobile and embedded devices (Blu-RayDisc Players, Printers, etc.) and its usage areas
has significantly increased thanks to its flexible structure. It consists of seven layers including Java ME
system "Application Layer", "Configuration Layer" which contains very specific APIs and has java language
virtual machine features and minimum class libraries, "Profile Layer" which supports high-level services and
is built on the configuration layer, -Optional Packages Layer which involves functions or specific applications
independent from Profile or Configuration (i.e., Java APIs for Bluetooth, Location APIs for J2me, J2ME Web
Services), Vendor specific classes, Native Operating System and Hardware. In addition to its flexible user
interfaces, its rich and robust security in terms of functionality and its support for network and offline
applications, Java ME is also designed in a way to be used on many portable devices and to improve the
performance of the device used.
Symbian
Symbian is a mobile operating system using open source code. Symbian which is an open source software
written using the C++ programming language, was first developed in 1977. It had become very popular until
the end of 2010. After this date, its place was largely taken by Android. Symbian is composed of layers such
as OS Libraries, application Engines, KVM, Servers, symbian OS Base-Kernel and Hardware. Being used for
many portable devices from the date it was developed until 2010, Symbian is also known as a software with
an outstanding security among the mobile OSs.
Windows Phone

© Copyright IBM Corp. 2016 2-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
It is an operating system developed by Microsoft for smart devices. This 32-bit Windows CE 5.0-based
mobile operating system which was first developed for PDAs is now used by the Smart Phones and touch
devices. In 2003, it was named as Windows Mobile. Windows Mobile experienced a drop against its rivals by
the end of 2010 and Microsoft has gradually renovated this operating system by a decision taken and put it
on the market as Windows Phone.

As it started using the .Net Compact Framework structure, Windows Phone has had many features and
advantages. For example, its coding language is able to integrate the written applications into mobile devices
thanks to its independent compilation structure (Common Language Runtime-CLR). Windows Phone is
moving towards becoming a promising operating system thanks to the special libraries, enhanced device
protection and software security features of .Net Framework oriented for developing mobile applications.

© Copyright IBM Corp. 2016 2-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Threats of Mobile Operating Systems IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Some major threats & vulnerabilities of mobile OS

– Malware
• Trojans
• Virus
• Worm
• Spyware
– Vulnerabilities
• Device-Hardware Vulnerabilities
• Software Vulnerabilities

© Copyright IBM Corporation 2016

Figure 2-15. Threats of Mobile Operating Systems

Threats of Mobile Operating Systems

As most of the devices have an internet connection, there are also a wide variety of threats to the smart
devices using mobile operating system. In line with the portable devices, the malicious software industry is
also growing both in technological and structural terms. These threats are discussed in three main categories
including Malware, Vulnerabilities and Attacks.
Malware
Malicious Software (Malware) are, in its simplest expression, the malicious software aimed at private specific
information which disturb users, may cause breakdown of the device and lead to results such as causing
information and documents belonging to the user to be stolen or become unusable. These illegal software
which are not installed by the user are used for all attacks from the outside taking advantage of the
vulnerabilities in the device or system. The major ones of these software are Trojans, Worms, Virus and
Spyware. The first known malware is Cabir which was created for the Symbian operating system in 2004.
Cabir is a malicious software which infected the Nokia 60 series and affected many smartphones. This worm
writes the word "Cabire" on the screen of the phone infected and uses Bluetooth connection to spread itself.
Apple is more protected against OS malware software thanks to its closed system. The OS which becomes
the target of Malware attacks most is Android OS. The biggest reason for this is that the applications can be
obtained from many secure-insecure sources.
Trojans: The main purpose of Trojan software is not to spread themselves but to seize the device
management and information. With this aspect, they differ from the worms and viruses. The most widely used
spyware are, in this respect, the keyloggers. The purpose of these software transmitted under the cover of
another file and unintendedly activated by the user is to get the device entirely under control in the

© Copyright IBM Corp. 2016 2-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
background. These malware are generally carried inside a more innocent software and not noticed by the
user. For this reason, while downloading an application necessary for the smart devices, it is of utmost
importance to use checked and reliable software. However, this is a little harder for the Android devices.
Because, those who use such devices are also able to download applications from elsewhere other than the
Google App Store. And even, since they can recognize the external units such as USB or SDcard, the
Trojans can also get into the devices through such devices and create a vulnerability in the system. This is a
bit more difficult for iOS compared to the Android devices. Because Apple Store constitutes the only option to
download application.
Virus: These are the malicious software which have some features such as penetrating into the existing
documents and sending them elsewhere, distorting their contents and making them unusable and slowing
down the hardware elements. For the spread of viruses, infected programs should also be installed in other
devices. In other words, the infected program must also be sent to other devices by the user. For example; in
2010, the "Zombie" virus infected more than 1 million smartphones in China and caused a loss amounting to
$300,000 per day. Besides its numerous damages, it also leads to data loss, data leakage and even
disruption of the conversation.
Worm: Worms which are counted among the malware contain harmful and misleading instructions. The
worms affecting mobile devices do not require user interaction in order to be effective and are usually
transmitted through the text messages (SMS) or picture messages (MMS). Worm is actually a kind of virus.
However, it does not require user interaction to reproduce itself. For example, clicking on a file or opening a
plug-in sent by e-mail activates the worm. A security vulnerability in the operating system would be sufficient
for Worm infection. The Worm penetrates using this vulnerability and integrates itself into a service running in
the operating system. After this stage; it can act as a spy inside the device, send the required information to
the center managing itself, cause clogging and slowing down in the Internet bandwidth through creating an
unnecessary data flow and degrade the performance of the device.
Spyware: Spyware software are used to collect information on a specific subject. Though specifying that they
are used for advertising and promotional purposes (adware) or to provide better service to users (cookies),
these software collect information about a person or organization and send that information to someone else
without their consent. In this sense, it works like a Trojan and can be used by malicious people. It is also a
software aimed at taking control of the devices infected. In the studies performed by security firms, it is seen
that malware software are not only used by hackers but also created by the profit-oriented "teams" making
cooperation in this regard. For example; in an incident in 2013, the Trojan 'botnet
TrojanSMS.AndroidOS.Opfake.a' enabled the spread of the malware software 'Backdoor.AndroidOS.Obad.a'
through sending a spam containing the malware to its victim list. Trojan software are seen at the highest level
among the malware software with a high rate of 64 %.
Vulnerabilities
The weaknesses occurring in the system security procedures, internal controls, design and applications are
among the security vulnerabilities in the device. These vulnerabilities can be grouped under several
headings. In the present study, the analyze is carried out in two main categories including device-hardware
vulnerabilities and mobile operating system and application (software) vulnerabilities.
Device-Hardware Vulnerabilities
The most-encountered problem which should be considered first in this regard is the agedness of the device.
Because, the manufacturers do not support the devices manufactured before a certain date. Therefore, the
device may not receive security updates.
The second issue, however, is the inability of the mobile devices in assuring the safety of the ports they use
while connecting to a network or the Internet. The fact that the mobile devices have generally no "navigation"
limit used in the Internet environment and there is no firewall to control this is an important vulnerability. A
hacker can easily access to the mobile devices via this unsecure port. In such cases, the software called
"firewall" which protect these ports must be used. Thus, the user will be asked for a permission while
connecting to the mobile device and will be able to see it. There may be unauthorized changes ("jailbreaking"
or " rooting") on the mobile devices which are not using a firewall. Jailbreaking which provides an escape for
Apple iOS is the method applied to obtain an application that does not belong to Apple (iTunes, App store.) or
cannot be downloaded due to some restrictions from any other source. This method allows to have access to
the operating system of the mobile device and this constitutes a vulnerability. In addition, the "jailbroken"

© Copyright IBM Corp. 2016 2-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
devices may not receive security updates of the manufacturer and the devices without the necessary updates
may become vulnerable to threats.
Software Vulnerabilities
The out-datedness of the mobile operating system is also an important vulnerability. Yet, the best known of
the security vulnerabilities arising from software is the use of an old Mobile OS and out-datedness. For
example, an Android supports application installation from Google Play or another file system. Since Google
file system is a protected area, the downloads or packages (APKs) from this area are secure. However,
downloading APK files from third-party application stores, mobile ad libraries and local storage units (i.e.,
sdcard) is often unprotected. Such vulnerabilities are tried to be met by the firms through new versions or
patches.
The shared open source common components also constitute an important vulnerability. Another vulnerability
occurring in all open source software is in the design of the system containing common open source
components such as WebKit and Linux kernel. These components have a reusable structure in order to
reduce the costs and this is a common practice in large open source systems such as Android. A vulnerability
has been discovered in WebKit or Linux, however, a patch was released in order to use in solving this
problem. Apple's iPhone-like WebKit and BSD kernel derivative (Darwin) constitutes the common software
components. The problem at this point is not its re-use but where it is employed. In this regard, Android has
put the patch model into practice with a little delay.
The vulnerabilities occurring during the installation of APK files are very common. The presence of a
vulnerability known as "Check Time" of the package installer has also been identified. This means that it is
replaced by an open APK file or can be changed during installation without the user's knowledge. This open
package constitutes the vulnerability of the installer and affects APK files downloaded from unprotected local
storage units.

© Copyright IBM Corp. 2016 2-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Threats of Mobile Operating Systems IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Some major attacks of mobile OS

– Hardware-based attacks
– Device-independent attacks
– Software-based attacks
– User-based attacks

© Copyright IBM Corporation 2016

Figure 2-16. Threats of Mobile Operating Systems

Attacks
Attacks are the interferences made from outside using a variety of vulnerabilities. These interferences are all
considered as an attack regardless of whether they are made through malware software or they use
vulnerabilities in the smart device or mobile operating system. However, the terms "attack" is generally
defined as the attacks made by the hackers for obtaining users' private information without their knowledge.
The first real attack against smartphones was first made by two researchers called Vincenzo Iozzo and Ralf
Philipp Weinmann in March of 2010 in order to steal a database from a phone via SMS. This attack was
made by looking at an error in the Safari Browser of iPhone 3GS phones and it was aimed to upload the file
sent by SMS to the server.
In November 2010, however, an attack was directed to the browser in the Android operating system using a
common vulnerability. More recently, the first ―over-theair attack for GSM software which will lead to
memory corruption has been introduced again by Weinmann. Moreover, Oberheide and Lanier has identified
several different attack vectors for the iTunes App Store.
There are various classifications in terms of attacks. One of them is the classification made by Becher which
groups the attacks towards mobile devices in four main categories i.e. Hardware-based, device-independent,
software-based, and user-based attacks.
• Hardware-based attacks: With a broad perspective, hardware-based attacks constitute an element of
mobile security. Even if the Mobile Device has any vulnerability, it cannot easily reach to the user
information, however, there is an access to the device.

© Copyright IBM Corp. 2016 2-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
• Device-independent attacks: These are the attacks independent from the device which directly target
the mobile device user. They intend to violate the privacy of the user's personal data through wireless
connection or wiretapping.
• Software-based attacks: An important part of the technical vulnerabilities on mobile devices are the
software-based attacks. Especially the increase in the number of mobile web browser has led to an
increase in the vulnerabilities used in this field.
• User-based attacks: Such attacks are not technical attacks. These constitute the attacks made through
cheating without using malicious software which are direct to the mobile device users.
These attacks made through "social engineering" and aimed at reaching to private information are today
quite common. A large number of the attacks are not technical-based. For example; the Denial of Service
(DoS) attacks are not directed through applications or malware installed in smartphones but using the
vulnerabilities created by the malformed text messages. In addition to these attack vectors, there are also
other types of attacks. However, the aim of all attacks are essentially to find the victim's vulnerabilities and to
make attack using a well-intended process and application.
• JTAG (Joint Test Action Group) Attacks: JTAG is the best-known hardware and debug standard. Even
though it provides a high control and observability, it also creates vulnerabilities because of allowing for
the control of the device at a deep level.
• Forensic Analysis: This is an attack vector targeting the privacy of the data stored on the mobile
devices. This vector applies to the cases where the attacker has physical access to the device. The
attacker takes the device of the user who do not realize this situation under his/her control for a certain
time. In such a case, the attacker can reach to the information stored in the device. The second
possibility is, however, to obtain the confidential corporate data and personal conversations and today,
some studies show that this is the most commonly used method.
• Phishing Attacks: This is a kind of attack formed by combining the words "Password" and "Fishing".
Phishing in the mobile applications is a threat related to the successful attacks reported. This is an
OS-independent method and can be used for all types of devices. Such attacks are made through
directing the user to the imitation websites instead of the legitimate ones in order to steal their private
information such as credentials, credit card information, user name or password. There are some
varieties of this attack such as Similarity attack, Forwarding attack, Background attack and Notification
attack.
• QR Code Based Attacks: This is an application which has become very popular recently thanks to its
large storage capacity due to the QR (Quick Response) code, ease of production and distribution and the
fast readability features. However, users usually are not able to understand the type of knowledge
contained in it while scanning QR codes content of which are easily encoded. And this provides a
suitable environment to direct users to malicious URLs. Google Safe Browsing API and Phishtank API
increases the speed in detecting phishing and malware attacks as well as malicious URLs (SafeQR).
• SSL Proxy Attacks: Secure Sockets Layer (SSL)/Transport Layer Security (TLS) encryption used in
many applications today (especially in internet banking) is a protocol that generally reassures users and
provides data security. SSL is an encryption scheme and provides adequate security when implemented
correctly. Otherwise, applications may be encountered with security threats and unintended
vulnerabilities occurs. If this code is left un-reviewed, the settings can be changed in an undesired
manner and the information which were presumed to be safe and transmitted can be stolen through
communication path.

© Copyright IBM Corp. 2016 2-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Lab: Tripwire SecureCheq IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Tool Introduction
– Tripwire SecureCheq™ tests and remediates Microsoft Windows desktop or server configurations. It
particularly
– Tests for typical and often dangerous Windows configuration errors
– Provides detailed remediation and repair advice
– Tests for configuration errors related to OS hardening, data protection, user account activity and audit
logging
– Demonstrates how systems can be continually hardened against attack
• Some features that make it a viable choice for business users include the following:
– Installs in minutes using a set up and configuration wizard
– Comprehensive scan results and audit-ready reports in less than an hour
– Comprehensive policy library that makes it easy to check for compliance
– On premise deployment gives you complete control
• System Requirements:
– Hardware
– Software

© Copyright IBM Corporation 2016

Figure 2-17. Lab: Tripwire SecureCheq

Lab Specifications
System Requirements
Hardware
4 GB System Memory
50 GB free hard disk drive space
3.0 GHz processer Core 2 Due
Local Network connectivity
Internet Access Connectivity is necessary for the Installer Media
Either a DVD Drive or USB port for the installer media
Software
Operating System: Windows 7

© Copyright IBM Corp. 2016 2-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step -1) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Download Tripwire_SecureCheq_WS_2003_110 file.

Figure: Download screen

© Copyright IBM Corporation 2016

Figure 2-18. Installation (Step -1)

Download Tripwire_SecureCheq_WS_2003_110 file.

(Link: http://www.tripwire.com/free-tools/securecheq/)

© Copyright IBM Corp. 2016 2-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Double click on .msi file of Tripwire SecureCheq to begin the installation. Click on “Yes” to
run the Tripwire SecureCheq setup

© Copyright IBM Corporation 2016

Figure 2-19. Installation (Step - 2)

© Copyright IBM Corp. 2016 2-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 3) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Click on “Next” to proceed the installation

© Copyright IBM Corporation 2016

Figure 2-20. Installation (Step - 3)

© Copyright IBM Corp. 2016 2-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 4) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Read the Licence Agreement and select “I Agree”. Then click on “Next”.

© Copyright IBM Corporation 2016

Figure 2-21. Installation (Step - 4)

© Copyright IBM Corp. 2016 2-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 5) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Choose installation folder. Then click on “Next”.

© Copyright IBM Corporation 2016

Figure 2-22. Installation (Step - 5)

© Copyright IBM Corp. 2016 2-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 6) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Click on “Next” to confirm installation

© Copyright IBM Corporation 2016

Figure 2-23. Installation (Step - 6)

© Copyright IBM Corp. 2016 2-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 7) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• The progress bar will be display installation progress

© Copyright IBM Corporation 2016

Figure 2-24. Installation (Step - 7)

© Copyright IBM Corp. 2016 2-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Installation (Step - 8) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Now click on “Close” to complete the installation

© Copyright IBM Corporation 2016

Figure 2-25. Installation (Step - 8)

© Copyright IBM Corp. 2016 2-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Starting the Scan (Step - 1) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Now the Tripwire SecureCheq will start and will ask to scan the system. Click on “Scan” to
beginning scanning the system

© Copyright IBM Corporation 2016

Figure 2-26. Starting the Scan (Step - 1)

© Copyright IBM Corp. 2016 2-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Starting the Scan (Step - 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• SecureCheq will now start scanning

© Copyright IBM Corporation 2016

Figure 2-27. Starting the Scan (Step - 2)

© Copyright IBM Corp. 2016 2-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Starting the Scan (Step - 3) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• After the scan is complete, the results can be viewed by clicking on “View Results”

© Copyright IBM Corporation 2016

Figure 2-28. Starting the Scan (Step - 3)

© Copyright IBM Corp. 2016 2-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Starting the Scan (Step - 4) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Scan results will be displayed as “SecureCheq Summary Report”.

© Copyright IBM Corporation 2016

Figure 2-29. Starting the Scan (Step - 4)

© Copyright IBM Corp. 2016 2-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

About the tool window IBM ICE (Innovation Centre for Education)
IBM Power Systems

© Copyright IBM Corporation 2016

Figure 2-30. About the tool window

The pane on the top of the window shows following three panes and the statistics of the scan results.
Security Scan
View
Reports

© Copyright IBM Corp. 2016 2-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

About the tool window IBM ICE (Innovation Centre for Education)
IBM Power Systems

© Copyright IBM Corporation 2016

Figure 2-31. About the tool window

© Copyright IBM Corp. 2016 2-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Summary Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

© Copyright IBM Corporation 2016

Figure 2-32. SecureCheq Summary Report

© Copyright IBM Corp. 2016 2-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

System aspects covered in scan IBM ICE (Innovation Centre for Education)
IBM Power Systems

• OS Hardening

© Copyright IBM Corporation 2016

Figure 2-33. System aspects covered in scan

© Copyright IBM Corp. 2016 2-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

System aspects covered in scan IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Data Protection

© Copyright IBM Corporation 2016

Figure 2-34. System aspects covered in scan

© Copyright IBM Corp. 2016 2-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

System aspects covered in scan IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Communication Security

© Copyright IBM Corporation 2016

Figure 2-35. System aspects covered in scan

© Copyright IBM Corp. 2016 2-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

System aspects covered in scan IBM ICE (Innovation Centre for Education)
IBM Power Systems

• User Account Security

© Copyright IBM Corporation 2016

Figure 2-36. System aspects covered in scan

© Copyright IBM Corp. 2016 2-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

System aspects covered in scan IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Log and Auditing

© Copyright IBM Corporation 2016

Figure 2-37. System aspects covered in scan

© Copyright IBM Corp. 2016 2-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Tests Conducted

© Copyright IBM Corporation 2016

Figure 2-38. SecureCheq Test Report

SecureCheq Test Report

Tests Conducted
Following tests are conducted during the scan of the server:
1. Windows Remote Desktop Configured to Only Allow System Administrators Access
2. Windows Remote Desktop Configured to Always Prompt for Password
3. Safe DLL Search Mode is Enabled
4. Anonymous Access to Windows Shares and Named Pipes is Disallowed
5. All Shares are Configured to Prevent Anonymous Access
6. Windows Default Guest Account is Disabled
7. Force Encrypted Windows Network Passwords
8. Strong Windows NTLMv2 Authentication Enabled; Weak LM Disabled
9. Strong Encryption for Windows Remote Desktop Required
10. Enable Strong Encryption for Windows Network Sessions on Clients
11. Enable Strong Encryption for Windows Network Sessions on Servers

© Copyright IBM Corp. 2016 2-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty
12. Windows Password Complexity is Enabled
13. Minimum Windows Password Length Configured to be at Least 8 Characters
14. Windows Account Lockout Counter Configured to Wait at Least 15 Minutes Before Reset
15. Windows Account Lockout Duration Configured to at Least 15 Minutes
16. System Event Log is Configured to a Sufficient Size
17. Logging of Executed Applications is Enabled
18. Logging of Credential Validation is Enabled
19. Logging for Successful and Failed Logon Attempts for Domain Accounts is Enabled
20. Logging for Successful and Failed Logon Attempts for Local Accounts is Enabled
21. Logging of Successful System Change Events is Enabled
22. Security Event Log is Configured to a Sufficient Size

© Copyright IBM Corp. 2016 2-65

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

© Copyright IBM Corporation 2016

Figure 2-39. SecureCheq Test Report

SecureCheq Test Report

These tests are displayed altogether in the “Results” tab of the pane on the right side of SecureCheq
Summary Report window.
Status of each test is shown against it (Passed/Failed)

© Copyright IBM Corp. 2016 2-66

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Windows Remote Desktop Configured to Only Allow System Administrators Access

© Copyright IBM Corporation 2016

Figure 2-40. SecureCheq Test Report

SecureCheq Test Report

Details about the test and the remediation techniques (in case the results is “FAILED”) can be found by
clicking on the test. Remediation steps can be followed to attend to the security issues.
The images show how the details about the test conducted, the result of the test (Passed/Failed), the
remediation techniques and references from internet for further study on the test and the issues are
displayed.

© Copyright IBM Corp. 2016 2-67

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Windows Remote Desktop Configured to Only Allow System Administrators Access

© Copyright IBM Corporation 2016

Figure 2-41. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-68

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Windows Remote Desktop Configured to Only Allow System Administrators Access

© Copyright IBM Corporation 2016

Figure 2-42. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-69

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Windows Remote Desktop Configured to Always Prompt for Password

© Copyright IBM Corporation 2016

Figure 2-43. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-70

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Windows Remote Desktop Configured to Always Prompt for Password

© Copyright IBM Corporation 2016

Figure 2-44. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-71

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Windows Remote Desktop Configured to Always Prompt for Password

© Copyright IBM Corporation 2016

Figure 2-45. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-72

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Safe DLL Search Mode is Enabled

© Copyright IBM Corporation 2016

Figure 2-46. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-73

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Safe DLL Search Mode is Enabled

© Copyright IBM Corporation 2016

Figure 2-47. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-74

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Safe DLL Search Mode is Enabled

© Copyright IBM Corporation 2016

Figure 2-48. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-75

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Anonymous Access to Windows Shares and Named Pipes is Disallowed

© Copyright IBM Corporation 2016

Figure 2-49. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-76

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Anonymous Access to Windows Shares and Named Pipes is Disallowed

© Copyright IBM Corporation 2016

Figure 2-50. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-77

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

SecureCheq Test Report IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Anonymous Access to Windows Shares and Named Pipes is Disallowed

© Copyright IBM Corporation 2016

Figure 2-51. SecureCheq Test Report

© Copyright IBM Corp. 2016 2-78

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
1. How is UNIX protection system a discretionary access control system
A. It checks whether the process identity’s UID corresponds to the owner UID of the le being
accessed
B. owner UID, or group GID may be changed by any UNIX processes run by the le’s owner, that
have the same UID as the le owner
C. owner UID is never allowed to be changed
D. none of the above
2. What security mechanism is followed by Microsoft Windows’ Applocker?
A. Grant access to file based upon the attributes of file and identity of user
B. Mark application data as non-executable
C. Decrypt all the application and user data
D. Use a tamper-proof hardware chip (Trusted Platform Module) which stores encryption key
material
3. Which of the following is true about Network Access Protection?
A. It is assured that the operating system is not compromised before it gets access to a corporate
network
B. Limit the number of external connections to allow successful connections to be made only to
trusted resources
C. Limit access to objects in its operating systems
D. All of the above

© Copyright IBM Corporation 2016

Figure 2-52. Checkpoint

© Copyright IBM Corp. 2016 2-79

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
4. How do modern operating systems judge the code to be executed?
A. By matching the fingerprint or “hash” of the application to be executed with the cryptographically
signed hash
B. Virtualize whole operating system and run on a hypervisor
C. Code is marked executable or non-executable
D. Use a Trusted Platform Module
5. What happens in Time-of-Check-to-Time-of-Use (TOCTTOU) attacks?
A. The state of the system between the time an operation is authorized and the time that the
operation is performed is changed
B. The identity of the user (attacker? between the time an operation is authorized and the time that
the operation is performed is changed
C. The code being executed between the time an operation is authorized and the time that the
operation is performed is changed
D. None of the above
6. What purpose do Service Packs serve in securing server operating system?
A. They are installed and used in managing patches to fix security vulnerabilities that are well known
to intruders
B. Ensure that only required network services should be installed in the server
C. They are not a security solution but a threat
D. Both A and B

© Copyright IBM Corporation 2016

Figure 2-53. Checkpoint

© Copyright IBM Corp. 2016 2-80

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
7. Which one of the following is not true for hardening operating systems?
A. Boot on “OS banner” should be enabled
B. OS media should be procured only from an authorised vendor of the manufacturer
C. Turn off all network services that are not needed
D. All of the above are true
8. Which layer in Apple iOS Layer constitutes the section that enables using Audio, Animation video and
Image formats (JPEG, PNG, TIFF) and documents?
A. Media Layer
B. A layer in Cocoa Touch platform
C. Core Services layer
D. Both A and B
9. Which Mobile OS threat can penetrate the existing documents and send them elsewhere?
A. Trojan
B. Worm
C. Virus
D. Spyware

© Copyright IBM Corporation 2016

Figure 2-54. Checkpoint

© Copyright IBM Corp. 2016 2-81

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
10. How are Denial of Service attacks directed in mobile devices?
A. Through applications or malware installed in smartphones
B. Using the vulnerabilities created by the malformed text messages. In addition to these attack
vectors
C. Directing the user to the imitation websites instead of the legitimate ones in order to steal their
private information
D. Both A and C

© Copyright IBM Corporation 2016

Figure 2-55. Checkpoint

© Copyright IBM Corp. 2016 2-82

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 2. Operating System Security

Uempty

Unit summary IBM ICE (Innovation Centre for Education)

IBM Power Systems

Having completed this unit, you should be able to:

• Get to know the threats that are faced by operating systems and how they are evolving
• Understand key security features of operating systems
• Get an insight on the security guidelines for server and workstation operating systems
• Get familiar with threats in various mobile operating systems

© Copyright IBM Corporation 2016

Figure 2-56. Unit summary

© Copyright IBM Corp. 2016 2-83

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Unit 3. Endpoint Security

Overview
This unit provides knowledge about need of endpoint solutions and what solutions are deployed

How you will check your progress

• Checkpoint

© Copyright IBM Corp. 2016 3-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Unit objectives IBM ICE (Innovation Centre for Education)

IBM Power Systems

After completing this unit, you should be able to:

• Know what are the threats that drive the need of endpoint security solutions
• Get familiar with the components with endpoint security
• Understand the challenges faced by endpoint security
• Relate the deployment of endpoint security solutions with practical scenarios

© Copyright IBM Corporation 2016

Figure 3-1. Unit objectives

© Copyright IBM Corp. 2016 3-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

What is Endpoint Security? IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Introduction of Endpoint security

– Critical Components of Endpoint Security
– Endpoint security perspectives: Consumer versus corporate

© Copyright IBM Corporation 2016

Figure 3-2. What is Endpoint Security?

What is Endpoint Security?

Security is top of mind for today’s CIO/CISO and endpoints are the new target. Criminals are targeting
employees and using their devices to gain access to networks. Compromise is inevitable but a breach can be
prevented. Anti-virus solutions are important but they no longer offer complete protection to the organization.
The terms Endpoint Security or Endpoint Protection are generally used to refer to corporate products that
include a range of security features. These typically include:
• Malware removal based on existing signature files and heuristic algorithms
• Built-in antispyware protection
• Ingress/Egress firewall
• IPS/IDS sensors and warning systems
• Application control and user management
• Data input/output control, including portable devices
Consumer products with similar features are generally referred to as Internet security suites. Endpoint
security is used in contrast to network security products, which corporate IT managers are also responsible
for.
Endpoints can be desktop PCs, laptops, mobile phones, or servers in a datacenter. Additional functionality is
starting to appear in endpoint security products, such as:
• Full Disk Encryption

© Copyright IBM Corp. 2016 3-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Data Leak Prevention
• Application White listing
What differentiates endpoint security from the well-known anti-virus software is that within the endpoint
security framework, endpoints bear some or all responsibility for their own security. This is in contrast to
network security, in which security measures encompass the network as a whole rather than individual
devices and servers.
Endpoint security products may contain features and functionality such as:
• Data loss prevention
• Insider threat protection
• Disk, endpoint, and email encryption
• Application whitelisting or control
• Network access control
• Data classification
• Endpoint detection and response
• Privileged user control
Endpoint security isn’t solely conducted from devices, however. Typical endpoint security solutions provide a
two-pronged approach, with security software installed on a central server or management console along
with software installed on individual devices.
Still, some simpler forms of security fall under the endpoint security umbrella by some definitions. For
instance, anti-virus software and personal firewalls could be described as simple forms of endpoint security.
That said, modern endpoint security definitions generally describe more advanced methodologies,
encompassing intrusion detection and behavior-blocking elements that identify and block threatening actions
and behaviors, either by end users or intruders.
Critical Components of Endpoint Security
Two key components of an effective endpoint security solution, endpoint encryption and application control
are essential layers of endpoint security that prevent issues such as data leaks occurring intentionally or
unintentionally through the copying or transfer of data to removable media devices. Endpoint encryption fully
encrypts your enterprise data on endpoints, including laptops, mobile devices, and other endpoints, as well as
in individual folders, files, and removable storage devices like CDs and USB drives.
Application control prevents the execution of unauthorized applications on endpoints, a core component of
comprehensive endpoint security measures. Application control solves the challenge of employees
downloading unauthorized or dangerous applications on mobile devices, which could create network
vulnerabilities and lead to unauthorized access.
Endpoint security perspectives: Consumer versus corporate
There is a difference between consumer and corporate editions. It amounts to how the application is
managed. Most home networks consist of only a few computers and managing them individually is typically
not a problem. Since there is no central administration:
• Signature and application updates are received from the developer's control servers via the Internet.
• Endpoint security apps are configured on each computer.
• Alert and log entries are only available on the affected computer.
Corporate software uses a centralized server application. It's the only way to logically manage more than a
few installations. Centralized administration allows:
• Single sign-on web interface for configuring endpoints.
• All log entries and alerts to be sent to one location, the controlling server.
• Downloading of signature and application updates once, then the server application pushes the files out
to all endpoints.

© Copyright IBM Corp. 2016 3-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Set up and enforcement of a network-wide usage policy
For consumers, there’s no centralized management and administration, signature and application updates
are received from the developer’s control servers, delivered over the Internet. The security applications are
configured on each individual computer or endpoint, and individual alert and log entries are available on
respective endpoints.
In the enterprise endpoint security model, centralized administration always exists. A single sign-on interface
streamlines the configuration of endpoint security software on individual endpoint devices, and log entries
and alerts are sent to the central administration server for evaluation and analysis. Signature and application
updates are downloaded once, and the central server pushes updates out to endpoints configured within the
network. This enables the setup and enforcement of a network-wide usage policy.

© Copyright IBM Corp. 2016 3-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Pillars of Endpoint Security IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Four Pillars of Endpoint Security

– Endpoint Hardening
– Endpoint Resiliency
– Network Prioritization
– Network Resiliency

© Copyright IBM Corporation 2016

Figure 3-3. Pillars of Endpoint Security

Pillars of Endpoint Security

The Four Pillars of Endpoint Security is a model for making IT security a strategic business asset. This is
important because the most competitive companies want their employees to be productive on their own
terms: whenever, wherever, and from whatever device. The best people - the ones you most want to hire and
retain - are exactly the ones that are attracted to flexibility, enablement, and rapid decision making.
The most competitive, high-velocity businesses are built on a strong foundation of information technology. IT
capabilities, such as providing low-friction access to data and rapid deployment of the latest line-of-business
applications, are necessary ingredients, but these capabilities don’t develop overnight. Instead, strategic IT
capabilities are created through systematic investment, continuous improvement, and recognizing the strong
link between IT and business enablement.
Likewise, strategic IT capabilities are built on a foundation of security. If sensitive data can’t be protected, one
of two things will happen. Either the data won’t be made available in the situations where employees are most
likely to need it (e.g. on the road, at a customer site, or in a critical meeting), or the data will be made
available and it will become compromised or exposed to an unauthorized party. Either way, the business
suffers.
The good news is that the tools are available to lay a strong foundation of IT security and to enable the
business. The Four Pillars of Endpoint Security provide an easy-to-use context for evaluating and prioritizing
the use of those tools.

© Copyright IBM Corp. 2016 3-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
The Four Tenets of Security:
Cloud computing has changed some things like scalability and the cost model for web application hosting.
But when it comes to security, the basics still apply. There are four tenets of security: identity, authentication,
access control, and authorization.
• Identity - how principals, such as users, are represented.
• Authentication - how identity is established. For example, a user in possession of a smartcard
provisioned with a trusted X.509 certificate, plus knowledge of the smartcard PIN, will use the card to
authenticate, thereby establishing his or her identity within the system.
• Access control - the ability of the system to selectively allow or deny principals to perform actions on
protected objects. Access control enforces authorization rules.
• Authorization - the process by which access control rules are expressed.
To better understand these four tenets, imagine this: Airbus and Boeing are collaborating on a new Joint
Strike Fighter (JSF). Rather than exchange huge engineering design documents between worldwide teams
every night, which is what projects of that scale used to entail, the teams collaborate by using a more modern
and manageable mix of:
• Centralized document repositories, such as SharePoint.
• Security token server, such as Microsoft Active Directory Federation Services (ADFS) or Shibboleth.
• Password-based and multi-factor authentication technologies, such as smartcard or one-time password
(OTP).
In the case of identity, within Airbus’ Active Directory (AD) domain, users are represented as security
identifiers (SIDs). But those SIDs may have no meaning in Boeing’s AD. So, identity might be represented by
user email address plus other metadata, such as project group membership. And in the case of authorization,
it may be necessary to define authorization rules granting auditing staff read-only access to documents on
cost expenditures and accounting staff read/write access to those documents.
To support complex, collaborative projects such as a design of a JSF, security software has become
increasingly complex. For example, the most sensitive data may only be accessible to users with specified
project group membership, with certain national citizenship, and from provably secure client hardware. But
how do you define an authorization language that allows such rules to be expressed by a typical system
administrator? The rules can get even more complex: suppose Airbus trusts identity data regarding JSF
weapon system group membership originating from Boeing, since Boeing is contributing to that system. But
claims regarding propulsion system group membership from Boeing must be ignored, since that subsystem
belongs to Airbus.
Looking at the current state of the art, the capability of expressing such rules exists in the form of
standardized technologies such as SAML and XACML. While some ramp-up is required, especially when it
comes to complex collaborations, sophisticated line-of-business application integration with those standards
is available.
The Four Pillars of Endpoint Security complement the four tenets discussed before. The basic premise of the
Four Pillars of Endpoint Security is to allow the network to perform even while under attack. But what is an
endpoint? In this model, an endpoint is any of the following (where the work is done): desktops, servers, and
mobile devices.
With these assets in mind, the Four Pillars of Endpoint Security include:
• Endpoint hardening - protect the endpoint from attack
• Endpoint resiliency - make the endpoint auto-healing
• Network prioritization - guard network bandwidth
• Network resiliency - make the network auto-healing

© Copyright IBM Corp. 2016 3-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Endpoint Hardening
The goal of the first pillar - endpoint hardening - is to ensure that network assets are using the latest
technologies to defend against threats. Typical threats include unsafe email attachments, worm-like viruses
that propagate over the network, and related threats to your web browsers.
One example of an attack counter-measure is the isolation, or sandboxing, of computer application
processes from potential malware by way of mandatory integrity levels enforced by the operating system.
This type of protection is applied to Google Chrome and Microsoft Windows. However, manageability can be
lacking - namely, the ability to centrally deploy and manage isolation settings for the entire host. To be useful,
this needs to be done in such a way that third-party applications work seamlessly (and are protected).
The following technologies can aid in endpoint hardening:
• Antivirus and anti-malware software
• Mandatory integrity levels
• Auditing of network resource access
Endpoint Resiliency
The goal of endpoint resiliency is to ensure that health information on devices and applications is
continuously gathered and monitored. That way failed devices or applications can be automatically repaired,
thus allowing operations to continue. The following technologies can make endpoints more resilient:
• Network access control (NAC), including products such as Cisco NAC and Microsoft Network Access
Protection
• Configuration baselining, including the use of government standards such as Security Content
Automation Protocol (SCAP)
• Patching
• Antivirus and anti-malware software
• Centralized policy and confirmation management, including products such as Microsoft System Center
and VMware vCenter
Network Prioritization
The goal of network prioritization is to ensure that the available infrastructure can always meet application
bandwidth needs. This consideration applies not only at well-known peak demand times, but also when there
are unexpected surges on network loads and distributed external and internal attacks.
Technologies that can manage application bandwidth include DiffServ and Quality of Service (QoS).
However, this pillar currently represents the biggest technology gap between what’s needed and what’s
commercially available. In the future, it would help to have solutions to integrate user identity, application
identity, and business priorities. Then network routers could automatically partition bandwidth based on that
information.
Network Resiliency
The goal of network resiliency is to allow for seamless asset failover. Techniques in this area ideally afford
reconfiguring the network in real-time as performance degrades. This pillar is similar to endpoint resiliency in
that the goal is to facilitate network self-healing in order to minimize the management burden.

© Copyright IBM Corp. 2016 3-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Endpoint Security in BYOD IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Four Pillars of Endpoint Security in Bring your own device (BYOD)

– Endpoint Hardening
– Endpoint Reliability
– Network Prioritization
– Network Resiliency

© Copyright IBM Corporation 2016

Figure 3-4. Endpoint Security in BYOD

Endpoint Security in BYOD

Bring your own device (BYOD) is the trend in enterprise IT to rely on users to supply their own computing
hardware in the form of smartphones, tablets, and, to a lesser extent, laptops. While there is an ostensible
cost savings to be had in capital expenditure, and businesses can realize productivity in making it as
convenient as possible for employees to always be connected, BYOD is mostly just a response to an external
reality: as smartphones become more capable, consumers use them for almost all computing tasks aside
from heavy content creation (e.g. programming, video editing). Plus, while checking work email can be a
primary task for a consumer smartphone, the latest generation of users communicate via SMS, Facebook,
and Twitter. All those communication needs are met using public, free apps.
In that context, providing knowledge workers with a separate, corporate managed, mobile computing device
is moot. Nobody needs it. But if your responsibilities include IT security management or compliance, then you
should already be squirming. There’s a balance to be struck, and it’s unlikely to be the same for any two
businesses. On one hand, the latest communication, collaboration, and information exchange modalities
must be supported. On the other hand, there is a fiduciary obligation to deploy security control systems that,
at minimum, help keep honest people honest when it comes to data storage and exchange.
Recent competition in the mobile sector has paid off for consumers: the latest devices from Apple, Google,
and Samsung are incredibly cutting-edge and incredibly usable. That impressive combination is in fact an
inspiration for us security folks. Heterogeneity is hard for the IT security manager, since disparate mobile
platforms expose different security controls. Yet, the raw power and extensibility present in these devices
means that the sky is the limit, both for the IT security manager in terms of developing and applying controls,

© Copyright IBM Corp. 2016 3-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
as well as for the business manager in terms of dreaming up new scenarios for increasing business capability
and velocity.
The Four Pillars of Endpoint Security as a guide to secure all those mobile devices for corporate data access.
Endpoint hardening - technologies like platform attestation allow server-side resources to extract
high-assurance security claims from mobile devices. This helps to keep sensitive data off malware and rootkit
infested devices and can also be used to enforce client attributes, such as the use of hardware-based disk
encryption. The latest generation of mobile devices supports a variety of high-integrity security features,
including TPMs, SIMs, and other hardened cryptographic and data protection features.
Endpoint reliability - the ability to make mobile devices self-healing is still a work-in-progress, but all the
major platforms have recognized the increased support cost, and negative user experience, that comes from
supporting a wide-open application ecosystem in which discerning good software from bad is impossible for
the layman. Curated app stores help endpoint reliability, although they don’t guarantee it. This is moving in
the right direction, but enterprises with sophisticated security needs must still necessarily distinguish between
managed (for example, an Active Directory domain joined laptop) and unmanaged (typical smartphone)
devices when it comes to granting information access. Enforcing patching and platform updates is key to
maintaining endpoint reliability; technologies exist to do this across all platforms.
Network prioritization - link encryption is a must-have. All web applications should enforce Transport Layer
Security (TLS); all clients support it. Bandwidth waste is on unencrypted or untrusted requests is avoided
Network reliability - many of the same proven security technologies and practices apply equally across
traditional enterprise computing assets: routers, servers, laptops, and desktops. They need to be utilized and
they’re constantly increasing in sophistication. This applies whether the assets are mobile, private cloud, or
public cloud.

© Copyright IBM Corp. 2016 3-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Endpoint Encryption IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Defining endpoint encryption and its difference modes

– Disk Encryption
– Removable Media Encryption

© Copyright IBM Corporation 2016

Figure 3-5. Endpoint Encryption

Endpoint Encryption
If a computer or a removable USB drive is being used, the chances are that there is sensitive data on these
devices. Whether it's a computer with sensitive corporate information, or a thumb drive with government
secrets, it should be ensured that there is no unauthorized access to that data should the device be lost or
stolen.
Endpoint encryption (which typically includes disk encryption and removable media encryption) protects this
data, rendering it unreadable to unauthorized users. Endpoint encryption describes the differences between
disk encryption and file encryption, details how disk encryption and removable media encryption work, and
addresses recovery mechanisms.
When it comes to encrypting data, there are various encryption strategies. Disk encryption protects a hard
drive in the event of theft or accidental loss by encrypting the entire disk including swap files, system files,
and hibernation files. If an encrypted disk is lost, stolen, or placed into another computer, the encrypted state
of the drive remains unchanged, ensuring only an authorized user can access its contents.
Some endpoint encryption solutions also include support to encrypt files stored on or copied to removable
media devices. As with disk encryption, removable media encryption helps prevent unauthorized access to
information on lost or stolen devices (in this case the devices are USB flash drives, external hard drives
(USB, FireWire, and eSATA), SD cards, and compact flash cards). In this way, organizations can benefit from
the productivity gains associated from collaboration using removable storage without putting data at risk.
Disk encryption typically uses one key to encrypt a hard disk, so all data is able to be decrypted when the
system runs. If someone has logged into their system and left the computer unattended, system is unlocked
and unauthorized users can access the system just as an authorized user could.

© Copyright IBM Corp. 2016 3-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Just as an alarm system protects an entire home and a safe provides additional security, disk encryption
protects the entire computer system, and file encryption provides an additional layer of security.
File encryption encrypts specific files so when a user successfully authenticates to an operating system, the
contents of the file remain encrypted. An application can protect individual files and folders, prompting the
user for a passphrase to permit access. File encryption requires user action while disk encryption
automatically encrypts everything you or the operating system creates.
Disk Encryption
During the startup process of an operating system, a boot sequence is executed. The boot system is the
initial set of operations that the computer performs when it is switched on. A boot loader (or a bootstrap
loader) is a short computer program that loads the main operating system for the computer. The boot loader
first looks at a boot record or partition table, which is the logical area “zero” (or starting point) of the disk drive.
Disk encryption modifies the boot sector. For example, a computer protected with Symantec™ Endpoint
Encryption presents a modified preboot environment for the user to authenticate to the computer.
This modified pre-boot screen prompts the user for authentication credentials in the form of a passphrase
(typically a longer password, often resembling a sentence). At this point, the computer may ask for additional
credentials such as a smart card, token, or other two-factor authentication. After the user enters valid
authentication credentials, the operating system continues to load as normal and the user can access the
computer.
Most disk encryption software operates in conjunction with the file system architecture. It filters I/O operations
for one or more file systems or file system volumes.
When a drive is encrypted for the first time, it converts unencrypted drive blocks into encrypted blocks one at
a time. Disk encryption allows users to continue working as normal during this initial encryption process by
varying the amount CPU power assigned to the initial encryption process.
When a user accesses a file, disk encryption decrypts the data in memory before it is presented for viewing.
If the user makes any changes to the file, the data is encrypted in memory and written back to the relevant
disk drive block just as it would be without encryption. Decrypted data is never available on the disk. The
encryption/decryption process happens at such a speed that it appears completely transparent to the user.
Removable Media Encryption
Removable media encryption software provides the ability to encrypt files on removable storage devices.
When a user copies files of a system onto a removable storage device, each file is encrypted to a password,
a shared key or a certificate. At the same time, utilities for Windows or Mac systems can be copied (if
permitted by policy) allowing authorized access to data without the endpoint client installed on a machine.
This file encryption can be governed by policy, user action, or Symantec DLP. In the case of Symantec DLP,
the Endpoint Prevent software monitors users’ machines and understands when a person is moving a
sensitive file off his computer. With the integration of Symantec DLP and Symantec Endpoint Encryption,
administrators can ensure files with sensitive information that are moving to removable media are encrypted
rather than blocked, allowing business processes to continue in a secure manner.
To access the information, when the user inserts a removable media device like a USB drive with encrypted
files into a computer system, the removable media encryption software will prompt for passphrase, and upon
successful authentication, the user can access the file.

© Copyright IBM Corp. 2016 3-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Driver influence endpoint security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the business drivers that influence the endpoint security

– Correct and reliable operation
– Service-level agreements
– IT asset value
– Protection of the business asset value or brand image
– Legal and regulatory compliance
– Contractual obligation
– Financial loss and liability
– Critical infrastructure
– Safety and survival

© Copyright IBM Corporation 2016

Figure 3-6. Driver influence endpoint security

Need of Endpoint Security: Business context

Drivers that influence endpoint security
Most projects are driven by both business and IT drivers, although business drivers are almost always the
initiating factor.
• Business drivers: Business drivers measure value, risk, and economic costs that influence their
approach to IT security. Value drivers determine the worth of the assets of the system to the business and
the worth of the business itself. Risk drivers involve compliance, corporate structure, corporate image,
and the risk tolerance of the company. Economic drivers determine the productivity impact, competitive
advantage, and system cost.
• IT drivers: IT drivers represent operational constraints in the general IT environment. For example, the
complexity of a system, including its environment, that is exposed to internal and external threats
presents risks that the organization must address.
Business drivers also represent issues and consequences of significance to the stakeholders of the managed
business system. This set of drivers might vary from industry to industry, from organization to organization in
the same industry, and even between different business applications in an organization.
IT drivers represent technical considerations that affect the trustworthiness of the IT environment and likely
the managed business systems. IT drivers are universal and must be considered within the context of the
business drivers in all efforts. The combination of business and IT drivers represents the key initiatives for
security management.
Business drivers that influence security

© Copyright IBM Corp. 2016 3-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Business drivers represent a relationship between the IT organization and the rest of the business. They refer
to business values that must be supported by the IT security infrastructure.
Correct and reliable operation
Correct and reliable operation is the degree to which the business must be accurate and consistent in its
operation. Correct operation means that the operations perform the appropriate response or function with no
errors. Reliable means that the same result occurs all the time. Any IT system must consistently provide
stakeholders with the expected results.
Security events and incidents might affect the correct and reliable operation of these business processes. It
might also affect the underlying IT infrastructure or upstream and downstream business processes. The
consequences of a defective service (incorrect or varying results over time) might be significant to the
consumer of the service, and therefore to the provider of the service.
Service-level agreements
This driver applies to circumstances where security threats and threat agents can affect the ability of an
organization to conduct business. Service-level agreements (SLAs) incorporate acceptable conditions of
operation within an organization. SLAs might vary from business system to business system or application to
application. Availability of systems, data, and processes is a condition commonly referenced within SLAs.
IT asset value
From the business perspective, the IT asset value directly relates to the value of the business transactions
that it supports. These assets might be tangible or intangible. For an e-retailer, these assets are tangible
assets. For a financial services
company, the asset might be the client information or other data used in transactions of the system.
Protection of the business asset value or brand image
This driver captures the desire of the firm to protect its image. The loss of goodwill from a security incident or
attack has a direct consequence to the business. Therefore, the security measures are likely to be
proportional to the consequence. When the desire to avoid negative publicity increases upon encountering a
security breach, the stipulation for this driver becomes stronger.
Legal and regulatory compliance
Legal and regulatory compliance refers to the externally imposed conditions on the transactions in the
business system and the company, including the rules and policies imposed by regulatory and government
agencies. Civil, criminal liability, or regulatory penalty from a security incident or attack have a negative
impact on the business. Therefore, the amount of regulation and steps to ensure compliance must be
factored in this driver, which includes privacy issues, the ability to prove the transaction initiator, and proving
compliance.
An implemented log management system can tell who did what, where, and when. Log management,
therefore, is part of an IT security compliance management system. For the retention period of the logs, it is
ensured that the necessary information is available and can be analyzed or interpreted to a level that can
help management to better investigate security incidents or comply with external regulation or laws.
Compliance is a key business driver today, and log management must be a part of every IT security
compliance management solution. But, it can also be implemented alone as an initial step toward a larger IT
security compliance initiative.
Many international standards and regulatory controls require logging to be enabled and implemented. Also,
these logs must be analyzed periodically and stored for a specific period, depending on the standard or
regulatory control.
Contractual obligation
Security measures for an IT system are likely to be proportional to the consequences encountered when the
business encounters contractual liability from a security attack. Depending on the structure and terms of the
contract, the consequence might lead to financial loss or liability. For example, when security incidents are
encountered, the business might be unable to fulfill its contractual obligations of providing goods or services.
Financial loss and liability

© Copyright IBM Corp. 2016 3-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Direct or indirect financial loss is a consequence to the business because of a security incident. Direct loss
might include theft of an asset, theft of a service, or fraud. Indirect loss might include loss based on civil or
criminal court ruling, loss of good will, or re-prioritized budget allocation. This driver identifies the fact that
security measures for an IT system are likely to be in proportion to these consequences.
Critical infrastructure
This driver applies where security threats or threat agents can have a major impact on services or resources
that are common to, or shared among, a community of businesses, the population at large, or both. Examples
include telecommunications, electrical power, transportation systems, and computing. The loss of critical
infrastructure by its provider might have a ripple effect, causing secondary losses and driving security
decisions for affected businesses and resources. An important part of risk analysis is identifying critical
infrastructure.
Safety and survival
This driver applies where security threats and threat agents can have a major impact on aspects of human
life, government function, and socio-economic systems. Examples of processes to be considered for their
safety and survival impact include the continuity of a critical infrastructure, medical system, life support, or
other high-impact or time-dependent process.

© Copyright IBM Corp. 2016 3-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Driver influence endpoint security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the IT drivers that influence the endpoint security

– Internal threats and threat agents
– External threats and threat agents
– IT service management commitments
– IT environment complexity
– Business environment complexity
– Audit and traceability
– IT vulnerabilities: Configuration
– IT vulnerabilities: Flaws
– IT vulnerabilities: Exploits
– End User Complexity
– Fast-Growing Web Threats
– VPN Security Challenges

© Copyright IBM Corporation 2016

Figure 3-7. Driver influence endpoint security

IT drivers that influence security

IT drivers make up the second group of key security initiatives. These universal drivers must be considered in
every modern IT solution in a manner commensurate with the risks and consequences of a related failure or
incident.
Internal threats and threat agents
Security-related failures and incidents are caused by threats or threat agents found within the physical and
logical boundaries of the organization or enterprise that operates and controls the IT system. These threats
and threat agents might be associated with technology or people.
An example of an internal threat is a poorly designed system that does not have the appropriate controls. An
example of an internal threat agent is a person who uses an ability to access the IT system or influence
business or management processes to carry out a malicious activity.
External threats and threat agents
Security-related failures and incidents are caused by threats or threat agents found outside the physical and
logical boundaries of the organization or enterprise that operates and controls the IT system. These threats
and threat agents are also associated with technology or people. They seek to either penetrate the logical or
physical boundary to become internal threats or threat agents, or to influence business or management
processes from outside the logical or physical boundary.
Examples of external threats are single points of failure for one or more business or management processes
that are outside the enterprise boundary, such as a power system grid or a network connection, or a
computer virus or worm that penetrates the physical or logical network boundary. An example of an external

© Copyright IBM Corp. 2016 3-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
threat agent is a malicious hacker, or someone who gained the ability to act as an insider, by using personal
electronic credentials or identifying information.
IT service management commitments
This driver identifies the fact that failure to manage the operation of the IT system might result in security
exposures to the business. This driver can be divided into two categories: IT service delivery and IT service
support.
Service delivery commitments
The failure of the IT system to meet its metrics for managing itself can be viewed as a security
exposure to both business or management processes. An example of security exposure for service
delivery is when IT operations processes cannot respond to critical events in a timely manner.
Another example is when IT resilience processes cannot recover from a denial of service attack in a
timely manner, resulting in a loss of capacity or response time for business processes.
Service support commitments
The failure of the business or IT management system to meet its service level agreements (SLAs)
can be viewed as a security exposure to business or management processes.
An example of security exposure for service support is a situation in which the customer relationship
processes do not add, modify, or remove users from access control lists in a timely manner.
IT environment complexity
The complexity of the IT environment might contribute to the security or insecurity of the IT system. The IT
environment reflects the infrastructure on which the business system is placed.
For example, any IT environment that is connected to the intranet or extranet is exposed to internal or
external threats or threat agents and requires specific security responses. A stand-alone facility for our
system represents the lowest complexity. A hosting facility with other systems and other firms represents a
more complex environment. An environment with a larger number of systems, varied network access paths,
or a complex architecture, is a complex IT environment.
Business environment complexity
Because most businesses rely on IT, most business environments are an interconnected set of businesses,
each with its own complex IT environment, business processes, and IT management processes. This
complexity might contribute to the security or insecurity of the IT system.
Audit and traceability
This driver identifies the need for the IT system to support an audit of information contained within the
system, whether it is associated with management data or business data.
IT vulnerabilities: Configuration
Configuration vulnerabilities are potentially present in every IT system, providing an opening to a potential
attack based on the system and how it is designed and set up.
IT vulnerabilities: Flaws
Software flaws potentially exist in every IT system. These flaws represent vulnerabilities that were not
detected and are not evident in the design documents. Therefore, they are an unexpected deviation from
what was designed. An example is a defect in an operating system or application that is discovered after
implementation.
IT vulnerabilities: Exploits
The basic design of software in any IT system might be exploited by threats or threat agents as a part of an
attack on the IT system, the business, or the management processes, which might include the use of a
function within a system in a way to compromise the system or underlying data. Although certain people
might define an exploit as both the flaw and the method, we treat them separately because an exploit might
involve the use of normal functions as designed in an unusual manner to attack the system. The exploits can
also be viewed as the openings or avenues that an attacker can use.

© Copyright IBM Corp. 2016 3-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
The general trend in the endpoint security industry has been to consolidate disparate applications listed
above into a unified product or a suite of integrated products.

End User Complexity

In the last 20 years, the endpoint security market has evolved from a single antivirus product on the desktop
to a complex and intricate set of solutions.
This evolution is mostly due to the mounting threats facing the endpoints which are not limited to virus and
worms anymore but also now includes web threats such as phishing attacks and drive-by downloads. In
addition, solutions such as remote access for mobile workers and data security in highly regulated countries,
states and industries have forced the corporate laptop to bear up to 9 separate solutions to be fully protected.
The complexity of the new endpoint security environment makes it difficult for IT security staff to update and
patch all assets across all technologies in a timely manner while the performance of laptops and the
productivity of their users is hindered by too many scans, updates and patches.
Fast-Growing Web Threats
Drive by downloads, phishing attacks and other web-based threats constitute over 40% of all threats today.
Web 2.0 opened new horizons for end-users but has been the target of modern hackers learning fast how to
propagate malware or steal confidential information from unprotected endpoints.
Here are just a few examples of the most popular attacks and exploits happened recently.
- Nine Ball is a multi-layered Web browser attack targeting legitimate Web sites and forcing them
to redirect users to malicious sites owned by the attacker. The Nine Ball attack first works by
infecting a legitimate Web site, and then redirects the visiting victim to a malicious site owned by
the attacker. The compromised website, loaded with malware, checks for vulnerabilities in the
browser, Microsoft Data Access Components (MDAC), AOL Super Buddy, Adobe or QuickTime
software on the user’s desktop, making the victim susceptible to a drive-by-download attempt. If
successful, the attack will download a Trojan with a keylogger component used to log keystrokes.
Anything the victim types could be monitored and used to commit data theft, such as stealing
customer data, corporate credit card numbers or passwords. To counter that threat, WebCheck
protects and alerts users to phishing attempts and drive-by downloads.
- Gumblar is a Web attack that compromises Web sites and downloads malware onto
unsuspecting computers. Gumblar is named after the Gumblar.cn exploit, which so far targets
users of Internet Explorer and Google search, delivering malware through compromised sites to
infect a user’s PC and subsequently intercept traffic between the user and the visited sites. Once
infected, anything the victim types could be monitored and used to commit data theft. Visitors
encountering the compromised website also risk having their subsequent search results replaced
with links that point to other malicious websites. The malware can also steal FTP credentials
from the victim’s computer and use them to infect more sites, thus increasing the spread of this
threat.
VPN Security Challenges
Today, the C-level executives are concerned about two things: rogues and regulations;
• They want to eliminate rogues so their networks and computers are protected from hackers and thieves.
Rogue are:
▪ good computers gone bad – out of compliance and thereby offer vulnerabilities that can be
exploited,
▪ good employees gone bad or
▪ computers manned by hackers or thieves to exploit other systems.
• They want to comply with regulations so that they don’t get unwanted attention from their shareholders or
the press or fines from the government

© Copyright IBM Corp. 2016 3-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Challenges of Endpoint Security (1 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Some major challenges while delivering endpoint security

– Complacency and Risk
– Business Challenges
– The Threats Keep Coming

© Copyright IBM Corporation 2016

Figure 3-8. Challenges of Endpoint Security (1 of 2)

Challenges of Endpoint Security

Delivering endpoint security in an increasingly mobile environment comes with some major challenges.
Growing businesses know they need to protect their end users from viruses, spyware and unauthorized
intrusion. In fact, the majority use some kind of anti-virus software and firewall on their desktop and notebook
PCs. But it is not good enough.
According to research by PricewaterhouseCoopers, the vast majority of small and medium-size businesses
(83%) suffered a security incident in the year 2015. Nearly half of them (43%) were virus infections. So,
clearly there is a difference between what companies say they do about security and the results they actually
achieve.
Complacency and Risk
This gap between needs and results comes down to following factors:
• IT management bandwidth: Without large IT departments, it is hard for companies to check
continuously that every PC has the latest patches, the correct anti-virus software and a fully up-to-date
firewall.
• More flexible and mobile workforce: The increase inflexible and mobile workers have changed the
nature of security. More than 63% of SMBs give their staff remote access to company systems. If security
software doesn’t allow for remote management and remote updating, these users are at greater risk of
infection.

© Copyright IBM Corp. 2016 3-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Lack of integration: Only large companies with large IT departments have a fully-integrated, coherent,
multilayered defense against security threats backed up by in-house security expertise. When you
multiply best-of-breed point solutions for security what you get is a mongrel.
• Fast moving security threats: The traditional model of a perimeter-based firewall and client-resident
endpoint security provides a degree of security but also the risk of complacency. After all, the attacks
continue, online criminals get smarter and new patterns of work create new risks. For example, targeted
trojans and zero-day attacks are on the rise.
• In short, businesses have got the message that they need anti-virus software and firewall protection on
all their PCs (or ‘endpoints’) but they don’t always have the right technology to do it well. The result is a
false sense of security. They think they are safe, but they’re not.
Business Challenges
Companies are facing challenges that make good security tough:
• Lack of IT resources: Most smaller companies rely on a handful of individuals, some with other
responsibilities, and often a third party IT consultant to manage their infrastructure. Without the resources
and scale or a large IT department, it can be a struggle just dealing with routine user problems, let alone
proactively defending the company against security threats.
• No in-house expertise: It is unlikely that a growing company would have a specialist IT security expert
on staff. Most IT support firms do not have this expertise either. Instead, companies have to rely on the
credentials and track record of software vendors.
• Ad-hoc PC management: Growing companies often have limited or non-existent PC management
systems. This makes it harder to ensure that software installations and PC configurations are consistent
and it makes it harder to solve problems when they occur, especially for remote users.
• Focus on more important tasks: Quite rightly, companies tend to focus on growing the business rather
than growing their IT overhead.
• Clearly, growing businesses need to take a new approach to ensure they stay protected, to look after
remote users and to do all these things while keeping costs down and reducing the administration
overhead.
The Threats Keep Coming
Client-side vulnerabilities are the weakest link in the security chain, according to a SANS Institute report on
the top ten cyber-security risks. Online criminals exploit them using targeted email and ‘drive-by’ web-hosted
malware. Up-to-date security software is the main defense but updating many PCs can be time-consuming,
especially if PCs are not connected to the company network for a while. This delay can leave endpoints
vulnerable for hours, or even days, before the patch is applied.
Delays increase risk, especially with zero-day attacks that strike hard and fast before security vendors can
issue an update. The SANS Institute reports a rising number of these zero-day attacks over the past three
years. A large IT department can throw resources at a problem like this, but a small to midsize company with,
say 100 employees and one full-time IT manager, will always find it harder to react quickly.

© Copyright IBM Corp. 2016 3-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Challenges of Endpoint Security (2 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Some major challenges while delivering endpoint security

– Protecting Mobile Users
– Client-side Performance
– Overworked IT Staff
– The Cloud Alternative

© Copyright IBM Corporation 2016

Figure 3-9. Challenges of Endpoint Security (2 of 2)

Protecting Mobile Users

Mobile and flexible working is on the rise. It helps growing business attract and retain great talent and reduce
the cost of office space. Also, more entrepreneurial companies like to spend more time with clients than they
do in the office. So, everyone’s a laptop warrior now but this brings concerns on the security front.
According to Gartner Research, companies that do not address mobile security risks properly will experience
more security breaches and this will increase the costs per remote worker by a factor of ten. In other words,
security problems could erase the very benefits an organization hopes to achieve by letting their staff out of
the office.
In any company, managers love the idea of remote access and the productivity it brings, with one exception.
The IT security manager is often the lone holdout who resists the practice, arguing that with company
computers leaving the physical confines of the office, it becomes more difficult to retain control over it, control
over it, check how up to date the security software is, and monitor what websites the end user is connecting
to on the internet. When computers are safely inside the worker’s cubicle, the IT manager can impose URL
filters to keep out potentially dangerous web sites, prevent installation of unauthorized software, and regularly
update security software. But things might take an unpleasant turn when those computers leave the office, or
worse, when employees start using their unprotected, un-firewalled home computers and laptops to connect
to the corporate intranet.
Client-side Performance
End users have little patience with slow computers, regardless of whether they are on-site or at home in their
pajamas. The industry continues to produce faster processors on a regular basis, and this fuels our
expectations for responsive applications. When the computer takes too long to boot, or when an application

© Copyright IBM Corp. 2016 3-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
doesn’t respond to a command within a split second, people call the help desk. Or, worse, they disable
anti-virus software altogether.
Client-side security has the advantage of performing a final check after traffic has already passed through a
corporate firewall, but it often comes with a performance hit. Companies may have dozens of older
computers that are still in use, which struggle with resource-intensive client-resident security programs and
huge virus definition lists.
Overworked IT Staff
Nobody has an unlimited IT budget. This is especially true in entrepreneurial companies where funds are
needed for growth. Often, IT staff are overwhelmed with routine technical support and systems
administration. Time spent "putting out fires" leaves no time for putting good security practices in place. In
fact, according to the Cybersecurity Watch Survey, only 56% of respondents actually had a formal plan for
managing security and responding to incidents. 19% said they had no such plans but planned to create them
within the next year, and 18% had no plans at all.
As a result, companies need security systems that are as simple as possible – "set-it and forget it" rather than
install upgrade-and-fidget – and they also need systems that provide the greatest security for the least
amount of management oversight. They need a solution that installs endpoint security easily, manages it
consistently and keeps it up to date automatically.
The Cloud Alternative
Cloud services (also known as hosted services, software-as-a-service or SaaS) are becoming increasingly
popular. It requires little or no on-site hardware and companies usually pay for it on a per-user fee. Moving
applications and security to the cloud can lower capital costs, make management easier and improve
flexibility.
The greatest benefit of cloud services is that it delivers economies of scale and expertise. For example, with
cloud based security, there is the benefit of IT security experts and robust, up-to-date technology. It is simply
too hard and too expensive to build this capability in an individual company. Besides the human resources,
the technology resources are also state-of-the-art. The cloud security provider’s data center is much more
likely to possess the latest technology, high-end servers and fast connections, all of which are managed and
monitored 24x7x365.
Other advantages include streamlined management and ease of deployment. With the service provider
taking care of routine maintenance, upgrades, security patches and other tasks, the client can focus on other
areas of the business. Control and visibility over the security environment is retained with a secure web
based portal that delivers detailed reports and the ability to change policy settings or carry out routine tasks
such as adds/changes/moves.
However, cloud security’s biggest advantage is that it solves the remote user dilemma. Many solutions don’t
update remote users until they log into the company network. This means delays and vulnerability. In a
hosted environment, geography is irrelevant. Each client automatically obtains updates directly from the
cloud solution provider, regardless of location.

© Copyright IBM Corp. 2016 3-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Endpoint Security Solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems

• General aspects covered by an Endpoint Solution

– Personal Firewall
– Wireless Security
– Port Control
– Data Encryption
– USB and Storage Device Security
– Application Control
– Integrity and Remediation
– Client Self-Defense
– Alerts Monitoring

© Copyright IBM Corporation 2016

Figure 3-10. Endpoint Security Solutions

Endpoint Security Solutions

Of all the IT elements that to secure in an organization, the endpoints are the most elusive. A flaw in an end
user device can lead to a breach at the very core of the business, so hardening those endpoints is key to
preventing those breaches.
Endpoints are as hard to define as they are to protect. The term traditionally referred to desktops and laptops,
but endpoints now encompass smartphones, tablets, point-of-sale machines, bar code scanners,
multifunction printers and practically any other device that connects to the company network. Without a
well-conceived strategy, keeping track of and securing these devices is difficult and frustrating.
Endpoints are also more vulnerable than they've ever been. Zero-day attacks via Java and Adobe Flash,
exploit kits waiting for unsuspecting end users and targeted phishing attacks demonstrate that attackers have
moved away from targeting servers and are taking laser aim at endpoints. As a result, security pros must
worry less about the perimeter and more about the most fragile and volatile piece of the IT infrastructure:
endpoints - and the unpredictable end users whose behavior can put the business at risk.
Hardening networks with firewalls isn't enough, yet companies still leave their networks flat and unprotected
inside the firewall. The security of the internal network starts to matter just as much as the external.
While server security is critical, locking servers down is easier than securing endpoints. Servers serve one or
two core functions, letting IT build security controls around those functions. Endpoints serve many functions,
and even when they're outfitted with security controls, users often change them, and attackers also can fool
users into skirting security practices.

© Copyright IBM Corp. 2016 3-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Security awareness among users is a primary aspect of meeting the endpoint security challenge. Training
users on how to spot certain types of attacks and instilling a sense of caution is key to his approach.
Companies must also adopt endpoint hardening techniques, new endpoint security products and
network-based security controls. Even then, attackers may break through, but with protection and monitoring
in place, companies can detect and remediate attacks before it's too late.
For most IT pros, endpoint protection equates to antivirus and anti-malware products. But endpoint protection
starts with "host hardening," implementing best practices to secure endpoints before they're handed to end
users or before any third-party applications are added.
These include practices such as the principle of least privilege, whereby users are granted only the account
privileges they need to do their jobs; segregation of duties, which requires more than one person to make
critical changes; and need to know, under which access to resources is limited to those who must have it.
Some IT shops buy cleverly marketed products that promise off-the-shelf endpoint security using
anti-malware and sandboxing. In most cases, attackers can easily bypass those defenses. Readily available
exploits and tutorials help attackers identify hosts that haven't been properly configured or ones where users
have made changes - disabled antivirus protection or installed vulnerable software, such as Java - that
increase the vulnerability of the host.
Failing to follow the least privilege principle can cause major problems, particularly when users are given
admin privileges on their desktops, laptops and mobile devices. Users often are given admin rights when an
IT environment is being created and is still small, then they resist losing those privileges later. When IT
environments are set up with the endpoint administrative rights disabled, power users and executives often
fight for those privileges, saying they regularly install software or make system changes.
There are other ways security organizations lose control of administrative rights; however, it happens, letting
users act as admins creates the potential for local administrator, domain-level and service accounts to be
compromised.
For example, say the CEO's administrative assistant falls for a phishing scam and clicks on a link that takes
her to a site that exploits the latest Java zero-day vulnerability. The malware installed on her system now has
the same admin rights that she does. If there's software running on the system with a shared domain-level
service account - or if the administrator password on the administrative assistant's computer is the same
across many of the desktops in the company - the malware can spread from her system to practically every
system in the company.
If the user in this scenario hadn't had admin rights, it would have been more difficult (though not impossible)
for the malware to spread. Security consulting firms like mine look for these users with administrative
privileges when we do penetration testing. An attacker needs only one vulnerable endpoint to spread laterally
throughout a company, pivoting from endpoint to endpoint, siphoning data.
Policy configuration best practices on desktop, laptop, and even tablet and smartphone operating systems
limit the impact of, and even prevent, successful attacks. These practices include password age, history and
complexity requirements; account lockout provisions; system and user activity audits; firewall configuration;
logging; and putting unique local administrator passwords on each host.
Aspects covered by an Endpoint Solution
Generally, endpoint solutions are sought to provide a fully integrated suite for perimeter-to-core endpoint
protection, covering following aspects:
• Personal Firewall: Protects the endpoint device against hackers, malware, protocol attacks, etc.
• Wireless Security: Controls where, when, and how users can connect. Wireless connectivity can be
limited to authorized access points, establish a minimum level of encryption strength, or even disable
wireless networking completely. VPN policies can be automatically enforced, requiring VPN software to
be running while devices connect to foreign networks such as those in hotels, hot spots and coffee
shops. Rogue access point detection helps ensure wireless security in and around the office.
• Port Control: Secures all the endpoint communication ports and adapters, including LAN, USB, modem,
Bluetooth, infrared, and serial and parallel ports.

© Copyright IBM Corp. 2016 3-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Data Encryption: Secures data stored on endpoint devices, including information stored on both fixed
and removable media, by encrypting files so they can only be read by authorized users. Keys are
managed transparently throughout the enterprise, requiring no end-user involvement other than getting
work done in the usual way.
• USB and Storage Device Security: Prevents intentional or inadvertent transmission of data to
removable storage devices. Storage devices such as thumb drives, iPods, cameras, printers, CD and
DVD drives can be placed in read-only mode or fully disabled, while the endpoint hard drive and all
network drives remain accessible and operational. White lists of specifically approved USB devices can
be employed.
• Application Control: Determines the applications that can and cannot be used, ensuring that only
approved applications run on your corporate endpoints. Both white lists (allowed applications) and black
lists (prohibited applications) can be created, and applications can be forced, such as a VPN client to run
prior to network connection.
• Integrity and Remediation: Verifies that designated endpoint antivirus and anti-spyware software is
running and is up-to-date, whether the endpoint connects to the corporate network or the Internet.
• Client Self-Defense: Prevents the endpoint security client from being altered, hacked, or uninstalled.
• Alerts Monitoring: Ensures that attempts to compromise corporate security policies are reported to the
Management Console so that risk can be promptly remediated. A complete suite of reporting and audit
tools is also available to ensure that users are complying with internal security policies and to document
compliance of your endpoint security controls with SOX, HIPAA, and other regulatory mandates.

© Copyright IBM Corp. 2016 3-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Gartner’s Magic Quadrant IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Endpoint protection platforms capabilities & things include in EPP

– Antimalware
– Personal firewall
– Port and device control

© Copyright IBM Corporation 2016

Figure 3-11. Gartner’s Magic Quadrant

Gartner’s Magic Quadrant for Endpoint Protection Platforms

The enterprise endpoint protection platform (EPP) is an integrated solution that has the following
capabilities:
• Anti-malware
• Personal firewall
• Port and device control
EPP solutions also often include:
• Vulnerability assessment
• Application control and application sandboxing
• Memory protection
• Behavioral monitoring of application code
• Endpoint detection and remediation technology
• Full-disk and file encryption, also known as mobile data protection
• Endpoint data loss prevention (DLP)
• Enterprise mobility management (EMM), typically in a parallel non - integrated product

These products and features are typically centrally managed and ideally integrated by shared policies. Not all

© Copyright IBM Corp. 2016 3-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
products in this analysis provide the same collection of features. Here, we focus primarily on anti-malware
effectiveness and performance, management capability, protection for Windows and non-Windows platforms
(such as VMware, Macintosh, Linux, Microsoft Exchange and Microsoft SharePoint), application control,
vulnerability assessment, and emerging detection and response capabilities. See the Completeness of Vision
section for more information.
DLP, EMM and vulnerability assessment are also evaluated in their own Magic Quadrant analyses (see the
Gartner Recommended Reading section). In the longer term, portions of these markets will be subsumed by
the EPP market, just as the personal firewall, host intrusion prevention, device control and anti-spyware
markets have been subsumed by the EPP market. EPP suites are a logical place for the convergence of
these functions. In a recent Gartner survey, 40% of organizations said they already use a single vendor for
several EPP functions, or are actively consolidating products. In particular, mobile data protection is the
leading complement to EPP, and purchasing decisions for the two products are increasingly made together.
For most organizations, selecting a mobile data protection system from their incumbent EPP vendors will
meet their requirements. Application control and the features of vulnerability analysis are also rapidly
integrating into EPP suites. Currently, EMM is largely a separate purchase for more demanding large
enterprise buyers; however, small and midsize businesses (SMBs) are likely to be satisfied with EPP
vendor's EMM capabilities.
The total EPP revenue of the Magic Quadrant participants at year-end 2014 was slightly under than $3.2
billion, up 2% over the previous year. EPP suites continue to grow in functionality. Consequently, some EPP
revenue is inflow from other markets. We anticipate that growth will continue to be in the low single digits in
2016.

© Copyright IBM Corp. 2016 3-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Quadrant Descriptions IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Explaining the quadrant descriptions

– Leaders
– Challengers
– Visionaries
– Niche Players

© Copyright IBM Corporation 2016

Figure 3-12. Quadrant Descriptions

Leaders
Leaders demonstrate balanced progress and effort in all execution and vision categories. Their capabilities in
advanced malware protection, data protection and/or management features raise the competitive bar for all
products in the market, and they can change the course of the industry. However, a leading vendor isn't a
default choice for every buyer, and clients should not assume that they must buy only from vendors in the
Leaders quadrant. Some clients believe that Leaders are spreading their efforts too thinly and aren't pursuing
clients' special needs.
Challengers
Challengers have solid anti-malware products that address the foundational security needs of the mass
market, and they have stronger sales, visibility and/or security lab clout, which add up to a higher execution
than Niche Players offer. Challengers are good at competing on basic functions, rather than on advanced
features. They are efficient and expedient choices for narrowly defined problems.
Visionaries
Visionaries invest in the leading-edge (aka "bleeding edge") features - such as advanced malware
protection, data protection and/or management capabilities - that will be significant in the next generation of
products, and will give buyers early access to improved security and management. Visionaries can affect the
course of technological developments in the market, but they haven't yet demonstrated execution. Clients
pick Visionaries for best-of-breed features, and, in the case of small vendors, clients may enjoy more
personal attention.
Niche Players

© Copyright IBM Corp. 2016 3-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Niche Players offer viable anti-malware solutions that are typically component parts of broader solutions via
OEM-provided component parts, or are vendors that offer solutions that complement, rather than replace,
incumbent EPP solutions. Some
Niche Players have not demonstrated sufficient focus on the core needs of buyers, despite long tenures in
this market.
Protection from common malware, as well as more APTs, is the top critical consideration for EPP buyers.
There is significant variation in the quality of attack prevention, as illustrated by multiple malware testing
organizations. Buyers should look for solutions that offer a broad portfolio of protection techniques and high
efficacy, as determined by multiple public test results.
Solutions should provide a holistic security state assessment and a prioritized action plan to remediate
potential security gaps. This not only enables administrators to proactively lower the attack surface on
endpoints, but also can provide a performance metric that can be tracked over time to demonstrate the
effectiveness of security operations.
Protection from highly targeted, new and low-volume attacks requires a more proactive approach that is
grounded in solid operations management processes, such as vulnerability analysis, patch management and
application control capabilities. In particular, application control, which restricts execution to known good
applications, is proving to be effective in demanding security environments, and is especially effective when
combined with support for trusted change and supplemented with cloud-based file reputation services.
Full application attestation - that is, classifying the entire application and process inventory into bad, good or
unknown classifications, and rapidly classifying the unknown - will provide higher degrees of confidence that
endpoints are malware-free. Traditional approaches using malware-detection-only approaches can leave
unknown processes lurking for long dwell times. Integration with cloud-based or private malware sandboxes
will improve the speed of classification of unknown objects.
In theory, any security solution can be bypassed. Enterprise buyers should look for malware infection
detection tools. These tools provide the capability to alert administrators about threats that may have had a
longer dwell time or more virulent infections. Malware investigation information should be sufficient to enable
administrators to perform their own manual inspections for missed components of more complex infections,
and to ascertain when, where and how the initial infection occurred, what happened after the infection
started, as well as what other systems have handled the malicious content.
Solutions should include EMM capabilities and data protection for mobile and employee-owned devices.
Buyers should favour solutions that have a short-term integration roadmap of the EMM capability into the
broader suite.
Performance on virtual servers and hosted virtual desktops/the virtual desktop infrastructure is an
increasingly important critical capability. Consider the level of optimization and integration for virtual servers,
but do not assume that solutions must be "agentless" to provide the best performance. There are other ways
to optimize performance in virtualized environments - for example, with the coordinated sharing of caches
between VMs.
Server platforms are commonly supported by EPP vendors; however, optimal server protection may require
additional features and protection mechanisms, such as file integrity monitoring or Web application firewalls.
Enterprise buyers should consider specialized server solutions.
Clients investigating solutions for VMware environments need to consider that VMsafe APIs will be going end
of life from ESXi 5.5 and beyond. Those wishing to implement ESXi 5.5 or updated versions need to consider
how vendors plan to support vCloud Networking and Security.
Solutions that take a more operational tool approach will be more flexible, and will provide more security state
information, more forensic information and better remediation capability. IT organizations that cannot handle
the increased complexity should outsource EPP management to managed security service providers.

© Copyright IBM Corp. 2016 3-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Evaluation Criteria Definitions IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Explaining the evaluation criteria definitions

– Ability to Execute
– Vendor Strengths and Limitations

© Copyright IBM Corporation 2016

Figure 3-13. Evaluation Criteria Definitions

Evaluation Criteria Definitions

Ability to Execute
• Product/Service: Core goods and services offered by the vendor for the defined market. This includes
current product/service capabilities, quality, feature sets, skills and so on, whether offered natively or
through OEM agreements/partnerships as defined in the market definition and detailed in the subcriteria.
• Overall Viability: Viability includes an assessment of the overall organization's financial health, the
financial and practical success of the business unit, and the likelihood that the individual business unit will
continue investing in the product, will continue offering the product and will advance the state of the art
within the organization's portfolio of products.
• Sales Execution/Pricing: The vendor's capabilities in all presales activities and the structure that
supports them. This includes deal management, pricing and negotiation, presales support, and the
overall effectiveness of the sales channel.
• Market Responsiveness/Record: Ability to respond, change direction, be flexible and achieve
competitive success as opportunities develop, competitors act, customer needs evolve and market
dynamics change. This criterion also considers the vendor's history of responsiveness.
• Marketing Execution: The clarity, quality, creativity and efficacy of programs designed to deliver the
organization's message to influence the market, promote the brand and business, increase awareness of
the products, and establish a positive identification with the product/brand and organization in the minds
of buyers. This "mind share" can be driven by a combination of publicity, promotional initiatives, thought
leadership, word of mouth and sales activities.

© Copyright IBM Corp. 2016 3-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Customer Experience: Relationships, products and services/programs that enable clients to be
successful with the products evaluated. Specifically, this includes the ways customers receive technical
support or account support. This can also include ancillary tools, customer support programs (and the
quality thereof), availability of user groups, service level agreements and so on.
• Operations: The ability of the organization to meet its goals and commitments. Factors include the
quality of the organizational structure, including skills, experiences, programs, systems and other
vehicles that enable the organization to operate effectively and efficiently on an ongoing basis.
• Completeness of Vision Market Understanding: Ability of the vendor to understand buyers' wants
and needs and to translate those into products and services. Vendors that show the highest degree of
vision listen to and understand buyers' wants and needs, and can shape or enhance those with their
added vision.
• Marketing Strategy: A clear, differentiated set of messages consistently communicated throughout the
organization and externalized through the website, advertising, customer programs and positioning
statements.
• Sales Strategy: The strategy for selling products that uses the appropriate network of direct and indirect
sales, marketing, service, and communication affiliates that extend the scope and depth of market reach,
skills, expertise, technologies, services and the customer base.
• Offering (Product) Strategy: The vendor's approach to product development and delivery that
emphasizes differentiation, functionality, methodology and feature sets as they map to current and future
requirements.
• Business Model: The soundness and logic of the vendor's underlying business proposition.
• Vertical/Industry Strategy: The vendor's strategy to direct resources, skills and offerings to meet the
specific needs of individual market segments, including vertical markets.
• Innovation: Direct, related, complementary and synergistic layouts of resources, expertise or capital for
investment, consolidation, defensive or pre-emptive purposes.
• Geographic Strategy: The vendor's strategy to direct resources, skills and offerings to meet the specific
needs of geographies outside the "home" or native geography, either directly or through partners,
channels and subsidiaries as appropriate for that geography and market.

© Copyright IBM Corp. 2016 3-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Vendor Strengths and Limitations

(1 of 6) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining Vendor Strengths and Limitations

– Bitdefender
– Check Point Software Technologies
– Cylance

© Copyright IBM Corporation 2016

Figure 3-14. Vendor Strengths and Limitations (1 of 6)

Bitdefender
Bitdefender still generates the majority of its revenue from consumer sales, but the gap between consumer
sales and enterprise sales narrowed in 2015. The company is investing heavily into its sales operations in
Europe and the U.S. Updates to the enterprise offering included improvements in security event feeds from
endpoints to the management console, formulating better insights into the presence of malware, unwanted
applications, advanced threats and remediation. Bitdefender is a consistently solid performer in anti-malware
test results, and noted by clients for ease of use and customer support. Increased evaluation weight on
malware effectiveness and company focus nudged Bitdefender into the Visionary quadrant this year. It is a
good choice for SMBs in supported geographies that highly weight malware detection accuracy and
performance.
Strengths
• Bitdefender provides very good malware detection capabilities, including a sandboxed application
emulation environment, automatic unknown file analysis and continuous behavior monitoring, resulting in
very good public test scores. The agent performance is very good, too, with low overhead.
• Enhancements to the GravityZone management interface provide enterprise clients with better insights
into the state of malware, applications and advanced threats for physical, virtual and mobile endpoints.
• Good support is provided for public and private hybrid cloud based management of endpoints, virtualized
endpoints, AWS security as a service and Exchange.
• Device control and Exchange security module have been added to the Management Console, and
improvements to the remediation process can be triggered via a single-click action.

© Copyright IBM Corp. 2016 3-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• The company received high marks from reference customers for support and service.
• The company provides OEM solutions to many vendors included in this analysis.
Limitations
• Bitdefender is aggressively investing in growing its sales operations in the U.S. and EMEA; however,
significant work remains for it to become a well-known name and to get mind share outside of its core
SMB market.
• Bitdefender does not offer full feature parity between Windows, OS X and Linux. The Windows offering
supports anti-malware, firewall, content control and device control. OS X and Linux have only
anti-malware capabilities.
• List price is at the upper end of the average pricing for this market.
Check Point Software Technologies
Check Point Software Technologies is a well-known network security company. Its venture into the EPP
market, starting with the 2004 acquisition of ZoneAlarm, continues to suffer from poor marketing and channel
execution. However, it will still appeal to organizations that value strong integration among endpoint threat
prevention and forensics with network-based detection.
Strengths
• Endpoint's URL filtering capability enables an off-LAN URL filtering security policy synchronized with a
firewall blade policy.
• Antivirus Software Blade centrally captures data from activity sensors and initiates algorithm based
analysis when triggers are tripped from within protection mechanisms. Relevant data is presented
providing a complete picture of events under investigation.
• Check Point's endpoint management console can be customized for each administrator with user specific
policy views across multiple devices.
• The Endpoint Security Best Practice Report provides the main configuration/vulnerability issues,
including vulnerable applications, misconfigurations, missing windows service packs and potentially
unwanted applications.
Limitations
• Again, this year, Check Point did not disclose sufficient detail for Gartner to adequately evaluate its
progress in this market; however, based on Gartner client inquiry levels about Check Point's EPP
solutions, it has again failed to significantly improve its market share or mind share in the EPP market
beyond the acquired installed base of customers.
• While Check Point has invested over the past year in its own malware research lab, it continues to
depend on Kaspersky Lab's engine and signature updates for this offering.
• Check Point's application control capabilities (which it calls "program control") remain largely unchanged
for this year. Application control capabilities continue to rely on URL filtering, anti-bot and anti-malware
for restricting unapproved and suspicious applications.
• Check Point EPP protection is oriented toward Windows endpoint PCs. Not all software blades are
available for OS X, and Check Point doesn't offer protection for specialized servers, such as Microsoft
Exchange, Microsoft SharePoint or Lotus Notes. It does not offer feature parity for OS X or Linux.
• Although its agent will run in virtual machines (VMs), Check Point has no specific optimization for
virtualized environments.
• Cloud management is focused on Check Point Capsule and Mobile Threat Prevention products only, and
does not include the management of endpoint offerings.
Cylance
Cylance is a fast-growing startup that provides an innovative new approach that replaces traditional signature
database approaches found in traditional antivirus products. The company uses a machine learning algorithm
to inspect millions of file attributes to determine the probability that a particular file is malicious. The

© Copyright IBM Corp. 2016 3-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
algorithmic approach significantly reduces the endpoint and network resource requirement. Because of its
signatureless approach, it is capable of detecting both new threats and new variants of known threats that
typically are missed by signature-based techniques. Cylance's approach is also disruptive, because the
company does not require legions of signature authors to analyze new threats and codify them in signature
updates. Cylance will appeal to organizations looking for improved zero-day malware protection, those
looking for low-impact protection for resource-constrained platforms, and systems that are disconnected and
cannot rely on regular signature updates.
Strengths
• The Cylance machine-learning algorithm has been demonstrated to be very accurate at detecting new
variants and repacked versions of existing malware. Cylance also offers memory injection protection for
several the most common classes of vulnerabilities, alternative protection techniques (such as script
control) and lockdown.
• Because the endpoint agent does not require a database of signatures or daily updates, it is extremely
lightweight on the network and has a minimal performance impact on endpoints. It can remain effective
even when disconnected for long periods.
• The management console is cloud based, making it very easy to deploy. However, Cylance does not rely
on cloud based detection, which means protection does not require exfiltration of potentially sensitive
files or data to the cloud.
• Cylance provides file assessment information showing static details on files and global assessment
information, including what other customers do with detected files (that is, the percentage of other
customers that quarantine suspect files).
• Protection is available for Windows and Mac devices. Linux support is due in 2Q16.
• Cylance is easily the fastest growing EPP startup in the last ten years and is gaining traction as an OEM
provider for other security solutions, such as Dell's Endpoint Security Suite Enterprise and Blue Coat.
Limitations
• The Cylance solution provides only anti-malware capabilities. Extended EPP functionality - such as
personal firewalls, URL filtering, port protection, data protection, mobile device protection, enterprise
mobility management, vulnerability analysis, endpoint detection and response (EDR), and application
control - must be sourced and managed separately, if required.
• Cylance is a rapidly growing startup and is likely to suffer from at least some growing pains. Existing
customers are mostly in North America, but Cylance is expanding to the EU and Asia/Pacific (APAC).
• Malware authors develop evasions for more popular anti-malware approaches. As Cylance gains in
adoption and market share, its approach will come under more scrutiny from attackers.
• The Cylance algorithm can cause false positives on less-well-known files that have attributes like
malware files, especially consumer files. However, evidence reports on convicted files, which include
community ratings and severity scores, should provide sufficient info for admins to whitelist most false
positives. Cylance is planning on improving forensic data in 2Q16.
• Support for Microsoft Exchange and other specialized servers is lacking.
• The management console is cloud-based, which may not be a desired deployment option for some
buyers. Reference customers noted the absence of regular expressions for memory defense exclusions,
and the need for improved search functions and agent tamper resistance.
• Current Linux protection is only sold as an OEM solution.

© Copyright IBM Corp. 2016 3-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Vendor Strengths and Limitations

(2 of 6) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining Vendor Strengths and Limitations

– Eset
– FSecure
– Heat Software

© Copyright IBM Corporation 2016

Figure 3-15. Vendor Strengths and Limitations (2 of 6)

Eset
Eset has built a substantial installed base in EMEA, and it has a rapidly growing presence in North America.
Its Completeness of Vision score benefits from good malware effectiveness in a lightweight client, but it still
suffers from a lack of investment in market-leading features, such as vulnerability detection and application
control. Increased evaluation weight on malware effectiveness and company focus nudged Eset into the
Visionary quadrant this year. Eset is a good shortlist option for organizations seeking an effective, lightweight
anti-malware solution.
Strengths
• Eset's anti-malware engine is a consistently solid performer in test results. The engine benefits from
virtual sandbox that simulates executable files before execution in a virtual emulator, a memory scanner
that monitors process behavior and a vulnerability shield for widely exploited software.
• Eset offers broad coverage of capabilities for endpoint security (Windows, OS X), antivirus (Linux,
Windows, OS X, Android), server security (Windows, Linux/BSD/Solaris), mail server security (Microsoft
Exchange, Lotus Domino, Linux/BSD/Solaris, Kerio) and VMware vShield.
• Device control offers OS X support via Endpoint Security and Endpoint Antivirus for OS X from 6.1.
• Cloud-augmented malware protection system for advanced threat defense automatically processes
suspicious objects and potential threats harvested via the Eset Live Grid network.
• Network-traffic-based signatures extend network attack protection (Vulnerability Shield) and botnet
protection analysis of malware network protocol changes via routine signature updates instead of code
updates.

© Copyright IBM Corp. 2016 3-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Limitations
• Eset was late to market with industry-leading functions, such as Web-based management consoles,
EMM and virtualization support. It still does not offer application control or vulnerability scanning.
• Vulnerability Shield does not report on Common Vulnerabilities and Exposures (CVEs) covered.
• Eset SysInspector now supports the automatic triggering of snapshots when events occur; these can be
viewed using Eset Remote Administrator. However, the dashboards still do not provide any vulnerability
or configuration information that would aid in security state assessments.
• Eset does not yet offer a cloud-based management console, despite its focus on SMB customers. Eset
Remote Administrator 6 is currently being evaluated as a Microsoft Azure Certified virtual machine.
F-Secure
F-Secure, a veteran of the anti-malware industry, has an excellent track record for malware testing results.
F-Secure business solutions are targeted for SMBs seeking cost-effective solutions with low administration
overhead. Its Completeness of Vision score is tempered by the slow development of advanced capabilities,
such as dashboards, security state assessments, application control, EMM and virtualization protection.
Increased evaluation weight on malware effectiveness and company focus nudged F-Secure into the
Visionary quadrant this year. Its Ability to Execute score is hampered by low growth and limited market
presence. F-Secure is a good choice for SMB organizations in supported geographies that weight malware
protection as the most import decision factor in their EPP decision.
Strengths
• F-Secure has consistently good malware test results and performance tests. It provides cloudbased
lookups and a file reputation feature, which considers file metadata (such as prevalence, source and age)
before allowing files to execute. The sandbox environment tests unknown applications in a virtual
sandbox for malicious behavior. Safe browsing protection and DeepGuard exploit interception also aid
detection accuracy. F-Secure client agents are lightweight, with minimal performance impact.
• Software Updater provides automatic or manual updating of outdated software, including more than
2,800 versions of the most well-known endpoint and server applications.
• The F-Secure Security for Virtual and Cloud Environments solution is a hypervisor-agnostic, agentbased
security solution that operates as a separate VM.
• On-premises and cloud-based management portals have new user interfaces, with enhanced focus on
security administrator management functions, and streamlined day-to-day activities.
• F-Secure's advanced threat protection solution leverages sensor technology on endpoints and networks
to detect attacks, and leverages F-Secure specialists for review, forensic analysis and response.
• Freedome for Business supports Android and iOS devices, and includes mobile device management that
includes anti-theft, management, monitoring and reporting, VPN, browsing protection, and cloud-based
antivirus (AV).
Limitations
• In 2015, there continued to be very little awareness or brand recognition of F-Secure outside Northern
Europe, despite having had an offering in the EPP market for many years, and adding sales presence in
selected areas of Europe, China and the U.S.
• The updates to the management interface in 2015 provide for a better experience, but still need to be
improved to facilitate the integration of additional relevant data points in context to streamline the analysis
process.
• While F-Secure has a healthy focus on malware detection effectiveness, it has not invested in more
advanced protection techniques, such as security state assessments, application control, malware
investigation and impact assessment capabilities, or network-based malware sandboxing capability.
• F-Secure Security for Virtual and Cloud Environments still does not natively support VMware NSX or
vShield APIs.

© Copyright IBM Corp. 2016 3-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• OS X, iOS and Android are only managed via the cloud-based Protection Service for Business, and
cannot be managed via the on-premises-based console that manages the rest of the suite.
• Although F-Secure develops its own signatures and behavioral detection techniques for advanced
threats, its solution continues to rely on Bitdefender as a reference engine of anti-malware signatures.
Business disruptions at Bitdefender could impact F-Secure customers.
• F-Secure's solutions do not have full-feature parity between the Windows platform and OS X or Linux.
Heat Software
Heat Software was derived from the acquisition of FrontRange by Clearlake Capital Group and its
subsequent merger with Lumension. The Heat Endpoint Management and Security Suite (Heat EMSS)
provides for the integration of client management tools, EMM and security. Current Heat Software customers,
or those seeking integrated solutions for security, operations and compliance, should add this vendor to their
shortlists.
Strengths
• The combination of vulnerability detection, patch management and application control provides a strong
framework for hardening and isolating endpoints from malware. Application control capabilities benefit
from a cloud-based file reputation service and a recently added memory protection capability.
• Heat replaced its Norman anti-malware engine with the more accurate Bitdefender engine.
• Heat EMSS provides a generic framework for the management of third-party security agents, such as
Windows firewalls.
• Heat Endpoint Integrity Service (EIS) provides risk scoring of new applications. Local authorization lets
end users make ad hoc changes with accountability by tracking changes and giving administrators the
ability to reverse when required.
• Heat Software Device Control is a very granular solution for managing and restricting USB and other
ports, and provides shadow copy capability.
Limitations
• Heat Software drifted back into the Niche quadrant this year, as buying focus has shifted to malware
detection capability, and as a result of its limited brand awareness in the EPP market outside of its patch
management installed base. While it is growing, its EPP market share remains very low.
• Heat Software has no anti-malware labs of its own; rather, it relies on a partnership with Bitdefender to
provide this capability. Heat also leverages a disk encryption component from Sophos. Disruptions to
these relationships could have consequences for Heat Software customers.
• Heat Software does not currently plan to offer Application Control, Device Control or AntiVirus to other
platforms beyond Windows.
• Despite the wealth of information in the Heat Software EMSS solution, security state assessment and
support for forensic investigation are weak.
• Heat Software does not provide a personal firewall, but instead relies on native OS firewalls, which don't
provide as many policy options as dedicated solutions. Heat Software provides prebuilt wizards to
configure and manage the Windows Firewall.
• Heat Software does not provide antivirus for specialized servers (for example, Microsoft Exchange and
Microsoft SharePoint). Although its agent will run in VMs, Heat Software has no specific optimization for
anti-malware protection in virtualized environments.

© Copyright IBM Corp. 2016 3-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Vendor Strengths and Limitations

(3 of 6) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining Vendor Strengths and Limitations

– IBM
– Intel Security
– Kaspersky Lab

© Copyright IBM Corporation 2016

Figure 3-16. Vendor Strengths and Limitations (3 of 6)

IBM
IBM's EPP offering is built on the foundation of its client management tool platform, the IBM BigFix,
previously called IBM Endpoint Manager (IEM). IBM Security Trusteer Apex provides application exploit
protection technology and complements the repackaged Trend Micro core anti-malware engine. These tools
are augmented by IBM's X-Force and Trusteer research labs. Large organizations that are considering IBM
for client management tools should include IBM on their shortlists.
Strengths
• The complete set of solutions from IBM, both native and repackaged, represent a significant capability
set that will be welcomed by large, complex organizations. BigFix provides a converged endpoint
management and security operations console that supports multiple endpoint types, including mobile
devices, Linux and Mac devices, and virtual environments. IBM BigFix Compliance offers fully integrated
patch, configuration and vulnerability management, as well as the ability to monitor other EPP agents,
such as Intel Security, Symantec and Microsoft.
• Trusteer Apex integration into the BigFix console provides visibility, configuration and management of the
Apex agent.
• Trusteer Apex application fingerprinting identifies known good versus unknown, but does not identify
applications performing risky tasks. Java environments are offered a lockdown mode for the execution of
nonwhitelisted Java code.

© Copyright IBM Corp. 2016 3-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• IBM BigFix Protection provides serialization of antivirus scans and caching of files based on virtual
desktop image (VDI) golden image, while Virtual Server Protection exploits VMsafe network security
APIs to provide non-agent-based virtual security.
• The security and compliance analytics Web interface can establish and monitor built-in and
administrator-created key performance metrics, and show compliance over time.
Limitations
• IBM drifted back into the Niche quadrant this year. It is not showing leadership on pushing the state of the
art in this market. As a result, although IBM is continuing to gain some market share, it is disproportionate
to the potential advantages of its brand and channel. IBM is rarely seen in final competitive bids outside
of where they have an existing, strong client relationship.
• BigFix does not offer investigation capabilities or malware sandboxing capability, although IBM has a
collection of solutions and services it calls the IBM Threat Protection System, which can aid in this
function.
• The Proventia Host-Based Intrusion Prevention Systems (HIPS) and Virtual Server Protection products
went end-of-market in April 2014. They are being supported until April 2016, but are no longer available
for new customers.
• BigFix Protection does not provide antivirus protection for Microsoft Exchange, Microsoft SharePoint,
Lotus Notes and other specialized servers.
• Although IBM has its X-Force and Trusteer security analysis teams, it is dependent on Trend Micro for its
broad signature database, personal firewall and behavioral monitoring solution, with cloudbased file and
Web reputation analysis. Disruptions affecting this critical partner could have an impact on IBM's
customers. Integration of the latest Trend Micro engine into the Tivoli Endpoint Manager (TEM) client can
take 30 days.
• IBM does not currently have an EDR offering and is still considering options. These include the possibility
of an integration of Trusteer Apex with other IBM solutions; or incorporating QRadar and BigFix; or
creating partnerships like the one between IBM Security (QRadar) and Palo Alto Networks (WildFire).
Intel Security
Intel Security (formerly McAfee) holds the second-largest EPP market share worldwide, and offers a broad
portfolio of information security solutions. Intel Security has integrated its core endpoint security components
into a common endpoint agent, Endpoint Security ENS (v 10.1). Intel Security's ePolicy Orchestrator (ePO)
policy management and reporting framework provides a platform for addressing several aspects of the
security life cycle. It continues to be the leading feature that brings and keeps clients with Intel Security. Intel
Security is a very good choice for any organization, but especially a large, global enterprise that is seeking
solid management and reporting capabilities across a number of disparate security controls.
Strengths
• Intel Security offers a broad array of protection mechanisms, including firewall, Web controls, malware
protection and HIPS, that share event data and have the ability to communicate in real time to take action
against potential threats.
• ePO provides a common administrative platform for all of Intel Security's offerings and integrates with
over 130 third-party applications. The cloud-based ePO now offers organizations the benefits of ePO with
significantly faster deployments and less complexity.
• Mature Application Control supports trusted sources of change, and integration with Intel Security's
Global Threat Intelligence (GTI) and Threat Intelligence Exchange (TIE) provides file reputation services.
• Intel Security, through enterprise system management (ESM), provides countermeasure-aware analytics
capabilities from which organizations can prioritize assets to be patched, by most vulnerable and least
protected.
• Intel Security has the optional TIE and Data Exchange Layer (DXL) to exchange local object reputation
information across both network and endpoint products. TIE is also part of the new common endpoint
framework.

© Copyright IBM Corp. 2016 3-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Intel Security's Advanced Threat Defense (ATD) provides a centralized network-based sandbox for
malware inspection. Intel v. 10.1 clients can send samples to ATD for inspection via the TIE module.
• Intel Security's Management for Optimized Virtual Environments (MOVE) provides anti-malware
scanning in virtualized environments. MOVE offers agentless anti-malware scanning in VMware
environments using native vShield API integration, as well as hypervisor-neutral implementations to
support OpenStack, Microsoft Azure and VMware vSphere.
Limitations
• The most common customer complaints continue to be the effectiveness of the older multiple agent
architecture and its impact on deployment complexity and performance. The new version 10 agent
should improve the situation as roadmap items become available, but currently it does not support all
functions (such as whitelisting). Additional agents will still be necessary to get full functionality.
• The Intel Security integration framework - despite its broad set of security tools beyond Threat
Prevention, Firewall and Web Control and TIE - continues its slow evolution, with policy and context
layer integration still missing among core components.
• ePO Real Time products are being wound down in favor of McAfee Active Response, an endpoint
detection and response capability. McAfee Active Response is still relatively new and does not address
all EDR critical capabilities.
• Some Intel Security solutions require the advanced capabilities embedded in Intel-based chipsets. For
example, Deep Defender is dependent on the presence of Intel Virtualization Technology (VT), and Deep
Command is dependent on Intel vPro.
• Organizations must upgrade to the latest versions of Intel Security ePO and endpoint agent to take
advantage of detection performance and administration improvements.
Kaspersky Lab
Kaspersky Lab's global market share continues to grow rapidly, along with its brand recognition. Gartner's
Kaspersky-related inquiries show an increase over previous years. Kaspersky Lab's Completeness of Vision
score benefits from very good malware detection effectiveness as measured by test results, as well as its
virtual server support, EMM, integrated application control and vulnerability analysis, tampered by an aging
management interface. It is a good candidate as a solution for any organization.
Strengths
• The malware research team has a well-earned reputation for rapid and accurate malware detection. The
vendor offers advanced HIPS features, including an isolated virtual environment for behavior detection,
vulnerability shields, application and Windows registry integrity control, real-time inspection of code at
launch, and integrated malicious URL filtering. On PCs, the endpoint agent (Kaspersky System Watcher)
can perform a system rollback of system changes made by malware.
• Kaspersky offers an impressive array of integrated client management tools, including vulnerability
analysis, patch management and application control. Application control includes a fully categorized
application database and trusted sources of change.
• Kaspersky Security for Virtualization provides a light-agent approach combined with the use of VMware's
vShield APIs for virtual guests with a shared cache, as well as agentless intrusion prevention
systems/intrusion detection systems (IPSs/IDSs) and URL filtering using VMware Network Extensibility
(NetX) APIs. Kaspersky Endpoint Security provides life cycle maintenance for nonpersistent virtual
machines, automated installation agents to nonpersistent virtual machines, and automatic load
optimization.
• Kaspersky provides a broad range of functionality across Windows, Linux, OS X, iOS, Android and virtual
platforms, including VMware, Hyper-V and Citrix, which will appeal to organizations wishing to
consolidate vendor capabilities into one offering.
• Automatic Exploit Prevention (AEP) targets malware that leverages software vulnerabilities by reducing
the chain of vulnerability exploits, especially in well-known targets, such as Java, Flash, Adobe Reader,
browsers and office applications.

© Copyright IBM Corp. 2016 3-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Zero-day, Exploit and Targeted Attack (ZETA) Shield scans data streams for code fragments resembling
exploits in legitimate files, such as executable code in office documents or call commands typically not
used by the file type.
Limitations
• Kaspersky Lab's client management tool features (such as vulnerability and patch management) are not
replacements for broader enterprise solutions. However, they are good for the enterprise endpoint
security practitioner to validate operations, or to replace or augment SMB tools.
• While Kaspersky has begun the development of a new console slated for the Kaspersky Endpoint
Security for Business 10 SP2, due in mid-2016, the existing Microsoft Management Console (MMC) will
continue to be used in many client environments for some time to come. Small deployments can use the
cloud-based console associated with Kaspersky Small Office Security 4.
• Kaspersky does not currently offer EDR or malware sandboxing capability, but is piloting the new
Kaspersky Anti-Targeted Attack (KATA) platform, an anti-advanced persistent threat (APT)/EDR with
sandboxing capabilities, at select clients.

© Copyright IBM Corp. 2016 3-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Vendor Strengths and Limitations

(4 of 6 ) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining Vendor Strengths and Limitations

– Landesk
– Microsoft
– Panda Security

© Copyright IBM Corporation 2016

Figure 3-17. Vendor Strengths and Limitations (4 of 6 )

Landesk
Landesk provides system, security, service, asset and process management. While it has developed its own
security solutions, including firewall, vulnerability, patch and application control solutions, it also repackages
leading offerings from Lavasoft and Kaspersky Lab. Landesk appeals to clients that have a blend of
technology solutions from different vendors and wish to bring them under common management, with the
flexibility of assigning different administrative personnel to control them. The base Landesk Security Suite
includes an anti-spyware signature engine (from Lavasoft), a personal firewall, HIPS, device control and
file/folder encryption, vulnerability and configuration management, patch management, and limited network
access control (NAC) capabilities. Landesk Patch Manager includes vulnerability assessment, operating
system patching, third-party patching, distributed and remote system patching for Windows, OS X, Red Hat
Linux, SUSE Linux, and HP Unix, along with automated and advanced distribution modes.
Strengths
• Customers can use Landesk to manage Intel Security, Symantec, Sophos, Total Defense and Trend
Micro solutions, or they may choose to pay extra for Landesk Antivirus Manager, which leverages an
integrated Kaspersky Lab malware scan engine and application reputation database. Landesk can also
manage the Windows Firewall.
• Landesk expanded its Landesk One technology alliance partner program to support additional
capabilities, including endpoint encryption, application containerization, privilege management and
Security Content Automation Protocol (SCAP) compliance assessment.
• Application control capabilities enable organizations to limit untrusted applications that may not be
detected with traditional anti-malware technologies. Application control leverages the application

© Copyright IBM Corp. 2016 3-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
database, containing reputation information of over 2 billion applications to quickly identify unknown and
untrusted applications.
• Landesk can connect and assess a machine via the VMware Virtual Desk Development Kit (VDDK) to
scan and patch offline virtual machines and templates residing on VMware ESXi hypervisors.
• Automated provisioning and state management are particularly useful to easily reimage PCs in the case
of pervasive malware.
Limitations
• Landesk drifted back into the Niche quadrant this year because of lack of focus on the needs of the
security role and continued low market and mind share, despite good channel and market presence in
the IT service support management tools market. Landesk security workspace should start to help
address the needs of security operations when it is released in 2016, but will not address the emerging
EDR requirement.
• Landesk expanded its relationship with Kaspersky Lab to include both its anti-malware engine and
application reputation database. Business disruptions between Kaspersky and Landesk could have an
impact on customers.
• Not all Landesk Security Suite features are available on all managed platforms. There's no malware
support for Linux, Microsoft SharePoint, Lotus Notes and Android, or for Windows Mobile clients.
• While Landesk can discover, patch and inventory VMs, and its agent will run within a VM, it has no
specific optimization for anti-malware protection in virtualized environments.
• Landesk still does not provide either cloud or on-premises malware sandboxing in its product offering.
• While the offering is comprehensive, pricing for the Landesk Secure User Management suite is
considered to be at a premium over competing offerings.
Microsoft
Microsoft's System Center Endpoint Protection (SCEP, formerly Forefront) is intimately integrated into the
popular System Center Configuration Manager (ConfigMgr) console. Microsoft licensing often includes
SCEP, making it an attractive shortlist candidate. Gartner views SCEP as a reasonable solution for
Windows-centric organizations licensed under the Core Client Access License (Core CAL) that have already
deployed Microsoft System Center ConfigMgr, and that have additional mitigating security controls in place,
such as application control or additional HIPS protection.
Strengths
• Microsoft's malware lab benefits from a vast installation of over 1 billion consumer endpoint versions of
the SCEP engine and its online system check utilities, which provide a petri dish of common malware
samples. A dedicated enterprise-focused team monitors telemetry from enabled SCEP, Forefront
Endpoint Protection (FEP) and Microsoft Intune endpoint clients for enterprise specific low-prevalence
malware.
• SCEP relies on the software distribution capability of System Center Configuration Manager for
deployment and updates. Existing System Center ConfigMgr shops only need to deploy the SCEP agent.
System Center ConfigMgr supports a dedicated endpoint protection role configuration. SCEP also allows
on-demand signature updates from the cloud for suspicious files and previously unknown malware.
• Microsoft Intune is a lightweight management solution that can manage the deployment of endpoint
protection clients, and manage security policies and patch management for non-domain joined Windows
PCs. Intune can also manage and enforce security policies for Windows RT, Windows Phone, Android or
Apple iOS devices, and integrate with ConfigMgr.
• Organizations that are licensed under Microsoft's Enterprise Client Access License (CAL) or Core CAL
programs receive SCEP at no additional cost, leading many organizations to consider Microsoft as a
"good enough" way to reduce EPP budget expenses.
• Microsoft offers advanced system file cleaning, which replaces infected system files with clean versions
from a trusted Microsoft cloud.

© Copyright IBM Corp. 2016 3-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Microsoft's Enhanced Mitigation Experience Toolkit (EMET) provides supplemental memory and OS
protection for all Windows systems. It is offered to all Windows users, independent of SCEP.
• Microsoft introduced several new security features in Windows 10, including a new anti-malware scan
interface (AMSI), PowerShell logging and device guard, App Locker, and enterprise data protection
(EDP), which are now managed as part of Microsoft Intune and System Center Configuration Manager.
Limitations
• Microsoft SCEP continues to rely heavily on signature-based detection methods. Test results (such as
AV-Test and AV-Comparatives) of the effectiveness of SCEP remain very low when compared with
industry averages. Microsoft is focused on reducing the impact of prevalent malware in the Windows
installed base, with very low false-positive rates. It does not focus exclusively on rare or targeted threats,
the impact of which minimal to the entire Microsoft ecosystem.
• SCEP still lacks numerous capabilities that are common in other security solutions, including advanced
device control, network-based sandbox and application control. Windows features such as Firewall,
BitLocker, and AppLocker are not as full-featured as comparable solutions from leading vendors, and the
management of these components is not integrated into a single policy and reporting interface.
• While Microsoft supports anti-malware product updates independently, it delivers its most important
security improvements in the OS. While every Microsoft customer benefits when the OS is more secure,
including those that use alternative EPP solutions, most enterprises cannot upgrade OSs as fast as EPP
versions.
• Despite the integration with system and configuration management, SCEP does not provide a security
state assessment that combines the various security indicators into a single prioritized task list or score.
• SCEP also does not provide preconfigured forensic investigation or malware detection capabilities.
SCEP provides support for virtual environments by enabling the randomization of signature updates and
scans, and by offline scanning. It does not integrate with VMware's vShield or provide similar agentless
solutions for Microsoft's Hyper-V environments.
• Intune EMM comes at an additional cost.
Panda Security
Panda Security is rapidly advancing the state of the art in cloud-based EPP, with numerous advanced
features that provide customers with tools for all stages of the security life cycle. Panda is the first EPP
vendor to deliver a full process inventory attestation service. As a result, it can advise customers of the
providence and reputation of all executed files. This is a significant innovation versus traditional malware
detection services. It offers EPP, email, Web gateways and PC management capabilities - all delivered within
a cloud-based management console. SMBs that are seeking easy-to-manage cloudbased solutions should
consider Panda as a good shortlist entry in supported geographies (primarily Spain, Germany, Sweden,
Portugal, the Benelux countries [Belgium, the Netherlands and Luxembourg] and North America).
Strengths
• Panda's Adaptive Defense product provides a good blend of endpoint protection, endpoint detection and
response, and adaptive defense capabilities for Windows, OS X, Linux and Android at an aggressive
price point that will have strong appeal to SMBs. Over 85% of deployed seats are managed via the cloud
infrastructure, with the remainder planned to be migrated in 2016.
• The automated classification process for executables has been optimized for better performance and
real-time visibility.
• Indicators of compromise (IOC) protection supports API for third parties to pull IOCs from Panda
Collective Intelligence, along with support for endpoints protected by Panda Adaptive Defense to pull
IOCs detected by other solutions via API.
• Managed whitelisting is available for embedded systems, including point-of-sale and ATMs.
• Panda Advanced Defense provides a service for the classification of all running executable files. This
service is an intelligent blend of application control and traditional malware-based analysis to provide a
high degree of confidence that no malware has been missed.

© Copyright IBM Corp. 2016 3-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Panda's traditional malware detection includes several proactive HIPS techniques, including
policy-based rules, vulnerability shielding ant exploit protection against commonly attacked software
(such as Java) and behaviour based detections. Trusted Boot ensures that all boot elements are
trustable on restart, and administrators have granular control to modify policies or add exclusions. Panda
uses a cloud database lookup to detect the latest threats.
• The cloud-based management interface provides granular role based management and group-level
configurations - but, at the same time, simple and frequent tasks are easy to perform. Status updates for
problem resolutions are effectively summarized on the main screen. The solution provides an
easy-to-use report scheduler that delivers reports in PDF. A large selection of template policies is
provided, as well as many standard reports.
• Panda's pricing is very competitive, and there are no upfront license costs - only an annual subscription.
Limitations
• The Spain-based vendor continues to slowly expand beyond its EMEA presence into Latin America and
the U.S., with APAC adoption remaining very low. Even with this growth, more than 60% of its business
remains in Europe. Mind share is still weak in other geographies.
• While Panda is focusing on growing its enterprise business, which accounts for 60% of its revenue,
nearly 70% of seats are still in the hands of consumers.
• Although Panda has several large customers, the cloud-based solutions are primarily designed for SMBs
that favor ease of use over depth of functionality, with the significant majority of enterprise sales to
sub-500 seat deployments.
• Even though the scan process is run with low priority, and users can delay scanning if they are
authorized, the solution only offers one option to minimize the impact of a scheduled scanning (CPU load
limitation).
• The vendor is more focused on the endpoint than the server. Panda does not have any specific
optimization or integration for virtualization platforms or for Microsoft SharePoint.

© Copyright IBM Corp. 2016 3-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Vendor Strengths and Limitations

(5 of 6 ) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining Vendor Strengths and Limitations

– Qihoo 360
– SentinelOne
– Sophos

© Copyright IBM Corporation 2016

Figure 3-18. Vendor Strengths and Limitations (5 of 6 )

Qihoo 360
Qihoo 360 offers the most popular consumer anti-malware in China, with more than 500 million users. It has
recently started to branch out into the enterprise EPP market in China, with global expansion plans. Qihoo is
good shortlist candidate for the Chinese market.
Strengths
• Qihoo has a massive installed base of over 700 million endpoints and mobile devices, which provides
over 9 billion samples for data mining to automatically and manually create signatures, and to monitor the
spread of viruses and malware. It also offers vulnerability detection and patch management for Microsoft
and third-party product patches, and provides a basic application control option delivered via an
app-store-type "software manager" product module.
• System reinforcement capabilities add additional controls to monitor password complexity, shared
folders, registry lists and account permissions, including audit to trace activity, detect illegal internally and
externally initiated connections, and prevent access to peripherals.
• Qihoo uses peer-to peer technology to upgrade software, signature files and patches to save network
bandwidth.
• 360 Safeguard Enterprise for SMBs is a free, cloud-managed EPP offering for very small organizations
(fewer than 200 seats).
• 360 SkyKey provides EMM solutions, including an antivirus engine for Android.
• 360 XP Shield Enterprise Edition provides specific protection for Windows XP platforms.

© Copyright IBM Corp. 2016 3-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Qihoo offers a managed public cloud solution.
Limitations
• Qihoo 360 has a dominant consumer market share in China, but it has no presence in enterprises within
Europe or the Americas, so not a viable option when thinking globally.
• While Qihoo 360 is growing its SMB and enterprise sales, less than 0.1% of total seats deployed are
SMB or enterprise seats at this time.
• The management interface is in Chinese, and does not provide native English support. It requires
localization via the Web browser, which is not effective.
• Malware protection methods are based on rapid sample collection and signature distribution, rather than
advanced techniques for detection malicious programs. A lack of global sample collection methods will
hinder effectiveness at detecting regional threats.
• Qihoo leverages the Bitdefender Antivirus engine; disruptions in this relationship can affect results.
• Qihoo's enterprise product is still relatively immature. Reference customers had a long list of needed
improvements, including hierarchical policy management, improved reporting, more streamlined
installation packages, firewall features and more granular policy controls. Qihoo has made some
progress in addressing these issues.
• All product modules are not integrated into a common management console, making it more complex to
administer.
• Qihoo 360 enterprise security customers are only in China. The Qihoo 360 enterprise security team
supports large customers directly. Smaller organizations are only supported by a valueadded reseller.
SentinelOne
SentinelOne is a rapidly growing startup developed to reinvent endpoint protection. The company focuses on
behavior-based detection techniques, augmented by a cloud database of threat intelligence. SentinelOne is
the only vendor in this analysis that includes full EDR-type functionality in the core platform. SentinelOne is a
good prospect to replace or augment existing EPP solutions for any company looking for a fresh approach
and integrated EDR, and that is willing to work with an emerging Visionary company.
Strengths
• SentinelOne offers on-device dynamic behavioral analysis to detect zero-day threats and APTs and
prevent exploitation. The solution performs well in AV tests without relying on traditional signatures, IOCs
or whitelisting.
• The management console, including full EDR event recording, can be deployed as cloud-based or
on-premises, easing installation and scalability.
• Automated mitigation capabilities can kill processes and quarantine threats to minimize the impact of
destructive threats, and provides a malware removal and remediation feature capable of rolling back
changes made by malware, based on recorded behavior.
• SentinelOne offers complete endpoint visibility (Windows and Mac) for full investigative information in
real time, and an API to integrate in any common-format, IOC-based threat feed.
Limitations
• Extended EPP functionality is missing, such as personal firewalls, URL filtering, port protection, data
protection, mobile device protection, enterprise mobility management, vulnerability analysis and
application control. Application and device control, IP/URL reputation and filtering are planned for 2016.
• SentinelOne is a rapidly growing startup and is likely to suffer from at least some growing pains. It has
limited global presence, with most customers in North America and central EU.
• SentinelOne participated in an AVtest.org test on Windows 8 and OS X in June 2015 and did well, but it
has not been extensively tested for effectiveness against other vendors. Malware authors develop
evasions for more popular anti-malware approaches. As SentinelOne becomes more popular, its
approach will come under more scrutiny from attackers.

© Copyright IBM Corp. 2016 3-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Support for Linux, virtual servers, Exchange and other specialized servers is lacking. Linux and Android
under contemplative stage.
Sophos
Sophos is one of a few companies in this Magic Quadrant that sell exclusively to business markets. It makes
available free versions of its offerings to consumers. Sophos has expanded into the mid-market network
security market, and in 2015 delivered the first release of a consolidated network and endpoint security
solution that offers a unified, context-aware approach to threat prevention, detection and response. Sophos is
good fit for buyers that value simplified administration, and for organizations that are interested in a unified
endpoint and network approach to security.
Strengths
• The Sophos Synchronized Security approach establishes a Security Heartbeat between endpoints and
perimeter next-generation firewall (NGFW) to exchange contextual information on the overall security
status, the health of endpoints and current threats. Synchronized Security triggers actions to address
potential threats in real time.
• The user threat quotient and application risk index provide insight into the level of risk associated with
users and applications, based on history and other metrics.
• Sophos' management interface is, by design, very easy to use and highly capable out of the box, without
the need for excessive fine-tuning. It provides consolidated management of endpoint protection and
encryption for Windows, Mac and Linux, as well as mobile device protection. Sophos Cloud, which
includes endpoint protection (for Windows and Mac), mobile device management and Web content
filtering, is an alternative. Integration provides user-based policies that work across devices and
platforms.
• New pre-packaged reporting capabilities provide better insight into day-to-day security operations, which
will have broad appeal for the mid-market.
• Sophos optimizes the scanning or rescanning of high reputation files by leveraging smart behavior
detection from the exploit engine to trigger scanning when suspicious activities are identified.
• Sophos' Mobile Control for mobile data protection is a strong product capability set.
• Malicious Traffic Detection, crowdsourced reputation, exploit detection engine and Sophos Security
Heartbeat enhance traditional signature, heuristic, behavioral and whitelisting techniques to enhance
detection.
Limitations
• Sophos' innovative marketing campaigns have driven up awareness of the brand in specific targeted
markets. However, traction remains focused on the mid-market.
• The simplicity of Sophos' management console, which Sophos developed for the mid-market, becomes a
liability in larger enterprises that need more granular control and reporting. The security state
assessment capabilities are buried and should be moved to the main dashboard. The cloud management
interface is still maturing, and does not include all product or all capabilities of the on-premises
management server.
• Performance test scores for Sophos remain in the middle of the pack.
• The movement to a full cloud-managed, network-to-endpoint security platform is promising, but it is still a
work in progress, and not all components are fully integrated.
Symantec
In October 2014, Symantec announced a strategy to reinvigorate company growth by splitting the information
management business unit and the security products groups into separate companies. Symantec's
Completeness of Vision score is affected by the limited capabilities of its application control, the just
introduced malware sandboxing, vulnerability analysis and forensic investigation. Its Ability to Execute score
is impacted by three years of corporate strategy adjustments, resulting in a slower growth rate moderated by
the fact that Symantec is still the market share leader. Symantec remains a good tactical choice for solid
anti-malware endpoint protection.

© Copyright IBM Corp. 2016 3-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Strengths
• Symantec Endpoint Protection (SEP) 12 has an extensive set of layered defense capabilities, such as
Symantec Online Network for Advanced Response (SONAR), Symantec Insight and its network protect
technologies, which go beyond traditional signatures for protection from advanced targeted attacks. Most
recent improvements were in components of SONAR. Symantec also integrated an advanced repair tool,
Norton Power Eraser, into the Symantec Endpoint Protection client.
• Symantec continues to be listed as the top overall competitive threat by vendors reviewed in this Magic
Quadrant.
• Symantec's Security Technology and Response (STAR) technology allows evidence of compromise
(EOC) scanning on the endpoint via SEP and is used by Symantec Managed Security Services and
Symantec ATP.
• Cynic is a cloud-based sandboxing platform that provides bare-metal hardware and network sandboxing
analysis of objects submitted by Advanced Threat Protection (ATP), Endpoint Protection and email.
Results are passed to ATP for remediation.
• Application control offers one-click lockdown via a whitelist or blacklist of applications.
• Synapse integrates, correlates and prioritizes SEP, email security, cloud and ATP information.
• Symantec Data Center Security leverages VMware's vShield APIs and NSX to offer "agentless" antivirus
and reputation security features on a VMware ESX hypervisor. On other platforms, such as Hyper-V or
Kernel-based Virtual Machine (KVM), SEP provides input/output (I/O)-sensitive scan, virtual image
exception and file cache, offline image scanner, and randomized scanning.
• Symantec's new Advanced Threat Protection will combine network-based object and traffic scanning with
existing SEP clients to provide EDR functionality without the need for existing customers to deploy new
client agents.
Limitations
• Symantec has been in a nearly continuous rebuilding mode since 2012, with few customer benefits to
show for its efforts. In the longer term, it is easy to imagine that a more focused security company may be
better for security customers; however, in the short term, it has more significant potential for disruptions.
Moreover, real product improvements will only result from a durable corporate strategy, regardless of the
company size. Strong competition from vendors in this market and client concerns over the long-term
direction of the organization are beginning to show signs of strain with renewals.
• Symantec's security product portfolio is not integrated at a meaningful level, and requires five distinct
consoles to manage the complete endpoint solution set.
• The OS X offering only includes AV and IPS.
• Although Symantec has mobile management and protection capabilities and advanced data protection
capabilities, they are not integrated into the SEP management console.
• Removable media encryption requires adhering to a confusing set of policies across Symantec's
encryption products and using SEP 12's device control functionality.

© Copyright IBM Corp. 2016 3-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Vendor Strengths and Limitations

(6 of 6 ) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining Vendor Strengths and Limitations

– Trend Micro
– Webroot

© Copyright IBM Corporation 2016

Figure 3-19. Vendor Strengths and Limitations (6 of 6 )

Trend Micro
Trend Micro is the third-largest enterprise EPP vendor, with a large worldwide installed base. Trend Micro has
made significant visionary investments in the areas of application control, vulnerability detection and
shielding, malware sandboxing, and EDR, and continues to lead the market in addressing the specific needs
of the data center. It also offers very tightly integrated EMM capabilities, including mobile app reputation
service and data protection capabilities. The Smart Protection Suite offers one of the most complete,
integrated packaging of protection technologies in this market. Trend Micro is a very good shortlist candidate
for all types of buyers.
Strengths
• OfficeScan provides a range of malware protection options, including malicious URL filtering, critical
resource and process protection, browser-exploit protection, vulnerability detection and shielding, and
behavioral monitoring. Trend Micro has also invested in leading-edge security solutions, including a
malware sandbox, application control and an incident response investigation tool.
• Deep Security and its "agentless" anti-malware scanning, intrusion prevention and file integrity
monitoring capabilities for VMware have benefited greatly from Trend Micro's close relationship with
VMware. Further, Deep Security has been optimized to support the protection of multitenant
environments and cloud-based workloads, such as Amazon Web Services and Microsoft Azure.
Additional capabilities include encrypting these workloads with its SecureCloud offering and an optional
SaaS version of its Deep Security management console.
• Trend Micro is the first of the established EPP vendors to deliver an EDR solution. The Endpoint Sensor
records endpoint activity, and is used to aid investigation of alerts generated by the Network Monitor, or

© Copyright IBM Corp. 2016 3-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
for malware hunting activity based on a suspicious object, OpenIOC or Yara rules. The Endpoint Sensor
EDR tool has an excellent graphical representation of the threat event chain.
• Deep Discovery Analyzer, Trend Micro's network-based malware detection sandbox, can be centralized
to receive files from Trend Micro Web gateway and email security products. Trend Micro also offers
sandboxing as part of its Cloud App Security offering for Office 365. It received top scores from NSS Labs
in a breach detection sandbox test.
• Trend Micro Control Manager provides security dashboards to give the administrators quick visibility of
users and endpoints with multiple points of view to accomplish investigative tasks.
• Trend Micro Endpoint Application Control is very complete and includes support for self-updating
applications and software deployment tools as trusted sources, as well as out-of-the-box inventory
reports.
• Trend Micro integrates mobile device management capabilities in Trend Micro Control Manager, with
support for Android, iOS, Windows Phone, and BlackBerry.
Limitations
• Trend Micro has not brought the "agentless" anti-malware scanning capabilities to OfficeScan; rather, it
has left customers that want to do this for VDI to adopt Deep Security for hosted virtual desktop
protection. OfficeScan and Deep Security are two separate products from separate teams with separate
consoles, although both report up to the Trend Micro Control Manager for reporting.
• The unifying Control Manager interface is suitable for high level reporting but insufficient for
managing individual products. Native consoles for Trend Micro Endpoint Encryption and Application
Control must still be deployed to enable day-to-day management within Trend Micro Control Manager.
The individual consoles are still required to updating policies and sending tasks to their agents.
• Application control, encryption, DLP and device control do not extend to all OS platforms.
• The Endpoint Sensor stores history locally on the agent, rather than a central database.
• There is no detection capability outside of the network sensor alerts. Remediation and containment
actions are based on the OfficeScan client, and are limited to isolating an endpoint using firewall policy,
quarantine and block process execution.
• Policy-level integration of the various Trend Micro products is still emerging. For example, the application
control agent cannot automatically send unknown files to the Deep Discovery Analyzer sandbox for
analysis.
• Reference customers have commented on the size of Service Pack updates and their effect on the
network.
Webroot
Webroot SecureAnywhere Business Endpoint Protection takes a behaviour based approach that uses cloud
databases to keep its EPP client small and fast. The cloud lookup classifies all files as good, bad or unknown,
providing a higher degree of confidence in detection accuracy. Webroot SecureAnywhere is a reasonable
shortlist inclusion for organizations in supported geographies that are seeking a lightweight, behavior and
cloud-based approach to malware detection. It can also be a good additional tool for highsecurity
organizations.
Strengths
• Webroot SecureAnywhere is one of the few products to focus primarily on behavioral rules to identify
threats. Webroot SecureAnywhere works by monitoring all new or highly changed files or processes, and
checks file metadata and behavior against the cloud database of known files and behaviors. The cloud
lookup results in a very small and fast EPP client. Webroot is the only vendor in this analysis that reports
on malware dwell time.
• By journaling changes undertaken by unknown files, Webroot provides rapid remediation once malware
behavior is detected. Consequently, remediation of ransomware, such as CryptoLocker, is possible by
restoring data files from journaled versions, even if the initial infection evades detection.

© Copyright IBM Corp. 2016 3-51

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Webroot SecureAnywhere provides a remote management tool, built-in application process monitoring, a
change log and rollback functionality to ease remediation. It also features remote application
management controls using its override function, as well as a built-in identity and privacy shield to
minimize the loss of sensitive data from unknown malware.
• Both the endpoint security consoles and the new Global Site Manager management consoles are
cloud-based, with no on-premises server requirement.
• Administrators can build policies around the actions to be taken on files introduced onto the endpoint,
including those via USB or CD/DVD.
• The vendor also offers security and basic EMM capability, including a mobile app reputation service for
Android and iOS devices from within the same management console.
• Webroot again received the highest satisfaction scores from reference customers that were contacted for
this Magic Quadrant.
Limitations
• Due to Webroot's emphasis on a behaviour based malware detection approach, existing malware testing
does not accurately reflect capabilities, making it hard to compare efficacy to other solutions.
• SecureAnywhere is primarily an anti-malware utility. It does not provide port/device control, or endpoint
management utilities, such as vulnerability or patch management.
• SecureAnywhere provides a basic malware event investigation capability.
• Webroot does not protect the workload of specialized servers, such as Microsoft Exchange and Microsoft
SharePoint.

© Copyright IBM Corp. 2016 3-52

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Case Study 1: Palo Alto Networks IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Let’s solve the case study on Palo Alto Networks

– Challenge
– Solution
– Results
– Summary
– Putting an End to Endpoint Attacks
– Cybersecurity from End to End
– Seeing Is Believing
– Uniform Control and Prevention
– Secure Infrastructure Means Secure Business

© Copyright IBM Corporation 2016

Figure 3-20. Case Study 1: Palo Alto Networks

Case Study 1: Palo Alto Networks

CAME Group operates in 118 countries through 480 branches and licensed dealers. Operating under the Bpt,
Urbaco, Parkare and GO brands, CAME Group is a key global player in the home automation, urban planning
and high-security sectors, for which it offers integrated solutions for regulating and monitoring people flows
and access points. Approximately 70 percent of CAME Group’s business is global. It is a company that is
extremely proud of its Italian heritage and employs over 1,500 staff with sales around €250 million in 2015.
Challenge
Protect endpoints from targeted cyberattacks, such as CryptoLocker, to eliminate business disruption and
unpredictable remediation costs, as well as enable enterprise-wide network security with uniform policies that
eliminate security vulnerabilities and unauthorized traffic impacting application performance and employee
productivity.
Solution
Palo Alto Networks® Next-Generation Security Platform deployed in the central data center and 50 branch
offices, providing increased visibility and control of network traffic and automatically preventing cyberthreats
from infiltrating endpoint devices or the enterprise network.
Results
• Saved approximately $2.5 million over three years through security consolidation
• Avoided $250,000 in endpoint remediation costs over three years
• Prevented cyberthreats from infiltrating network and endpoints automatically

© Copyright IBM Corp. 2016 3-53

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
• Improved bandwidth and application performance with
• increased visibility and control of network traffic
• Ensured uniform security policy implementation and enforcement enterprise-wide
Summary
CAME Group (CAME) provides automation systems for residential and industrial entrances, parking lots, and
access control points. With 50 branches in 40 countries all networked with its corporate headquarters in Italy,
CAME was uniquely challenged to provide a network architecture that ensured both secure network access
and secure endpoints. Targeted attacks by malware, such as CryptoLocker, were frequently infiltrating
servers and PCs, disrupting productivity and creating unpredictable remediation costs. Traditional antivirus
software was ineffective in stopping such attacks. By deploying the Palo Alto Networks Next-Generation
Security Platform with Next-Generation Firewalls, Threat Intelligence Cloud services, and Advanced
Endpoint Protection, CAME successfully prevents cyberthreats from infiltrating endpoint devices and its
network. Through consolidation, CAME is saving $2.5 million over three years, with an additional $250,000 in
savings by eliminating remediation costs on endpoint devices. Moreover, the company now has uniform
security policies enterprise-wide, with increased visibility and control over network traffic for improved
bandwidth and application performance.
Putting an End to Endpoint Attacks
With business operations in 118 countries, CAME Group relies on a global network to connect employees,
customers and partners 24/7 year-round – whether they’re at a desktop in one of the company’s 50 branch
offices or connecting remotely while traveling. However, every time a user logs in to the corporate CRM
application, shares a file via email, uses Skype with a customer, or conducts any form of communication and
collaboration online, they are exposed to potential cyberthreats.
Even with the best network security in the world, all of CAME’s endpoints were still vulnerable to targeted
attacks by sophisticated exploits, as well as inadvertent downloading and sharing of malicious executable
files. Like many companies, CAME traditionally relied on antivirus solutions to protect its endpoint devices.
But signature-based antivirus systems are no match for today’s advanced, quickly evolving threats and
zero-day attacks.
In fact, CAME frequently experienced such attacks, many of which were nearly impossible to detect until
serious damage was inflicted. Among the worst was CryptoLocker, which required a huge investment in time
and money to eradicate – plus the added expense to recover lost data. With the number of malicious attacks
constantly rising, the cost of remediation was unpredictable and wreaked havoc on CAME’s IT budget.
Mr. X, Group CIO at CAME, explained the company’s strategy to address the situation: “We approached the
issue by first considering how advanced threats could compromise our endpoints and then identifying a way
to prevent them from getting in.”
CAME determined that, fundamentally, all users were vulnerable when connected to the Internet. Another
problem was inadvertent exposure through removable media such as USB drives. With numerous employees
traveling from one part of the world to another, CAME needed a consistent way to protect end-user devices
regardless of where or how they were connecting.
CAME looked for complete execution control for all computers in the company, with visibility to see where and
when attacks were occurring and validation that those attacks were successfully blocked. They considered
solutions from Trend Micro and Intel Security’s McAfee line, but the company ultimately chose Palo Alto
Networks Traps Advanced Endpoint Protection to complement its existing Palo Alto Networks security
technologies and platform. According to Mr. X, they chose Traps because, unlike other approaches, it can
reliably prevent exploits and malware – known and unknown – across all our endpoints, no matter where in
the world they are used.
Cybersecurity from End to End
CAME deployed Traps as part of a comprehensive cybersecurity strategy built on the Palo Alto Networks
Next-Generation Security Platform, which consists of Next-Generation Firewalls, Threat Intelligence Cloud
services, and Advanced Endpoint Protection. The platform delivers application, user and content visibility and
control, as well as protection against known and unknown cyberthreats.

© Copyright IBM Corp. 2016 3-54

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Working with its trusted IT partner, NGS srl, CAME has deployed Traps to approximately 1,000 servers, PCs
and laptops, with plans to protect more than 1,600 endpoint devices when fully rolled-out. In addition to Traps
Advanced Endpoint Protection, CAME deployed four Palo Alto Networks PA-3020 next-generation firewalls in
its headquarters facility to protect production data center operations. Another 40 PA-200 and 10 PA-500
next-generation firewalls were deployed in branch offices with redundant and secure virtual private network
(VPN) connections enabled for remote users. All of the Palo Alto Networks next-generation firewalls are
configured with Threat Prevention and URL Filtering (PAN-DB). Palo Alto Networks Panorama provides
centralized management for device configurations, uniform policy enforcement, and reporting across the
entire secure network.
CAME also implemented Palo Alto Networks WildFire, which provides threat intelligence cloud services.
WildFire proactively identifies and blocks the most advanced known and unknown cyberthreats, leveraging
central intelligence capabilities and automatic delivery of preventive security measures. The integration of
WildFire and Traps proved especially important to CAME.
Traps was the only endpoint protection product in the market natively integrated with WildFire. This was
extremely important because it enabled them to protect against zero-day attacks. WildFire provides dynamic
analysis and continuous updates that stop even unknown threats before they compromise an endpoint device
or our network. Other products start working only at a subsequent stage of malware activity, and this can lead
to endpoint outages.
Seeing Is Believing
After deploying Traps, CAME saw almost immediate results. In fact, in the early stages of rollout, Traps
successfully identified and prevented an attempt by CryptoLocker to attack endpoint devices at several of the
company’s branch offices.
They could see first-hand that the Advanced Endpoint Protection was working and with Traps they could see
what was going on and that malware attacks were being prevented.
Traps provides CAME with more than assurance that its endpoint devices are protected from cyberthreats. It
has also eliminated the cost of remediation, which had been a frequent and difficult-to-manage problem in the
past.
When CAME was attacked by CryptoLocker in the past, they not only had the cost to get back thier data but
also the cost for the time and resources required by the organization. All those costs were eliminated by
having Traps in place. As a result, they saved a lumpsum in the coming years
This savings is on top of even greater cost reductions that CAME realized from deploying the complete Palo
Alto Networks Next-Generation Security Platform. Previously, CAME had more than 100 Cisco firewalls, each
with different capabilities.
Every branch office configured and managed its own device, many using consultants, which cost the
company $50,000 per branch per year. By consolidating its security infrastructure on the Palo Alto Networks
security platform, CAME has been able to remove devices from its network - and expensive consultants from
its payroll.
Uniform Control and Prevention
With the Palo Alto Networks Next-Generation Security Platform, including Next-Generation Firewalls, Threat
Intelligence Cloud services, and Advanced Endpoint Protection, CAME now has end-to-end protection
against cyberthreats. Thanks to improved visibility and built-in prevention capabilities, the security team can
now see all traffic on the network, get real-time information on attempted intrusions, and automatically block
unauthorized packets from infiltrating the network or any devices connected to it.
CAME’s ability to identify, control and manage applications and traffic also improved bandwidth availability
and eliminated network latency issues. Previously, rogue traffic caused connectivity problems, especially for
the call center, during the busiest times of the workday. Application availability also declined during traffic
peaks. Now those concerns are a thing of the past.
CAME prioritized traffic packets to ensure the availability and responsiveness of core applications which also
freed up more bandwidth, eliminating background noise and dropped calls that frustrated our customers and
employees.

© Copyright IBM Corp. 2016 3-55

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
What’s more, all of the traffic flowing through the Palo Alto Networks platform is logged to Panorama, which
allows CAME to perform traffic analysis, quickly investigate and respond to security incidents, and collect
audit information from a single, centralized location. This also makes it easier and more efficient for CAME to
integrate new branches.
Secure Infrastructure Means Secure Business
Ultimately, end-to-end security is essential for keeping CAME’s business running smoothly. Mr. X pointed out
that any vulnerability can allow malware to compromise an employee’s PC or hackers to breach the network
and steal proprietary company information. This can slow or stop productivity and, in the worst of
circumstances, impact revenue streams and diminish customer confidence.

© Copyright IBM Corp. 2016 3-56

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Case Study 2: Trend Micro IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Let’s solve the case study on Tread Micro

– Challenge: Security Causing Performance
– Solution: Agentless Security Drives Down CapEx and OpEx
– Effective Protection at the Hypervisor Level
– Immediate Protection in the Cloud
– Results: Business Continuity Along with Efficiency Gains

© Copyright IBM Corporation 2016

Figure 3-21. Case Study 2: Trend Micro

Case Study 2: Trend Micro

Challenge: Security Causing Performance
Hits in Virtual Environment United Way of Atlanta is one of the largest branches of the non-profit organization,
and serves 13 counties surrounding the metropolitan Atlanta area. Each year, from August through
December, the fundraising campaign increases the demands on the organization’s data center and
infrastructure. Virtualization has offered a cost-effective platform for scaling services during the busy season.
Initially, virtualization was introduced for support servers. When the benefits were proven, the organization
virtualized its production servers, too. Most of the year, the data center hosts about 80 virtual machines.
During the fundraising campaign season, that number increases, ranging from 100 to 150 virtual machines.
In addition to virtualized servers, virtual desktop infrastructure (VDI), based on VMware View, has also been
introduced at United Way of Atlanta. Virtual servers and VDI have introduced a cost-effective and flexible
model for the United Way of Atlanta’s data center. However, with the progress came the need to adjust the
security solutions in the new environment. The more they virtualized, the more they saw performance hits.
Communications would be impacted every time security updates were pushed out. It was not so severe that
users noticed, but they saw it happening and realized that their agent-based endpoint security was not going
to scale in our virtual environment.
Solution: Agentless Security Drives Down CapEx and OpEx
The IT team researched security for VMware environments. A wealth of online information and YouTube
video tutorials piqued their interest in Trend Micro Deep Security. The next step was to contact their Trend
Micro reseller, Softchoice, in Atlanta.

© Copyright IBM Corp. 2016 3-57

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
“Softchoice put me in touch with a local Trend Micro representative, and helped us in our evaluation process,”
said Mr. Y, the IT head. After the initial discussions and follow-up with a technical expert in the region, they
decided that Deep Security was the product that they wanted. A 60-day free trial was deployed.
The security team at Softchoice supported United Way’s choice of the Trend Micro solution. “We have seen
increasing numbers of medium-sized businesses turning to VDI to drive down CapEx and OpEx, especially
for remote endpoints such as kiosks,” explained Mr. Z, the Trend Micro Business Development Specialist at
Softchoice. United Way of Atlanta is a typical example - and they have had to address the typical pain points
associated with virtualization as well. Deep Security avoided the problem of simultaneous updates, and also
provides virtual patching capabilities.
After installing VMware vShield and building the foundation for hypervisor-level security, the deployment of
Deep Security was a quick process. United Way of Atlanta installed the four standard Deep Security modules:
anti-malware, web reputation, firewall, and deep packet inspection. The installation went smoothly, and the
rules were adjusted and configured to protect the organization and allow employees to get their jobs done
without putting assets at risk. Deep Security, a VMware-ready solution, has now been in place for the last
year.
Effective Protection at the Hypervisor Level
The IT team had seen the difference in the level of protection offered by Deep Security. One attack hit their
data center when a user downloaded a screensaver virus onto the organization’s main file server. Deep
Security was able to detect the attack and stop it - the virus was literally frozen in its tracks. Most viruses start
by looking for the antivirus software and disabling it. With Deep Security, there was nothing to disable. The
protection is outside of the virtual machine. Because of this, Deep Security definitely offered more protection.
When a virtual machine is attacked, Deep Security can stop it immediately and clean-up is therefore simple.
With traditional endpoint security, the attack would have taken down that server and files would have been
corrupted. They would have to go back and restore the system. With Deep Security, threats are stopped and
the bulk of the server is still viable and in use while the threat is managed.
Immediate Protection in the Cloud
Deep Security also gives United Way of Atlanta a layer of protection in the cloud. The Trend Micro™ Smart
Protection Network™ cloud-client infrastructure collects global threat intelligence to deliver proactive
protection from emerging threats.
Flexible Platform Support United Way of Atlanta is now making another change in the data center. “We are
deploying Cisco UCS server platforms,” explained Mr. Y. The Cisco hardware will further reduce thier footprint
and allow us to cut the number of hosts by half.
Results: Business Continuity Along with Efficiency Gains
By pointing United Way of Atlanta to the Trend Micro solution, Softchoice helped the organization maximize
the returns on its investments in virtualization.
Prior to deploying Deep Security, United Way of Atlanta had five VDI hosts and 10 other hosts for server
activity. With the increased efficiencies of the new agentless security deployment, the organization has been
able to remove two of the VDI hosts and four server hosts. The biggest efficiency gains have been seen on
the server hosts.
Flexibility has been another major benefit gained from virtualization, and Deep Security has proven to be well
aligned with the evolving VMware environment and Cisco servers and networks that support United Way of
Atlanta. Deep Security was
found to be a very good fit in their data center, and provided excellent protection for the virtualized servers
and desktops and the continually changing environment.
Business continuity is also very critical for United Way of Atlanta. Virtualization and Deep Security have not
only minimized risks of disruptions in their main data center, but are being used to protect their disaster
recovery (DR) facility.
Virtualization gave them the ability to handle major incidents without disrupting business. And with Deep
Security, protection for cyber threats is automatically extended to those remote servers. Even if the central

© Copyright IBM Corp. 2016 3-58

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty
Deep Security server goes offline to a power outage, the agents on each host still operate to defend the
virtual machines.
The remote United Way of Atlanta data center is also virtualized, and critical applications are replicated and
kept up to date at that site even when it is not supporting operations. With Deep Security protecting their
disaster recovery site, they were also able to operate even in the event of a major outage at the main data
center site.

© Copyright IBM Corp. 2016 3-59

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems

1. Which of the following is true for Disk Encryption?

A. Disk encryption modifies the boot sector
B. Disk encryption typically uses one key to encrypt a hard disk
C. Disk encryption protects a hard drive in the event of theft or accidental loss by encrypting the
entire disk
D. All of the above
2. How is network resiliency similar to endpoint resiliency?
A. Both facilitate network self-healing in order to minimize the management burden
B. Both ensure that health information on devices and applications is continuously gathered and
monitored
C. They more or less represent the same thing
D. They are not at all similar
3. Which attack redirects users to malicious sites owned by the attacker?
A. Nine Ball
B. Gumblar
C. Lobo
D. Deez Nuts

© Copyright IBM Corporation 2016

Figure 3-22. Checkpoint

© Copyright IBM Corp. 2016 3-60

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems

4. Which attack works by infecting a legitimate Web site first and then redirecting visiting
victim to a malicious site owned by the attacker?
A. Deez Nuts
B. Gumblar
C. RiteWay
D. None of the above
5. Which aspect of an endpoint solution secures all the endpoint communication ports and
adapters?
A. Port control
B. Wireless fecurity
C. Application control
D. Personal firewall
6. Which one of the following statements is false?
A. Bitdefender does not offer full feature parity between Windows, OS X and Linux
B. The management console Cylance is cloud based
C. Secure business solutions are targeted for SMBs seeking costeffective solutions with low
administration overhead
D. All are true

© Copyright IBM Corporation 2016

Figure 3-23. Checkpoint

© Copyright IBM Corp. 2016 3-61

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems

7. Which business driver applies to circumstances where security threats and threat agents
can affect the ability of an organization to conduct business?
A. Contractual obligation
B. Legal and regulatory compliance
C. Service-level agreements
D. IT asset value
8. Single points of failure for one or more business or management processes that are
outside the enterprise boundary are an example of
A. External threats
B. Internal threats
C. IT service management commitments
D. None of the above
9. Which business challenge makes it harder to ensure that software installations and PC
configurations are consistent?
A. Ad-hoc PC management
B. No in-house expertise
C. Lack of IT resources
D. None of the above

© Copyright IBM Corporation 2016

Figure 3-24. Checkpoint

© Copyright IBM Corp. 2016 3-62

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems

10. Which of the following statemen(s) is true about cloud services?

A. It requires little or no on-site hardware and companies usually pay for it on a per-user fee
B. Streamlined management and ease of deployment
C. Cloud security provider’s data center is much more likely to possess the latest technology, high-
end servers and fast connections
D. All of the above

© Copyright IBM Corporation 2016

Figure 3-25. Checkpoint

© Copyright IBM Corp. 2016 3-63

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 3. Endpoint Security

Uempty

Unit summary IBM ICE (Innovation Centre for Education)

IBM Power Systems

Having completed this unit, you should be able to:

• Know what are the threats that drive the need of endpoint security solutions
• Get familiar with the components with endpoint security
• Understand the challenges faced by endpoint security
• Relate the deployment of endpoint security solutions with practical scenarios

© Copyright IBM Corporation 2016

Figure 3-26. Unit summary

© Copyright IBM Corp. 2016 3-64

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Unit 4. Application Server Security

Overview
This unit imparts knowledge about application server security, types of attacks faced, and countermeasures
taken

How you will check your progress

• Checkpoint

© Copyright IBM Corp. 2016 4-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Unit objectives IBM ICE (Innovation Centre for Education)

IBM Power Systems

After completing this unit, you should be able to:

• Get acquainted with various application server threats and countermeasures
• Get an overview of general application server security overview
• Get familiar with the Oracle application server security architecture
• Understand the need of application server security

© Copyright IBM Corporation 2016

Figure 4-1. Unit objectives

© Copyright IBM Corp. 2016 4-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Application Server Security Overview IBM ICE (Innovation Centre for Education)
IBM Power Systems

© Copyright IBM Corporation 2016

Figure 4-2. Application Server Security Overview

Application Server Security Overview

An application server is a component- based product that resides in the middle-tier of a server centric
architecture. It provides middleware services for security and state maintenance, along with data access and
persistence.
Java application servers are based on the Java™ 2 Platform, Enterprise Edition (J2EE™). J2EE uses a
multi-tier distributed model. This model generally includes a Client Tier, a Middle Tier, and an EIS Tier. The
Client Tier can be one or more applications or browsers. The J2EE Platform is in the Middle Tier and consists
of a Web Server and an EJB Server. (These servers are also called "containers") There can be additional
sub-tiers in the middle tier. Enterprise Information System (EIS) tier has the existing applications, files, and
databases. For the storage of business data, the J2EE platform requires a database that is accessible
through the JDBC, SQLJ, or JDO API. The database may be accessible from web components, enterprise
beans, and application client components. The database need not be accessible from applets.
Security is a system issue, not a single-product issue. Each component of system application affects the
security of the entire system. Proper security requires careful configuration of all system components,
including the following third-party components:
• Web Browsers
• Firewalls
• Load Balancers
• Virtual Private Networks (VPNs)

© Copyright IBM Corp. 2016 4-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
Web Browsers: In the overall system security picture, the Web browser is the component over which
e-business sites have least control. When running a Web storefront, for example, you may not be able to
control the browser that customers use. The customer’s browser nonetheless impacts the security of your
system, and must be taken into consideration. To securely implement Web transactions, your application
must support specific communications and security technologies, including HTTP, LDAP, SSL, x.509
certificates, and Java.
Most commercially available Web browsers support several of these security-related features. However,
users must configure the browser properly to take advantage of its security capabilities.
By default, information sent to and from a Web browser is transmitted in the clear; any intermediate site can
read the data and potentially alter it in midstream. Web browsers and servers partially address this problem
by using the Secure Sockets
Layer to encrypt HTTP transmissions (referred to as HTTP/SSL or HTTPS). This ensures the security of data
transmitted between the client to the server. However, because commercially available Web browsers do not
ship with client certificates, most HTTP/SSL transmissions are authenticated in only one direction, from
server to client; the client does not authenticate itself to the server.
Because the HTTP protocol does not support sessions, many e-commerce applications use cookies to store
session data for individual customers. These cookies are transmitted as cleartext; this means that they can
be intercepted by a third party. For this reason, it is wise for the application to encrypt or obfuscate
information that is stored in cookies, even when using HTTPS.
Firewalls: Firewalls control access between the full Internet and a corporation’s internal network. A firewall
defines which sorts of Internet communications will be permitted into the corporate network, and which will be
blocked. A well-designed firewall can foil many common Internet-based security attacks. However, a firewall
is only as secure as its maintenance. New Internet-based attacks are constantly being designed, and firewall
configurations must constantly be updated to keep abreast of these attacks.
Firewalls monitor communications methods, not communications content. Therefore, firewalls cannot protect
applications against misuse of permitted communications channels. For instance, to permit the use of the
Web, a firewall must permit HTTP communication. Because firewalls do not monitor content, a firewall cannot
protect against security attacks transmitted within valid HTTP messages. Similarly, because a firewall does
not monitor the content of e-mail messages, it cannot prevent the transmission of e-mail viruses.
Load Balancers: Load balancing distributes an application’s load over many identically configured servers.
This distribution ensures consistent application availability, even when one or more server fails. Load
balancing has a significant impact on security design, especially on encryption issues. For instance, in many
installations, SSL keys are unique to a particular server in a cluster, and are not necessarily shared with other
servers. This sharing complicates moving an SSL session from one server to another.
Virtual Private Networks (VPNs)
A Virtual Private Network (VPN) allows applications to use the public Internet to communicate securely with
the corporate LAN. All IP communications between the application and the corporate LAN are encrypted so
that they cannot be read or altered by intermediate sites. A VPN prevents a third party from monitoring or
altering communications. Like other network-based security solutions, VPNs cannot prevent the transmission
of viruses, nor can they control the content of the information being transmitted.

© Copyright IBM Corp. 2016 4-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

SSL Keys and Certificates IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Introduction to SSL Keys and Certificates

– Steps to negotiated SSL session

© Copyright IBM Corporation 2016

Figure 4-3. SSL Keys and Certificates

SSL Keys and Certificates

The Secure Socket Layer provides secure communications over intranets and the Internet. This section
discusses the basic concepts underlying SSL implementations.
In SSL communication between two entities, such as companies or individuals, the server has a public key
and an associated private key. Each key is a number, with the private key of an entity being kept secret by
that entity, and the public key of an entity being publicized to any other parties with which secure
communication might be necessary. The security of the data exchanged is guaranteed by keeping the private
key secret, and by the complex encryption algorithm. This system is known as asymmetric encryption,
because the key used to encrypt data is not the same as the key used to decrypt data.
Asymmetric encryption has a performance cost due to its complexity. A much faster system is symmetric
encryption, where the same key is used to encrypt and decrypt data. But the weakness of symmetric
encryption is that the same key has to be known by both parties, and if anyone intercepts the exchange of the
key, then the communication becomes insecure.
SSL uses both asymmetric and symmetric encryption to communicate. An asymmetric key (PKI public key) is
used to encode a symmetric encryption key (the bulk encryption key); the bulk encryption key is then used to
encrypt subsequent communication. After both sides agree on the bulk encryption key, faster communication
is possible without losing security and reliability.
When an SSL session is negotiated, the following steps take place:
• The server sends the client its public key.
• The client creates a bulk encryption key, often a 128 bit RC4 key, using a specified encryption suite.

© Copyright IBM Corp. 2016 4-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
• The client encrypts the bulk key with the server's public key, and sends the encrypted bulk key to the
server.
• The server decrypts the bulk encryption key using the server’s private key.
• This set of operations is called key exchange. After key exchange has taken place, the client and the
server use the bulk encryption key to encrypt all exchanged data.

© Copyright IBM Corp. 2016 4-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Need of Security IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Application Server Threats and Countermeasures

– Network Eavesdropping
– Unauthorized Access
– Viruses, Worms, and Trojan Horses

© Copyright IBM Corporation 2016

Figure 4-4. Need of Security

Application Server Threats and Countermeasures

Network Eavesdropping
Attackers with network monitoring software can intercept data flowing from the Web server to the application
server and from the application server to downstream systems and database servers. The attacker can view
and potentially modify this data.
Vulnerabilities
• Vulnerabilities that can make your application server vulnerable to network eavesdropping include:
• Sensitive data transmitted in clear text by the application
• Use of SQL Server authentication to the database, resulting in clear text credentials
• Lack of transport or application layer encryption
• Insecure network-hardware administrative interfaces
• Use of the .NET Remoting TCP Channel to remote components
Attacks
The attacker places packet-sniffing tools on the network to capture traffic.
Countermeasures
• Countermeasures to prevent packet sniffing include the following:

© Copyright IBM Corp. 2016 4-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
• Use secure authentication, such as Windows authentication, that does not send passwords over the
network.
• Encrypt SQL Server authentication credentials. If SQL Server authentication is being used, you can
encrypt credentials automatically by installing a server certificate on the database server.
• Secure communication channels. Options include using Secure Sockets Layer (SSL) or Internet Protocol
Security (IPSec).
• Use remote procedure call (RPC) encryption with Enterprise Services applications.
• Use a segmented network, which can isolate eavesdropping to compromised segments.
• Use the HttpChannel and SSL with .NET Remoting.
Unauthorized Access
If the ports used by applications that run on the application server at the perimeter firewall cannot be blocked,
an external attacker can communicate directly with the application server. If computers other than the
front-end Web servers are allowed to connect to the application server, the attack profile for the application
server increases.
Vulnerabilities
• Vulnerabilities that can result in unauthorized access include:
• Weak perimeter network and firewall configurations
• Superfluous ports open on the internal firewall
• Lack of IPSec policies to restrict host connectivity
• Unnecessary active services
• Unnecessary protocols
• Weak account and password policies
Attacks
• Common attacks to gain unauthorized access include:
• Port scanning that detects listening services
• Banner grabbing that gives away available services and possibly software versions
• Malicious application input
• Password attacks against default accounts with weak passwords
Countermeasures
• Countermeasures to prevent unauthorized access include:
• Firewall policies that block all traffic except expected communication ports
• TCP/IP filtering or IPSec policies to prevent unauthorized hosts from establishing connections
• Disabling unused services
• Static DCOM endpoint mapping that allows access only to authorized hosts
Viruses, Worms, and Trojan Horses
These attacks are often not noticed until they begin to consume system resources, which slows down or halts
the execution of other applications. Application servers that host IIS are susceptible to IIS attacks.
Vulnerabilities
• Unpatched servers
• Running unnecessary services
• Unnecessary ISAPI filters and ISAPI extensions
Countermeasures

© Copyright IBM Corp. 2016 4-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
• Countermeasures that help mitigate the risk posed by viruses, Trojan horses, and worms include:
• Promptly applying the latest software patches
• Disabling unused functionality, such as unused ISAPI filters and extensions
• Running processes with least privileged accounts to reduce the scope of damage in the event of a
compromise

© Copyright IBM Corp. 2016 4-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Introduction to Oracle Application Server IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Introduction to Oracle Application Server and security objectives

– Providing Basic Security Services
– Supporting Standards
– Ensuring Deployment and Configuration Flexibility
– Minimizing Application Development and Deployment Cost
– Providing Security in Depth

© Copyright IBM Corporation 2016

Figure 4-5. Introduction to Oracle Application Server

Introduction to Oracle Application Server

Oracle Application Server is a reliable, scalable, secure middle-tier application server designed to support a
company’s evolution into e-business. The technological complexity of assembling a complete middle-tier
Internet foundation is managed by this application. The technological foundation that Oracle Application
Server provides can grow with your business.
Oracle Application Server components provide a general framework for development and deployment of
applications, as well as specific application services and functionality. Here we are going to focus on the
security services provided by Oracle Application Server Infrastructure, which includes Oracle Application
Server Single Sign-On and Oracle Internet Directory, an LDAP version 3-compliant directory service.
Security Objectives
The security objectives for Application Server derive from the overall architecture and functions of the
product, as well as the range of operational environments and risk scenarios in which the product will be
deployed. These objectives include
• Providing Basic Security Services
• Supporting Standards
• Ensuring Deployment and Configuration Flexibility
• Minimizing Application Development and Deployment Cost
• Providing Security in Depth
Providing Basic Security Services

© Copyright IBM Corp. 2016 4-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
Certain security services are fundamental to providing security in a multiuser, networked environment. Oracle
Application Server has been designed to provide all these services, including:
Authentication: Allows a system to verify the identity of users and other systems that request access to
services or data. Authentication is a prerequisite for many other security services, including access control,
authorization, and accountability.
The authentication process deals with the question “Who is trying to access my services?” In any system and
application, it is paramount to ensure that the identity of the entity or caller trying to access your application is
identified in a secure manner. In a multitier application, the entity or caller can be a human user, a business
application, a host, or one entity acting on behalf of (or impersonating) another entity.
Authorization: Allows a system to determine the privileges which users and other systems have for
accessing resources on that system. Authorization is generally required for effective access control.
The authorization (or access control) process deals with the question “Who can access what services offered
by which components?” For large-scale enterprises, where the access to various business-critical services
and resources by millions of users need to be managed, it is important that a scalable authorization
infrastructure be in place to deal with user and application provisioning.
Unfortunately, in part due to the complex nature of authorization, this is also an area where confusion reigns
and incompatible technologies and standards are prevalent.
Access Control: Ensures that a system grants access to resources only in ways that are consistent with
security policies defined for those resources. Access decisions are based on the authenticated identity and/or
authorization of the requesting user, and on what type of access that user is requesting.
Data Protection: Protects sensitive data against access by those who are not authorized users of the
system. For example, encryption mechanisms can protect data sent through a public network from
interception. Encryption can also protect highly sensitive data (such as passwords) stored on a disk from
users who bypass system access control mechanisms, such as by exploiting a vulnerability in the underlying
operating system or by stealing the physical disk storage medium.
Supporting Standards
Oracle Application Server is an open standards-based product. It complies with the J2EE framework and
supports standard protocols, such as HTTP, and markup languages, such as HTML and XML. Corresponding
Oracle Application Server security services also comply with relevant standards, facilitating interoperation
with third-party products. For example, most Oracle Application Server applications support browser-based
clients, typically Internet Explorer or Netscape Navigator. Oracle Application Server therefore supports the
security standards that these browsers implement, including SSL for encryption, and X.509v3 when
certificates are in use. Similarly, OC4J supports the J2EE security standards such as the Java Authentication
and Authorization Service (JAAS), so that customers can deploy third-party Java applications securely.
Ensuring Deployment and Configuration Flexibility
Oracle Application Server supports a wide range of potential configurations and deployment options. These
configurations span the range from standalone developer installations of Oracle Application Server Java
Edition on a small desktop computer to large, distributed, multi-server deployments of Oracle Application
Server serving hundreds of thousands of users in a worldwide enterprise.
Oracle Application Server security services have been designed to support the full range of product
deployment options. In particular, the security services deployed on each edition of Oracle Application Server
have been chosen to support the particular deployment scenarios and types of applications for which that
edition of Oracle Application Server is targeted. Moreover, security mechanisms in Oracle Application Server
have been designed to ensure that practical, real-world constraints on deployment can be met, such as the
need to deploy certain components of Oracle Application Server in the DMZ, other components in the
corporate intranet, and allow those components to communicate through firewalls.

Minimizing Application Development and Deployment Cost

Oracle Application Server serves as a development and deployment environment for web applications.
Oracle Application Server is designed to provide services and tools that reduce the time, effort, and expense

© Copyright IBM Corp. 2016 4-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
to develop and deploy such applications. Because security is an important part of deploying applications in a
production environment.
Working in cooperation, the security services provided in Oracle Application Server ensure the following:
• Easy development and deployment of secure applications. Oracle Application Server provides the basic,
easy-to-use services required to deploy applications.
• Scalability, supporting complex deployments that support large numbers of users and servers. Oracle
Application Server provides additional security services that reduce cost and complexity for large or
complex deployments. These services include centralized user provisioning, single sign-on, and
authorization, so that customers do not need to develop or purchase and integrate these services
themselves.
• Protection of existing investments in third-party technology. Oracle Application Server protects the
existing investment through compliance with security standards and support for specific third-party
security mechanisms and infrastructure where required.
Providing Security in Depth
An important design objective for Oracle Application Server is to provide security in depth, meaning that:
• Security mechanisms are implemented with high assurance, so that the probability of failure of any given
security mechanism is low. This is achieved through secure coding practices, developer security
education and training, secure coding compliance checklist/testing, independent evaluations,
independent security assessments and penetration testing, and security incident response.
• Security must degrade gracefully, and there must be no single points of failure. Failure of any single
security mechanism should cause only incremental loss of security, not compromise the entire system.
• Privileges are minimized by default. You must explicitly grant permission to perform sensitive functions or
access sensitive data.
• Intrusions are contained. The system should detect and limit damage from security breaches.

© Copyright IBM Corp. 2016 4-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Security architecture of oracle

application server IBM ICE (Innovation Centre for Education)
IBM Power Systems

© Copyright IBM Corporation 2016

Figure 4-6. Security architecture of oracleapplication server

Security Architecture of Oracle Application Server

Oracle Application Server provides a solid framework for building and deploying Web applications using the
Apache-based Oracle HTTP Server, Oracle Application Server Containers for J2EE, and OracleAS Portal,
which use the advanced security functionality provided by Oracle Application Server Infrastructure. Oracle
Application Server Infrastructure consists of Oracle Application Server Metadata Repository and Oracle
Identity Management. Oracle Application Server security starts from the well-tested and highly configurable
Web security services provided by Oracle HTTP Server, adds a comprehensive set of Web single sign-on
services, and extends them further with centralized user provisioning that is available in Oracle Internet
Directory, an LDAP, version 3-compliant directory service. In addition, Oracle Application Server provides the
Oracle implementation of Java Authentication and Authorization Services (JAAS) for J2EE application
security, and extensive portal authorization and application integration mechanisms. Oracle Application
Server also supports secure access to Oracle database systems using Oracle Advanced Security.
Elements of Oracle Application Server Security Architecture

© Copyright IBM Corp. 2016 4-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Oracle HTTP Server Security IBM ICE (Innovation Centre for Education)
IBM Power Systems

Single Sign-On With mod_osso

© Copyright IBM Corporation 2016

Figure 4-7. Oracle HTTP Server Security

Oracle HTTP Server Security

The Oracle HTTP Server provides the first line of defense in Oracle Application Server security. The Oracle
HTTP Server makes data available to users through a standard Web interface. Oracle HTTP Server mediates
user access to both static and dynamic content by restricting access to URLs and directories on the server.
Dynamic content is provided by applications running natively on Oracle HTTP Server, such as CGI, or in
other Oracle Application Server components. These components include J2EE applications deployed on
Oracle Application Server Containers for J2EE (OC4J) and accessed through mod_oc4j, as well as PL/SQL
applications deployed on an Oracle Database and accessed through mod_plsql. Access is configured to
resources on Oracle HTTP Server using the standard Apache directive model.
The Oracle HTTP Server controls access to resources based on user identity. Identity is established through
standard Apache authentication mechanisms, such as basic authentication and SSL with client certificate.
Users can also be authenticated through OracleAS Single Sign-On, using mod_osso. Applications running on
Oracle Application Server can obtain OracleAS Single Sign-On user identity from Oracle HTTP Server using
the Apache header created by mod_osso.
In Oracle Application Server 10g, when users are authenticated by mod_osso, control of user access on
Oracle HTTP Server is limited to specifying whether a user may have access to server resources (URLs,
directories) or not. Applications accessible through Oracle HTTP Server can use the SSO-authenticated user
identity to enforce fine-grained control of user access to resources that are managed by those applications.
The Oracle HTTP Server does not itself provide fine-grained access control of users to static content on the
HTTP Server when users are authenticated using SSO.

© Copyright IBM Corp. 2016 4-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
Oracle HTTP Server can be configured to protect data exchanged between the server and Web clients using
the Secure Sockets Layer (SSL) cryptographic protocol. The SSL protocol is an industry-accepted standard
for network transport layer security. SSL provides encryption and data integrity, and support for digital
certificate authentication using a public key infrastructure (PKI).
Message Flow with Single Sign-On
Figure shows the flow of information when a user requests the URL for a partner application using the Oracle
HTTP authentication module mod_osso.
• The user tries to access a partner application
• The user is redirected to the single sign-on server. The server challenges her for her credentials. After
verifying these credentials in Oracle Internet Directory, it passes them on to the partner application
• The application serves up the requested content
Authenticating to an External Application for the First Time
OracleAS Single Sign-On uses the following process if the user is accessing an external application for the
first time.
• The external application login procedure checks the single sign-on server password store for the user’s
credentials for the requested external application. If it finds that the user has no such credentials, the
single sign-on server prompts the user for them.
• The user enters the user name and password.
• If the user elects to save the credentials in the single sign-on server password store, the server uses
these credentials to construct a login form to submit to the login processing routine for the external
application. This routine has been preconfigured by the single sign-on server administrator and is
associated with the requested application.
• The single sign-on server sends the form to the client browser, with a directive to post it immediately to
the external application.
• The client posts the form to the external application and logs the user in.
• If the user declines to save her credentials in the single sign-on password store, she must enter a user
name and password each time she logs in to the application.
SSL Acceleration
In addition to offboard SSL acceleration solutions, Oracle Application Server supports BHAPI-compliant
hardware for deployment on servers running Oracle Application Server Web Cache and/or Oracle HTTP
Server. When executed in software, SSL operations place a strain on server CPU resources, causing a
reduction in throughput and slower overall performance. The hardware offloads the SSL key exchange
processing from a server's CPUs, increasing the number of concurrent SSL connections and improving
response times for SSL-protected content.

© Copyright IBM Corp. 2016 4-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Oracle application server portal security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Brief introduction about Oracle Application Server Portal Security

© Copyright IBM Corporation 2016

Figure 4-8. Oracle application server portal security

Oracle Application Server Portal Security

OracleAS Portal allows customers to organize Web content and applications in a logical and consistent Web
portal format. OracleAS Portal provides a flexible, sophisticated model for managing user access to
OracleAS Portal resources based on user identity and privilege. It supports a hierarchical, group-based
model for aggregating privileges. A collection of privileges is associated with each group, and users who are
members of that group inherit the appropriate privileges. The model is hierarchical: groups may be defined as
subgroups of other groups. In this case, users who belong to the subgroup inherit all the privileges of the
larger group in addition to privileges unique to the subgroup.
As do other components of Oracle Application Server, OracleAS Portal uses Oracle Identity Management for
user management, authentication, and authorization. After users have been provisioned in the Oracle
Internet Directory component of Oracle Identity Management, they can authenticate themselves to OracleAS
Portal using Oracle Application Server Single Sign-On.

© Copyright IBM Corp. 2016 4-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Oracle Application Server Security Best Practices

(1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the oracle application server security best practices

– Best practices for HTTPS Use
– Best Practices for Cookie Security
– Best Practices for Certificates Use

© Copyright IBM Corporation 2016

Figure 4-9. Oracle Application Server Security Best Practices(1 of 2)

Oracle Application Server Security Best Practices

Best practices for HTTPS Use
• Configure Oracle Application Server to fail attempts that use weak encryption. Oracle Application Server
can be configured to use only specific encryption ciphers for HTTPS connections. Connections from all
old Web browsers that have not upgraded the client-side secure sockets layer (SSL) library to 128-bit can
be rejected. This functionality is especially useful for banks and other financial institutions because it
provides server-side control of the encryption strength for each connection.
• Use HTTPS to HTTP appliances for accelerating HTTP over SSL. Huge performance overhead of
HTTPS forces a trade-off in some situations. Use of HTTPS to HTTP appliances can change throughput
from 20 to 30 transactions per second on a 500MHz Unix to 6000 transactions per second for a relatively
low cost, making this trade-off decision easier. This is a better solution than mathematics/cryptography
cards, which can be added to UNIX/NT/Linux computers.
• Ensure that sequential HTTPS transfers are requested through the same Web server. Expect 40/50
milliseconds CPU time for initiating SSL sessions on a 500 MHz computer. Most of this CPU time is spent
in the key exchange logic, where the bulk encryption key is exchanged. Caching the bulk encryption key
will significantly reduce CPU overhead on subsequent access, provided that the access is routed to the
same Web server.
• Keep secure pages and pages not requiring security on separate servers. While it may be easier to place
all pages for an application on one HTTPS server, the resulting performance cost is very high. Reserve
your HTTPS server for pages that require SSL. Put pages that do not require SSL on an HTTP server.

© Copyright IBM Corp. 2016 4-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
If secure pages are composed of many .GIF, .JPEG, or other files that would be displayed on the same
screen, it is probably not worth the effort to segregate secure from non-secure static content. The SSL key
exchange (a major consumer of CPU cycles) is likely to be called exactly once in any case, and the overhead
of bulk encryption is not that high.
Best Practices for Cookie Security
• Make sure that cookies have proper expiration dates. Permanent cookies should have relatively short
expiration dates of about three months or less. This will avoid cluttering client Web browsers, which may
cause errors if the Web browser cannot transmit all the valid cookies. Non-permanent cookies should be
set to expire when the relevant application exits.
• Make sure that information in cookies contains Method Authentication. Method Authentication should be
used to ensure that cookie data has not been changed since the application set the data. This helps
ensure that the cookie cannot be modified and deceive the application. Also, this helps prevent
application failures if the cookie is inadvertently corrupted.
• Make sure that the size and varieties of cookies are kept low. There is a finite number and aggregate size
of cookies that Web browsers support. If this is exceeded, then the Web browsers will not send all the
relevant cookies leading to application failures. Also, very large cookies can result in performance
degradation.
• Carefully use cookie domain name facilities. Use of cookie domains should ensure that the domain is the
smallest possible. Making the domain oracle.com, for instance, would mean that any host in oracle.com
would get the cookie. With hundreds of applications on different parts of oracle.com, a domain of
oracle.com for each of them results in attempts to send hundreds of cookies for each HTTP input
operation.
Best Practices for Certificates Use
• Ensure that certificate organization unit plus issuer fields uniquely identify the organization across the
Internet. One way to accomplish this would be to include the Dun and Bradstreet or IRS identification as
identification for the issuer and the organizational unit within the certificate.
• Ensure that certificate issuer plus distinguished name uniquely identify the user. If the combination of
issuer and distinguished name is used as identification, there is no duplication risk.
• Include expiring certificates in tests of applications using certificates. Expiration is an important
consideration for a number of reasons. Unlike most username/password-based systems, certificates
expire automatically. With longer duration certificates, fewer re-issues are required, but revocation lists
become larger. In systems where certificates replace traditional usernames/passwords, expiring
certificate situations may result in unexpected bugs. Careful consideration of the effects of expiration is
required and new policies will have to be developed because most application and infrastructure
developers have not worked in systems where authorization might change during transactions.
• Use certificate re-issues to update certificate information. Because certificates expire, infrastructure for
updating expired certificates will be required. Take advantage of the re-issue to update organizational unit
or other fields. In cases of mergers, acquisitions, or status changes of individual certificate holders,
consider re-issuing even when the certificate has not yet expired. But pay attention to key management.
If the certificate for a particular person is updated before it expires, for example, put the old certificate on
the revocation list.
• Audit certificate revocations. Revocation audit trails can help you reconstruct the past when necessary.
An important example is replay of a transaction to ensure the same results on the replay as during the
original processing. If the certificate of a transaction participant was revoked between the original and the
replay, failures may occur which would not have occurred when the original transaction was processed.
For these cases, the audit trail should be viewed to simulated authentication at the time when the
transaction was initially processed.

© Copyright IBM Corp. 2016 4-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Oracle Application Server Security Best Practices

(2 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the oracle application server security best practices

– Review Code and Content Against Already Known Attack
– Follow Common Sense Firewall Practices
– Leverage Declarative Security
– Use Switched Connections in DMZ
– Place Application Server in the DMZ
– Secure Sockets Layer

© Copyright IBM Corporation 2016

Figure 4-10. Oracle Application Server Security Best Practices(2 of 2)

Review Code and Content Against Already Known Attack

• It is quite common for viruses or known attacks to resurface in slightly altered shape or form. Thus, just
because a threat has been apparently eliminated does not mean it will not resurface. Use the following as
guidelines to minimize the recurrence of the threat:
• Ensure that programs are reviewed against double encoding attacks. There area many cases where
special characters, such as , | are encoded to prevent cross-site scripting attacks or for other reasons.
For example, "<" might be substituted for ">". In a double encoding, the attacker might encode the "&" so
that later decoding might involve the inadvertent processing of a >,<, or | character as part of a script.
Prevention of this attack, unfortunately, can only be provided by careful program review, although some
utilities can be used to filter escape characters that might result in double encoding problems in later
processing.
• Ensure that programs are reviewed against buffer overflow for received data.
• Ensure that programs are reviewed against cross-site scripting attacks. This attack typically tricks HTML
and XML processing via input from Web browsers (or processes which act like Web browsers) to invoke
scripting engines inappropriately. However, it is not limited to the Web technologies, and all code should
be evaluated for this.
Follow Common Sense Firewall Practices
• The following are some common recommended practices pertaining to firewalls; while not unique to
Oracle Application Server, these are important to overall Oracle Application Server security:

© Copyright IBM Corp. 2016 4-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
• Place servers providing Internet services behind an exterior firewall of the stateful inspection type.
Stateful inspection means that the firewall keeps track of various sessions by protocol and ensures that
illegal protocol transitions are disallowed through the firewall. This blocks the types of intrusion that
exploit illegal protocol transitions.
• Set exterior firewall rules to allow Internet-initiated traffic only through specific IP and PORT addresses
where SMTP, POP3, IMAP, or HTTP services are running. Some protocols (for example, IIOP) leave
ports open without receiving processes. PORT and IP combinations that are not assigned to running
programs should not be permitted.
• Set interior firewall rules to allow messages through to the intranet only if they originate from servers
residing on the perimeter network. All incoming messages must first be processed in the perimeter
network.
• Send outgoing messages through proxies on the perimeter network.
• Do not store the information of record on bastion hosts. Bastion hosts are fortified servers on the
perimeter network. Information and processing should be segmented such that the bastion hosts provide
initial protocol server processing and generally do not contain information of a sensitive nature. The
database of record and all sensitive processing should reside on the intranet.
• Disallow all traffic types unless specifically allowed. allow only the traffic required by Oracle Application
Server for better security. For example, HTTP, AJP, OCI, LDAP.
Leverage Declarative Security
Oracle HTTP Server has several features that provide security to an application without requiring the
application to be modified. These should be leveraged and/or evaluated before programming similar
functionality as those features into the application. Specifically:
• Authentication: Oracle HTTP Server can authenticate users and pass the authenticated user-id to an
application in a standard manner. It also supports single sign-on, thus reusing existing login mechanisms.
• Authorization: Oracle HTTP Server has directives that can allow access to your application only if the
end user is authenticated and authorized. Again, no code change is required.
• Encryption: Oracle HTTP Server can provide transparent SSL communication to end customers without
any code change on the application.
These three features should be leveraged heavily before designing any application specific security
mechanisms.
Use Switched Connections in DMZ
Oracle recommends that all DMZ attached devices be connected by switched, not bussed connections.
Place Application Server in the DMZ
Application servers should exist in the DMZ. In this architecture Oracle Application Server Web Cache only
forwards requests to computers containing Web servers. Web servers only forward requests to application
servers or via PL/SQL to database servers. The application servers only forward inward requests to the
database or, perhaps, special message processing processors in the intranet. This provides excellent fault
containment because a compromised Web server must somehow compromise an application server before
the database can be attacked.
Secure Sockets Layer
SSL encryption can be used to secure both LDAP and HTTP traffic that passes between the various
components of the Oracle Application Server.

© Copyright IBM Corp. 2016 4-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Oracle Application Server Security Best Practices

(2 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the oracle application server security best practices

– Review Code and Content Against Already Known Attack
– Follow Common Sense Firewall Practices
– Leverage Declarative Security
– Use Switched Connections in DMZ
– Place Application Server in the DMZ
– Secure Sockets Layer

© Copyright IBM Corporation 2016

Figure 4-11. Oracle Application Server Security Best Practices(2 of 2)

Review Code and Content Against Already Known Attack

• It is quite common for viruses or known attacks to resurface in slightly altered shape or form. Thus, just
because a threat has been apparently eliminated does not mean it will not resurface. Use the following as
guidelines to minimize the recurrence of the threat:
• Ensure that programs are reviewed against double encoding attacks. There area many cases where
special characters, such as , | are encoded to prevent cross-site scripting attacks or for other reasons.
For example, "<" might be substituted for ">". In a double encoding, the attacker might encode the "&" so
that later decoding might involve the inadvertent processing of a >,<, or | character as part of a script.
Prevention of this attack, unfortunately, can only be provided by careful program review, although some
utilities can be used to filter escape characters that might result in double encoding problems in later
processing.
• Ensure that programs are reviewed against buffer overflow for received data.
• Ensure that programs are reviewed against cross-site scripting attacks. This attack typically tricks HTML
and XML processing via input from Web browsers (or processes which act like Web browsers) to invoke
scripting engines inappropriately. However, it is not limited to the Web technologies, and all code should
be evaluated for this.
Follow Common Sense Firewall Practices
• The following are some common recommended practices pertaining to firewalls; while not unique to
Oracle Application Server, these are important to overall Oracle Application Server security:

© Copyright IBM Corp. 2016 4-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
• Place servers providing Internet services behind an exterior firewall of the stateful inspection type.
Stateful inspection means that the firewall keeps track of various sessions by protocol and ensures that
illegal protocol transitions are disallowed through the firewall. This blocks the types of intrusion that
exploit illegal protocol transitions.
• Set exterior firewall rules to allow Internet-initiated traffic only through specific IP and PORT addresses
where SMTP, POP3, IMAP, or HTTP services are running. Some protocols (for example, IIOP) leave
ports open without receiving processes. PORT and IP combinations that are not assigned to running
programs should not be permitted.
• Set interior firewall rules to allow messages through to the intranet only if they originate from servers
residing on the perimeter network. All incoming messages must first be processed in the perimeter
network.
• Send outgoing messages through proxies on the perimeter network.
• Do not store the information of record on bastion hosts. Bastion hosts are fortified servers on the
perimeter network. Information and processing should be segmented such that the bastion hosts provide
initial protocol server processing and generally do not contain information of a sensitive nature. The
database of record and all sensitive processing should reside on the intranet.
• Disallow all traffic types unless specifically allowed. allow only the traffic required by Oracle Application
Server for better security. For example, HTTP, AJP, OCI, LDAP.
Leverage Declarative Security
Oracle HTTP Server has several features that provide security to an application without requiring the
application to be modified. These should be leveraged and/or evaluated before programming similar
functionality as those features into the application. Specifically:
• Authentication: Oracle HTTP Server can authenticate users and pass the authenticated user-id to an
application in a standard manner. It also supports single sign-on, thus reusing existing login mechanisms.
• Authorization: Oracle HTTP Server has directives that can allow access to your application only if the
end user is authenticated and authorized. Again, no code change is required.
• Encryption: Oracle HTTP Server can provide transparent SSL communication to end customers without
any code change on the application.
These three features should be leveraged heavily before designing any application specific security
mechanisms.
Use Switched Connections in DMZ
Oracle recommends that all DMZ attached devices be connected by switched, not bussed connections.
Place Application Server in the DMZ
Application servers should exist in the DMZ. In this architecture Oracle Application Server Web Cache only
forwards requests to computers containing Web servers. Web servers only forward requests to application
servers or via PL/SQL to database servers. The application servers only forward inward requests to the
database or, perhaps, special message processing processors in the intranet. This provides excellent fault
containment because a compromised Web server must somehow compromise an application server before
the database can be attacked.
Secure Sockets Layer
SSL encryption can be used to secure both LDAP and HTTP traffic that passes between the various
components of the Oracle Application Server.

© Copyright IBM Corp. 2016 4-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Web Application Server Security best practices IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the best practices of web application server security

– Use separate servers for internal and external applications
– Use Separate Development Server for Testing and Debugging Apps
– Audit Website activity and store logs in a secure location
– Education of developers on sound security coding practices
– Patching Operating System and Web Server
– Use of Application Scanners

© Copyright IBM Corporation 2016

Figure 4-12. Web Application Server Security best practices

Oracle Application Server Web Cache Security

OracleAS Web Cache serves as a caching front end to Oracle HTTP Server. When used, it intercepts HTTP
requests sent to Oracle HTTP Server, and proxies them to Oracle HTTP Server if necessary. Because it acts
as a proxy, OracleAS Web Cache necessarily terminates any SSL connections established by a client system
to Oracle Application Server. If the SSL connection uses client certificate authentication, then the client
certificate identity is provided to OracleAS Web Cache, and not to Oracle HTTP Server, because the SSL
connection is established between the client and OracleAS Web Cache.
OracleAS Web Cache can proxy the contents of a client certificate, when used in an SSL connection, to
Oracle HTTP Server. In this way, a client’s SSL authenticated identity can be obtained and used by Oracle
HTTP Server, even if OracleAS Web Cache is used in front of Oracle HTTP Server.
Web Application Server Security best practices
Use separate servers for internal and external applications
Mostly, organizations have two classes of web applications; one of them serves the external users while the
other one serves the internal users. To ensure proper placement of security, both applications can be placed
on different servers. This reduces the risk of some malicious person – who tries to access the external
application in order to get internal information, which is sensitive and confidential. In case this implementation
seems too costly, isolation can be processed to ensure that external and internal application do not interact
which each other.
Use Separate Development Server for Testing and Debugging Apps

© Copyright IBM Corp. 2016 4-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
It sounds like common sense to test applications on a stand-alone web server, but most companies allow
developers to tweak code and, in many cases, allow developing new applications on a production server.
It can cause many problems. It is not reliable and also not secure. On the one hand, these testing codes can
make users experience malfunctions – sometimes it can be a complete outage – and on the other, these
codes can invite security vulnerabilities.
The latter is because these codes are unchecked, and it is possible that these codes will be vulnerable to
attack.
Audit Website activity and store logs in a secure location
It is certain that every professional knows how important server activity logs are. The audit trails helps discern
the attacks and also help you to troubleshoot many problems
To seek high level security, logs should be at the device, which is virtually and physically secure. Digital ways
like the encryption with digital signatures can always be used, which prevent any scam modification.
Education of developers on sound security coding practices
Many developers who work for software corporations and develop many types of software usually forget that
information security is a pre-requisite for business success.
It is the responsibility of companies to educate the developers on critical issues regarding web server safety.
The organizations should educate the developers about the security mechanisms and make sure they aren’t
circumventing those mechanisms.
They should also be educated about overflow attacks and process isolation, which will result in the web
server security in the longer run.
Patching Operating System and Web Server
It is such a simple thing and entails common sense that most administrators even forget it because they are
burdened with other heavy tasks.
Software vendors often release patches for security vulnerabilities, and the administrators should patch their
web servers with the latest security fixes. If someone finds a flaw in the web server, he is surely going to
exploit it.
Use of Application Scanners
Application scanners are also best to secure your web server from security vulnerabilities because tools like
Watchfire, SUCURI ensure that no exploitable code slips through the crack into the production environment.
It all depends if you can afford application scanners which can validate internally developed codes.
One should also consider the fundamental things like the architecture of web servers should be well
designed, and it should be based on sound security principles. All these factors – if implemented – will ensure
the safety of the web server.

© Copyright IBM Corp. 2016 4-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Introduction of mobile application server

security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Understanding the mobile application server security

© Copyright IBM Corporation 2016

Figure 4-13. Introduction of mobile application server security

Mobile Application Server Security

Mobile application server refers to a server that hosts, installs, and operates mobile applications and other
services. A mobile application server is a key component in EMM, or enterprise mobile management. With
the rise in BYOD, or Bring Your Own Device, businesses are facing an increased need to have a
comprehensive system that supports the use of company applications as well as data on a variety of devices
and operating systems. EMM has emerged as a solution to this problem. In this context, the mobile
application server is the centralized system that stores company apps and oversees their deployment,
distribution of updates, and removal if necessary.
The mobile application server will contain both a server operating system and server hardware. These
function simultaneously to allow the server to provide remote access and services to apps, which can include
authentication, updates, and security features. In this system, the mobile application server communicates
with the client component, which operates on the mobile device to receive apps, download updates, and
follows the commands of the server. All of these functions occur OTA, or over-the-air. This allows the
administrator of the system to configure app settings, send out updates, and wipe all data from a remote
location.
In a mobile application server, the key features include user management, data redundancy, security of the
application and data, high levels of availability, a centralized interface for management, and load balancing.
Mobile application servers are beneficial because they allow employees to use the mobile device of their
choice, and they offer a simple solution the issues the BYOD platform creates.
Mobile phone usage is growing by the day. Unlike the situation a decade ago, today, people feel handicapped
and uncomfortable without their mobile device close at hand. There have been great advances in mobile

© Copyright IBM Corp. 2016 4-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
computing. People can download apps that help them socialize, keep fit, get directions, transact, shop, and
much more. There are millions of mobile applications available in app stores that make our simple life
simpler.
Amidst all the great things that have been accomplished in the mobility space, there is a global community of
hackers who have been watching the mobile space closely. They use newer and bolder techniques to break
into mobiles and applications, so app developers need to be cautious.
Mobile applications security testing is the process of reviewing the application characteristics and the code
for vulnerabilities. It is a combination of static analysis, code review, and penetration testing.
Applications become prone to attacks when:
• Security flaws originate at the development stage
• An application is cloned with extra functions that run in the background and perform malicious actions
In both cases, the application can compromise sensitive information contained in user devices. Security
testing involves analysis to find out if the application is vulnerable. The application is dissected into
component code and assets. The code is checked for flaws and penetration testing is done to determine
whether unauthorized access is possible.

© Copyright IBM Corp. 2016 4-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Introduction to OWASP ( 1 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Introduction to OWASP and top 10 OWASP

– Insecure Data Storage
– Weak Server-Side Controls
– Insufficient Transport Layer Protection
– Client Side Injection
– Poor Authorization and Authentication

© Copyright IBM Corporation 2016

Figure 4-14. Introduction to OWASP ( 1 of 2)

OWASP
The Open Web Application Security Project (OWASP) is a worldwide nonprofit charitable organization
focused on improving the security of software. OWASP is involved in detecting and combating leaks in
application security and techniques. They provide testers and developers guidelines to create secure
applications.
OWASP Top Ten
The OWASP Top Ten is a list of vulnerabilities determined by identifying some of the most critical risks faced
by mobile platforms. The OWASP Top 10 is referenced by many standards, books, tools, and organizations
such as MITRE, PCI DSS, DISA, FTC, and others.
The OWASP top ten highlights the following threats to mobile applications:
• Insecure Data Storage
• Weak Server-Side Controls
• Insufficient Transport Layer Protection
• Client Side Injection
• Poor Authorization and Authentication
• Improper Session Handling
• Security Decisions via Untrusted Inputs
• Side Channel Data Leakage

© Copyright IBM Corp. 2016 4-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
• Broken Cryptography
• Sensitive Information Disclosure
In security analysis, priority is given to the user and user data, which is targeted the most. Vulnerabilities that
pose a threat to user data are a security concern.
Insecure Data Storage
Insecure data storage, as the name suggests, means improper storage of data. Mobile applications should
not store any data on the device unnecessarily.
According to OWASP
“Insecure data storage, occurs when development teams assume that users will not have access to the
phones file system and store sensitive pieces of information in data-stores on the phone. Devices file
systems are often easily accessible and you should expect a malicious user to be inspecting your data
stores. Rooting or jailbreaking a device usually circumvents any encryption protections and in some cases,
where data is not protected properly, all that is needed to view application data is to hook the phone up to a
computer and use some specialized tools.”
Data stored in devices can be easily extracted, and therefore needs to be properly secured. Recent reports
show that even encrypted phones can be exploited.
Weak Server-Side Controls
The server-side of any mobile application is a web application. When the server-side validation is not done
properly, the server is prone to attacks. This in turn could put the client application and device at risk.
In a client-server hierarchy, where the mobile device is the client end, attacks intended to damage the server
can be initiated from the device. If the server-side is not validated properly, it could result in a security breach.
There are other ways to attack the server-side. In case of Android applications, an emulator can be used.
Browser-based attacks can also be generated from big browsers using a modified user agent.
Insufficient Transport Layer Protection
The most important feature of client-server architecture is information exchange. When data is exchanged,
information may be exchanged through the carrier network or the Internet. While developing an application, if
care is not taken while sharing data between the client and server, there is a chance that the data may be
compromised in transit. The best way to protect data in transit is to encrypt it. This prevents data from being
sniffed, particularly in the case of usernames, passwords, and credit card information.
According to OWASP, “Unfortunately, mobile applications frequently do not protect network traffic. They may
use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. In
addition, the existence of transport security does not mean it is implemented to its full potential. Detecting
basic flaws is easy. Just observe the phone's network traffic. More subtle flaws require inspecting the design
of the application and the applications configuration.”
Even though the exploitability level is difficult, any threat to data should be taken seriously.
Client-Side Injection
Client-side injection refers to application vulnerabilities in the absence of client-side validation. The local
storage of mobile devices is targeted here. Attacks such as SQL injections become very dangerous if the
application has multiple user accounts on the same device. For example, a shared device may contain more
than one user account in the database, which, if compromised, can lead to exposure of sensitive data.
All client-side injections that affect a web application can also pose a threat to the mobile application. The
ease of exploitability of a client-side injection in vulnerable applications is the biggest risk. In case of mobile
applications, anyone with physical access to the phone can generate an attack.
Prevention of client-side injection can be ensured by using proper validation methods.
Poor Authorization and Authentication
Authentication and authorization refers to user privileges granted for using an application. In an application
with functionalities beyond publicly usable features, permission may be required for accessing privileged

© Copyright IBM Corp. 2016 4-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
functions. Authentication refers to who you are in an application, and authorization points to what you are
authorized to do in an application. When the authorization and authentication schema fails to protect the
application, the privileged functions in the application are compromised, rendering it vulnerable to attacks.
Authorization and authentication should be dealt with meticulously while developing an application to ensure
that unauthorized users are not granted access to sensitive information. This can be achieved by ensuring
secure session-handling and login functions.

© Copyright IBM Corp. 2016 4-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Introduction to OWASP ( 2 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Introduction to OWASP and top 10 OWASP

– Improper Session Handling
– Security Decisions via Untrusted Inputs
– Side Channel Data Leakage
– Broken Cryptography
– Sensitive Information Disclosure

© Copyright IBM Corporation 2016

Figure 4-15. Introduction to OWASP ( 2 of 2)

Improper Session Handling

The sessions used in mobile devices are much longer compared to web applications. The session identifier
and the session mechanisms used in mobile devices can threaten valid sessions of users. Sometimes the
application chooses the device ID as the session identified because of its authenticity. However, the
application ID can be extracted using third-party software, in which case the session ID can be made
available to third parties as well, exposing valid sessions to attacks.
Encryption of valid session data is highly recommended. The application should use encryption in order to
protect valid session data from being stolen through LAN sniffing and Wi-Fi attacks.
Security Decisions via Untrusted Inputs
Security decisions made in an application should not solely depend on user inputs. If security-related
decisions are based on user inputs, it could leave the application vulnerable to threats. In case of mobile
devices, security decisions should be taken with utmost care. Testing should be done on both sides of the
application – server-side as well as client-side.
The application’s logic should ensure that security does not depend on the user input, which could be abused
to bypass permissions and security models. In a platform such as Android, the intent may be abused to attack
applications.
Side Channel Data Leakage
Side channel data leakage is considered to be a wide area of attack. The data contained in the system logs,
and data that can be derived from leaks, power consumption, and timing information comprise side channel
data leakage. These provide additional information that can be exploited if not protected.

© Copyright IBM Corp. 2016 4-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
In a Side Channel Data Leakage Attack, Data Is Obtained from the following Sources:
• Web caches
• Keystroke logging
• Screenshots
• Logs
• Temp directories
Third-party libraries and APIs used in application development may contain malicious code that could steal
data stored by the application. Developers need to ensure that only trusted APIs and libraries are used in the
application. While executing procedures such as logging, sensitive data should not appear in the logs.
Case studies have shown that some applications store a snapshot of the running state when it is interrupted.
This snapshot can be used to make the user believe that the application is working well even when it is
interrupted. Such practices can lead to snapshots being stored insecurely leading to compromised data.
Broken Cryptography
Cryptography is the art of protecting information by transforming it into an unreadable format called cipher
text. Cipher text may not resemble the original text; however, the original text can be decrypted from the
encrypted data/cipher text.
Cryptography is used in mobile applications to ensure that the application stores the user data securely.
Encryption is also used when applications fail to provide proper security to the data.
This failure is caused due to two reasons:
• Broken implementations of strong algorithms: The developer may use a strong algorithm to protect the
data, but the implementation of the algorithm is flawed, resulting in the data being decrypted by a hacker.
• Weak algorithm or crypto implementation: Instead of using a strong algorithm, the developer uses a weak
algorithm that can be decrypted effortlessly.
In both cases, the application fails to protect sensitive user data. In many cases, developers confuse between
encryption and other text scrambling methods. They fail to realize that encoding, obfuscation, and
serialization is not encryption.
Sensitive Information Disclosure
Sensitive information disclosure refers to the personal and important data stored in the application as
hardcoded values such as passwords and credit card information. Applications that are developed for mobile
devices can be reverse engineered, revealing the code of the application. Sensitive information hardcoded in
the application can be accessed by hackers using this technique. The sensitive information thus gained can
be used to craft attacks.

© Copyright IBM Corp. 2016 4-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Mobile Application Security Testing IBM ICE (Innovation Centre for Education)
IBM Power Systems

• We Can Divide Mobile Application Testing into Three Parts:

– Dynamic analysis
– Black box security testing
– Static analysis & code review

© Copyright IBM Corporation 2016

Figure 4-16. Mobile Application Security Testing

Mobile Application Security Testing

Dynamic Analysis
In dynamic analysis, the behavior of an application is analyzed after installing it on various versions of
compatible and non-compatible devices. This method of testing helps testers understand possible flaws. The
behavior of the application is observed and test cases are created based on observations.
Black Box Security Testing
Black box testing involves treating the application like a black box that produces output to input stimuli. The
tester feeds the application with inputs and observes the response. The input strings for the application are
crafted based on the results of dynamic analysis and the OWASP testing methodology. The application is
tested thoroughly with several well-crafted attacks to make sure the application can defend itself.
Static Analysis & Code Review
Static analysis and code review covers the analysis of the application code and coding defects. The code of
the application is analyzed using static analyzers. The code is reviewed manually and checked for
vulnerabilities that may arise due to poor coding practices.
With static analysis, the business logic and the security of the application are covered. The code reviewer
tests the application for each taint location in the application.

© Copyright IBM Corp. 2016 4-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Identifying and protecting IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Describing identifying and protecting data in mobile devices

– Identify Sensitive Data?
– Protecting Data - Things to Remember

© Copyright IBM Corporation 2016

Figure 4-17. Identifying and protecting

Identifying and Protecting Data in Mobile Devices

Identification and protection of sensitive data on a mobile device is an important aspect of mobile application
development. Mobile devices are expected to replace desktop computers in the near future. With
improvements in technology, mobile devices have managed to scale up to match the complex computing
capabilities of a desktop computer. From management of email account credentials to control of automobiles,
mobile phones can do it all today.
Hackers attack an application with the intention to derive certain value. The more valuable the target is, the
more prone it is to attacks. For developers, the data contained in the application is valuable. Every piece of
data that the application handles is significant and developers must handle it with care. Protection of data
should be one of the primary goals of a mobile developer.
The close interaction with an operating system allows the application on devices to access more data than a
browser on a computer. This helps to build innovative features into the application. The data is vulnerable
when the entire application is not developed by the same team. There may be APIs and code from other
sources; some applications tend to be interconnected. These possibilities cause the data in the application to
leak. Additionally, third-party services such as advertising are gaining ground. If these services are not
integrated carefully, it can lead to disclosure of significant amounts of personal data.
Mobile users are ignorant about the technical functionality of an application and assume that application data
is secure. Users usually install applications without verifying source and remain clueless about how the
application processes data.
Users remain unaware even when the application makes an external connection to the internet to process
the data. Hackers take advantage of user ignorance to exploit data on the devices.

© Copyright IBM Corp. 2016 4-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
How to Identify Sensitive Data?
Every piece of data is sensitive. Data cannot be classified as sensitive and non-sensitive. Users enter data
into an application under the assumption that security will not be compromised. Considering the importance
users give to data, applications should be designed to treat every little piece of user data as sensitive.

Examples of personal data users prefer to keep private:

• Their location
• Contacts
• Unique device and customer identifiers (such as IMEI, IMSI, UDID and phone number)
• Identity of the data subject
• Identity of the phone (make of the phone)
• Credit card and payment data
• Phone call logs, SMS or instant messaging
• Browsing history
• Email
• Information society service authentication credentials (especially services with social features)
Protecting Data - Things to Remember
• The data handled by an application should be protected from storage to transit
• Access to data being stored in another field is to be taken into consideration while handling data
• An important location where data leak can occur is the side channel data leakage
• Data should be logged or shown in error logs
• Each piece of code that handles data needs to be crafted carefully
• User data should be encrypted using smart algorithms before being stored on the device
• The encryption method should use a strong key
• The data stored on the device should be accessible only to the application that stores the data
• The data should not be given global read privileges leading to other applications residing on the device
• Whenever the data is transferred to other locations, such as a server, the application should use https

© Copyright IBM Corp. 2016 4-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Formidable App IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Describing the concept of formidable app

– Creating a Formidable App
– Steps to create a secure and powerful application

© Copyright IBM Corporation 2016

Figure 4-18. Formidable App

Creating a Formidable App

Developers creating mobile applications need to realize that the mobile application is only a part of the
system that attackers target. When an application is built, every piece of information that enters the
application needs to be validated. Some points that should be taken into consideration while developing a
formidable app are:
• User input should be considered, but not enforced while making security decisions
• The data stored on the device should be handled carefully to ensure that none of the information is
accessible even when the device changes hands
• The permissions set to the files and databases should ensure that application use is unique and should
be accessible only to the owner
• The user may install a malicious application accidentally. Such applications should not be able to access
the files and database of the developed application (Malicious applications enter the device when the
user installs application from untrusted sources)
Steps to Create a Secure and Powerful Application
The first step is to identify the data that is most critical to an application or a device – this can be done by
threat modeling the data before development. Consider all the data that the application uses, analyze the
data and identify the threat level associated with the data. Once the threat modeling is done, decide the level
of security that is required to protect the data.

© Copyright IBM Corp. 2016 4-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
Next, implement the level of security required to protect the data. During the coding phase the developer
writes necessary protection methods for the data. This includes validations on both client and server sides to
hashing and encryption of data. Security is embedded into the application without disturbing the business
logic of the application. The application works normally with all the security features embedded into it.
The third phase of the process is the testing of the application to verify all the implemented security and
application logic. Once the application is complete, it is subjected to thorough testing to analyze the quality of
the application.

© Copyright IBM Corp. 2016 4-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Security Testing Tools IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Explain the various security testing tools

– Qasat
– HashQ
– Android Emulator
– WebScarab
– WebSlayer

© Copyright IBM Corporation 2016

Figure 4-19. Security Testing Tools

Security Testing Tools

Qasat - Qasat is an Android static analyzer. The application helps code reviewers decompose an Android
Package File (APK) and understand the application better. The analyzer decomposes an APK file into its
components. The assets in the applications are enumerated as lists. Qasat also enumerates code fragments
that are considered sensitive. Qasat allows the user to save the code into a location of their choice. This
helps the code reviewer to review the code.
HashQ - HashQ is a tool used to list out difference between two applications of the same type (JAR/APK).
Built on pure shell scripts and the GUI called Yad, HashQ highlights the file-level differences between the
applications under analysis.
Android Emulator - Android Emulator is an application that emulates and tests virtual android devices.
Applications can be installed on virtual machines and used as if they are installed on a real device. Emulator
is free to download and easy to install. The emulator is also included in the Android SDK.
WebScarab - WebScarab is an intercepting proxy used to monitor conversations between a client and
server. Intercepting proxy is used to watch the outgoing and incoming traffic from a device. The conversations
and server headers from responses can be viewed in detail.
WebSlayer - WebSlayer is a tool used to fuzz applications to test different values for parameters. This helps
a tester to test a large number of parameters at a time.
Other Penetration Testing Tools - There are lot of other penetration testing tools (Fuzzers, Crawlers,
Spiders and others) and scripts that are used to attack applications.

© Copyright IBM Corp. 2016 4-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Real-Time Examples IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Following are the real time examples:

– Rogue Instagram Application
– DroidDream

© Copyright IBM Corporation 2016

Figure 4-20. Real-Time Examples

Real-Time Examples
Wikipedia defines a user as “an agent, either a human agent (end-user) or software agent, who uses a
computer or network service.” Most users download and use the service, and remain clueless about the
technicalities involved in development.
The only thing that most users care about while using an application is its utility. Any additional feature or
functionality is a plus.
In reality, a mobile application can perform any function desired from it without the end user’s knowledge.
Malicious applications get installed on the device without warning. In many cases, the web application that
provides the user with the installer is not legitimate.
There are stores from which users can download applications. Google Play is an example of a legitimate
store. The applications in such stores are subjected to thorough code review and analysis and suspicious
apps are barred.
In most cases, users are not aware of the damage malicious applications can cause. From sending premium
SMSs to leaking mails and contacts details, a malicious application is capable of plenty of damage.
There are numerous examples of malicious clones of well-known applications available on third-party sites.
Rogue Instagram Application
The fake Instagram application was distributed through a Russian website. The application was designed to
send SMS to premium numbers yielding revenue to its creators. The scam was so convincing that users were
unable to distinguish between the fake and real app. Suspicions arose only when cell phone bills spiked.

© Copyright IBM Corp. 2016 4-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty
DroidDream
DroidDream is a Trojan attack that is hidden within legitimate looking Android apps. It is considered more
intrusive than other malicious components as it has broken into Android application stores.
DroidDream lives up to its name. The application is designed to infect the device during sleep time – between
11 PM and 8 AM.
Once the infected device is rooted, DroidDream searches for the package
“com.android.providers.downloadsmanager.” If the package is not installed, DroidDream installs a second
malicious app. Other malicious applications can be installed from the DroidDream command and control
servers. DroidDream passes on a lot of information to the command and control center. This includes IMEI,
IMSI, device model, SDK version, language, country, and user ID.
Some of the other malicious applications are listed below. Some of them are based on the Trojan
DroidDream.
• Falling Down
• Super Guitar Solo
• Super History Eraser
• Photo Editor
• Super Ringtone Maker
• Super Sex Positions
• Hot Sexy VideosChess
• Livelocker
• TDT direct to TV
• Mera live TV
• PhotoShop tutorials Free
• Dealers Scale lite
• Cute wallpapers
• Beach wallpapers
• Android video converter
• TV by Zurera
• owling Time
• Advanced Barcode Scanner
• Super Bluetooth Transfer
• Task Killer Pro
• Music Box
• Sexy Girls: Japanese
• Sexy Legs
• Advanced File Manager
• Magic Strobe Light

© Copyright IBM Corp. 2016 4-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
1. Which component of the system security defines which sorts of Internet communications will be
permitted into the corporate network, and which will be blocked?
A. Web Browser
B. Firewalls
C. Load Balancers
D. None of the above
2. Which of the following statements is/are NOT true about Secure Socket Layer?
A. Provides secure communications over intranets and the Internet
B. In SSL communication between two entities, such as companies or individuals, the server has a
public key and an associated private key
C. SSL uses both asymmetric and symmetric encryption to communicate
D. All of the above statements are true
3. In which attack, the attacker places packet-sniffing tools on the network to capture traffic?
A. Network eavesdropping
B. Unauthorized access
C. Trojan horses
D. Worms

© Copyright IBM Corporation 2016

Figure 4-21. Checkpoint

© Copyright IBM Corp. 2016 4-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
4. Which of the following cannot be identified as security objectives for application server?
A. Authentication
B. Authorization
C. Data Protection
D. All of the above
5. When services available and software versions pertaining to an application server are given away
due to banner grabbing, it corresponds to which threat?
A. Banner threat
B. Worm
C. Unauthorized access
D. None of the above
6. Choose the correct alternative from the following
Assertion (A): Load balancer ensures consistent application availability, even when one or more server
fails
Reason (R): Load balancer distributes an application’s load over many identically configured servers
A. Both A and R are true and R is the correct explanation of A
B. Both A and R are true but R is NOT the correct explanation of A
C. A is false but R is true
D. Both A and R are false

© Copyright IBM Corporation 2016

Figure 4-22. Checkpoint

© Copyright IBM Corp. 2016 4-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
7. Which of the following statements is NOT true for SSL keys?
A. A symmetric encryption key (the bulk encryption key) is used to encode An asymmetric key (PKI
public key)
B. Asymmetric encryption has a performance cost due to its complexity
C. The bulk encryption key is used to encrypt subsequent communication
D. Both A and B
8. Choose the correct sequence of steps undertaken to negotiate an SSL session
W) The client creates a bulk encryption key, often a 128 bit RC4 key, using a specified
encryption suite.
X) The server sends the client its public key.
Y) The client encrypts the bulk key with the server's public key, and sends the encrypted
bulk key to the server.
Z) The server decrypts the bulk encryption key using the server’s private key.
A. WXYZ
B. XWYZ
C. ZXYW
D. XYZW

© Copyright IBM Corporation 2016

Figure 4-23. Checkpoint

© Copyright IBM Corp. 2016 4-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
9. Which of the following is/are NOT application scanner tool(s)?
A. Watchfire
B. SUCURI
C. AppScan24
D. Both A and B
10. Which of the following is an attack associated with unauthorized access?
A. Port scanning that detects listening services
B. Banner grabbing that gives away available services and possibly software versions
C. Malicious application input
D. All of the above

© Copyright IBM Corporation 2016

Figure 4-24. Checkpoint

© Copyright IBM Corp. 2016 4-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 4. Application Server Security

Uempty

Unit summary IBM ICE (Innovation Centre for Education)

IBM Power Systems

Having completed this unit, you should be able to:

• Get acquainted with various application server threats and countermeasures
• Get an overview of general application server security overview
• Get familiar with the Oracle application server security architecture
• Understand the need of application server security

© Copyright IBM Corporation 2016

Figure 4-25. Unit summary

© Copyright IBM Corp. 2016 4-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Unit 5. Database Server Security

Overview
This unit provides knowledge about the importance of database system security, the threats that are
witnessed and steps to secure database server

How you will check your progress

• Checkpoint

© Copyright IBM Corp. 2016 5-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Unit objectives IBM ICE (Innovation Centre for Education)

IBM Power Systems

After completing this unit, you should be able to:

• Get an overview of the need of database server security mechanisms
• Get familiar with the methodology of securing open source databases
• Understand the role of database administrator in securing database server
• Know the components of database security assessment

© Copyright IBM Corporation 2016

Figure 5-1. Unit objectives

© Copyright IBM Corp. 2016 5-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Introduction to Database Server Security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• A brief introduction of database server security and its importance

– Introduction
– Importance of Database Server Security

© Copyright IBM Corporation 2016

Figure 5-2. Introduction to Database Server Security

Introduction to Database Server Security

A database can be defined as a collection of data that is saved on a computer system’s hard drive.
Databases allow any authorized user to access, enter and analyse data quickly and easily. It’s a collection of
queries, tables and views. The data stored in the databases are usually organised to model aspects that
support processes that require information storage and retrieval. Major chunk of data is stored in the
repository called database. The user interface for databases is called a database management system.
DBMS are a software application that interacts with the authorised user, other applications and the database
itself to capture and analyse data. It helps to organize data for better performance and faster retrieval by
maintaining indices.
DBMS performs the function of concurrency control. DBMS also performs data recovery operations of
database. Now a day’s Enterprises need databases to store any type of data needed, because of the speed
and affordable cost database is popular among the enterprises. Advantage of using the database is it
automates different procedures, saving resources and man hours. For example, instead of manually verifying
transactions, users can rely on computer reports stored in the database. Instead of entering warehouse or
retail stock information manually, Hand held scanners can be used to save information in the database. A
database can provide efficiency and speed in the modern workplace.
Security in today’s world is one of the important and challenging tasks that people are facing all over the
world in every aspect of their lives. Databases are complex and many database security professionals do not
have full understanding of risk and security issues related to different databases. According to many IT
experts and DBAS, many enterprise DBAS are not aware of which databases, tables and columns contain
sensitive data because they are either handling legacy applications or there are no records or documentation

© Copyright IBM Corp. 2016 5-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
of the data models. Even with full knowledge of the database assets databases are harder to secure because
there are unique implementation and procedure for databases. We can say that database security is the use
of a wide range of data security controls to protect databases against any attacks (internal or external),
against compromises of database confidentiality, integrity and availability. The security involves different
types of controls like technical, administrative and physical controls. Similarly, security in electronic world has
a great significance. Protecting the confidential/sensitive data stored in a repository is actually the database
security. There are various security layers in a database. These layers are: database administrator system
administrator, security officer, developers and employee and security can be breached at any of these layers
by an attacker.
Importance of Database Server Security
Database servers are the foundation of virtually every Electronic Business, Financial, and Enterprise
Resource Planning (ERP) system, and frequently include sensitive information from business partners and
customers. In spite of the importance of preserving data integrity and security on these systems, databases
typically have not been subjected to the same level of security scrutiny as operating systems and networks.
Data integrity and improper access can be compromised by many factors, including complexity, insecure
password usage, misconfigurations, and unrecognized system backdoors, making imperative regular use of
an adaptive database server security solution.
Database servers are needed to protect access to an organization’s sensitive information and digital assets.
A large majority of any organization’s electronic digital assets are stored in off-the-shelf relational database
products. Businesses and government organizations use these database servers for personnel information
such as employee payroll and medical records for which they have responsibility for privacy and
confidentiality. Database servers hold sensitive financial data, past and future, including trading records,
business transactions, and accounting data. Strategic or classified information such as proprietary technical
and engineering data - even marketing plans - must be guarded from competitors and unauthorized internal
access. Database servers also include detailed customer information including financial accounts, credit
card numbers, and the trusted data of business partners.
Databases are extremely complex systems and difficult to correctly configure and secure. Database server
applications can be amazingly complex to master – on a level that rivals that of the operating systems they
run on. Database systems such as Oracle, Sybase, and Microsoft SQL Server include the following features:
user accounts and passwords, auditing systems, privilege model and specific permissions for control of
database objects, built-in commands (stored procedures/packages), unique scripting and programming
languages (usually vendor specific derivatives of SQL), middleware, network protocols, patches and service
packs, and powerful database management utilities and development tools.
Most DBAs have a full time job administering the complexities of these systems. As a result, serious security
vulnerabilities and misconfigurations frequently go unchecked or completely undetected. Therefore, just as
the traditional security community has mostly ignored the topic of database security, database professionals
usually don’ t consider security as one of their primary responsibilities. The philosophy of “Adaptive Network
Security” – viewing security as an ongoing “process” instead of a onetime checklist – has not yet been
embraced by many database administrators.
As Database domain increasing growth and the wide Internet has been revolutionized over many years, a
large number of people interact through information over the internet. There is strong need for information
security because of many factors. Database security concerns the use of a broad range of information
security controls to protect databases (potentially including the data, the database applications or stored
functions, the database systems, the database servers and the associated network links) against
compromises of their confidentiality, integrity and availability. It involves various types or categories of
controls, such as technical, procedural/administrative and physical.
Security risks to database systems include, for example:
• Unauthorized or unintended activity or misuse by authorized database users, database administrators, or
network/systems managers, or by unauthorized users or hackers (e.g. inappropriate access to sensitive
data, metadata or functions within databases, or inappropriate changes to the database programs,
structures or security configurations.

© Copyright IBM Corp. 2016 5-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• Malware infections causing incidents such as unauthorized access, leakage or disclosure of personal or
proprietary data, deletion of or damage to the data or programs, interruption or denial of authorized
access to the database, attacks on other systems and the unanticipated failure of database services.
• Overloads, performance constraints and capacity issues resulting in the inability of authorized users to
use databases as intended.
The present invention is for developing a secure process for the managing the database within the
organization. When database is deployed to store financial and personal data, the real need for high security
is felt. This invention uses the concept of Dynamic certificates to provide security to database. This
DB-Certificate process will provide a mechanism to assign digital certificates to its user according to their
designation/ level in the organization. These certificates will contain the types and list of queries which the
user can execute on the database. This will help in implementing security principle as well as granting and
revoking privileges to/from the accounts. Only after verifying the authenticity of the certificate, the authorized
part of the database can be accessed by using the list of the queries attached with the certificate.
The security protocol is comprises of a client machine to request and use certificates while communicating
across the network and a server machine that manage issuance and the maintenance of security certificates.
The server machine receives request for a certificate from a client machine. There are a set of some
predefined protocols to process these requests. A central certification authority (CA) is a trusted party which
provides certificates when receive requests from the client. The CA has a set of predefined policies which are
implemented to generate these certificates. These set of policy engines has at least one policy which is
configured as a software element, for e.g. a Java bean can be used to perform the various distinct functions
defined in the policy and generates notifications as a response. The certificate is generated dynamically each
time when the client requests. This prevents the certificates from hackers. Each level of user has a certificate
which will contain the types and list of queries which the user can execute on the database. This will help in
implementing security principle as well as granting and revoking privileges to/from the accounts. Only after
verifying the authenticity of the certificate, the authorized part of the database can be accessed by using the
list of the queries attached with the certificate.
The dynamically generated digital certificate validation method of a client connectable in communication with
a host is provided. The very first connection is made up with the host to establish data communication within
the host. Also, a request for a certificate validation result is sent back to the host. Then a file containing the
requested certificate validation result is imported from the host and the imported file is stored locally for later
retrieval of at least the requested certificate validation result.

© Copyright IBM Corp. 2016 5-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Architecture for Database Systems IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the Architecture for Database Systems and it provide:

– Independence of data and programs
– Ease of system design
– Ease of programming
– Powerful query facilities
– Protection of data

Direct connection with database server

© Copyright IBM Corporation 2016

Figure 5-3. Architecture for Database Systems

Architecture for Database Systems

Software systems generally have an architecture, i.e. Possessing of a structure (form) and organization
(function). The former describes identifiable components and how they relate to one another structurally; the
latter describes how the functions of the various structural components interact to provide the overall
functionality of the system as a whole. Since a database system is basically a software system (albeit
complex), it too possesses an architecture. A typical architecture must define a particular configuration of and
interaction between data, software modules, meta-data, interfaces and languages. The architecture of a
database system determines its capability, reliability, effectiveness and efficiency in meeting user
requirements. But besides the visible functions seen through some data manipulation language, a good
database system architecture should provide:
• Independence of data and programs
• Ease of system design
• Ease of programming
• Powerful query facilities
• Protection of data
As new computing methods have evolved, different methods of transferring the data between the database
systems and the end users have been also evolved. For database-backed up systems, there are three most
common architectures as follows:
• A direct link to the computer which performs all the work

© Copyright IBM Corp. 2016 5-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• A client/server (two-tier) architecture
• A thin client (three-tier) architecture
In the first architecture, the database(s), database software, program code, and all other resources located
on one local machine.

In the second architecture, the database server and the database and other resources are placed at one
location while the code for application is placed on a client machine or on their personal computer. In this
architecture, queries are carried to the server machine and the resultant data is carried back to the client’s
machine by pre-defined queries. Queries are processed on the database server, while rest part is done on
the workstation. The processing at workstation mostly includes managing the user interface and display, and
the application processing which is independent of the database Direct connection with database server

The latest type of architecture is more efficient and uses a low capacity workstation as a first tier. The
workstation does not run the application really. It only manages display of the GUI and taking user inputs. It
processes the requests by downloading whole code onto the client machine. The second tier in this is the
Application Server. It executes and holds the applications using some programming language and
communicates with the workstations. The applications that executes on this server machine communicate
with the third tier and server database by using the protocols for the databases. Where security concerns, the
three-tier architecture is very useful in many ways. It requires higher security requirements on the application
server, minimal security requirements at the client side and changing number of security requirements at the
back-end server databases.

In general, the goals of database security are:

• Confidentiality and secrecy: Data should not ever be revealed to anyone who is not authorized to access
it
• Authentication, accuracy and integrity: It means that data cannot be modified maliciously or corrupted
intentionally. Authenticity provides an easy way to user verify the original location of the data
• Recoverable and availability: Systems should continue working, and the lost data could be recovered
easily, efficiently and in the original form

© Copyright IBM Corp. 2016 5-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Database attacks,security & lifecycle IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Defining the different database attacks and security

– Insider Threat
– Login Attacks

© Copyright IBM Corporation 2016

Figure 5-4. Database attacks,security & lifecycle

Attacks on Database
Two kinds of attack can be made to the databases; physical attack and the logical attack. Physical attacks
can include forced disclosure of sensitive information like passwords, demolition of storage devices in
system, complete power failure, and theft of secured information. To prevent these kinds of attacks, common
way is to limit the access to all the storage devices and keeping the backup and recovery procedures safe.
While logical threats are intentionally or unauthorized access to sensitive information. This is usually done
through software. Logical threats can lead to denial of service (DOS) attack, disclosure of sensitive
information, and tempering of data.
Insider Threat
Corrupt authorized user can harm the system. These kinds of users can legitimately access the confidential
information and misuse it. This confidential information can be exposed electronically, through print outs to
the outer organizations. To prevent information from within the organization is very difficult. Mandatory access
controls are required to hide data from unauthorized users. This kind of attack is usually taken care by limiting
the number of users at different levels of access. Complicated procedures can also be used to address them.
Login Attacks
Another more popular way to damage a database is to login successfully to the system as a valid user.
Passwords can be stolen physically or by monitoring network traffic continuously for login data. Also,
password lists can be accessed which are stored in the files of operating system. If password is easy to
guess, there are full chances of system damage. Restrictions on passwords can be done to prevent from
loss, but it does not completely solve the problem. The database administrator must employ encryption
mechanisms and authentication procedures to prevent this kind of attacks.

© Copyright IBM Corp. 2016 5-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Database Security
Securing the network and operating system on a database server is critically important, but insufficient to
protect that database server. This is a common misconception among experienced security professionals,
who assume that, once they have assessed and locked down critical network services and operating system
vulnerabilities, all applications on those servers will also be secured. Modern database systems have a wide
array of features and capabilities that can be misused or exploited to compromise the confidentiality,
availability, and integrity of data. To begin with, all modern relational database systems are “port
addressable,” which means that anyone with readily available query tools can attempt to connect directly to
the database, bypassing security mechanisms used by the operating system. For example, Oracle 7.3 and 8
can be accessed via TCP/IP on their default ports of 1521 and 1526. Most database systems also have
well-known default accounts and passwords, which provide varying levels of access to database resources.
These two simple data points combined could probably compromise an embarrassingly large number of
critical database systems. Unfortunately, the opportunities to compromise database security does not end
there for knowledgeable intruders.
Poor database security not only compromises the database, but the server operating system and other
trusted systems, too. This is another not-so-obvious reason why database security is important - a
database system may itself provide the mechanism to compromise an entire network’ s security
infrastructure. As an example, a company may have a database server that keeps an inventory of all
technical manuals, documentation, and white papers. The information in the database is not considered
mission critical, so its security is not a priority. Even running on a well-secured operating system, an intruder
could use access to the database to gain access to the local operating system through powerful built-in
database features such as “extended stored procedures.” These procedures can give Administrator-level
command line access to the underlying operating system and full access to all of its resources. If this
particular database system has trust relationships with other servers, the intruder could potentially
compromise the security of the entire network domain.
Databases are foundation of new Electronic-Business, Enterprise Resource Planning (ERP) and other critical
business systems. While much of the focus of E-Commerce and E-Business is on Web servers, Java, and
other emerging technologies, it is important to remember that the vast majority of these consumer-oriented
and business-to-business systems are based on relational databases behind the Web servers. Security in
these systems is directly related to systems availability, data and transaction integrity, and confidentiality.
Downtime and lack of system availability can be damaging not only to a business, but also to a company’s
reputation. By necessity, these systems are more open to the dangers of intruders, yet the responsibility for
confidentiality of business partners and customers ’sensitive information has never been greater. In addition,
ERP and management systems such as SAP R/3 and PeopleSoft are built on these same standard database
systems. Unmanaged security vulnerabilities have a direct correlation with costly downtime, system integrity
issues, and customer confidence.
Database security can be divided into the following key points:
• Server Security, Database Connections, Table Access Control
• Restricting Database Access
All of these issues need to be considered when securing database servers.
Database security lifecycle
Database assessment represents the first step within a complete database security life cycle. Three
subsequent steps build upon the results of the assessment.
• Set Policies / Controls - With a complete assessment of database risk and user profiles available as
guidance, the administrator is in a position to define audit and security policies or “controls”. These
policies specify allowed behavior, disallowed behavior, and specifically regulated transactions.
• Monitor and Enforce - Database activity is monitored and enforced according to policy. Audit data is
collected and violations optionally trigger real-time response.
• Measure – Reporting systems measure the results of the previous three phases of the cycle. Reports
serve as a feedback loop for adjusting the lifecycle and help communicate results to auditors and
management.

© Copyright IBM Corp. 2016 5-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Need of Database Server Security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Following are the database vulnerabilities

– Lack of security feature maturity Login Attacks
– Database Password Management
– Oracle Internal Password
– Oracle Listener Process password
– Oracle Internal Password - “orapw” File Permission Control
– Operating system back doors
– Auditing
– Trojan Horses MS SQL
Sybase Oracle 7 Oracle 8
Server
Account Lockout
No No No Yes
Facility
Rename Admin
No No No No
Account
Require Strong
No No No Yes
Passwords
Stale Accounts No No No No

Password Expiration No Yes No Yes

Login Hours
No No No No
Restriction
© Copyright IBM Corporation 2016

Figure 5-5. Need of Database Server Security

Need of Database Server Security

Database Vulnerabilities
Traditional database security focuses only on user accounts, roles, and operating permissions on specific
database objects, such as access to tables and stored procedures. A thorough security analysis of a
database system must be much broader, assessing potential vulnerabilities in all possible areas, as broadly
outlined in the categories below.
• Risks associated with vendor-supplied software - bugs, missing operating system patches,
vulnerable services and insecure choices for default implementations and configurations.
• Risks associated with administration - security options available but not used correctly, risky default
settings, improper granting of excessive privileges to users or unauthorized changes to the system
configuration.
• Risks associated with user activity - insufficient password strength, inappropriate access to critical
data and malicious activities such as stealing contents of databases.
These categories of risk can apply to network services, operating systems, or the actual databases
themselves. All of these elements need to be considered when securing database servers.
Listed below are a few examples of the wide variety of database server vulnerabilities and misconfigurations
that can exist in critical database servers.
Lack of security feature maturity - Most popular relational database systems have been in existence for
well over ten years and are mature products with powerful feature sets and scalability. Unfortunately, many

© Copyright IBM Corp. 2016 5-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
features that IT and security professionals require and take for granted in operating systems and networks
are simply not available in most of the popular database systems in use today.
For example, the table lists features that most IT professionals would expect or require in an operating
system, but are not present in a database server’ s standard security offerings. Since these databases are
port addressable, the core operating system security mechanisms are not applied to direct network
connections to the database. Some products, such as Microsoft SQL Server, allow the more powerful
Windows NT security mechanisms to address some of the shortcomings listed. However, the majority also
run MS SQL Server standard security for backward compatibility in environments that are not 100% Windows
NT. Implementation is another concern.
The combination of several of these features makes the implications even more serious. Since System
Administrator accounts (“SA” for SQL Server and Sybase, and “system” and “sys” for Oracle ) can’t be
renamed, and if there is no password lockout available or configured, intruders can launch brute force
dictionary login attacks against the database server with nothing to prevent them from patiently and
persistantly trying to break into the server at the highest level access.
Database Password Management - In the standard security provided by most database systems, there is
no mechanism to ensure that individual users are choosing strong – or any – passwords. This fundamental
security issue requires careful monitoring. There is also the additional issue of managing and securing a
whole list of additional system passwords. For example, Oracle database systems have over ten specific
default user accounts and passwords, and additional unique passwords for managing critical database
operations such as booting the Oracle database, access to the network listener process and remote
database access privileges. If compromised, many of these system passwords would give an intruder full
access to the database system, yet they are stored in ordinary text files on the operating system. A few
examples:
Oracle Internal Password - the Oracle Internal password is stored in clear text within the following file
“strXXX.cmd”, where XXX is the Oracle System ID or SID, which defaults to “ORCL”. The Oracle Internal
Password is used for Oracle database start-up processes, and gives complete access to database
resources. This file needs be properly secured for Windows NT based Oracle implementations.
Oracle Listener Process password - Password used to start and stop Oracle listener process, which routes
all incoming traffic to appropriate Oracle instances on a system. A strong password needs to be chosen for
this value to replace the system default, and the permissions must be secured on the “listener.ora” file, where
the password is stored for all Oracle implementations. Improper access to this password could allow an
intruder to create a Denial of Service attack on an Oracle based electronic business site.
Oracle Internal Password - “orapw” File Permission Control - Oracle Internal password and passwords
of accounts granted the SYSDBA role are stored in the “orapw” text file. Privileges to this file should be
restricted on Unix and Windows NT implementations of Oracle even though it is encrypted. If accessed, the
encrypted file is potentially vulnerable to brute force attacks.
These are just a few examples of how critical administrator and system passwords and accounts can be
compromised in unexpected ways. Please note that password management security issues are by no means
unique to the Oracle database environment, and apply to virtually all major database vendors.
Operating system back doors - Most database systems have powerful features that, while convenient for
DBAs, are also potential backdoors into a database server’ s host operating system.
As mentioned previously, an intruder who has compromised a Sybase or SQL Server “sa” password can
potentially gain system rights to the underlying operating system by using “extended stored procedures”. By
logging in as ‘sa’ , an intruder has use of the extended stored procedure xp_cmdshell, which allows a Sybase
or SQL Server user to run an operating system command as if that person was running a command prompt at
the server console. As an example, the following SQL commands can be used to add a Windows NT
account called ‘hacker1’ with a password of ‘nopassword’, and then add ‘hacker1’ to the
‘Administrators’group:
xp_cmdshell ‘ net user hacker1 nopassword /ADD’ go
xp_cmdshell ‘ net localgroup /ADD Administrators hacker1’ go

© Copyright IBM Corp. 2016 5-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Now the unscrupulous intruder is a Windows NT Administrator (let’ s hope this SQL Server is not on a domain
controller). This simple attack works because the commands are submitted to the operating system using the
Windows NT account under which the MSSQLServer service runs under. By default, this is the ‘LocalSystem’
account, which is the most powerful account on the local Windows NT system. Another way a hacker might
use SQL Server to compromise the operating system’ s security is by using the stored procedure xp_regread
to read the encrypted Windows NT SAM password database out of the registry. There are several free
Windows NT password crackers that make it important to keep these encrypted Windows NT passwords
secure. Below is an example of how an intruder can get at this information:
xp_regread ‘ HKEY_LOCAL_MACHINE’ ,‘ SECURITY\SAM\Domains\Account’ , ‘ F’
Note that reading the encrypted passwords out of the registry is something even the local Windows NT
“Administrator” account cannot do. SQL Server allows this data to be read from the registry because SQL
Server by default runs using the ‘LocalSystem’ account.
Oracle database systems also include powerful features that can be used to gain direct access to the
operating system’ s native file system. For example, with proper access, the UTL_FILE package allows
users to read and write files to the host operating system. The UTL_FILE_DIR profile variable can be
misconfigured or intentionally set to allow Oracle users to use the UTL_FILE package to write anywhere in
the file system, which also has the potential to compromise the host operating system.
Auditing - The depth of information and events that can be recorded by the auditing systems of relational
database systems varies from basic to very granular and detailed, but auditing systems only provide valuable
security and alerting information if properly used and configured. These features can provide early warning
signs that intruders are compromising the security of specific database servers, and provide valuable clues
for detecting and repairing any damage.
Trojan Horses - Trojan horses in operating systems have been around for years, but Database
Administrators need to be aware of the threat they pose to system stored procedures. One well-known
Trojan Horse modifies the password changing stored procedure, notifying the intruder of new passwords as
they are updated. For example, an individual can add several lines to the sp_password system stored
procedure to log new passwords to a table, send the password in an e-mail, or write the password to an
external file for later review. This procedure continually grabs passwords until the intruder catches the “SA”
password being changed – leading to the accomplishment of further break-ins going undetected. An intruder
or disgruntled employee only needs to gain access to a system once to place this trojan horse and steal a
stream of future passwords.

© Copyright IBM Corp. 2016 5-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Database Server threats &

countermeasures IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Following are the database vulnerabilities

– SQL Injection
– Network Eavesdropping
– Unauthorized Server Access
– Password Cracking

© Copyright IBM Corporation 2016

Figure 5-6. Database Server threats & countermeasures

Database Server Threats and Countermeasures

SQL Injection
With a SQL injection attack, the attacker exploits vulnerabilities in the application's input validation and data
access code to run arbitrary commands in the database using the security context of the Web application.
Vulnerabilities
Vulnerabilities exploited by SQL injection include:
• Poor input validation in your Web applications
• Unsafe, dynamically constructed SQL commands
• Over?privileged application logins to the database
• Weak permissions that fail to restrict the application's login to the database
Countermeasures
To counter SQL injection attacks:
• Application should constrain and sanitize input data before using it in SQL queries.
• Type safe SQL parameters for data access should be used. These can be used with stored procedures
or dynamically constructed SQL command strings. Using SQL parameters ensures that input data is
subject to type and length checks and also that injected code is treated as literal data, not as executable
statements in the database.

© Copyright IBM Corp. 2016 5-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• SQL Server login that has restricted permissions in the database should be used. Ideally, execute
permissions should be granted only to selected stored procedures in the database and provide no direct
table access.
Network Eavesdropping
The deployment architecture of most applications includes a physical separation of the data access code
from the database server. As a result, sensitive data, such as application?specific data or database login
credentials, must be protected from network eavesdroppers.
Vulnerabilities
Vulnerabilities that increase the likelihood of network eavesdropping include:
Insecure communication channels
Passing credentials in clear text to the database; for example:
• Using SQL authentication instead of Windows authentication
• Using SQL authentication without a server certificate
Countermeasures
To counter network eavesdropping:
• Windows authentication should be used to connect to the database server to avoid sending credentials
over the network.
• A server certificate should be installed on the database server. This results in the automatic encryption of
SQL credentials over the network.
• An SSL connection should be used between the Web server and database server to protect sensitive
application data. This requires a database server certificate.
• An IPSec should be used encrypted channel between Web and database server.
Unauthorized Server Access
Direct access to database server should be restricted to specific client computers to prevent unauthorized
server access.
Vulnerabilities
Vulnerabilities that make database server susceptible to unauthorized server access include:
• Failure to block the SQL Server port at the perimeter firewall
• Lack of IPSec or TCP/IP filtering policies
Attacks
Direct connection attacks exist for both authenticated users and those without a user name and password; for
example:
• Tools such as Query Analyzer or the command line equivalent are used to establish a direct connection
to SQL Server and issue commands.
• Server information, such as software version, is revealed to an attacker who sends carefully constructed
packets to listening ports.
Countermeasures
To counter these attacks:
• It should be made sure that SQL Server ports are not visible from outside of the perimeter network.
• Within the perimeter, direct access must be restricted by unauthorized hosts, for example, by using IPSec
or TCP/IP filters.
Password Cracking
A common first line of attack is to try to crack the passwords of well known account names, such as SA (the
SQL Server administrator account).

© Copyright IBM Corp. 2016 5-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Vulnerabilities
Common vulnerabilities that lead to password cracking are:
• Weak or blank passwords
• Passwords that contain everyday words
Attacks
Common password cracking attacks include:
• Dictionary attacks
• Manual password guessing
Countermeasures
• To counter these attacks:
• Passwords should be created for SQL Server login accounts that meet complexity requirements.
• Passwords that contain common words found in the dictionary should be avoided.

© Copyright IBM Corp. 2016 5-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Acquiring Database and Server Security IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the database acquiring and server security mechanisms

– NAT and PAT
– A demilitarised zone (DMZ)
– Content-based firewalls
– SSL connections
– IPSec security

Database server farm

© Copyright IBM Corporation 2016

Figure 5-7. Acquiring Database and Server Security

Acquiring Database and Server Security

Securing database servers needs administrators to go the extra mile in terms of technical design efforts. It is
a job to be carried out by sysadmins as well as database admins, to cover all the network layers. Often, the
practice is to assume that using OS-level user administration and leveraging the product’s built-in security is
enough to protect databases.
Unfortunately, this is not true. While the user- and role-based models with strong passwords for SA accounts,
etc., are essential, they exist only at the application layer; relying on them alone defeats the purpose of
securing databases.
The technical reason behind why legacy methods fail is because a database is a widely and continuously
accessible component, which makes it more vulnerable and susceptible to attacks. Database security
requirements touch all networking layers, and hence, need careful design.
As an example, consider a database server that accepts connections from within the corporate network as
well as from outside. It is accessed programmatically by the frontend software, as well as directly by admin
and development staff to run queries, etc. It is accessed by backup services, anti-virus servers, and other
maintenance-based utilities, and thus is widely accessible.
Any of these human or automated means of accessing the database server make it vulnerable to possible
attacks originating at various networking touch-points. The latest spyware, and vulnerabilities that revolve
around the infamous SQL-injection method, prove that something needs to be done beyond these legacy
methods.

© Copyright IBM Corp. 2016 5-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
This is exactly where the security mechanisms and solutions that span the lower layers in the networking
model come into the picture.
NAT and PAT
Using Network Address Translation (NAT) and Port Address Translation (PAT) is the first recommended step.
Since database products use predefined default ports, it is the first thing hackers look for, and hence should
be changed. Even though the database IP address and port is not exposed to the outside world, it is a best
practice to change it, to keep spyware and viruses away. Any standard firewall nowadays provides NAT and
PAT features.
A demilitarised zone (DMZ)
The database server is not exposed to the Internet, but is separated from it by an additional firewall. This
design method is well-known, and is called a demilitarised zone (DMZ). In earlier days, it was a practice to
keep database servers in the same network as the frontend/Web application servers, making them prone to
attacks. An additional layer of security is now achieved by the second firewall, which opens up only the
database port for the frontend servers, and not the IP addresses of the entire Internet. If the database carries
mission-critical datasets of sensitive information, this method can be clubbed together with the NAT-PAT
method, making it even harder for malware to breach the database server.
Content-based firewalls
The latest firewall products are equipped with the capability to look into the data packets owing in either
direction, and provide systems administrators a means to configure actions based on the intercepted content.
These firewalls are capable of reading SQL queries, query data, validation data, XML data, etc. Deploying
such a firewall can certainly reduce virus attacks drastically, because data packets pertaining to ill-behaved
operations are dropped and reported.
SSL connections
While SSL technology is commonly used to secure Web-server connections to browsers, it can also be used
between frontend servers and the backend database server. SSL uses public-key and private-key
cryptography to encrypt all connections between caller and listener. While this solution is a bit costly and
takes a toll on data transfer speeds, it is worth the effort to alleviate man-in-the-middle attacks.
IPSec security
The real challenge while securing a database server is to figure out who should access it. In terms of people,
it is as simple as deploying user-ID and password-based access. However, if the network is compromised by
a hacker, this won’t help much. A further step, in such a case, would be to deploy IPSec security, whereby
each server will connect to the database server using an IPSec token, making it a unique and non-crackable
connection.

© Copyright IBM Corp. 2016 5-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Securing Open Source Databases IBM ICE (Innovation Centre for Education)
IBM Power Systems

• How to secure open source database and its methodology

– Patches and Updates
– Services
– Protocols
– Accounts
– Files and Directories
– Shares
– Ports
– Registry
– Auditing and Logging
– SQL Server Security
– SQL Server Logins, Users, and Roles
– SQL Server Database Objects

© Copyright IBM Corporation 2016

Figure 5-8. Securing Open Source Databases

Securing Open Source Databases

A database administrator always carries out the essential chores to secure a database; however, for
Linux-based open source solutions, a little extra effort is required. While there is no single solution to cover all
open source database distributions, there are a few good tools for each.
A popular open source database is MySQL, which is used by many commercial websites as their backend.
MySQL comes with the necessary scripts to harden the server from the security perspective, such as scripts
to remove test databases, lower system and database privileges, enable the built-in Linux firewall to
configure default database ports and block others, etc.
MongoDB and CouchDB are two famous database servers running on Apache distributions. Both come
equipped with the great feature of IP binding, whereby the database kernel services are bound to one single
IP. Adding an open source content firewall or a NAT-PAT solution can help create a very cost-effective and,
yet, secure database farm.
The Hypertable open source database, which is modelled after Google’s BigTable DB structure, provides an
extensive library of API calls that are used exclusively for adding security features. It is easy to write scripts
using those API calls, to securely deploy and configure Hypertable distributions in a big server farm.
Unlike Microsoft SQL Server, Oracle and Sybase products, while designing security for open source
products, it is important to incorporate a combination of network security methods, as well as the database
product’s application-layer security.
Methodology for Securing Server

© Copyright IBM Corp. 2016 5-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
The securing methodology has been organized into the categories which are based on best practices
obtained from field experience, customer validation, and the study of secure deployments.
The rationale behind the categories is as follows:
Patches and Updates
Many security threats exist because of vulnerabilities in operating systems, services, and applications that
are widely published and well known. When new vulnerabilities are discovered, attack code is frequently
posted on Internet bulletin boards within hours of the first successful attack. Patching and updating your
server's software is the first step toward securing your database server. There may be cases where a
vulnerability exists and no patch is available. In these cases, the details of the vulnerability to assess the risk
of attack and take measures accordingly should be known.
Services
Services are prime vulnerability points for attackers who can exploit the privileges and capabilities of the
service to access the server and potentially other computers. Some services are designed to run with
privileged accounts. If these services are compromised, the attacker can perform privileged operations. By
default, database servers generally do not need all services enabled. By disabling unnecessary and unused
services, the attack surface area can be quickly and easily reduced.
Protocols
Limit the range of protocols that client computers can use to connect to the database server and make sure
you can secure those protocols.
Accounts
Restrict the number of Windows accounts accessible from the database server to the necessary set of
service and user accounts. Use least privileged accounts with strong passwords in all cases. A least
privileged account used to run SQL Server limits the capabilities of an attacker who compromises SQL
Server and manages to execute operating system commands.
Files and Directories
Use NTFS file system permissions to protect program, database, and log files from unauthorized access.
When you use access control lists (ACLs) in conjunction with Windows auditing, you can detect when
suspicious or unauthorized activity occurs.
Shares
Remove all unnecessary file shares, including the default administration shares if they are not required.
Secure any remaining shares with restricted NTFS permissions. Although shares may not be directly
exposed to the Internet, a defense in depth strategy with limited and secured shares reduces risk if a server
is compromised.
Ports
Unused ports are closed at the firewall, but it is required that servers behind the firewall also block or restrict
ports based on their usage. For a dedicated SQL Server, block all ports except for the necessary SQL Server
port and the ports required for authentication.
Registry
SQL Server maintains a number of security?related settings, including the configured authentication mode in
the registry. Restrict and control access to the registry to prevent the unauthorized update of configuration
settings, for example, to loosen security on the database server.
Auditing and Logging
Auditing is a vital aid in identifying intruders, attacks in progress, and to diagnose attack footprints. Configure
a minimum level of auditing for the database server using a combination of Windows and SQL Server
auditing features.
SQL Server Security

© Copyright IBM Corp. 2016 5-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
A number of SQL Server security settings can be controlled through Enterprise Manager. These include the
authentication mode, auditing level, and the accounts used to run the SQL Server service. For improved
security, you should use Windows authentication. You should also enable SQL Server logon auditing and
ensure that the SQL Server service runs using a least privileged account.
SQL Server Logins, Users, and Roles
SQL Server 2000 manages access control using logins, databases, users, and roles. Users (and
applications) are granted access to SQL Server by way of a SQL server login. The login is associated with a
database user and the database user is placed in one or more roles. The permissions granted to the role
determine the tables the login can access and the types of operations the login can perform. This approach is
used to create least privileged database accounts that have the minimum set of permissions necessary to
allow them to perform their legitimate functionality.
SQL Server Database Objects
The ability to access SQL Server database objects, such as built?in stored procedures, extended stored
procedures and cmdExec jobs, should be reviewed. Also, any sample databases should be deleted.

© Copyright IBM Corp. 2016 5-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Steps for Securing Database Server IBM ICE (Innovation Centre for Education)
IBM Power Systems

© Copyright IBM Corporation 2016

Figure 5-9. Steps for Securing Database Server

Steps for Securing Database Server (Windows 2000 and Windows Server 2003 and SQL Server 2000)
Step 1. Patches and Updates
Failure to apply the latest patches and updates in a timely manner means that there will be opportunities for
attackers to exploit known vulnerabilities. It should be verified that database server is updated with the latest
Windows 2000 / Windows Server 2003 and SQL Server service packs and updates.
Step 2. Services
To reduce the attack surface area and to make sure database is not affected by undiscovered service
vulnerabilities, disable any service that is not required. Run those services that remain using least privileged
accounts. In this step:
• Unused SQL Server services are disabled
• Microsoft DTC is disabled (if not required)
To disable a service, set its startup type to Disabled using the Services MMC snap?in in the Computer
Management tool.
Step 3. Protocols
By preventing the use of unnecessary protocols, the surface area of attack is reduced. Configure SQL Server
to support only clients that connect using the TCP/IP protocol. Disable all other protocols, unless required. In
this step:
• SQL Server is restricted to TCP/IP

© Copyright IBM Corp. 2016 5-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• TCP/IP Stack is hardened
Step 4. Accounts
The principle of least privilege for the accounts used to run and connect to SQL Server to restrict the
capabilities of an attacker who manages to execute SQL commands on the database server is reduced. Also
apply strong password policies to counter the threat of dictionary attacks.
In this step:
• The SQL Server service account is secured
• Unused accounts are deleted or disabled
• The Windows guest account is disabled
• The administrator account is renamed
• A strong password policy is enforced
• Remote logins are restricted
• Null sessions are disabled (anonymous logons)
Step 5. Files and Directories
In addition to securing operating system files using ACLs, NTFS permissions are hardened to restrict access
to SQL Server program files, data files, and log files together with system level tools. Additionally, the SQL
Server service account should have access only to what it needs. In this step:
• Verify permissions on SQL Server install directories are verified
• IT is verified that the Everyone group does not have permissions to SQL Server files
• Setup log files are secured
Step 6. Shares
Any unused shares should be removed and the NTFS permissions on any required shares must be
hardened. By default, all users have full control on newly created file shares. These default permissions are
hardened to make sure that only authorized users can access files exposed by the share. Also, NTFS ACLs
are used on files and folders exposed by the share in addition to explicit share permissions.
In this step:
• Unnecessary shares are removed
• Access to required shares is restricted
Step 7. Ports
By default, SQL Server listens on TCP port 1433 and uses UDP port 1434 for client?server negotiation. A
combination of firewalls and IPSec policies is used to restrict access to these ports to minimize the avenues
of attack open to an attacker.
In this step:
• Access to the SQL server port is restricted
• Named instances are configured to listen on the same port
• The firewall is configured to support DTC traffic (if necessary)
Step 8. Registry
When SQL Server is installed, it creates a number of registry entries and subentries that maintain vital system
configuration settings. It is important to secure these settings to prevent an attacker from changing them to
compromise the security of SQL Server installation.
In this step:
• Permissions for the SQL Server registry keys are verified
• The SAM (stand?alone servers only) are secured

© Copyright IBM Corp. 2016 5-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Step 9. Auditing and Logging
Auditing does not prevent system attacks, although it is a vital aid in identifying intruders, attacks in progress,
and to diagnose attack footprints. It is important to enable all auditing mechanisms at user’s disposal,
including Windows operating system level auditing and SQL Server login auditing. SQL Server also supports
C2 level extended auditing. This may be required in specific application scenarios, where auditing
requirements are stringent.
In this step:
• All failed Windows login attempts are logged
• All failed actions across the file system are logged
• SQL Server login auditing is enabled
Step 10. SQL Server Security
In this step:
• The SQL Server authentication is set to Windows only
• SQL Server audit level is set to Failure or All
• SQL Server is run using a least privileged account
Step 11. SQL Server Logins, Users, and Roles
To be able to access objects in a database, two layers of security checks are needed to be passed. First, a
valid set of login credentials is presented to SQL Server. If Windows authentication is being used, Windows
account should be used to connect, that has been granted a SQL Server login. If SQL Server authentication
is being, a valid user name and password combination should be supplied.
The login grants access to SQL Server. To access a database, the login must be associated with a database
user inside the database that is needed to be connected to. If the login is associated with a database user,
the capabilities of the login inside the database are determined by the permissions associated with that user.
If a login is not associated with a specific database user, the capabilities of the login are determined by the
permissions granted to the public role in the database. All valid logins are associated with the public role,
which is present in every database and cannot be deleted. By default, the public role within any database that
you create is not granted any permissions.
Following recommendations are used to improve authorization settings in the database:
• A strong SA (system administrator) password must be used
• The SQL guest user account should be removed
• The BUILTIN\Administrators server login should be removed
• Permissions for the public role should not be granted
Step 12. SQL Server Database Objects
SQL Server provides two sample databases for development and education together with a series of built?in
stored procedures and extended stored procedures. The sample databases should not be installed on
production servers and powerful stored procedures and extended stored procedures should be secured. In
this step:
• The sample databases should be removed
• Stored procedures should be secured
• Extended stored procedures should be secured
• cmdExec access should be restricted to the sysadmin role

© Copyright IBM Corp. 2016 5-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Best Practices to secure database server IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Database server secure practices and planning

– Strong Password Policy Execution
– Discard all Default Users and Demo-test Databases
– Change the Admin User Name
– User Privileges Need to be Restricted
– Disable Public Network Access to Database Servers
– Enforce SSL/TLS on Remote Connections and Restrict IP
– Check for Database Dumps in Public Locations
– Encrypt Your Application Files and Backups
– Web Application Firewall and Malware Scanner Should be used
– Always keep the Software Updated

© Copyright IBM Corporation 2016

Figure 5-10. Best Practices to secure database server

Best Practices to Secure Database Server

It may be the health records or credit card details; everything is stored in the form of database today.
Database is similar to a goldmine for hackers. The main purpose behind any cyber-attack is simply getting an
access to a database server.
This indicates that the security of the database servers needs to be strengthened and that completely
depends on network security, operating system hardening and physical security. It continues to be a big list
but it’s important to learn how to secure database server first.
• Strong Password Policy Execution
While creating a user, enforce database configuration to REQUIRE a strong password. Some servers have
built-in validation features, for example MSSQL has built-in password validation feature while some like
MySQL forces to install additional plugins (validate_password plugin). Execute a password policy that asks a
password length of 20+ characters and blocks dictionary words.
• Discard all Default Users and Demo-test Databases
No doubt all database servers come with few demo databases as well as users. These databases are public
information and therefore, anyone can access the server using these details to collect the database as well
as user information. These databases should be deleted immediately delete after user creates his own.
• Change the Admin User Name

© Copyright IBM Corp. 2016 5-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Suppose the attacker knows the admin user name, he can easily guess the password and gain access. Many
database servers set the admin username by default and then have to face the consequences. For example
– In the case of MySQL, it’s “root”. For additional security, it’s better to change the admin username.
• User Privileges Need to be Restricted
Usually, database users are created with access to all tables available in the database which is required only
in few cases. Access needs to be given to only minimum required tables and privileges (SELECT, INSERT,
etc.) should be limited to only what’s actually required by the user. This will help in preventing data loss even
after an exploit attempt.
• Disable Public Network Access to Database Servers
Business applications are stores in the databases. In a real world, the end users don’t need access the
database directly. It’s therefore essential to block all public network access to database servers unless you
are a hosting provider. Set up gateway servers (SSH tunnels or VPN) for your remote administrators.
• Enforce SSL/TLS on Remote Connections and Restrict IP
For a database hosting provider, remote connections are needed to be opened up. In such situations,
restricting connection by IP and enabling SSL/TLS encryption on database ports is a must.
• Check for Database Dumps in Public Locations
Leaving the database backups in publicly accessible locations like web folders, temporary partition, etc. is a
common mistake done by application owners. SQL dump files in public fodders can be detected by setting up
your monitoring system.
• Encrypt Your Application Files and Backups
The configuration files of your applications include database access information. If a hacker is able to access
the configuration file through application vulnerability, it’s very easy for him to enter the database. So, it’s
better to encrypt all application files and their backups for security.
• Web Application Firewall and Malware Scanner Should be used
In public facing web application, database servers are often “back end”. Therefore, attackers use the most
common way of web application exploits to access the databases. Set up Web Application Firewalls like
NAXSI, ModSecurity, etc. for blocking all common web application exploits. Additionally, these firewalls can
be integrated with malware scanners (ClamAV) to secure from sophisticated attacks propelled from within the
server.
• Always keep the Software Updated
As per Google, it detects 11,000 infected websites per day and majority of these infections are caused due to
application vulnerabilities. So, it won’t be worthless to mention what you already know – install the update
urgently after receiving a notification.
Security Planning
While planning a database server for the organization, the DBA (Database Administrator) should consider the
following issues:
• Type of Server Required: Depending upon the requirements, the DBA should choose from one of the
following types of server types:
▪ Standalone server
▪ Client-Server Model
▪ Clustering Model
• Server Security: Server security is the process of limiting actual access to the database server itself. It is
the most important aspect of security and should be carefully planned.
▪ The database server should not be visible to the world.
▪ There should be no anonymous connection.

© Copyright IBM Corp. 2016 5-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
▪ A database server supplying information to a dynamic website should never be on the same machine
as the web server.
▪ If a database server is supplying information to a web server then it should be configured to allow
connections only from that web server.
▪ Every server should be configured to allow only trusted IP addresses.
▪ A database server supplying information to a homegrown application running on the internal network
should only answer to addresses from within the internal network.
• Database Connections
▪ All updates to a database via a web page should be validated.
▪ No data should be allowed to be submitted if a normal user can’t input data.
▪ A super-user account like "sa" should not be used for every connection and data source on the
server.
▪ Only the minimum privileges required by a user to connect with a database should be provided.
• Table Access Control: Table access control is one of the most overlooked forms of database security
because of the inherent difficulty in applying it. Properly using table access control will require the
collaboration of System Administrator, Database Administrator and Database Developer.
• Physical location of server: Physical protection should be provided to the server depending upon the
importance of data being stored in it.
• Separate storage area: A separate storage area for keeping the backup of the database and archive
should be decided in advance.
• Identify Users and Their Needs: Identify the types of users and grant them minimum access permissions
to database depending upon their needs.
• Security Policy: A security policy consisting of the procedures and regulations needed to maintain a
desired level of system security should be based on:
Identification of Security Requirements
▪ Identify the business importance of the data and the associated processing system.
▪ Assign a security priority to the data, based on the business case evaluation
▪ Identify the classes of users requiring access to Database Server and the data that it controls
▪ Identify the system resources that require protection to ensure continued availability data to all valid
users.
▪ Identification of Security Levels
▪ Minimal Security: Users have unrestricted access to all database server resources. No one performs
security related auditing and no formal security policy exists.
▪ Moderate Security: A small privileged subgroup has unlimited access. The DBA performs only
occasional auditing of security-related events, and no formal security policy exists for the users.
▪ High Security: The DBA is the only user whom database server permits to perform the following
security-related actions:
- Define username/password combinations to whom database server will grant access.
- edgeDefine and control the auditing of security-related events.
- Review the results of security-related audits.
• Guidelines for Each User: Each user should receive a document that states the security policy, explains
the importance of security, outlines the role of the user in supporting that policy, and defines the
guidelines for protecting passwords and data.

© Copyright IBM Corp. 2016 5-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Security checklist (1 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Security checklist for a Database Administrator with various operations

– Installation & Configuration
– Operations & Maintenance

© Copyright IBM Corporation 2016

Figure 5-11. Security checklist (1 of 2)

Security Checklist for a Database Administrator

• Ensure that the database RDBMS version is a vendor supported product version.
• Monitor the RDBMS software on a regular basis to detect unauthorized modifications.
• Ensure that all directories and file permissions created by the installation of a RDBMS are protected in
accordance with security evaluation specifications if available or, if not, vendor recommendations.
• Ensure that end user accounts are not granted permissions to change directory or file permissions
associated with the database software.
• Ensure that all default installation passwords will not remain on DBA database accounts.
• Change all default database account passwords after the application installation and disable default
application accounts that are not required.
• Ensure that the following password management rules are enforced:
▪ Configure all database accounts to be protected by a password, certificate, or approved
network-based authentication.
▪ Assign a temporary password at account creation.
▪ Store all passwords in an encrypted format.
▪ No database account name and password should be visible to the host operating system.
▪ Passwords should be alphanumeric characters and should include at least one numeric character.

© Copyright IBM Corp. 2016 5-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
▪ Passwords should not contain consecutively repeating characters.
• Restrict access to files containing logon credentials and encryption keys to SAs and DBAs.
• Ensure that RDBMS installation default object privileges are not granted to PUBLIC except for those
object privileges whose removal is not supported by the RDBMS vendor.
• Ensure that all user accounts are granted roles containing the minimum set of privileges required for the
application.
• In a shared production/development environment, ensure that no application developer account is given
permission to create, alter, or drop schema objects.
• Ensure that application developer accounts on shared production/development systems are at no time
given DBA roles within the database or on the operating system.
• Ensure that all database actions are traceable to an individual user logon.
• All database objects should be owned by the database system, database administrators, or by an
account created especially for application object ownership.
• Ensure that a tested and verifiable backup strategy is implemented on all RDBMS databases.
• Ensure that roles or application object privileges are not granted to PUBLIC.
• Ensure that the DBA role is restricted to authorized DBA accounts in a production environment.
• Ensure that the DBA role is restricted to DBA accounts and authorized application developer accounts in
a development environment.
• Restrict assignment of alter, index, and references object privileges to DBAs, object owners and
predefined roles.
• Restrict the assignment of the grant option of any object privilege to DBAs.
• Restrict access to the AUD$ table to DBAs and/or security auditors.
• Do not include a version number, vendor name or any identity thereof in production database instance
names.
• Protect the environment variable identifying the location of the password file.
• Configure an idle time limit for all database accounts through the use of profiles.
• Deny Everyone group any permissions on any database files or directories.
• Restrict write permissions to database registry keys to the Database Administrators and System
Administrators.
Installation & Configuration
A DBA should keep in mind the requirements and applications of the database server before starting the
installation. The DBA, in consultation with management and Network Administrator, should:
• Check the License of the Database Server Software
▪ Ensure that the instance being installed is legal and properly licensed.
▪ Check for Appropriate Version
▪ Ensure that the instance to be installed matches with the hardware and software already present in
the organisation.
• Type of Installation: Choose custom mode of installation to change the default values and avoid known
vulnerabilities of the database server.
• Change default passwords: No default passwords should be kept for the database server. Secure
passwords should be assigned to all the accounts and objects as defined in the password security policy
of the organisation.
• Disable/Remove unnecessary accounts: Any account created while setting up the server should be
disabled or deleted if not required. If the account has to be kept, then the password should be changed.

© Copyright IBM Corp. 2016 5-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• Remove Unnecessary Scripts: Any script installed or copied during installation of the server should be
deleted as soon as possible to secure the database.
• Verify the Features Installed: After the completion of installation, check to ensure that all the required
features have been installed and no required feature is missing.
• View Error Log: After completion of the installation, the error log should be reviewed to ensure that there
was no error in the installation.
• Calculate Checksum: Checksum of the files installed should be performed to ensure that all the required
files have been installed and there has been no error in the installation.
• Install All the Patches/Hot-Fixes/Service Packs: Install all the patches available to strengthen the
database server. Any hot-fixes and service packs provided by the vendor should be installed immediately.
• Implement Auditing Policy: Implement the auditing policy of the organization.
• Create an Account for Back-up & Archiving
• Create a separate account for backing up the database and archiving it. This account should be different
from the administrator account.
Operations & Maintenance
• User and Application Accounts
▪ During installation, some default accounts are setup. Keep an inventory of all accounts and disable or
remove the unnecessary ones.
▪ Assign privileges to application-owner account as per their roles. Make a policy for assigning roles
and privileges and follow that when opening new user accounts.
▪ Make sure that the passwords are not visible by file searches (such as use of the UNIX grep
command).
• Control the Distribution of Database Name: Service names and aliases should be used to mask the
physical location and name of every database in the system.
• Encrypt the Contents: Enable encryption of stored data on a high risk database environment. Any user
trying to access the data should need the right password as well as the encryption key.
• Effective Auditing: Logs should include the time and date of activities, the user ID, commands (and
command arguments) executed, ID of either the local terminal or remote computer initiating the
connection, associated system job or process number, and error conditions (failed/rejected attempts,
failures in consistency checks, etc.)
• Make Password Changes Mandatory: Users should be required to change their passwords frequently.
Force passwords to expire and prevent the reuse of old passwords.
• Isolate Production Database: A Production Database should be kept separate from development
database.
▪ Revoke operating-system-level access for developers on the production server and implement a
standardized change-control process.
▪ Never publicize the name of the database and server supporting the production application.
▪ Forbid the use of the production database for development or testing.
• Dormant Accounts: Accounts must be regularly reviewed for inactivity, and any dormant accounts
should be suspended.
• Privileged Accounts: Passwords for privileged accounts should be given only to people with a need for
privileged access. The passwords for these accounts must be encrypted when network is used to access
them.
• Test Security Patches: Vendor or author provided security patches must be evaluated for compatibility,
and installed.

© Copyright IBM Corp. 2016 5-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• Hide Vendor & Software Information: Wherever feasible, all operating system, version/release
numbers, and vendor information provided in login/sign-on banners should be limited or disabled.
• Review of Security Policy: A system security policy should not remain static. The following factors
make a review of the security policy necessary:
▪ Changes in the profiles of users who access the system.
▪ Changes in business needs that raise or lower the value of the data being protected.
▪ New releases of database server software that might introduce new security features.
▪ Discovery of security violations, potential violations, or attempted violations.

© Copyright IBM Corp. 2016 5-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Security checklist (2 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Security checklist for a Database Administrator in various tasks

– Backup & Recovery
– Web-based Databases

This is the smallest, but most common database problem.

Invalid Data It occurs when a finite number of invalid entries find their
way into the data.

The next level of database problems includes situations in

Corrupted Database Object which a single or limited number of database objects have
become corrupted or invalid.

At this level, the scope of the problem is so significant

Full Database Corruption that the database is no longer operational and a full database
recovery must be performed.

The largest levels of database problems occur when multiple

Multiple Database
databases within the organization have been corrupted and
Corruption
must be recovered as a set.

© Copyright IBM Corporation 2016

Figure 5-12. Security checklist (2 of 2)

Backup & Recovery

Databases should be protected from accidental data loss. A general backup and recovery strategy must be
designed depending on various factors, such as database size, volume of changes, and resources available.
Attention must be paid when choosing the backup type (incremental, full) and testing the whole set of
procedures to recover the system in case of disaster, and in a timely manner.
• Backup: Backing up databases should protect against accidental loss of data, database corruption,
hardware failures, and even natural disasters
▪ A database backup records the complete state of the data in the database at the time the backup
operation completes.
▪ A transaction log backup records the state of the transaction log at the time the backup operation
starts.
Depending upon the requirements, one of the following ways to backup the database should be selected:
▪ Complete database backups
▪ Perform a full backup of the database, objects, system tables, and data.
▪ Differential backups
▪ Back up data that has changed since the last complete backup.
▪ Transaction log backups
▪ Back up all database modifications transaction logs.

© Copyright IBM Corp. 2016 5-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
▪ File and filegroup backups
▪ Back up database files and filegroups rather than the entire database.
• Recovery: A backup is only as good as the recovery it can provide. A DBA may experience one or more
of the following database integrity problems and will be required to recover the lost data
▪ Transaction Recovery: Transaction recovery, also known as data-level recovery, allows DBAs to
precisely identify and correct the invalid data. The DBA should select and examine each of the
changes that were applied to the database by using selection and filtering capabilities
▪ Database Object Recovery: database object recovery allows DBAs to identify and recover only the
missing or damaged objects. DBA should use tools available for Object recovery contain built-in
database intelligence to identify all of the objects making up the database from information captured
when the backup was taken. This information can be then matched against the existing database
environment. Missing or invalid objects can then be automatically recovered from the physical
backup of the database, while valid objects remain unaffected
▪ Full Database Recovery: The DBA may need to recover entire database. This requires the
database to be closed. During this time, users will not be able to access important business-critical
applications
▪ Multiple Database Recovery: The DBA should select tools that combine an enterprise -wide view of
the organization with maximum database recovery capabilities. This enterprise-wide recovery
management console allows consistent, reliable backup and recovery plans to be established and
automated
Web-based Databases
Access to a web based database server is via network connections such as SQL/net. Authentication is often
an automated or scripted task, or the network access is via a single username as far as the operating system
on the server is concerned.
Configuration for Web-Based Database Server: It is recommended that in a web-based application, a
typical configuration should keep the database with the sensitive information behind a firewall. It will be
accessed from an application-server also located behind a second firewall, which will receive the web server
requests. This three-tier design isolates the Web-server from the database, isolating the database server
from the outside users by two dedicated private networks. Only the
Web server can communicate through the firewall with the application-server, and only this can communicate
with the database. This configuration is relatively secure and special attention must be paid on securing the
information sent to the client from the Web server, the Web-server itself, and the database/application-server
system. The application-server will incorporate the event logging and the security analyzer that recognizes
unauthorized attempts to log into an account.
Security Threats to Web Based Database Servers: All web-based database servers have ports that they
listen to. Most intruders do a simple ‘port scan’ to look for ports that are open that popular database systems
use by default.
For web security, the following three primary areas must be addressed:
▪ Server security: Ensure security for the actual data or private HTML files stored on the server
▪ User-authentication security: Ensure login security to prevent unauthorized access to information
▪ Session security: Ensure that data is not intercepted as it is broadcast over the Internet or Intranet

© Copyright IBM Corp. 2016 5-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Database Security Assessment IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Following four attributes of a best practice database security assessment

– Impact on production systems
– Accuracy
– Efficiency
– Breadth of analysis
• Barriers of database security assessment

© Copyright IBM Corporation 2016

Figure 5-13. Database Security Assessment

Database Security Assessment

Database security assessment is fundamentally a process that measures database risk at a point in time.
The first element of risk is measured by evaluating a database’s susceptibility to a series of known
vulnerabilities and attack scenarios.
A vulnerability might be a best practice system configuration error such as a lack of a database password
policy; a software coding error such as a buffer overflow in a procedure; or a privilege management error
such as public access to a sensitive table. Each vulnerability identified is then rated by severity – low,
medium, high, critical, etc. Finally, a report is generated that summarizes the results. A typical assessment
summary charts the total number of vulnerabilities by severity. This summary is essentially a snapshot of
overall risk that management can use to prioritize the steps required to improve database security. It tells
security managers and database administrators which databases and which specific vulnerabilities need their
attention first.
The fundamental design of a best practice database security assessment process includes consideration of
the following four attributes:
• Impact on production systems
• Accuracy
• Efficiency
• Breadth of analysis
Impact on Production Systems

© Copyright IBM Corp. 2016 5-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Many assessment processes attempt to identify vulnerabilities by mimicking the activities of an attacker. For
example, an assessment may try to exploit a known buffer overflow vulnerability or use brute force to obtain
valid access credentials. Such exploit techniques are common amongst automated Web server and network
assessment tools – especially open source tools such as Nikto, Nessus, and Whisker. The problem with
these methodologies is that they can cause downtime or damage the database if any exploit is successful. A
buffer overflow simulation, for example, can crash a database.
Any chance of downtime or damage is obviously unacceptable in production environments. This fact makes
exploit mechanisms appropriate for lab testing only. On the other hand, lab test results are not applicable to
production databases. Vulnerabilities found, or more importantly, those not found in the lab may or may not
exist in production. The database security assessment solution, therefore, should function without using
actual exploits. Production databases cannot be put at risk.
Accuracy
Many assessments do not dig deep enough into available database information to validate the status of a
given vulnerability. Consider the xp_sprintf buffer overflow vulnerability in Microsoft-SQL server (BID1204).
xp_sprintf is an extended stored procedure that may be exploited by an attacker to crash the server or gain
administrative privilege. There are two coarse approaches to assessment with respect to this vulnerability
that lead to inaccurate results.
• Exploit Approaches - Exploit-oriented approaches attempt to send data to xp_sprintf (despite the risk).
Depending upon the response to the exploit, they report whether or not the server is vulnerable.
However, the accuracy of this approach depends upon whether or not the database user account used
by the assessment tool has EXECUTE privileges over xp_sprintf. A PUBLIC user may not have privileges
to this account. Therefore, an exploit from a PUBLIC account fails and the assessment reports a not
vulnerable result. However, a Web application may have privileges to xp_sprintf making the database
server quite vulnerable – despite the original not vulnerable result.
• Version-Only Approaches - Other assessment approaches simply check software version to evaluate
vulnerability. In this case, SQL Server versions 6.5 SP4 and earlier suffer from this vulnerability. Such
version-only assessment concludes that a server with version 6.5 SP1 is vulnerable. However, this
approach ignores whether or not the stored procedure actually exists on the server. If the stored
procedure has been removed, as best practices recommend, the assessment result should be not
vulnerable.
Efficiency
Database security assessment should do more than provide a flat vulnerability listing. Such a listing alone is
not actionable. Administrators could attempt to sequentially remediate each vulnerability on the list, but such
a effort would be extremely inefficient. Some vulnerabilities require immediate attention, while others can
wait or even be ignored. A more efficient assessment process prioritizes each vulnerability according to risk.
With a prioritized risk analysis, a security manager or database administrator can develop an effective plan
for remediation.
Another problem with flat listing database vulnerabilities is that the risks cannot be evaluated and prioritized
by management. Database administrators, security managers, and internal auditors need assessment
reports that communicate database security posture at an executive level. Among other uses, these reports
are used to justify security budgets, report on the results of a new security process, and measure regulatory
compliance. Therefore, database assessment solutions should integrate reporting capabilities that translate
flat vulnerability data into executive-level risk analysis.
Breadth of Testing
Best practice database security assessment should include a breadth of tests that address each of the
following areas.
• Known Platform Vulnerabilities
• System Configuration
• Privilege Management
• External Objects

© Copyright IBM Corp. 2016 5-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• Regulatory Compliance
• Known Vulnerabilities
Public vulnerability databases (Bugtrac, NVD, etc.) track thousands of known software vulnerabilities -
including those that exist within databases and their underlying operating systems. Database security
assessment should evaluate susceptibility to all such known vulnerabilities that are relevant to the target
database software and underlying operating system. To understand how such vulnerability testing and
prioritization may take place without actually simulating an attack, consider the following example.
BID 2041: Microsoft SQL Server / Data Engine xp_printstatements Buffer Overflow Vulnerability
Bugtrac ID number 2041 identifies a Microsoft SQL Server 2000 / Data Engine vulnerability in which an
extended stored procedure is susceptible to a buffer overflow that may crash the system or enable execution
of arbitrary code (i.e. a worm). To test for this vulnerability without actually sending data to the input buffer in
question, the security assessment may apply the following process.
• Test for Vulnerability
Check the software version against those known to be vulnerable. Microsoft has issued a patch for this
vulnerability.
▪ If the patch has been applied, then the server is not vulnerable.
▪ If the version is found to match known vulnerable versions, check for the existence of the
xp_printstatements stored procedure. Database security best practices recommend the removal of
all unnecessary extended stored procedures.
- If xp_printstatements has been removed, then the database is not vulnerable.
- If xp_printstatements exists, then the database is vulnerable.
• Prioritize by Risk
To prioritize the vulnerability by risk, list of users that have “EXECUTE” privileges on the xp_printstatements
stored procedure is extracted.
▪ If privileges are granted to a large number of users or PUBLIC (i.e. everyone), then the risk
associated with this vulnerability is relatively high.
▪ On the other hand, if privileges are granted only to SA (system administrators) then the risk
associated with this vulnerability is low.
• System Configuration
Database security is highly sensitive to system configuration issues, many of which are covered by best
practices. Hundreds of configuration items should be assessed based upon the type and intended usage of
the database (e.g. a database supporting an external Web application may require different configuration
than one supporting a large group of internal users). One simple example is password change frequency.
Best practices recommend that user account passwords change frequently. The database assessment
should allow the administrator to configure a change frequency (i.e. 30 days) policy and then automatically
compare that policy to the age of all actual passwords. The assessment solution may then list all accounts
with passwords that are in violation of policy to help prioritize the threat and remediate the problem. A good
assessment test checks whether the administrator has used built-in database mechanisms to correctly
enforce the password policy.
• Privilege Management
The extent to which database privileges are managed should also be assessed. In general, database owners
should adhere to a “least privilege” policy. For example, best practices mandate that user privileges should
be granted to accounts only through roles. Privileges granted directly may yield excessive access rights
when users shift positions within the organization. Direct grants also imply an undocumented authorization
process – a common barrier to compliance with regulations such as Sarbanes-Oxley. Therefore, the
assessment should examine the data dictionary for records in which the grantee is an account and not a role.
Any accounts that match this condition may then be listed along with the privileges directly granted to help to
measure the threat and help remediate the problem.

© Copyright IBM Corp. 2016 5-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• External Objects
Certain objects that are external to the database may be leveraged (if not properly configured) to attack a
database. These external objects are primarily operating system objects such as files, services, registry
keys, etc. For example, DB2 includes an executable file called db2job that can be exploited, by default, to
allow local users to execute code with administrative privileges. Susceptibility to this vulnerability can be
determined by checking operating system permissions on the db2job file.
• Regulatory Compliance
Database assessment should pay special attention to security requirements that are specifically relevant to
regulatory compliance. For example, SOX requires tracking of all new user accounts within databases that
store financial reporting information. Therefore, the assessment should check the data dictionary for
accounts whose creation date is within a configurable time period. Any new accounts may then be listed in
the assessment results reports.
Barriers to Assessment
Despite the benefits to database assessment, many organizations face one of several implementation
barriers: budget, resources, and staff expertise.
• Budget - Many organizations require written justification prior to approving budget for investments in IT.
Database security assessment measures the security posture of their databases and can help justify
investment in additional database security measures, but what can IT use to justify investment in
assessment tools.
Unfortunately, commercial assessment tools require investment before IT can completely quantify the
need. Free security assessment tools have been available for the network, Web servers, and other
infrastructure segments, but until recently
there were no free database assessment tools.
• Resources - Database administrators are usually overworked and their responsibilities are limited to
daily operations. They have limited bandwidth to allocate toward security tasks. Since the consequences
of lax security, although inevitable, may not be immediate, database assessment tends to be pushed to
the back burner.
• Expertise - Organizations with staff dedicated to security and resources to assess database
infrastructure rarely have the level of database-specific expertise necessary to conduct a best practices
assessment that includes analyzing database configurations, privileges, etc.

© Copyright IBM Corp. 2016 5-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Database Security Program Design

(1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the DB security programme design and its process with checklist
– Define a database security program with actionable processes
– Clarify the scope of your program through database discovery and inventory
– Define security standards and compliance policies
– Conduct vulnerability and configuration assessments

© Copyright IBM Corporation 2016

Figure 5-14. Database Security Program Design (1 of 2)

Database Security Program Design

Relational databases and big data stores are a prime target for attackers due to the amount of sensitive
information residing within, such as customer information, intellectual property and proprietary secrets. Yet
many businesses fall victim to database intrusions because of common database flaws. To address their
ever-expanding network perimeters that become more porous as they swell, organizations need to push data
security deeper. Reducing the risk of compromise and fulfilling compliance requirements requires extending
data protection measures all the way through to the database.
An effective database security program requires commitment and discipline across the organization. Policies
must be established, standard configurations must be reviewed and approved and production systems must
be monitored for compliance. Most importantly, an operational method consisting of not only technology but
also people and processes must be documented and institutionalized.
Once it’s deployed, properly configured and staff is trained in its use, technology will support these objectives.
But technology alone is not a cure-all. In our work we find that organizations that see the greatest positive
impact are those that combine people, process and policy and then reinforce those aspects with robust
security technology. Only through the development of an effective process and methodology can the
program’s objectives come to fruition. This requires establishing policy, assigning accountability, defining
workflow, and delivering relevant analytics and reporting to each functional area.
Principles of Database Security Program Design
• Describe a database security program with actionable processes
• Clarify a scope baseline through database discovery and inventory

© Copyright IBM Corp. 2016 5-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• Define standards, security and compliance policies
• Conduct vulnerability and configuration assessments
• Identify excessively privileged user accounts
• Implement risk mitigation and compensating controls
• Establish acceptable user and activity policies
• Audit privileged user behavior in real-time
• Deploy policy-based activity monitoring
• Detect, alert, and respond to policy violations in real time
Technology alone will not reduce the risk of database compromise. A complete program incorporates people,
process and technology. Instituting a proven methodology and identifying the individuals directly responsible
for delivering on the program objectives will prevent the over-extension of resources, which can include
personnel, IT infrastructure, business operations, application integrity, budget or political capital. IT security,
risk, audit, database administration, application management and IT infrastructure functions will all play a role
in the establishment and execution of the process. Determining and establishing the appropriate policies,
roles, accountability, workflow, mitigation, reporting and ongoing management will set all stakeholders on a
course to achieve your program goals.
Pragmatic database security does not begin with activity monitoring.. At a minimum, a database security
technology must facilitate policy management, asset management, vulnerability management, rights
management and activity monitoring to help an organization achieve its database security and compliance
goals. In addition, these fundamental capabilities must integrate and inform each other. If they do not, they
become islands of information existing in a vacuum, which significantly decreases the efficacy of an
operational model.
DAM and IDS/IPS are pull technologies, for which there is less control over the workload. These
technologies’ output depends on how broadly the monitoring policy is defined, and the volume of database
activity that matches it. Without a full view of these elements and a structured process regarding how they
integrate, DAM technology will likely yield countless false positives and negatives, overwhelming reports, and
logs of indeterminate data – resulting in significant resource drain and potentially outright failure.
A database security programme accommodates the following:
• On-boarding and retirement of databases
• Addition and removal of users
• Changing of user roles
• Evolving audit requirements
• Ongoing patch cycles
• Constantly shifting security threats
This approach will likely take the form of two inter-connected database security processes
Define a database security program with actionable processes
A plan is the key to success. With all stakeholders at the table, the project team can identify your existing
processes, people, and technologies to help drive the rapid development of your template model. This project
team will also define the scope and phases of implementation and identify any gaps in people, process, or
technology.
Checklist:
• What is the program’s mission statement?
• What, if any, documented database standards exist today?
• What objectives can be achieved with the first phase (and then subsequent phases)?
• How can we leverage existing processes? What additional processes are needed?

© Copyright IBM Corp. 2016 5-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
• Who owns security policy? What compliance requirements are within the project’s scope?
• What reporting output do we seek?
• How many personnel resources do we need? How will we add resources if/when needed?
Clarify the scope of your program through database discovery and inventory
Is there currently a single “source of truth” that can identify all the databases across the entire enterprise
environment? An accurate inventory of database instances in the environment is a critical-path item in
establishing a holistic and effective database security program. It only takes one unpatched, rogue database
on the network to potentially expose the datacenter to unchecked, malicious activity. Application developers
often complicate matters by “temporarily” copying production data to development systems to test their latest
software builds. More often than not, this data is stored on an unprotected (and many times unpatched)
system outside the normal scope of compliance and security controls.
An accurate inventory of all databases (production and non-production) is needed on the network in order to
identify, classify and prioritize systems that require attention. It should be known where data resides in order
to protect it. A baseline inventory of the database systems helps to identify which systems should be
considered in-scope for security and compliance policies.
Checklist:
• What, if any, asset management programs are in place? What checks and balances exist to confirm its
accuracy? Are there any exceptions?
• What is the approval process for placing a database on your organization’s network?
• What applications read/write to the database assets?
• Which of those applications are known to be in scope for regulatory compliance?
• What sensitive or private information resides in those databases?
• What local privacy laws might limit access to (or the transfer of) any of this data?
Define security standards and compliance policies
Managing policy is a continuous process. Without defined polices and standards to conform to, an
organization cannot measure compliance or progress against benchmarks. While many organizations have
developed corporate polices for data security, those policies are rarely mapped to the systems that store data
- the databases themselves. Database vendors rarely enforce more than the most obvious weaknesses in
the out-of-the-box installations of their platforms. When database security weaknesses are remediated, more
often than not it’s a reaction to an incident rather than proactive response to a standard or policy. When
vendors do patch vulnerabilities or ship new versions of software, an organization needs to review policies to
ensure they account for new and updated configurations and settings.
Checklist:
• How often are policies updated?
• Who is responsible for updating policies?
• What can trigger a policy change?
• Who approves a policy change?
• How are exceptions handled?
• Who approves exceptions?
• Which teams are involved in the review process of suggested policy changes?
• What, if any, communication process is in place to communicate policy changes?
• How, if an agreement exists, do teams cooperate to enforce defined policies?
Conduct vulnerability and configuration assessments
Many organizations need to demonstrate compliance with more than one set of business, security, or
regulatory policies. Since databases are often an organization’s largest repository of sensitive data, they

© Copyright IBM Corp. 2016 5-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
usually fall into scope for regulatory compliance and the inevitable IT audit. Databases may need evaluation
to ensure they fulfill any number of standards and requirements, such as: Sarbanes Oxley, PCI DSS, FISMA,
DISA-STIG and more. To demonstrate effective controls surrounding sensitive data, organizations will need
to run a baseline assessment and establish a practice of continuous assessment to ensure issues are
remediated in a timely manner.
Checklist:
• Who can approve the scan policy?
• Who can update scan policy?
• What, if any, risk acceptance (or exceptions) process exists?
• Who can approve exceptions?
• What do stakeholder teams agree must be assessed?
• At what frequency will scans take place? Monthly? Quarterly?
• What is the process for addressing identified vulnerabilities?

© Copyright IBM Corp. 2016 5-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Database Security Program Design

(2 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Explaining the DB security programme design and its process with checklist
– Define a database security program with actionable processes
– Clarify the scope of your program through database discovery and inventory
– Define security standards and compliance policies
– Conduct vulnerability and configuration assessments

Outsiders with insider

Authorized users Privileged users Knowledge users access and/or vulnerability
knowledge
Employees such as clerks, Individuals with elevated Users with access and These users may not have
accountants, finance staff, privileges, broad access and knowledge of systems or the same user rights as
sales people, purchasing extensive database security protocols like IT “Authorized”, “Privileged”, or
staff and others. This type of knowledge, such as: DBAs, operations, network “Knowledge” users do, but
user includes anyone developers, quality operations, security and they may be capable of
granted authorized access to assurance staff, contractors audit personnel. performing privileged activity.
the data or systems within a and consultants.
given enterprise.

© Copyright IBM Corporation 2016

Figure 5-15. Database Security Program Design (2 of 2)

Conduct vulnerability and configuration assessments

Many organizations need to demonstrate compliance with more than one set of business, security, or
regulatory policies. Since databases are often an organization’s largest repository of sensitive data, they
usually fall into scope for regulatory compliance and the inevitable IT audit. Databases may need evaluation
to ensure they fulfill any number of standards and requirements, such as: Sarbanes Oxley, PCI DSS, FISMA,
DISA-STIG and more. To demonstrate effective controls surrounding sensitive data, organizations will need
to run a baseline assessment and establish a practice of continuous assessment to ensure issues are
remediated in a timely manner.
Checklist:
• Who can approve the scan policy?
• Who can update scan policy?
• What, if any, risk acceptance (or exceptions) process exists?
• Who can approve exceptions?
• What do stakeholder teams agree must be assessed?
• At what frequency will scans take place? Monthly? Quarterly?
• What is the process for addressing identified vulnerabilities?
Identify excessively privileged user accounts

© Copyright IBM Corp. 2016 5-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
One particularly challenging question for many organizations is, “Who has access to my sensitive data?”.
Many database scanning technologies can not only identify vulnerabilities and misconfigurations, but also
users, roles and privileges. The only way to establish meaningful controls that track how users interact with
the data, or to capture an audit trail for use in a breach investigation, is to know who has access to what data
and why/how they’ve been granted that access. For example, you might not be comfortable with the amount
of employee and customer data your HR department’s summer intern is capable of accessing.
Checklist:
• How often, if at all, do we review who has administrative access to our databases?
• How do we compare users’ privileges to a known benchmark?
• Who should be auditing user activities for compliance and access violations?
Implement risk mitigation and compensating controls
Remediating high-risk vulnerabilities and misconfigurations within the database will not only reduce the risk of
compromise, it also narrows the scope of any required compensating controls, such as exploit monitoring
(e.g., Intrusion Detection). DAM can also be an appropriate compensating control for vulnerabilities that
cannot be remediated or patched in a timely manner. Using data analytics to associate risk scores with the
results/findings of vulnerability assessment help identify the most exposed systems or groups.
Checklist:
• Specific to an organization’s environment, where do we begin in making the most impactful changes to
reduce our risk of compromise?
• How do we get visibility into where we may need to add compensating controls to cover gaps in our
configurations?
• What is the response plan for the remediation of findings?
• How do security policies support the response plan?
Establish acceptable user and user activity policies
A number of technologies facilitate user profiling, database auditing being one method. If currently, database
auditing is being performed, there must be a means of identifying which user accounts have high levels of
database privileges. However, as duties change, new employees join the organization and others leave,
regular evaluation of database account privileges becomes all the more important. Such an assessment
should also identify unauthorized accounts or those with excessive privileges.
Many native database platforms include profiling tools. The best practice is to verify the existence of any
native auditing or profiling capabilities, and request access to any related information.
DAM can create an enormous set of results requiring ever-increasing amounts of storage and making review
of the logs time-consuming and expensive. User profiling helps in identifying what activities need to be
logged, reducing the volume of DAM alerts and ensuring resources are only spent reviewing relevant,
actionable information.
Below we’ve listed and explained some of the more common database user account types.
Checklist:
• Do we use the native auditing capabilities within our database software? If not, why not and should we
enable the capability?
• If it exists, who is reviewing the collected audit information and for what purposes?
• How long is auditing data stored?
• What, if any, reporting is provided and to whom?
Audit privileged user behavior in real-time
DAM is a class of technologies that allows to collect a forensic audit trail of all privileged activities in a
database. Many compliance regulations (including Sarbanes-Oxley) require tracking of structural changes in
the information, which means auditing privileged (administrative) activity, not just the actions of known
privileged users.

© Copyright IBM Corp. 2016 5-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Checklist:
• Who manages our list of database users and their privileges?
• Who is reviewing audit events and how often?
• For what purpose are they reviewing audit events?
• What actions are taken once these audit events are reviewed?
Deploy policy-based activity monitoring
Working in tandem with database audit logging technologies, your DAM security and compliance policies
should trigger alerts when activity that violates those policies is detected. Be wary - some DAM technologies
rely on a “learning” mode that accepts all database activity captured during a certain limited time-window (a
learning cycle) as normal transactions representative of all activity that occurs throughout the year (including
batch jobs and maintenance activities). Many vendors recommend learning-based activity monitoring policies
because manually configuring policies within their products is too complex.
As enterprise database activity evolves with business growth, a learning-based product will need to
continually self-modify the monitoring policy (which makes demonstrating compliance with a particular policy
to an IT Auditor very difficult), or the administrators of the product will end up turning off learning mode and
manually configuring the DAM solution anyway.
Checklist:
• Who and/or what applications should have access to each monitored database and for what purpose?
• What activities will we define as authorized (e.g., application activities)? ? What is our policy for retaining
log or event data?
• If reporting is currently available, what information is included and who reviews the reports?
• What events do we want to be alerted to, who will review them and what actions should be taken in
response?
• What other higher-level event correlation system, such as a SIEM technology, might consume this event
information?
Detect, alert and respond to policy violations in real time
Most real-time DAM solutions can send alert messages in a variety of formats so that operations center
personnel can take action when a security violation is identified. Many organizations then choose to feed
these events into a SEIM or network management tool if/when suspicious or malicious activity is detected.
Depending on the policy violation and the sensitivity of the affected system or data, automated and scripted
responses (“active responses”) can contain the threat and give the security team time to investigate and take
corrective action. Examples of active responses may include: terminating the user session, locking out the
offending user account and triggering a database vulnerability/configuration scan and/or anti-malware scan of
the database host.
Checklist:
• Who has authority over other security technologies that might consume DAM data?
• What integrations are available with third-party security and network management solutions (e.g. SIEM)?
• What types of events will you want your security staff to be alerted to in real time?
• Is staff sufficiently knowledgeable to take immediate action on alerts? If not, for which critical security
events can we implement an automated action (“active response”) as a protective measure?
Finally, the output of the DAM data received is fitted into the security infrastructure and IT operational
eco-system. This should be part of the operational model, but designing proper reporting must begin with an
understanding of the program as a whole. As the database security program is designed and refined, the data
needed and its distribution mechanism becomes clearer. Integration with a centralized security solution
makes the design and planning phases much more efficient.

© Copyright IBM Corp. 2016 5-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty
Checklist:
• What systems need to be protected for each stakeholder?
• What level of information sharing will provide them the data they need to make informed decisions?
• What amount of control over the reporting does each stakeholder require?
• How will data from a database security solution be consumed by other security programs within the
jurisdiction of each stakeholder?
Database security and compliance best practices dictate that organizations regularly scan for vulnerabilities
and highly privileged user accounts and then monitor for anomalous activity. A pragmatic database security
program requires that organizations implement an automated process for identifying critical vulnerabilities
and privileged accounts, remediating issues where possible and then monitoring privileged activity whether
it’s associated with authorized, recognized privileged accounts or other accounts with excessive privileges.
Organizations need to make sure administrators and/or security personnel have sufficient, actionable data to
make informed decisions and are not distracted by excessive alerts, false-positives and false-negatives.
Commonly referred to as a compensating control, real-time activity monitoring can protect databases during
the gap between discovery of a vulnerability and mitigation of that vulnerability. Responsible organizations
should proactively deploy activity monitoring, informed by vulnerability and rights review scan results, to
ensure the highest, most efficient level of database security.
Checklist:
• Involve stakeholders early and often
• Define and document processes (and base them on existing policies where possible to save time and
resources)
• Establish your response plan ahead of time
• Create policies that support the response plan
• Understand and document your reporting requirements

© Copyright IBM Corp. 2016 5-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
1. Which of the following is NOT a feature of a good database system architecture?
A. Independence of data and programs
B. Ease of system design
C. Powerful query facilities
D. Dependency on data and programs
2. Which of the following statement(s) is/are NOT true for Client/server architecture of database
systems?
A. The database server and the database and other resources are placed at one location while the
code for application is placed on a client machine or on their personal computer
B. The database server and the database and other resources and the code for application are
placed at the same location to ease the operation and access to database
C. Queries are carried to the server machine and the resultant data is carried back to the client’s
machine by pre-defined queries
D. Queries are processed on the database server, while rest part is done on the workstation
3. In slim client architecture, higher security requirements are required on the
A. Client side
B. Application server
C. Back-end server databases
D. None of the above

© Copyright IBM Corporation 2016

Figure 5-16. Checkpoint

© Copyright IBM Corp. 2016 5-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
4. In slim client architecture, changing number of security requirements are required at the
A. Application server
B. Client side
C. Back-end server databases
D. None of the above
5. Which type of threats on database can lead to denial of service attack (DOS)?
A. Logical threats
B. Physical threats
C. Databases are inherently immune to DOS attacks
D. Both A and B
6. Which of the following is NOT a countermeasure against SQL injection in a database server?
A. Sanitization of input data by application before using it in SQL queries
B. Usage of SQL server login that executes permissions only to selected stored procedures
C. An application should constrain input data before using it in SQL queries
D. All of the above are a countermeasure against SQL injection

© Copyright IBM Corporation 2016

Figure 5-17. Checkpoint

© Copyright IBM Corp. 2016 5-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
7. Which of the following is a vulnerability associated with Unauthorized database server access?
A. Lack of IPSec or TCP/IP filtering policies
B. Failure to block the SQL Server port at the perimeter firewall
C. Both A and B
D. Neither A nor B
8. Which of the following database security mechanisms are equipped with the capability to look into
the data packets owing in either direction, and provide systems administrators a means to configure
actions based on the intercepted content?
A. Content-based firewalls
B. SSL connections
C. A demilitarised zone (DMZ)
D. None of the above
9. Which of the following database security mechanisms uses public-key and private-key cryptography
to encrypt all connections between caller and listener?
A. IPSec security
B. Content-based firewalls
C. SSL connections
D. A demilitarised zone (DMZ)

© Copyright IBM Corporation 2016

Figure 5-18. Checkpoint

© Copyright IBM Corp. 2016 5-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
10. Which of the following is one of the best practices to secure database server?
A. Discard all default users and demo-test databases
B. Change the admin user name
C. Restrict user privileges
D. All of the above

© Copyright IBM Corporation 2016

Figure 5-19. Checkpoint

© Copyright IBM Corp. 2016 5-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 5. Database Server Security

Uempty

Unit summary IBM ICE (Innovation Centre for Education)

IBM Power Systems

Having completed this unit, you should be able to:

• Get an overview of the need of database server security mechanisms
• Get familiar with the methodology of securing open source databases
• Understand the role of database administrator in securing database server
• Know the components of database security assessment

© Copyright IBM Corporation 2016

Figure 5-20. Unit summary

© Copyright IBM Corp. 2016 5-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Unit 6. IT System Security Processes

Overview
This knowledge imparts knowledge about various processes involved in application of system security

How you will check your progress

• Checkpoint

© Copyright IBM Corp. 2016 6-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Unit objectives IBM ICE (Innovation Centre for Education)

IBM Power Systems

After completing this unit, you should be able to:

• Know how to identify assets, threats and vulnerabilities before applying system security
mechanisms
• Understand importance of examining tools, techniques and technologies involves in system
security processes
• Understand when and where to apply operational controls
• Get an insight on the aspects involved in implementation of security policy

© Copyright IBM Corporation 2016

Figure 6-1. Unit objectives

© Copyright IBM Corp. 2016 6-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Identification of risk IBM ICE (Innovation Centre for Education)

IBM Power Systems

Risk Identification Process

© Copyright IBM Corporation 2016

Figure 6-2. Identification of risk

Identification of Risks
Risk identification begins with the process of self-examination. At this stage, managers identify the
organization’s information assets, classify them into useful groups, and prioritize them by their overall
importance.

© Copyright IBM Corp. 2016 6-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Organizational Assets Used in Systems IBM ICE (Innovation Centre for Education)
IBM Power Systems

IT System
Risk Management Components
Components
People inside an Trusted employees
People
organization Other staff
IT business and standard procedures
Procedures Procedures
IT business and sensitive procedures
Transmission
Data Data/Information Processing
Storage
Applications
Software Software Operating systems
Security components
Systems and peripherals
Hardware Hardware
Security devices
Intranet components
Networking Networking components
Internet or Extranet components

© Copyright IBM Corporation 2016

Figure 6-3. Organizational Assets Used in Systems

Creating an Inventory of Information Assets

The risk identification process begins with the identification of information assets, including people,
procedures, data and information, software, hardware, and networking elements.
This step should be done without pre-judging the value of each asset; values will be assigned later in the
process.

© Copyright IBM Corp. 2016 6-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Identifying assets IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Here we can identifying various assets

– Identifying Hardware, Software, and Network Assets
– Identifying People, Procedures, and Data Assets
– Classifying and Categorizing Assets

© Copyright IBM Corporation 2016

Figure 6-4. Identifying assets

Identifying Hardware, Software, and Network Assets

Whether automated or manual, the inventory process requires a certain amount of planning. Most
importantly, it is determined which attributes of each of these information assets should be tracked.
That determination will depend on the needs of the organization and its risk management efforts, as well as
the preferences and needs of the information security and information technology communities.
When deciding which attributes to track for each information asset, consider the following list of potential
attributes:
• Name
• IP address
• MAC address
• Asset type
• Serial number
• Manufacturer name
• Manufacturer’s model or part number
• Software version, update revision, or FCO number
• Physical location
• Logical location

© Copyright IBM Corp. 2016 6-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
• Controlling entity
Identifying People, Procedures, and Data Assets
Responsibility for identifying, describing, and evaluating these information assets are assigned to managers
who possess the necessary knowledge, experience, and judgment. As these assets are identified, they are
recorded via a reliable data-handling process like the one used for hardware and software.
• People
• Position name/number/ID
• Supervisor name/number/ID
• Security clearance level
• Special skills
• Procedures
• Description
• Intended purpose
• Software/hardware/networking elements to which it is tied
• Location where it is stored for reference
• Location where it is stored for update purposes
Classifying and Categorizing Assets
Once the initial inventory is assembled, it must be determined whether its asset categories are meaningful to
the organization’s risk management program. The inventory should also reflect the sensitivity and security
priority assigned to each information asset. A classification scheme should be developed that categorizes
these information assets based on their sensitivity and security needs, i.e. confidential, internal, and public.
Each of these classification categories designates the level of protection needed for a particular information
asset. Some asset types, such as personnel, may require an alternative classification scheme that would
identify the information security processes used by the asset type. Classification categories must be
comprehensive and mutually exclusive.

© Copyright IBM Corp. 2016 6-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Threat Identification IBM ICE (Innovation Centre for Education)

IBM Power Systems

Threat Example
Act of human error or failure Accidents, employee mistakes
Compromises to intellectual property Piracy, copyright infringement
Deliberate acts of espionage or trespass Unauthorized access and/or data collection
Deliberate acts of information extortion Blackmail for information disclosure
Deliberate acts of sabotage or vandalism Destruction of system or information
Deliberate acts of theft Illegal confiscation of equipment or information
Deliberate software attacks Viruses, worms, macros, denial-of-service
Forces of nature Fire, flood, earthquake, lightening
Quality of service deviations from service
Power and WAN quality of service issues
providers
Technical hardware failures or errors Equipment failure
Technical software failures or errors Bugs, code problems, unknown loopholes
Technological obsolescence Antiquated or outdated technologies

© Copyright IBM Corporation 2016

Figure 6-5. Threat Identification

Threat Identification
Any organization typically faces a wide variety of threats. If you assume that every threat can and will attack
every information asset, then the project scope becomes too complex. To make the process less unwieldy,
each step in the threat identification and vulnerability identification processes is managed separately and
then coordinated at the end.
Identify and Prioritize Threats and Threat Agents
Each of these threats presents a unique challenge to information security and must be handled with specific
controls that directly address the particular threat and the threat agent’s attack strategy. Before threats can be
assessed in the risk identification process, however, each threat must be further examined to determine its
potential to affect the targeted information asset. In general, this process is referred to as a threat
assessment

© Copyright IBM Corp. 2016 6-7

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Prioritizing System Vulnerabilities IBM ICE (Innovation Centre for Education)

IBM Power Systems

High Likelihood Medium Likelihood Low Likelihood

Tape backups taken No administrator
Sensitive information
High offsite that are not password on an
stored on an
Impact encrypted and/or internal SQL Server
unencrypted laptop
password protected system

Unencrypted e-mails Missing Windows patch

No passwords required
Medium containing sensitive on an internal server that
on several Windows
Impact information being can be exploited using
administrator accounts
sent Metasploit

Outdated virus
signatures on a Employees or visitors Weak encryption
Low Impact standalone PC gaining unauthorized ciphers being used on
dedicated to Internet network access a marketing website
browsing

© Copyright IBM Corporation 2016

Figure 6-6. Prioritizing System Vulnerabilities

Prioritizing System Vulnerabilities

Prioritizing the security vulnerabilities is critical because many issues might not be fixable, and others might
not be worth fixing. As the business situations, it might not be possible to eliminate some vulnerabilities
because of various technical reasons, and it might not be able affordable to eliminate others. Or, simply
enough, the business may have a certain level of risk tolerance. Every situation is different. There is a need
to factor whether the benefit is worth the effort and cost. On the other hand, spending a few weeks of
development time to fix cross-site scripting and SQL injection vulnerabilities could be worth a lot of money,
especially if one ends up getting dinged by third-parties or lose potential customers. The same goes for
mobile devices that everyone swears contain no sensitive information. Each vulnerability must be studied
carefully, business risks must be determined, and it should be weighed whether the issue is worth fixing.
It’s impossible - or at least not worth trying - to fix every vulnerability that there is. Each vulnerability must be
analyzed carefully and wort case-scenarios must be determined. For example, is there cross-site request
forgery (CSRF) on the printer’s web interface? What’s the business risk? Perhaps FTP is running on
numerous internal servers. What’s the business risk?
With security - like most areas of life - focus should be on highest payoff tasks. Here’s a quick method to use
when prioritizing your vulnerabilities. This method can be tweaked to accommodate different needs. Two
major factors should be considered for each of the vulnerabilities discovered:
• Likelihood of exploitation: How likely is it that the specific vulnerability analyzed will be taken
advantage of by a hacker, a malicious user, malware, or some other threat?
• Impact if exploited: How detrimental would it be if the vulnerability analyzed were exploited?

© Copyright IBM Corp. 2016 6-8

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
Many people often skip these considerations and assume that every vulnerability discovered has to be
resolved. Big mistake. Just because a vulnerability is discovered doesn’t mean it applies to a particular
situation and environment.
Each vulnerability is ranked using criteria such as High, Medium, and Low or a 1-through-5 rating (where 1 is
the lowest priority and 5 is the highest. The table has a representative vulnerability for each category.
The vulnerability prioritization shown is based on the qualitative method of assessing security risks. In other
words, it’s subjective, based on the knowledge of the systems and vulnerabilities.

© Copyright IBM Corp. 2016 6-9

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Prepare for Selecting Security Controls IBM ICE (Innovation Centre for Education)
IBM Power Systems

© Copyright IBM Corporation 2016

Figure 6-7. Prepare for Selecting Security Controls

Prepare for Selecting Security Controls

In order to select the appropriate security controls for the information system, the information system owner
collects relevant documentation specific to the information system such as the initial system security plan and
the risk assessment results. In addition, the information system owner also collects any available guidance
documentation issued by the organization. The information system owner continues their relationships with
others within the organization that are also impacted by the security control selection process (e.g.,
information security program office, information sharing partners,
contracts/acquisition organization).
Collect System Documentation
Prior to selecting security controls for an information system, the information owner collects the initial system
security plan, risk assessment results, and other available documentation on the information system. The
initial security plan includes the results of the system categorization, system description and architecture, and
interconnections with other systems. The risk assessment results include a summary of the potential threats
to and vulnerabilities in the information system and the planned or in place mitigations against those threats
and vulnerabilities.
Collect Organizational Documentation
Information owners also obtain organization-specific guidance on how to select, tailor, supplement, and
document security controls for their information systems. Typically, organizations have guidance that
elaborates on the NIST standards and guidance and that provides organization-specific implementation
details, including organization-specific tools, templates, or checklists to support the selection process. The

© Copyright IBM Corp. 2016 6-10

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
organization-specific guidance usually includes internal requirements for reporting and approving the
selected set of security controls for the information system.
Organizations also identify their common controls and the common portion of hybrid controls. The senior
information security officer is responsible for coordinating with the common control provider (e.g., facilities
managers, site managers, personnel managers) responsible for the development and implementation of the
designated common controls to ensure that the controls are put into place, assessed, and the assessment
results are shared with information system owners. The common and hybrid controls are published in a
format that allows information system owners to gain the information necessary to incorporate the common
controls and common portion of hybrid controls into their individual information systems.
Maintain Organizational Relationships
In addition to gathering documentation, information owners maintain relationships with others within their
organization. The information security program office establishes the organization-specific policies on
conducting a risk assessment, selecting security controls, and documenting the selection process in the
security plan. The office may also provide tools, templates, or checklists to assist with the selection and
documentation processes. The information security program office is the primary contact for advice and
support while selecting the security controls for individual information systems. The information owner also
works with others within the organization including the enterprise architecture group, information sharing
partners, and technical operations personnel. Each of these groups provides a portion of the information
needed to effectively select the information system’s security controls.

© Copyright IBM Corp. 2016 6-11

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Initial Security Control Baseline IBM ICE (Innovation Centre for Education)
IBM Power Systems
No. Control Name Tailoring Rationale
AC-1 Access Control Policy and Procedure
….
AC-3 Account Enforcement
….
AT-3 Security Training
AT-4 Security Training Records
….
CP-2 Contingency Plan
CP-3 Contingency Training
….
IA-3 Device Identification and Authentication
IA-4 Identifier Management
….
PE-14 Temperature and Humidity Controls
PE-15 Water Damage Protection
….
SC-12 Cryptographic Key Establishment and Management
….
SI-11 Error Handling

SI-12 Information Output Handling and Retention

© Copyright IBM Corporation 2016

Figure 6-8. Initial Security Control Baseline

Select the Initial Security Control Baseline and Minimum Assurance Requirements
Once the system’s impact level is determined, the initial set of security controls and minimum assurance
requirements are identified. The initial set of security controls is selected from the corresponding low,
moderate, or high baselines.
The minimum assurance requirements are grouped by system impact level and apply to each control within
the final, selected set of security controls.
Look Up the Initial Security Control Baseline
The system’s security impact level, identified during the Categorize Step, determines the initial security
baseline. Using the security impact level (low-, moderate-, or high impact). If a security control is not used in
a particular baseline, the entry is marked as not selected. Some security controls, supplemental guidance for
the controls, and control enhancements in the security control catalog are not used in any of the baselines but
are available for use by organizations, if needed.
Document the Initial Security Control Baseline
The security controls can be listed in a spreadsheet or table similar to the one shown. The spreadsheet/table
provides a way to summarize the decisions made during the tailoring and supplementation processes that
result in the selected set of security controls for the information system. The table can be included as an
appendix to the system security plan, while detailed information on how each of the security controls is
implemented is included in the main body of the security plan.
All the security controls in the selected baseline are listed in the appropriate column in the spreadsheet/table.
The initial information that is recorded is the family identifier, control number, and control name. Control

© Copyright IBM Corp. 2016 6-12

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
enhancements, when used to supplement basic security controls, are indicated by the number of the control
enhancement in parentheses. During the tailoring process, additional information is added to the table.
Look Up the Minimum Assurance Requirements
The assurance requirements are directed at the activities and actions that security control developers and
implementers define and apply to increase the level of confidence that the controls are implemented
correctly, operating as intended, and producing the desired outcome with respect to meeting the security
requirements for the information system. The system’s impact level determines the appropriate minimum
assurance requirements. Low-impact systems following the low baseline minimum assurance requirements,
while moderate- and high-impact systems following the moderate or high baseline minimum assurance
requirements.
Document the Minimum Assurance Requirements
The minimum assurance requirements are documented in the security plan. For example, a
moderate-impact information system is expected to implement the moderate-impact minimum assurance
requirements, recording the assurance requirements in the security plan in the general description section.

© Copyright IBM Corp. 2016 6-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Apply Scoping Guidance (1 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

© Copyright IBM Corporation 2016

Figure 6-9. Apply Scoping Guidance (1 of 2)

Apply Scoping Guidance

Organizations have the flexibility to tailor the security control baselines. Tailoring activities include: (i) the
application of appropriate scoping guidance to the initial baseline; (ii) the specification of compensating
security controls, if needed; and (iii) the specification of organization-defined parameters in the security
controls, where allowed.
When applying scoping guidance, the information system owner reviews the information system to determine
if the scoping guidance (e.g., use of common controls, physical infrastructure-related considerations, or
technology-related considerations) is applicable to each security control in the information system. If the
scoping guidance applies, the appropriate action (e.g., does not apply, downgraded) is noted in the
spreadsheet/table used to document the security control selection process.
Apply Operational/ Environmental-related Considerations
Security controls that are dependent on the nature of the operational environment are applicable only if the
information system is employed in an environment necessitating the controls. For example, temperature and
humidity controls may not be applicable to remote sensors that exist outside of the indoor facilities where
other information system components are located. Review each security control and determine if the control
does or does not apply to the information system or specific components within the information system based
on the system’s operational/environmental conditions. If the security control does not apply to the information
system, mark the control in the spreadsheet/table as does not apply and explain the rationale justifying why
the control does not apply. If the security control does not apply to specific components in the information
system (e.g., remote sensors), identify the component to which the controls do not apply.
Apply Technology-related Considerations

© Copyright IBM Corp. 2016 6-14

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
Security controls that refer to specific technologies (e.g., wireless, cryptography, public key infrastructure) are
applicable only if those technologies are employed or are required to be employed within the information
system. In addition, the security controls apply only to the components of the information system that provide
or support the security capability addressed by the control and are sources of potential risk being mitigated by
the control.
The information system owner also determines if an automated mechanism that could explicitly or implicitly
support a security control is readily available in COTS or GOTS products, is cost-effective, and technically
feasible. If the automated mechanism is not readily available, cost-effective, or technically feasible,
compensating security controls are implemented through non-automated mechanisms or procedures.
Review each security control and determine if the control does or does not apply to the information system or
specific components within the information system based on the implemented technologies and available
automated mechanisms. If the security control does not apply to the information system, mark the control in
the spreadsheet/table as does not apply and explain the rationale justifying why the control does not apply. If
the security control applies only to selected components within the information system, identify the
components to which the control applies.
Apply Physical Infrastructure-related Considerations
Security controls that refer to organizational facilities (e.g., physical controls such as locks and guards,
environmental controls for temperature, lighting, fire, and power) are applicable only to those sections of the
facilities that directly provide protection to, support for, or are related to the information system (including its
information technology assets such as email or web servers, server farms, data centers, networking nodes,
boundary protection devices, and communications equipment). Organizational facilities often implement
security controls as common controls that apply to multiple information systems. If the physical
infrastructure-related security control is implemented as a common control, mark the control in the
spreadsheet/table as common control and identify the components to which the security controls apply. The
common control may not provide sufficient security protection to the information system. If any of the system
components need system-specific infrastructure protections, in addition to common controls that apply to the
information system, the control is implemented as a hybrid control. Mark the control in the spreadsheet/table
as hybrid control and identify the components to which the security control applies. For example, emergency
power may be implemented as a common control for the facility in which the system resides, but the specific
information system requires additional availability protection based on the criticality of the information in the
system to the organization’s mission resulting in the implementation of a separate uninterrupted emergency
power source for the information system.
Apply Public Access-related Considerations
Some information systems allow public access. Security controls associated with public access information
systems are carefully considered and applied with discretion since some security controls from the specified
control baselines (e.g., identification and authentication, personnel security controls) may not be applicable to
users accessing information systems through public interfaces. The type of information accessed through
the publicly available system is also carefully considered. If users are accessing public information through a
public interface, access controls may not be necessary.
On the other hand, access controls would be required for users accessing their personal information through
a public interface or by organizational personnel that maintain and support the information system. Review
each security control and determine if the control does or does not apply to the information system or specific
components within the information system based on the public access needs associated with the information
system. If the security control does not apply to the system, mark the control in the spreadsheet/table as
does not apply and explain the rationale justifying why the control does not apply. If the security control
applies only to specific system components or system users, identify the specific components related to the
control in the spreadsheet/table.
Apply Policy/Regulatory-related Considerations
Security controls that address matters governed by applicable laws, Executive Orders, directives, policies,
standards, or regulations (e.g., privacy impact assessments) are required only if the employment of those
controls is consistent with the types of information and information systems covered by the applicable laws,
Executive Orders, directives, policies, standards, or regulations.

© Copyright IBM Corp. 2016 6-15

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Apply Scoping Guidance (2 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• The application of appropriate scoping guidance to the initial baseline

– Apply Security Objective-related Considerations
– Apply Common Control-related Considerations
– System Component Allocation-related Considerations
– Apply Scalability-related Considerations
– Document the Decisions in the Security Plan

© Copyright IBM Corporation 2016

Figure 6-10. Apply Scoping Guidance (2 of 2)

Apply Security Objective-related Considerations

Security controls that uniquely support the confidentiality, integrity, or availability security objectives may be
downgraded to the corresponding control in a lower baseline (or appropriately modified or eliminated if not
defined in a lower baseline) if, and only if, the downgrading action: (i) is consistent with the security category
for the supported security objectives of confidentiality, integrity, or availability before moving to system’s
impact level (i.e., high water mark); (ii) is supported by an organizational assessment of risk; and (iii) does not
adversely affect the level of protection for the security-relevant information within the information system.
Review each security control and determine if a security control that uniquely supports the confidentiality,
integrity, or availability of the system may be available for downgrading (e.g., if the system’s impact level is
moderate based on the security category for confidentiality and integrity being moderate, while the security
category for availability is low, controls uniquely related to availability may be downgraded to the low-impact
baseline. If the security control is downgraded to a control in a lower baseline, mark the control in the
spreadsheet/table as downgraded. If an impact value for a security objective in the security category is lower
than the system’s impact level (e.g., the impact value in the security category for availability is low, while the
system’s impact level is moderate), examine the corresponding security controls in the lower baseline and
analyze the risks to the system if the security control in the lower baseline is used and whether and how the
downgrading action affects the security-relevant information within the information system.
If a corresponding security control in the lower baseline is not selected, analyze the risks to the systems if the
security control that corresponds with the system’s impact level is not used and whether and how the
absence of the security control that corresponds with the system’s impact level affects the security-relevant
information within the system. Depending on the analysis, the security control could be eliminated or
modified to accommodate the risks to the system. If the security control is downgraded to a lower baseline or

© Copyright IBM Corp. 2016 6-16

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
control enhancement, mark the control in the spreadsheet/table as downgraded to security control
number/enhancement and explain the rationale. If the security control is modified to accommodate risks to
the system, identify the modifications. If, based on a thorough analysis, the information system owner
determines the elimination of the controls does not pose security risks to the information system, mark the
control in the spreadsheet/table as does not apply and explain the rationale.
Apply Common Control-related Considerations
Some security controls or portions of security controls are implemented by the organization and apply to
multiple information systems. These controls are known as common controls or hybrid controls. Individual
information system owners do not need to implement and assess the common controls or the common
portion of hybrid controls, but do need to identify if common or hybrid controls are applicable to the system
and incorporate the assessment results into the information system’s security plan either directly or by
reference. Every control in a baseline must be fully addressed, either by the organization or the information
system owner. The information security program office publishes the common and hybrid controls in a format
that provides contact information for each control and the applicability of the control along with guidance on
how to obtain the assessment results for the control.
Review each security control and determine if the organization has a common or hybrid control that is
applicable to the information system or specific components within the information system. If there is a
common or hybrid control that is applicable to the information system, the information system owner
determines if the common control or the common portion of the hybrid control is sufficient to meet the
information system’s requirements (e.g., does it provide sufficient protection against potential system risks).
If the security control can be implemented as a common control, mark the control in the spreadsheet/table as
common and explain the rationale justifying why the control can be implemented as a common control. If
only a portion of the control can be implemented as a common control, mark the control in the
spreadsheet/table as hybrid, explain which portion of the control is common and which portion is
system-specific, and justify why the control can be implemented as a hybrid control.
System Component Allocation-related Considerations
Security controls are applicable only to the components of the information system that provide or support the
security capability addressed by the control and are sources of potential risk being mitigated by the control.
Review the inventory of information system components to determine which security controls are applicable
to the various components and decide where to allocate the controls in order to satisfy organizational security
requirements. Document the system components that are associated with each security control. For new
system development, the system components associated with the security controls may not be known during
the Select Step. The system’s component allocation-related considerations may be refined during the
Implement Step.
Apply Scalability-related Considerations
Scalability-related considerations apply to how the control is implemented and the documentation produced
for the security control. Scalability is guided by the system’s impact level, with more detail provided for
higher-impact systems than for lower-impact systems. Organizations use discretion in applying the security
controls to information systems, giving consideration to the scalability factors in particular environments. This
approach facilitates a cost-effective, risk-based approach to security control implementation that expends no
more resources than necessary, yet achieves sufficient risk mitigation and adequate security.
Document the Decisions in the Security Plan
The information system owner documents the decisions made during the security control selection process,
providing a sound rationale for each decision. This documentation is essential when examining the overall
security considerations for the information system with respect to potential mission or business impact. When
documenting the selected set of security controls in the security plan, the extent and rigor of the rationales
provided in the plan are scaled to the system’s impact level with significantly less explanation needed for a
low-impact system than for a high-impact system.
All applications and systems must be covered by system security plans if they are categorized as a “major
application” or “general support system.” Specific security plans for other applications are not required
because the security controls for those applications or systems would be provided by the general support
systems in which they operate. For example, a department-wide Financial Management System would be a

© Copyright IBM Corp. 2016 6-17

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
major application requiring its own security plan. A local program designed to track expenditures against an
office budget might not be considered a major application and would be covered by a general support system
security plan for an office automation system or a local area network (LAN). Standard commercial
off-the-shelf software (such as word processing software, electronic mail software, utility software, or other
general- purpose software) would not typically be considered a major application and would be covered by
the plans for the general support system on which they are installed.

© Copyright IBM Corp. 2016 6-18

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Analyzing System Environment IBM ICE (Innovation Centre for Education)

IBM Power Systems

• A brief description of the technical system is provided which includes any

environmental or technical factors that raise special security concerns, such as:
– The system is connected to the Internet;
– It is located in a harsh or overseas environment;
– Software is rapidly implemented;
– The software resides on an open network used by the general public or with overseas
access;
– The application is processed at a facility outside of the organization's control; or
– The general support mainframe has dial-up lines.

© Copyright IBM Corporation 2016

Figure 6-11. Analyzing System Environment

Analyzing System Environment

The primary computing platform(s) used (e.g., mainframe, desk top, LAN or Wide Area Network (WAN)) are
described. Include a general description of the principal system components, including hardware, software,
and communications resources. The type of communications included (e.g., dedicated circuits, dial circuits,
public data/voice networks, Internet) should be clear and the controls used to protect communication lines in
the appropriate sections of the security plan should be predefined,
Any security software protecting the system and information is included in this step. The type of security
protection provided (e.g., access control to the computing platform and stored files at the operating system
level or access to data records within an application) is described in general terms. Only controls that have
been implemented or are planned, rather than listing the controls that are available in the software are
included in this process.

© Copyright IBM Corp. 2016 6-19

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Planning for security in the system

lifecycle IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Few basic phases of IT system lifecycle

– Initiation Phase
– Development/Acquisition Phase
– Implementation Phase
– Operation/Maintenance Phase

© Copyright IBM Corporation 2016

Figure 6-12. Planning for security in the system lifecycle

Planning for Security in the System Life Cycle

Although a system security plan can be developed for a system at any point in the life cycle, the
recommended approach is to draw up the plan at the beginning of the computer system life cycle. It is
recognized that in some cases, the system may at any one time be in several phases of the life cycle. For
example, a large human resources system may be in the operation/maintenance phase, while the older,
batch-oriented, input sub-system is being replaced by a new, distributed, interactive user interface. In this
case, the life cycle phases for the system are the disposal phase (data and equipment) related to the
retirement of the batch-oriented transaction system, the initiation and acquisition phase associated with the
replacement interactive input system, and the operations/maintenance phase for the balance of the system.
In this section, it is determined which phase(s) of the life cycle the system, or parts of the system, are in. It is
identified how security has been handled during the applicable life cycle phase. Listed below is a description
of each phase of the life cycle, which includes questions that will prompt the reader to identify how security
has been addressed during the life cycle phase(s) that the major application or general support system is in.
There are many models for the IT system life cycle but most contain five basic phases: Initiation,
development/acquisition, implementation, operation, and disposal.
Initiation Phase
During the initiation phase, the need for a system is expressed and the purpose of the system is documented.
A sensitivity assessment can be performed which looks at the sensitivity of the information to be processed
and the system itself.
Development/Acquisition Phase

© Copyright IBM Corp. 2016 6-20

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed.
This phase often consists of other defined cycles, such as the system development cycle or the acquisition
cycle.
During the first part of the development/acquisition phase, security requirements should be developed at the
same time system planners define the requirements of the system. These requirements can be expressed as
technical features (e.g., access controls), assurances (e.g., background checks for system developers), or
operational practices (e.g., awareness and training). If the system or part of the system is in this phase,
include a general description of any specifications that were used and whether they are being maintained.
Among the questions that should be addressed are the following:
• During the system design, were security requirements identified?
• Were the appropriate security controls with associated evaluation and test procedures developed before
the procurement action?
• Did the solicitation documents (e.g., Request for Proposals) include security requirements and
evaluation/test procedures?
• Did the requirements permit updating security requirements as new threats/vulnerabilities are identified
and as new technologies are implemented?
• If this is a purchased commercial application or the application contains commercial, off-the-shelf
components, were security requirements identified and included in the acquisition specifications?
Implementation Phase
In the implementation phase, the system’s security features should be configured and enabled, the system
should be tested and installed or fielded, and the system authorized for processing. A design review and
systems test should be performed prior to placing the system into operation to assure that it meets security
specifications. In addition, if new controls are added to the application or the support system, additional
acceptance tests of those new controls must be performed. This ensures that new controls meet security
specifications and do not conflict with or invalidate existing controls. The results of the design reviews and
system tests should be fully documented, updated as new reviews or tests are performed, and maintained in
the official organization records.
If the system or parts of the system are in the implementation phase, describe when and who conducted the
design reviews and systems tests. Include information about additional design reviews and systems tests for
any new controls added after the initial acceptance tests were completed. Discuss whether the
documentation of these reviews and tests have been kept up-to-date and maintained in the organization
records.
Operation/Maintenance Phase
During this phase, the system performs its work. The system is almost always being continuously modified
by the addition of hardware and software and by numerous other events. If the system is undergoing
modifications, determine which phase of the life cycle the system modifications are in and describe the
security activities conducted or planned for in that part of the system. For the system in the
operation/maintenance phase, the security plan documents the security activities. In appropriate sections of
this security plan, the following high-level items should be described:
• Security Operations and Administration: Operation of a system involves many security activities.
Performing backups, holding training classes, managing cryptographic keys, keeping up with user
administration and access privileges, and updating security software are some examples.
• Operational Assurance: Operational assurance examines whether a system is operated according to
its current security requirements. This includes both the actions of people who operate or use the system
and the functioning of technical controls. A management official must authorize in writing the use of the
system based on implementation of its security plan.
• Audits and Monitoring: To maintain operational assurance, organizations use two basic methods:
system audits and monitoring. These terms are used loosely within the computer security community
and often overlap. A system audit is a one-time or periodic event to evaluate security. Monitoring refers

© Copyright IBM Corp. 2016 6-21

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
to an ongoing activity that examines either the system or the users. In general, the more "real-time" an
activity is, the more it falls into the category of monitoring.
• Disposal Phase: The disposal phase of the IT system life cycle involves the disposition of information,
hardware, and software. If the system or part of the system is at the end of the life cycle, briefly describe
in this section how the following items are disposed:
• Information: Information may be moved to another system, archived, discarded, or destroyed. When
archiving information, consider the method for retrieving the information in the future. While electronic
information is generally easier to retrieve and store, the technology used to create the records may not
be readily available in the future. Measures may also have to be taken for the future use of data that has
been encrypted, such as taking appropriate steps to ensure the secure long-term storage of
cryptographic keys. It is important to consider legal requirements for records retention when disposing of
IT systems. For federal systems, system management officials should consult with their office
responsible for retaining and archiving federal records.
• Media Sanitization: The removal of information from a storage medium (such as a hard disk or tape) is
called sanitization. Different kinds of sanitization provide different levels of protection. A distinction can
be made between clearing information (rendering it unrecoverable by keyboard attack) and purging
(rendering information unrecoverable against laboratory attack). There are three general methods of
purging media: overwriting, degaussing (for magnetic media only), and destruction.

© Copyright IBM Corp. 2016 6-22

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Applying Operational Controls (1 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Describing the operational control measures

– Personnel Security

© Copyright IBM Corporation 2016

Figure 6-13. Applying Operational Controls (1 of 2)

Applying Operational Controls

The operational controls address security methods that focus on mechanisms that primarily are implemented
and executed by people (as opposed to systems). These controls are put in place to improve the security of
a particular system (or group of systems). They often require technical or specialized expertise – and often
rely upon management activities as well as technical controls. In this section, describe the operational
control measures (in place or planned) that are intended to meet the protection requirements of the target
systems.
Personnel Security
The greatest harm/disruption to a system comes from the actions of individuals, both intentional and
unintentional. All too often, systems experience disruption, damage, loss, or other adverse impact due to the
well-intentioned actions of individuals authorized to use or maintain a system (e.g., the programmer who
inserts one minor change, then installs the program into the production environment without testing).
This section includes detailed information about the following personnel security measures. It is
recommended that most of these measures be included as part of the Rules of Behavior. If they are
incorporated in the Rules of Behavior, reference the applicable section.
• Have all positions been reviewed for sensitivity level? If all positions have not been reviewed, state the
planned date for completion of position sensitivity analysis.
• A statement as to whether individuals have received the background screening appropriate for the
position to which they are assigned. If all individuals have not had appropriate background screening,
include the date by which such screening will be completed.

© Copyright IBM Corp. 2016 6-23

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
• If individuals are permitted system access prior to completion of appropriate background screening,
describe the conditions under which this is allowed and any compensating controls to mitigate the
associated risk.
• Is user access restricted (least privilege) to data files, to processing capability, or to peripherals and type
of access (e.g., read, write, execute, delete) to the minimum necessary to perform the job?
• Are critical functions divided among different individuals (separation of duties) to ensure that no individual
has all necessary authority or information access which could result in fraudulent activity?
• Is there a process for requesting, establishing, issuing, and closing user accounts?
• What mechanisms are in place for holding users responsible for their actions?
• What are the termination procedures for a friendly termination and an unfriendly termination?
Background Investigations and Personnel Selection
Only individuals who meet the requirements for sensitive positions may be members of the systems staff or
users with special access privileges, such as operator privileges.
The data center manager and the information systems security officer (ISSO), for non-mainframe AISs,
ensure that a limited background investigation (LBI) is performed for all personnel with access to the system.
Separation of Duties
The SO, the data center manager, the system manager, and the user's supervisor structure user access
privileges to reflect the separation of key duties that users perform within the function the specific application
supports. Access privileges will be consistent with the separation of duties established for manual processes.
Server Room Access
The data center manager and the system manager, designate the computer room, which houses the central
processing unit (CPU) and associated storage devices, as a limited access area restricted to authorized
personnel only.
The data center manager and the system manager limit access to the operating system and application
software designated for use on the AIS to system personnel identified on the authorized access list
While in the computer room, un-cleared visitors are under continuous visual observation by a person with
authorized unescorted access.
The data center manager and the system manager ensures that custodial and building maintenance
personnel entering the computer room are under continuous visual observation at all times by a person with
authorized unescorted access.

© Copyright IBM Corp. 2016 6-24

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Applying Operational Controls (2 of 2) IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Describing the operational control measures

– Physical and Environmental Protection

© Copyright IBM Corporation 2016

Figure 6-14. Applying Operational Controls (2 of 2)

Physical and Environmental Protection

Physical and environmental security controls are implemented to protect the facility housing system
resources, the system resources themselves, and the facilities used to support their operation. An
organization's physical and environmental security program should address the following seven topics, which
are explained below. In this section, briefly describe the physical and environmental controls in place for the
major application
Routine Maintenance and Repair Service
All personnel who service and maintain the computer and its support systems are cleared to the level of the
most sensitive material associated with the system or monitored by authorized and knowledgeable escorts.
The organization has established an effective preventive maintenance program to eliminate or reduce most
of the need for unscheduled corrective maintenance. This program also addresses remote and off-site
maintenance services.
The organization has developed an effective training program to ensure that staff members, maintenance
personnel and contractors are informed of IT security and Privacy Act restrictions and requirements.
Explanation of Physical and Environment Security
• Access Controls: Physical access controls restrict the entry and exit of personnel (and often equipment
and media) from an area, such as an office building, suite, data center, or room containing a local area
network (LAN) server. Physical access controls should address not only the area containing system
hardware, but also locations of wiring used to connect elements of the system, supporting services (such
as electric power), backup media, and any other elements required for the system's operation. It is

© Copyright IBM Corp. 2016 6-25

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
important to review the effectiveness of physical access controls in each area, both during normal
business hours and at other times -- particularly when an area may be unoccupied.
• Fire Safety Factors: Building fires are a particularly important security threat because of the potential for
complete destruction of both hardware and data, the risk to human life, and the pervasiveness of the
damage. Smoke, corrosive gases, and high humidity from a localized fire can damage systems
throughout an entire building. Consequently, it is important to evaluate the fire safety of buildings that
house systems.
• Failure of Supporting Utilities: Systems and the people who operate them need to have a reasonably
well-controlled operating environment. Consequently, failures of electric power, heating and
air-conditioning systems, water, sewage, and other utilities will usually cause a service interruption and
may damage hardware. Organizations should ensure that these utilities, including their many elements,
function properly
• Structural Collapse: Organizations should be aware that a building may be subjected to a load greater
than it can support. Most commonly this results from an earthquake, a snow load on the roof beyond
design criteria, an explosion that displaces or cuts structural members, or a fire that weakens structural
members.
• Plumbing Leaks: While plumbing leaks do not occur every day, they can be seriously disruptive. An
organization should know the location of plumbing lines that might endanger system hardware and take
steps to reduce risk (e.g., moving hardware, relocating plumbing lines, and identifying shutoff valves.)
• Interception of Data: Depending on the type of data a system processes, there may be a significant risk
if the data is intercepted. Organizations should be aware that there are three routes of data interception:
direct observation, interception of data transmission, and electromagnetic interception.
• Mobile and Portable Systems: The analysis and management of risk usually has to be modified if a
system is installed in a vehicle or is portable, such as a laptop computer. The system in a vehicle will
share the risks of the vehicle, including accidents and theft, as well as regional and local risks.
Organizations should:
• Securely store laptop computers when they are not in use; and
• Encrypt data files on stored media, when cost-effective, as a precaution against disclosure of information
if a laptop computer is lost or stolen.

© Copyright IBM Corp. 2016 6-26

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Contingency Planning IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Briefly describing the contingency plan

© Copyright IBM Corporation 2016

Figure 6-15. Contingency Planning

Contingency Planning
Procedures are required that will permit the organization to continue essential functions if information
technology support is interrupted. These procedures (contingency plans, business interruption plans, and
continuity of operations plans) should be coordinated with the backup, contingency, and recovery plans of
any general support systems, including networks used by the application. The contingency plans should
ensure that interfacing systems are identified and contingency/disaster planning coordinated.
Briefly describe the procedures (contingency plan) that would be followed to ensure the application continues
to be processed if the supporting IT systems were unavailable and provide the detailed plans as an
attachment. Include consideration of the following questions in this description:
• Are tested contingency plans in place to permit continuity of mission-critical functions in the event of a
catastrophic event?
• Are tested disaster recovery plans in place for all supporting IT systems and networks?
• Are formal written emergency operating procedures posted or located to facilitate their use in emergency
situations?
• How often are contingency, disaster, and emergency plans tested?
• Are all employees trained in their roles and responsibilities relative to the emergency, disaster, and
contingency plans?
Include descriptions of the following controls:
• Any agreements for backup processing (e.g., hotsite contract with a commercial service provider).

© Copyright IBM Corp. 2016 6-27

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
• Documented backup procedures including frequency (daily, weekly, monthly) and scope (full backup,
incremental backup, and differential backup).
• Location of stored backups (off-site or on-site).
• Generations of backups kept.
• Coverage of backup procedures, e.g., what is being backed up.

© Copyright IBM Corp. 2016 6-28

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Maintenance controls IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Maintenance controls with examples

© Copyright IBM Corporation 2016

Figure 6-16. Maintenance controls

Maintenance Controls
These controls are used to monitor the installation of, and updates to, application software to ensure that the
software functions as expected and that a historical record is maintained of application changes. This helps
ensure that only authorized software is installed on the system.
Such controls may include a software configuration policy that grants managerial approval (re-authorize
processing) to modifications and requires that changes be documented. Other controls include products and
procedures used in auditing for or preventing illegal use of shareware or copyrighted software. Software
maintenance procedures may also be termed version control, change management, or configuration
management. The following questions are examples of items that should be addressed in responding to this
section:
• Was the application software developed in-house or under contract?
• Does the government own the software?
• Was the application software received from another federal agency with the understanding that it is
federal government property?
• Is the application software a copyrighted commercial off-the-self product or shareware?
• If a copyrighted commercial off-the-self product (or shareware), were sufficient licensed copies of the
software purchased for all of the systems on which this application will be processed?
• Is there a formal change control process in place for the application, and if so, does it require that all
changes to the application software be tested and approved before being put into production?

© Copyright IBM Corp. 2016 6-29

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
• Are test data “live” data or made-up data?
• Are all changes to the application software documented?
• Have trap door “hot keys” been activated for emergency data repairs?
• Are test results documented?
• How are emergency fixes handled?
• Are there organizational policies against illegal use of copyrighted software or shareware?
• Are periodic audits conducted of users’ computers (PCs) to ensure only legal licensed copies of software
are installed?
• What products and procedures are used to protect against illegal use of software?
• Are software warranties managed to minimize the cost of upgrades and cost-reimbursement or
replacement for deficiencies?
These controls are used to monitor the installation of, and updates to, hardware, operating system software,
and other software to ensure that the hardware and software function as expected, and that a historical
record is maintained of application changes. These controls may also be used to ensure that only authorized
software is installed on the system. Such controls may include a hardware and software configuration policy
that grants managerial approval (re-authorize processing) to modifications and requires that changes be
documented. Other controls include products and procedures used in auditing for, or preventing, illegal use
of shareware or copyrighted software. In this section, provide several paragraphs on the hardware and
system software maintenance controls in place or planned. The following statements are examples of items
that should be addressed in responding to this section:
• Are procedures in place to ensure that maintenance and repair activities are accomplished without
adversely affecting system security? Consider the following items:
▪ Restriction/controls on those who perform maintenance and repair activities.
▪ Special procedures for performance of emergency repair and maintenance.
▪ Management of hardware/software warranties and upgrade policies to maximize use of such items to
minimize costs.
▪ Procedures used for items serviced through on-site and off-site maintenance (e.g., escort of
maintenance personnel, sanitization of devices removed from the site).
▪ Procedures used for controlling remote maintenance services where diagnostic procedures or
maintenance is performed through telecommunications arrangements.
• Describe the configuration management procedures for the system. Consider the following items in the
description:
▪ Version control that allows association of system components to the appropriate system version.
▪ Procedures for testing and/or approving system components (operating system, other system, utility,
applications) prior to promotion to production.
▪ Impact analyses to determine the effect of proposed changes on existing security controls to include
the required training for both technical and user communities associated with the change in
hardware/software.
▪ Change identification, approval, and documentation procedures.
▪ Procedures for ensuring contingency plans and other associated documentation are updated to
reflect system changes.
▪ Are test data “live” data or made-up data?
▪ How are emergency fixes handled?
• Describe the policies for handling copyrighted software or shareware. Consider including in this
description answers to the following questions:
▪ Are there organizational policies against illegal use of copyrighted software or shareware?

© Copyright IBM Corp. 2016 6-30

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
▪ Do the policies contain provisions for individual and management responsibilities and accountability,
including penalties?
▪ Are periodic audits conducted of users’ computers (PCs) to ensure only legal licensed copies of
software are installed?
▪ What products and procedures are used to protect against illegal use of software?
▪ Are software warranties managed to minimize the cost of upgrades and cost-reimbursement or
replacement for deficiencies?

© Copyright IBM Corp. 2016 6-31

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Data integrity/validation controls IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Describing the Data integrity/validation controls

– Various data integrity/validation Controls
– Malicious Programs
– Virus Protection
– Message Authentication
– Integrity Verification
– Reconciliation

© Copyright IBM Corporation 2016

Figure 6-17. Data integrity/validation controls

Data Integrity/Validation Controls

Data integrity controls are used to protect data from accidental or malicious alteration or destruction and to
provide assurance to the user that the information meets expectations about its quality and that it has not
been altered. Validation controls refer to tests and evaluations used to determine compliance with security
specifications and requirements.
In this section, describe any controls that provide assurance to users that the information has not been
altered and that the system functions as expected. The following questions are examples of some of the
controls that fit in this category:
• Are password crackers/checkers used?
• Are intrusion detection tools installed on the system? Describe where the tool(s) are placed, the type of
processes detected/reported, and the procedures for handling intrusions.
• Is system performance monitoring used to analyze system performance logs in real time to look for
availability problems, including active attacks, and system and network slowdowns and crashes?
• Is penetration testing performed on the system? If so, what procedures are in place to ensure they are
conducted appropriately?
Malicious Programs
Are there sufficient controls associated with the installation of software included in the configuration
management program to identify malicious programs?
Virus Protection

© Copyright IBM Corp. 2016 6-32

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
Is virus detection and elimination software installed? If so, are there procedures for:
• Updating virus signature files
• Automatic and/or manual virus scans (automatic scan on network log-in, automatic scan on client/server
power on, automatic scan on diskette insertion, automatic scan on download from an unprotected source
such as the Internet, scan for macro viruses)
• Virus eradication and reporting
Message Authentication
Is message authentication used in the application to ensure that the sender of a message is known and that
the message has not been altered during transmission? State whether message authentication has been
determined to be appropriate for your system. If so, describe the methodology.
Integrity Verification
Are integrity verification programs used by applications to look for evidence of data tampering, errors, and
omissions? Techniques include consistency and reasonableness checks and validation during data entry
and processing. Describe the integrity controls used within the system.
Reconciliation
Are reconciliation routines used by the system, i.e., checksums, hash totals, record counts? Include a
description of the actions taken to resolve any discrepancies.

© Copyright IBM Corp. 2016 6-33

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Documentation IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Examples of documentation for major application

© Copyright IBM Corporation 2016

Figure 6-18. Documentation

Documentation
Documentation is a security control in that it explains how software/hardware is to be used and formalizes
security and operational procedures specific to the system. Documentation for a system includes descriptions
of the hardware and software, policies, standards, procedures, and approvals related to automated
information system security in the application and the support system(s) on which it is processed, to include
backup and contingency activities, as well as descriptions of user and operator procedures.
Documentation should be coordinated with the general support system and/or network manager(s) to ensure
that adequate application and installation documentation are maintained to provide continuity of operations
List the documentation maintained for the application
The example lists are provided to show the type of documentation that would normally be maintained for each
type of system and are not intended to be all inclusive or imply that all systems should have all items listed.
Examples of General Support System Documentation
• Vendor-supplied documentation of hardware
• Vendor-supplied documentation of software
• General support system security plan
• Testing procedures and results
• Standard operating procedures
• Emergency procedures

© Copyright IBM Corp. 2016 6-34

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
• Contingency plans
• Disaster recovery plans
• User rules of behavior
• User manuals
• Risk assessment
• Backup procedures
• Authorize processing documents and statements
Example Documentation for Major Application
• Vendor-supplied documentation of hardware
• Vendor-supplied documentation of software
• Application requirements
• Application security plan
• General support system(s) security plan(s)
• Application program documentation and specifications
• Testing procedures and results
• Standard operating procedures
• Emergency procedures
• Contingency plans
• Memoranda of understanding with interfacing systems
• Disaster recovery plans
• User rules of behavior
• User manuals
• Risk assessment
• Backup procedures
• Authorize processing documents and statement

© Copyright IBM Corp. 2016 6-35

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Implementing Security Policy IBM ICE (Innovation Centre for Education)

IBM Power Systems

Scope of security policy properties

© Copyright IBM Corporation 2016

Figure 6-19. Implementing Security Policy

Implementing Security Policy

System security is a condition that results from the establishment and sustainment of protective measures
that contribute to continuous achievement of mission/business objectives despite risks posed by potential
threats throughout the system life cycle. The condition that determines what it means for a system to be
secure is specified by security policy. Security policy is a fundamental computer security concept that differs
from security requirements. Security policy is a set of rules that governs all aspects of security-relevant
behavior of individuals and processes acting on behalf of individuals. Such security-relevant behavior can be
exhibited, for example, by systems, subsystems, components, mechanisms, services, and infrastructures.
Security policy is enforced:
• by individuals (i.e., procedurally);
• by devices in the physical environment (i.e., physically); and
• by automated mechanisms implemented in the hardware, firmware, and software of the system.
Security policy is intended to be enforced continuously and is intrinsically related to the concepts of trust and
trustworthiness. One condition that must be satisfied for a system to be deemed trustworthy is that there is
sufficient confidence or assurance that the system is capable of enforcing security policy on a continuous
basis. The implications associated with demonstrating the continuous enforcement of security policy at the
system level is what distinguishes systems security engineering from its composite security specialties and
from systems engineering and related engineering specialties - particularly those concerned with accuracy,
availability, fault tolerance, performance, reliability, sustainability, human safety, and general functional

© Copyright IBM Corp. 2016 6-36

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
correctness. Security policy is expressed in terms of the foundational security properties of confidentiality,
integrity, and availability.
Confidentiality: Rules that govern access to, use of (i.e., operations that can be performed on), and
disclosure of resources. While confidentiality policy typically applies to information and data, it may also apply
to protect the knowledge of and the use of capabilities operating on the data (e.g., functions, mechanisms,
services, and infrastructures);
Integrity: Rules that govern the authorized manners in which data, information, and other resources (e.g.,
mechanisms, functions, processes, services, and infrastructures) can be manipulated; and
Availability: Rules that govern the ability to access and use data, information, or a resource

Security policy addresses all aspects of confidentiality but only the security-relevant aspects of integrity and
availability. Whereas confidentiality protections against unauthorized access and unauthorized disclosure of
resources are fully addressed by the security discipline, the scope of integrity protections and availability
protections are addressed by the combination of security and other specialty disciplines. The integrity and
availability scope overlap leads to confusion when the basis for the protection need is not properly allocated
or understood. The confusion is often the source of design conflicts and contradictions that are best resolved
through informed trade space analysis among all impacted and contributing disciplines. Security policy
distinguishes the security-relevant aspects of integrity protections and availability protections from the
integrity and availability protections that are addressed by other specialty disciplines. System security policy
(i.e., automated security policy) specifies what a trusted system is trusted to do. It is the set of restrictions and
properties that specify how a system enforces or contributes to the enforcement of an organizational security
policy. This includes, for example, defining how an operating system governs executing processes and the
use of system resources, or how a firewall mediates the flow of incoming and outgoing data packets. The
system security policy has the restriction that its scope of authority is limited to the resources within the scope
of control of the system. Each instance of a system security policy is properly matched to the set of resources
that are within the scope of control of the system and the capabilities of the security-relevant elements of the
system that enforce the system security policy. Any resource operation that is not authorized by or specified
by the system security policy violates organizational security policy. The transformation of an organizational
security policy to a system security policy is supported by policy-driven verification and validation activities
that are equivalent to those used to verify the system against its design requirements and to validate the
system against stakeholder requirements.
The IT system security is generally limited to guaranteeing the right to access a system's data and resources
by setting up authentication and control mechanisms that ensure that the users of these resources only have
the rights that were granted to them.
And yet security mechanisms can create difficulties for users. Instructions and rules often become
increasingly complicated as networks grow. Thus, IT security must be studied in such a way that it does not
prevent users from developing uses that they need and so that they can use information systems securely.
This is why one of the first steps a company must take is to define a security policy, which is implemented
with the four following stages:
• Identify the security needs and the IT risks that the company faces and their possible consequences
• Outline the rules and procedures that must be implemented for the identified risks in the organization's
different departments
• Monitor and detect the information system's vulnerabilities and keep informed of the flaws in the
applications and materials being used
• Define the actions to be taken and the individuals to contact in case a threat is detected
The security policy is all of the security rules that an organization (in the general sense of the word) follows.
Therefore, it must be defined by the management of the organization in question because it affects all the
system's users.
In this respect, it is not the job of the IT administrators to define user access rights but rather that of their
superiors. An IT administrator's role is to ensure that IT resources and the access rights to these resources
are in line with the security policy

© Copyright IBM Corp. 2016 6-37

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
defined by the organization.
Moreover, given that he or she is the only person who masters the system, he or she must give security
information to the management, advise the decision makers on the strategies to be implemented, and be the
entry point for communications intended for users about problems and security recommendations.
A company's IT security depends on employees (users) learning the rules through training and
awareness-building sessions. However, security must go beyond employee knowledge and cover the
following areas:
• A physical and logical security mechanism that is adapted to the needs of the company and to employee
use
• A procedure for managing updates
• A properly planned backup strategy
• A post-incident recovery plan
• An up-to-date documented system
Security considerations in system support and operations
System support and operations refers to everything done to run a computer system. This includes both
system administration and tasks external to the system that support its operation (e.g., maintaining
documentation). It does not include system planning or design. The support and operation of any computer
system, from a three-person local area network to a worldwide application serving thousands of users, is
critical to maintaining the security of a system. Support and operations are routine activities that enable
computer systems to function correctly. These include fixing software or hardware problems, loading and
maintaining software, and helping users resolve problems.
System management and administration staff generally perform support and operations tasks although
sometimes users do. Larger systems may have full-time operators, system programmers, and support staff
performing these tasks. Smaller systems may have a part-time administrator.
The failure to consider security as part of the support and operations of computer systems is, for many
organizations, their Achilles heel. Computer security system literature includes many examples of how
organizations undermined their often expensive security measures because of poor documentation, old user
accounts, conflicting software, or poor control of maintenance accounts. Also, an organization's policies and
procedures often fail to address many of these important issues.
The primary goal of computer support and operations is the continued and correct operation of a computer
system. One of the goals of computer security is the availability and integrity of systems. These goals are
very closely linked.
The important security considerations within some of the major categories of support and operations are:
• user support,
• software support,
• configuration management,
• backups,
• media controls,
• documentation, and
• maintenance

© Copyright IBM Corp. 2016 6-38

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Security considerations IBM ICE (Innovation Centre for Education)

IBM Power Systems

• Explaining the security considerations in system support and operations

© Copyright IBM Corporation 2016

Figure 6-20. Security considerations

Security considerations in system support and operations

System support and operations refers to everything done to run a computer system. This includes both
system administration and tasks external to the system that support its operation (e.g., maintaining
documentation). It does not include system planning or design. The support and operation of any computer
system, from a three-person local area network to a worldwide application serving thousands of users, is
critical to maintaining the security of a system. Support and operations are routine activities that enable
computer systems to function correctly. These include fixing software or hardware problems, loading and
maintaining software, and helping users resolve problems.
System management and administration staff generally perform support and operations tasks although
sometimes users do. Larger systems may have full-time operators, system programmers, and support staff
performing these tasks. Smaller systems may have a part-time administrator.
The failure to consider security as part of the support and operations of computer systems is, for many
organizations, their Achilles heel. Computer security system literature includes many examples of how
organizations undermined their often expensive security measures because of poor documentation, old user
accounts, conflicting software, or poor control of maintenance accounts. Also, an organization's policies and
procedures often fail to address many of these important issues.
The primary goal of computer support and operations is the continued and correct operation of a computer
system. One of the goals of computer security is the availability and integrity of systems. These goals are
very closely linked.
The important security considerations within some of the major categories of support and operations are:

© Copyright IBM Corp. 2016 6-39

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
• user support,
• software support,
• configuration management,
• backups,
• media controls,
• documentation, and
• maintenance

© Copyright IBM Corp. 2016 6-40

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Important security considerations

(1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Important security considerations within some of the major categories

– user support,
– software support,
– configuration management,
– backups,

© Copyright IBM Corporation 2016

Figure 6-21. Important security considerations (1 of 2)

User support
In many organizations, user support takes place through a Help Desk. Help Desks can support an entire
organization, a subunit, a specific system, or a combination of these. For smaller systems, the system
administrator normally provides direct user support. Experienced users provide informal user support on
most systems.
An important security consideration for user support personnel is being able to recognize which problems
(brought to their attention by users) are security-related. For example, users' inability to log onto a computer
system may result from the disabling of their accounts due to too many failed access attempts. This could
indicate the presence of hackers trying to guess users' passwords.
In general, system support and operations staff need to be able to identify security problems, respond
appropriately, and inform appropriate individuals. A wide range of possible security problems exist. Some
will be internal to custom applications, while others apply to off-the-shelf products. Additionally, problems can
be software- or hardware-based.
Small systems are especially susceptible to viruses, while networks are particularly susceptible to hacker
attacks, which can be targeted at multiple systems. System support personnel should be able to recognize
attacks and know how to respond.
The more responsive and knowledgeable system support and operation staff personnel are, the less user
support will be provided informally. The support other users provide is important, but they may not be aware
of the "whole picture."

© Copyright IBM Corp. 2016 6-41

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
Software support
Software is the heart of an organization's computer operations, whatever the size and complexity of the
system. Therefore, it is essential that software function correctly and be protected from corruption. There are
many elements of software support.
One is controlling what software is used on a system. If users or systems personnel can load and execute
any software on a system, the system is more vulnerable to viruses, to unexpected software interactions, and
to software that may subvert or bypass security controls. Viruses take advantage of the weak software
controls in personal computers. Also, there are powerful utilities available for PCs that can restore deleted
files, find hidden files, and interface directly with PC hardware, bypassing the operating system. Some
organizations use personal computers without floppy drives in order to have better control over the system.
There are several widely available utilities that look for security problems in both networks and the systems
attached to them. Some utilities look for and try to exploit security vulnerabilities.
One method of controlling software is to inspect or test software before it is loaded (e.g., to determine
compatibility with custom applications or identify other unforeseen interactions). This can apply to new
software packages, to upgrades, to off-the-shelf products, or to custom software, as deemed appropriate. In
addition to controlling the loading and execution of new software, organizations should also give care to the
configuration and use of powerful system utilities. System utilities can compromise the integrity of operating
systems and logical access controls.
A second element in software support can be to ensure that software has not been modified without proper
authorization. This involves the protection of software and backup copies. This can be done with a
combination of logical and physical access controls.
Many organizations also include a program to ensure that software is properly licensed, as required. For
example, an organization may audit systems for illegal copies of copyrighted software. This problem is
primarily associated with PCs and LANs, but can apply to any type of system.
Configuration management
Closely related to software support is configuration management, the process of keeping track of changes to
the system and, if needed, approving them. Configuration management normally addresses hardware,
software, networking, and other changes; it can be formal or informal. The primary security goal of
configuration management is ensuring that changes to the system do not unintentionally or unknowingly
diminish security. Some of the methods discussed under software support, such as inspecting and testing
software changes, can be used. Chapter 9 discusses other methods.
Note that the security goal is to know what changes occur, not to prevent security from being changed. There
may be circumstances when security will be reduced. However, the decrease in security should be the result
of a decision based on all appropriate factors.
A second security goal of configuration management is ensuring that changes to the system are reflected in
other documentation, such as the contingency plan. If the change is major, it may be necessary to reanalyse
some or all of the security of the system.
Backups
Support and operations personnel and sometimes users back up software and data. This function is critical to
contingency planning. Frequency of backups will depend upon how often data changes and how important
those changes are. Program managers should be consulted to determine what backup schedule is
appropriate. Also, as a safety measure, it is useful to test that backup copies are actually usable.

© Copyright IBM Corp. 2016 6-42

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Important security considerations

(1 of 2) IBM ICE (Innovation Centre for Education)
IBM Power Systems

• Important security considerations within some of the major categories

– media controls,
– documentation
– maintenance

© Copyright IBM Corporation 2016

Figure 6-22. Important security considerations (1 of 2)

Media controls
Media controls include a variety of measures to provide physical and environmental protection and
accountability for tapes, diskettes, printouts, and another media. From a security perspective, media controls
should be designed to prevent the loss of confidentiality, integrity, or availability of information, including data
or software, when stored outside the system. This can include storage of information before it is input to the
system and after it is output.
The extent of media control depends upon many factors, including the type of data, the quantity of media,
and the nature of the user environment. Physical and environmental protection is used to prevent
unauthorized individuals from accessing the media. It also protects against such factors as heat, cold, or
harmful magnetic fields. When necessary, logging the use of individual media (e.g., a tape cartridge)
provides detailed accountability to hold authorized people responsible for their actions.
• Marking
Controlling media may require some form of physical labelling. The labels can be used to identify media with
special handling instructions, to locate needed information, or to log media (e.g., with serial/control numbers
or bar codes) to support accountability. Identification is often by coloured labels on diskettes or tapes or
banner pages on printouts.
If labelling is used for special handling instructions, it is critical that people be appropriately trained. The
marking of PC input and output is generally the responsibility of the user, not the system support staff.
Marking backup diskettes can help prevent them from being accidentally overwritten.
• Logging

© Copyright IBM Corp. 2016 6-43

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
The logging of media is used to support accountability. Logs can include control numbers (or other tracking
data), the times and dates of transfers, names and signatures of individuals involved, and other relevant
information. Periodic spot checks or audits may be conducted to determine that no controlled items have
been lost and that all are in the custody of individuals named in control logs. Automated media tracking
systems may be helpful for maintaining inventories of tape and disk libraries.
• Integrity verification
When electronically stored information is read into a computer system, it may be necessary to determine
whether it has been read correctly or subject to any modification. The integrity of electronic information can
be verified using error detection and correction or, if intentional modifications are a threat,
cryptographic-based technologies.
• Physical access protection
Media can be stolen, destroyed, replaced with a look-alike copy, or lost. Physical access controls, which can
limit these problems, include locked doors, desks, file cabinets, or safes.
If the media requires protection at all times, it may be necessary to actually output data to the media in a
secure location (e.g., printing to a printer in a locked room instead of to a general purpose printer in a
common area).
Physical protection of media should be extended to backup copies stored offsite. They generally should be
accorded an equivalent level of protection to media containing the same information stored onsite.
• Environmental protection
Magnetic media, such as diskettes or magnetic tape, require environmental protection, since they are
sensitive to temperature, liquids, magnetism, smoke, and dust. Other media (e.g., paper and optical storage)
may have different sensitivities to environmental factors.
• Transmittal
Media control may be transferred both within the organization and to outside elements. Possibilities for
securing such transmittal include sealed and marked envelopes, authorized messenger or courier, or certified
or registered mail.
• Disposition
When media is disposed of, it may be important to ensure that information is not improperly disclosed. This
applies both to media that is external to a computer system (such as a diskette) and to media inside a
computer system, such as a hard disk. The process of removing information from media is called
sanitization.
Three techniques are commonly used for media sanitization: overwriting, degaussing, and destruction.
Overwriting is an effective method for clearing data from magnetic media. As the name implies, overwriting
uses a program to write (1s, 0s, or a combination) onto the media. Common practice is to overwrite the
media three times. Overwriting should not be confused with merely deleting the pointer to a file (which
typically happens when a delete command is used). Overwriting requires that the media be in working order.
Degaussing is a method to magnetically erase data from magnetic media. Two types of degausser exist:
strong permanent magnets and electric degaussers. The final method of sanitization is destruction of the
media by shredding or burning.
Documentation
Documentation of all aspects of computer support and operations is important to ensure continuity and
consistency. Formalizing operational practices and procedures with sufficient detail helps to eliminate
security lapses and oversights, gives new personnel sufficiently detailed instructions, and provides a quality
assurance function to help ensure that operations will be performed correctly and efficiently.
The security of a system also needs to be documented. This includes many types of documentation, such as
security plans, contingency plans, risk analyses, and security policies and procedures. Much of this
information, particularly risk and threat analyses, has to be protected against unauthorized disclosure.
Security documentation also needs to be both current and accessible. Accessibility should take special
factors into account (such as the need to find the contingency plan during a disaster).

© Copyright IBM Corp. 2016 6-44

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty
Security documentation should be designed to fulfill the needs of the different types of people who use it. For
this reason, many organizations separate documentation into policy and procedures. A security procedures
manual should be written to inform various system users how to do their jobs securely. A security procedures
manual for systems operations and support staff may address a wide variety of technical and operational
concerns in considerable detail.
Maintenance
System maintenance requires either physical or logical access to the system. Support and operations staff,
hardware or software vendors, or third-party service providers may maintain a system. Maintenance may be
performed on site, or it may be necessary to move equipment to a repair site. Maintenance may also be
performed remotely via communications connections. If someone who does not normally have access to the
system performs maintenance, then a security vulnerability is introduced.
In some circumstances, it may be necessary to take additional precautions, such as conducting background
investigations of service personnel. Supervision of maintenance personnel may prevent some problems,
such as "snooping around" the physical area. However, once someone has access to the system, it is very
difficult for supervision to prevent damage done through the maintenance process.
Many computer systems provide maintenance accounts. These special log-in accounts are normally
preconfigured at the factory with pre-set, widely known passwords. It is critical to change these passwords or
otherwise disable the accounts until they are needed. Procedures should be developed to ensure that only
authorized maintenance personnel can use these accounts. If the account is to be used remotely,
authentication of the maintenance provider can be performed using call-back confirmation. This helps ensure
that remote diagnostic activities actually originate from an established phone number at the vendor's site.
Other techniques can also help, including encryption and decryption of diagnostic communications; strong
identification and authentication techniques, such as tokens; and remote disconnect verification.

© Copyright IBM Corp. 2016 6-45

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
1. Which one of the following is an attribute to be considered when deciding which attributes to track for
each information asset?
A. MAC address
B. Serial number
C. Manufacturer name
D. All of the above
2. What is the step prior to determining whether asset categories are meaningful to the organization’s
risk management program?
A. Threat identification
B. Classification and categorization of assets
C. Identification of data assets
D. None of the above
3. When public access-related considerations are being applied, what is the correct step to be taken in
the case the security control does not apply to the system?
A. Mark the control in the spreadsheet/table as does not apply
B. Explain the rationale justifying why the control does not apply
C. Identify the specific components related to the control in the spreadsheet/table
D. Both A and B

© Copyright IBM Corporation 2016

Figure 6-23. Checkpoint

© Copyright IBM Corp. 2016 6-46

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
4. In which phase of the IT system life cycle, system is designed, purchased, programmed, developed,
or otherwise constructed?
A. Initiation phase
B. Development/acquisition phase
C. Operation/maintenance phase
D. Implementation phase
5. Who ensures that custodial and building maintenance personnel entering the computer room are
under continuous visual observation at all times by a person with authorized unescorted access?
A. Head of IT department
B. The data center manager
C. The system manager
D. Both B and C
6. Which controls are used to monitor the installation of, and updates to, application software to ensure
that the software functions as expected?
A. Data integrity/validation controls
B. Maintenance controls
C. Software controls
D. None of the above

© Copyright IBM Corporation 2016

Figure 6-24. Checkpoint

© Copyright IBM Corp. 2016 6-47

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
7. Security policy can be enforced by
A. individuals
B. by devices in the physical environment
C. by automated mechanisms implemented in the hardware, firmware, and software of the system
D. All of the above
8. Which property of the security policy deals with protections against unauthorized access and
unauthorized disclosure of resources?
A. Availability
B. Integrity
C. Confidentiality
D. Technicality
9. Which of the following is not true for software support while implementing security policy?
A. It should be ensured that software has not been modified without proper authorization
B. It should be easily recognizable which problems (brought to their attention by users) are security-
related
C. Care is given to the configuration and use of powerful system utilities
D. Both A and C

© Copyright IBM Corporation 2016

Figure 6-25. Checkpoint

© Copyright IBM Corp. 2016 6-48

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Checkpoint IBM ICE (Innovation Centre for Education)

IBM Power Systems
10. Which controls include a variety of measures to provide physical and environmental protection and
accountability for tapes, diskettes, printouts, and another media?
A. Media controls
B. Software controls
C. Hardware controls
D. None of the above

© Copyright IBM Corporation 2016

Figure 6-26. Checkpoint

© Copyright IBM Corp. 2016 6-49

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Unit 6. IT System Security Processes

Uempty

Unit summary IBM ICE (Innovation Centre for Education)

IBM Power Systems

Having completed this unit, you should be able to:

• Know how to identify assets, threats and vulnerabilities before applying system security
mechanisms
• Understand importance of examining tools, techniques and technologies involves in system
security processes
• Understand when and where to apply operational controls
• Get an insight on the aspects involved in implementation of security policy

© Copyright IBM Corporation 2016

Figure 6-27. Unit summary

© Copyright IBM Corp. 2016 6-50

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Appendix A. Review answers

AP

Appendix A. Review answers

Unit 1, "Introduction to IT system security"
Solutions for Figure 1-21, "Checkpoint," on page 1-66

Checkpoint Solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems
1. A
2. C
3. A
4. A
5. C
6. D
7. A
8. C
9. D
10. D

© Copyright IBM Corporation 2016

© Copyright IBM Corp. 2016 A-1

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Appendix A. Review answers

AP
Unit 2, "Operating System Security"
Solutions for Figure 2-55, "Checkpoint," on page 2-82

Checkpoint solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems

1. B
2. A
3. A
4. A
5. A
6. A
7. A
8. D
9. A
10. B

© Copyright IBM Corporation 2016

© Copyright IBM Corp. 2016 A-2

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Appendix A. Review answers

AP
Unit 3, "Endpoint Security"
Solutions for Figure 3-25, "Checkpoint," on page 3-63

Checkpoint solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems

1. D
2. A
3. A
4. D
5. A
6. D
7. C
8. A
9. A
10. D

© Copyright IBM Corporation 2016

© Copyright IBM Corp. 2016 A-3

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Appendix A. Review answers

AP
Unit 4, "Application Server Security"
Solutions for Figure 4-24, "Checkpoint," on page 4-43

Checkpoint solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems

1. B
2. D
3. A
4. D
5. C
6. A
7. A
8. B
9. C
10. D

© Copyright IBM Corporation 2016

© Copyright IBM Corp. 2016 A-4

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Appendix A. Review answers

AP
Unit 5, "Database Server Security"
Solutions for Figure 5-19, "Checkpoint," on page 5-48

Checkpoint solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems

1. D
2. B
3. B
4. C
5. A
6. D
7. C
8. A
9. A
10. D

© Copyright IBM Corporation 2016

© Copyright IBM Corp. 2016 A-5

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
V11.0
Appendix A. Review answers

AP
Unit 6, "IT System Security Processes"
Solutions for Figure 6-26, "Checkpoint," on page 6-49

Checkpoint solutions IBM ICE (Innovation Centre for Education)

IBM Power Systems

1. D
2. D
3. D
4. B
5. D
6. B
7. D
8. C
9. D
10. A

© Copyright IBM Corporation 2016

© Copyright IBM Corp. 2016 A-6

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.