Townsend Security Data Privacy Blog

CISOs often can have an arduous time getting budget. To top it off, they are tirelessly thinking about how to improve security programs, justify what they are currently doing, and getting the budget they need for next year. When it comes to improving budget, CISOs need to trade their technology hat with a colleague in the sales or marketing department.

When it boils down to it, a CISO is not technology provider, but rather business solution provider. This can sometimes be a hard realization to make. Especially after spending the first part of your career immersed deep in the technology weeds. For the new CISO, and even seasoned veterans, it can be a challenge to learn to sell and market your ideas (and get funding from) the various stakeholders within the company. It is imperative for the CISO to market and sell the security side of the house to the business at large to get what they need.

Speak Their Language
Not too long ago, the CISOs job was to walk to the C-suite and say, for example, “Hey, we need encryption and key management. Give me the budget and I will go make that happen.” Back in the day, they would usually get the money. Now it is more about building relationships and having a business problem to solve.

With times changing, now it is important to better understand what technologies the stakeholders are hearing about and how you can leverage their knowledge of current security events to bolster your security program. Many of the stories that in the past would have been exclusive to publications like CSO Online and Krebs on Security are now showing up in places like Forbes, Businessweek, and the Wall Street Journal – places where your stakeholders go to get information.

When we look at what is being covered by the mainstream media, it is stuff that security professionals have had to deal with for years, but was relatively unknown to the upper echelons of the company. When security admins talk about data breaches, they talk about SQL injections or the best practice for data protection and how to manage a database – IT vernacular.

It is important to remember that the executive team doesn’t speak your language. When they talk about someone impersonating the CEO via email and exposing W2 information, they don’t know that this is called a “phishing attack.” Security professionals know this, but that isn’t what they call it in USA Today. You have to understand how to make those connections and draw those lines for people.

Sell and Market Your Program
You will have an opportunity from time to time to engage stakeholders for 30-seconds to 2 minutes. When you have those chances for an interaction, you need to sell your program. You need to practice it and have it come across very natural and as you would normally talk. Some suggestions:

• Talk about the great things that you are doing and that you want to do more of it
• Make sure that they understand your successes
• Don’t talk about stuff that doesn’t matter – that is not how you get a budget

It is also important to have various elevator pitches, depending on who you are going to be talking with. For example, if you have 30 seconds with a CIO or director, the pitch is going to be different for each one, because they care about different things. Remember, when you talk with them, it has to be about something that they care about. The secret to success is to sell your program and the services of your group. Don’t just talk about building a security kingdom, but rather business solutions.

Often, when you think about selling, you think about selling to the CFO or even the board. You don’t often think about it, but you do in fact have to sell to the SOC (Security Operations Center) manager or other teams or lines of business within the organization. You may not be asking them for funding, but you need to get them on board so that when you do go to whoever you need to make the big pitch to, they will have your back. It is a much easier sell when there is a choir of voices saying, “Yeah, this is what we think that we need. This is the solution that we want. We have already bought into the fact that this is what we need.” If you can get 3 or 4 other directors from different lines of business backing you, you will be much more successful at actually getting funding than if you were to say “This is what I think is needed” and the board replies “What does the SOC manager think?”

If your funders still need more convincing, compliance regulations can often help your cause. Regulations like PCI DSS and HIPAA (as well as others) are constantly evolving, going through review and update, and bringing in stronger language and more stringent security demands. PCI DSS, in particular, carries a big stick. Whether you love it or hate it, it can often get you what you need because your business has to comply if they want to take credit cards.

External audit findings can also help propel your security program forward. When they come back negative, business risk has been identified – and business risk speaks very loudly to the C-suite. It is in their charter to acknowledge business risks and take appropriate actions.

Finally, and unfortunately, there will be times that you are simply told “No, there just isn’t budget for _______.” But what you can do, because you are a smart CISO, is go into your backup pitch. Just because you didn’t hit a “grand slam” doesn’t mean that getting a “single” or a “walk” is out of the question. Your “walk” should be the absolute bare minimum needed to move your cause forward, at least a little. Even the guy that gets walked is going to score from time to time. If you can take a “walk” and deliver something with it, you are going to further gain the trust of your funders and establish a positive track record for delivering on time and on a budget.

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."

The evolution of computing and delivery platforms continues at a rapid pace and this presents substantial challenges as organizations of all sizes attempt to deploy data protection strategies. Security professionals now know that Data Centric Data Protection, or encryption, is crucial to their security strategy. Deploying encryption means properly protecting encryption keys. This is the biggest challenge organizations will face with their encryption strategy. The large investment required to develop defensible key management implementations, the importance of key management to critical data infrastructure, the rush to cloud and hybrid implementation.

Encryption Finally Takes Off

Encryption of sensitive data, sometimes called Data Centric Data Protection, has not been a high priority in many organizations. Investments in security have focused on deploying endpoint protection such as anti-virus and data leak protection, active monitoring and alerting of system logs, and other security features. While encryption is a core security requirement, it has not had as much attention and many organizations are lagging in this key security control.

The large data breaches over the last two years and the resulting impacts on the executive teams, along with resulting brand damage, has changed all of that. Customers, employees and all other stakeholders expect the highest levels of executive management to be pro-actively involved in the protection of sensitive data. When CEOs lose their jobs over a data breach, the industry is poised for change. Encryption and data protection are now considered cornerstones of a company’s governance, risk management, and compliance regime. Failures in data protection are now perceived as failures at the highest levels of management. Additionally, the State of California’s recent guidance that a minimum reasonable level of security requires the full implementation of the CIS Critical Security Controls, will force organizations to fully adopt encryption protections. This is leading to a rapid re-focus of the security strategy on data protection with strong encryption and key management. This will continue in the months and years ahead.

Take Aways

• Review your defense-in-depth security strategy and move quickly to protect sensitive data with strong encryption and key management.
• Be sure your IT department has a clear inventory of sensitive data across all of you internal systems, cloud solutions, and service providers. Know what is protected and what is at risk.
• Prioritize your encryption projects to address the most sensitive and exposed data.
• Every implementation of encryption needs good encryption key management. Start a remediation plan for any current encryption implementation that fails to properly protect encryption keys.
• Communicate your security strategy to your customers, employees and stakeholders. Let them know that data protection is important.

Encryption for Data at Rest
Linux applications use a variety of database and storage methods that include MySQL, MongoDB, PostgreSQL, Amazon S3 and RDS, and many others. Like any application deployed on any operating system and storage mechanism, Linux applications need to protect sensitive data at rest using strong encryption. Compliance regulations, state and federal laws, customers, employees, and stockholders expect data to be protected and Linux developers know this.

The most common method of encryption for data at rest is the Advanced Encryption Standard, or AES. Sometimes call Rijndael, reflecting the names of the original authors Joan Daemen and Vincent Rijmen, AES is now an international standard. Using AES encryption will align you with these standards and with all major compliance regulations. Fortunately, AES is now available in a wide variety of development languages and software libraries. On the Linux platform, you will find ready-to-use AES encryption support in development languages like Java, PHP, Python, Perl, Ruby and many others. The OpenSSL software library also provides access to AES encryption.

Using the Right Mode of Encryption
AES encryption can be implemented via several modes of operation. Electronic Code Book (ECB) is the basic raw mode of operation, but you should avoid it for business applications. It can leak information when encrypting repetitive data. Probably the most common mode of operation for protecting business data with AES is the Cipher Block Chaining (CBC) mode. It takes a random Initialization Vector (IV) which helps prevent leaking information when encrypting repetitive data. You will find support AES CBC mode in all of the primary languages and software libraries. There are other modes of encryption that use IVs, but you will find AES CBC is most commonly used in business applications.

Initialization Vectors
Assuming you are using a mode of AES encryption that uses an initialization vector such as CBC, be sure that you are using a good random number generator to create the IV and that it is unique for each item that you encrypt. In other words, don’t use a fixed IV and don’t re-use an IV in your application. If you use this practice for generating unique IVs you won’t need to protect the IV with encryption as it is not considered cryptographic material. However, if you have especially sensitive data or a lot of it, it won’t hurt to take the extra precaution of encrypting the IV.

Encryption Key Management
Now we get to the hard part that most developers get wrong about encryption - the protection of the encryption keys. A good encryption strategy depends on the use of strong encryption keys, and the protection of that key. Encryption keys that are weak or that are stored on the same server as the sensitive data are likely to provide little real protection. Common poor practices include:

• Using a password as an encryption key.
• Using a flawed or non-standard random number generator to create a key.
• Storing the encryption key in the application code or in a SQL statement.
• Storing the encryption key in a file or table.
• Storing the encryption key with poor protection (XOR with weak data, etc.).
• Storing the encryption key with password-based encryption protection.
• Storing the encryption key on a mounted drive.

These are just a few of the practices that can set you up for a data breach and compliance audit failure. Use a good key management system that is designed for that purpose and which meets industry standards like FIPS 140-2.

Retrieving a Key vs. Using an Encryption Service
Assuming you are protecting the encryption key properly, you need to decide if you want to retrieve an encryption key from a key manager and then use it to perform encryption, or if you want to use an encryption service provided by the key manager. If you are developing an application in a more exposed environment such as a cloud platform, or an internet-facing web server, you may want to reduce the risk of encryption key loss by using an encryption service on the key manager. All encryption is performed on the key manager and the key never leaves the key management server. This can provide additional protections against the loss of the key.

If you are encrypting large amounts of data, or making many encryption requests in your application, retrieving the encryption key once and using it many times can provide a boost in encryption performance. Remember to securely erase the key when you are finished with it.

Key Management and Business Continuity
When you use a key management system it becomes a part of your critical infrastructure. This means that it is particularly important that the key management system provide a high level of redundancy and implement best practices related to backup and restore. If you are using a hardware security module (HSM) it should implement redundant power supplies, hot swappable RAID disk drives, and redundant network interfaces for maximum resiliency. All key management systems should implement real-time, active-active key and policy mirroring, automatic recovery from network failures, manual and automated backup, and a high availability failover strategy. The ability to implement geographic redundancy between primary and secondary key servers should be fully supported, and this can be a challenge on some cloud platforms.

Key Management and Key Custody
Who has access to your encryption keys is becoming a hot-topic issue for many organizations. In many regulated environments you must insure that unauthorized access to keys or compromised keys can be detected and managed by your organization. This is not always possible with some cloud service provider key management services. Additionally, access to encryption keys by law enforcement or government agencies may happen without your knowledge. Be sure that your key management strategy gives your organization exclusive access to encryption keys and prevents the key management vendor, cloud service provider, or another other entity from accessing encryption keys. You should be able to receive clear and unambiguous assurances from your key management vendor or cloud service provider on this question.

Key Management and Virtualization
Most organizations now deploy their Linux and Windows applications in virtualized environments such as VMware. Almost all encryption libraries and language implementations of encryption are compatible with VMware and other virtualization platforms. The same is not true for key management solutions and vendor-provided SDKs. Even if your Linux application will not be deployed on VMware today, be sure that you implement an encryption key management strategy that will allow deployment of the key manager in a secure workgroup in VMware. The key manager should be fully virtualized and able to support a no-hardware approach to deployment in VMware.

Key Management and the Cloud
If your Linux applications will be deployed on a cloud platform it can be tempting to use the key management services of the cloud service provider. These services are very low cost or free, and are therefore attractive. Think hard about this before you make this decision. Besides key custody issues (see above) most key management services on cloud platforms use proprietary interfaces to their key management services. This locks you into the particular cloud service provider and makes it difficult to migrate to other platforms. It also makes it extremely difficult to implement dedicated key management services outside of the cloud platform. As attractive as cloud key management services appear to be, there are definite downsides to binding your Linux application to one specific cloud platform.

Key Management, Developers, and SDKs
Linux developers need maximum flexibility as they deploy applications and web services. One application may be based on the Java language, another on Python, another on Ruby, and so forth. There is a rich ecosystem of development languages available to Linux developers. When deploying encryption key management to protect encryption keys be sure that you have access to a rich set of SDKs that work naturally across all of these environments. When you deploy a Java application you want a Java SDK to enable key management. Attempting to cobble together a solution using different language SDKs is going to be a difficult and unpleasant process, not to mention the problems with supporting hybrid language environments.

Key Management for Linux ISVs
If you are developing a Linux application to take to market you have a number of other issues to consider. Your customers will want to run your solution in a variety of ways. Some will be happy with a low cost, multi-tenant cloud solution. Others will want to deploy in a dedicated virtual private cloud. Others will want a traditional IT data center approach, perhaps with VMware infrastructure. And key management requirements will be all over the map. Shared multi-tenant key management, dedicated cloud key management, dedicated virtual cloud key management, and true hardware HSMs will all come into play. Be sure that your key management solution works well in all of these environments and bridges them in hybrid deployments. Getting this right from the beginning will be important to your success as a Linux ISV.

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires that medical providers, called Covered Entities, implement data security to protect patient information from disclosure. Sensitive patient data is termed “electronic protected health information”, or ePHI, and includes information like patient names, addresses, social security numbers, procedure codes, birth dates, and much more. All Covered Entities, which is almost everyone in the healthcare system, must implement these data security controls. As a matter of law, a Covered Entity that fails to protect patient information and suffers a loss or exposure of that information must make a formal data breach report to the US Department of Health and Human Services.

Because many of the losses of patient data happened not by Covered Entities, but by vendors and service organizations they hire, the regulations were amended to cover Business Associates. Any Covered Entity that shares patient information with an outside organization must now have a Business Associate agreement with them that binds them to the same patient data protections that HIPAA requires of Covered Entities. This plugged a hole in the original HIPAA law that resulted in patient data loss through outside vendors. Everyone who handles ePHI, inside or outside the medical industry, is now obligated to implement the HIPAA data security rules.

So, to the basic question: Do I have to encrypt patient information?

The answer is Yes, but the rule allows for some exceptions. Let’s examine this more closely, because those exceptions get a lot of Covered Entities into trouble.

The HIPAA regulation requires the encryption of patient information when stored on disk, on tape, on USB drives, and on any non-volatile storage. This is called encryption of data at rest. The HIPAA regulation also requires the encryption of data as it moves across a network via a web browser session, FTP or any other method used to transfer data. This is called encryption of data in motion.

The relevant regulations which say you have to encrypt ePHI are these:

45 CFR 164.312(a)(2)(iv)

45 CFR 164.312(e)(2)(ii)

The regulations are simple and very easy to read. I suggest that you take a quick look. Just a few sentences define the requirement.

Notice that there is no mention of laptops, backup tapes, USB thumb drives, tablets, phones, or anything else in the regulation. If it is “electronic protected health information”, or ePHI, it must be protected.

Now we have to take a little side trip. Notice that this security control is “addressable”. What does that mean? Here is the formal definition for an addressable control.

So now you know that there is not a hard mandate to encrypt patient data if you can document that there is a reason you can’t do it, AND if you have an alternative that is equivalent to encryption. You might argue, for example, that it is expensive to do encryption. Or that it is really, really hard to do encryption. Those may actually be valid arguments. If you make that argument you have to document your reasons, and you have to provide a reasonable, appropriate, and equivalent alternative to encryption.

Notice those words “reasonable”, “appropriate”, and “equivalent”. Those are the words that are likely to get you into a lot of trouble. If you decide not to use encryption, you are committing to using something that is an equivalent method of protection, and you are committing to documenting your reasons.

Covered Entities put themselves at risk when they decide to use addressable controls for encryption. Those include:

• Failing to document the reasons why encryption can’t be used.
• Failing to document the particular hardship that encryption entails.
• Failing to implement a reasonable alternative to encryption.
• Failing to implement an equivalent method of protection.

When a Covered Entity experiences a data breach, the fact that data was not encrypted and the fact that the alternative method did not prevent the data breach, will put you at direct risk for a compliance action. It will be hard to argue that you’ve used a protection method that is equivalent to encryption when you’ve actually lost the patient data! It is going to be hard to win that argument.

If you review a number of the Corrective Action Plans (CAPs) for data breaches you will find that there are often a number of failures involved in the data breach besides the loss of unencrypted ePHI. Improper documentation and inadequate staff training are almost always involved when OCR issues a fine and CAP over a loss of patient data. But the failure to encrypt ePHI is always involved.

Now we are back full circle to our question: Do I have to encrypt patient information?

I think you can see now that the answer is "Yes". You need to encrypt patient data in order to provide adequate protection to your patients AND to your organization as a whole. It’s the only defensible strategy in light of how HIPAA, HHS, and OCR will evaluate your data breach.

We work with a number of Covered Entities around data protection and the implementation of encryption. I know that almost all Covered Entities have gaps in their implementation of encryption. Here are a few things you can do right now to start to address these:

• Make an inventory of all of the systems that store or transmit patient data.
• Identify all of the systems where encryption is not implemented.
• Prioritize the implementation of encryption for all of these systems. In many cases this will mean working with a software or hardware vendor.
• If vendor updates are available that add encryption capabilities, schedule those updates as soon as possible.
• Immediately notify all of your software and hardware vendors that you expect them to implement encryption according to industry standards, and that future acquisitions will require this security control.
• Remember that a proper implementation of encryption involves protecting encryption keys from loss. Be sure that encryption keys are stored away from patient data on key management servers that are designed to protect encryption keys.
• Make an inventory of all Business Associates that receive patient data from you and be sure you have a signed Business Associate agreement on file.

Encryption is far easier to implement now that at any time in the past. Covered Entities have lots of options and don’t have to be at risk of a compliance action.

Pretty Good Privacy (PGP) is a mature and well-regarded whole file encryption application. In partnership with PGP Corporation, McAfee and now Symantec, we’ve implemented PGP Command Line on both the IBM i (iSeries, AS/400) and on the IBM System z Mainframe. Our customers often have questions about PGP compatibility with open source implementations like Gnu Privacy Guard, or GPG. Let’s dive into this a bit deeper.

Before we jump into a discussion of solutions and their compatibility, it’s important to know about the Internet standards for PGP. These standards are defined in RFCs 2440 and 4880. The standards are referred to as the OpenPGP standard. These Internet RFCs define the format and behavior for any application that claims to support the OpenPGP standard. They do not define an application, and the term OpenPGP does not refer to any actual application or solution. It is just the name of the standard.

We have a standard for PGP, so now we need to identify which applications implement the standard. That’s important because we want our PGP encrypted information to be supported by the largest number of platforms and vendors.

In the open source world there are several solutions that implement the OpenPGP message format and conform to the RFC standards. Probably the most well known is the GNU Privacy Guard, or GPG, application. It is available on several operating system platforms including Windows, Linux, and Unix. GNU has a large community of developers who support this application and it is readily available. Other open source implementations include Bouncy Castle, the International PGP organization, Portable PGP, and others. While GNU Privacy Guard is actively maintained, other open source implementations may not receive as much on-going attention from developers.

Because of its history with the original developers of the PGP, the most common commercial version of PGP is provided by Symantec. Here at Townsend Security our relationship with Symantec allows us to bring the commercial version of PGP to IBM Enterprise platforms IBM i and IBM System z. We’ve been supporting PGP on the IBM platforms for more than a decade. Other commercial versions are provided by Viacrypt and SDS and are supported by those companies.

The OpenPGP standard assures customers that encrypted files can be processed by any application that supports that standard. The open source and commercial versions mentioned above do implement support for the OpenPGP standards.

The OpenPGP standard is reasonably complex and it is easy to inadvertently introduce incompatibilities. Interoperability testing is crucial to avoid implementation errors. Since there is no independent certification authority for PGP it is up to the open source and commercial vendors to perform interoperability testing. Here at Townsend Security we test our implementation against a variety of open source and commercial versions. We also perform the cryptographic test suite defined by the National Institute of Standards and Technology (NIST) to insure that our implementation of PGP Command Line meets all of the relevant encryption standards. In this respect we are standing on the shoulders of those original giants of the PGP world who brought us PGP and who regularly performed NIST FIPS 140-2 validation.

The IBM Enterprise servers are quite different than their Windows and Linux operating system cousins. You might wonder how easy it is to use PGP on these platforms. Our developers at Townsend Security have worked hard to adapt PGP to these platforms without impacting the implementation of OpenPGP. For example, PGP Command Line for the IBM System z Mainframe fully supports Batch z/OS, multiple z/OS file systems, z/OS text files, and built-in support for code page conversions. Combined with a number of JCL examples of encrypting, decrypting and signing files with PGP it provides a powerful implementation of PGP on that platform.

Our customers on the IBM i and IBM System z regularly exchange encrypted files with partners running GNU Privacy Guard. That compatibility is important to us and we will continue to validate our commercial PGP implementation with GPG through interoperability testing.

Patrick

“You have to encrypt your data!” More and more IT professionals, security architects, and executive leaders in the C-Suite are hearing these words. It’s no longer a question of IF there will be a data breach, but rather WHEN. And of course not just anything will do, you need NIST and FIPS 140-2 compliant solutions to help you make sure the investment you make doesn’t simply crumble when push comes to shove.

What does that all really mean? It means it’s important for you and your team to vet a solution deeply and ensure the vendor that created it dotted their i’s, crossed their t’s and hopefully didn’t cut any corners when they put their product to market. Makes sense, but again, what does that really mean????

The vendor should be established in the industry and should have gone through the proper reviews of their encryption solution. Those reviews help you determine whether they made the right choices when they created the security product you are planning on betting your company’s and your future on. A vendor that creates an encryption solution and has it NIST validated took the extra time to learn and understand the reasons NIST asks for those standards to be followed. Then they took the time to implement their solution following those standards. And then lastly the vendor took the time to get the solution reviewed and validated by a reputable and independent third party. In a study of the validation program, NIST found nearly 50% of software vendors had errors in their encryption solutions. It isn't easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do - every time.

When comparing encryption solutions, what are things you want to look for to make sure you are getting a solid product? You want the key generator to be using a Random Number Generator sequence that is as close to true random as possible. You want the solution to use the same technology when generating a strong Initialization Vector (IV) as well, and you want this solution to run the encryption algorythm true to its standard. (Why is that important? Check out this blog) You also can’t forget about encryption key management, an often overlooked but equally crucial aspect of strong encryption. Only then can you trust that when the pieces of the puzzle are put together and your data is encrypted, it was done so in a manner that can’t be undone WHEN you have that upcoming data breach.

As we all know time, in every essence of today’s world, equals money. The time the vendor invested in this process costs the vendor money. The time that was invested in reviewing the solution most likely cost the vendor money as well. The good news is that because of this you, your company and your IT team don’t need to spend that same time creating an encryption solution in house. I think so far we are most likely in complete agreement. So where’s the problem?

Several recent industry reports show that although more and more companies are asking their IT teams to implement this right kind of robust, validated encryption to secure their or their customer’s data, they are being asked to do so with less and less money in their budgets. Certainly the notion of ‘doing more with less’ is nothing new and efficiency should be a goal, the truth remains even in the data security industry what you pay for it what you get. Good encryption is now freely available, but good key management requires an investment. If you don’t commit the necessary resources to your data security projects you will not have a data security result that will protect your data (and you) WHEN that data breach occurs.

Excerpt from the White Paper "MySQL & VMware - Encryption and Key Management for Developers."

Whether you develop mostly on Linux or Windows, you can achieve a compliant implementation of encryption with the MySQL database and variations of MySQL like MariaDB. This blog looks at some key decisions you will need to make about the encryption approach, and how we help our customers get encryption right.

Using the MySQL Built-in Encryption Primitives

MySQL supports a number of encryption and encoding operations directly from the SQL language. When encrypting a column you can use the ENCRYPT function, AES_ ENCRYPT function, the older DES_ENCRYPT function, or the encoding or compression algorithms. If you want to use this approach to encryption and decryption, I would recommend that you use AES_ENCRYPT and AES_DECRYPT. For this, primitive MySQL uses the industry standard 128-bit AES algorithm, which is considered strong encryption and meets compliance regulations.

While the DES_ENCRYPT support is still a part of recognized industry standards, you will have a performance benefit when using the stronger 128-bit AES support and are not likely to run into the problem of a future deprecation of the Triple DES algorithm used by the MySQL DES_ENCRYPT method.

Here is an example of a MySQL insert statement that uses AES_ENCRYPT with a hex representation of the encryption key:

INSERT INTO t
VALUES (1,AES_ENCRYPT(‘text’,UNHEX(‘F3229
A0B371ED2D9441B830D21A390C3’)));

Of course, hard-coding the encryption key is poor security practice.

Encryption at the Application Layer

Encrypting and decrypting directly in your SQL statements is not always possible or optimal. Don’t worry, you can also implement encryption in your application code if that makes more sense. Our Alliance Key Manager includes several language-specific software libraries for developers. For example, if you are a Java developer you can install and use our Java .jar files for full support for encryption key retrieval and on-device encryption. If you are a Windows C# developer you can add our Windows .NET Client to your Visual Studio project and have full support for key management. Both Java and C# have great support for encryption - you won’t need support from third parties for AES encryption - but you will need to implement encryption key management the right way.

What are some reasons you might want to do encryption at the application layer?

• Minimize the changes to SQL for different databases.
• Take advantage of the stronger 256-bit AES encryption method.
• Use an AES mode of encryption that uses an Initialization Vector such as Cipher Block Chaining (CBC) mode.
• Embed information in the encrypted field about the key used, the version of the key, and the IV.
• Create custom logic for encrypting larger blobs in the database.

Whatever the reason or combination of reasons, implementing encryption at the application layer is an easy choice to make with the Alliance Key Manager language SDKs.

Where are the Encryption Keys?

The single biggest challenge a developer will face when deploying encryption for MySQL is how to properly manage encryption keys. Not getting it right leaves the organization open to security failures, audit failures, and litigation. Here are some ways NOT TO STORE encryption keys:

• As a part of the SQL statement (see above).
• In the application code.
• In a file on the same server.
• In a file on a separate server.
• In a separate table in the MySQL database.

All of these approaches have been the cause of security audit failures for our customers. Don’t let this happen to you.

Summary

Developers are the tip-of-the-spear when it comes to protecting their organizations from data breaches. When they are aware of the critical success factors for an encryption strategy they can dramatically improve the overall security posture of their companies.

At Townsend Security we provide developers with the tools they need to be successful and to get encryption right. Our key management solution, Alliance Key Manager, runs in all of the platform environments that developers need. The applications and software development kits that come with Alliance Key Manager run in VMware, the cloud and everywhere else you might deploy the MySQL database.

Because Townsend Security provides encryption for IBM System z Mainframes we often get asked about system logging for that platform. Our Alliance LogAgent solution provides system log collection for the IBM i (AS/400, iSeries) platform, so this is a natural question from Mainframe customers.

We don’t have a solution for IBM Mainframe customers, but I am happy to report that our partner CorreLog does! IBM System z Mainframe users can deploy the CorreLog solution and get the same types of security event collection and SIEM integration that we provide in Alliance LogAgent. The two products are not exactly the same in terms of features, but CorreLog will give you the security event collection and SIEM integration that you need.

Like the IBM i platform the IBM Mainframe contains a lot of sources for security event information and the data must be transformed into a usable format and transmitted to a SIEM. This is a daunting task for even an experienced Mainframe developer, so this is a perfect area for a third party product. CorreLog has just the right solution to make this happen.

IBM has been enhancing the System z Mainframe to bring it into the modern Internet-connected world. This means you have more security attack points on this venerable platform, and need to deploy modern security tools to protect it. Active monitoring of security audit logs by a SIEM solution is a must-have for Mainframe shops and CorreLog has a great solution.

CorreLog provides their own SIEM solution, but they also integrate with a wide variety of other SIEM vendor solution. You can deploy CorreLog to send security events to IBM Security QRadar, LogRhythm, HP ArcSight, Dell SecureWorks, RSA Envision, and many other SIEM solutions! This also means that you are not locked into any one SIEM vendor and can easily migrate to a new solution if or when you want to.

Another big bonus of the CorreLog solutions is support for File Integrity Monitoring, or FIM. FIM is an integral part of many compliance regulations such as PCI Data Security Solutions, and with CorreLog you can address that need along with the rest of you security monitoring needs. Many IBM Mainframe applications use DB2 files to store configuration information, so the FIM module really helps meet the compliance requirements.

You can get more information about CorreLog here.

Patrick

Data-centric security means planning for and implementing encryption and the proper management of encryption keys regardless of the environment.

All data security plans should constantly evolve to reflect changes in business and compliance regulations, as well as policy and infrastructure changes. Because of this evolution, developers are often called upon to modify existing applications, and to implement new or better security solutions. They also are often required to add new security applications in order to meet data protection best practices or prepare for an audit to meet compliance requirements (PCI DSS, HIPAA, FFIEC, etc.).  

What do developers need to know about coding for compliance?

From the ground up, regardless of the platform or language you use, it is the data security mindset that is critical. Developers need to be aware of protecting sensitive data when writing code because ever-evolving compliance requirements call for that disposition. There should be an emphasis to meet industry compliance standards from the beginning design stages. Code needs to be built with those data protection requirements in mind so that is doesn’t have to be reengineered. Projects can sink or fail due to inadequate data security measures, which can put a whole organization at risk.

Whether you are working in hardware, virtual, or cloud environments, understanding and identifying where sensitive data will reside is very important from day one. There needs to be an understanding of the criminal mindsets that will be trying to breach the systems you create, proper preparation for security audits, and a full knowledge of the compliance guidance available to meet industry standards. Developers should also develop for every possible platform/application that the project might be deployed on. As applications move more to multi-tenant cloud environments, you want to make sure you are not locked into or out of a particular platform. You want your code to be compatible from day one with hardware, VMware virtual environments, and cloud platforms. As more organizations move away from using only hardware, VMware technology is at the center of a revolution around virtual and cloud environments. VMware (the company) has done a great job with providing educational materials, helping developers program in a compliance fashion, and producing reference architecture for PCI compliance.

As developers know, their customers want “out of the box” third-party solutions that already meet required security validations. A few of the fundamental basics to keep in mind when developing for data security compliance:

• Use encryption standards such as AES encryption for data-at-rest.
• Use proper Encryption Key storage and management tools
• Do not burn the keys in code
• Do not store keys on the same server as the protected data
• Plan for a compliance audit from the beginning stages

It is also important to look for solution providers that will talk with you before just giving you an instant trial download, it is a good idea to make sure their solution is a technical fit, and not a waste of your time. This is something we do here at Townsend Security with all of our products. We offer a 30-day full version trial of all our software so that you can do a full proof-of-concept and test in your environment. We also feel it is important to supply client-side applications, SDK’s and modules that fit naturally into the platforms and languages that match your development environment. I encourage you to take a little time to listen to this podcast and hear from Patrick Townsend, the Founder & CEO of Townsend Security, on his perspective for developers.

Mic drop! California leads the way, once again.

California started the data breach notification revolution with SB 1386 back in 2003. Almost all of the other US states and territories followed suit passing their own versions of SB 1386, or passing even stronger protections.

Then California strengthened the original law with several new regulations that more stringently define what qualifies as encryption, and how law enforcement agencies interact with encrypted technologies.

THIS MONTH, the California Attorney General Kamala D. Harris published the “California Data Breach Report, 2012 - 2015”. Citing the California constitution’s guarantee of the “inalienable right” to privacy of its citizens, the report makes a new case for strong data protections.

You can read the entire report here.

Not only does the report make the case for strong data protection, it makes this statement as the first recommendation on about page 27:

Recommendation 1: The 20 controls in the Center for Internet Security’s Critical Security Controls define a minimum level of information security that all organizations that collect or maintain personal information should meet. The failure to implement all the Controls that apply to an organization’s environment constitutes a lack of reasonable security.

That’s right, the highest law enforcement official at the California Department of Justice just said that failing to implement the CIS Critical Security Controls demonstrates a lack of minimum reasonable security. While not intending to be legal advice, you can bet that this language will make its way into every lawyer’s lexicon when litigating a data breach or any failure to protect personally identifiable information (PII). Say this phrase over and over to yourself:

“A lack of reasonable security”

You are going to be hearing this a lot very soon.

There is no doubt that the 20 Critical Security Controls are very important. They encapsulate the best working knowledge of the security community on what you should do to protect your systems. They intentionally reflect the combined wisdom and experience of security professionals on what is effective and what has proven to work to protect systems.

You can read the CIS Critical Security Control here.

There is a lot of helpful documentation and guidance on the CIS web site. You will find practical guides for each of the 20 critical controls, a spreadsheet to help you organize your work, and other backing documentation. It will be a great resource as you start to move forward.

The change in mindset that this report signals won’t happen overnight. But it will happen and you should get prepared now. Here are some practical things you can do right away:

• Read the California Attorney General’s report. It will be old news for you security professionals, but for everyone else it is a great place to start. You can hand it out to your executives, too.
• Read the CIS Critical Security Controls which is now in version 6 (see the link above).
• Download the CIS Critical Security Controls spreadsheet. This will give you a template for the work you will need to do.
• Create a team to take the lead on implementing the security controls. You will need a member from your business leadership, a member of your compliance committee, a security professional, a manager from your application development team, and a manager from your network team. If you are a VMware shop, be sure to add someone from the VMware infrastructure team.
• The team should review and prioritize the security controls as the first task.

Now get to work implementing the controls! Some will be fairly easy to accomplish, and some are going to take some time and additional budget. But as I hinted above, it is going to be cheaper to do this now than to pay litigation costs and then have to do it under the gun.

As Laozi said “A journey of a thousand miles begins with a single step.”

Patrick