IT Security Forum
IT Security and Compliance. We take it to the max.
The BCPii hypervisor control function is a pretty new z/OS feature. It allows you to control the mainframe on its HMC console level, meaning that you access the hypervisor directly from z/OS. Therefore, BCPii authority stands for owning “real power.” Without doubt BCPii enables great functionality in the field of smart system automation, such as dynamic capacity management, etc., and lets you avoid necessary personal visits to the cold and windy server rooms. On the other hand, professionally acting hackers also receive new levels of power by now potentially controlling your entire mainframe platform. How is this possible, since BCPii is a protected feature? The answer is easily given. Professional attacks always also imply the deactivation of your security system during use, meaning that of RACF, CA-TSS or CA-ACF2. This means that any perfectly configured BCPii protection simply becomes void for the hacker during such a professional attack. In case BCPii is enabled, hackers are much more easily able to perform cross-LPAR attacks, and to reach and touch your production systems. For example, in case the actual hack happens on a test LPAR sharing the same physical machine with production. One detail has to be mentioned here, namely that such attacks will not focus on direct data access but on the LPARs’ overall operational availability or behavior.
In case of a critical mainframe infrastructure the golden rule claims “no BCPIii without strong intrusion detection (IDS),” otherwise you – irresponsibly – accept a significant operational risk. The requirement “strong” means that it’s an intrusion detection system that is not just evaluating SMF and syslog records or similar regular sources, but is also able to detect dynamic manipulations, the bypassing of the security system, and other fancy tricks in real-time. We apologize for this clear and frank statement and opinion, and also for pointing to SF-Sherlock within this context. But its unique IDS component exactly focuses on even these most dangerous and tricky attack methods; this in order to secure your mainframe platform against professional attacks. If you are curious about what such an attack looks like, the best way is to invite us to carry out a penetration test.
Provide complete and comprehensive audit and log data in real-time to your security monitoring solution in use (ArcSight, Tivoli, SF-RiskSaver, etc.)
Successful cross-platform monitoring requires comprehensive and complete data in real-time. The connection kits available for SF-Sherlock and SF-NoEvasion allow an easy integration of the z platform in your overall security monitoring, regardless from the solution in use. Both are based on the “plug & play” principles, and provide the ultimate and required strength to your detection and correlation procedures in order to successfully combat any attack or fraud.
Using FTP for file transfers between clients and the z/OS server offers a wide range of capabilities. Each FTP user who requests services from the z/OS FTP server requires prior authentification with a valid z/OS user ID and password – without enabling “anonymous FTP”. This user also needs a (UNIX) UID from the user’s OMVS segment if it is not provided by a default UID definition. After authentification, a wide spectrum of operations is then possible depending on the FTP server’s configuration and the authority granted to the user in the security system. You should know that z/OS FTP is not limited to simple file transfers. For example, you may also submit jobs and receive spool output within your FTP session by changing the “file type” accordingly. If enabled, you may even send SQL statements to your DB2 subsystem. Of course, the permission defined by your security system still represents the baseline for all available resources, functions, and operations.
It becomes immediately obvious that any weaknesses inside the security system’s definitions may immediately expose your z/OS system to high risk. Carefully consider a given user ID. It will make a difference, if it is used in a batch job, started in a task-related context, or used inside an FTP session coming from the outside. In a scenario based on the misuse of a highly privileged user ID via FTP-based remote access from “far away”, you probably do not want to grant all authority to this user ID, but restrict possible operations to “task-based” performance only. For example, you will not allow a JCL submission to all users, but only when it is specifically required. How can you solve this problem without disabling FTP completely?
SHER-BLOCK, the blocking component of SF-Sherlock, lets you establish smart command verification for FTP. Aside from supporting FTP, RACF, and console commands, it also monitors critical interfaces that allow hidden operations. Its highly flexible concept, which also supports whitelists referring to RACF definitions, lets you precisely control and log critical activities by setting up corresponding rules. Here are some sample blocking definitions provided in the standard plug & play rule set: a) prevent JCL submission in FTP, b) prevent disablement of RACF command logging via the “SETROPT NOSAUDIT” command, c) prevent the “Z EOD” system command from being issued in any TSO SDSF session, and much more. If your company’s IT requires SOX compliance, then SHER-BLOCK will let you finally setup fully-automated controls around FTP.
You ask yourself: What do IT security & compliance have in common with the subprime lending dilemma? Triple A ratings from your solution providor may rely on a false trust in vendor size, brand name and bona fides. Read the news. The top subprime lenders are world-class banks. It does not make a difference whether you compare the integrity between rating agencies and rated financial institutions or between operating system vendors and their security & compliance solutions. If there is no integrity in the separation of powers, and conflicts are ignored in the name of easy access, then any guarantee against a subprime-like debacle becomes worthless. In this respect, however, security & compliance software completely differs completely from other software categories. The separation of powers, or simply, “competition”, is essential in achieving true AAAA+ levels in IT security & compliance! This is what we call the “Max Approach”.
This statement may seem somewhat abstract, but integrity, trust, quality, IT security & compliance, auditing, etc., all imply a sound ethical foundation. All related production is based on abstract ideals and goals. So, where else should motivation come from than Socrates & Co.?
The Payment Card Industry (PCI) Data Security Standard und ISO-27001/2 represent important security standards for financial service institutions. This article keeps you updated on current topics surrounding PCI and ISO 27001/2 compliance of the mainframe platform. Latest best practice experience has shown potential mainframe-related difficulties in important areas not only your auditor should know about:
|10.5||Secure audit trails so they cannot be altered,|
|2.2.3||Configure system security parameters to prevent misuse,|
|6.2||Establish a process to identify newly discovered security vulnerabilities …,|
|6.5.2||Broken access control, etc.|
|A10.10.3||Protection of log information,|
|A11.5.4||Use of system utilities,|
|A12.6.1||Control of technical vulnerabilities, etc.|
Furthermore, ISO sections A13.2.1, A13.1.1, and PCI sections 11.4, 11.5, 12.9, all stipulate the mandatory implementation of real-time monitoring for compliance.
The mainframe’s failure to fully comply with these requirements also stems from its missing ability to both detect and combat dynamic manipulation and malicious code processing regarding
authentication (user ID switching, authorization theft, etc.),
logging (manipulation or suppression of audit information, which means breaking the audit trail),
resource access (manipulation of resource access procedures).
Best practice experience has proven that full compliance becomes impossible by solely relying on the capabilities of the standard operating and security systems, even when implementing some real-time SMF-based auditing (for technical details see below).
We are partners with the world’s largest companies and institutions in successfully achieving and maintaining extreme secure environments. Our unique real-time security monitoring technology, which we call SF-Sherlock, goes far beyond standard monitoring. It will “plug into” your mainframe environment and successfully detect and combat any attack. You become compliant easily.
Is single-vendor sourcing of all security software really the best strategy? Read why this is only ostensibly so
At first glance, it might sound odd, but key functions of security software performance target the “invisible workings of your IT” that require transparency. It is the job of security monitoring to locate hidden security gaps and weaknesses, even those unknown to their developers, as well as non-compliant operations and fraud in an apparently flawless and safe environment.
This key feature makes security software unique. Procurement-related decisions likewise require slightly different evaluations and strategies. Aside from quality-related concerns and technological depth, the vendor’s independence is paramount. Only independent vendors of security monitoring solutions are free to publish, discuss, target and ruthlessly remove all weaknesses of your IT platform, solution or product. Independence is both the requirement and the guarantee for not ignoring or bypassing any company-internal weaknesses or taboos internal to the company, such as not to tampering with the image or sales projections of any product.
Is this single argument really strong enough to supersede company policies like minimizing the number of software vendors? Isn’t it critical for independent security software vendors to remain compatible and up-to-date concerning the monitored platform, products, or solutions? Doesn’t this aspect demand a single-source strategy? Well, this argument is often used, and it sounds plausible that only the developer of the operating system, solution or platform is aware of the latest features and improvements for future implementation. But the reality of the professional software market proves otherwise, especially regarding operating systems – not just open source. Today, professional software vendors receive all the required information “just in time” to be capable of adapting their software products. General and specific legal regulations and agreements guarantee the expeditious release of the required current software to the customer.
We can conclude that missing competition in the area of security monitoring automatically results in a lower level of security on the user’s site. Like all monopolies, your reward will be low performance. The stimulating factor of competition is the precondition and guarantor for your success and sovereign control in IT.
Will the auditor really accept my company’s technical solutions to achieve compliance? Or does the auditor come with concrete requirements such as product and vendor lists?
IT Baseline Protection for the Z Platform (Mainframe)« of the German Federal Office for Information Security (BSI) Set your company’s rating, such as for Basel II, on a secure foundation by going far beyond the requirements of the U.S. Department of Defense (DOD)
The “OS/390 and z/OS Security Technical Implementation Guide” of the US Department of Defense (DOD) provides only a basic approach for a secure implementation of z/OS. The German Federal Office for Information Security (BSI) is far more comprehensive.
Since 2004 the German Federal Office for Information Security (BSI) has been focusing on necessary security measures for the mainframe platform in its central security guide, the “IT Baseline Protection Manual” (www.bsi.bund.de). Section 6.10 focuses on the z platform and describes the risks and related basic protection measures for a secure z platform.
The German security guide describes today’s demand for using real-time monitoring technology for securing the systems against manipulation and the exploitation of possible z/OS-specific weaknesses. According to the IT Baseline Protection Manual, “…such detection measures are practically indispensable if the greater damage is to be expected. …” and the necessary “… use of a real-time security monitor for z/OS systems in determining security infringements faster.…” (both passages are taken from the “Basic IT Security Protection Manual, 2004 Edition, Section “M6.67 Use of detection measures for security incidents”). Real-time monitoring of only a single isolated security aspect, such as SMF records, is still insufficient. Monitoring the entire z/OS with all its components and complex relations and details is crucial.
The strict requirements of the BSI demonstrate the high relevance of mainframe security and emphasize the need for additional protection against today’s risks. The z platform has thus become a “conventional” server platform with “conventional” risks, i.e. “less SNA, more TCP/IP” or “not only MVS, but also UNIX System Services”. This means that companies with an increasing demand for security and quality require further technical measures for their z platform not supplied by the standard security system. At this point, it is important to note that a real-time security monitor is not a standard component of the z/OS. BSI’s conclusion? Standard z security is not sufficient for companies with an increased need for security.
What types of companies have an increased need for z security and quality?
When you take into account the high investment and operational costs of mainframes, you realize that all mainframe users are affected, especially those in the financial and insurance sectors, commercial IT providers, health insurance companies, among others.
Which motivation, or rather, what pressure is there to act now to achieve such increased security measures? Enormous pressure, according to the new legislation and regulations, such as Basel II, IT Baseline Protection Manual (German Federal Office for Information Security), KonTraG, SOX, U.S. DOD Regulations, etc. Such pressure could even result in considerable “trouble” for companies and their management when the damage has already been incurred and any exonerating evidence is missing.
Nevertheless, even before something happens, insufficient security can prove expensive in the long run. This point has been reinforced by legislation, such as Basel II and SOX, among others. The key factor is the so-called “rating”, which acts as a consolidated measure for legislative compliance, professionalism, and stability for safeguarding companies and their business processes. As a result, IT becomes burdened with this added responsibility. On the one hand, business processes are based and dependent on IT. Given this relationship, IT becomes a source of risk. On the other hand, IT lets you minimize risks, e.g. through concepts that control, monitor, identify and eventually combat risks. IT security is therefore of central significance for rating agencies and governing bodies. One thing is clear: these organizations possess highly specialized knowledge of all platforms, including those belonging to the “good old” mainframes.
The assessment by rating agencies of companies is done by a so-called “rating”. A company’s rating can, for example, negatively impact the cost of credit. After all, a few per thousand of interest can add up to a large sum of money. The idea is that higher risk must correspond to an “extra charge”. In short, a company with a bad rating will have higher credit costs much like an insurance premium. Conclusion: Insufficient security costs more money in the long run.
Don’t you, as someone working in or for the financial IT service sector, feel affected by this? You ask yourself: how does a bank become rated? Why do only banks “rate” their customers, and not vice versa? While this may be true, remember that all companies are subject to a rating. After all, even banks are also debtors. Besides the legislation, there are several governing authorities that continuously rate banks. Some are state-controlled, such as the German Federal Financial Supervisory Authority (BaFin).
What can and should be done to protect the z platform against malicious code and exploits? It is necessary to set up pro-active and comprehensive measures to eliminate and control risks.
Isolated technical measures alone, even when operating in real-time, are not enough. Commercially offered systems for recording SMF records in real-time, such as RACF SMF records, are a good example. You have a good objective, but this is simply not enough, since the whole system must be comprehensively and systematically protected against manipulation. A simple scenario supports this argument. If a professional attacker manipulates his or her authorization and breaks the audit trail, he can easily disable any SMF records. This is a mere “bit” of effort. The old law of physics also applies here: “Nothing comes from nothing” – no cause, no effect. Missing SMF records will not bring up detection and notification even in a real-time live-evaluation and cannot be used for an automatic reaction.
In this context, some hard questions regarding “malicious code” arise:
• What exactly are all the APF-authorized modules, which come from so many different software vendors, doing?
• To what extent can these programs be misused for other purposes? Can they be misused for such actions as suppressing and deactivating SMF protocolling by dynamic (memory) manipulation?
• Which undocumented, security-critical functions can specialists uncover in the program code of modules when using corresponding analysis tools?
• To what extent can the development departments create and use authorized modules?
The questions are endless. Nevertheless, one thing is certain: no one z/OS user can clearly answer them, even when the software is installed properly with SMP/E. Conclusion: All processes running in the system must be monitored in real-time for “improper behavior”.
Another important legal aspect concerns the requirements and conditions for proper operations, transparency and completeness, especially in the areas of bookkeeping and financial data processing. In short, you require an invulnerable audit trail for the purpose of audit data completeness and authenticity. This is your primary concern. In addition, new concerns involving risk precautions and prevention require that this complete and correct audit data is not merely archived, but analysed immediately and properly as well.
What solution do we suggest?
As developers of SF-Sherlock, whose comprehensive z/OS real-time monitoring technology is unique to the market, we can gladly propose the successful way of implementing z/OS security and quality automation. The SF-Sherlock solution not only entirely complies with basic legal requirements and recommendations, but also accomplishes much more to keep your company on the right track. Apart from security concerns, SF-Sherlock also supports the goal of constant availability, for example, with its IPL simulation, parmlib syntax and semantic checking and many more quality checks. We supply connection kits that further enable SF-Sherlock’s integration into comprehensive cross-platform solutions, such as those of Symantec, Tivoli, CA, etc.
By using SF-Sherlock, you can eliminate the technical risks as well as successfully achieve the required automatic control and monitoring required by legislation. Both improve your rating significantly and thus lower costs. In this way, SF-Sherlock gives an increased added value to your company.
The concepts of automatic and complete monitoring, as well as the plug&play implementation, let you reach this goal with minimal time and cost. Our effective installation and implementation concept will convince you.
Leading banks, insurance companies, industrial companies and IT service providers have been successfully securing their mainframe platform for years with SF-Sherlock. Our company, our technology, our services, and our “value added”-based pricing have the references to prove that improving security and reducing costs are no longer contradictory.
The topic of internal attacks is an extremely sensitive one. Both determining the risks from bad colleagues and employees and communicating this to them is a rather undesirable task and also legally difficult. No wonder the term “intrusion detection” has developed such a biased connotation in the last years. Intrusion detection systems (IDS) have been “reduced” to focusing network-based and external attacks.
However, practice has shown that the main danger really does lie in internal attacks. Insider knowledge considerably reduces the effort and hurdles required for a successful “attack”. Without a doubt, it is essentially more difficult for an outsider to penetrate the system, then find and reach the data sources. That compared to an insider, who can easily transport the data to the outside – from the known location.
The relatively new term “extrusion detection” expands on the idea of this reduced “IDS” definition. The purpose of an “extrusion detection system” (EDS) is to keep track of procedures and events within the company in order to combat internal attacks. A close relationship between auditing and revision is obvious.
Automatically executed technical reactions are especially associated with “prevention”. No doubt actual prevention takes place in the awareness of the staff. And in general, there is high respect for technical prevention and an automatic reaction to incidents. This goes along with the “false positive” problem and erroneous decisions that could endanger production processes and their availability.
From the very beginning, SF-Sherlock’s “logical trap” concept was linked to the detection aspects of both intrusion and extrusion, combined with an optional reaction. Altogether, system attacks are detected as well as the “escape” of important data to the “outside”, e.g. by way of FTP.
The SF-Sherlock technology for security and quality automation is
• both an intrusion and extrusion detection and prevention system,
• host-based, but network activities are also monitored, such as Firewall and TCP/IP,
• z/OS-specific, while also monitoring the operating system, applications and subsystems (e.g. DB2, LDAP, etc.),
• able to evaluate SMF or any log data,
• equipped with necessary pre-defined attack patterns (“logical traps”) and
• can be supplemented with installation-defined attack patterns and installation-specific monitoring characteristics.
This comprehensive approach to our security technology guarantees a maximum return on investment and maximum security.
Your mainframe installation uses z/Linux, z/VSE and/or z/VM in addition to z/OS, and you need to integrate these platforms in a cross-platform real-time monitoring? SF-Sherlock provides the following powerful options:
• z/Linux without z/VM+RACF-based authentication: The syslog of all z/Linux systems will be automatically forwarded to SF-Sherlock for passing its intensive security scan.
• z/Linux combined with authentication via z/VM+RACF: Aside from the automated syslog scan, all SMF records resulting from z/VM’s RACF will also become part of the SF-Sherlock-based security monitoring. For example, to immediately detect any suspicious behavior in the mass of z/Linux logins.
• z/VSE: The Basic Security Manager (BSM) is a standard component of z/VSE’s kernel, and provides basic security capabilities. With version 4.1 this includes the creation of RACF-compatible SMF records. Simply forward these records to SF-Sherlock for being analyzed, and your z/VSE is covered by its strong monitoring.
• z/VM: RACF on z/VM creates regular RACF SMF records that will be forwarded to SF-Sherlock for setting up a correspondingly high surveillance level on z/VM.
Employing the SF technologies provides the easiest way to fully secure the “entire z”.
Buffer Overflow and Format String Attacks on the Mainframe Technical principles and possible countermeasures by “encapsulating an application”
One generally associates the terms “buffer overflow (attack)” and “format string attack” with a kind of primary risk. Both represent the threat of an outside attack on applications with an (IP) interface. Applications could be vulnerable and exploitable, in that “sophisticated” input is cleverly passed on to them, such as strings that are too long, strings with embedded control characters, program code, or the like. Both types of attack intend to overwrite memory areas through tricky specifications and passing parameters. Usually, the attacker’s goal is to overwrite the memory with executable machine code to reach high authorization levels within the targeted application. A possible scenario can be the misuse of the web server and its high authorization through attacks on a web application.
A technical basis for attacks is the application of a so-called “stack” as both a temporary and transfer memory through the runtime environment of an application. This program stack is not to be mistaken for the TCP/IP stack. In general, the stack is used to store parameters and save the so-called return address in the context of a subprogram call. Before program X calls subroutine Y and branches into it, the arguments required by routine Y will be “pushed” onto the stack, from which routine Y then “pops” them. Correspondingly, by calling Y from X, the return address – from Y back to X – will also be pushed onto the stack. The nesting of routine calls then lets the stack grow and shrink during runtime – it “swings”. There is one thing to remember. While the Intel stack grows in the direction of a smaller address –from top to bottom–, the z stack, as explained below, grows in the direction of bigger addresses.
The stack can already be implemented either on a processor level through its design and corresponding instructions, or through software emulation. For instance, the stack concept of Intel’s processors is an elementary part of the design and is supported on the level of machine code through corresponding instructions (PUSH, POP, etc.). A specific register, known as the stack register, identifies the stack and allows its addressing.
On the Z platform, the stack is virtually emulated in a “merely” software technical manner. The memory of the z architecture is a large linear memory with 32 or 64 bit addressing, whereas the Intel memory is segmented. A C language program, for instance, running on the z platform has a corresponding memory area within this 32 or 64 bit address space, where it places the emulated stack during runtime. A stack pointer, which identifies the current top address of the stack, moves up and down during program execution and is completely analogous to the special stack register of the Intel processor. From the perspective of the actual effect and function for a running program, there is no real difference between both processor worlds. Altogether the “z stack” is emulated through the runtime environment of the compiler. This reveals the potential for additional protection, in which the runtime environment carries out extensive plausibility checks. It is very important that the program code residing in the z stack can be executed since there is only “the one” memory. This aspect is a recent development and presents a marked difference from the Intel world. To protect programs against stack-based attacks, the new Intel processors can prevent the execution of program code residing in the stack (memory). An entire category of attacks was rendered impossible by this new measure, namely those transferring the executable program code as a command argument.
Let us turn now to the principles of both attacks. Both are based on the fact that programs expect parameter data of fixed length or that parameter data do not exceed a specific number of bytes. These programs do not check whether the incoming arguments are too long or too numerous, or whether they contain special format characters (e.g. “%n”) that affect a reference beyond the intended memory area by a special interpretation through the runtime system (e.g. through the print function). Here comes the point of attack, where an intentional passing of “unsuitable” or “special” arguments can cause a distinct saving of information. This can lead either to an unnoticed stack (memory) overflow of the running program, which can cause the application to crash, or an attempt to take over program control. In the latter case, the goal is to overwrite the memory with program code (machine instructions, such as an SVC instruction) and/or manipulate the return address in order to continue in a particular program code.
Important conclusion: In general, the primary deficiencies of buffer overflow and format string attacks come from the application or routine itself, which does not consistently check received input for plausibility and conformity. The culprit is less likely to be the processor and/or the operating system. Strong attention should be paid to code inspections, which can even be partially automated, particularly during software development. In commercial or open source software, the user’s influence is minimized and the software must be applied “as is”.
Which possibilities for further protection of applications, such as web applications, exist on the z/OS platform in addition to the standard measures for securing applications? Aside from the real-time monitoring of applications with SF-Sherlock, there is the possibility of “encapsulating” the application with SF-Sherlock’s “logical trap” concept. Since there is only partial or no influence on an existing application, the application’s external behavior and character must be categorized and shielded. By describing or recording the “normal behavior” of the application, irregularities can be revealed quickly and securely; for instance, when a web server supplying services to customers suddenly accesses the payroll information and no longer only the product information. This is a real indication of a possible attack. The encapsulation of applications is a successfully applied measure of the SF-Sherlock practice. One important point to consider is that the purpose of each attack is to reach higher authorizations for performing subsequent accesses and operations. In the context of this abuse, regardless of the methods of attack, the buffer overflow and format string attack methods are only two possibilities. There are many others.
SF-Sherlock’s real-time monitoring and logical trap concept lets you achieve a higher and more solid protection of your critical applications.
Join our newsletter list
Stay updated with our news and events.
Worldwide toll-free phone number
++800 - 37 333 853
or simply dial:
++800 - DRFEDTKE
++41 41 710 4005
(++ represents the prefix for international calls; in most countries it is 00; in the U.S. it corresponds to 011)