Resolve to Take Security Seriously in 2012

By Robin Tatam, Director of Security Technologies

Now that we’ve rolled through another New Year’s celebration, we’ve left behind one of the worst years on record for data breaches. Privacyrights.org, a consumer advocacy organization, reports that 2011 witnessed a staggering 547 breaches involving more than 30 million records. Companies ranged from small non-profits to industry giants such as Bank of America, Sony, and Epsilon. Interestingly, 86 of those breaches (involving almost 120,000 records) involved insiders with some level of legitimate access. With mitigation costs now surpassing an estimated $200 per record breached, we’re talking about some pretty serious money!

With all of the current investment and focus on legislative compliance, how is this still possible? How can huge multi-national companies continue to fall so hard? It’s actually not that hard to understand. In my opinion, too many companies focus on achieving compliance at the expense of security.

Guidelines Are Simply a Beginning

A simple analogy is to think of obtaining your first driver’s license. As young adults, we study a handbook and take a test to verify that we understand and are compliant with the basic laws of the road. But, do we let newly “certified” drivers loose on busy highways with the expectation that they are now perfect drivers and will never get into an accident? Of course not! The guidelines (hopefully) help us avoid making basic mistakes, but there are many other factors to consider.

One flaw in the guidelines is the assumption that everyone else is adhering to the same rules—something that every speed limit sign and red light camera shows isn’t true. Experienced drivers understand that many things aren’t included in the handbook. We have to expect the unexpected, adapt and use learned experiences to read between the lines, and improvise—sometimes with little or no warning—to avoid an unplanned disaster.

The same is true of computer security. Regulations like Sarbanes-Oxley and HIPAA were never meant to intricately detail how to protect your IBM i database from misuse. These two common regulations (and many others) are basic guidelines regarding access to critical business data. Focusing solely on satisfying compliance can be misguided, and might lead an organization to assume they are secure. In 2011, hundreds of new organizations joined the ranks of those that discovered the reality of making this assumption.

Don’t Sacrifice Security for Compliance

Compliance is an important objective, but it shouldn’t be pursued at the expense of a comprehensive security plan. In fact, taking the time to build and implement a solid security infrastructure will make that objective easier to achieve. New business processes and procedures typically will be required by a compliance standard, but the technology aspect of compliance usually is left to interpretation by an auditor who is often unfamiliar with IBM i. It’s critical, therefore, that you don’t rely on compliance directives as the sole guideline to protecting data access.

Using the analogy of new drivers, testing is important to ensure that we understand and acknowledge the basic rules of the road. However, it’s ultimately the focus on learning and employing good driving skills that’s going to have the greatest impact on the likelihood, magnitude, and consequence of an accident.

Make the Commitment Today

Businesses need to get smarter and become more committed to security. They must allocate a budget to assess and mitigate the largest risks and acknowledge that controls probably will be compromised at some point. The goal is to develop a plan to address possible breach scenarios BEFORE you find yourself in the middle of one. The plan should include the deployment of technology for the timely detection and alerting of a problem, and training of employees designated to respond and react. This is not just theoretical—a number of recent breaches involved warning signs that were not responded to correctly. Many employees never receive adequate training on their company’s security tools, leading to a false sense of security by management.

Look at the Big Picture

Don’t secure only the data at rest in the data center; look at the entire data lifecycle. And, expect the unexpected. Many of last year’s breaches involved collecting credit card information from point-of-sale (POS) devices and ATMs. This came from skimming devices, employee theft, and unauthorized replacement devices at retail store cash registers! We cannot control the intent of the criminal element so we have to devise better ways to deter, detect, and respond. Similarly, lost and stolen laptops might be out of your corporate control, but securing the data stored on them isn’t. And, while we might not classify this like a traditional breach, the Ponemon Institute reports that it happens 637,000 times at U.S. airports every year!

For most organizations, corporate budgets have been established for the upcoming year. If yours doesn’t include money for security-related projects, focus on fully leveraging your existing investments and staff resources for now. Ensure that employees are trained and are optimizing their tools. Remember, while we hope that this year is a vast improvement over last, it’s never too early to start planning for next year.

In 2012, let’s start taking security more seriously.
—————————————————————————————-

Generate and Distribute Audit Reports Automatically

By Robin Tatam, Director of Security Technologies

Remember the humorous MasterCard commercials from a few years ago? In my mind, I see one of them going like this:

• State-of-the-art, 64-bit, multi-core Power7 hardware: $225,000
• Highly securable IBM i operating system: $100,000
• Discovering you can generate and distribute audit reports automatically: PRICELESS

This joke probably isn’t too funny to anyone who’s responsible for generating audit reports from IBM i. Despite the server’s incredible security infrastructure, auditing remains primarily a thankless, manual chore. And, let’s face it, any task that’s thankless and manual probably won’t get done. Even with a commercial audit tool, a user must decide what reports to run, and then compile and interpret the results.

A Basic Audit Scenario

A common report request from auditors is for a list of the powerful users on the system. Your first question is likely to be “what is a powerful user?” Unfortunately, there’s no official auditor’s dictionary (wouldn’t that be nice!)—each auditor has different criteria.

Maybe you can omit IBM-supplied profiles, disabled profiles that haven’t signed on for at least 45 days, and any profiles without a password. They’ll ask for each of those reports separately. Then, don’t forget to include the users from all 15 production IBM i partitions, preferably on a single report so it’s easier to process.

Here’s one way to accomplish this task:

Step 1: Run IBM’s user profile report (PRTUSRPRF) to dump the configuration data for ALL defined users. Print a hard copy of the report, or figure out how to use Navigator for i to download it to your PC.

Step 2: Manually review each user profile to see if it meets the auditor’s criteria—and hope you don’t have too many profiles to deal with! Don’t forget special authorities of the sixteen possible group profiles the user might belong to in case any authority is inherited. Oh, and the report doesn’t include the number of days since prior sign-on, so you’ll have to determine what the date was 45 days ago, and check that manually. And, you’ll also have to manually exclude the “known” users from the report each time.

Step 3: Document the name of the users that remain.

Step 4: Return to Step 1 and repeat for the next server.

Step 5: Aggregate the results into a single report (somehow) and distribute it to the auditor (somehow) in a secure manner.

Step 6: Prepare to prove to the auditor that the information hasn’t been tampered with (since you’re likely to be one of those powerful users). Also, expect to be asked for a lot more than one simple report.

This is a fictitious scenario, but it’s not unrealistic. It doesn’t take very long to realize that the process is tedious, time-consuming, and expensive; not to mention error-prone and arguably considered self-policing.

A Basic Audit Scenario (Revised)

Compliance Monitor has the reports you need. Powerful (and modifiable) filters you can apply to the data make child’s play out of creating custom audit reports. And, its assessment scheduling and distribution function allows you to run reports at regular intervals across multiple systems and distribute them on completion.

Let’s take another look at that scenario, now using Compliance Monitor 3:

Step 1: Point and click to select the systems to assess.

Step 2: Point and click to select from the hundreds of available reports.

Step 3: Specify the run schedule (optional) and distribution requirements.

Step 4: Sit back and relax.

You can send the reports automatically via e-mail as individual files, or bundled into a password-protected (and encrypted) zip file. Report files can be editable, or PDFs that are digitally signed to reassure auditors that the information hasn’t been tampered with. If you prefer, you can place the reports in the IFS for the user to access.

Compliance Monitor eliminates the burden of audit reporting. Its hundreds of report options give visibility to static information, such as user profiles and system values, as well as dynamic events recorded into the security audit journal, QAUDJRN. Priceless—YES!
—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
Some of my Authority Broker reports are blank, even though I know there was activity during the requested time period. What would cause this?

A: Authority Broker records its activities to the security audit journal, QAUDJRN. When you request an Authority Broker activity report, the journal receivers on your system are checked for the entries that correspond to the date and time range specified. If the receivers that contain those entries have been removed from your system, the report will be blank. You’ll need to restore the receiver(s) to get the information you want.

You should consider automating your Authority Broker reports to prevent future problems. Schedule the LEVENTRPT command in a job scheduler, such as Robot/SCHEDULE. Press F4 to display the command prompt panel and complete the command parameters.

Dear Paulie,
How can I determine if the latest version of Compliance Monitor will run on my system?

A: Compliance Monitor Version 3 includes a Windows executable “pre-checker” utility (CM3CHECKER) that determines if your system meets the product’s prerequisites. You can run the pre-checker prior to a new install or an upgrade. The pre-checker uses an installation wizard to send a save file to your system, where you can restore it and run the program. When it completes, it generates a spooled file that identifies any prerequisites you might be missing.

The pre-checker also is available as a separate download from the PowerTech website.
—————————————————————————————-
Learn more with PowerTech Webinars and online training.

Request a demo.

by Robin Tatam, Director of Security Technologies

Habit 3: Assess Current Standing

Last month, we discussed identifying standards for your security infrastructure. The important next step is measuring yourself against them.

The results may startle you the first time, but it is better to discover gaps yourself than leave your system vulnerable.

As you review the findings of your security audit, determine if your server’s security configuration needs to be adjusted, or if the security policy needs to be adapted to better match business requirements.

Don’t Judge Yourself
When considering how to conduct your assessment, know that self-assessment is not as effective as a professional review. An impartial expert can zero in on deficiencies in your policy, whereas your IT staff might not be objective in assessing the controls they design and maintain.

After all, who wants to audit their own work?

Free Resources
PowerTech can get you started quickly, with a free, high-level assessment (see Figure 1) that compares your IBM i server against industry best practices. The process takes about ten minutes, and an IBM i security specialist analyzes the findings with your team.

PowerTech also performs deep-dive assessments to provide detailed information on dozens of security configuration areas. Our customers sometimes use these assessments as a precursor to a formal audit.

Figure 1 – PowerTech Offers Free Compliance Assessments of IBM i Servers

Habit 4: Perform Security Event Logging and Review

According to PowerTech’s annual State of IBM i Security study, almost 20% of IBM i shops still don’t practice event logging (see Figure 2).

This number would likely be higher if we excluded those using system events for High Availability (HA) replication, rather than for security monitoring. This is one of the lowest rates we found since we started keeping records in 2004.

Figure 2 – Systems Using the IBM i Audit Journal

Anticipate Audits
Most regulatory and industry compliance standards require user activities and system events to be logged and stored for subsequent forensic analysis.

The collection of audit data is a built-in function of the operating system; however, you have to configure it.

PowerTech has information resources and security specialists to help you with the activation. After you determine what types of activities should be audited, there are several operating system commands you can use.

Better Save than Sorry
The challenge for most enterprises lies in reviewing large volumes of event log data, which is best handled by a commercial solution.

Even if there is no way to review raw log data (the operating system only includes basic extraction commands), collecting the data lets you load a tool after a security event and review what was collected.

If there is no audit data, no tool can reconstruct it.

You are typically required to plan for event log data retention, and should defer decisions about retention periods to corporate auditors or legal advisors.

Get our full State of IBM i Security study here.

Learn more with PowerTech Webinars and online training.

Request a demo.

Q: How can I use PowerTech Network Security to globally prevent users from updating data via Open Database Connectivity (ODBC)?

Note: Before implementing global rules, run audit reports against the server to make sure you do not prevent necessary access.

A: From the Work with Security by Server screen, locate the SQL server (*SQLSRV) and place UA in the field to Edit User Authorities.  Add your user ID, and set the CAPTURE flag to YES (Cap = Y). Perform an update.

From the Main Menu, select the Work with Captured Transactions option. Then, locate the UPDATE transaction you performed. Place a 1 next to it to MEMORIZE the transaction. This opens the transaction for you to edit.

1.    Change the User to *PUBLIC.
2.    Change the Authority to *REJECT.
3.    Change the Transaction to UPDATE%.

To add users or groups who are exempt from this rule, give them an authority of  *OS400. Also, we recommend that you change the Send Messages option to *YES.

This configuration prevents users from updating data via Open Database Connectivity (ODBC).

Learn more with PowerTech Webinars and online training.

Request a demo.

By Robin Tatam

Although this article’s title is a play on the name of Stephen R. Covey’s motivational book series, my intent is serious: to highlight important habits companies must consider as part of an overall strategy for first becoming secure, and then compliant. These aren’t the only habits you’ll need, but they are imperative for organizations struggling to get started.

Over the next three months, I will explain what the seven habits mean to your organization and describe how to put them into practice successfully.

Habit 1: Break the Ostrich Syndrome

The first habit to adopt—or break, depending on how you look at it—is to realize and acknowledge that the server is NOT inherently secure.

Before you consider suing IBM for two decades of false advertising, or write to me politely questioning my expertise, realize that I said secure and not securable. The distinction comes from the fact that the server ships from the factory with its security configuration virtually wide-open. To be fair, IBM hasn’t ever claimed that you are going to be secure simply by plugging your server into an AC outlet and turning the power on. It’s staggering how many assessments we perform each year that show critical application data accessible through tools like Microsoft Excel. Or through free or cheap desktop tools connecting through services such as FTP, DDM, or remote command.

Don’t count on old standbys
Also, relying solely on legacy security mechanisms such as command line limitations and applications menus might not offer an appropriate level of security. Whether it’s programmer workload or a lack of IBM i object security knowledge, application developers do not put much thought into the security aspect of their programs. Many commercial application vendors add little value when it comes to securing the data in their application; customers often suffer from a false sense of security when purchasing these products.

Minimizing security risk takes money, time, and expertise. It also requires foresight and honesty. Habit #1 requires us to acknowledge risk so we can decide how to address it.

Habit 2: Develop a Security Policy

In a blog post, I announced that PowerTech security writers were updating our popular open-source security policy. If you don’t have a policy to oversee the numerous security controls and procedures in your environment—both for IBM i and beyond—you stand little chance of being able to maintain a secure configuration for any period of time.

Have you ever wondered why you have to repeat the dreaded task of cleaning out your garage, basement or attic annually? If so, it’s likely you don’t have a policy to control the use and placement of the contents in those locations. The bottom line is that computer servers don’t secure themselves! Even with the best intentions, we are only human and usually become complacent unless we have controls and procedures in place.

Balance is good policy
Consider developing a policy based on industry best practices. From there, customize the policy with an assessment of compliance levels in your environment. This allows you to establish balance between allowing the business to function and establishing the security that prevents it from being abused.

It’s important that the security policy not be designed and implemented only within the IT department. To be successful there needs to be executive sponsorship and management buy-in. This ensures the standards contained within the policy are consistent and enforceable within corporate directives.

Put security in the right hands
A good security policy has multiple layers, often beginning with non-technical corporate directives, general access and use statements, and moving to specific configurations and procedures for the technologies in use. Don’t make the mistake of involving executives in technical decisions—generally, they don’t understand or care. Place the responsibility for interpretation and documentation in the hands of a security officer. Then, have the security administrator set and monitor the configuration to ensure compliance with the security policy.

Your security policy should be a dynamic document with a defined lifespan. This helps guarantee that you remain abreast of changes in your business, your industry, and technology.

Next month, we’ll discuss security assessments and event logging as we continue through the 7 Habits of Highly Secure Organizations.

Learn more with PowerTech Webinars and online training.

Request a demo.

By Robin Tatam

According to PowerTech’s “State of IBM i Security” study, approximately 20% of enterprises don’t perform system, user, or object audits. When you factor in those that capture only a few event types, those that don’t do anything with data once it is captured, and those that use event data for purposes other than security, you end up with a river of events flowing through the cracks, completely unnoticed.

Luckily, PowerTech Compliance Monitor includes centralized compressed storage for audit journal events from multiple partitions.

Why Don’t People Audit?
Why aren’t administrators rushing to take advantage of an operating system with the built-in ability to collect event information? Auditing is the topic of many PowerTech Webinars, as well as a popular subject for presentations at COMMON and regional user groups. I have noticed three main reasons people don’t audit:

1.  Lack of awareness and understanding of auditing functions
Ignorance might be bliss in some aspects of life, but in security auditing, it’s never a good thing. You can’t expect to see anything unless you turn on the function—akin to turning on a flashlight in a dark hallway. Fortunately, the operating system contains a simple command, Change Security Auditing (CHGSECAUD), that performs the heavy lifting. PowerTech can provide the background knowledge to help you configure it to collect data efficiently.

2.  Poor forensics capability
Without a good forensics solution, audit data is just raw data without business benefit. IBM i contains a basic extract command, but you still need to write queries or programs to make much sense of it. Collecting but not reviewing event data is better than not collecting—at least data is there if you need it. But, it is better to have an efficient way to search, filter, and extract entries from the generated audit data.

3.  Insufficient storage space for overwhelming volumes of journal data
Although disk management is not directly related to auditing, anyone who has turned on auditing can testify to what I’m talking about. Large systems can generate gigabytes of data daily. Not only does this make a forensics solution an absolute must, it also requires careful consideration for the DASD units that house the audited data. You can and should be selective about how and what is audited, and you should save audit data frequently for disaster recovery. But, making recent events accessible quickly while consuming less disk space is usually more desirable.

Compliance Monitor Has An Answer
PowerTech, the market leader in security solutions for IBM i, can teach you how to configure the operating system’s auditing controls efficiently. Then, you use Compliance Monitor to address the challenges of reasons number two and three.

One of the advanced features of Compliance Monitor is its ability to harvest audit journal data. You choose the data you want from one or more endpoint partitions based on the audit journal code, then transfer and store the information on a central partition. A built-in scheduler in the graphical reporting console (see Figure 1) allows you to transfer data on a regular schedule on the days and times convenient for your business.

Figure 1: Compliance Monitor lets you specify schedule and event types to harvest and store.

The harvested data is stored on the central partition in compressed form. Imagine keeping 30 days of audit history online in the same amount of disk space previously consumed by just 3 days of data. When you need the data for forensic reporting, Compliance Monitor automatically handles the decompression–you don’t have to worry about locating and manually restoring journal receivers from tape, or transferring immense files using FTP.

Compliance Monitor helps you search, filter, and extract entries from your audited data.

Learn more about Compliance Monitor or request a Free Webinar demo.