+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

IBM i Privileged Users – A Unique Security Challenge

Posted by Patrick Townsend on Jun 27, 2017 8:54:41 AM

If you are an IBM i security administrator you know how hard it can be to determine a user’s true level of privilege on your system. IBM has given us a very flexible scheme to grant and restrict privileges to groups of users. And this flexibility can lead to unexpected security exposures. Let’s delve into this a bit deeper with an example (names are made up for this example):

JANICE
Janice is regional manager in the sales team. She’s exceptionally effective at her job and has taken on a number of tasks that help her support her team and the sales goals of her region. Let’s take a look at her user profile:

User Profile . . . . . . . . . . . . . . . . . . . : JANICE
Special authority . . . . . . . . . . . . . . . : *SPLCTL
   
Group profile . . . . . . . . . . . . . . . . . . : SALES
Supplemental groups . . . . . . . . . . . : HRUSER PAYROLL REPORTING
  INVENTORY MANAGERS …

 

Identify Escalated Privilege Attacks on IBM iAt first glance it would seem that Janice has a normal user level of special authorities. In fact the only special authority is spool file control (*SPLCTL) which would be reasonable for a manager who needs to run and print reports. It also seems appropriate that Janice has a Group Profile of SALES. You would imagine that this probably gives her the ability to access the company sales management application.

The first hint of concern is the long list of supplemental groups. If you’ve met effective managers like Janice it won’t surprise you that they have access to a number of applications. She probably has responsibility for approving time off for her department’s employees, and has responsibilities for reporting to management. But what privileges are hidden in that Group Profile and in those Supplemental Groups?

Let’s take a look. 

SALES (Group profile)
When we display the SALES user profile we find these special authorities: 

User Profile . . . . . . . . . . . . . . . . . . . : SALES
Special authority . . . . . . . . . . . . . . . : *SPLCTL
  *JOBCTL
   
Group profile . . . . . . . . . . . . . . . . . . : *NONE
Supplemental groups . . . . . . . . . . . :  

 

Janice already had authority to spool files, but notice the job control value of *JOBCTL. This means that Janice has now inherited additional authority to manage jobs. This is not a severe uplift in privileges, but it shows how privilege escalation works.

Now, what about those supplemental groups? Do we have to look at every one?

Yes we do. Let’s look at the HRUSER profile next

HRUSER (Supplemental Group)
When we display the HRUSER user profile we see these authorities: 

User Profile . . . . . . . . . . . . . . . .  : HRUSER
Special authority . . . . . . . . . . . . : *SPLCTL
  *JOBCTL
  *SECADM
   
Group profile . . . . . . . . . . . . . . . : *NONE
Supplemental groups . . . . . . . . :  

 

Wow, the HRUSER has the special authority of security administration (*SECADM). That’s a bit worrying. If we had to guess there is probably third party HR package requirement for this, or this authority was just granted out of convenience. But now Janice has much more authority. 

Let’s continue our exploration of those supplemental group profiles:

PAYROLL (Supplemental Group)
Let’s take a look at the PAYROLL user profile:

User Profile . . . . . . . . . . . . . . . . : PAYROLL
Special authority . . . . . . . . . . . . : *SPLCTL
  *JOBCTL
  *ALLOBJ
   
Group profile . . . . . . . . . . . . . . . . : *NONE
Supplemental groups . . . . . . . . . :  

 

Whoops, the PAYROLL user has All Object authority (*ALLOBJ). Bingo! This is the mother load of privilege. A user with All Object authority basically has the keys to the kingdom. It is pretty much equivalent to being the QSECOFR security officer (“root” for you Linux nerds). Once you have All Object authority you can manage other user profiles, grant yourself additional authority, and basically access any data on the IBM i server. 

If I am an attacker and I can steal Janice’s credentials for the IBM i server I now have all of the authority I need to infiltrate sensitive data.

Did you notice how much work it was to track down Janice’s true privilege level? As an IBM i security administrator you probably know how to fix this problem. You need to analyze the real need for the All Object authority and revoke it. But imagine that you managed a system with hundreds or thousands of users. And imagine if you needed to check this at least monthly in order to detect any changes since the last time you inspected your users? It would truly be impossible to keep up with this task, and as the security administrator you might have other things you need to do, right?

So, is there any hope?

 Sure there is. Our Alliance LogAgent solution will do this work for you. You can run the User Authorization report and Alliance LogAgent will track down these authorities for you. It will tell you the overall inherited authority of any (or all) users, and where they are getting the authority. Here is an example of the output for Janice:

escalated-privilege-report.png 

Notice that all of Janice’s cumulative authorities are listed right on the top line of the report detail. Then notice that the Group Profile and all Supplemental Group profiles are listed with their authorities. The PAYROLL user is clearly identified as having the All Object authority. Now you can go to work. 

The Alliance LogAgent report can be executed for all users, or for a group of users. And you can filter it so that you first get a list of all users who have inherited All Object authority. Then run it with additional authorities. In a few seconds you can find your privileged users, discover where they get that authority, and create a work plan to fix the problems.

However, Alliance LogAgent goes even further. As it is processing events from the security journal QAUDJRN, it can resolve in real time the true privilege of each user signing on to the IBM i server, tag job start events where the user has elevated privileges, and send them to your SIEM for monitoring. In real time.

I think that’s pretty powerful, don’t you?

Patrick

I

Topics: IBM i, Alliance LogAgent

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

SQL Server TDE vs Cell-Level Encryption: A Brief Comparison

Posted by Ken Mafli on May 31, 2017 2:21:18 PM

In 2008, Microsoft introduced Transparent Data Encryption (TDE) to its Enterprise and Datacenter Editions of SQL Server. Billed as a way to seamlessly deploy SQL Server encryption, users now had the choice of full database-level encryption, instead of just the previous choices of cell-level encryption (CLE), Encrypting File System (EFS), or Bitlocker. With its rapid deployment, ease-of-use, and enhanced security TDE has been a staple for every version of SQL Server Enterprise Edition (and Developer Edition) ever since.

Versions of SQL Server Enterprise with TDE:
2008, 2008 R2, 2012, 2014, 2016

Encryption & Key Management for SQL Server - Definitive GuideTDE has become a favorite for bulk encryption in meeting regulatory compliance (like PCI DSS) or internal corporate data security initiatives. But while TDE has it’s advantages, it is not a cure-all. Sung Hsueh did a great job explaining the advantages and disadvantages of TDE as compared to CLE. The following is a curated look at that whitepaper. Let’s take a quick look:

What is Transparent Data Encryption?

TDE fundamentally is full database-level encryption. It functions at the Input/Output (I/O) level. Any data written into the database is automatically encrypted. Backups are also automatically encrypted. Data in use is decrypted by TDE as they are read by a user or application and stored, in clear text, in memory. Since the data-in-flight is decrypted; TLS or SSH (or now, “Always Encrypted”) should be enabled to protect the data while in motion.

What is Cell-Level Encryption?

Introduced in 2005, CLE is implemented as a series of built-ins. It is a manual process “that requires a re-architecture of the application to call the encryption and decryption functions.” Hsueh also notes that “the traditional limitations of encryption are inherent in this method as none of the automatic query optimization techniques [of TDE] can be used.” 

CLE vs. TDE

The advantages of CLE:
  • Since it is column level encryption, it encrypts only the sensitive information in a table.
  • With CLE, the data is still encrypted even when it is loaded into memory.
    CLE allows for “explicit key management” giving you greater control over the keys and who has access to them.
  • CLE is highly configurable, giving you a high degree of customization (especially when your applications require it).
  • Queries may be faster with CLE if the encrypted column(s) is not referenced in the query. TDE will always decrypt the entire row in the table. CLE will decrypt the column value only IF it is a part of the data that is returned. So in some cases CLE implementations provide much better overall performance.

The disadvantages of CLE:

  • One of the main disadvantages of CLE is the high degree of fully manual application changes needed to use it. TDE, on the other hand, can be very simple to deploy with no changes to the database, tables or columns required.
  • CLE can also have high performance penalties if search queries cannot be optimized to avoid encrypted data. “As a rough comparison, performance for a very basic query (that selects and decrypts a single encrypted column) when using cell-level encryption tends to be around 20% worse [than TDE].”

The whitepaper goes on to note that with CLE performance impacts “are several magnitudes worse when attempting to encrypt an entire database. One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted.” TDE, on the other hand, only had a 3-5% average performance impact compared to a non-encrypted database.

Final Thoughts

A case could be made for using CLE in conjunction with TDE as a defense-in-depth strategy. By selectively encrypting columns with CLE, encrypting the full database with TDE, and then managing the separate keys with a centralized key manager; it would ensure that crucial data was protected, even while loaded into memory.

But, in general, TDE and CLE are used for different purposes. If you are looking to encrypt a small amount of data, if your application “has custom design requirements,” or if performance is not a much of a concern, CLE may have advantages over TDE. But, if performance is a concern or you would like to avoid manually implementing encryption (normally a time-consuming process) then TDE is the way to go.

For more information on both types of encryption and how they relate to Extensible Key Management, visit our Definitive Guide to SQL Server Encryption & Key Management.

Encryption

Topics: SQL Server, Cell Level Encryption, Transparent Data Encryption (TDE), SQL Server encryption

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.
Encryption Requirements 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.

Encryption

Topics: Compliance, GLBA/FFIEC

Who owns my encryption key in the Amazon AWS cloud?

Posted by Patrick Townsend on May 16, 2017 9:41:44 AM

One of the most frequent questions I receive about encryption in the AWS cloud is “Who owns the encryption keys in the cloud?” and “Does Amazon have access to my keys?” I understand why this is a confusing question. I also understand why the question is important to many Enterprise customers. Cloud service providers don’t like to talk about this very much, so let’s spend some time running this to ground. We’ll start with the question about Amazon’s access to your encryption keys.

How to Meet Best Practices for Protecting Information in AWS by Stephen WynkoopAmazon Web Services provides two encryption key management options:

  • AWS Cloud HSM
  • AWS Key Management Service (KMS)

The answer to the question of key ownership depends on which service you are using. Let’s deal with the easy one first.

The AWS Cloud HSM is a physical hardware security module (HSM) that is dedicated to you. It is physically located in an AWS regional cloud data center, but only you have administrative access to the key server. Amazon is clear on the topic of encryption key ownership with the Cloud HSM service: Only you have access to the keys. Of course, Amazon has physical access to the HSM in their data center, but I think we can trust Amazon’s claim that only you have access to the actual encryption keys in a Cloud HSM server.

Now let’s turn our attention to the AWS Key Management Service, or KMS. This is a multi-tenant service provided by Amazon which is backed by an Amazon hardware security module. That is, Amazon creates a key that is only used by you, but that key is protected (encrypted) by an Amazon managed HSM. When you create a key in KMS it is called a Customer Master Key, or CMK. The CMK is actually a data structure that contains your symmetric key and meta data about the key. The CMK is protected by an Amazon HSM key. So, the answer to the question about who owns your key is straight-forward: You and Amazon share ownership of the encryption key and that ownership is equal. You both can access the raw encryption key.

Recently Amazon introduced a new “Bring Your Own Key” option for the KMS service. Does this change anything about who has access to the key? No, you are bringing your own encryption key and loading it into the AWS KMS service as a part of a CMK, but it is still protected in the KMS service by an Amazon HSM key. This means that you and Amazon share equal ownership of the key and both of you have access to the key. The only difference with Bring Your Own Key is that you retain the actual value of the encryption key outside of the AWS cloud.

So, to summarize: The AWS Cloud HSM service provides dedicated encryption keys that only you have access to. The AWS Key Management Service provides encryption keys and both you and Amazon have access to the key.

So, why is this important? Here are some comments that Enterprise customers have shared with me:

In almost every country both law enforcement and national security agencies have legal means to compel a cloud service provider to surrender data related to cloud customers. Certainly in the US this is the case, and it is true in most other countries. In the US it is additionally true that law enforcement and national security agencies may access this information and prohibit the cloud service provider from notifying you – the customer – that access has been granted. Cloud service providers like Amazon and others naturally abide by the laws of the countries in which they operate. But this means that your encryption keys in AWS KMS can be surrendered without your knowledge. You may not like this aspect of your country’s legal system, but it is a fact of life.

Why is this of concern to Enterprise customers? It is because significant law enforcement or intelligence service activity concerning your employees or customers may take place without your knowledge. If you are an executive in a large Enterprise you really want to know if there are potential problems in your workforce, or significant problems with a customer or service provider. Questions like these might arise:

  • Do I have an employee engaging in illegal activity?
  • Do I have multiple employees colluding together to engage in illegal activity?
  • Is one of my customers engaging in criminal activity that may compromise my business?
  • Are there managers in my organization that are breaking the law?
  • Is there some activity that may significantly damage my business reputation?
  • How can I deal with a problem if I don’t know about it?

When your IT systems are physically located in your data center law enforcement and intelligence agencies have to contact you to get access to data. That is not the case in the cloud – you will be in the dark in many cases.

In my experience Enterprise customers will cooperate with their legal requirement to provide data to law enforcement. This is not a question of cooperating with legal requirements to surrender data in a criminal investigation. But Enterprise customers really want to know when significant legal events take place that affect their organizations.

The critical concern is visibility of law enforcement and intelligence service activity that affects you. For this reason many Enterprise customers will not use the AWS Key Management Service. And because they do not have physical access to the Amazon Cloud HSM devices, they will not use this dedicated encryption key management service either.

I hope this clarifies some of the issues related to the Amazon key management options. Of course, these issues are not exclusive to Amazon, the same issues are relevant to the Microsoft, IBM and Google cloud platforms. There are good alternative options to cloud encryption key management services and we will cover those in a separate blog.

Patrick

How to Meet Best Practices for Protecting Information in AWS by Stephen Wynkoop

Topics: Amazon Web Services (AWS), Encryption Key Management

Financial Services and Creating a Security Strategy

Posted by Patrick Townsend on May 9, 2017 9:04:17 AM

I recently spent the better part of an hour talking to a new IT director for a small financial services company. He was feeling overwhelmed at the scope of the work ahead of him, and was bemoaning the lack of any guidance on how to start. The set of tasks in front of him seemed gargantuan in terms of the number of tasks and the scope of work. I can understand that sense of panic when you realize that you are behind the curve and that your organization is facing real threats. I want to share with you some of the advice I gave this IT director (with a tip of the hat to all of those hard working security professionals who’ve shared with me!).

It’s a Process, Not a Destination

Compliance Ready Encryption for Financial ServicesThe first error I see many IT managers make is that they look at security as a set of tasks to accomplish rather than a set of new IT processes. We technical folks really like to make a task list and check them off. We have a sense of accomplishment when we get to the end of the list. It’s done! Hallelujah!

Sorry, security is never done. It is important to realize that a security program means that many people throughout your organization are going to be doing things differently, and will be adjusting to new threats over time. For example, we used to think that the use of strong passwords was adequate to protect our access to corporate web services. But it isn’t enough now. Now we have to use multi-factor authentication in addition to strong passwords. Why? The attacks on password protected assets has become more sophisticated. We have to step up our game. And this is true across a number of security practice areas.

If you are successful you will be changing how your organization OPERATES over time. Not just completing a set of tasks.

Know Where Your Sensitive Data Is

It is very common that businesses do not actually know where their sensitive data resides in the organization, and where it goes outside of the organization. Business are always undergoing change to meet new objectives, counter emerging competitive threats, accommodate new technologies, and comply with new compliance regulations. Managing a business is like fighting a war on many fronts – it is barely organized chaos!

It is understandable then that an IT organization may not have a clear map of its critical data. But you will need that map before you can start really protecting those assets. For example, you might have data extracts uploaded to your web site for customers but not know that the upload process was put in place 5 years ago and the development has moved on. That sensitive data just gets uploaded every night and might not be properly protected.

It’s time to do some archeology.

Be sure you have an inventory of all of your critical applications along with the data the process. This is going to seem like a tedious job, but it will be critical to everything you do. Make the map and then hold a celebration and invite your executive team.

In the process don’t forget the data feeds. Document every place that data enters your organization from the outside, and where you send data to outside services.

Find a Dynamic Security Framework

Now you need a plan! Fortunately you won’t have to figure out a plan on your own. There are several good sources of dynamic security planning guides that you can use as a starting point. A good plan will cover the essential security tasks, and will prioritize them by importance. A complete plan with prioritized tasks will help you focus your attention in the right areas!

Here are some sources for security plans that you can access and use right away:

The great thing about these security plans and frameworks is that you can get started with them very quickly. For example, the CIS Critical Security Controls is available as an Excel spreadsheet. You can make a copy and start working through the sections from top to bottom.

Do the Important Things First

We are sometimes tempted to do some of the easy things first in order to convey a level of accomplishment to our management team. I recommend that you try to resist this tendency as much as possible. Start with the most important items in your priority list and tackle those first. They often give you a lot of security benefit and many do not require a lot of investment or work. It is important to do the most effective and critical tasks first.

Get Your Management Buy-in

Security takes commitment, human resources, financial resources, and much more. You will need to get your management buy-in as quickly as possible. Start by sharing some stories from other companies in the financial services segment. We don’t necessarily want to scare our managers, but they need to have a realistic idea of the threat.

Educating your management team means explaining your need for budget resources. Some things can be done on the cheap, and you won’t want to overlook inexpensive steps to take that improve security. But some things are going to take some budget dollars to deploy. For example, continuous monitoring of system logs with a SIEM solution is one of the most effective security strategies you can deploy. But this will almost certainly mean the deployment of a commercial SIEM solution and this will require fiscal expenditures.

Any steps you take to educate your management team will be worth the effort.

Don’t Forget About Employee Education

Remember that you live in the security world, but the employees in your organization don’t. They are not likely to be up to date on the latest threats. Educating employees on how to identify spam email messages has a lot of benefits. Find ways to work in a few minutes each week into employee schedules a simple security awareness exercise.

You’ve probably heard of Bug Bounties – how about providing some small rewards to employees that discover and report spam emails with potentially harmful content? It is amazing how effective programs like this are.

Rinse and Repeat

Let’s go back to that first point. A security program is something that changes how you and your colleagues live your professional lives – it is not a set of checkboxes. Create an annual calendar of security tasks and review points. Make sure that this includes periodic reviews with the upper management team. If you are doing this right you will be making periodic adjustments to the security program and things that are important today may be eclipsed by new threats tomorrow. That’s not a particularly happy thought, but if you keep adjusting you will be in a safer position.

Finally, we make progress one step at a time. Once you start down this road it will get easier as you progress. Good luck with your new security programs!

Patrick

Compliance

Topics: Data Security, Security Strategy

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?

Encryption Requirements 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.

Encryption

Topics: GLBA/FFIEC

Splunk, Alliance LogAgent, and the LEEF data format

Posted by Patrick Townsend on Apr 18, 2017 7:09:08 AM

We have a lot of Enterprise customers deploying our Alliance LogAgent solution for the IBM i server to send security events to Splunk. On occasion a customer will deploy Alliance LogAgent and send data in the Log Event Extended Format (LEEF) to Splunk. The LEEF format is the preferred log data format for the IBM Security QRadar SIEM, so I’ve always found this a bit puzzling.

IBM i Security: Event Logging & Active MonitoringThe light finally came on for me this week.

Security event information in syslog format (see RFC 3164) is largely unstructured data. And unstructured data is hard for SIEM solutions to understand. Here is an example from an Apache web server log:

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

An SIEM administrator would have to do a fair amount of work configuring the SIEM to properly understand the importance of this message and take the proper action. If only the data was in some type of normalized format!

It turns out that the IBM Security QRadar LEEF format normalizes the system log information. A message like the above might look something like this in LEEF format:

date=20001011 time=143252 ipAddress=127.0.0.1 violation=client denied severity=5 path=/export/home/live/ap/htdocs/test

With field definitions like “date” and “time” the Splunk SIEM can easily digest the message and the Splunk query tools work great. It is easy to create reports and dashboards with this type of normalized data. The LEEF format is really good about this and Alliance LogAgent supports the LEEF definition.

What most Splunk administrators do not realize is that our Alliance LogAgent solution normalizes all IBM i security events in this type of normalized fashion. That is, this format is the default data format for security events. This is already what Alliance LogAgent does for IBM i security events!

When we started the development of Alliance LogAgent more than 10 years ago we understood at the outset that system log data would be hard for a SIEM to parse. So from the first release of our solution we provided data in this normalized format. Whether you are using Splunk, LogRhythm, Alert Logic, or any other SIEM we make it really easy for the SIEM to digest and act on the information. And forensic, query, and dashboards are easy to create.

So, Splunk users - listen up! The default system log format in Alliance LogAgent is exactly what you need to make Splunk work really well. You can use the LEEF format if you really want to, but you have all of the benefits of normalized data with the default format.

Here at Townsend Security we are vendor neutral when it comes to SIEM solutions. Our customers deploy a wide range of solutions including Splunk, IBM QRadar, LogRhythm, Alert Logic, SolarWinds, McAfee, and lots more. And they can move from one SIEM to another without changing their Alliance LogAgent configurations. We believe that actively monitoring system logs in real time is one of the most important security steps you can take. Early detection of a problem is so much better than trying to remediate a breach after the fact.

Patrick

IBM i

Topics: Alliance LogAgent, Splunk

Trying to Outfox the Other - A Brief Look at Cryptography and Cryptanalysis

Posted by Ken Mafli on Mar 31, 2017 10:35:55 AM

 A few months ago I wrote a definitive guide to Cryptographic Key Management. In it I wrote a section: A Brief History - the Need for Encryption Key Management. I wanted to expand upon the Classical Era of cryptography a bit because the story of data security goes back for millennia, and the twists and turns of this story can be felt even today.

Introduction

eBook: Definitive Guide to Encryption Key ManagementThere has been a competition playing out through the centuries all the way from the highest corridors of power down to the shadiest back alleys. It is a struggle of those with a secret and those who want to uncover it. It is the story of cryptography and cryptanalysis.

As with every competition, each side is constantly trying to outfox the other. Peter Baofu described the competition this way, it is “the never ending cycle of replacing old broken designs” of cryptography and “new cryptanalytic techniques invented to crack the improved schemes.” In fact, “in order to create secure cryptography, you have to design against [all] possible cryptanalysis.” This means that both sides are in a never-ending arms race.

In his book, “The Future of Post-Human Mass Media,” Peter Baofu describes two main types of cryptanalysis: Classical and Modern Cryptanalysis. Let’s take a look at the Classical Period to see how this cat and mouse game has played out through the centuries:

The Classical Cat-and-Mouse Game

Classical Cryptography

One of the earliest forms of “secret writing” is the Substitution Cipher where each letter of the message is systematically replaced by another set of predetermined letters. In it’s most famous form, the Caesar Cipher, used by Julius Caesar himself (1st century, B.C.E):

“each letter in the plaintext is 'shifted' a certain number of places down the alphabet. For example, with a shift of 1, A would be replaced by B, B would become C, and so on.”

Another technique was Steganography, which literally means: “covered writing,” is the art of concealing a message in plain sight. Mehdi Khosrowpour recounts one of the first recorded instances (in the 5th century, B.C.E):

“Demaratus, a Greek who lived in Persia, smuggled a secret message to Sparta under the cover of wax.” It “ was to warn Sparta that Xerxes, the King of Persia, was planning an invasion ... by using his great naval fleet. He knew it would be very difficult to send the message to Sparta without it being intercepted. Hence, he came up with the idea of using a wax tablet to hide the secret message. In order to hide the secret message, he removed all the wax from the tablet, leaving only the wood underneath. He then wrote the secret message into the wood and recovered the tablet with the wax.”

Classical Cryptanalytic Response

While steganography is only hard to crack if you don’t uncover the message; substitution ciphers were meant to remain a secret even if the message fell into enemy hands. It remained a fairly reliable means of securing messages, so long as the cipher was not revealed.

All that changed with the first recorded technique of cryptanalysis: Frequency Analysis. This technique “can be traced back to the 9th-century [C.E.], when the Arabian polymath Abu Yusef Yaqub ibn Ishaq Al-Kindi (also known as ‘Alkindus’ in Europe), proposed in A Manuscript on Deciphering Cryptographic Messages.” It comes from the observation that certain letters appear more often than others in a given language (the letter “E,” for example, occurs most often in English). There also also common letter pairings (like “TH” in English).

So, in the case of the Caesar Cipher where the plaintext message is :

meet me at the theater

If each letter is shifted one letter in alphabet, it becomes:

nffu nf bu uif uifbufs

Frequency analysis would note that the most common letter in the ciphertext is “f” (which would suggest it is an “e”) and only letter pairing is “ui” (which would suggest the “u” is “t” and the “i” is “h”). If we replace these portions of the ciphertext we reveal:

_eet _e _t the the_te_

With these two facts of frequency analysis alone we have more than half the message deciphered. With a few logical leaps we could decipher the remaining the five letters. The simple substitution cipher was rendered useless.

The Classical Cryptography Counterattack

Polyalphabetic.jpg

Over the centuries other ciphers were introduced like the Polyalphabetic Substitution Cipher where a repeating, offset key is used to encrypt the plaintext (see picture, courtesy of the Library of Congress). First perfected by Johannes Trithemius in 1518 (although other variants existed beforehand), the person encoding the message would switch alphabets for each letter of the message.

So, “meet me” would now become: “lcbp gy,” a ciphertext that simple frequency analysis could not break since most of the letter and pairing statistics of a given language are not easily recognized.

Although, in time, this type of cryptography was broken by the likes of Charles Babbage using modular arithmetic, the existence of his cryptanalytic techniques remained a military secret for some years.

Final Thoughts

Fascinatingly, it was the use of math to break a cipher that led to our current arms race in data security. The use of math and algorithms to break cryptography means you need longer keys to encrypt the data and prevent a brute force attack; which, in turn, means you need faster computers to break the encryption; which, in turn, means you need longer keys; etc.

Unlike today, however, it took centuries to break a cipher back then. Now, it is just decades. From the Hebern Electric Super Code Cipher Machine in the 1920s, to the Enigma Machine of the 1930s and 40s, to the Data Encryption Standard (DES) of the 1970s and 80s, each seemed invincible until enhanced cryptanalytic techniques or greater computing power toppled it. Our current cryptography is reliable and secure, but quantum computers loom on the near horizon and their non-binary logic could brute force attack our current public key cryptography and make them insecure.

And so the arms race continues. Fortunately, NIST has already forecasted this threat and called for replacements to our current standards, well before it is a crisis.  

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption

 

 

Subscribe to Email Updates

Posts by Topic

see all