12. Poesía Un caso especial lo constituyen algunos programas de telerrealidad concebidos para el mundo árabe, que cuentan las grandes diferencias culturales con
2.11 MARCO CONCEPTUAL
Appendix A.
Developing a custom
collector
This appendix provides the implementation details of the Security Compliance Manager custom collector for Tivoli Risk Manager.
The TivoliRiskManager collector consists of one class, TivoliRiskManagerV1, which extends the class com.ibm.jac.CollectorV2. The required methods in this appendix have to be implemented.
Required method getReleaseNumber()
This method (Example A-1) is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-1 Required method getReleaseNumber()
private static final int RELEASE = 1; public int getReleaseNumber() { return RELEASE;
}
Required method getCompatibleOS()
This method (Example A-2) returns a String array containing the list of the operating systems that the collector can run on. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector. Example: A-2 Required method getCompatibleOS()
private static final String[] COMPATIBLE_OS = { "Windows", ”SunOS", "AIX", "Linux", ”HP-UX" }; public String[] getCompatibleOS() {
return COMPATIBLE_OS; }
Required method getDescription()
This method (Example A-3) returns a String containing the description of the collector. This method is defined as abstract in the CollectorV2 class and must be implemented by any user defined collector.
Example: A-3 Required method getDescription()
private static final String DESCRIPTION = "Collector gathers installation, version, and status information of a Tivoli Risk Manager Agent";
public String getDescription() { return DESCRIPTION;
}
Required method getParameters()
This method (Example A-4) returns a Vector of Strings containing the names of the parameters supported by the collector. As the TivoliRiskManagerV1 collector does not require any parameter, we return an empty Vector. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-4 Required method getParameters()
public Vector getParameters() { return new Vector();
}
Required method getTables()
This method (Example A-5) returns an array of class CollectorTable that describes the structure of the collector database tables. Each database table defined by the collector is represented by an array element. This method is defined as abstract in the CollectorV2 class and must be implemented by any collector.
Example: A-5 Required method getTables()
private static final String[] TABLENAME = { "ANY_TIVOLI_RISKMGR" }; private static final CollectorTable.Column[][] TABLE_DEFINITION = {
{ new CollectorTable.Column("OS",Types.VARCHAR,30), new CollectorTable.Column("TRM_INSTALLED",Types.VARCHAR,75), new CollectorTable.Column("TRM_ACTIVE",Types.VARCHAR,25), new CollectorTable.Column("TRM_VERSION",Types.VARCHAR,15), new CollectorTable.Column("TRM_HASH_FILE",Types.VARCHAR,150), new CollectorTable.Column("TRM_HASH_VALUE",Types.VARCHAR,75) } };
public CollectorTable[] getTables(){
CollectorTable[] tables = new CollectorTable[TABLENAME.length]; for(int i = 0; i < TABLENAME.length; i++) {
tables[i] = new CollectorTable(TABLENAME[i]); }
tables[i].addColumn(TABLE_DEFINITION[i][j]); }
}
return tables; }
Required method executeV2()
This method (Example A-6) gathers compliance data from the client. In this method, we implement the actual functionality of the collector. Compliance data is returned as an array of class Message. Each array element represents the data for one database table. This method is defined as abstract in the
CollectorV2 class and must be implemented by any collector. The logic of this method is:
1. Initialize data objects, which are used to return the collected data. 2. Detect the operating system the collector is running on.
3. For each platform, collect the data.
4. Return the records for the database tables. Example: A-6 Required method executeV2()
public Message[] executeV2() { Message[] stats;
Vector[] columns; CollectorTable[] tables; String[] headers; Object[] record = null; String str = "";
String Value = "";
/*
* Get the table information for this collector. */
tables = getTables(); /*
* Allocate an array of Vectors to contain the database * table column information for this collector. Allocate * a vector for each database table used by the collector. */
columns = new Vector[TABLENAME.length]; /*
* collector. Allocate a Message object for each database table. */
stats = new Message[TABLENAME.length]; /*
* Instantiate the message array. */
for (int i = 0; i < TABLENAME.length; i++) { stats[i] = new Message(TABLENAME[i]); columns[i] = tables[i].getColumns(); /*
* Fill in the column headers for the current table. */
headers = new String[columns[i].size()]; for (int j = 0; j < columns[i].size(); j++) { headers[j] = ((CollectorTable.Column) columns[i].elementAt(j)).getName(); } stats[i].getDataVector().addElement(headers); } /*
* For each table, fill in the data records. */
record = new Object[columns[0].size()];
String os_name = System.getProperty("os.name"); /*
* Verify if Risk Manager is installed and get home directory */
record[0] = "TRM";
record[1] = isTRMInstalled ( os_name ); /*
* Verify if Risk Manager Agent is running */
record[2] = isTRMRunning ( os_name ); /*
* add first record to result set for SCM server */
stats[0].getDataVector().addElement(record); /*
* Hashing the policies */
ArrayList ruleset; File file;
//get rulesets defined in RMMonitorList
ruleset = getValues(new File(rmhome + EvMonWin), RMMonitorList); // extract the ruleset file names
for(int i = 0; i < ruleset.size(); i++) {
// get EventDefinitions, for example A1EventDefinitions, or A2EventDefinitions
eventDefinitions = getValues(new File(rmhome + EvMonWin), (String)ruleset.get(i) + "EventDefinitions");
//Building the hash of the files.
for(int j = 0; j < eventDefinitions.size(); j++) { try{
file = new File((String)eventDefinitions.get(j)); he = hashEntry(file);
} catch(Exception e){ he = "file not found"; }
record = new Object[columns[0].size()]; record[0] = "MD5"; record[1] = (String)eventDefinitions.get(j); record[2] = he; stats[0].getDataVector().addElement(record); } } return stats; }
The complete source code of the collector can be downloaded from the following site:
Appendix B.
Introducing the Security
Vulnerability Index
This appendix introduces a new IBM offering: The IBM Global Services
Security
Vulnerability Index
is a service that gets updated by IBM Global Services on a daily basis and causes the Security Compliance Manager policies to also get updated accordingly.This service answers the question that our customers have asked about the ability to be notified of new vulnerabilities and how to check their systems for them.
The package consists of a new install feature, available free of charge, for Security Compliance Manager; however, the IBM Global Services Security Vulnerability Index is a subscription service and as such is billable.
So what is the IBM Global Services Vulnerability Index?
IBM Security Intelligence Services created the IBM Global Business Security Index, which is a monthly report that assesses, measures, and analyzes network security threats and the broader business security landscape. The index is based on data culled from IBM's monitoring of large and small customer networks in multiple locations worldwide, as well as input from our security professionals working on consulting engagements.
It is a tool to aid in
tactical
incident response andstrategic
security planning. It serves as a barometer of the daily, weekly and monthly threat landscape, and is collected by IBM's 2700 worldwide information security professionals and half a million monitoring devices from many Fortune 500 companies and government entities in 34 countries around the world.
On average, IBM’s monitoring service detects 100 million suspected or actual attacks against customers each month.
The IBM Security Intelligence Services Team collects a broad range of IBM's security data, analyzes it for non-obvious trends, identifies emerging threats, and releases the analysis on a monthly basis via the IBM Security Threats and Attack Trends (STAT) report available to customers via a secure Web portal.
It distills the onslaught of security information to a manageable level and reduces hype to help enterprises gain better insight and advance warning on potential threats to the network and the broader enterprise so they can better prepare.
How does it work?
Security Compliance Manager customers get continually updated intelligence on patches and the latest security vulnerabilities.
Via a snapshot mechanism, systems are flagged that are missing key security patches and vulnerabilities based on latest advisory information from IBM Global Services.
IBM Global Services continually feeds and identifies critical security patches and vulnerability information to Security Compliance Manager for select OS platforms.
It is used to identify systems that are missing critical security patches and have vulnerabilities.
You can purchase this service directly through IBM Global Services at the following site:
http://www.ibm.com/services/us/index.wss/so/bcrs/a1008776
This Web site also contains sample reports.
The IBM Tivoli Security Compliance Manager Security Index Enablement Pack can be downloaded from the IBM Tivoli Security Compliance Manager 5.1 Utilities Web site at:
http://www.ibm.com/support/docview.wss?rs=2004&context=SSVHZU&dc=D400&uid=s wg24007082&loc=en_US&cs=utf-8&lang=en
The Security Compliance Manager new feature can be downloaded from:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliSecurityCompl ianceManager.html
Appendix C.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material
The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246450
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the redbook form number, SG246450.
Using the Web material
The additional Web material that accompanies this redbook includes the following files:
File name Description
SG246450.zip Zipped Risk Manager collector Java code, as described in Appendix A, “Developing a custom collector” on
page 173, and the corresponding Risk Manager policy file ABBC Risk Manager Policy.pol.
How to use the Web material
Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
Glossary
Basel II. A round of deliberations by central bankers from around the world, under the auspices of the Basel Committee on Banking Supervision (BCBS) in Basel, Switzerland, aimed at producing uniformity in the way banks and banking regulators approach risk management across national borders. The Basel II
(http://www.bis.org/publ/bcbs107.htm)
deliberations began in January 2001, driven largely by concern about the arbitrage issues that develop when regulatory capital requirements diverge from accurate economic capital calculations.
Basel II recommends
three pillars
: risk appraisal and control, supervision of the assets, andmonitoring of the financial market, to bring stability to the financial system.
CERT. Computer Emergency Response Team. The CERT/CC is a major reporting center for Internet security problems. Staff members provide technical advice and coordinate responses to security compromises, identify trends in intruder activity, work with other security experts to identify solutions to security problems, and disseminate information to the broad community. The CERT/CC also analyzes product vulnerabilities, publishes technical documents, and presents training courses.
The CERT/CC is located at the Software Engineering Institute (SEI), a federally funded research and development center (FFRDC) operated by Carnegie Mellon University (CMU).
For more detailed information about the CERT/CC, see Meet the CERT/CC at
http://www.cert.org/meet_cert/meetcertcc.html.
Collector. A software module that runs on a client system and gathers data. This data is subsequently sent to a server.
Common Criteria. The Common Criteria is the result of the integration of information technology and computer security criteria. In 1983, the US issued the Trusted Computer Security Evaluation Criteria (TCSEC), which became a standard in 1985. Criteria developments in Canada and European ITSEC countries followed the original US TCSEC work. The US Federal Criteria development was an early attempt to combine these other criteria with the TCSEC, and eventually led to the current pooling of resources towards production of the Common Criteria.
The Common Criteria is composed of three parts: the Introduction and General Model (Part 1), the Security Functional Requirements (Part 2), and the Security Assurance Requirements (Part 3). While Part 3 specifies the actions that must be performed to gained assurance, it does not specify how those actions are to be conducted; to address this issue, the Common Evaluation Methodology (CEM) was created for the lower levels of assurance.
More information can be found at
http://niap.nist.gov/cc-scheme/index.html.
Compliance query. An SQL query that extracts specific data from the server database and returns a list of clients that are in violation of specific security requirements.
Delta table. A database table used for saving changed data from subsequent runs of a collector.
Disinherit. To remove actions from a role that were originally copied from a template.
JAAS. The Java Authentication and Authorization Service (JAAS) is a set of APIs that enable services to authenticate and enforce access controls upon users. It implements a Java technology version of the standard Pluggable Authentication Module (PAM) framework, and supports user-based authorization. More information can be found at
http://java.sun.com/products/jaas/.
Policy. A set of one or more compliance queries used to demonstrate the level of adherence to specific security requirements.
Policy bundle. A file containing the information associated with a policy, such as the compliance queries, the collectors, and the associated
schedules. A policy bundle permits the policy to be saved and subsequently applied to other servers.
Proxy relay. A special pull client that acts as a relay between the server and one or more clients. A proxy relay is used to reach a limited number of clients that are located behind a firewall, or that are in an IP-address range that is not directly
addressable by the server.
Pull client. A client that permits communication with the server to be initiated by only the server.
Push client. A client that permits communication with the server to be initiated by either the client or the server.
Snapshot. The result of running all of the compliance queries in a policy against a set of clients. A snapshot shows the number of violations and indicates what clients are not adhering to the security requirements being tested by the compliance queries.