Our Top Five Blogs of 2013

As we start off 2014, take a look back at five of our most popular blogs from the past year. Great topics, great content… and more to come!

MySQL and Encryption Key Management - 3 Ways Alliance Key Manager Encrypts MySQL Database and Protects Encryption Keys

Summary: With a strong encryption key management solution you can encrypt data in a number of ways in MySQL databases to meet compliance regulations for proper encryption key management. MySQL is the most popular open source relational database system and is in wide use in commercial and non-commercial environments. It is natural that developers and security professionals want to know how to encrypt sensitive information stored in MySQL databases.
Download:  eBook – Encryption Key Management Simplified

 

AES vs PGP: What is the Difference?

Summary: AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. PGP uses symmetric and asymmetric keys to encrypt data being transferred across networks. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it.  AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.
Download:  Webinar – 4 solutions for Data Privacy Compliance

 

Understanding Log Management on the IBM i

Summary: System logging is important across all operating systems… Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.
Download:  Webinar – Understanding System Logging on the IBM i

 

Why Partner With Townsend Security? What To Look for in a Strong Technology Partner

Summary: Businesses only want to partner with a technology company that has a good reputation. Mark Foege (Business Development Consultant and Principal at the Colvos Group) recounted, “...and that’s why they were excited to partner with Townsend Security. We realize that everything we do impacts the reputation of our partners. That’s why it’s important to us to provide solid, high value products, to make sure we are offering consistently first class support, and we work with our partners to make sure that their customers are completely delighted." Watch the YouTube Video with Townsend Security CEO Patrick Townsend and Mark Foege, they outline the importance of building strong technology partnerships for success, and what to look for in a partner.

 

What is Encryption Key Management?
Key Lifecycle & Rotation Explained

Summary: Encryption key management refers to the ability of a system to administer an encryption key through the length of its crypto-cycle. From the creation of a key, through it’s use, and eventually to its deletion, an encryption key management system needs to be able to securely and efficiently handle the encryption keys.
Download:  eBook  - Encryption Key Management Simplified

 

Do you have topics you want to learn more about?  Let us know by leaving a comment here, we will get back to you with an answer... and probably blog about it too!

 

As we discovered in the blog Signs Your IBM i May Have Been Hacked, the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches.  Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by industry experts from Townsend Security and Integrity.  Here is a recap of that Q&A session:

Q: Do compliance regulations require system logging?

A: Most regulatory compliance standards such as PCI-DSS, FISMA, GLBA, and HIPAA/HITECH require organizations to monitor their network in real-time and provide audit reports. For the Payment Card Industry Data Security Standard (PCI-DSS), there are numerous logging requirements to be PCI compliant. Auditors want to look at how the logs are generated, whether it’s systematic or whether an operator can access/edit them, go in and pull them off and move them somewhere else. They want to look at if there’s mirrored events, where they go off the system through an automated process without any potential human intervention. It also details if people have the right privileges. Logs will show user events as well as what individuals are accessing libraries, files, or other areas outside of their designations. Logging is not only an industry best practice, it is a critical control to understanding access to a system.

Q: We have some custom applications that run our core business. Can a SIEM solution analyze the log files that come from these applications?

A: Dave Nelson from Integrity answers “Some SIEM applications are able to analyze log files from custom applications, others are not. Integrity’s SIEM can create a custom parser that can take just about any log that you can provide. Integrity can analyze that, we’ll work with your internal application development staff to identify what different error codes or security event log codes or whatever it is that you’re creating to identify a specific event. We can map that then into the parser then we can map those to either standard alerts or we can create new custom alerts, we can customize thresholds and a lot of different things. That’s one of the reasons that our customers choose us most frequently is because they have those internal applications that are custom that a lot of the other SIEM tools can’t handle, but we can handle and we can give them a lot of information about something that’s very unique to their business.”

Q: You mentioned File Integrity Monitoring (FIM), can you further explain how an organization would use it?

A:  It’s not every field that you’re going to want to alert and log and monitor on, but there might be ones with credit card numbers or store order authorization codes that you want to monitor and make sure the data hasn’t been altered or accessed without consent. The point to stress with logging and file integrity monitoring is ultimately it helps the individual system operator. You can have mirror alerts go to multiple people in the company, security officers as well as system operators. With FIM you take responsibility off of any one person having to follow up and do it all and you can create more of a collective team that analyzes this data to help the business.

Q: How can we distinguish a false alarm from a successful attack?

A: Sometimes it can be very difficult to determine a false alarm from a successful attack until you have done an entire investigation.  People that do this day in and day out and can begin to identify the patterns and trends of what makes an attack successful or not.  In our experience, the easiest way to do it is to look for key data points or key events that should have happened. One of the things you can do is jump right to the end if you know that a specific attack is successful, and work your way back through the system to determine the file name and creation date.  This really only comes with experience and practice of identifying the missing pieces.

Please post any additional questions you may have here on the blog!

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

(Based on a recent webinar with Townsend Security and Dave Nelson, President of Integrity)

Your IBM i may have been hacked and you don’t even know it yet!

Industry experts from Townsend Security and Integrity discuss how the combination of secure system logging on the IBM i and log monitoring with a SIEM will help you secure sensitive data and minimize the impact of security breaches. Topics cover (and go beyond) how log files and log data are the digital evidence (artifacts) that actually take us to a point of action within a system. They look at what the false alarms are within the plethora of data and how to screen those out. Then they also talk about the next steps: What are the red flags to watch for, and what to do with those red flags.

“As we look at the millions of data points that are created each day, every login or logout, every time a user is created, every time a user accesses a resource or adds a new resource or saves a file…. amidst all that data, hacking events happen. What we have to try and do is understand the ways that we can sift through that data and reduce the background noise and address the successful attacks.” (Dave Nelson)

Things to look for in log files as we’re trying to identify what’s real data, false alarms, or red flags:

New users and user accounts - Look for things like random names (like BSX or BS4XOR) and be able to identify new users. Always be able to trace these new user accounts back to a user account request and be able to identify which of those accounts have an approved resource and which ones have not.

New files and directories - Identify new directories, look for batches of files that show up between things that are normally next to each other. One of the things hackers love to do is hide files on any sort of Windows mountable or UNIX mountable directories within your i Series because a lot of times the IBM i doesn’t have an antivirus check or an antivirus application on it.

Date and time stamps - There are some (system) files that you know shouldn’t change. If you start to notice that those file modification dates or the save dates on those files and libraries have changed, that should start to be a red flag.

Significant increase or decrease in the size of a file or a library - Hackers will inject data into the back end of an existing file so that the file itself doesn’t change and it can still be executed. So watch for files that used to be a few kilobytes and are now a few megabytes or even gigabytes.

New processes or services that are running - Anytime you have a batch job that’s running and you’re not familiar with it, that should be something that you look at right away. Look for unusual interactive jobs working between LPAR’s or between systems. Do you normally have data leaving your IBM i and going to another platform? or a direct connection from a Windows server directly into your IBM i?

Cryptic or unusual file names - Create some sort of naming convention within your organization so that you know if something is outside of that standard.

It is suggested that we think of log files as the forensic evidence for the IBM i system and think about monitoring almost as a crime scene investigation. The relationship between the logging agent and the collector of those logs is very important because unexplained system value configuration changes, application changes, changes to privileges and privileged user profiles are indicators of potential malicious activity that you can record. These logging tools are strengths for an organization to really get to know what the system is doing as part of daily business activity, and then how to alert and monitor for data protection.

With all the different types of data that you can look for, the sheer volume of information that’s out there, there’s absolutely no way that an individual system administrator and application developer, even a full time security professional is going to be able to sift through that amount of information. Partnerships between the SIEM (Security Information and Event Management) collector and the logging agent are now industry standard defense and depth controls. Automation and email notifications about potential malicious activity can immediately give you the chain of custody to provide the digital evidence you require to go investigate further. You want to be able to drill down to specific threats, events, and user specific events as part of any good governance risk & compliance program and risk management approach. Essential for a total enterprise solution is the partnership (and strong encryption) between LogAgent and a SIEM.  

As a SIEM solution that partners with Townsend Security’s logging solution*, what Integrity’s done differently is provide a managed SIEM service. Dave tells us “We’ve got clients running this on the i Series platform using Alliance LogAgent to monitor, interfacing with our SIEM, and  they have said ‘Wow, we didn’t have any idea that we could get this much information and that it could be this easy to access and that we can share it’.  Clients want to be able to share that with their network administrators and say ‘See, this is what we’re seeing, we’re seeing this traffic and we don’t know why it’s coming in, can you please stop it and block it’.  One of the best things about Integrity’s SIEM solution from a cost perspective is that there’s no capital investment. You don’t have to spend $100,000 for the software, $50,000 for hardware and then go out and hire a full time person to review these logs and to set up the system and manage another system and application within the environment. It’s all provided for you for a low monthly cost. You get this in a matter of days and weeks instead of a matter of months. So you’re getting immediate return on your investment. In these economic times we all know how important that is to be able to show ‘Hey, we’re getting some real value for this expenditure that we’re making, we’re seeing a lot of things happening’. One of the other benefits is that you’re not going to see just security information from this. The amount of information that you’re going to get, you’re going to see operational things that you hadn’t seen in the past. You’re going to see things that you look at and say ‘Wow, we had no idea the system was operating that way, or those processes were running, or those jobs were running or taking so long to run’. The feedback that we get from our clients is that the value they get from the operational side of the SIEM is almost, if not as much, as what they get from the security side of the SIEM. So just being able to see deeper into the environment and seeing what’s happening, what’s going on has been great for a lot of our clients as well.”

*Townsend Security’s Alliance LogAgent is a comprehensive platform specific solution for IBM i which helps cut through the noise and deliver granular valuable data, providing file integrity monitoring right down to field level changes. Key steps you want and need for compliance purposes as well as data security.  

For a much deeper and more detailed discussion on secure system logging and monitoring as essential controls to detect and mitigate the risk of a data breach, please request a download of the entire webinar:

If these technologies are not in place, do you really know you haven't been hacked?

As we discussed in the blog Understanding System Logging on the IBM i – Part 1, secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.

Here is a recap of that Q&A session:

Q: Can you pick which group of users to audit?

Patrick: In our current version of Alliance LogAgent, our IBM i system logging solution, you can define a list of “excluded users.”  So you can actually tailor events on the IBM i platform and exclude particular user profiles.  We also provide some basic filtering capability allowing you to filter based on IBM event type and on User event type.  So yes, there is a fair amount of filtering capability in the product.  From a security posture, it would be a mistake to filter out significant security events, however the solution allows you to easily choose and select the events you want.  We have an option that maps straight to the security system values so you can easily set LogAgent to process those or you can establish and select any and all of the event types in the product that you want to monitor.

Q: With all the different IBM system events, is it possible to set up filtering of just the IBM security event types?

Patrick: Yes, In our solution, collection of the system security events is set as the default “out of the box” setting.  You have total control over the events you collect, and with just a few keystrokes, you can re-map your collection and filter in additional events, or leave it set to what IBM identifies as the security type events being collected in QAUDJRN.

Q: Can File Integrity Monitoring (FIM) also monitor read access to a database file? What about a user that comes in from another server doing just a select in SQL?

Patrick: The File Integrity Monitoring component in LogAgent is based on a database journal. A record-level read event is not collected in a database journal; but a file open and closed event is collected.  So if a user does access a file through read and there’s no update, insert, or add type of event, it may not appear in the journal. We capture all the information that the system makes available to us in the file integrity monitoring component on significant changes or access to any protected file.

Q: You mentioned File Integrity Monitoring. Can you further explain how an organization would use it?

Patrick:  File Integrity Monitoring is designed to monitor configuration changes and highlight them for early detection.  Generally, when an attack happens on an application it often involves changes to configuration files in an attempt to escalate privileges and give the attacker more authority or access than they should have.  For example if a new user is suddenly granted authority in the HR application to print checks, that is an important indicator of a potential problem!  Another common use for File Integrity Monitoring is to monitor the use of stored sensitive information (credit card information or social security numbers) on your IBM i platform, you would want to use FIM on those databases or applications in order to strengthen your security stance and identify those potential attacks early on.

Q: How do you keep QAUDJRN entries from flooding the network?

Patrick: With the large volume of events that can be collected by QAUDJRN, you can really help minimize network impacts by filtering out events that are not security related.  You can still collect those events, but exclude them from being transmitted to your SEIM console.  Because LogAgent works in real time it helps reduce the impact on your network because you are not transmitting millions of events all at once. We also provide metering capabilities so you can reduce the number of events per second that are being transmitted.

Q: How do these logs get stored?

Patrick: When it comes to log storage, you want them off of your IBM i platform as quickly as possible to avoid potential tampering or corruption.  With LogAgent, we do not make a copy of the events, we take the filtered events out of QAUDJRN in real time, format and transfer them to your log collection server or SEIM.  Since some compliance regulations require the events are stored for a defined period of time, SEIM consoles compress, store, and protect those log events so you have the ability to do forensics, queries, and reporting on them.

To learn more, view our webinar "Understanding Log Management on the IBM i" which examines the security principles, compliance requirements, and technical challenges for log collection and forwarding on the IBM i platform with the following learning objectives:

• Security principles of log collection and monitoring
• Compliance requirements of PCI DSS, HIPAA/HITECH, SOX, GLBA/FFIEC
• Communicating with log collection and SIEM servers
• File Integrity Monitoring and log collection
• IBM i log collection challenges

 

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

Compliance regulations require (or strongly recommend) system logging. Do you know which of these apply to you and your company?

PCI Section 10 requires logging for anyone who collects credit card data

Requirement 10:  
 “Track and monitor all access to network resources and cardholder data”

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!

Podcast: Better System Logging Download the podcast "System Logging on the IBM i - How to Do It Better." Click Here to Download Now

If you could find out if your network is being hacked or tampered with, as it happens in real time, would you want to know? If there was a tool that collected, encrypted, and standardized your IBM i security events to give you peace of mind, would you use it?

We’re guessing yes. Luckily, system monitoring software is widely available for IBM operating systems, and there are two big reasons why you should use system monitoring:

1. Most system breaches go unnoticed for months (sometimes years) before the breach is discovered and dealt with. By then a hacker or employee may have gained access to thousands of personal files containing sensitive information such as credit card numbers and home addresses.

2. Less than 1% of the breaches in 2011 were discovered through log analysis, even though 69% of these breaches could have been detected before any data was lost if proper system logging was in place.

You know you need to collect your system logs in real time in order to detect unauthorized changes to your system, but with all of your security logs being created on different systems, web services, and applications, the task might seem overwhelming. How do you get a consolidated view of the security state of your database? How do you get information into usable format for log collection and Security Information & Event Management (SIEM) servers?

The answer is in a third party logging solution that can standardize, collect, and report security events. There are many logging solutions out there, but your solution should always provide you with these four key points:

1. Real time Log Collection. Your logging solution should collect logs of events in real time as they happen across multiple applications and servers. You should be alerted immediately to suspicious log events on your servers instead of receiving a batch at the end of the day or week.

2. High Speed Performance. Performance should not be a barrier when it comes to log collection and analysis. Your logging solution should be able to collect tens of millions of events from multiple applications and thousands of users per day without huge performance impacts.

3. Secure Communication. Your logging solution also needs to secure the transfer of events to a log server. Your logging solutions should use SSL TCP to encrypt log entries in transit from an IBM server to a log collection server.

4. Industry Standard. There is a standard format for system log events, and the data you collect from your IBM i and transfer to your log collection server should be in that format. The most widely used standards are the syslog standard based on RFC 3164 and the Common Event Format (CEF) used by a number of SIEM vendors.

Townsend Security’s Alliance LogAgent and LogAgent Suite with File Integrity Monitoring (FIM) allows IBM i users to meet compliance regulations by collecting security system logs and transmitting to a log collection server or any SIEM solution. Alliance LogAgent will help you achieve inner peace of mind.

Podcast: File Integrity Monitoring on the IBM i Learn more about File Integrity Monitoring (FIM) on the IBM i. Click Here to Listen Now

1. Increased security of sensitive data

The number one advantage of File Integrity Monitoring (FIM) is increased security in your database(s). When you look at how data breaches happen, we often see a very similar chain of events. First, the data breach is discovered by someone inside the company, or a third party investigator. Second, the breach was discovered to have happened weeks, if not months ago. Third, the security holes in the IT infrastructure take several more weeks to plug. And finally, the database administrators discover that the breach could have been completely avoided using tools, such as file integrity monitoring. I won’t even go into the subsequent steps which also include data breach notification and paying hefty fines (an average data breach costs $5.5 million, by the way).

FIM allows you to see potentially harmful changes made in your database in real time. FIM helps you to detect early events by monitoring for changes to access controls, configurations, and all sensitive data at both database and application levels. For example, if you are storing social security numbers, credit card numbers, or other personally identifiable information (PII) on your IBM i, you can subject those fields to file integrity monitoring to catch any changes to that data immediately when it happens.

2. Comply with Industry regulations to pass your next audit

You should always know which data security regulations your organization must comply with. PCI DSS directly requires File Integrity Monitoring controls to prevent unauthorized access or changes to sensitive data (section 11.5). File Integrity Monitoring is also a critical component of the Sarbanes-Oxley (SOX) act for publicly traded companies. The Federal Information Security Management Act (FISMA) as well as the National Institute of Standards and Technology (NIST) also mention File Integrity Monitoring as a recommended security control.

3. Not a Matter of If, but When

There’s a really, really good reason why governments and industries are imposing more and more stringent data security regulations on both public and private organizations: the number of data breaches occurring every year is not slowing down. It’s speeding up! A common sentiment these days is that a data breach within your company isn’t a matter of “if”, but “when”. Think about it this way: How many times have you received a call from your bank informing you that your credit card has been compromised and they are issuing a new number? Once? Twice? Three times? More? The unfortunate reality is that even though data breaches run rampant like wildfire, many businesses are doing too little or nothing at all to protect their data. When the fire hits your business, I bet you won’t be thinking, “good thing I didn’t waste my time on fire alarms and home owner’s insurance!”

For more information on file integrity monitoring and meeting data security compliance regulations, check out our podcast, “File Integrity Monitoring on the IBM i”, featuring Patrick Townsend, founder and CEO of Townsend Security.

Podcast: File Integrity Monitoring on the IBM i Learn more about File Integrity Monitoring (FIM) on the IBM i. Click Here to Listen Now

As an IBM i security administrator, don’t you sometimes wish that your IBM i would just talk to you? Like a good friend, just tell you stuff that you need to know? The IBM security journal, QAUDJRN, can collect millions of events every day. But there is no way you can really sort through all of that. And, there isn’t even any information that tells you about your sensitive application file changes. It would be great if your IBM i would just inform you of bad stuff that is happening.

Perhaps it could say something like:

“Uh oh. Bill in the shipping department just changed the payroll file and gave himself a really big raise.  He’s now making major Wall Street coin. You might want to check on that.”

Or

“Whoa, big red flag here! Sally in accounting just transferred the credit card history file to an FTP server at 3 AM. There’s no way that should be happening!”

Yes, you DO want to know about these things before it hits the front page of the New York Times.

Actually, this kind of information is now easily within reach. Security applications that perform File Integrity Monitoring (FIM) do just this kind of thing. They let you define a sensitive file, perhaps a configuration file or a file containing credit card information, and then let you set up monitoring rules. You should be able to know in real time when an unauthorized user or application changes a file, and define upper and lower limits for alerts.

That’s exactly what our new Alliance LogAgent Suite with Database Monitoring does. OK, it doesn’t actually talk to you. But it speaks the language of your log monitoring solution. Here’s how it sends the alert about Bill:

<118>Mar 9 15:25:14 S10125BA LogAgentDB:[LGADB@0 column_name="SALARY"

column_text="Annual salary" SECURITY_ALERT_upper_limit="yes"

data_type="P" action="Update" data_image="After" value_option="Clear"

previous_value="35000" value="2800000" file_name="HRMASTER"

file_library="HRPROD" file_member="HRMASTER"

timestamp="20120309152514783008" job_name="QPADEV000K" job_user="BILL"

job_number="648169" jrn_seq="81327" jrn_sys_seq="0" user_profile="BILL"

program_name="QDZTD00001" program_library="*OMITTED"

In this case a whitelist of users was associated with the SALARY field in the HR master file. Bill was not on that list, and Alliance LogAgent raised the security alert message. Everything is in the message that you need to work on this potential problem. You know the date and time that Bill made the change. You can see that the program was the IBM DFU program, a file utility that is never used for real work on HR data. And you can see the previous and new values for the salary. And all of this happens in real-time giving you the chance to head-off a possible big problem.

Alliance LogAgent Suite with Database Monitoring is an affordable and easy-to-deploy solution. It will help you implement a FIM solution to meet PCI DSS and other compliance regulations. Listen to our podcast "File Integrity Monitoring on the IBM i" to learn more about selectively monitoring data access and change activity at the column or field level.

Patrick

Download Trial: Alliance LogAgent Suite Download a free trial of Alliance LogAgent Suite, our file integrity monitoring Solution. Click Here to Download Now

Many compliance regulations require that you monitor critical system files, application configuration files, and sensitive file content for unauthorized changes. In the PCI Data Security Standard (PCI DSS) which applies to everyone who accepts credit and payment cards, here is what Section 11.5 says:

11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Other compliance regulations also require this type of integrity monitoring and they are reflecting the security best practices in NIST’s Special Publication 800-53. Here are a couple of extracts on integrity monitoring from that guidance:

Section 3.4 – Monitoring Security Controls: Significant changes to the configuration of the information system through the removal or addition of new or upgraded hardware, software, or firmware or changes in the operational environment potentially degrade the security state of the system.

And:

SI-7 Software and Information Integrity

Control: The information system detects unauthorized changes to software and information.

Supplemental Guidance: The organization employs integrity verification applications on the information system to look for evidence of information tampering, errors, and omissions. The organization employs good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts.

What do IBM i (iSeries, AS/400) customers need to do to meet these file integrity monitoring compliance regulations? Here are the steps you should take to meet file integrity monitoring requirements:

• Identify, inventory, and monitor the application configuration files that control important security controls. You may need to work with your third-party software suppliers to know which files contain this information.
• Identify, inventory, and monitor the application database files that contain sensitive information. This would include files that have credit card numbers, social security numbers, and other Personally Identifiable Information (PII).
• Configure and enable system monitoring of changes to system values and network attributes. This involves setting up the system security journal QAUDJRN and initiating monitoring. IBM provides guidance on how to do this.
• Collect and transfer file integrity security events to an organization-wide security monitoring and alerting system. This will be a Security Information and Event Monitoring (SIEM) solution that you deploy in-house or through a Managed Security Services Provider (MSSP). It is impossible for humans to properly monitor file integrity events and this is the province of SIEM solutions.

Implementing all of the components of a file integrity monitoring system on the IBM i system is a huge task. Almost all IBM i customers will turn to off-the-shelf solutions to help them achieve compliance with data security regulations.

Our Alliance LogAgent Suite provides the full set of functions and capabilities you need to meet compliance regulations for file integrity monitoring. It monitors system configuration changes through the QAUDJRN security journal and from system history file QHST. It monitors and reports changes to your application configuration files. It monitors and reports changes to sensitive data such as credit card numbers, social security numbers, or any field you want to monitor. It applies user and application whitelists to minimize the volume of events.  And it securely reports events to a SIEM solution using industry standard formats. It is affordable, easy to deploy, and is easy on system resources.  We encourage you to try a free 30-day evaluation of our file integrity monitoring solution and see for yourself. We can get you up and running within an hour.

Because file integrity monitoring is crucial to your security posture, I will be talking more about the functions and features of Alliance LogAgent Suite for the IBM i platform in future posts.

Patrick

Podcast: Better System Logging Download the podcast "System Logging on the IBM i - How to Do It Better." Click Here to Download Now

Townsend Security’s latest version of Alliance LogAgent, Alliance LogAgent Suite, will allow IBM i log agent administrators to stay one step ahead of security compliance regulations. In a recent podcast, Patrick Townsend, Founder & CEO, discussed this enhancement:

Our major enhancement to Alliance LogAgent allows system logging administrators to extend visibility right down to the field and column level, record-by-record, in their databases. With the new features you’ll have the ability to monitor any particular file in order to recognize exactly which fields were viewed or changed by a particular user. The ability to do this is a soon-to-be critical area of compliance. Customers will need to be able to do forensics on access to particular fields in particular records.

European companies have some additional log management compliance regulations that we don’t yet experience in the United States, but these regulations are coming towards us. Advanced system logging on the IBM i is becoming more important than ever. With Alliance LogAgent Suite we give you the option to log the before and after versions of a particular field so you can see if there was a change made and what it was. If the field contains sensitive data, we can also log a secure hashed value of that field in order to keep the field completely secure.

Alliance LogAgent Suite will also let you create white lists of inclusion (people who should be able to see values in the database) and exclusion (who should not be able to see them). We can then log those unauthorized accesses, so that log management administrators don’t need to depend on native object authority on the IBM i. Instead you’ll see record-by-record, column-by-column level access and who has seen data they should or shouldn’t have seen.

We’ll also let you select floor and ceiling values, so that when a value goes over or under a certain amount, Alliance LogAgent Suite will alert you and record the event in a log. For example, a systems administrator at a bank could establish a wire transfer ceiling of $10,000 so that if an employee tried to wire $1 million to Aruba, LogAgent Suite would detect this report this large transfer attempt immediately.

These new features in Alliance LogAgent Suite will substantially improve the security posture of a company using system logging the IBM i. The implementation of LogAgent suite is easier than ever and will help to prepare IBM i users for the evolution of new compliance regulations.

Download a free 30-day evaluation of Alliance LogAgent Suite to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  In under an hour, you can start collecting all system logs on your IBM i (AS/400) and converting them to syslog or CEF format for any SIEM or log collection server.