Posted by Paul Taylor on Wed, May 16, 2012 @ 03:45 PM
In today's interconnected world, your company's reputation can be won or lost on the strength of your data security. Almost every day, you can read news reports about data breaches that expose confidential customer information. Credit card numbers, banking information, even home addresses and telephone numbers have been exposed by unscrupulous hackers and inattentive employees. Social network and online news outlets quickly spread the word of any potential breaches, exposing your company to public scrutiny and ridicule. Data breaches also expose your business to legal liability and sanctions. Once the data is out, there is no putting the cat back into the bag. You will be forced to explain what precautions you've taken, and why they didn't work. If you fail to meet any federal, state, or industry standards for data security, you could find yourself in a very precarious position.
Data breaches come about in a variety of ways. Many highly publicized exposures are the result of direct efforts by hackers. These hackers can have a variety of motivations, from purely financial to personal ideology, but the end result for your company is the same. If they get in, and get useful information, your bottom line and reputation can suffer irreparable harm.
Another infamous, but no less harmful, form of data loss can be caused by employee negligence. Lost laptops, misplaced flash drives, and low-quality passwords can all lead to data loss. A common thief who steals a notebook computer from a car may find himself in possession of your most sensitive data. Even though these exposures can't be directly attributed to any failure on your part, your business will still be responsible for a breach notification.
To adequately protect your data from all conceivable threats, you need to be protecting it with encryption and key management, which goes farther than just access prevention. A dedicated hacker or inattentive employee can circumvent the most secure firewall and bypass the most stringent security protocols. The only way to make sure your data is truly secure is to make sure that, no matter where it's located, it's useless to unauthorized personnel.
It's almost impossible to ensure that your sensitive data remains where you put it. Whether intentional or accidental, there is always the possibility that sensitive data will be removed from your site. The best defense against harmful data breaches is a comprehensive security protocol that utilizes data. When your data is properly encrypted, compliance regulations state that you aren’t responsible for a breach notification – because there is no useable data!
Townsend Security provides NIST-certified AES encryption for all major enterprise platforms and a FIPS 140-2 certified encryption key management hardware security module (HSM) – technology that will help you avoid a breach notification. There is no better way to securely store data and minimize your exposure.
Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.
Posted by Eppy Thatcher on Fri, May 11, 2012 @ 10:33 AM
Section 10 of PCI DSS requirements v2.0 states the need to track user activities, to be able to detect, prevent or minimize the impact of a data compromise. Because of the mere fact that most every application under the sun produces a log entry for when something goes amiss, you can also use that same log file as a security tool. It can provide a means of tracking and analysis when a possible data breach may be occurring as well as add crucial detail for investigative purposes. Now a smart criminal knows to cover their tracks at the scene of a crime, and they can do this simply by wiping out any log data that may exist. However if you’re capturing these logs in real time and sending them to a third party server, even the most savvy of crooks will be caught red handed.
Our Alliance LogAgent solution helps accomplish that, as well as satisfying parts of section 10 of PCI DSS by being able to capture logs from your IBM i’s audit journal, formatting them and sending them off to a waiting log collection server. We monitor for log entries out of numerous places on the iSeries allowing the user the a level of granularity to choose what log messages to capture and kick over the wall to the waiting log server. It's always a good idea to work hand-in-hand with your PCI auditor to make sure you're collecting all the appropriate events on your system to meet their requirements.
For instance, you'll want to make sure you're collecting AF (Authority Failure Events) events which come from the System Value QAUDLVL. This particular event is triggered by all access failures, such as sign-ons authorization, and job submissions. It also includes incorrect password and user ID attempts from a device. These details can play a crucial role in tracking down details around a possible breach into your system.
As I mentioned, Alliance LogAgent sends these events to a listening collection server or SIEM solution. We work with any SIEM product that is actively listening and waiting for logs to arrive and can accept messages in the RFC 3164 or Common Event format. There are a number of SIEM products available on the market and they help parse the influx of log messages as they arrive, as well as send out notification and alert emails when something suspicious is detected.
Currently, the PCI guidelines don't include transmitting logs over a secure SSL/TLS session (it’s a very, very good idea). However, looking ahead to when this becomes a requirement, you can rest assure that you’re already running software that can meet those needs. LogAgent is already setup to handle secure SSL/TLS transmissions and is one of the reasons it stands apart from the competition. The only change you'll have to make in the configuration of the product when switching over from UDP/TCP to SSL will be to provide an SSL application ID. This is an ID that is associated with a digital certificate that you can create with IBM's Digital Certificate Manager (DCM). Having this secure session in place will ensure that your log message data won't be intercepted on its journey to the collection server.
Download a free 30-day evaluation of Alliance LogAgent Suite and meet Section 10 of PCI DSS. 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.
Posted by Adam Kleinerman on Thu, May 10, 2012 @ 11:33 AM
The security breach involving Global Payments, a US credit card processing company is still in complete disarray months after the breach took place. A little over a month ago, it was reported that a maximum of a staggering 10 million credit card numbers could have been apprehended during a five week period starting in late January. Global Payments reluctantly admitted to being the victims countering with a figure of 1.5 million credit card numbers stolen. While there isn’t any reason why any company should have this happen to them, it is a growing trend to claim a bit of ignorance on the matter, or at least try to redistribute the blame.
When these breaches happen, many business owners and executives are blindsided by the blow. Of course they have security software, and in most cases, if they have it, the word “breach” shouldn’t have any place inside the walls of these businesses. But, as we’ve seen, credit card numbers and other personal information that should be safe, sometimes isn’t. Having strong passwords is the first step an organization should be doing to keep unauthorized individuals from accessing sensitive information.
Make sure that any passwords that you choose to enter are not what as known as “default passwords.” It seems logical enough, but a default password is one of most common flaws in a security system that leads to a breach. Hackers have databases full of default passwords, and those can be typed in at a rapid pace. Some of these include the obvious “1-2-3-4-5” or “a-s-d-f.” Any sequence of characters that in some universe make sense in a logical order should be completely abandoned. Also, birthdays or dates that can be easily discovered should be the last passwords that are selected. It is far better to come up with something so outrageous, and take the extra time to completely type it out then to use simple passwords that are already on databases. Also, use different passwords for different accounts. That way, if one is discovered, the rest are still secure.
Your credit card company should be monitoring all activity on your accounts, so that if anything suspicious is going on, you will be notified about it instantly. You don’t want to be on this list of companies that have allowed breaches, so make sure to be smart about your passwords. If you ever had a tree house and the bully next door successfully guessed “peanut butter” as the password, you would have to, begrudgingly, let him in. But, he probably wouldn’t guess “138927491AsmaraEritrea53211” so taking the smart choice would pay off.
For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person. Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.
Posted by Eppy Thatcher on Mon, May 07, 2012 @ 10:29 AM
The Alliance LogAgent Solution for system logging on the IBM iSeries is able to grab log messages out of a variety of places such as your system's audit journal, (QAUDJRN), your history log (QHST), and system operator messages (QSYSOPR) and format them to either a standardized Syslog format, in this case RFC3164 or Common Event Format (CEF). Once formatted, we pass the messages over to the communications module that handles the transmission of the messages to your waiting log collection server using either the UDP, TCP or SSL/TLS protocol.
LogAgent can send to any collection server that is listening for messages. You simply assign either a remote host or IP address of the waiting server as well as the port number. Ideally you would want a SIEM (like from LogRhythm, Solutionary, or SolarWinds, for example) running on that server to read the messages that are received, sort them and send out alarms to your security team when dubious messages arrive.
A question I am frequently asked is what format should my logs be in to work with my SIEM product? More often than not you'll want to use the Syslog format as it is generally accepted. The RFC3164 format that we use is composed of three parts. The first part is called the PRI, the second part is the HEADER, and the third part is the MSG.
The PRI part is the Priority value and begins the log message. Its value is contained within angled brackets and is either two or three digits in length. It is comprised of the Facility value and the Severity level of the message. The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. (Example: <40> )
The second part of the message is the header which will contain a timestamp, and an indication of the hostname or IP address of the device it originated from. The MSG part will fill out the remainder of the syslog packet and contain the generated message and the text of the message.
Here is a quick sample of a log message in RFC 3164 format.
<118> Apr 18 16:32:58 10.0.1.11 QAUDJRN: [AF@0 event="AF-Authority failure" violation="A-Not authorized to object" actual_type="AF-A" jrn_seq="1001363" timestamp="20120418163258988000" job_name="QPADEV000B" user_name="TESTFORAF" job_number="256937" err_user="TESTFORAF" ip_addr="10.0.1.23" port="55875" action="Undefined(x00)" val_job="QPADEV000B" val_user="TESTFORAF" val_jobno="256937" object="AFTEST" object_library="CUS9242" object_type="*FILE" pgm_name="" pgm_libr="" workstation=""]
If you're using a SIEM such as ArcSight who is expecting logs messages in the Common Event Format (CEF) you can easily switch the formatting from the configuration menu of LogAgent to send in this manner. Much like the RFC 3164 version, the message contains a timestamp and hostname or IP address at the beginning. This is followed by the Extension part of the message and is really a placeholder for additional fields. Some common fields you'll find are CEF version, Device Vendor, Device Product Severity and Signature ID just to name a few.
Example of what a CEF formatted log message looks like.
Feb 29 15:47:25 10.0.1.43 CEF: 0|PATownsend|IBM-QAUDJRN|1.28|1007|CO-Create object|4|msg=CO-Create object act=N-Create of new object actual_type=CO-N jrn_seq=102361 timestamp=20120229154725823000 dproc=ICC suser=MVAGANEK job_number=638012 eff_user=MVAGANEK object=X_BIGNUM object_library=ICAPITST object_type=*MODULE object_attrCLE
It's always a good idea to check with the team managing your log collection server to see what format they are expecting log messages to arrive in. Hopefully having a clearer understanding of what your choices are will help make the task of deploying system logging on your AS/400 smoother and easier to satisfy section 10 of PCI DSS compliance. If you haven't yet, download a free 30-day evaluation of our Alliance LogAgent for IBM i system logging software. Our customers have deployed the solution in under an hour from the time they download it from our website!
Posted by Luke Probasco on Fri, May 04, 2012 @ 10:19 AM
IBM announced recently the end of support date for V5R4. This has prompted many IBM i shops running this older OS to upgrade to a newer release - either V6R1 or V7R1. Traditionally, we have seen that most IBM i administrators upgrade just one release forward. In this particular case, we recommend going to V7R1. Not only is upgrading to V7R1 a fully supported path by IBM, there are security reasons. I recently sat down with Patrick Townsend, Founder & CEO, to discuss IBM i V7R1 and how Townsend Security can help organizations take advantage of FIELDPROC, a new feature that allows companies to encrypt their sensitive data without changing their applications.
You said recently that upgrading your IBM i to V6R1 is a bad idea. Can you explain why?
Security today is more important than it was even two or three years ago. We live in an evolving world around security and organizations of every size - from small companies to global companies - really have been under severe attack. The bad guys are getting much better at what they do and we are faced with highly sophisticated attacks. Even mid-sized companies are now under pressure to protect their data. So we live in a world that is far more sensitive and insecure, and we really have to put more attention on protecting sensitive data.
IBM gave us FIELDPROC in the latest release of the operating system (V7R1), which allows encryption with no application changes. FIELDPROC is really attractive for mid-sized and large customers. It makes the usually very difficult task of encrypting data in our systems much easier. I think that customers who are on older versions of the operating system (V5R4, for example) and who might in the past have just moved up one level, should really move up to V7R1. From a security perspective, it is time to jump a level from V5R3 or V5R4, past V6R1, which would be the next release, to V7R1 and get the benefits of FIELDPROC encryption.
What would an organization need to do to take advantage of FIELDPROC once they upgrade? They still need third-party encryption, right?
Yes, FIELDPROC is the ability to do encryption, but IBM relies on third-party vendors like us to actually provide the encryption libraries and appropriate encryption key management. When customers deploy our FIELDPROC encryption solution on V7R1, they are getting our NIST-certified encryption libraries, as well as seamless integration with Alliance Key Manager, our encryption key manager. Alliance Key Manager is FIPS140-2 certified, and when used with our encryption, lines up perfectly with best practices for encryption across all compliance regulations. Whether it is PCI/DSS with Credit Cards, HIPAA/HITECH in the Healthcare industry, FFIEC in the financial industry, DICAP if you are a civilian company working with the federal government, or if you are a federal agency where it is a mandate that you must have a FIPS140-2 solution.
Our FIELDPROC solution installs into an IBM i customer’s environment, provides both our optimized and certified AES encryption libraries, and the key management you need to be compliant. IBM has done the hard work of making this capability available and we do the work of snapping in proper encryption and key management.
Download a free 30-day evaluation of our Alliance AES/400 encryption, built specifically for IBM i V7R1. Alliance AES/400 is the only NIST-certified FIELDPROC encryption available.
Posted by Patrick Townsend on Thu, May 03, 2012 @ 09:42 AM
I am on a new kick to share some security resources with you that I’ve found valuable over the years. I am not following any particular order or ranking people and resources by importance: I’m just going to do this as the mood strikes me.
Let me introduce you to Chris Evans and his blog.
Chris works for Google, he’s a software and security geek, and is an independent sort. A lot of his work is technically deep, which is great for those of us who enjoy that sort of thing. But I also really like his world view.
Chris has a hacker’s mentality (in the good sense) and his values are lined up with making the world a better and safer place. He doesn’t avoid talking about his own mistakes, and believes that more information about security problems makes the world safer as it gives people the information they need to protect themselves, and it helps developers make their solutions better. He also provides a lot of just plain good advice that anyone can use.
One example is a recent blog on web browser security. The blog combines some technical information, but it also gives you information about how to think about web browser security, and why some web browsers are better than others.
He also makes an interesting statement about browser security that I think has corollaries that apply to anyone writing software that needs to be safe. Chris says:
“The security of a given browser is dominated by how much effort it puts into other peoples' problems.”
For those of us who write business applications and security software, I would put it this way:
"In addition to everything else you do to make your solution more secure, you have to include other people’s problems in the scope of your thinking, including the unexpected ways they might use your solution."
Enjoy.
Patrick
Posted by Adam Kleinerman on Mon, Apr 30, 2012 @ 12:44 PM
Download the white paper "Achieve Safe-Harbor Status from HITECH Act Breach Notification" to learn more about encyption and key management best practices.
Click Here to Download Now
|
An alarming number of security breaches have occurred in the last decade victimizing families of military personnel, who belong to TRICARE. Since the fall of 2009, over 400 breaches have occurred. At least 500 people have been directly affected and another 50,000 smaller scale breaches have been reported to the government. The community of Palo Alto, California was hit closest to home, when over 20,000 names of emergency room patients were available on an online public forum before the list was discovered by authorities. For several months, all these people were susceptible to a profusion of afflictions such as identity theft, credit card fraud or fraud against Medicare and Medicaid programs. Just one move can financially ruin a family.
One major cause of the breach was that security tapes were stolen from the car of a TRICARE employee, and these backup tapes had people’s private information on them. The big problem of course, was that after these tapes were stolen, the information was readily available to pirates. Any encryption didn’t exist, so the information was just there for the taking. If the data on these tapes was encrypted, TRICARE wouldn’t have to worry about the tapes being stolen and you wouldn’t be hearing about this problem – HIPAA grants a breach notification safe harbor to organizations who are encrypting their sensitive data.
If you aren’t familiar with HIPAA (The Health Insurance Portability and Accountability Act), it was established in 1996 and its main focus is to protect the rights to health insurance for families when the wage earner was to change or lose a job. It’s second objective focuses on standards for electronic health care transactions. With HIPAA, there are legal regulations that the government has put in place to protect our Personal Health Information (PHI). While there is no encryption requirement, it is strongly considered a best practice.
The largest concern when a story like this breaks is for the victims. The Federal Trade Commission (FTC) has published a few tips for individuals who are affected from the TRICARE breach:
- Don’t willingly give out personal information over the phone unless you know exactly whom you are dealing with.
- Increase the frequency at which you check over your medical records to make sure nothing looks out of the ordinary.
- Any fraudulent report you notice should be reported to the police immediately.
The TRICARE breach should be an example of why encryption should be mandatory for organizations that deal with PHI. Not only does it protect the privacy of your customers, when a breach does happen, HIPAA grants you a breach notification safe harbor.
Learn more about encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".
Posted by Luke Probasco on Fri, Apr 27, 2012 @ 02:55 PM
We have been talking a lot recently about the benefits of FIELDPROC as being the main reason to upgrade to IBM i 7.1 (V7R1). Since IBM recently announced the end of support date for IBM i 5.4 (V5R4), we are seeing many shops planning upgrade projects and discussing whether to move their systems to V6R1 or V7R1. Without a doubt, V7R1 is the correct choice – it is even a fully supported V5R4 upgrade path from IBM. So, aside from FIELDPROC, what other security reason is there to skip V6R1? Simply, the updates to Secure Shell sFTP. I recently sat down with Patrick Townsend, Founder & CEO, to discuss how these updates can help further secure your data.
Another key security feature in V7R1 is a new version of the Secure Shell sFTP application. How is it different and better?
IBM has been making Open SSH available on the IBM i for quite some time. We had the ability to install it back on V5R3. It has become a very popular secure file transfer mechanism, especially for financial institutions. We are seeing large commercial banks across the board moving to Secure Shell sFTP for encrypted file transfers. IBM brings the latest version of SSH to each new release and V7R1 is no exception. The latest version has picked up new security features since the V5R4 release, some of which are quite important. I think moving to V7R1 and getting the latest version of Secure File Transfer (sFTP) is really important. We are learning from security professionals at the NSA, NIST, and SANS just how important it is to make sure the patches to our systems are up-to-date. So again, having the latest version of any security technology is imperative, which re-emphasizes skipping V6R1 when upgrading from V5R4.
Download our podcast “IBM i Security: Skip V6R1 and Upgrade to V7R1” for more information on the security reasons that you should go straight to V7R1. Additionally, we will discuss how Townsend Security can help you take advantage of FIELDPROC, a new addition to V7R1, which allows companies to encrypt their sensitive data without changing their applications.
Posted by Patrick Townsend on Wed, Apr 25, 2012 @ 07:30 PM
Really successful technology partnerships are hard to achieve and therefore are rare. There are so many potential pitfalls in this type of partnership that include conflicting goals, changing market conditions, and on and on. That’s why I am particularly pleased with our partnership with Symantec on the IBM Enterprise platform versions of PGP encryption. This technology partnership now spans more than a decade and several mergers and acquisitions. The level of trust and integration between Townsend Security and Symantec has just gotten better over time, and our IBM i (AS/400, iSeries) customers and IBM System z Mainframe customers have benefited.
One thing that has confused our customers is where they should go to get information and to license PGP Command Line for the IBM Enterprise platforms.
It can be hard to negotiate the Symantec web site to locate the PGP Command Line products. And calling Symantec’s 800 number can be downright disorienting. Symantec provides a large number of security and system management products, and finding the PGP products can be hard. Of course, you can always go to the old PGP web site, and it will re-direct you to the Symantec site. That helps, but not many people know about that little short-cut.
Here is a better idea – you can just go directly to the Townsend Security web site and you will be starting in the right place. Just select the PGP option under products.
IBM System z customers will be glad to know that we’ve partnered with Software Diversified Systems (SDS) to provide sales management and customer support that meets the Mainframe customer’s expectations of knowledge and experience with that platform. Just select the PGP Command Line product under their Products link. SDS and their worldwide partner network have really provided the Mainframe experience and depth of knowledge that customers expect. That’s also been a great partnership.
If you are an IBM Enterprise platform customer, save yourself some time and trouble. Go straight to Townsend Security or SDS for your PGP Command Line encryption solutions.
Patrick
Posted by Paul Taylor on Mon, Apr 23, 2012 @ 12:17 PM
Download the white paper "Achieve Safe-Harbor Status from HITECH Act Breach Notification" to learn more about encyption and key management best practices.
Click Here to Download Now
|
Data breaches in the medical industry are occurring at a greater rate now than ever before. Emory Healthcare recently experienced a significant PHI (Private Health Information) breach and has announced that approximately 315,000 medical records have gone missing.
Included among those records are those of the chief executive officer of the hospital, who has tried to calm public outcry by noting that, to his knowledge, none of the personal information had been used in attempts at identity theft. But the loss is significant because it violates patient privacy rights and could have been prevented if Emory Healthcare was properly encrypting the data.
In total, 10 backup discs for the hospital system have been gone from their storage facilities since mid-February. Within each record was a wealth of information, including patient names, Social Security numbers, and surgical procedures and dates.
Emory has said that it had strong policies in place to protect the personal information of patients. It also attributed the cause of the theft to an honest mistake made by an employee. However, HIPAA states that an organization is responsible for a breach notification regardless of whether the data was “hacked” or just lost.
As part of their remediation plan, Emory is providing free resources to help patients combat and prevent identity theft. While Emory has said it is revisiting its policies and procedures to better protect patient information, it's unclear if they are making systemic changes that could protect patients even if data is stolen in the future. Regardless of what security measures they take to better protect patient information, the only way Emory -- or any other medical facility -- can guarantee patient information is safe and avoid a breach notification will be to protect it with encryption and key management.
If you are not familiar, AES encryption (the standard for Data at Rest) is a form of data protection that uses an algorithm to transform information in a way that makes it unreadable by other entities. AES encryption that is certified by the National Institute of Standards and Technology (NIST) is used to attain the highest levels of security. Encryption can't be ignored as a security measure.
The second part of the encryption process is managing the encryption key. Only by knowing the encryption key can that information be unlocked and read. When data such as patient information is encrypted with proper key management, it is safe from being compromised by hackers or other entities that steal the information. Without the encryption key, the data is worthless.
With breaches in the healthcare industry up 32% in the last year, it is more important than ever to be encrypting PHI. Data breaches have dollars lost directly tied to each record lost. Download our white paper “Achieve Safe-Harbor Status from HIPAA/HITECH Breach Notification” to learn more about how your organization can protect PHI with encryption and key management.