A couple of weeks ago, I attended a fascinating presentation by a local Minneapolis firm that specializes in forensic audits. These are the guys hired by companies that suspect criminal behavior within their ranks. While not technically a law enforcement entity, their expertise centers on finding hidden evidence. The presenting experts were an ex-law enforcement officer who worked on St. Paul’s “Crimes Against Children” task force, and a trained interrogator who painted a picture of how it’s possible to dissect a computer to find evidence of wrongdoing.

We heard the tale of a hospital manager that was ordering expensive supplies on behalf of his employer, and then turning around and supplementing his disposable income by selling them on Craigslist. He even got confident enough in his fraudulent scheme to start drop-shipping some of the orders directly to his “customers.” He was finally caught after his computer showed evidence of ghost orders totaling approximately $250,000, and incriminating e-mails from one of his various online buyers. Then, there was the female employee who claimed sexual harassment from her supervisor, but was subsequently found out in an e-mail message to be buying cocaine from that same supervisor! These examples were quite staggering cases that took some time to solve, but both were carried to prosecution on the weight of the computer forensics.

I was particularly fascinated by the topic as I love true-crime shows on television. I love to hear how people think they’ve committed the elusive “perfect crime.” Unfortunately (usually for the perpetrator), it’s often the littlest details that get them caught. For example, the case of a woman’s Internet search on “how to kill someone without getting caught,” which became evidence after her husband mysteriously turned up dead.

Fortunately, PowerTech has never had to consult in a murder case. However, our software does enable security teams to perform detailed forensic analysis of events that take place on an IBM Power Systems server. IBM i has an extensive (and often under-utilized) facility to log activities performed by system and application users. If logging events for all users garners too much log data, you can narrow it down to specific users, or even specific objects accessed by those specific users.

As I mentioned, many customers still don’t make use of this capability, but the biggest challenge for those that do is usually analyzing and interpreting the data. No one in their right mind wants to manually pour over log entries that can number in the millions per day. Even if a person wanted to, realistically it wouldn’t be humanly possible. PowerTech is well-versed in this dilemma and has several powerful solutions to help with the burdensome aspect of the task, including escalating the log entries to an enterprise monitoring tool in syslog format. We also help many customers via the advanced analysis capabilities of Compliance Monitor. And if you want to get down to the database record and field level, we have DataThread. These solutions ensure that your security staff is equipped to react to issues in a timely manner and, by doing so, reduce risk. Who wouldn’t want their security team to have the proper equipment necessary to enforce and react to questionable activities?

I often have to meet with executives to explain how spending money on security adds value to an organization. While it might not be as immediately quantifiable as a new machine in the factory, there are plenty of ways to demonstrate a return on security investment (ROSI). In fact, if some of the companies in my earlier examples had had better controls and tools in place, these unfortunate, embarrassing, and definitely costly situations might have been averted.

If you would like to learn more about how to analyze your IBM i event log, give the experts at PowerTech a call.

Cheers,

- rt

For the past couple of weeks, the PowerTech team has been busy analyzing the data for the 2011 “State of IBM i Security” study update. This white paper continues to be one of our most popular downloads, and is a frequently requested topic for local user group presentations. This update will mark the eighth consecutive year of its publication.

The security data used for this study is collected via an “opt in” feature in our free Compliance Assessment tool. We harvest the anonymous information from the authorized systems—no corporate application data is retained, nor is anything that would compromise the integrity of the customer’s security infrastructure identifiable. This year, we analyzed data collected from 182 systems, as well as 61 systems collected by a non-PowerTech source.

While the results do not provide annual trends (we don’t knowingly reassess the same systems twice), we continue to see significant room for improvement in the implementation of security controls in IBM i environments. Despite the many customers that approach PowerTech for help with stringent compliance requirements—Sarbanes-Oxley, HIPAA, and PCI are the most common—the majority of companies reviewed still are not leveraging the resources that have been available for many years. This supports the general opinion that there’s a broad lack of knowledge in the IBM i community on what capabilities are already owned, and how to effectively implement them. The data also indicates that many systems remain unprotected from network access, and have no forensic auditing facility.

One debate we sometimes have is whether the data we collect is truly a random sample and representative of the true state of security. While we readily acknowledge that these systems have been “chosen” by the very nature of their inclusion in our assessment process, we do contend that the servers we assess are a random sampling of system sizes and application types, and that they come from enterprises in every industry and numerous geographic regions. One could argue that the customers that come to us influence the study by having enough awareness of security vulnerabilities to request an assessment, or that these are enterprises that have not already secured their systems. Both arguments have credibility, but based on the overwhelming evidence of more than 1000 systems being unsecured, my professional opinion is that we are stating the vulnerabilities fairly.

We’ll be revealing the 2011 study to the public during a Webinar on March 30, so join us to hear about the latest findings.

Cheers,

- rt

LinkedIn is one of the most popular social media services used by professionals to network with each other. I’m a LinkedIn member and one of its features I really enjoy is the ability to participate in “group” discussions. I belong to a couple of groups, including Security Officers and AS400 Specialists.

Last week, someone posed an interesting question to the AS400 Specialists group that elicited some passionate exchanges. It started with a simple enough question regarding what mechanism should be used to log all activity on an IBM i server (AS/400), including the requirement that it could be reviewed daily, be unalterable, and that it log data and admin changes. Of course, several people (myself included) indicated that we would need to know more before we could really offer a detailed opinion. However, one person responded that a user only needed to use the operating system controls, and if any commercial vendor tried to sell him any of their wares, he was literally being ripped off and wasting his money (I paraphrased).

Now, here’s my response: although I am employed by the leading security software company, I have always been a proponent of deploying every control, including those that are “free” in the base operating system. This includes limiting the special authorities assigned to users, correctly establishing system values, securing libraries and objects, and, as discussed in this particular online exchange, using IBM i auditing functions for events, users, and objects. Why would I suggest this? Simple! I’m a firm believer that layered security is the best approach to risk reduction. This is because multiple layers of controls are inherently more secure than one single layer.

I also responded to the suggestion that (all) commercial security companies are only out to make a fast buck. I can’t speak for my competitors, but as the Director at PowerTech, I am totally focused on helping customers make good long-term decisions about their compliance strategy. This is demonstrated by the commitment my team shows performing our popular (and free!) security assessment service. Invariably, mitigation of some of the uncovered risks involves our software, but if PowerTech were simply selling solutions for the sake of it, we would have gone out of business a long time ago. You might be surprised to read that I do not think commercial solutions totally negate the need for the built-in controls. I strongly support the necessity of object-level security, but I also know for a fact that most customers don’t have this well implemented. Even when they do, access levels that are appropriate in one interface might be totally inappropriate for another. It’s also important to remember that the IBM i security model was designed long before anyone had insight into the requirements (for example, segregation of duties) of our current regulatory world.

While you may be able to write software that’s similar in function to a commercial vendor solution, why would you spend the immense amount of time and money reinventing the wheel? Most home-grown security “solutions” don’t even start to compare to the functionality provided by a company that dedicates thousands of dollars in R&D, testing, and support each year. And one certainly can’t substitute the expertise gained from providing specialized solutions for customers around the globe. Regardless of any intent to try to save money, most auditors don’t support the idea of “self-policing.”

PowerTech’s commercial solutions will add tremendous value to your compliance efforts. Enterprises that record thousands of events each day, as some of our customers do, can’t review their logs manually. At best, it would mean that critical events often get missed, and most likely it wouldn’t get done at all. The ability to feed events into a SIM console as they happen, or send them to a mobile device when a critical situation arises, is one obvious benefit of a professional solution. Monitoring database activity, as this particular member wished to do, can be done with journaling. But, it’s far more productive when a market-proven solution is making sense of the collected data, and alerting your security team in real-time when, and only when, there is a data anomaly.

The bottom line is that there is no single measurement that indicates “you are now totally secure.” It’s all about balancing and managing risk. Even with compliance, auditors have to follow the regulations and often have differing interpretations. In my humble opinion, the IBM Power Systems servers are some of the most securable servers on the planet. But it takes work, skilled effort, and money to get it perfectly tuned. It also takes a trusted partner, like PowerTech, that invests heavily in its solutions, dedicates numerous free resources to the IBM i security community, and with the integrity to acknowledge that even our software works better when it’s used in conjunction with IBM’s own controls.

Thanks to all our customers, distributors, and employees who know the value of PowerTech solutions, and for coming back to us year after year.

Cheers,

- rt

Now that the new year celebratory “dust” has settled, many things are emerging as key business opportunities for us.

The first area of opportunity comes from some exciting product initiatives now under way. Updates to several existing PowerTech products, as well as some brand new technology, are things I’ve been talking about recently and are enabling competitive replacements and new customer sales. I won’t go into more detail just yet, but the next eighteen months are an exciting part of a two-year product roadmap; a journey that has already witnessed the completion of Network Security 6 and Compliance Monitor 3.

Our overseas offices are poised to repeat a fantastic 2010. Numerous large international customers are moving forward with their compliance initiatives, and PowerTech has been helping them along the way. Presentations and Webinars, similar to the ongoing series presented here in the Unites States, are demonstrating our security expertise and brand investment to customers in European and Asia-Pacific countries.

Another big growth opportunity lies in our corporate pedigree. When I travel to user groups around the country, I introduce my company as PowerTech, the newest member of the Help/Systems family. I often joke that it’s one of the software industry’s worst-kept secrets. While many people do already know, I still find some who are pleasantly surprised by this “news.” For more than two decades, Help/Systems has enjoyed the reputation as the undisputed leader in automation software. As the first ISO 9001-certified software company in the U.S., Help/Systems set the bar for exemplary service and support. This renowned quality has led to deep market penetration that is now enabling a lot of good conversation about security in many enterprises—large and small—running IBM i.

We’ve also spent time this year to help our account managers become more aware of the different product silos. We want them to recognize when one of the other silos can assist with a business challenge. For example, we talk to customers about security and the volume of audit data they collect. That can lead to discussions about how they handle their corporate data, and how SEQUEL is a tool that can help them use that data. Or, perhaps the customer is looking for a solution to the problem of scheduling across their various platforms, an area where Robot/SCHEDULE Enterprise can help.

Having class-leading brands like Robot, SEQUEL, PowerTech, and Bytware under the same corporate umbrella means that we can service our customers better, and allow them to feel the benefits that come from working with a single vendor.

So, if your business needs include cross-platform scheduling, lights-out automation, systems management, data access and analysis, or, of course, security solutions, then Help/Systems is here to help!

Cheers,

- rt

Oh, how Mother Nature likes to keep one (and hopefully only one!) last trick up her sleeve! Following last week’s 50-degree “melt-fest,” we awoke on Monday to over a foot-and-a-half of fresh, blowing snow—a back-breaking reminder that in Minnesota “it ain’t over ‘til it’s over.” It wouldn’t be so bad except for the fact that all roads seem to converge at the end of my driveway—at least that’s what the snowplows seem to think.

Fortunately, things continue to stay heated at the office. We conducted a product planning session last week, and proceeded to build a roadmap for one of the strategic new ideas that we’re working on. Although only scheduled for an hour, we finally wrapped up after more than two because of the dozens of fantastic ideas that came up. I’m not typically the biggest fan of meetings (who really is?), but I love to come out of one feeling such energy about our products and our strategic direction.

One direction we are very excited about comes from the recent availability of the DataThread database module. If you haven’t seen this amazing solution in action, I want you to stop and ask yourself these five questions:

• Can you list (and prove!) every single way that your data is accessed?
• Can you provide an auditor with the full change history of a sensitive data element?
• Do you require electronic signatures for important data changes?
• Can you filter trusted applications from your audit reports?
• Do application owners get notified in real-time, perhaps via e-mail, the instant that their data is changed outside of a control boundary?

If, like many people, you can’t answer a resounding “Yes!” to all five questions, then you need to explore the extraordinary control DataThread brings to your database. No matter whether you’re under the scrutiny of a regulatory standard, such as the Payment Card Industry Data Security Standard (PCI DSS) that I introduced over the last few weeks, or you just want to ensure the integrity of critical data assets, DataThread can provide visibility into the actions of users—regardless of whether they use an approved application, or powerful (and hard to monitor) tools like SQL and DFU.

The power of DataThread comes from its ability to rapidly analyze database journals to find the events that are important to you. DataThread can take advantage of journal receivers that you’re already using, or configure new ones for you. You also can use triggers to see who is even looking at individual data records. Ask your PCI auditor if that feature would be helpful! If a breach does occur, you can identify which individual records were exposed rather than assuming it affected the entire file or database. That simple feature alone could justify the cost of DataThread.

Powerful workflow features in the product allow actions to be performed when certain criteria are met. For example, perhaps you want to receive an e-mail when a salary field changes by more than $1,000, or invoke a reordering program the instant the widget inventory falls 10% below the desired stocking level.

Of course, one of the most challenging parts of auditing in the real world is often the volume of audit data that you need to review. Some companies generate gigabytes of audit information every day! Having to pour over reams of paper reports is like looking for the proverbial needle in the haystack, and likely will lead to missed events and eventually less (or no) ongoing review. The ability to have a server monitor itself, and escalate only the important data events, is critical to facilitating a quick response and reducing risk.

So, if your compliance needs have you looking for a solution to the database dilemma, take a closer look at DataThread! You’ll be glad that you did.

Cheers,

- rt

This week, I am going to close out my series on PCI-DSS with the final three of PCI’s twelve requirements. Since the beginning of the year, I have witnessed a renewed interest in PCI as companies work diligently to plan compliance with the new regulation. Fortunately, we are continuing to expand our solution suite, and so are able to assist many of these contacts to reduce the effort that it takes to gain—and maintain—compliance.

Requirement 10. Track and monitor all access to network resources and cardholder data

One of the niceties of the IBM i operating system is that the security components are integrated. The ability to audit user activities is something that can be performed without much configuration, using the CHGSECAUD command. Unfortunately, I don’t have room in this blog to get into the nuances of audit configuration, but you need to make sure that you are using the controls that IBM provides. Contact PowerTech if you would like assistance, or refer to the IBM security reference manual for more information.

Performing forensic analysis on the collected audit entries can be challenging, as IBM does not provide any reporting or notification tools. Fortunately, PowerTech has created the “missing links” with our Compliance Monitor reporting engine, and Interact real-time monitor.

Use these tools to ensure that systems are appropriately configured, and configurations are not altered without approval. Operations to be reviewed for PCI include object creations and deletions – both of which are capabilities that can be audited within the base operating system. PowerTech also recommends auditing the activities of powerful users (users with special or private authorities, in conjunction with a command line).

When it comes to monitoring access to cardholder data, check into DataThread. Enhancing the proven capability of database journaling and triggers, DataThread provides real-time monitoring of database access down to the record and field level. Powerful workflow capabilities ensure that security officers and auditors are not overloaded with insignificant activities and critical data events are not missed.

Requirement 11 Regularly test security systems and processes

PCI requires that quarterly scans are performed to ensure that alerts are generated and that failures are mitigated. External scans should be performed by an Approved Scanning Vendor (ASV), approved by the PCI council. For servers on an internal network, such as the System i typically is, testing should include connecting via common data protocols such as FTP and ODBC.

PowerTech Network Security provides intrusion detection and prevention capabilities via operating system exit points, and should be implemented in conjunction with IBM i’s own IDS capabilities.

File integrity monitoring for critical files is a key component of this requirement, and that can be accomplished using object auditing controls in the OS, as well as database-level monitoring using DataThread.

Requirement 12 Maintain a policy that addresses information security for all personnel

It is still surprising to me in this day that many security-conscious organizations don’t maintain a security policy that pertains to their IBM Power Systems servers. Policies are important to define the intended standards, and also to provide a measure of how well your processes are meeting those standards. Even if the policy is not perfect, it provides a jumping-off point for performing a compliance review. If the policy is found to be deficient, then it is a policy discussion and not an IT discussion.

PCI compliance requires that you have a policy and that you prove that you are adhering to it. Requirement 12 involves a thorough review of your security policy standards, and determination if you are disseminating those requirements correctly. It also ensures that certain controls are specified, such as terminal disconnect intervals, and the existence of data leak prevention controls. PowerTech’s solutions help companies comply with these requirements, and prove that compliance.

I hope you have enjoyed this short series on the twelve requirements of PCI v2. For additional information on the PCI standards, visit www.pci.org, where you will find many valuable resources to aid with your PCI compliance initiative.

If you have any questions about PCI compliance on servers running IBM i, or the solutions that can help with its compliance, please drop me a line. Otherwise, join me next week when I’d like to further introduce our powerful new DataThread solution.

Cheers,

- rt

In my ongoing introduction of the requirements of the Payment Card Industry’s Data Security Standard (PCI-DSS), we have covered the first six of twelve requirements. Today, I’m going to touch on the next three requirements comprising of the goal to “Implement Strong Access Control Measures.”

Requirement 7. Restrict Access To Cardholder Data By Business Need-to-Know

Like the majority of PCI’s requirements, limiting data access to users with a proven business need may seem like an important but obvious qualification. Unfortunately, the IBM i often suffers from an abundance of overly-powerful user profiles, as well as open public access that makes private data easy to display and even change.

Often, the first step in mitigating this problem is to establish role-based access controls (RBAC), meaning that employees are categorized based on their access requirement. This may involve determining application usage, as well as the types of network interfaces they need to access.

IBM i contains powerful object-level authority controls, and these should be carefully applied to all important application programs and databases. While compensating controls, such as menu restrictions and command line access, can be used to control some forms of data access, it is imperative to understand that some interfaces, such as FTP and ODBC, are not restricted by menus, and may even permit limited-capable users to execute commands. Public access should be configured as deny-by-default, and authorized users be granted authority based on their role. This is easier to accomplish in IBM i than most people realize.

Network interfaces should also be policed by a quality exit program solution. This enables additional functionality not contained in the operating system, such as auditing of users’ requests. PowerTech Network Security even enables authorized transactions to run with temporary credentials to facilitate flexibility above and beyond normal object authorities.

Another consideration is emergency access. By restricting programmer or administrative access to data, security officers can help prevent those powerful users from simply circumventing business controls. However, a role should be defined to include a “firecall” function to enable access when the need arises. Solutions like Authority Broker can facilitate access when the situation warrants, and handles all of the user-based auditing and reporting requirements for regulatory compliance.

Requirement 8 Assign A Unique ID To Each Person With Computer Access

Users are authorized to IBM i functions via a user profile and password combination. To satisfy most compliance mandates including PCI, each user should be uniquely identifiable to the system. This ensures that there is accountability of any actions that are taken.

After connection, it is required that data only by manipulated though approved application interfaces, and not directly via tools like DFU or SQL. The exception to this is for database administrators. I recommend that administrators of any kind use PowerTech Authority Broker to be granted controlled access to functions, and PowerTech Data Thread be used to monitor and audit all database changes performed through non-application interfaces.

Session idle times should be set to 15 minutes or less, which is something commonly left open in most environments running IBM i.

Password rules include a minimum length of seven characters (best-practices typically only require six, so watch for that!) and should incorporate numeric and alphanumeric characters. Passwords should be changed every 90 days, not be the same as any of the previous four values, and accounts should be automatically disabled after six invalid sign-on attempts.

Numerous other controls can be enacted easily with IBM i’s QPWDRULES system value, and audited for compliance using Compliance Monitor.

Requirement 9 Restrict Physical Access To Cardholder Data

In my career, I have audited dozens of companies who have spent thousands of dollars to secure their data, but paid far less attention to the physical security of their servers. In one particular case, the customer would leave their backup tapes out in a public hallway for a courier (well, hopefully a courier!) to collect and take to a safe site.

Attention must be given to ensuring that sensitive areas require access controls such as key cards and access logs, and visitors should be easily identifiable. Social engineering is a very real threat, and I have witnessed numerous examples while working on an assessment team. Entry doors should be monitored by video surveillance and data from cameras should be kept for at least three months.

Media classification should also be used to determine sensitivity, and therefore the extent of the controls that should secure it, and then a plan should be developed and followed to ensure the safe disposal of information when it is no longer required.

If you have any questions about PCI compliance on servers running IBM i, or the solutions that can help with its compliance, please drop me a line. Otherwise, join me next week when we’ll wrap up with the final three requirements of the new PCI 2.0.

Cheers,

- rt

In last week’s blog, I began my introduction to the standards that govern organizations that process and store credit card information. Today, I’m going to touch on the next three requirements of the Payment Card Industry’s Data Security Standard (PCI-DSS).

Requirement 4. Encrypt transmission of card holder data across open, public networks

Similar to requirement 3, the use of encryption in this requirement is considered a critical part of data protection. This protection includes the use of technologies such as secure socket layer (SSL) and Secure Shell (SSH) to safeguard data while it is being transported across open networks. Version 2 of the PCI-DSS standard no longer permits the use of Wireless Encryption Protocol (WEP) encryption commonly found in home wireless networks, as the encryption is easily broken. Encryption of IBM i databases can be accomplished using IBM-supplied encryption interfaces—possibly requiring extensive application modification—or through the use of a commercial encryption solution.

Requirement 5 Use and Regularly Update Anti-Virus Software & Programs

The IBM i operating system has always enjoyed the envious reputation of being highly virus “resistant” (no-one wants to go out on a limb and guarantee it as virus “proof”). I would also offer that while its object structure makes a traditional viral infection unlikely, there are many other forms of malicious intent.

According to the PCI standard, any server that could be exposed to malware is required to use up-to-date anti-virus software. Despite its unique infrastructure, many PCI Qualified Security Assessors (QSAs) take issue with the ‘i’ platform not having such software. It should also be pointed out that if you use the Integrated File System (IFS) for any type of file storage, then it is very possible for the server to play host to virtually any form of traditional virus.

Fortunately, anti-virus functionality is now available for the IBM i. Standguard Anti-virus from Bytware—the only native AV solution to use a commercial scanning engine—should be integrated with the operating system’s own anti-virus controls. These controls include the ability to invoke an on-demand scan, or upon the open or close of a file. For more information on anti-virus for IBM i, check out this AV white paper.

Requirement 6 Develop and Maintain Secure Systems and Applications

Developing and using secure applications is an important aspect of data protection. While IBM i system patches—known as PTFs—are obtained directly from IBM, it is common for many shops to run on an unsupported operating system version, or without a policy for applying patches in a timely fashion.

Change control processes are a key component of compliance with this requirement, and numerous commercial applications exist to facilitate the promotion of application programs into a production environment. PCI requires procedures that review application code for coding vulnerabilities and, starting in June 2012, will require a risk ranking for newly discovered security vulnerabilities.

If you have any questions about PCI compliance on servers running IBM i, or the solutions that can help with its compliance, please drop me a line. Otherwise, join me next week when we’ll chat about the next three requirements of the new PCI 2.0.

Cheers

- rt

As you read this, I will be in the envious position of being able to compare a Midwest winter with an East Coast winter first hand, and I have a sneaking suspicion it’ll be a pretty fair fight! In the blue corner, we have Minneapolis, with a snow total measuring in at 48” so far this season; a solid 12” ahead of the seasonal average. In the red corner, the “Big Apple” showing its muscle after receiving its third largest snowfall since records began—a crippling 20 inches in one day! I do love both of these states, but as I travel between them and witness temperature dipping down to -35° F (actual temperature before windchill), I look back on last month’s trip to the Mojave Desert in Utah with a sad sense of longing. At least I will get to spend time with several local user groups in New York, Connecticut, and New Jersey, as well as sitting down with several customers to review their product usage, and upcoming compliance requirements.

Today we’re going to start our look at PCI compliance on IBM i, and learn about the first three of PCI’s twelve main requirements.

Requirement 1. Install and maintain a firewall configuration to protect cardholder data

While firewalls have long been regarded as a prerequisite to protect the corporate perimeter, the PowerTech “State of IBM i Security” study shows that 40% of servers still provide no restrictions to the internal users.

You have a couple of configuration areas to consider when it comes to firewall functionality for IBM i.

i) Exit points exist to allow monitoring of requests originating through network services such as FTP, DDM, and ODBC. Functionality of these services includes file transfer, remote data access, and even command entry. As the leading commercial exit program solution, PowerTech Network Security can firewall the servers’ network openness and provide auditing and control of user access through the 30+ network exit points that exist.

ii) Greatly enhanced in v6.1, IBM’s Intrusion Detection System (IDS) provides “traditional” firewall type restrictions to monitor anomalies in the TCP traffic. These anomalies can include Denial of Service (DoS) attacks, IP fragments, SYN floods, and scans of unused ports. For i 6.1, the IDS was enhanced to include a GUI configuration interface. For more information on the IDS, refer to the security category in the IBM information center.

Requirement 2. Do not use vendor-supplied defaults for system passwords and other security parameters

In this day and age, leaving system defaults might seem like an obvious requirement and one that wouldn’t need to be spelled out. However, the “State of IBM i Security” study continues to warn us that servers are often left with the IBM-shipped default password. Public access to libraries was restricted for only 8% of all libraries reviewed, and 88% of new objects created allow anyone with a user profile and password to view, change, and delete the data. Almost 60% of servers have no visibility to network requests through FTP and ODBC. And shockingly, 18% are still not auditing security events such as authority failures and failed logon attempts, despite the operating system having the capability built-in. Of the 82% that are auditing, I would argue that a good portion of those are doing it for High Availability (HA) purposes, and few are actually looking at the events that are collected. And then, of course, there are the servers that are deliberately configured with weak password rules and system values. Surely not, I hear you cry.  Unfortunately, I assessed a system myself last year that had a minimum password length of 1 and that never required password changes (not that passwords were adding much value to their security). The justification was that the CIO didn’t want to enforce strong password policy due to a large number of non-technical employees!

To help comply with this requirement, PowerTech Compliance Monitor has been engineered to report on hundreds of security metrics across any number of partitions, including password control system values and the identification of users with default passwords. Quickly identify which systems are in—and more importantly out of—compliance with your published policy.

Lastly, there is also the requirement to ensure that terminal sessions are encrypted and secured.  Fortunately, this is accomplished using IBM i’s existing SSL support.  TELNET connections that are not secure can be rejected.

Requirement 3. Protect stored cardholder data

A number of controls can help satisfy this requirement. Firstly, all communications should be encrypted to ensure that confidential data is not transmitted to display screens in plain text. This can be accomplished via secure socket layer (SSL) and virtual private network (VPN) technologies. Data encryption is often an important part of protecting stored cardholder information. This can be accomplished using IBM-supplied encryption interfaces—possibly requiring extensive application modification—or through the use of a commercial encryption solution.

If you are unable to effectively encrypt data (you will really have to prove your case), the PCI standards allow for “compensating controls.” One example of a compensating control is PowerTech Network Security which provides access control to database files from the network, and can be highly effective when combined with traditional controls such as an object-level security implementation.

If you have any questions about PCI compliance on servers running IBM i, or the solutions that can help with its compliance, please drop me a line. Otherwise, join me next week when we’ll chat about vulnerability management and access control.

Cheers,

- rt

A couple of weeks ago, I mentioned that January 1st 2011 would mark the official adoption of an updated PCI-DSS standard. PCI, for those of you who are not familiar, is an acronym for “Payment Card Industry” and DSS stands for “Data Security Standard.” The PCI regulatory body was formed by an international consortium of credit card organizations including VISA, American Express, and MasterCard. The first version of the PCI-DSS standard was first release in 2004. A security standards council (SSC) formulates the requirements of how credit card data must be processed and secured in response to the explosion of credit card fraud over the past 10 years.

Version 2 was released at the end of October, and is now formally adopted as the current standard. The previous version (1.3.1) is still going to be honored through December 31st 2011, although this is intended only to give companies time to review, understand, and comply with the new directives.

Unlike some other regulatory standards, the PCI-DSS standard is relatively easy to comprehend from an Information Technology standpoint. There are six main control objectives, consisting of a total of 12 main requirements.

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software on all systems commonly affected by malware
6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security

Over the next few weeks, I am going to give you an introduction to each of the PCI-DSS requirements, along with some ways that PowerTech solution modules can assist you with compliance.

Cheers,

- rt