On July 30, 2002, President George W. Bush signed into law the Public Company Accounting Reform and Investor Act, more commonly know as Sarbanes-Oxley or SOX. The intention of this legislation was to reign in the corporate financial scandals that had marked the start of this decade, and to prevent future problems. Set into motion by the accounting fraud and insider trading at Enron, a Texas-based energy company whose collapse sent shock waves throughout the financial world, Sarbanes-Oxley placed significant—if not vague—requirements on businesses with serious legal consequences for failure to comply.
Half a world away, in 2006, similar events played out in Japan as Internet service provider Livedoor found itself at the center of a securities fraud scandal that led to the company’s delisting from the Tokyo Stock Exchange and imprisonment of the company’s founder and executives. In the aftermath of the Livedoor scandal, Japan passed the Financial Instruments and Exchange Law, informally known as J-SOX.
JSOX seeks to achieve the same essential goal as the American regulations, and is an example of the increasing number of such laws popping up around the globe. As the world continues to become smaller and companies conduct business on a global scale, the expansion of regulatory legislation abroad
places even greater demands on IT. Considering the widespread use of System i worldwide, taking into account legal requirements in places outside the U.S. is quickly becoming a reality for those in charge of protecting corporate data, assets, and customer information.
In this paper we will look at virus prevention and how it related to the now all too familiar Sarbanes-Oxley law, as well as the emerging Japanese flavor of the same, known perhaps affectionately as J-SOX in its home country. Just as foreign companies listed on the U.S. stock exchange must abide by SOX, non-Japanese companies listed on the Tokyo stock exchange must adhere to J-SOX.
The New Age of Viruses
When the first virus was created by Fred Cohen in 1983, the seeds of today’s scourge were planted. Cohen’s motives were more scientific than malicious, as he created the code to test a theory he had about programs that could self-replicate and spread.
But with each passing year, viruses and malicious code increas - ingly become the tools of organized crime. Today the goal is no longer to cause headaches for the average user. Instead, modern viruses target corporate information, customer data, and other sensitive materials that can be exploited for profit. Regardless of the platform on which you run your operations, if you’ve got valuable information, you’re a target.
New types of threats are emerging all the time, and “blended threats”—multiple types of malicious code packaged togeth - er—are challenging the ability of IT administrators and soft - ware to keep up.
This puts virus protection at the center of any comprehen - sive security policy. In order for today’s companies to protect their assets, comply with regulatory legislation, and maintain consumer confidence, countermeasures must be deployed on a broad scale, across the entire data infrastructure. And that brings us to SOX and J-SOX.
How to Approach Sarbanes-Oxley
SOX is notoriously vague. The 66-page document provides few specific instructions and has left corporate executives and IT staff largely on their own to figure out how best to comply.
One of the most widespread practices has become the use of COBIT Objectives to guide IT compliance efforts. COBIT is short for “Control Objectives for Information and Related Technology,” a set of guidelines established in 1992 as a set of best practices to help IT manages and auditors maximize the benefits of technology. Although COBIT predates SOX by a decade, the framework has proven invaluable to those strug - gling with SOX compliance.
An update to COBIT took place in December 2005 with the release of the fourth edition. Currently COBIT includes 34 high-level objectives that address 318 control objectives. CO - BIT is divided into sections or “domains”: Plan and Organize (PO); Acquire and Implement (AI); Deliver and Support (DS); and Monitor and Evaluate (ME). Security-focused items can be found in all domains, and very specific virus-related items can be found in the Deliver and Support domain.
The Requirement for Virus Protection
Although SOX may be vague, COBIT guidelines are very specific about combating the threat of malicious code. The Deliver and Support domain addresses such issues as the execution of applications and the health of the environment in which applications operate and data are exchanged. Viruses and malicious code can have a significant impact on the well being of the IT environment.
COBIT Objective DS5.19 covers “Malicious Software Prevention, Detection, and Correction.” Paraphrased, DS5.19 states that, regarding malicious software, such as computer viruses or Trojan horses, management should establish a framework of adequate preventative, detective, and corrective control measures, and occurrence response and reporting. Business and IT management should ensure that procedures are established across the organization to protect information systems and technology from computer viruses. Procedures should incorporate virus protection, detection, occurrence response, and reporting.
Another objective, DS9.5, specifies that clear policies restricting the user of personal and unlicensed software should be developed and enforced. The organization should use virus detection and remedy software. Business and IT management should periodically check the organization’s personal computers for unauthorized software. Compliance with the requirements of software and hardware license agreements should be review on a periodic basis.
COBIT is not the only source for guidance in SOX compliance. The National Institute of Standards and Technologies (NIST)—an American organization—has published several guidance documents that focus specifically on computer security and malware prevention.
NIST document 800-61 “Computer Security Incident Handling Guide,” for example, states “antivirus software is a necessity to combat the threat of malicious code and limit damage. The software should be running on all hosts throughout the organization.” (page 5–4, 5.2.2).
The Impact on System i
Now, you may be wondering what all of this has to do with System i. After all, System i is famous for its security and immunity to viruses. Well, any system is only as secure as its configuration, and immunity is a more complex issue than is generally believed.
Speaking only of traditional network security, an alarming number of System i servers operate with their default settings unchanged and aren’t really secure. Any attacker with a rudimentary knowledge of System i (and they will have this knowledge) will know IBM’s default passwords. This is the reality of security: it is what you make it.
The same holds true for virus prevention—except that with viruses you must take extra steps to close the gaps because, unlike basic security, anti-virus software is not built into i5/OS.
If you are like many System i users, you probably still believe that System i can’t “get” viruses. This simply is not true. Viruses can and do spread to System i, and System i can and will spread these viruses to other computers on your network.
Many users still do not see this as a risk because they focus on the traditional view of a virus executing on a specific operating system. Because the vast majority of viruses exploit flaws in Microsoft Windows, they erroneously believe that only a Windows-based PC can be harmed.
However, a virus does not need to target a specific operating system in order to wreak havoc on your operations. If a Windows-based PC is infected and has a connection to System i, the virus can perform any action for which the infected PC has authority. This means that files on System i can be deleted, settings and objects can be modified, and the server can even be shut down. Your level of protection lies not in some inherent immunity but rather in the security you have in place.
The Impact on Business
Long gone are the days of simple .EXE infectors sent as e-mail attachments. This old-fashioned approach has given way to stealthier and more sophisticated attacks aimed at infecting large numbers of systems or penetrating and compromising critical servers.
As of July 2007 there were more than 290,000 threats floating around, and Anti-virus firm McAfee estimates that approximately 150 to 200 viruses, Trojans, and other threats emerge every day. McAfee predicted at the end of 2006 that the total number of threats would exceed 300,000 before the end of 2007. Considering that nearly half the year remains and the count has already passed 290,000, McAfee’s prediction, which may have seemed alarmist initially, looks to have been quite conservative.
New threats are coming through sources that are considered legitimate business tools, including ZIP archives, IM services, and even Skype. It is becoming increasingly difficult to balance security with the needs of the company. Many necessary tools are being discarded in the name of safety, so there is a price to pay for protection against perceived threats. It is important to keep in mind that the modern “virus threat” really encompasses a broader menace of traditional viruses, spyware, malware, blended threats, phishing, worms, backdoors, and other threats. Attacks may come from remote locations or from inside the firewall, at the heart of your organization. Technology controls are an absolute necessity to mitigate the threat, and are therefore a key component of compliance with SOX and J-SOX.
All Roads Lead to System i
These days everything is connected. Whether by LAN, WiFi, VPN, flash drive, or other protocol or device, everything and everyone can connect to the systems and assets they need. It’s great for convenience and getting work done quickly, but along with the convenience comes diminished security.
Any of these connection types, along with many others, can give viruses and malicious code access to System i. This expansion in means of transmission represents the greatest obstacle to controlling the threat. The modern System i hosts a variety of operating systems—including i5/OS, Linux, and AIX—and sits connected to a vast field of Windows-based systems. Each path represents a potential infection and outbreak of malicious code.
Although e-mail remains an important method of distribution, LAN, WiFi, and VPN connections, as well as employee laptops, iPods, PDAs, IM chat clients, file sharing programs, and drive-by downloads by malicious Web pages can all serve as A virus does not need to target a specific OS in order to wreak havoc on your operations. Protection doesn’t lie in some inherent immunity. 4 7 sources of infection. Unfortunately, many of these are impor - tant business tools and controlling them is difficult.
Another source of infection and data loss is your own staff. If you allow employees to bring their own computers into the office, there is also the risk that a virus on a user’s personal sys - tem could leak confidential information to the public without the user’s knowledge. Such an incident made news in Japan and was particularly troubling considering the current state of global affairs and terorrism.
In 2005, the home computer of a Mitsubishi Electric Plant En - gineering employee was infected with a virus that copied se - cret information about Japanese nuclear power plants to the popular file sharing service Winny. The leaked data included photos of the inside of nuclear plants and other critical infor - mation concerning staffing and inspections.
The ways in which networks and data can be compromised are extensive, but the impact is simple: lost time, lost money, and lost consumer trust. And in the case of SOX and J-SOX compliance the impact could also be huge financial penalties levied by the government and prison time for executives lev - ied by the courts.
Mitigating the Threat
As was shown in COBIT Objectives DS.5.19 and DS9.5, taking steps to prevent virus and malicious code outbreaks is a must. Even if it were not required, the potential impact to a company’s finances and stature with customers is enough to make the necessity of protection obvious. Imagine the dam - age to an organization’s image if associated with the leaking of sensitive information as in the case of the Japanese nuclear facility or the loss of millions of customer credit card numbers as in the case of TJ Maxx.
So just how does one go about eradicating viruses and mali - cious code? Like roaches, for every virus you see, there are likely hundreds—if not thousands—more lurking under the surface. You can kill the roaches that come out into the open, and spraying poison along the baseboards will help hold off new ones; but it won’t get rid of the nest. The same holds true for viruses and malicious code. In other words, scanning your client PCs alone will not protect you. You must take control from the center of the network—System i.
At IBM’s request, Bytware and McAfee began developing a native anti-virus solution for System i that would be integrated with i5/OS beginning with V5R3. This solution was released in June 2003 as StandGuard Anti-Virus. By coupling this solution with the new Virus Scanning Enablement that IBM built into i5/OS V5R3, users could for the first time easily and safely protect System i from viruses and malicious code.
StandGuard Anti-Virus addresses a number of needs unique to System i by providing an engine designed to run natively under i5/OS, protection for all guest operating system partitions, inte - gration with i5/OS, the ability to handle recursive links, and the ability to detect changes to IBM’s digitally-signed OS objects. StandGuard Anti-Virus is powered by the McAfee scanning engine, which uses the same definition library as all McAfee solutions—including VirusScan on Windows. As of July 2007, McAfee DAT files could detect more than 290,000 threats.
The ability to run natively on System i is the key to real protec - tion. By eliminating the need for open, full-authority paths to System i from scanning PCs, the risk of infection from outside the system during scanning is removed. The native application also allows for real-time, on-access scanning of files stored on System i, providing protection throughout the day without disrupting operations.
Beyond the basic concept of detecting and cleaning viruses, there is a more specific reason to implement anti-virus soft - ware as part of your efforts to comply with SOX, J-SOX, and other regulatory legislation. It’s the changes you don’t see.
Because the various flavors of SOX-like legislation popping up around the world were created with the aim of cleaning up corporate misbehavior, monitoring and reporting is a key component that runs throughout. The need to identify and document alterations that could create security exposures is critical, and some of these alterations simply can’t be detect - ed any other way.
Changes to i5/OS itself, which could be made by malicious code, patched programs, or even insiders such as consultants, are a perfect example. Such changes can create security exposures and instabilities in system operations. Scanning client PCs alone will not protect you. You must take control from the network’s heart. The ability to run native AV on System i is the key.
StandGuard Anti-Virus provides a tool known as Object In - tegrity Scanning (OIS) that scans the objects at the heart of i5/ OS. These objects are digitally-signed by IBM and changes to them can have a serious impact on the health of your system and IT environment—which is, we recall, the point of COBIT’s Deliver and Support domain and the objectives pertaining to viruses and malicious code.
Maintaining an audit trail and a record of any changes on the system is a necessary part of proving compliance with SOX and J-SOX. OIS provides the ability to check for and report on these aspects of your operations that are very specific to System i and i5/OS.
The Sooner the Better
The American SOX law had tight deadlines for compliance, but they don’t compare to the short notice being given in Ja - pan. For those required to comply with J-SOX as well, there’s little time to achieve a lot. Despite the fact that details are only now being finalized, the deadline for compliance with J-SOX is April 1, 2008. To make matters worse, reports are that com - panies must demonstrate three months of compliance prior to that date. This means that essentially you must be in compli - ance by January 1, 2008.
And even without regulatory deadlines, the modern virus threat is a ticking bomb just waiting to go off; and you never know where it will strike next. The only way to ensure that your corporate data and assets, and the integrity of sensitive cus - tomer information, remain out of harm’s way is to take steps to mitigate the threat presented by malicious code on all systems and servers. Platform does not matter to the malicious code of today. An unprotected server, regardless of platform, is a chink in your armor than can be exploited.
Many aspects of compliance are complex, but meeting the anti-virus requirements is simple. The solution is available and easy to implement. It’s been tested in the field as part of SOX compliance efforts in the United States for more than four years and can be a critical, inexpensive, and effective compo - nent of your efforts to meet regulatory requirements.