+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Luke Probasco

Recent Posts

Alliance LogAgent for IBM i Integrates with ServiceNow

Posted by Luke Probasco on Sep 19, 2017 12:12:00 AM

Alliance LogAgent for IBM i now instantly records critical system events and integrates line-of-business applications with ServiceNow, the leading cloud-based solution for IT systems to instantly record critical system events.

Townsend Security today announced support for integration of IBM i servers and applications with ServiceNow, the leading cloud-based solution for IT system support problem tracking and resolution. Leveraging the ServiceNow REST web interface, Townsend Security’s Alliance LogAgent solution can now instantly record critical system events as ServiceNow Incident reports. Additionally, Alliance LogAgent also exposes an API command to allow IBM i customers the ability to integrate line-of-business applications with ServiceNow. When business applications encounter critical events or errors, these can be immediately visible to the IT administrative and security teams for rapid response and resolution.

“IBM i customers want to leverage the best of the new generation cloud-based service offerings. This new release of Alliance LogAgent gives them that ability right out of the box. Existing ServiceNow customers have all they need to record critical incidents in real time. IBM i users who are not currently ServiceNow customers can rapidly subscribe to ServiceNow and start enjoying the benefits of this leading IT Systems Service Management (ITSSM) solution,” said Patrick Townsend, CEO of Townsend Security.

“The power and stability of the IBM i system can integrate with the best of the cloud-based ITSSM solutions. It’s an easy win for IBM i customers, and those with existing system logging solutions will be happy to know that Alliance LogAgent can co-exist with existing technology, or IBM i customers can take advantage of our competitive upgrade program,” continued Townsend.

New ServiceNow features in Alliance LogAgent include:

Privileged User Access
Monitoring administrative access to IBM i servers is a critical compliance and security best practice. Alliance LogAgent can identify in real-time the privilege level of a user signing on to the system and report it to ServiceNow and to any SIEM solution. Alliance LogAgent is unique in its ability to dynamically identify the true privilege level of a user by examining the native authority of the user as well as authorities inherited from Group and Supplemental profiles. Cyber criminals often use privilege escalation as a starting point in an attack. Alliance LogAgent can now identify privileged user logons and raise a ServiceNow support incident.

User Profile Disabled
A common labor-intensive task for IT administrators is managing user accounts that are disabled due to an excessive number of password failures, or which are disabled due to a brute force attack. Alliance LogAgent will now automatically identify disabled user profiles in real-time and create a ServiceNow incident report. This gives the IBM system and security administrator rapid visibility and resolution for disabled profiles. Additional system security is provided by an out-of-band notification via ServiceNow of a potential attack in progress.

File or Object Change
An attacker often modifies a program or file on the IBM i server as a part of compromising sensitive data. For example, an attacker might modify the IBM i web server configuration file to direct users to malware on infected sites. IBM i customers can now identify both library and IFS objects for monitoring by Alliance LogAgent with reporting directly to ServiceNow. Early detection of modified programs and files can help an IBM i customer avoid a data breach.

Application Integration with ServiceNow
IBM i developers can now easily integrate business applications and processes with ServiceNow through a new command named Create ServiceNow Incident (CRTSVNINC). By embedding this command into user applications the IBM i developer can provide a wide set of incident creation capabilities. This new command builds on the ServiceNow REST interface without requiring complex communications or API logic in the business application. Using the ServiceNow command does not require the SIEM integration components of Alliance LogAgent. IBM i customers can use just the ServiceNow integration component, or combine its use with Alliance LogAgent SIEM integration.

Alliance LogAgent is licensed on a Logical Partition (LPAR) basis. Both perpetual and subscription licenses are available. Volume discounts are available. Additional charges apply to the ServiceNow application. Alliance LogAgent can be downloaded from the Townsend Security website for a free 30-day trial of the fully functional solution. ServiceNow integration requires a subscription license from ServiceNow. Trial subscriptions are available from their website at http://servicenow.com.

IBM i

Topics: Alliance LogAgent, Press Release

Introduction to Encrypting Data in MongoDB

Posted by Luke Probasco on Sep 7, 2017 1:27:20 PM

An excerpt from the White Paper "Introduction to Encrypting Data in MongoDB".


In fewer than ten years, MongoDB has risen to become a top player in nonrelational database providers, outcompeting and upsetting database monoliths such as OracleDB and Microsoft SQL Server. Built on a model of low up-front operational costs alongside improved performance, MongoDB has become one of the most widely growing databases for organizations across retail, financial, healthcare, and government entities.

Introduction to Encrypting Data in MongoDBBeyond cost and performance, a key component of MongoDB’s toolset is a robust plan to help customers achieve strong data security through encryption of data in flight and at rest, along with options to secure and manage encryption keys to meet industry compliance requirements and meet data security best practices.

If you are an organization who routinely considers security and compliance when purchasing third-party software, built-in security solutions can be hugely beneficial to your security and compliance strategy. However, like any new software, questions around deployment and how to get the most out of native encryption tools may still be a barrier to your success.

In order to paint both a broad and in-depth picture of how to best deploy encryption and encryption key management in MongoDB, let’s first start by discussing your options to encrypt data in your MongoDB database. If you’d like to first learn the fundamentals of encryption and key management before diving in, check out The Definitive Guide to Encryption Key Management Fundamentals.

Encrypting data in MongoDB

If you choose to encrypt your data, MongoDB offers solutions for encrypting data in motion as well as at rest.

Data-in-Motion Encryption

For securing data in motion, all versions of MongoDB support TLS (Transport Layer Security) and SSL (Secure Socket Layer) to send and receive data over networks. TLS and SSL are the types of encryption commonly used to secure website traffic and file sharing. They are cryptographic protocols that secure data while it is traveling from one point to another; however, before the data is sent and after the data arrives at its endpoint, the data appears unencrypted, or “in the clear”. MongoDB provides ample documentation on how to configure TLS and SSL protocols using certificates and public and private key pairs, also called asymmetric key systems. (Resource: TLS/SSL Configuration for Clients)

When considering encryption, enterprise customers must be aware of governmental and private regulations that require protecting sensitive information. For example, the Payment Card Industry (PCI) requires that credit card numbers be encrypted in storage. The HIPAA medical regulations require protection of Electronic Protected Health Information (ePHI). And there are many other regulations that require proper protection of Personally Identifiable Information (PII). A challenge for MongoDB users is that it is often difficult to know when sensitive information is being added to the database. The safe security strategy is to always encrypt the MongoDB database and use proper key management.

Data-at-Rest Encryption

To encrypt data at rest, MongoDB Enterprise offers native storage-based file symmetric key encryption, which means that users can use transparent data encryption (TDE) to encrypt whole database files at the storage level. First offered in version 3.2, MongoDB utilizes the Advanced Encryption Standard (AES) 256-bit encryption algorithm, an encryption cipher which uses the same secret key to encrypt and decrypt data. MongoDB also provides the option to turn encryption on in “FIPS mode”, which means the encryption you use in MongoDB is built to meet the highest standard and meet compliance. The Federal Information Processing Standard (FIPS) is a National Institute of Standards and Technology (NIST) validation that demonstrates your encryption algorithm has undergone rigorous tests. The NIST FIPS validation is often required for government and Department of Defense contractors; however, today NIST-validated AES encryption is considered an industry standard and is typically recommended or required by most industry-based compliance regulations. Data at rest encryption is only available on MongoDB Enterprise and Atlas editions using the required WiredTiger storage engine.

When encrypting data natively using TDE, it is important to know how encryption keys are stored in MongoDB. When a database file is encrypted, a unique, private encryption key is generated. Each encrypted database file generates a new private symmetric key, and all keys in your storage device are encrypted using a master key. While the database keys are stored alongside the encrypted data, the MongoDB never allows the master key to be stored on the same server as the encrypted data. This means that the database or security administrator must identify a secure storage location for the encryption key. MongoDB strongly recommends a third-party enterprise key management solutions; however, users have the option to store the key locally using a keyfile. This second option is extremely risky, and almost never recommended for key protection.

To download this White Paper in it’s entirety, download “Introduction to Encrypting Data in MongoDB” and learn about Encrypting data-at-rest and in-motion in MongoDB, MongoDB vs SQL encryption, encryption performance, and what is key management.

Introduction to Encrypting Data in MongoDB

Topics: MongoDB

Talking Drupal Security: Encryption, Key Management, & Defense in Depth

Posted by Luke Probasco on Aug 8, 2017 8:15:27 AM

Securing data in Drupal is a hot topic that Townsend Security’s Luke Probasco, Lockr’s Chris Teitzel, and Mediacurrent’s Mark Shropshire (Shrop) talk about often, including at DrupalCons, camps, blogs, and our upcoming Security By Design - An Introduction to Security webinar.  They recently met up on Mediacurrent’s Dropcast podcast to discuss modules for protecting private data in Drupal, tools developers can use to build secure sites, as well as how businesses should be thinking about security.

Security By Design WebinarShrop: Let’s talk about encryption and key management.  From your perspective, how does encryption work in Drupal?  What do you get out of the box with Core and what types of encryption should be utilized?

Probasco: First off, encryption is not in Core, but we did just see someone create an issue, which is a very good thing.  One thing that I often say is, Drupal is being brought in to a lot of enterprise projects and their security teams don’t really care what CMS is used, as long is it meets their objectives and it is secure.  Luckily, I think that Drupal really has a lot of security advantages.  I mean, we have a whole security team and a suite of security modules (of which Townsend Security and Lockr are big sponsors of), so I think we are doing a lot of really good things to give Drupal a strong security posture.

Teitzel: And to take a step back in the past, take a look at where we’ve come from.  We used to not have ANY tools for developers to implement encryption properly.  When we analyzed the technology that was out there, we realized that there were some serious gaps akin to tapeing your keys to the front door of your house and hoping that nobody breaks in.  So, out of the box, Drupal doesn’t have any encryption at the field level, or for files, or anything like that.  We, along with a whole band of community members, said “we need to do this right” and not only implemented a robust framework around making encryption strong within Drupal, but also saying, “How are we managing encryption and extending it out?”  Encryption within Drupal is no longer the expensive, complicated project that it used to be.

Shrop: So it sounds like encryption is way easier to set up.  When people say, “I don't have anything I need to encrypt.  Why do I need to worry about encryption?” I think think they are missing a valuable point.

Probasco: I think there is a lot of misunderstanding about what needs to be protected.  It is pretty obvious that if you have a credit card or social security number, that needs encrypted.  When you get to the concept of personally identifiable information (PII), a lot of the things that you wouldn’t think would be considered PII actually are.  For example, when you combine things like an email address and someone’s city, you can pretty easily form the identity of a person.  Think about your most basic marketing site that offers a white paper where someone gives up their email address and phone number and ZIP code.  It is imperative to be protecting this type of information.

Shrop: Yeah, that makes a lot of sense.  I think a lot of times, just turning it around and saying “Would I want this piece of PII out there on me?” would be huge.

Teitzel: Another thing to keep in mind is that small businesses and sites actually need to be just as concerned as the big guys.  They are actually considered more of a target because they are often less attentive to security.  Small business sites are hacked more often and in larger numbers, and so for us, if Drupal is really going to grow up, and the enterprise world is demanding encryption, we need to make it dead simple.

Probasco: You made an excellent point.  A lot of people say “I’m too small to be a target.”  Symantec recently did a study that showed mid-sized companies are actually a greater target because they typically don’t have a lot of the controls in place to prevent a data breach.  You should never have a mindset of “I’m too small” or “Nobody is paying attention to me.”

Shrop: A good point on that.  That is true for so many of the technologies that we are concerned with.  You could say the same thing for accessibility or performance.  All these things are important for everybody, no matter their size.  So what does it look like to implement encryption at the field level?

Teitzel: We have simplified the process down into a series of modules that are separate, in order to remain lean and extensible in what they do, but they really all walk hand in hand.  In order to implement encryption at the field level, you will need to download the Encrypt module (the main core of encryption), the Key module is going to be managing all of your encryption keys, and the Field Encryption module.  The three of those together will give you the basics that you will need for encryption.  The one caveat there is that in Drupal 8, you now are required to use the Real AES module.  We are also really in support of what those guys are doing with strong, standards based encryption.  However, these modules are limited in that the keys you are using to encrypt private data have to sit somewhere that Drupal can access – typically the database for the file system.  That is where Townsend Security and Lockr come in.  We say, “we are going to take your keys and store them with an external key manager.”

Probasco: One that that I would also like to add is, it is a security best practices to be storing and managing encryption keys separate from the data that they protect.  It isn’t “Oh, that would be nice” or “that’s a good idea” – industry wide, key management is a fundamental security practice, which Drupal is now able to adopt.

Teitzel: So we built all the encryption and key management modules to be extensible and easy to use.  When you start to talk about encryption, people’s eyes glaze over because it is a seemingly very difficult process and it shouldn’t be, which has been our goal.

Shrop: Something else that I wanted to bring up about encrypting fields, I know that you are talking about using the Real AES module.  I noticed that you didn’t mention coming up with your own encryption scheme.

Teitzel: No, not at all.  Real AES implements the Defuse PHP encryption library, which really just is AES wrapped in a full-proof way to ensure that you are implementing it correctly.  The core of encryption relies on the ability to make un-encrypting data impossible without the key, which is why it is important to be proven and based on industry standards.

Probasco: We have been talking a lot about encryption and key management, which is a natural segue to API key security.  Your APIs are keys within Drupal as well and need to be considered as sensitive data.  Chris, I know you have several examples of what can happen when your API keys are compromised.  When I say API keys, I mean like your link to Amazon S3 or MailChimp.  How often do we here people say “I’m not going to handle credit cards so I will use PayPal”, but what happens when those APIs are stolen?

Teitzel: When we were building the Key module we were sitting in a coffee shop in Seattle and I had this epiphany moment where I said “Why are we only looking at encryption keys?”  We have all these other secrets in Drupal that we are trying to manage.  Why not centralized API keys as well and provide the same level of security to those as we would encryption keys.  Take a look at OneLogin, which a good number of enterprises use for single sign on.  A single AWS key brought down their entire system.  Hackers were able to get in and get user data, resulting in a massive breach.  Many times the data that you are trying to encrypt is behind API keys, so it is a security hole that many people just don’t have plugged.

Shrop: One misperception out there is, once I do a site audit, my site is secure.

Teitzel: That would be great!  Security is an ever-changing landscape.  There are continually new exploits coming out.  Security is not a one-time deal, but a continual process.  Unfortunately, it is a bolt-on after the project is done or about to be shipped.  One of my favorite regulations is the European General Data Privacy Regulation (GDPR), which requires security by design.  If you have a breach, you have to show that you were taking security seriously during design and implementation, not just after the fact.  I think that is a concept that not a lot of people do right now.

Probasco:  Exactly.  GDPR is a serious regulation.  They aren’t just saying, “if you have a breach you will have a small fine.”  They are actually attaching a percentage of your company’s overall revenue.

Shrop: A lot of small companies that you are talking about are vulnerable, but aren’t able to implement all security controls because of budget.  What do you say to companies that think they are just priced out of security?

Teitzel: Shameless plug here, but that is exactly why we created Lockr.  There is a free tier of Lockr that is there for small businesses.  We did that because we feel that everybody should be able to take first steps towards encrypting private data.  By taking budgetary constraints out, we are enabling small businesses to learn about implementing security.  And there are other free services out there for small companies as well.  There are so many other services out there with free tiers as well, that it is possible for small sites to piece together security without breaking their budgets.

Probasco:  I’d also like to give a plug to the project that Shrop is working on – Guardr.  I first learned about it at DrupalCon Baltimore and was just amazed at the cool stuff he is doing.  Guardr is allowing sites to start with a strong security foundation (including modules and settings) that will position them to grow and keep data safe.

To hear this interview in it’s entirety, download Mediacurrent’s podcast “Security!” and hear Luke Probasco from Townsend Security, Chris Teitzel from Lockr and Mediacurrent’s Mark Shropshire to talk about all sorts of security concepts and improvements with Drupal, including, Guardr.

Security by Design Webinar

Topics: Drupal

Drupal Encryption: Protecting Private Data

Posted by Luke Probasco on Jul 24, 2017 1:54:25 PM

Cloudflare.  HipChat.  OneLogin.  The list goes on – and that is just companies that have suffered breaches so far in 2017.  Businesses, large and small, are losing vast amounts of intellectual property (IP) and customer personally identifiable information (PII) to data breaches.  While there is no “silver bullet” to data security, there is one tool that stands out among the rest – encryption.  Encryption can mean the difference between a public breach notification (when private data is lost) and keeping the incident to yourself (if data is encrypted, you didn’t lose any decipherable information).

Security By Design WebinarTo protect data in Drupal, encryption is deployed at the application level with modules, rather than at the database level.  This makes it much easier to encrypt specific fields, forms, user-related data, or files.  It is important to note that Drupal Core does not natively support encryption and that developers will need to look to contributed modules to secure private data.  Let’s first look at the two primary reasons for encryption.

Why We Encrypt: Protect Brand/Customers

The most recent Ponemon Cost of a Data Breach Study shows the average cost of a lost or stolen record to be $141.  This cost includes loss of customers, remediating the breach, and post data breach costs – ultimately affecting a business’s bottom line and in some cases, their ability to keep doors open.

Why We Encrypt: Compliance

While we expect businesses to deploy encryption whenever sensitive data is present, unfortunately, they often need another budge in the right direction.  That budge is handled by compliance regulations.  Both public and private organizations fall under compliance.  Compliance regulations include PCI DSS (if you take credit cards), HIPAA (healthcare), FFIEC (finance), FERPA (education), etc.  Further, aside from industry specific regulations, many states have their own data security mandates.

What Should We Encrypt?

Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.  Examples include:

Social Security Number

Student ID Number

Email Address

Student Educational Records

Health Records

IP Address

Phone Number

Birth Date

 

Excuses, Excuses, Excuses

No more excuses.  If you aren’t encrypting private data, you are not applying due diligence.  Yes, learning security best practices may be something new for site developers, but by not evolving your skills, your sites and clients will be left vulnerable when bad actors come knocking.

“My clients aren’t asking for encryption.”

It may be true that your clients aren’t asking specifically for security, but they are paying you for it. Your clients expect site security, just as they expect you to anticipate and address their needs in other areas of site development. Further, by not implementing appropriate security controls, if there is a breach, you can be liable.

“I’m too small to be a target.”

It is often a surprise to small and medium sized businesses that they are actually considered a greater target than large enterprises. Why? Because hackers know that SMBs are an easy target. Symantec recently published a report confirming that three out of five cyber-attacks target small and midsize companies.

“There is no budget.”

Encryption has a reputation for being costly and causing severe impact on performance.

Today this reputation doesn’t hold true, and these common fears can, in fact, get in the way of implementing a strong security solution.

Encryption in Drupal

As mentioned earlier, Drupal Core does not natively support encryption and developers will need to look to contributed modules to secure private data. The following modules will help you get started on the right foot.

Encrypt

Encrypt creates an API for performing symmetric encryption and decryption of data within Drupal. It provides a plugin-based system for encryption methods and key providers, allowing the ability to choose how to encrypt data.

Real AES
Real AES provides an encryption method plugin for the Encrypt module.  This module offers authenticated encryption based on AES-128 CBC with a HMAC.

Field Encryption
Field Encryption encrypts Field values when stored in the Drupal database.  This module is useful for fields that site visitors may input sensitive data into.

Encrypted Files
Encrypted Files allows Drupal to encrypt files that users upload and decrypt files for download, keeping the unencrypted versions of files from ever being stored on disk.

Key Management in Drupal

Most users who are currently encrypting sensitive data are storing the encryption key locally in either a file on the server, in the database, or in Drupal’s settings file. None of these methods meet data security best practices or compliance regulations such as PCI DSS, HIPAA, etc.  In order to truly protect encrypted data, businesses need to also store and manage their keys with an external key manager.  The Key module can help with this.  Key provides the ability to manage encryption keys and define how/where keys are stored, allowing sites to meet regulatory or compliance requirements and security best practices.

At the end of the day, it is important to remember that there is no silver bullet to data security and you should take a defense in depth approach to protecting your or your clients’ web sites. 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. Alternatively, Lockr is the first hosted API & encryption key management for modern content management systems like Drupal and WordPress, providing affordable solutions for all sites to properly manage access and encryption keys.

Security by Design Webinar

Topics: Key Connection for Drupal, Drupal

Identify Escalated Privilege Attacks on IBM i

Posted by Luke Probasco on Jul 13, 2017 11:21:03 AM

It can be difficult to identify IBM i users who have administrative privileges. This is because of the unique nature of IBM i user profiles. An IBM i user has an explicit level of privilege that is easy to determine, but that user can adopt additional privileges through a Group Profile and through any number of profiles defined in a Supplemental Group.

Identify Escalated Privilege Attacks on IBM iI recently sat down with Patrick Townsend, Founder and CEO, and discussed how to determine the true level of authority of a user profile, control and monitor administrative level users, and set email alerts to include critical job and security information.

Cyber criminals attempt to escalate their level of privilege by stealing and using administrative credentials. Because IBM i servers are accessed from user PCs across internal and external networks, credential stealing from these exposed PCs and networks is the preferred mechanism for compromising an IBM i server.

That’s right.  An attacker will typically compromise a user’s PC and use that as a platform to attack an IBM i server. While it is possible to attack an IBM i directly, I think that is a pretty unusual case.  Normally an attacker will try to determine who in your organization is likely to have elevated privileges and then, using standard attack vectors like phishing emails or poisoned web links, get access to that user’s PC. From that point, it is not difficult to piggyback on that user’s credentials into the IBM i platform – and that gives them access to data from the IBM i, especially if they have elevated privileges.  On the IBM i server, we have a particularly difficult challenge in identifying exactly who has a lot of privilege.  It is quite surprising how many regular users end up with a high level of privilege – and that is because of the hierarchy (Group Profile  and Supplemental Groups) that can be related to  a user profile on the IBM i platform.  If any of those groups that the user is a member of has elevated privileges, so does that user.

To determine a user’s actual level of authority, an IBM i security administrator may have to research dozens of additional accounts. That sounds like a daunting task.

It is.  IBM gives us some security commands to help print information about users, but unfortunately they don’t drill down and give you all the information that you need in one place.  You need to use multiple commands and look specifically at a particular user – which becomes an administrative headache.  Imaging multiplying that by hundreds or thousands of users on an IBM i server and you have got a major challenge in front of you.  At Townsend Security, we are giving the IBM i administrator some new tools in Alliance LogAgent that make this job a whole lot easier.  We will actually chase down those highly privileged users, resolving all of the adopted authorities that they have through group profiles and supplemental groups, and then alert system administrators when a highly authorized privileged user signs on to the IBM i server.  Alerts are sent via email notifications or by special events to your SIEM.   We think we have done a pretty good job of helping the IBM i administrator see and resolve problems with adopted authorities.

That is really cool.  How does it work?

We look at a user profile or a selected subset of user profiles, and for each one we look at what authorities each one has.  Do they have All Object authority?  Do they have control over jobs or audit capabilities?  What authorities do they have?  Then, we drill down into the group profile and ask the same questions.  What authorities are additive to the ones that you natively have? With this information, we start to build a matrix. If a user picks up authority with a group profile, we’ll tell you.  We take the mystery out of where the level of privilege comes from. This makes it easier for an IBM i security administrator to say “Oh my goodness, I have a user profile here who has All Object authority.  That shouldn’t be there!” and make it easier to reign in the number of highly authorized users.

Aside from reporting to a SIEM, there is an email-alerting component as well, right?

Yes.  We send an email in real-time when a highly authorized user signs on to the IBM i server or starts a job (either interactive or batch).  The notification contains information on the name of the user and job – enough information so that a security administrator can easily identify the system where the job is starting.  This gives security administrators a real fast alerting process so that they can identify when a highly authorized user signs on to the system.  That means that they can detect a brute force attack, somebody who has stolen credentials, or even when someone is signing on at an odd time.  If you find yourself saying “Bill in the shipping department has a high level of authority and signed on at 2:00am, there might be a problem here” – you now have a way to see and react very quickly.

What else would you like to tell us about Alliance LogAgent, your log and event monitoring solution?

Alliance LogAgent is a very rich and mature system logging and notification solution and is designed to integrate with any SIEM (IBM Security QRadar, Splunk, LogRhythm, etc.).  Additionally, we do File Integrity Monitoring (FIM) and can pick up changes to a database, even on a field by field basis.  FIM is a part of PCI DSS, for example, and other compliance regulations.  It really allows you to put a very detailed focus on the sensitive data sitting on the IBM i.

Additionally, the security audit journal is not the only place on the IBM i that collects important security information.  We monitor many exit points on the IBM i (FTP, ODBC, etc.) and capture activity and send it to your SIEM.  The communications are all built into Alliance LogAgent – syslog, UDP, TCP, and TLS encrypted sessions to move data in real-time off of the IBM i platform to your SIEM.  The solution allows you to bring your IBM i fully into a continuous monitoring SIEM view of security events on the IBM i.

To hear this interview in it’s entirety, download our podcast “Identify Escalated Privilege Attacks on IBM i” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss determining the true level of authority of a user profile, controlling and monitoring administrative level users, and setting email alerts to include critical job and security information.

I

Topics: IBM i, Alliance LogAgent

Why Encryption is Critical to FinTech

Posted by Luke Probasco on Jul 5, 2017 8:27:26 AM

FinTech is transforming the financial services industry. Everyone from banks and credit unions to insurance companies deal with huge amounts of private data on a daily basis - and the best way to secure it is with encryption. Not only are companies deploying encryption to meet compliance (PCI DSS, etc.), but also as a security best practice.

Why Encryption is Critical to FintechI recently sat down with Patrick Townsend, Founder and CEO, and discussed why encryption is critical to FinTech, meeting the various compliance requirements, as well as how Townsend Security is helping FinTech customers better secure their private data.

The financial world is rapidly changing. Innovations in technology are impacting payments, lending, insurance, and even compliance. Unfortunately, security often does not get as much attention as it should. Do you have any stories that you can share with our listeners about when security really wasn't thought all the way through?

Not only is security a consideration for new solutions coming to market, but it can also be a problem for businesses using legacy technology that was deployed many years ago. Encryption and data protection just were not on the top of anyone’s mind when the applications were built. I recently talked with a large global bank who is running a software package from a well known financial services software vendor and it DOES NOT implement security in the way that we think of it today. Encryption libraries didn’t even exist on some of these platforms when solutions were created, so we are left with applications without encryption, let alone proper key management. This is a ubiquitous problem across the financial services industry as a whole and has become a very big challenge.

Sometimes I wonder how secure our personal data would be if it weren’t for compliance regulations like PCI and GLBA. What are your thoughts on the impact of compliance and data security?

I think compliance follows threats and losses. When individuals suffer from cybercrime, they complain to their legislators and lawyers, and out of that come compliance regulations. For example, we are seeing new compliance regulations like those from the New York State Department Financial Services (NYDFS) requiring organizations to establish and maintain a “risk-based, holistic, and robust security program” that is designed to protect consumers’ private data.” Other compliance regulations like PCI DSS, GLBA, and not just regulations specific to the finance industry, have been created to protect individuals who may be cybercrime targets.

Financials organizations are responding to compliance regulations by further protecting data that they collect. They do it because they have to (to meet compliance requirements), but also because it is important to their brand and the trust that they have established with their customers. Today, no acquirer of FinTech would find it acceptable to have sensitive data not protected to industry standard encryption and security best practices.

The technologies around data protection are pretty straightforward. Encryption and key management are the fundamental compliance related controls required to protect non-public information (NPI) and personally identifiable information (PII) in financial services environments. Encryption can be deployed at the application or database level and allow organizations to provably meet compliance requirements for protecting data – both on premises and in the cloud.

What advice do you have when it comes to selecting and evaluating a FinTech vendor?

Security and compliance have to be top of mind. Businesses need to make sure that their FinTech is secure and that if it handles sensitive data, that it is protected with encryption and key management. Security needs to become an internal governance issue to be sure that solutions that are acquired and deployed or upgraded truly and provably meet compliance and industry standards.

Townsend Security is helping these organizations with Alliance Key Manager, our centralized encryption key management solution. We believe in compliance and standards and our key manager is FIPS 140-2 compliant, in use by over 3,000 customers worldwide, and is available as a hardware security module (HSM) or as a software appliance in VMware or the Cloud (AWS and Azure). Additionally, Alliance Key Manager has been validated to meet PCI DSS in VMware, giving businesses in the financial services industry a “compliance out of the box” solution.

To hear this interview in it’s entirety, download our podcast “Why Encryption is Critical to FinTech” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss encryption, key management, and meeting compliance requirements specific to financial services.

Why En

Topics: Encryption, FinTech

Case Study: Plaza Premium Lounge

Posted by Luke Probasco on Jun 19, 2017 8:29:59 AM

PPL-Logo.pngMeeting PCI DSS with Townsend Security's Alliance Key Manager Hardware Security Module (HSM)


“Alliance Key Manager is simple, reliable, and easy to use - as a result, has allowed us to meet PCI DSS compliance and expand our market.”

- Sandeep Tewatia, IT Director

 
Plaza Premium Lounge

Plaza Premium Lounge Case Study

Plaza Premium Lounge is a global service brand headquartered in Hong Kong and is the industry-leader in premium airport services. Their goal is to make your airport experience seamless and effortless and, through their hearty services, change the perception of travel at the airport. The company operates in more than 140 locations in 35 airports across the globe and counts over 3,500 employees. The success of their business model has prompted airport authorities around the world to offer independent lounge facilities and value-added airport services as part of a bid to enhance the overall traveler experience.

 

The Challenge: Meet PCI DSS Compliance with Encryption Key Management

PCI DSS 3.0 requires businesses to, “Protect stored cardholder data.” The Requirement 3 summary names encryption, truncation, masking, and hashing as “critical components of cardholder data protection” and places strong emphasis on key management: “If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.”

Storing encryption keys next to the data they protect is not considered a security best practice and won’t meet data security compliance requirements like PCI DSS.

Faced with designing a PCI DSS compliant environment to store and process credit cards, Plaza Premium Lounge understood the importance of deploying an encryption key manager and that it should be based on industry standards. The solution had to be FIPS 140-2 compliant, designed to scale with their business needs, and have easy integration with IT infrastructure.  Additionally, the chosen vendor needed to provide excellent developer and technical support.

 

The Solution

Alliance Key Manager HSM

“I looked at all of the encryption key management HSM vendors,” said Sandeep Tewatia, IT Director. “Not only is Alliance Key Manager available as a FIPS 140-2 compliant HSM, Townsend Security has the same technology available in the cloud - which is important as we scale.”  By deploying Alliance Key Manager HSM, Plaza Premium Lounge was able to meet their business needs with a FIPS 140-2 compliant solution that could not only deploy quickly, but was also easy to set up and configure.

Integration with IT Infrastructure

“Townsend Security’s integration with our existing IT infrastructure really set the company apart,” continued Tewatia. “Alliance Key Manager has helped us meet our business goals of meeting PCI DSS in record time.”

By combining Alliance Key Manager and Townsend Security’s client applications and SDKs, Plaza Premium Lounge experienced a seamless integration with their IT infrastrutucture. Alliance Key Manager includes an unlimited license to use the Key Connection for SQL Server software.

Meeting PCI DSS Compliance

By managing encryption keys separately from the encrypted data, meeting PCI DSS encryption key management requirements went from a long, difficult, developer project to an easy integration.

“Having a PCI compliant environment has allowed us to expand our market and Alliance Key Manager was essential to us meeting section 3 for protecting stored cardholder data,” finished Tewatia.

Plaz

 

Topics: Alliance Key Manager, Case Study

Banks & Financial Services: Meeting Data Security Compliance Requirements

Posted by Luke Probasco on May 22, 2017 7:11:00 AM
Due to the vast amounts of sensitive data that they deal with on a regular basis, it is understandable that the banking and financial services industries are among the most regulated in the world. While GLBA/FFIEC are specific to these industries, compliance regulations such as PCI DSS, SOX, and state privacy laws can also apply. One thing that they all have in common though, is that encryption, along with proper key management, can mean the difference between a public breach notification and having a safe harbor.
Compliance Ready Encryption for Financial ServicesI recently sat down with Patrick Townsend, Founder and CEO, of Townsend Security to discuss the Gramm-Leach-Bliley Act (GLBA), the Federal Financial Institutions Examination Council (FFIEC), and what they say about protecting non-public personal information (NPI) and personally identifiable information (PII).

Hi Patrick. 95% of the top US commercial banks have a network security grade of “C” or below (according to SecurityScorecard’s latest Financial Cybersecurity report). In the past we have talked about the perimeter being weak and this report really supports that - which in turn supports the importance of encrypting data at rest.

Yes, the financial industry is a little bit late to the game in terms of protecting data at rest with encryption. I know this might surprise some people when they hear this. There has been an increased level and sophistication of attack and cybercriminal activity towards financial institutions. We are seeing attacks on banks, insurance companies, and many others. And it makes sense, right? Verizon recently reported that the vast majority of these attacks, around 90%, have a financial motive. Yes, these actors have other interests, but largely, data breaches and attacks have a financial motive, which makes banks a natural target.

Historically, banks have not had much compliance pressure to implement encryption – which is now changing. We are seeing this happening now, for example, in New York with the Department of Financial Services regulations. There is a lot more pressure for financial institutions to encrypt data at rest, along with properly managing encryption keys – and it is only going to continue with more regulations and more requirements.

Let’s talk about compliance regulations. The finance industry arguably falls under more than any other industry. Can you talk about the various regulations?

You are absolutely right. Financial institutions do cross a lot of boundaries – GLBA/FFIEC, PCI DSS for credit cards, SOX if they are publicly traded, privacy regulations, etc. There is just a broad set of compliance regulations coming into play.

Banks who handle credit cards have always fallen under PCI DSS. But PCI DSS focuses specifically on credit card data – credit card number, expiration date, cardholder name, etc. Specific to the banking industry, GLBA and FFIEC are requiring these organizations to protect non-public personal information (NPI). At the end of last year there was an update from the FFIEC covering best practices on strengthening the regulations around encrypting and protecting NPI. The FFIEC has been very active in that area and is fully empowered to ensure the security and confidentiality of customer records and information.

Furthermore, we just saw the state of New York and the Department of Financial Services promote some new regulations in the area of data security. NYDFS covered a lot of ground, all the way from specifying the requirement of a compliance officer right down to encrypting private data. We are seeing an evolving regulatory structure that is moving towards more security and data protection, not less, and there is no question that across the board compliance regulations and banks are having to step up to better protect data with provable technologies. Encrypting data at rest is an evolving area, but has certainly been moving at a rapid pace.

When you talked about PCI you covered what credit card numbers are required to be encrypted. What are some examples of NPI that needs protection under GLBA?

Think of it as any kind of sensitive data that could be used by a cyber criminal. For example:
  • Any information an individual gives you to get a financial product or service (for example, name, address, income, Social Security number, or other information on an application)
  • Any information you get about an individual from a transaction involving your financial product(s) or service(s) (for example, the fact that an individual is your consumer or customer, account numbers, payment history, loan or deposit balances, and credit or debit card purchases)
  • Any information you get about an individual in connection with providing a financial product or service (for example, information from court records or from a consumer report)
Just think about it as sensitive data in the broader sense and not worry so much about the formal definition of NPI – again, information that might compromise someone’s financial or reputational status and you probably have a pretty good idea of what needs to be protected.

Along with encryption also comes key management, which has often been described as the most difficult part of encryption.

Yeah, we often say that encryption is the hardest part of data security and key management is the hardest part of encryption. Why is that? When you encrypt data, you are using a special secret, known as an encryption key (something that can’t be guessed or predicted) to keep the encrypted data safe.

First, businesses should be using standards-based encryption like AES or RSA, and these algorithms require keys to make them work. Key management then becomes the real challenge for financial institutions because they need to create and manage provably strong and protected encryption keys. Regarding strong keys, it is important to note that a password, or even what you think of as a strong password, is not adequate. This is the function of an enterprise key management solution. At Townsend Security we have our Alliance Key Manager, which is validated to industry standards (FIPS 140-2), and that means that encryption keys are strong, stored in a protected fashion, away from the data that they are protecting. All of that becomes a very important part of an encryption strategy because encryption is only as strong as the protection of the keys.

Critical functions of a key manager include:
  • Ensure origin and quality of keys
  • Manage keys through entire lifecycle, not just store them remotely
  • Use accepted and standards-based encryption algorithms
  • Implement dual control, separation of duties, split knowledge
  • Ensure that keys are securely backed up, at all times
  • Implement strong authentication mechanisms
  • Protect and restrict access to encryption keys

Thanks Patrick. Any final thoughts you’d like to share?

We really believe in the term “Compliance out of the box.” Townsend Security provides several solutions that can help members of the financial services industry protect NPI/PII and help them meet the vast number of evolving compliance requirements. We provide encryption key management solutions that are validated to meet PCI DSS, as well as a variety of client-side applications and SDKs to make encryption projects easier than ever. Alliance Key Manager is a mature product that is in use by thousands of customers, worldwide.

To hear this interview in it’s entirety, download our podcast “Encryption Requirements for Banks & Financial Services” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss encryption, key management, and meeting compliance requirements specific to financial services.

Compliance

Topics: Compliance, GLBA/FFIEC

Press Release: Townsend Security Secures Nonpublic Personal Information (NPI) for Financial Services and Personally Identifiable Information (PII)

Posted by Luke Probasco on May 1, 2017 6:00:00 AM

By protecting data with encryption and key management solutions from Townsend Security, businesses can easily meet compliance requirements.

Townsend Security, a leading provider of encryption and key management solutions, today announced that Alliance Key Manager can help businesses in the finance industry meet new encryption requirements, including those found in the New York Department of Financial Services (NYDFS) cybersecurity regulation and the European Union General Data Privacy Regulation (GDPR), in addition to existing Gramm-Leach-Bliley Act (GLBA) and PCI Data Security Standard (PCI DSS).

By protecting nonpublic personal information (NPI) and personally identifiable information (PII) with NIST-compliant AES encryption and FIPS 140-2 key management found in Townsend Security’s Alliance Key Manager, businesses can protect private information including: customer financial records, social security number, income, and account numbers. Organizations that experience a data breach where un-encrypted data is lost can suffer fines reaching into the millions of dollars, as well as face indirect costs like brand damage and customer loss.

Fortunately, encryption and key management has gotten tremendously easier to deploy and is within reach of the most modest budgets. Customers worldwide have turned to Alliance Key Manager because it enables them to easily meet the most stringent requirements found in GLBA, PCI DSS, and HIPAA. The solution has been validated to meet PCI DSS in VMware, and is also available as a hardware security module (HSM) and in the cloud (AWS, Azure, vCloud).

“The finance industry is increasingly being held accountable for the security, confidentiality and integrity of non-public customer information,” said Patrick Townsend, founder and CEO, of Townsend Security. “Encryption, along with key management, is the best way to ensure that private information remains private – even in the event of a breach.”

Encryption Key Management Trends Perspectives 

Topics: Press Release

Encryption Requirements for Banks & Financial Services

Posted by Luke Probasco on Apr 25, 2017 8:33:00 AM

It should come as no surprise that the financial industry is among the most regulated in the world.  There are strong data security requirements for banking and financial industries due to the sensitive and private data that they deal with.  While GLBA/FFIEC are specific to these industries, compliance regulations such as PCI DSS, SOX, and state privacy laws can also apply.  One thing that they all have in common though, is that encryption, along with proper key management, can mean the difference between a public breach notification and having a safe harbor.

What Data Needs Encryption?

Compliance Ready Encryption for Financial ServicesAside from the obvious personally identifiable information (PII) such as names, addresses, and social security numbers, the financial industry also regularly handles data that includes income, credit score, collection history, and family member PII and Non-public Personal Information (NPI).

The Gramm-Leach-Bliley Act (GLBA) specifically requires that institutions doing business in the US establish appropriate standards for protecting the security and confidentiality of customers’ NPI. The objectives are to:

  • Ensure the security and confidentiality of customer records and information
  • Protect against any anticipated threats or hazards to the security or integrity of such records
  • Protect against unauthorized access to information which could result in substantial harm or inconvenience to any customer

Additionally, the Federal Financial Institutions Examination Council (FFIEC), which is “empowered to prescribe uniform principles, standards, and report forms to promote uniformity in the supervision of financial institutions,” adds:

“Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit.”

Between FFIEC and GLBA, banks and financial institutions should encrypt:

  • Any sensitive information an individual gives you to get a financial product or service (such as name, address, income, Social Security number, or other information on an application)
  • Any information you get about an individual from a transaction involving your financial products or services (for example, the fact that an individual is your customer, account numbers, payment history, loan or deposit balances, and credit or debit card purchases)
  • Any information you get about an individual in connection with providing a financial product or service (for example, information from court records or from a consumer report)

Encrypting Private Data

Encryption is often considered the hardest part of securing private data.  The first step that banks and financial services can take is to deploy encryption based on industry-tested and accepted algorithms, along with strong key lengths.  Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

There are many levels within an organization’s stack that encryption can be deployed, ranging from the operating system to the application and database level.  Choosing where to implement encryption has security implications.  Let’s focus on the two that are the most secure.

Encryption at the Database Level

Almost all commercial databases now support some time of encryption in the database itself.  Encryption at the database layer provides some distinct advantages:

  • Encryption is optimized for database performance
  • Encryption services are better integrated with other database access control services resulting in fewer security gaps
  • Encryption key management may be better integrated into the encryption implementation

Encryption at the Application Level

Application encryption involves the use of an encryption library and a key retrieval service.  Encryption at the application layer fundamentally means that you are encrypting data before inserting it into a database or other storage mechanism, and decrypting it after you retrieve the data.  It provides a very granular level of control of sensitive data and allows for the application of user access controls, program access controls, data masking, and other security controls.  Many feel that application layer encryption is the most secure way to protect data.

Encryption Key Management

Encryption is only as secure as your encryption keys.  The essential functions of a key management solution include storing the encryption keys separate from the data that they protect, as well as managing the encryption keys through the entire lifecycle including:

  • Generating keys for different cryptographic systems and different applications
  • Generating and obtaining public keys
  • Distributing keys to intended users, including how keys should be activated when received
  • Storing keys, including how authorized users obtain access to keys
  • Changing or updating keys, including rules on when and how keys should be changed
  • Addressing compromised keys
  • Archiving, revoking, and specifying how keys should be withdrawn or deactivated
  • Recovering keys that are lost or corrupted as part of business continuity management
  • Logging the auditing of key management-related activities
  • Instituting defined activation and deactivation dates, and limiting the usage period of keys

Just as with encryption, it is paramount that your key management solution meets industry standards.  Again, look to NIST and vendors who have a solution that is FIPS 140-2 compliant.  By adequately encrypting data to industry standards, the loss of encrypted data is not generally considered a breach, and is exempt from notification requirements.

FFIEC Guidance

The FFIEC provides guidance and oversight of GLBA for banks and financial organizations.  They publish the IT Examination Handbook, which provides guidance for the IT security controls that can or should be used to protect NPI under GLBA.  According to the Handbook, financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:

  • Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk
  • Effective key management practices
  • Robust reliability

Fortunately, encryption and key management has gotten tremendously easier to deploy and is within reach of even the most modest budgets.  By protecting data with strong, standards-based encryption, organizations can meet the requirements of GLBA/FFIEC and protect their customer's’ private data – even in the event of a breach.

Compliance

Topics: GLBA/FFIEC

 

 

Subscribe to Email Updates

Posts by Topic

see all