Thinking Outside the Box When Monitoring DB2 Security - Essay Example

Thinking “Outside the Box” when Monitoring DB2 Security on z/OS Summary The President of the United s recently announced plans to develop a comprehensive universal health care system. This program will require the highly sensitive records to be stored on massive computers. Essentially, they will be a “DNA footprint” for millions of Americans. Security for these records should not be thought of as “after the fact” and will require vigilant and pro-active monitoring of security regardless of the operating system on which they reside. The records are required to be protected according to the Federal Information Security Management Act of 2008 (FISMA, also referred to as US Senate Bill S.3474) with adequate security. FISMA mandates that “the underlying framework that information systems and assets rely on in processing, transmitting, receiving or storing information electronically”. It goes on to say “Meaning security commensurate with the risk and magnitude of harm from loss, misuse, or unauthorized access to or modification of information”. Web connections to data residing on the mainframe DB2 platform through z/OS Web Services, CICS and TSO have added functionality to legacy processing and brought transaction processing to new levels. It has also introduced a new perception of vulnerability. Mainframe security administrators sometimes view it as opening up the mainframe to “intruders.” The "bad guys" are finding new inventive ways to obtain corporate and personal information and to disrupt a companys business as was done by someone holding the State of Virginia’s medical records hostage and demanding a $10 million dollar payment. Most of the Financial, Healthcare and Pharmaceutical industries keep their vital records on DB2 and other databases located on the IBM z/OS mainframe platform. Government interests in these corporations will lead to the next wave of exchange of information between them and it is expected that private industries sharing database information with the Government will soon have to comply with the FISMA guidelines. But regardless of the industry and whether or not they fall into the FISMA regulations, every company is at risk of losing information. Security is not always the highest priority in a corporation until it is named in the lead story on the evening news or Wall Street Journal. Summary: This paper puts its focus on ways to monitor DB2 database security by thinking outside the box. It will provide an elaborate description of various ways through which it will be possible to develop an efficient security framework that will be able to monitor security setting and protect confidential data from bad guys in economical way. This paper will also talk about the tools that are available for developing such security framework. In the present paper, main focus is placed mainly on those security tools that can be used outside the mainframe security framework. The stress on “thinking outside the box” has been placed in this paper mainly because most of the traditional tools which are required to be set inside the mainframe security setting have failed to deliver desired outcomes. Before moving on to the detail analysis of the ways to monitor DB2 database security by thinking outside the box, the paper has devoted some of its space in discussing the problems with the traditional security measures to highlight the needs of developing ways to monitor DB2 database security by thinking outside the box. The paper will first set a background for the betterment of the understanding of the issue. Then it will move on analyzing how in earlier days security settings used to violate the act of separation of duties and how leading mainframe security installations have developed the ways of monitoring security in compliance to the act. Then the paper will put its focus on costs of security breaches to highlight the needs of efficient security setting. The paper will not only focus on hard impacts of security breaches, but also on the soft impacts as in many occasion, the soft impacts may take very severe forms. After providing an elaborate discussion on costs of security breaches, the paper will focus on the areas of mainframe security framework which are vulnerable to security threats. Thereafter, it will discuss how DB2 SMF Records can be used within mainframe security network as event tracking measures. The paper will also provide a discussion on the way of implementing DB2 SMF Audit Trace Records. It will provide an elaborate discussion on the steps to be taken when setting up log collection and security analysis programs on the mainframe within your organization by using economical sources readily available. However, along with mentioning the efficient of this system, it will also put stress on the need of new framework as very often traditional measures are found to be incapable of countering security threats of modern days. Finally it will discuss the methods that can be adopted to counter the modern day’s security threats and how these tools work. Background DB2 on mainframes commonly use security products from IBM and Computer Associates for reporting. They are the first levels of defense. These products either allow or deny a user access to a resource. Unlike UXIX and other operating systems security, it is a simple yes or no decision. If security is denied, a violation event will be recorded on the security log files and in most cases a message will be issued to the primary console. The event may go unnoticed until the System Administrator runs a violation report in response to an incident. DB2 also keeps a separate log file of events throughout its course of normal processing. These log files are a mainframe operating system function called System Manage Function or “SMF” records. The DB2 SMF records contain information related to many different types of events occurring within system but the level of granunuality depends on configurations of the DB2 audit trace at the individual table level. The SMF records provide data useful for investigating security events and if used with in combination with other resources, help investigate possible attacks and breached for incident response, auditing and compliance purposes. The DB2 SMF records are in binary format and not readable by a plain text editor making online viewing impossible. Separation of duties DB2 security should not be like herding cats. In most mainframe shops, the security administrators are still the person responsible for monitoring security. In addition to defining and maintaining users and passwords, they assume the role of chasing down batch reports to answer periodic auditing and compliance questions. However this is a clear case of violation of the act of separation of duties. According to these act, the person who is monitoring security should not be the same guy who is setting up security. To conform to the act of separation of duties, security setting has be built in such a way that security administrator of a company does not require to monitor security also. The task of security monitoring should be placed in the hands of some specialized group. One of the most fundamental aspects of the Sarbanes-Oxley Act of 2002 was the definition of Separation of Duties. As a result, leading mainframe installations are appointing an independent mainframe department to take on the role of pro-actively monitoring the security and SMF event information. Others have placed mainframe security experts within the departmental and budgetary structure of an external security monitoring group that monitors Network, UNIX, Windows and other operating systems. These departmental restructured groups (a) allow mainframe events to be monitored from “outside the box” in a centralized repository, (b) allow non-mainframer technicians to be come exposed to what is happening “inside the box” and (c) introduce new technologies and experience to mainframe computer security experts wishing to expand their careers and is a win/win proposition for all. The cost of a security breach U.S. Department of Justice cases determined that the average loss per incident was $1.5 million. A 2005 CSI/FBI survey have estimated the cost to be $167,000. A Ponemon Institute survey of 2006 figured the average cost to be $4.8 million per breach. The Forrester group, a leading IT advisory firm, did some of the best analysis on breaking down the hard cost of a data breach. As the table below shows, Forrester broke down the cost per record. Government Agencies, large companies hosting medical and financial databases and most of the financial institutions would obviously fall into the Company C profile. In addition to the soft costs identified earlier, a significant data breach at a major bank would be quite substantial. The bigger they are, the greater the losses. Just for the fun of it, let’s say a hacker compromised data from 1,000,000 credit cards. I am sure you can do the math, but according to the Forrester’s charts, estimates would be around $305,000,000. One large bank has more than 150 million credit card accounts worldwide. One could argue that we could get some economies of scale due to a loss of so many records, but that is an argument no one wants to make! Soft financial impacts include damaged corporate reputation, loss of potential customers, loss of existing customers, and increased regulatory scrutiny. Soft data breaches have a real financial impact, but are difficult to quantify. No one wants to be on a regulator’s radarscope, and the surest way to get there is to have a front page news item about customer data being compromised. CEO embarrassment pain is pretty high when a company is making news by losing customer information. Hard financial impact of data loss is easier to identify and quantify. It is the direct, measurable loss to the company. These losses would include cost to correct stolen funds, costs to monitor credit, investigation costs, remediation costs, and legal cost associated with suits brought as a result of data breaches. They don NOT take into consideration the personal losses to CIO stemming from the latest trend of law suites for failing to protect the stockholders best interest. In one example, past security exposures on theft of data has lead to three class action law suits against the Secretary of Veterans Affairs. The data theft was related to Data Governance, a result of data being transferred to a laptop which was stolen from a private residence of a VA Contractor. The security breach affected 26.5 million records with a VA estimate of between $100 million to $500 million to prevent and cover possible losses from data theft. Mainframe DB2 Choke Points Changes to DB2 on the mainframe now allow for the product to make use of the system security that is implemented with the operating system. Prior to these changes, DB2 performed internal resource checking on its own and was dependant on the mainframe DB2 System Administrator configuration to do so. When attacking DB2 data one of the most sought after targets is the ability to achieve escalation of privileges and the second is obtaining the password of the DB2 system administrator. The objective is to attack it without setting off the bells and whistles of the operating system security product currently in place. One successful example of this happened while performing a network vulnerably assessment of a large government agency. The network was compromised (with authority of the agency) and a workstation was hacked. Application files related to a process running on the workstation were examined. A mainframe DB2 logon ID and password was found, in the clear, unencrypted and in plain text format. The ID and password was then used to log into the DB2 application on the mainframe with SYSADMIN privileges. JACKPOT, GAME OVER! Mainframe DB2 Application Code Choke Points There are two major concerns regarding DB2 application code being developed and running on mainframe processors. 1. Random checks of application code being developed using mainframe Web Services seems to be in line with the security guidelines and standards of today but “you don’t know, what you don’t know”. Application reviews by the mainframe ISSO are almost non-existent. 2. Many of the DB2 legacy applications (legacy is not a bad word; it simple means that something has been around for a long time and works well) were written in an era prior to 9/11 mentality and it is not cost-justified to change them to fit into the security conscious world we are living in today. The inability to adapt these applications to today’s security awareness posture poses a big problem for many large companies and government agencies around the world today. Using DB2 SMF Records as event tracking There are over 100 different types of SMF records reserved by the mainframe operating system for its own usage. Numbers above a certain level can be used for vendor products and mainframe application programs. SMF record number eighty (type80) are used by two of the mainframe security commonly used on the mainframe. The third security product uses a SMF number assigned to it at the installation time of the product (commonly #231). The SMF records are written to files before, during and after the mainframe operating system performs an event. The mainframe systems programmer defines the size of the primary and secondary SMF files. When the primary file fills, the secondary becomes the primary and the original SMF file is achieved. Thousands upon thousands of SMF records are written daily and in many shops the SMF logs switch once a day, twice a day and even hourly, depending on the customer’s transaction process volume. The SMF records are impossible to monitor from a workstation in real-time, however, they are the historical foundation for security, auditing and compliance batch reporting. Another problem regarding these SMF records is that these historical foundations for security, auditing and compliance batch reporting are not at all cost effective. In fact, cost of reviewing logs is very high. Creation of logs with an aim to provide security is one thing, but actually reviewing them is highly expensive. Very often companies seem to be reluctant in spending huge sum on reviewing these logs. But if a company doe not review a log, then what is the purpose of putting efforts in collecting them? How to Implement DB2 SMF Audit Trace Records SMF log analysis is a very important when it comes to monitoring DB2 security, auditing and compliance and one of the best ways to do it is by using the DB2 audit trace facility. The DB2 audit trace facility must be turned on for each table you wish to monitor. This is done by using the AUDIT clause at the time of the CREATE of the table. Additionally, Audit Trace classes must be activated in order to collect the data in the DB2 SMF records. Each class is associated with the type of DB2 events you wish to monitor. The DB2 Audit Trace Classes are as follows: Class One Access attempts that DB2 denies because of inadequate authorization. Class Two Explicit GRANT and REVOKE statements and their results. This class does not trace implicit grants and revokes. Class Three CREATE, ALTER, and DROP statements that affect audited tables, and the results of these statements. Class Four Changes to audited tables Class Five All read accesses to tables that are identified with the AUDIT ALL clause. Class Six The bind of static and dynamic SQL statements of the following types: INSERT, UPDATE, DELETE, CREATE VIEW, and LOCK TABLE statements for audited tables. SELECT statements on tables that are identified with the AUDIT ALL clause. Class Seven Assignment or change of an authorization ID because of the following reasons: • Changes through an exit routine (default or user-written) • Changes through a SET CURRENT SQLID statement • An outbound or inbound authorization ID translation • An ID that is being mapped to a RACF ID from a Kerberos security ticket Class Eight The start of a utility job, and the end of each phase of the utility Class Nine Various types of records that are written to IFCID 0146 by the IFI WRITE function Class Ten (DB2 V9.1) CREATE and ALTER TRUSTED CONTEXT statements, establish trusted connection information and switch user information Here is a partial list of DB2 security related events commonly monitored: Access rights Privilege changes, explicit privilege changes as well as administrative changes SYSCTRL and SYSADM activity Changes to authorization Dropping of tables Inserting/changing records Accessing data from unauthorized id’s GRANT/REVOKE statements The actual SQL Other activity within the DB2 audit trail information that is important for computer forensics and incident response is the actual SQL that was being performed at the time of the incident. It is a fingerprint to the table, row and column that the user was going after at the time. Unfortunately, it is buried behind a very complex index of binary bit settings and not something that is readily available for the weak at heart technician to find. The DB2 Audit Trace facility has a track record of adding on additional CPU overhead, however, there has been a drastic reduction on that overhead and DB2 has gotten progressively better with each new release announced. The latest IBM statistics on the overhead of the DB2 Trace facility indicate that it will introduce less than 10% additional CPU overhead if all of the classes are turned on (per transaction). The mainframe operating system platform is the premier transaction-processing machine and has always boasted industry-leading security technology. During many years of service, often under the most demanding conditions imaginable, it has survived. It has proven itself time and again, and was awarded the U.S. Government’s highest certification for commercial security. However, in a changing world with an increase in lost trade secrets, theft of personal identity, and wrongdoings by employees, associates and contractors, the strongest security mechanisms are essential. The mainframe security concept of “allow” or “not allow” security simply may not be enough. It needs additional safeguards that help protect users and data with features that were not possible until recently. The answer is; technology working in concert with existing mainframe security and network security products to bring mainframe security to the next level. In a world where the Reagan-era motto “Trust but Verify” is essential and the mainframe security professional needs the tools to accomplish this feat. Thinking outside the Box There are a variety of security applications that may already be deployed within your own organizations. These products sit outside the mainframe, on the network and collect events logging from firewalls, UNIX, Widows and other operating systems but very seldom does a mainframe security administrator tap into the resources. One way to leverage to leverage money already spend and to get the “employee of the month” award is to think outside the box and to integrate mainframe events into one of the product that your company has already invested in. DB2 Log Management Log Management products from commercial vendors including LogLogic, Network Intelligence, Novell, Computer Associates, IBM, NetIQ and others. Log Management products collect raw log data. Mainframe console are mostly in text format and can be routed to these applications with little efforts. Challenges arise when you attempt to transport mainframe console logs, security log files and raw SMF data to these vendor products devices (a) in a timely manner, (b) unfiltered and (c) in binary format. SEIM PRODUCTS SUPPORTING DB2 SIEM products collect security events from many sources other than the mainframe. The events are expected to be condensed by agent software executing on a remote device. DB2 SMF records can be in excess of 32k in length and should be filtered or condensed for any SEIM product. The process of reading the security logs and condensing them into warnings and alerts is expected to occur by a remote agent process residing on the mainframe. Doing so, saves network traffic overhead and expenses related to storing excess data in the central repository on a mid-range disk device. Commercial vendors for SIEM products include Intellitactics, IBM, NetForensics, ArcSight and Novell (my apologies to any vendor I might have left out) often have remote batch or real-time process to collect DB2 information from the mainframe. DB2 Mainframe Homegrown solutions Developing a homegrown agent application to read and monitor the DB2 SMF records, non-DB2 SMF records, console messages, application messages and vendor products is an overwhelming and monumental task. The DB2 SMF records are considered to be one of the most complex record formats and can only be interrupted by a veteran Systems Programmer. Not including them in a system wide application collection would lead to in ineffective system. Another interesting point is that the Sarbanes-Oxley Act of 2002 definition of Separation of Duties specifies that security personnel administrating or monitoring should not be writing security code. In essence, homegrown code, including log monitors and exits by a security person could be in violation of the very thing it was intended to eliminate. With that being said; should you decide to proceed, important issues that have to be worked out before you even begin include: Asynchronous timing Unacceptable consumption of CPU and Network resources Conversion of data from binary to text format Delivering the information on a timely manner so that it can be immediately acted upon funding (or lack of) The complexity and costs related to the development of a homegrown application is often cast aside by management when compared to the costs of purchasing proven software from ISV’s. Mainframe Data Compliance Mainframe Data Compliance often takes on different definitions for different core businesses. Compliance guidelines for the credit card industry strongly differ from those for the financial industry and likewise between a power company and an insurance company. Data compliance standards cannot be fully covered within the scope of this document. “Financial institutions should take reasonable steps to ensure that sufficient data is collected from secure logs files to identify and respond to incidents and to monitor and enforce compliance” The Federal Financial Institutions Examination Council Summary: Today in all organizations, be it public or private, most of works are done through computers. Computers are used as the storage of documents important to the organizations as well as to their clients. Here comes the issue of providing security to the important data stored in the computers. The issue of security becomes more critical when data are transferred through web connection. According to the law enacted for ensuring security of confidential data, commonly known as the Federal Information Security Management Act (FISMA) of 2008, every company is essentially required to protect its customer’s data and any other types of business related records. Most of the companies and other public institutions generally keep their vital resources on mainframe platform using DB2 or other databases. This white paper mainly discusses some important issues relating to security breach, how mainframe platform works towards monitoring security of records, what are the pitfalls in traditional system of using DB2 SMF records for event tracking, and how the mainframe platform can be modernized for providing improved security monitoring of important and confidential records. The major points that have come out during the whole set of discussion in this paper are as follows: The most basic level of defense against security threat to the data stored in computers of any firm or any other important organization is the security products used by DB2 on mainframes. Throughout the entire processing of security monitoring, DB2 generally uses separate log files for different events. These Log files are commonly known as SMF (System Manage Function) records. These SMF records are extremely vital for the purpose of investigation of security events. According to the well-known security related act (Sarbanes-Oxley, 2002) relating to the protection of data on computers, a well-devised security framework should exercise separation of duties in the sense that security administer should be a different person than the one who is monitoring security. But the thing of concern is that in most of the traditional mainframe installations this rule of ‘separation of duties’ has been violated. However, to comply with this law, today most of the leading mainframe installations are building security system in such a way that his law is appropriately met by restructuring the mainframe department in order to provide a separate group of experts for the purpose of monitoring only. But, in spite of undertaking security measures through the implementation of mainframe security frameworks which were also in compliance with the act of separation of duties, security breach could not be avoided. A number of security breaches have occurred, some with soft financial impacts and some with hard financial impacts. One of the basic problems of using many of DB2 applications to counter security threat in present day is that most of these applications have been developed prior to the incidence of 9/11. As a result of this, these systems are not accustomed to the new kind of security threats. These systems are inappropriate in today’s world. Not only that these traditional mainframe security systems are also incapable of being adapted to the present day’s security awareness posture. The result is the many companies as well as government agencies that need to store large amount of confidential data are exposed to large amount of security threats. Although most of the DB2 applications which have been invented prior to 9/11 are not as useful as they were earlier, DB2 audit trace facility is still considered to be a very efficient application to counter security threat to recorded data. The white paper provides a brief description of how DB2 SMF Audit Trace Records can be implemented and how it works. The paper also highlights how the DB2 Audit Trace Facility on mainframe platform has survived even in the phase of extreme turmoil. However, under the continuously changing world scenarios, it can not be forgot that, the efficiency of such DB2 based application can only be maintained only if it is graduated to a modern version that is capable of countering new types of threats. The traditional concept of ‘allow’ or ‘not allow’ in most of the mainframe security applications is not enough in today’s world. Today, the mainframe security device is required to fulfill the motto of “trust and verify”. Under such changing world scenarios, time has come to think about highly modern technological device that would be efficient to protect important data in computers and to reduce security breaches by a large extent. To develop such devices, it is now necessary to think outside the box. It would no longer be efficient to develop a system that would work inside the mainframe security setting as it has been found that all the security setting that have been developed inside the mainframe security setting are not efficient enough to trace all the incidences where security has been violated. In most of the traditional DB2 applications security products use to sit inside the mainframe platform and quite frequently fail to detect possible security attacks as well as the events tat have already occurred by violating security rules. Hence, it is now necessary to develop some products that would be able to work outside the mainframe security framework. These new devices should be able to collect necessary information regarding events logging from firewalls, UNIX, windows and other operating system. These devices can also be cost effective than the devices used earlier. Among the various kinds of newly devised security products that can work sitting outside the mainframe platform are DB2 Log management tools, SEIM products supporting DB2 and some other DB2 mainframe homegrown solutions. All these products have their own pros and cons. For example, in case of DB2 log management tools which are mainly produced by commercial vendors like LogLogic, Network Intelligence, Novell, Computer Associates, IBM, NetIQ, etc. raw log data can be routed to these applications with little effort. But problems arise at the time of transporting mainframe console logs, security log files, raw data etc. SEIM products are a little more efficient compared to log management tools, while home grown solutions have their own advantages and disadvantages. But the important thing is that all these devices are efficient than the earlier models in countering new types of security threats. Today one of the most vital problems is therefore, given wide range of products, is to choose the appropriate security product for protecting important data stored in computers. So, how will you choose a correct device among o many alternatives? While choosing a particular security product that is able to work sitting outside the mainframe platform, certain factors have to be checked. Here are some criterions that you can consider while buying a security product for your company. The Product should necessarily be scalable. The product should be managed easily. The product must allow for lateral growth. The product should be efficient enough in collecting events in real time. The product should be easily configurable. And, The product must use small footprint of mainframe processing. The protect data, the companies are require to be more proactive. The companies should not wait for the incident to happen that would make a newspaper headline. Rather, the companies should use such devices that would not let such security breaches to happen. It is absolutely true that cost of protecting data is high and in today’s economic scenarios most of the companies are in great pressure to cut costs. But it is also not right to leave confidential data unprotected. Although, cost of protecting data is quite high, the companies can now take a sigh of relief as some products have been devised which are cost effective. As a result, Companies can now have access to cost efficient security devices which also have wide range of overages. These products have been built in order to meet the current needs of the companies in the area of securing confidential records of their own businesses as well as of their clients. These products have all the qualities that are required to counter today’s security threats. These products can help the enterprises in meeting G/R/C logging requirements. They can also work efficiently with RACF, ACF2 and Top Secret. They can also make use of SMF and console messages in appropriate way. Apart from these, these modern devices are capable of tracking DB2 audited events, tracking several types of insider threats, delivering mainframe alerts in real time, integrating with security monitors of any existing enterprise with sufficient ease. These products are efficient enough to be implemented in application Programming Interface in order to produce customized events. Adding to all these, they do not require any additional components on mainframe platform or any unwieldy management framework to operate these. These newly developed devices can provide a single solution to any large organization which needs complete coverage. So, don’t let data breaches derail your boss’s career, or more importantly, your career. The proactive companies will be out in front of government requirements and have a solid track record of correctly administering security framework and managing risk. Doing so puts those companies in a better competitive position to participate in the evolving medical records marketplace. Reference material Reference material on log management best practices can be found: National Institute of Standards and Technology (NIST) in Special Publication 800-92: Computer Security Log Management, and Special Publication 800-53 Federal Information Security Management Act (44 U.S.C. 3544) TECH center Addressing Sarbanes-Oxley IT Security Issues BY NEIL BEBBINGTON, J.H. COHN LLP NEW JERSEY CPA • MAY•JUNE 2005 The Paperwork Reduction Act requires agencies to manage information collections from the public in the manner prescribed in OMB’s guidance in 5 CFR section 1320. For additional information see: http://www.access.gpo.gov/nara/cfr/waisidx_99/5cfr1320_99.html. Focus on risk and compliance will follow: Meeting the challenges of PCI DSS Source: PricewaterhouseCoopers http://www.cio.com/documents/whitepapers/FocusOnRiskWP2.pdf Process Development and Tool Selection for Security Event Log Analysis Gartner, Inc. Publication Date: 25 July 2005/ID Number: G00129322 Reference: , Gartner Group Document ID Number: G00129322 Read More