How About We Fix The Problem?

As I pointed out in my last post, EMV would have not stemmed the loss of data in the Target breach.  All EMV would have done is restricted where the thieves could use the card data obtained.  Even though the thieves can supposedly clone cards from the data gathered, as far as anyone has reported at this point, cloned cards do not appear to be the method of fraud.  So the assumption I have is that all, or the vast majority, of the fraud committed to this point has been through card not present transactions.

In response to people clamoring for a solution to the breach problem, Visa and MasterCard have curiously remained silent.  I would have assumed that the card brands would have trotted out their press releases touting EMV as the savior.  Yet they have said nothing.  Could it be that the card brands are actually acknowledging that EMV would have not been the answer?  One can only hope.

So what is the answer?

To me the answer is single use transaction codes of 15 to 16 characters in length.  With the advent of smartphones and miniaturization of electronics, the ability to create a card or an application that generates such a code is not only possible, but has been demonstrated in recent years.  Not only that, but the card brands and banks themselves dabbled with such solutions over 10 years ago but for some reason backed off on pushing such a solution.  My best guess is that without a portable method of using the single use code system, there was no point to pushing such a system.  But times and technology change.

With the capabilities of today’s technology, the single use codes could be displayed as bar codes so that existing merchant POS systems could scan them and avoid data entry errors.  Since they are no more than 16 characters in length, the codes can be stored in applications’ existing fields used to store card numbers without modification.  Since the card brands and banks have already developed the algorithms for this approach, they only have to agree on which algorithms to use.  But best of all, since the code can only be used once, it can be processed, stored and transmitted wherever and however without fear of a compromise because it can only be used once.

This is just my thought for a solution but there are other people and organizations that have their own solutions to fix this problem.  The bottom line is that it is time to fix the problem, not keep kicking the can down the road with a known format that is at the end of its life.

Advertisement

Encryption Basics

NOTE: This is a revised version of my original post to reflect readers concerns regarding statements made that do not reflect best practices surrounding encryption key management.  A big thank you to Andrew Jamieson who reviewed and commented on this revised posting.

During the last couple of years, I have run into more and more questions regarding encryption and encryption key management than I thought existed.  As a result, I have come to the realization that, for most people, encryption is some mystical science.  The stories of the Enigma machine and Bletchley Park have only seemed to add to that mysticism.  Over the years, I have collected my thoughts based on all of the questions and developed this distilled and very simplified version of guidance for those of you struggling with encryption.

For the security and encryption purists out there, I do not represent this post in any way, shape, or form as the “be all, to end all” on encryption.  Volumes upon volumes of books and Web sites have been dedicated to encryption, which is probably why it gets the bad reputation it does as the vast majority of these discussions are about as esoteric as they can be.

In addition, this post is written in regards to the most common method of encryption used in encrypting data stored in a database or file and that is the use of an encryption algorithm against a column of data or an entire file.  It does not cover public key infrastructure (PKI) or other techniques that could be used.  So please do not flame me for missing your favorite algorithm, other forms of encryption or some other piece of encryption minutiae.

There are all sorts of nuances to encryption methods and I do not want to cloud the basic issues so that people can get beyond the mysticism.  This post is for educating people so that they have a modicum of knowledge to identify hyperbole from fact.

The first thing I want to clarify to people is that encryption and hashing are two entirely different methods.  While both methods obscure information, the key thing to remember is that encryption is reversible and hashing is not reversible.  Even security professionals get balled up interchanging hashing and encryption, so I wanted to make sure everyone understands the difference.

The most common questions I get typically revolve around how encryption works.  Non-mathematicians should not need to know how an encryption algorithm works, that is for the experts that develop and prove that they work.  In my opinion, unless you are a mathematician studying cryptography, I recommend that people trust the research conducted by the experts regarding encryption algorithms.

That is not to say you should not know strong cryptography from weak cryptography.  I am just suggesting that the underlying mathematics that defines a strong algorithm can be beyond even some mathematicians, so why we expect non-mathematicians to understand encryption at this level is beyond me.  My point is that the algorithms work.  How they work is not and should not be a prerequisite for management and even security professionals to using encryption.

This leads me to the most important thing people need to know about encryption.  If you only take away one thing from this post, it would be that strong encryption comes down to four basic principles.

• The algorithm used;
• The key used;
• How the key is managed; and
• How the key is protected.

If you understand these four basic principles you will be miles ahead of everyone else that is getting twisted up in the details and missing these key points.  If you look at PCI requirement 3, the tests are structured around these four basic principles.

On the algorithm side of the equation, the best algorithm currently in use is the Advanced Encryption Standard (AES).  AES was selected by the United States National Institute of Standards and Technology (NIST) in 2001 as the official encryption standard for the US government.  AES replaced the Data Encryption Standard (DES) that was no longer considered secure.  AES was selected through a competition where 15 algorithms were evaluated.  While the following algorithms were not selected as the winner of the NIST competition, Twofish, Serpent, RC6 and MARS were finalists and are also considered strong encryption algorithms.  Better yet, for all of you in the software development business, AES, Twofish, Serpent and MARS are open source.  Other algorithms are available, but these are the most tested and reliable of the lot.

One form of DES, Triple DES (3DES) 168-bit key strength, is still considered strong encryption.  However how long that will remain the case is up for debate  I have always recommended staying away from 3DES 168-bit unless you have no other choice, which can be the case with older devices and software.  If you are currently using 3DES, I would highly recommend you develop a plan to migrate away from using it.

This brings up another key take away from this discussion.  Regardless of the algorithm used, they are not perfect.  Over time, encryption algorithms are likely to be shown to have flaws or be breakable by the latest computing power available.  Some flaws may be annoyances that you can work around or you may have to accept some minimal risk of their continued use.  However, some flaws may be fatal and require the discontinued use of the algorithm as was the case with DES.  The lesson here is that you should always be prepared to change your encryption algorithm.  Not that you will likely be required to make such a change on a moment’s notice.  But as the experience with DES shows, what was considered strong in the past, is no longer strong or should not be relied upon.  Changes in computing power and research could make any algorithm obsolete thus requiring you to make a change.

Just because you use AES or another strong algorithm does not mean your encryption cannot be broken.  If there is any weak link in the use of encryption, it is the belief by many that the algorithm is the only thing that matters.  As a result, we end up with a strong algorithm using a weak key.  Weak keys, such as a key comprised of the same character, a series of consecutive characters, easily guessed phrase or a key of insufficient length, are the reasons most often cited as why encryption fails.  In order for encryption to be effective, encryption keys need to be strong as well.  Encryption keys should be a minimum of 32 characters in length.  However in the encryption game, the longer and more random the characters in a key the better, which is why you see organizations using 64 to 256 character long random key strings.  When I use the term ‘character’ that can be printable characters of upper and lower case alphabetic as well as numeric and special characters.  But ‘character’ can also include hexadecimal values as well if your key entry interface allows for hexadecimal values to be entered.  The important thing to remember is that you should ensure that the values you enter for your key are as hard to guess or brute force as maximum key size of the algorithm you are using.  For example, using a seven character password to generate a 256 bit AES key does not provide for the full strength of that algorithm.

This brings us to the topic of encryption key generation.  There are a number of Web sites that can generate pseudo-random character strings for use as encryption keys.  To be correct, any Web site claiming to generate a “random” string of characters is only pseudo-random.  This is because the character generator algorithm is a mathematical formula and by its very nature is not truly random.  My favorite Web site for this purpose is operated by Gibson Research Corporation (GRC).  It is my favorite because it runs over SSL and is set up so that it is not cached or processed by search engines to better guarantee security.  The GRC site generates 63 character long hexadecimal strings, alphanumeric strings and printable ASCII strings, not numerical strings provided by other random and pseudo-random number generator sites.  Using such a site, you can generate keys or seed values for key generators.  You can combine multiple results from these Web sites to generate longer key values.

In addition, you can have multiple people individually go to the Web site, obtain a pseudo-random character string and then have each of them enter their character string into the system.  This is also known as split key knowledge as individuals only know their input to the final value of the key.  Under such an approach, the key generator system asks each key custodian to enter their value (called a ‘component’) separately and the system allows no key custodian to come into contact with any other custodian’s component value.  The key is then generated by combining the entered values in such a way that none of the individual inputs provides any information about the final key.  It is important to note that simply concatenating the input values to form the key does not provide this function, and therefore does not ensure split knowledge of the key value.

Just because you have encrypted your data does not mean your job is over.  Depending on how your encryption solution is implemented, you may be required to protect your encryption keys as well as periodically change those keys.  Encryption key protection can be as simple as storing the key components on separate pieces of paper in separate, sealed envelopes or as high tech as storing them on separate encrypted USB thumb drives.  Each of these would then be stored in separate safes.

You can also store encryption keys on a server not involved in storing encrypted data.  This server should not be any ordinary server as it needs to be securely configured and very limited access.  Using this approach is where those key encryption keys (KEK) come into play.  The way this works is that each custodian generates a KEK and encrypts their component with the KEK.  Those encrypted components can then be placed in an encrypted folder or zip file where computer operations have the encryption key.  This is where you tend to see PGP used for encryption as multiple decryption keys can be used so that in an emergency, operations can decrypt the archive and then the key custodians or their backups can decrypt their key components.

Finally, key changes are where a lot of organizations run into issues.  This is because key changes can require that the information be decrypted using the old key and then encrypted with the new key.  That decrypt/encrypt process can take days, weeks even years depending on the volume of data involved.  And depending on the time involved and how the decrypt/encrypt process is implemented, cardholder data can potentially be decrypted or exposed because of a compromised key for a long period of time.

The bottom line is that organizations can find out that key changes are not really feasible or introduce more risk than they are willing to accept.  As a result, protection of the encryption keys takes on even more importance because key changes are not feasible.  This is another reason why sales of key management appliances are on the rise.

That is encryption in a nutshell, a sort of “CliffsNotes” for the non-geeky out there.  In future posts I intend to go into PKI and other nuances to encryption and how to address the various PCI requirements in requirements 3 and 4.  For now, I wanted to get a basic educational foundation out there for people to build on and to remove that glassy eyed look that can occur when the topic of encryption comes up.

More On Mobile Payments

As I have found out, the definition of “mobile payment” is defined by to whom you are talking.  For consumers, mobile payment means using their smartphone to pay for goods and services.  For merchants it includes the consumer definition as well as using smartphones or similar mobile devices to process payments.

Last year I wrote a post regarding mobile payments and the use of smartphones, primarily the iPhone, for use as credit card terminals.  When I wrote that first post, Apple was running an advertisement for the iPhone that showed it being used to process a credit card payment with the ubiquitous tag line, “There’s an app for that.”  Shortly after that post, the advertisement dropped the iPhone as a credit card terminal.  I am not aware that the PCI SSC or any of the card brands complained about that advertisement, but I found it interesting that those images of it processing a credit card were removed particularly given that a number of security and privacy issues that were and still are being discussed regarding the iPhone.

That is not to say that iPhone credit card adapters have not continued to be developed.  It is just that they are nothing like the one shown in that original Apple advertisement.  The first one that I came into contact with was Verifone’s PAYware Mobile solution and the fact that it is PA-DSS certified.  Whoa!  In my previous post I talked about all of the issues with the iPhone that make it almost impossible to be PCI certified.  How did Verifone create a PA-DSS certified application on the iPhone?  What Verifone did was to create a digital back to the iPhone.  All of the operations that need to comply with the various PCI standards are done through the digital back, not the iPhone.  The iPhone is just used as a display.  In the event that a credit card will not swipe through the digital back, the customer must go to a standard register.  I have also been privy to a number of similar iPhone applications.  All of them avoid the iOS interfaces as iOS is the problem in achieving PCI compliance.

While iPhone is the “Big Kahuna” of smartphones, it does not mean that Android and Windows Phone devices are not also used for credit card payments.  Unfortunately like the iPhone, Android and Windows Phone devices have similar issues that make them difficult, if not impossible; to have PA-DSS certified applications.  So from a merchant perspective, iPhone, Android and Windows Phone all have to be treated very carefully when they are used to process credit card payments.

But security concerns have not stopped merchants from rolling out mobile payments.  Starbucks recently introduced an iPhone and Android application that allows the customer to put their Starbucks cash card on their phone.  The application creates a 2D bar code with the cash card’s number.  The Starbucks POS system reads the bar code and automatically deducts the purchase from the account’s balance.  Within a week of releasing the application, it was determined that if you take a picture of the screen containing the bar code, anyone with the bar code can use the account until it cannot pay for a purchase.  So much for secure mobile payments.

If we expect to secure payments, the traditional credit card is just not going to get the job done.  EMV, aka Chip and PIN, is a short term technological fix but also a back up payment method for where I think we are really headed.  I truly believe that the future in payments is smartphones and other mobile devices with software that generate one-time transaction codes for paying for goods and services.  Whether those codes are displayed as a 15/16-digit number or bar code on a screen or transmitted via Wi-Fi, Bluetooth or RFID, a consumer will not need a traditional credit card.  A 15 or 16 digit number will be necessary to use so that POS systems do not have to be re-engineered to support the new payment method.  Scanners are already capable of reading bar codes from smartphone screens, so that much of the solution is already in place.  Wi-Fi, Bluetooth and RFID technology is coming as we speak so it is only a short matter of time before the infrastructure is in place to support such a solution.  All that is needed is the software.

Such an approach not only will secure card present transactions, but would also tackle the security issues we face with card not present transactions.  If done right, mobile payments can become the solution to our PCI compliance problem.

The Reinvigoration Of Social Engineering

Social engineering did not go away, but it seems to have taken a backseat to other attack techniques over the last few years.  With the publication of the results of the social engineering contest at Defcon this year, the participants in the contest have shown that social engineering is still alive and well and a very successful attack technique.  The following quote from the report on the contest says it all.

“Targeting people has become the most cost efficient attack vector in many situations, and all indications point to this trend continuing to increase.”

Social engineering is one of the most insidious attack techniques around.  Unfortunately, organizations do little to address social engineering and have only made social engineering easier over the years.  Customer service methodologies and training over the last 30+ years have done a great disservice to organizations.  For example, organizations trip all over themselves to be the JD Power customer service leader.  Employees are assessed on their ability to solve a problem on the first customer contact.  Yet in my experience, these sorts of activities typically focus organizations on blindly providing customer service at the expense of the organization’s security.

The organizers of the contest defined 32 objectives or flags that contestants could obtain over a 25 minute call to the target.  These flags were assigned point values based on the perceived difficulty in obtaining them.  While the flags were not considered to be highly sensitive information, the flags were such that one as to wonder if even more sensitive information would have easily been obtained had the contestants been allowed to go after it.

Prior to the contest, contestants were required to develop dossiers and attack scenarios on their targets that were also graded and given a value that became part of their score.  In the 25 minutes, contestants could call their target once or multiple times.

The statistics gathered as a result of the contest bear out the effectiveness of social engineering.  Of the 15 organizations targeted, 14 of them did give up at least one flag.  More troubling is the fact that if a contestant encountered difficulty in obtaining information all it took to get the information was to hang up and call back and get a different employee.

Another area that provides concern is the amount of information the contestants were able to obtain through their dossier development.  The use of Google, Google Earth and Google StreetView provided an amazing amount of information for the contestants.  Also used were social media sites such as Facebook, MySpace and LinkedIn.  While Facebook, MySpace and similar sites have garnered the most attention by the media, it was LinkedIn that provided the most information, in a few cases providing the contestants with the ability to develop an organization chart for the target.

Security is only as good as the weakest link.  As this contest points out, an organization’s weakest link is probably their employees – the likely cause of which is a lack of or only cursory focus on security awareness.  The contest just magnifies the fact that organizations have done little or nothing to protect their organizations from information leakage by employees.  As I constantly like to remind everyone, security is not perfect.  While you may have a fairly good security awareness program, you are still at risk from social engineering.  As PT Barnum liked to say, “There’s a sucker born every minute.”  Humans are fallible and as much as we try, everyone has their moments, but some people have a lot more moments than others.

If you think this is all just a nice exercise and it really does not present a strong enough threat, then go back over the last six months and read all of the news clippings about data breaches and other exploits.  The majority of these attacks are all social engineering based or had a very strong social engineering component.

I highly recommend that you visit the Social-Engineer.org Web site and obtain a copy of their report.  Share the report with your executives, particularly the leader of your customer service area.  Hopefully they will get a clue regarding the amount of information that is inadvertently leaving your organization.

Extremely Mobile Payment Processing

In a previous post I discussed mobile computing and PCI compliance.  In the last couple of weeks I have been questioned about using mobile devices such as smartphones and Wi-Fi enabled PDAs as payment terminals and I thought this particular incarnation of mobile computing deserved an in-depth look.

Pay attention to that Apple iPhone advertisement.  If you notice in one of their advertisements they show a person processing a credit card payment on their iPhone.  As Apple likes to say, “There’s an app for that.”  However, it is not just Apple that has a payment application for a mobile device; there are also payment processing applications for Windows Mobile environments.  There are also proprietary solutions from VeriFone and the like.  Some of these applications are PABP and/or PA-DSS certified.  Devices from VeriFone and the like are PCI PTS certified, but the iPhone and other cellular phones as well as PDAs are not PCI PTS certified devices.

So when the pizza delivery person shows up at your door and wants to swipe your credit card through their mobile device, how do you know that it is safe?  You likely will not know.

The security surrounding the telecommunications used by these devices is the easiest thing to discuss.  All of the devices I have been able to examine use telecommunications methods that are encrypted either by SSL v3 or TLS.  The cellular network and Wi-Fi are just used as the conduit and are not relied upon to provide any security.

Do not assume that VeriFone and the like are meeting all of the PCI standards.  While their mobile payment terminals are PCI PTS certified, the application software in those devices is not PA-DSS certified.  I pointed to the flaws in these devices in a previous post.

But there are bigger problems lurking with the iPhone.  Ask any computer forensic examiner about the iPhone and they will talk at length about the fact that the iPhone has a number of “features” that make security and privacy things of the past.  From a PCI compliance perspective, some of the more problematic issues are as follows.

• Deleted information does not physically get deleted.  In some cases, deleted data can remain on an iPhone for up to six months or even more depending on use.
• The iPhone has a built-in keyboard logger, so anything typed into it is recorded.
• While it is not certain that card swipes would be retained on the iPhone, given all of the other information it retains, it is highly likely that such information would also be retained.

As a result, using the iPhone as a payment processing platform is probably not a good idea until it is certified.

So what, if anything, are the PCI SSC and/or the card brands doing about this situation?  As much as they can, given that these solutions are popping up faster than they can identify them.  The problem is that the developers of these applications are usually unaware that they are required to comply with various PCI standards.  And since the developer is responsible for certifying their solution unless they get ‘ratted out’, the solution will not get certified.  So it is up to the application developer and the merchants to ensure that an application is properly certified.  If that is not worrisome enough, the cost involved in certifying such an application would likely raise the cost of that solution to a point where it would not be economical to the merchant or salesperson.

Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

• The PANs can only be displayed one at a time.
• You have to be in administration mode to view the PANs.
• The PANs cannot be printed out.
• The PANs are stored in memory, not on a hard drive.
• The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.”

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.

Dispelling Rumors – CVV/CVC

One of the things I hate about blogs is that they seem to generate more rumors than dispel. One of the reasons I created this blog was to get rid of some of the rumors surrounding the PCI process. Where these rumors come from, I’m not sure. However, the sooner they are dispelled, the more secure we will be.

The rumors I would like to dispel in this posting are related to why merchants seem to think they need to retain the card verification value or code otherwise known as CVV/CVC. It’s that three digit code on the backs of Visa or MasterCard cards and four digit value on the front of American Express cards. Actually, to be correct, American Express calls it the CID. Regardless of what it’s called, it is NOT allowed to be retained once a transaction has been processed.

The first rumor is that by using the CVV/CVC in transactions merchants reduce their interchange fees with their processor and the card brands. This is not true.

What is true is that by including the CVV/CVC value when a merchant submits a transaction for authorization, should a dispute or chargeback situation arise, the processor and/or card brands will reduce their fees on the dispute or chargeback. The rationale being that the processors and card brands assume that by having the CVV/CVC, it is less likely that the transaction will result in a dispute or chargeback.

The second rumor is that merchants conducting repeat transactions need to submit the CVV/CVC for the original and all subsequent transactions. Again, this is false.

There are two ways to conduct such recurring transactions. The easiest way is to use a processor that can provide you with a reference number from the original transaction and then process all subsequent transactions by allowing you to use the reference number so that your organization does not have to store the cardholder information. The other option is for your organization to store the cardholder’s name, account number and expiration date. Of course, if your organization is storing this information, you need to ensure it is stored securely either by encrypting it if on a computer or physically securing it if using a manual system.