Townsend Security Data Privacy Blog

As everyone is now aware the Federal Bureau of Investigation has acquired a court order requiring that Apple create a back-door to the iPhone that would allow bypassing the protection provided by strong encryption.

Tim Cook, the CEO of Apple, has strenuously objected to this order on the grounds that providing a back-door will make everyone less safe. You can read Apple’s reasoning and response here.

Like Apple, here at Townsend Security we create encryption products that do not have back-doors or ways to bypass security. We do not hold any encryption keys that would allow us to have access to customer information, and we also believe that this makes our customers that much safer. This approach is strongly supported by the security and cryptographic communities who have noted that law enforcement agencies have many other effective tools to help them prevent crimes.

I am in complete agreement with Tim Cook’s response and support his efforts to quash this initiative on the part of the FBI. Like Tim, we are appalled at the violence that took place in San Bernardino. I grew up close by and have family in the area. I believe that I can understand the fear that people feel. But we are all immensely safer when the technology products we use implement the best possible security.

I also have a great respect and admiration for local, state, and federal law enforcement. They are tasked with an unbelievably difficult and often dangerous job. They work hard every day to keep us safe and I know they want to have all of the tools they need to accomplish that job. In the case of encryption back-doors, we should have a dialogue as a people before handing this tool to law enforcement. The time for that dialogue is now.

It should be clear to everyone that providing back-doors that circumvent strong encryption protections will be the immediate target of cyber-criminals and state sponsored hackers. The risk to to those struggling for freedom against tyrannical regimes is truly frightening. Further, there will be an immediate loss of trust in US products that implement such back-doors. This is not good for Apple’s business or any US business that relies on the trust of its customers across the world. The damage to US commercial interests would certainly be quite large.

There is nothing certain about life and we all must face our many fears. Individually and as a people we do better when we face life from a place of courage and confidence. I strongly support Apple in their efforts to stop this unfortunate attempt to weaken their products and therefore the safety of their customers.

Patrick Townsend

"This article was originally posted on CorreLog's blog. CorreLog is a high performance correlation, search and log management company and Townsend Security partner."

That’s the thing about myths: they’re only partly true.

Yes, File Integrity Monitoring (FIM) has been part of the distributed computing landscape for a few years now. And yes, real-time enterprise security monitoring is harder to accomplish in a mainframe environment. But as attacks become more sophisticated, FIM needs to be a key component of the entire network, including your mainframe.

There’s a well-known software vendor that has an antivirus “sandbox” that is used to explode viruses in much like a police bomb squad would do with a suspicious package at a crime scene. After said software suspicious package is exploded, the software vendor adds the footprint to its database and the next time that package comes through the network, if it was clean the first time, it gets let through; if not, it’s blocked.

The tricky part of this story is that hackers are now smart enough to detect when they are about to be put into one of these sandboxes. When the A/V program starts to sandbox, the suspected virus, the virus goes into a cloaking mode to evade the sandbox. The A/V tool gives the executable a passing grade and there you have it; virus enters network.

Chances are you won’t have to worry about mainframe viruses anytime soon (though anything is possible these days). The point of the story here is the sophistication at which hackers are attempting to compromise corporate and government IP. For it is a much faster path to market to steal technology than it is to develop it. The same could be said for nation-state attackers who lack the subject matter expertise to develop their own IP, be it leading-edge technologies or schematics for nuclear reactors.

Having a Security Information & Even Management (SIEM) system with Data Loss Prevention (DLP), supported with antivirus detection and Identity/Access Management Systems (IAMS), gives you a fighting chance. Having a means for File Integrity Monitoring, especially on z/OS where the most strategic global banking and government data resides, further fortifies your security strategy and arms your information security team with another data point to determine the level of risk to your data.

FIM protocols are well established on the distributed side, but if you were to ask a mainframe sysprog (system programmer) if they have some type of FIM protocol in place for z/OS, they would look at you like you were speaking a foreign language. FIM on mainframe, or MFIM, must be addressed, at a minimum, to facilitate the Payment Card Industry Data Security Standard (PCI DSS) requirements 10.5.5; 10.6.1; 11.5; and 12.10.5. The standard and corresponding requirements can be found here, and we should note that this blog is not a review of the requirements. The takeaway in today’s blog is to understand that FIM is important to the Payment Card Industry Security Standards Council (and HIPAA, and FISMA, and IRS Pub. 1075, and others). PCI DSS lists FIM in four different requirements and it does not say “do this just on your Windows and UNIX systems.” The requirement says do this for all systems in your datacenter.

The key to MFIM is to look at the mainframe counterparts to the Microsoft Windows install folder. One of these, SYS1.PARMLIB, or the PARMLIB concatenation, is the most important set of datasets on z/OS, listing system parameter values used by nearly every component of z/OS. You can’t just take a checksum "snapshot" of these files, as a SIEM would do with distributed systems, because they’re simply too big for that to be a practical approach.

The details of tracking mainframe event messages are far too many to get into here. Essentially, you need a way of connecting the mainframe and your distributed SIEM system for notifications in real time, and you need a software tool that will convert mainframe events to a distributed event log format — RFC 3264 syslog protocol — so your SIEM system can interpret the data as actionable information.

You can learn more about MFIM and its relevance to PCI DSS from CorreLog’s complementary whitepaper titled “InfoSec Myths Debunked: FIM is only for Windows/UNIX.”

When the weather outside is frightful, keep a watchful eye on those tracks in the snow!

I used to love looking out the sliding glass doors at my parents deck when it would snow. I would rush to the cold glass first thing in the morning to see just who had been out and about. It was always exciting to see what footprints the various critters had left behind from the night before. Strange topic for a tech blog to be sure, however this memory always pops to the front of my mind when discussing system logging, log collectors, and their ever-important counterpart, SIEM solutions. The one question I hear most in our support department is “I’ve got a log collector do I really need a SIEM?” Well let’s think about that and compare log collection and monitoring to a fresh snowfall.

Envision the log collector as a blanket of snow over a deck. The deck in this example represents your database, the footprints are the events. Just one database server can generate millions of events in a day. With that kind of traffic your blanket of snow is going to become packed ice very quickly. You wouldn’t be able to pick out and clearly identify any one specific footprint from that mess. The shear amount of events generated by the average system makes detecting an anomalous event a logistical nightmare for a human observer. So simply having a good log collector is great, but it is only half of the equation. You have to be able to identify events and act on the information gathered, preferably in real-time.

One morning, after it had snowed I was up early peering out at the snow cover when I noticed boot prints near the garage. This was unusual as we lived in a relatively rural area. I told my parents what I’d seen, and tried to show them, but the snow was starting to melt. So the evidence that I had seen was rapidly being lost to time and inactivity. My parents brushed off my concern and went on with their day, opting to forego any further “analysis”. The following morning they awoke to an open garage door and a missing car.

This scenario is strikingly similar to how cyber criminals operate. Evidence of a breach is often left long before any data is actually stolen. It can take weeks and, in some cases, months for an intruder to find the data they want and take it. Early detection has spelled the end of many data theft attempts. Unusual events like someone accessing the system from an unfamiliar location, or an unexpected access of a sensitive file can be identified before data goes missing. All of those events show up in the system logs, but if you aren’t doing anything with the information, then you are making it easy for criminals to get what they came for. When properly deployed, and monitored in real-time, a SIEM can be your strongest weapon in actively preventing breaches.

Proper set-up can appear to be daunting because the system logging solution needs to be able to understand the events being received. The SIEM can’t correlate data to recognize patterns, and identify suspicious activity if the log collector is sending events in a language the SIEM doesn’t understand. In a perfect scenario SIEMs and log collectors would work together to create an “out of the box “ solution. Townsend Security has recently worked with IBM to enhance our system logging solution to include support for IBM Security QRadar.  Alliance LogAgent for IBM QRadar can now send events in IBMs “Log Event Extended Format” or LEEF to the QRadar SIEM. Because we worked directly with the IBM team for the QRadar Device Support Module (DSM) definitions, you just need to pull the latest DSM definitions from IBM to get started. Though it’s similar to other log formats like syslog, QRadar can sort and use the information received without any major set up.  This means that instead of logging tons of unreadable, unsorted events, you can query the SIEM to find something specific like a log on, or file change - which, going back to the original analogy, can help you find the boot prints in the snow!

Alliance LogAgent for IBM QRadar works seamlessly with IBM Security QRadar to give you the real-time, active monitoring tools you need to be proactive when dealing with a potential data breach. For more information, request this white paper on Making Security Better for the IBM i and IBM QRadar:

Understanding the basics can help you avoid problems! 

As enterprise customers deploy data security solutions to meet various compliance regulations (PCI DSS, HIPAA, etc.), they are frequently surprised by the performance impacts of encryption. Inadequate preparation in an encryption project can lead to increased costs, delayed (or even failed) projects, inability to meet compliance requirements, and even exposure in the event of a data breach.

By its very nature, encryption and decryption are resource intensive processes. Enterprise customers can be surprised to discover that encryption from one vendor can perform very differently than the very same encryption from another vendor. While the various vendor solutions accomplish the same tasks, they vary greatly in how efficiently they do these tasks. The differences can vary by a factor of 100 or greater! This can have a large impact on business applications that perform encryption and decryption tasks. One vendor’s solution may encrypt a data in 10 minutes, and another vendor’s solution may take 10 hours to perform the same task!

Avoid surprises, ask for performance metrics:

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server? Optimizing software for performance is a complex task and usually involves specialized technical talent and some experimentation with different computational techniques. Unless an encryption vendor is deeply committed and invested in encryption technologies, they may not make performance enhancements to their applications.

Create your own proof-of-concept applications that measure encryption and decryption performance in your application environment. Be sure to measure how well the encryption solution performs under your current transaction loads, as well as anticipated future transaction loads. A good rule of thumb is to be sure you can handle three times your current encryption volume. This will position you for increased loads due to unexpected changes in the market, or an acquisition of another company. It also insures that you are seeing real-life performance metrics, and not just the vendor’s marketing message.

Avoid hidden costs, ask for pricing calculations:

Ask your purchasing and accounting departments to include performance upgrade costs in the pricing calculation during vendor evaluation. Be sure these costs include any increases in software license fees. If an encryption solution consumes one third of the CPU processing power of a server, you might want to include the cost of upgrading to a processor twice as powerful as the one you have. Working these costs in during the product evaluation phase can provide a more realistic view of the actual cost of a vendor encryption solution. Upgrading hardware can lead to unexpected additional software costs. Some software vendors license their solutions to the number of processors, or speed of the processors, in your server. Upgrading hardware to solve a performance problem can result in increased software license fees.

Avoid red flags, not all AES encryption solutions are the same:

Some encryption solutions use “shadow files” (files external to your application) to store encrypted data. The use of shadow files normally indicates that the vendor has an incomplete implementation of the AES encryption suite, or that the system architecture is limited in some way. The use of shadow files can impose severe performance penalties. In order to perform an encryption or decryption task an addition file read or write is required which essentially doubles the file activity. This may also increase processor loads as your application mirrors the data to a hot backup system. You will want to be very careful in measuring the performance impacts of encryption solutions that use shadow files.

If an encryption vendor will not provide you with a fully functional evaluation of their solution, this represents a clear warning signal. Your application environment is unique and you will need to be able to evaluate the impact of encryption in your environment with a limited test. A vendor who refuses to provide you with a clear method of evaluating the performance of their solution may not have your best interests in mind.

Avoid frustrations, take a test drive with us:

Despite an organization’s best efforts, data will get out. The best way to secure sensitive information is with strong encryption that is NIST compliant and FIPS 140-2 compliant key management that meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws. For a more technical look at AES encryption, including FieldProc exit points and POWER8 on-board encryption, check out this blog by Patrick Townsend, Founder and CEO of Townsend Security: How Does IBM i FieldProc Encryption Affect Performance?

Our proven AES encryption solution encrypts data 115x times faster than the competition. But don’t just take our word for it, we provide a fully functional evaluation!  Request a free 30-day trial (full version) of our popular Alliance AES Encryption and see for yourself.

When our customers consider deploying Alliance LogAgent for IBM QRadar on their IBM i (AS/400, iSeries) servers, they often have a number of questions about how the application works. Here are a few of the common questions we encounter:

Can I monitor security events collected in the IBM security audit journal QAUDJRN?
Yes, all of the events in the QAUDJRN security journal are processed by Alliance LogAgent and assigned a severity level that is recognized by QRadar. Be aware that the security event information collected in the QAUDJRN security audit journal depend on system values that you define. Minimally you should configure your IBM i server to collect all *SECURITY level events. See the Alliance LogAgent documentation for more information.

Can I monitor user messages in the security audit journal QAUDJRN?
Yes, Alliance LogAgent for IBM QRadar processes all user-defined events in the security audit journal. If you wish to write user-defined events to QAUDJRN you should be aware of the data format defined for QRadar called the Log Event Extended Format, or LEEF. The LEEF format documentation is available from IBM.

Why is Alliance LogAgent for IBM QRadar better than what I already have?
Alliance LogAgent for IBM QRadar has several security advantages over the native AS/400 DSM definition in QRadar. The most important is that Alliance LogAgent processes security events in real time. This means that QRadar can perform event correlation and alerting more effectively. There is less chance that a security breach will result in the loss of data. Additionally, Alliance LogAgent provides more information for security events. For example, when a user profile is changed all of the granted authorities are reported to QRadar, not just the summary information. Lastly, Alliance LogAgent collects information from a variety of sources including IBM i Exit Points, the system message file QHST, the system operator’s message queue, and user defined messages via a data queue. For all of these reasons Alliance LogAgent for IBM QRadar will improve your IBM i security.

Do I have to make any changes to QRadar?
No, you just need to pull the latest QRadar Device Support Module (DSM) definitions from IBM and you are ready to use Alliance LogAgent for IBM QRadar. If you are automatically updating your DSM definitions you probably already have the DSM support you need. Townsend Security worked with the IBM QRadar team for the DSM definitions. You do not need to do any manual work for IBM QRadar to recognize and process IBM i security events transmitted by Alliance LogAgent for IBM QRadar.

Is Alliance LogAgent for IBM QRadar certified by IBM?
Yes, Townsend Security worked directly with the IBM Security QRadar technical team to certify the security events transmitted by Alliance LogAgent. Out of the box the QRadar SIEM will recognize and process events sent by Alliance LogAgent for IBM QRadar. Townsend Security is validated to the Ready For IBM Security Information program.

What is the performance impact?
Alliance LogAgent for IBM QRadar runs as a low priority batch job on the IBM i platform and will have minimal impact on CPU and other resources. The application uses normal IBM APIs for security event information and does not bypass normal application performance controls. You should not notice any significant impact on interactive user jobs or system resources.

Can I filter messages that are sent to QRadar?
Yes, Alliance LogAgent for IBM QRadar provides several ways to filter messages sent to IBM QRadar including:

• Which QAUDJRN events are reported
• Which QAUDJRN user events are reported
• Which System Values are reported
• Which libraries and objects are included or excluded
• Which IFS directories and files are included or excluded
• Which user profiles are excluded.
• Which IBM i Exit Points are monitored
• Which files and tables are monitored at the field level

As you can see you have many options for filtering which events are transmitted to IBM QRadar.

How much storage does Alliance LogAgent use, and will I need to add storage?
Alliance LogAgent does not make any temporary or permanent copies of security information and will not impact your storage utilization. The only storage you need is for the Alliance LogAgent program objects (about 100 Megabytes) and you will not need to add additional storage.

How are security events transmitted to QRadar, and will I need third party software for this?
Alliance LogAgent provides the communications applications as a part of the base product and you will not need any third party software.

Can I monitor exit points like FTP?
Yes, Alliance LogAgent monitors the FTP exit point and several other critical exit points provided by IBM. These include the exit points for remote data queues, SQL (including ODBC), DB2, FTP and many others. Please contact Townsend Security if you have questions about a specific exit point. New Exit Point monitors are added on a periodic basis.

Can I monitor messages in the system history file (QHST)?
Yes, Alliance LogAgent for IBM QRadar can monitor messages in the QHST system history files. It automatically detects new QHST files created by the operating system and processes messages in near real time.

Can I monitor changes to database files at the field level?
Yes, Alliance LogAgent for IBM QRadar includes a license for the File Integrity Monitoring module. This gives you the ability to monitor access to one or more fields in any database file. There is no limit to the number of fields or files that you can monitor. Monitoring also includes processing file open and close requests so that you have a full picture of user access to a file.

Can I my RPG and CL applications write messages to QRadar?
Yes, Alliance LogAgent can monitor one or more user data queues and transmit messages to QRadar. Your application can write the important security information to the data queue and Alliance LogAgent will add the QRadar headers, convert to the ASCII character set, and transmit the event to QRadar in the appropriate format. There is no limit to the number of data queues you can define or the number of messages.

We use Splunk for log collection, can we use IBM QRadar at the same time?
Yes, many customers use both Splunk and QRadar at the same time. You will find information in the IBM and Splunk documentation on how to implement these solutions together. It is recommended that you send information to QRadar in the native Log Event Extended Format (LEEF) first, and then forward the information to Splunk. This will give you the best security implementation.

How is Alliance LogAgent for IBM QRadar licensed?
Alliance LogAgent for IBM QRadar is licensed on a Logical Partition (LPAR) basis at a flat fee per LPAR. Multiple license discounts are available. Please contact Townsend Security for pricing and support options.

I am using a different SIEM solution, can I use Alliance LogAgent?
Yes, Alliance LogAgent works with all major SIEM solutions including, but not limited to, LogRhythm, Alert Logic, AlienVault, Splunk, McAfee and managed service providers like Dell SecureWorks, NTT/Solutionary and others. If you decide to upgrade to IBM Security QRadar you can easily upgrade to Alliance LogAgent for IBM QRadar.

I need help installing IBM Security QRadar, can you help us?
Townsend Security provides no-charge support for installation and configuration of Alliance LogAgent for IBM QRadar on your IBM i server. If you need assistance with installing, evaluating and using IBM Security QRadar we will provide you with an introduction to a certified IBM QRadar partner company.

Can I try Alliance LogAgent for IBM QRadar on my IBM i server?
Yes. Alliance LogAgent for IBM QRadar can be downloaded and installed on your IBM i server at no charge. During the evaluation period the solution is fully functional and you can integrate it with IBM Security QRadar at no charge for the Townsend Security software (IBM QRadar EPS charges may apply).

How do I get started with Alliance LogAgent for IBM QRadar?
Once you request an evaluation of Alliance LogAgent for IBM QRadar you will receive information on how to download the software and install it on your IBM i server. The Townsend Security customer support team will provide you with training and support at no charge.

If you have any other questions about Alliance LogAgent for IBM QRadar, or other Townsend Security solutions, please contact us.

Collecting and Monitoring Real-time IBM i Security Events with Alliance LogAgent for IBM QRadar

Because the IBM i (AS/400, iSeries) can handle multiple applications, it doesn’t log information like other systems do. The IBM i collects logs simultaneously from multiple sources and deals with large volumes: Up to 3,500 events per second…250 Million events per day!  The essence of good log security is externalizing the systems logs and collecting them in a central repository, which helps remove the risk of tampering. Close monitoring of system logs can help you detect a breach before it happens, it can be a requirement for compliance with security regulations, and it can be a very difficult, inefficient, and cumbersome process.

For years, our Alliance LogAgent solution has been helping businesses using the IBM i to collect logs from the QAUDJRN security journal, convert them to common syslog formats and then transmit to a central log server or SIEM product for collection, analysis, and alert management. Now, with Alliance LogAgent for IBM QRadar, deeper threat intelligence and security insights can be gained in real-time.

For example, having chosen IBM Security’s QRadar SIEM, the security team at Boyd Gaming needed a solution to collect IBM i security and application logs into a coherent strategy for log collection, analysis and alert management. Before they started using Alliance LogAgent for IBM QRadar, Boyd Gaming used a Device Support Module (DSM) that made copies of their security journal and sent them out over FTP to a server, where QRadar would go grab them – a very cumbersome and inefficient process. By implementing Alliance LogAgent for IBM QRadar, they brought their IBM i platform into a common strategy for log consolidation and analysis with the security events from other servers.

“Alliance LogAgent for IBM QRadar does exactly what it needs to do. It was built for the IBM i and gives you the data you need,” said Anthony Johnson, IT Security Engineer, Boyd Gaming. “Knowing that Townsend Security worked with IBM made Alliance LogAgent for IBM QRadar an easy choice. By being able collect all security events and convert them to the IBM Log Event Extended Format (LEEF) made a seamless deployment.”

For Boyd Gaming, getting started was very simple. With 15 installations of Alliance LogAgent for IBM QRadar, it only took one hour for them to get them to set up, configured, and begin collecting logs from their IBM i platform.

“Alliance LogAgent for IBM QRadar fits the bill for everything. It is very simple to set up, minimal maintenance, and once you set it, you never have to make any adjustments – set it and forget it,” finished Johnson.

Not only does IBM Security QRadar perform real-time monitoring of events across the Enterprise, it learns from the events over time in order to recognize normal patterns, detect anomalies, and better identify attacks and breaches. Combined with this intelligent platform IBM Security QRadar provides a broad set of compliance reports that are ready to use. Townsend Security’s Alliance LogAgent for IBM QRadar helps IBM i customers realize the full benefits of the IBM QRadar Security Intelligence solution.

For more detail, please read the whole case study on Boyd Gaming:

Now it’s time to take the next step and improve your IBM i security.

Take a victory lap, you deserve it!

You deployed one of the best security applications to help protect your IBM i data - IBM Security QRadar. As a Gartner Magic Quadrant leader in SIEM the QRadar solution is proving a valuable part of your company's’ security strategy. IBM QRadar is easy to deploy, easy to use, easy to manage, and automatically learns about your environment to get better over time. Actively monitoring your network, applications and systems is one of the Top 10 security controls, and QRadar is one of the leading SIEM solutions. You deserve that victory lap!

After you take that victory lap and catch your breath, it is time to take the next step.

The NEXT STEP ???   I thought I was DONE !!!

Not quite. Like all SIEM solutions IBM QRadar works best when it gets information in real-time. When QRadar can see an authority failure, a rogue SQL statement, a change to a system value, or any other critical security event in real time it can correlate that event with all of the others from across your Enterprise. It can evaluate its likely impact and compare it with other events to understand the severity of the event. Real-time monitoring is crucial for good security.

The default Device Support Module (DSM) provided by IBM QRadar provides for a periodic, batch view of basic IBM i security events. Because it is a batch process most IBM i users only collect security events once or twice a day. There is no real-time collection available and your QRadar implementation is not functioning as well as you might like.

Fortunately, it is really easy to fix this. Alliance LogAgent for IBM QRadar from Townsend Security helps you take the next step by providing that real-time monitoring for your IBM i server. Running in the background, Alliance LogAgent collects security events, converts them to IBM QRadar format, and transmits them to QRadar as they happen. Attempted hacks to your IBM i server are captured when they happen, not hours later. And QRadar sees them immediately. You get better security within a few minutes of installing Alliance LogAgent for IBM QRadar.

In addition to real-time monitoring, you also get these critical security functions that are not included in the default QRadar DSM for the IBM i:

• File Integrity Monitoring (FIM) for any DB2 database file on your system. You can monitor access to sensitive data on a field level.
• System history file (QHST) monitoring for critical messages and interactive logon and logoff activity.
• User data queue monitoring so that you can write your own security events from your RPG and CL applications.
• Exit Point monitoring so that you can monitor and record the host server activity and send the information to QRadar.

Active monitoring with IBM Security QRadar is one of the most important things you can do. Deploying Townsend Security’s Alliance LogAgent for IBM QRadar will make you more secure by making QRadar better. It’s affordable and easy to deploy. You can download a fully functional evaluation and see for yourself. Alliance LogAgent for IBM QRadar is certified by IBM and supported by the QRadar DSM.

That next step is not a big one, but it has big benefits.

Patrick

IBM i customers should be aware of a new security issue with IBM i Access for Windows version 7.1. This issue will affect a large number of IBM i users as Access for Windows is very commonly used by IBM i customers. US-CERT/NIST in the NVD database indicates this issue has a base score of 7.2 and an impact score of 10. This means that IBM i customers should give this issue attention as soon as possible.

• The vulnerability ID is CVE-2015-2023 and you can find the details here
• IBM provides a description of this issue on their website here
• A fix from IBM is available with Service Pack SI57907 and can be found here

If you are an IBM security administrator I recommend that you sign up for notifications on the NVD website. While the volume of IBM i issues is relatively small, they do occur from time to time and some of them are severe enough to warrant quick action. You can also review IBM i security notifications on the IBM i website here (but be sure to monitor the NVD site too).

Patrick

"This article was originally posted on Pantheon’s blog. Pantheon is a website management platform for Drupal and WordPress."

To keep something safe, you protect it under lock and key, right? Same is true in Drupal and WordPress. Except in these CMSs, that key is unfortunately often hidden under the “Welcome” mat called your database. Not always a very secure place for such important items. So, the question is, what can you do to keep the key safe?

Let’s back up a few steps. Why are there keys and where are they in the first place? 

Private API Keys

Private API keys are actually used frequently within a CMS by services like Authorize.net, PayPal, MailChimp, etc., and stored in the clear. If your site gets hacked, so does access to the services that you have integrated into your site. For example, if your Amazon S3 API key were in your stolen database, hackers would have access to your entire offsite S3 storage. Let’s take MailChimp, for example:  If your MailChimp API key becomes compromised, hackers could send out emails as if they appeared from you, leaving customers surprised to learn that you just got into selling Viagra.

Encryption Keys

In Drupal, for example, there are several modules (Encrypt, Field Encryption, Encrypted Files, etc.) that allow you to encrypt various types of data. This is a very necessary step to keeping your data secure, however what happens to the key to unlock that data? Typically, developers will store their encryption keys locally in either a file protected on the server, in the database, or in Drupal’s settings file. Not very secure places. Further, for companies who fall under data security compliance requirements like HIPAA, FISMA, or PCI DSS, key management requirements are pretty clearly spelled out, and these default methods don’t even come close to being sufficient. Essentially, the compliance requirements all say the same thing: encryption keys should never reside in the same environment or server as the encrypted data. This is a technical way of saying, don’t leave your key under the doormat a hacker walks in over.

Unfortunately in WordPress, there are isolated solutions, but no plugin that provides and manages the encryption process. The team working on the Drupal encryption modules are also working to bring the same functionality to WordPress.

Now that we have established storing sensitive keys within the CMS is not secure, what should we do with them?

Key Management

Keys need to be stored outside of the CMS and developers need to consider how they’ll manage all of these keys. Most encryption modules are designed to create a new key each time the encrypted data is accessed and re-encrypted. As you can imagine, versions of keys add up quickly and managing them is quite a task—not something that you’d want to do manually (luckily your server can’t put a sticky note of keys on its hard-drive).

There are solutions and services designed specifically for key management that can run on a wide variety of platforms ranging from in the cloud, to VMware, to a physical hardware security module (HSM). These solutions can safeguard your API keys, as well as manage encryption keys through the entire lifecycle—from creation to destruction.  Additionally, an external key manager will allow for:

• Key naming and versioning

• Key change and rotation

• Secure key retrieval

• Key mirroring

• Key import and export

• Password and passphrase protection

• User and group control for key access

Modules and Plugins for Key Management

Luckily, for Drupal users, there is a super easy way to integrate external key management (and follow security best practices). This can happen by way of the “Key” module. Key acts as a central routing API for keys and is easily extended to integrate with your key management vendor of choice.

These modules act as the bridge between the various encryption/API modules and an external key manager. They give site administrators the ability to define how keys are stored, which provides an increased level of security and allows sites to meet compliance requirements and security best practices. With these modules installed, users no longer need to settle for storing their keys in insecure places.

While there currently isn’t a Key equivalent for WordPress, efforts are being made to remedy this.  By early 2016, we can expect to see great progress in the way of managing encryption and API keys in via a plugin similar to that in the Drupal environment.  For now, WordPress developers need to rely on an  external service such asLockr to secure these keys.

Who Holds the Keys to Your Kingdom?

There are three important questions that need to be asked when considering your key management strategy:

1. Do I want to manage the keys myself or use a service?

2. Do I need to meet any compliance requirements?  

3. What is my budget?

Your budget and needs can play a large part in determining which route you take. With a low entry price point, a multi-tenant managed key service (where your keys are stored alongside other companies’ keys on the same key manager) is a great option. These services typically operate in the cloud and allow businesses to remove their keys from under the “Welcome” mat and store them in a more secure environment. As businesses or security needs grow, managed key services can easily scale and migrate users to a dedicated, FIPS 140-2 compliant key manager that can help them meet compliance (PCI DSS, FISMA, etc.).

For users who feel more comfortable with a hands-on approach—or don’t trust anyone but themselves with their keys)—a dedicated and self-managed option may be right for them. Dedicated key managers are available virtually (AWS, Azure, VMware) or physically as a Cloud HSM or HSM, and have a wide variety of licensing options.

To Key or Not to Key?

By now the choice should be fairly obvious. Protecting keys is an important aspect of  a strong security posture. As the headlines show, data breaches are a reality—regardless of the size of your business. They can happen as a result of a hacker or disgruntled employee.  Properly protecting API and encryption keys is a very easy way to manage the risk and severity of a data breach.

Townsend Security’s dedicated Alliance Key Manager is in use by over 3,000 customers worldwide and is the only dedicated key manager with Drupal integrations. Cellar Door Media also recently launched Lockr, a managed key service for Drupal and WordPress that’s free during development, and once deployed to a site, pricing starts at $30 per month. Lockr also offers managed dedicated key service for enterprise customers.

2015 was a year of large and sometimes very controversial data breaches across a broad industry spectrum.  The Identity Theft Resource Center 2015 Breach List contains 780 breaches and 177,866,236 exposed records. Here are just a few that everyone should be aware of:

HEALTHCARE

Anthem

• 78.8 million highly sensitive patient records
• 8.8 to 18.8 million non-patient records
• Names, birth dates, Social Security numbers, addresses, employment information, and income data

Premera

• Over 11 million subscribers
• Names, birth dates, Social Security numbers, member identification numbers, and bank account information.

Excellus

• 10 million members
• Names, birth dates, Social Security numbers, member identification numbers, financial account information, and claims information

ENTERTAINMENT

Avid Life Media (ALM), the parent company of Ashley Madison

• 37 million user accounts
• Email addresses, first and last names, and phone numbers.

VTech

• 6.4 million children accounts
• 4.9 million customer (parent) accounts
• Photos, names, passwords, IP addresses, download history, and children’s gender and birth dates.

Hello Kitty (SanrioTown)

• 3.3 million customers, including children
• Full names, encoded by decipherable birth dates, email addresses, and encrypted passwords, along with password reset questions and answers.

TECHNOLOGY

T-Mobile via Experian

• 15 million records
• Names, birth dates, addresses and social security numbers and/or an alternative form of ID, such as drivers’ license numbers. (This was an unusual hack because the company itself (in this case T-mobile) didn’t have a data breach rather Experian (a credit reporting company) had a data breach which leaked T-mobile’s consumers’ data)

TalkTalk

• 3 breaches affecting up to 4 million user records
• Names, addresses, dates of birth, phone numbers, email addresses, TalkTalk account details and payment card information

Comcast

• Over 200,000 users
• Login credentials were sold on the dark web

GOVERNMENT

Office of Personnel Management (OPM)

• Over 4 million personnel files
• Over 21 million federal employees and contractors
• Social Security numbers, security clearance information, fingerprints, and personal details that could leave federal personnel vulnerable to blackmail.

Internal Revenue Service (IRS)

• Over 100,000 taxpayers
• Online transcripts and significant personal information was accessed as a result of access to previously stolen identity information.

Wrapping up the year; on December 20th, 191 million registered U.S. voter records were exposed online. The database that was discovered contained more than the voter’s name, date of birth, gender, and address; which on their own is a good amount of personally identifiable information (PII). It also include the voter’s ethnicity, party affiliation, e-mail address, phone number, state voter ID, and whether he/she is on the “Do Not Call” list.

As we head into 2016, we will be focused on prevention and how we can best provide information and solutions to protect your sensitive & valuable data.

Let us know how we can help you!