I Am Concerned – Linkables

I got notified of a new service that is popping up at merchants these days, particularly grocery chains.  The service is called Linkables (mylinkables.com) from Linkable Networks, Inc.  The issue I discovered with this service is not PCI related, but it is privacy related.  With all of the discussion going on regarding the NSA collecting and analyzing telephone records, I think this is a good venue to make people aware of a practice that is possibly even more risky than storing PANs.

According the their Web site:

“Linkables are savings offers that can be connected to your credit or debit card to deliver savings to you automatically after you shop. It’s a simple and convenient way to take advantage of advertisers’ online and offline promotions, with no coupons to clip and no paperwork after you shop. Offers can be used online and offline just by using your credit or debit card.”

When you go to the Linkables Web site, you set up an account using an electronic mail address and a password as is standard operating procedure these days.  But where this service goes terribly wrong is in the registering the subscriber’s credit/debit card(s).  While you are required to provide your PAN and expiration date, the subscriber is then required to provide their logon identifier and password to the online banking system for the bank that issued the card.

Yes, you read that right.  The customer needs to provide access to their online banking system.  The reason given on the Linkables’ FAQ is:

“To deliver your savings, MyLinkables needs to be able to see when you redeem offers. To identify your redemption transactions in a secure way, MyLinkables prompts you to enter your card number and expiration date, and in some cases, your online banking credentials. This is to establish a secure connection for ongoing read-only access, and for the ability to credit your account with your savings. This connection is sustained via a PCI-compliant secure token. For some banks, we are able to create this connection without asking you to enter this information.”

The first problem I have with this is that Linkables invokes PCI compliance as though it should provide some sort of comfort to their customer.  However, PCI compliance has nothing to do with access to someone’s bank account.  They have a green colored seal at the bottom of their home page that indicates they are a “Payment Card Industry Data Security Standard PCI Level 1” which is meaningless on a variety of levels.  If you read the FAQ, PCI compliance is brought up all over the place for not only securing cardholder data, but for implying Linkables is secure as a whole because of their PCI compliance.

But an even more troubling discussion is in regards to the fact that in order to provide you your rebates, they need access to an online banking account.

To give customers a better sense of security, the following FAQ answer is given in regards to if someone does manage to compromise Linkables and obtain customer online banking login information.

“No, MyLinkables encrypts your card number and expiration date, and does not store your bank account credentials. The identifier that was created when you entered your account credentials is encrypted, never displayed within MyLinkables, and connects to your account exclusively with read-only access to view your completed transactions. In addition, details about your banking transactions are not stored in MyLinkables.”

You might want to read that response multiple times as it makes no sense.  In the first sentence they claim they do not store the credentials, then in the second sentence it appears to imply that the credentials are stored but encrypted.  But the real troubling statement is that somehow Linkables only gains read-only access to the customers’ bank accounts.  I have audited a lot of online banking environments over the years and I have never run across one that had read-only access.  Last I knew my online banking credentials gave me full access to my accounts.  So how Linkables ensures that they only have read-only access must be in the fact that their software only reads information.

The bottom line on this service is that either this is the biggest, legitimate looking scam to obtain access to peoples’ bank accounts through their online banking system OR this system was developed by people that had no clue as to how the financial systems in the world operate.  I am hoping it was the latter, but I really have to wonder based on the FAQ answers.

The PCI SSC and card brands should be concerned about the abuse of the PCI standards by this service.

Update:  I got the following response today from Linkables regarding the question I put to them regarding why online banking credentials are required.

“We’ve partnered and integrated with Visa and MasterCard.  When you register a Visa or MasterCard, only the 16-digit card number and expiration date is required.

We’ve not yet completed our integration with the AMEX and Discover card networks, however.  Until then, cards must be registered via Yodlee, our PCI-Compliant processing partner.  Yodlee then communicates with the card-issuing bank and is issued their own token for use in receiving read-only transactional data from the bank.  We don’t have any access to initiate any new transaction of any type.”

While I get this, I still do not understand what the bank has to do with anything.  They state that they need transactional data from the bank, yet the customer’s bank would not have transactional detail other than a total transaction amount.  As I understand it, Linkables is refunding like a coupon.  So they need to know you purchased ABC Orange Juice for example so that they can rebate $1USD to your account.  That detail comes from the merchant that sold the orange juice, not the bank.  The mystery about this service just gets worse, not better.

Diagramming For Your QSA

I have been reviewing network and data flow diagrams for PCI compliance engagements for years.  But it only recently dawned on me that I have never discussed the issues that keep recurring when I review organizations’ network and data flow diagrams as part of the PCI compliance efforts.  To rectify that situation, here are some comments so that all of you can provide better diagrams to your QSAs.

Network Diagrams

Some organizations treat their network diagrams better than some governments treat their Ultra Top Secret documents.  Even though all organizations require a non-disclosure agreement (NDA) to be in place before having a QSAC conduct their PCI assessment, we constantly run into networking and security personnel that keep detailed network diagrams secret from the QSA.

Unfortunately for these people, the PCI assessment process requires a level of detail that is not comfortable.  In such situations I have received diagrams from network/security personnel that can only be described at levels higher than even high level diagrams.  Such documentation is worthless to a QSA and only puts thoughts in the back of the QSA’s mind regarding what you are trying to hide.

QSAs need diagrams that show everything that is contained in the cardholder data environment (CDE) and all of the network connections to the CDE.  A QSA needs this level of detail to reconcile your configuration standards, running configurations and other relevant documentation to the network diagram as part of the process to ensure that the CDE is properly defined and securely configured.  The network diagrams are also used by the QSA to ensure that appropriate samples are taken for devices in-scope for the assessment if sampling is used.

At a minimum, the information that needs to be on network diagrams includes all virtual local area network (VLAN) numbers (if applicable), IP address ranges/blocks for relevant network segments and key firewalls, routers, switches and servers along with their DNS names and IP addresses.  Anything less just makes the PCI assessment process all the more difficult for you and your QSA.

Data Flow Diagrams

Data flow diagrams typically end up in the Details About Reviewed Environment section at the front of the ROC.  As a result, you need to make sure that they carry enough detail for readers of the ROC, but not enough detail to aid an attacker if they get a hold of the ROC.  I will talk about the details that are required in these diagrams in the next section on ROC Diagrams.

The first thing that gets noticed with data flow diagrams is that they do not even come close to matching up to the network diagrams.  This is typically because the data flow diagrams are prepared by the business owners of the card processing processes and these people typically have no idea how the data actually flows through the network.  As a result, the QSA has no point of reference between the data flow and the network to evaluate whether the CDE is properly defined.  As such, the first recommendation I make is for the business owners and the networking people sit down together and get their diagrams in synch.  Not that the same detail that is in the network diagrams needs to be in the data flow diagrams, but key security points such as firewalls, servers, public networks and business partners should be noted in these diagrams.

The second thing that I notice in data flow diagrams is that there can be a lot of lines with arrows, sometimes even colored in red, green, yellow and other colors.  But most of the time there is no description or legend that allows the reader to understand what the diagram is to represent.  Worse yet, the lines and arrows are all over the place and difficult, if not impossible, to follow in a cacophony of color or monochrome.  To add to this mess, sometimes we get this overlaid on top of the detailed network diagrams in an effort to address my first point.  The net result is that it is all clear as mud!

And if you want to add insult to injury, you do get some commentary with the data flow diagrams in the addition of callouts or balloon comments.  Unfortunately, these comments are near to impossible to understand what comments/balloons go with what line.  Or if that comment/balloon is also a data flow line.  Yuck!

What typically needs to be done is to create separate diagrams for how a transaction flows when a card is processed.  This could result in multiple diagrams for “brick and mortar” retail locations, eCommerce, call center, returns and other order processing processes.  Then a diagram that shows the data flow for settlement.  Settlement may result in multiple diagrams as well.  Then there may be other data flow diagrams that show other manual or paper-based processes related to CHD that also need to be documented.

ROC Diagrams

In the Executive Summary and Details About Reviewed Environment sections of the front part of the ROC, the QSA is required to provide three diagrams.

• A “high level” network diagram.
• CDE external and internal network connectivity diagram.
• Card transaction data flow diagram.

The purpose of these diagrams is to give people such as those at your acquiring bank, the card brands, or heaven forbid, the forensic examiners in the event of a breach, an overview of your organization’s network and how cardholder data flows over that network so that they have some context.

The high level network diagram needs to include the following information.

• All connections into and out of the network, including demarcation points between the CDE and all other networks/zones.
• All critical components and key systems, as well as their locations and the boundaries between them.  You do not have to document every switch crossed in the network, but you need to show the key components such as core switches or other networking devices that impact the security of the CDE. You also need to document some of the key servers such as Active Directory, SIEM, patch management, backup, operations management or other operational servers that might not be in the CDE but provide support to the CDE.
• All other necessary components or key systems, their locations and boundaries, as applicable. This would be devices such as consoles and monitoring stations as well as any user systems that have access to the CDE or to the operational support systems.

Note that there is no requirement to provide details such as DNS names, IP addresses or other identifying information that would be extremely useful for an attacker.  There needs to be sufficient detail as to provide the reader with a reasonable understanding of the architecture of the network so that they can assess whether the ROC covers everything it should cover and that the CDE was properly defined.

The CDE external and internal network connectivity diagram needs to provide the following information.

• All boundaries of the cardholder data environment.
• Any network segmentation points which are used to reduce scope of the assessment.
• Boundaries between trusted and untrusted networks.
• Wireless and wired networks.
• All other connection points applicable to the assessment.

Again, there is not a lot of detail provided here, but enough information to give the reader the context of what is connected to what and how the CDE is structure for security.

Data flow diagrams need to provide the following.

• Identify all transmission and processing flows of cardholder data (CHD) including: authorization, capture, settlement, chargeback and any other CHD applicable data flows.
• For each transmission and processing flow: describe how cardholder data is transmitted and/or processed and identify the types of CHD involved (for example, full track, PAN, expiry date).

As I stated earlier, for all of these diagrams, you may need to create multiple diagrams to get your meaning across.  So do not try to pack too much information into a single drawing only to have it unreadable in the ROC.

These ROC diagrams are typically a collaborative effort between the QSA and the appropriate personnel in the organization.  In some cases, it can take quite a lot of work and creativity to get diagrams that are useful yet does not give away the store.

Hopefully you now understand what diagrams your QSA needs and the level of details required.

BlackPOS

I got a Tweet from a friend today regarding this new piece of malware found out in the wild and dubbed ‘BlackPOS’.  BlackPOS is very similar in nature to vSkimmer.  Now before everyone goes off and panics, if you are religiously following the PCI DSS, BlackPOS should not be an issue and here is why.

• Requirement 11.5 – Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.  BlackPOS does a lot of manipulation around known file names, but the hash values of those files should change from the known good values, so any file monitoring system should alert on that fact.  It also uses file names that would never exist on a production system, so those should also generate an alert.  In addition, BlackPOS creates a TXT file that also should generate an alert when created.  However, if you are not alerting in real-time, you should be so that you pick up these issues as soon as possible.  This is where the bad guys are headed with their attacks, so you may as well alert as soon as an incident occurs so that you can address it before it gets out of control.
• Requirement 1.1.5 – Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.  BlackPOS uses FTP to move the TXT file from the POS system to their server.  If you are allowing FTP to flow freely from your POS or cardholder data environment (CDE) to anywhere on the Internet, you were not PCI compliant in my opinion, even if you had some bizarre business justification.
• Requirement 5.1 – Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).  While BlackPOS was only identified today, the anti-virus vendors will most likely have signatures out by the time you read this, so they will be looking for BlackPOS by the time you get your updated signatures.

Just these three requirements can stop this sort of an attack.  Yet, time and again we see these attacks succeed because people are not properly implementing their file integrity and not restricting network traffic flowing out of their internal networks.

PCI compliance does work when you use it the way it was intended.

PCI Scoping Tool

Since September 2012, the Open Scoping Framework Group has been providing free of charge the Open PCI DSS Scoping Toolkit.  If you are a QSA, ISA or someone responsible for PCI compliance and you have not gotten a copy of this fantastic document, you need to get a copy.  A copy is easy to get, just go to the IT Revolution Web site, register and you will be allowed to get your copy.

Never heard of the Open Scoping Framework Group (OSFG)?  Neither had I until late last fall when a friend told me to go check out their PCI scoping methodology.  The OSFG was started by Gene Kim whose name should be familiar to almost everyone as the founder of Tripwire.  He got together his DevOps group to tackle the issues faced by all of us trying to scope the cardholder data environment (CDE) and the result was the toolkit.

The toolkit defines three categories of systems.

• Category 1 – System components that process, store or transmit cardholder data or are not isolated or restricted through controlled access from other Category 1 system components.
• Category 2 – System components that have controlled access to a Category 1 system component.
• Category 3 – System components that are isolated from all Category 1 system components.

People always get the reason why Category 1 devices are in scope because they are contained in the CDE.  While one would think that Category 3 components would be also just as easy to categorize as Category 1, but that is not necessarily the case.  The key is that Category 3 systems cannot have any access to Category 1 components.  While attempting to ping Category 1 components from the Category 3 component could be used, a better test is to use Nmap or similar port scanner from a sample of Category 3 components to scan the CDE IP address range to determine if any ports are open.

While Category 3 components can be troublesome, it is the Category 2 devices that usually give everyone a problem including, at times, yours truly.  The reason is the connectivity issue as it can be very unclear at times whether or not a device actually has connectivity to the CDE.

To assist in identifying connected systems, the toolkit breaks Category 2 systems into four sub-categories.

• Category 2a – System components which, through controlled access, provide security services (e.g., authentication) to a Category 1 device.
• Category 2b – System components which, through controlled access, can initiate an inbound connection to a Category 1 device.
• Category 2c – System components which, through controlled access, can only receive a connection from a Category 1 device (i.e., cannot initiate a connection).
• Category 2x – System components which, through indirect and controlled access, have the ability to administer Category 1 devices. Note: Category 2x devices have no direct access to/from Category 1 devices.

The first thing we need to clarify is what is meant by “controlled access.”  Controlled access means that the system components have: (1) limited network traffic to only that which is required for business operations; and (2) are business justified and documented.

It is the first point of controlled access that typically give people the most trouble.  The concept of “limited” network traffic just does not come across the same for everyone.  I have seen people try to justify limited traffic when just about every port north of 31000 is open for dynamic use.  Do not get me wrong, there are instances where a significant number of ports need to be open (look at Windows 2003 Active Directory as a prime example), but when the answer used to justify the large number of ports is, “We did it to be safe and avoid any problems” says to an assessor you did not want to research the exact ports you needed open or, worse yet, you have no idea what ports are needed to be open.

The sub-category most people will struggle with is 2x.  2x components are those that do not have direct access to the CDE but have access to 2a, 2b and/or 2c components that do have direct access to the CDE.  The best example of this sort of situation would be a system management console for a log management server.  The console has access to the log management server which does have access to the CDE, but the console should not have access to the CDE.  Since the console could be compromised and it has access to a component that has direct access to the CDE, it needs to be included in the scope of the PCI assessment.

The final pieces of the Open PCI DSS Scoping Toolkit I really like are the decision tree and the scenarios provided.  If these do not help explain how to scope your PCI assessment, nothing will.

Again, if you do not yet have a copy of the Open PCI DSS Scoping Toolkit, hopefully this post will entice you to get a copy.

Can An ISA Sign Off On A ROC Or SAQ?

This question came up recently on one of the LinkedIn PCI groups and drove a lot of discussion.  However, one of the things that concerned me the most is that no one belonging to this group bothered to submit the question to the PCI SSC to be answered.

When such questions come up, the first thing you should do is go to the PCI SSC Web site’s FAQ page to see if the question has already been answered.  There is an amazing wealth of information contained in the FAQs.

If you search the FAQs and you do not come up with an answer to your questions, then submit your question to the PCI SSC.  Technically, anyone can submit a question to the PCI SSC.  However, if you are a QSA in a QSAC, the person listed in your QSAC listing should be the focal point and should submit all questions you have to the PCI SSC.

Questions are submitted to info@pcisecuritystandards.org.  Expect a few days to a few weeks to get a response.  Simple procedural questions such as whether an ISA can sign a ROC or SAQ like a QSA can get a response in a day or two.  Questions that require the PCI SSC to formulate a position, may take a number of weeks before a response is provided.

So, can an Internal Security Assessor (ISA) sign off on a Report On Compliance (ROC) or Self-Assessment Questionnaire (SAQ)?  The answer provided by Cathy Levie, Senior ISA Program Manager, PCI SSC, is as follows.

“The ISA can sign off as long as their Processor/Acquirer has approved of that. This is not up to the PCI SSC.”

In the future, if you have a question and cannot find an answer, ask the PCI SSC.  When you get your answer, please post the answer to any of the PCI groups on LinkedIn or send them to me so that the rest of the PCI world can benefit from the knowledge.  One of the unfortunate issues the PCI SSC has is that not all questions seem to make it into the FAQs or the FAQs are not updated as quickly.

The Problems With Big Data

I developed a presentation on big data for a series of education sessions I am delivering for a financial institution trade association.  As I was putting the presentation together, I realized that this was probably a good topic for the blog as a lot of you are running headlong toward big data either for log data analysis or just as the next “I need to be doing this” technology fad.

Most people do not realize that big data has been around for quite a while, relatively speaking.  Google, Yahoo and similar Web service providers have been dealing with big data for years.  But it was only recently that big data management frameworks such as Apache Hadoop, Google BigQuery and MongoDB became publically available through shareware, commercial solutions and software as a service (SaaS).

So we are all on the same page, let us define “big data.”  The best definition I have seen for big data is from Gartner.

“Big data are high-volume, high-velocity, and/or high-variety information assets that require new forms of processing to enable enhanced decision making, insight discovery and process optimization.”

Examples of big data include information such as Web search results, electronic messages (e.g., SMS, email and instant messages), social media postings, pictures, videos and even system log data.  However, it can also include credit/debit card transactions, check images, receipts and other transactional information depending on the source of the information.  As a result, big data can easily end up in-scope for PCI compliance.

The first problem with big data is that organizations are expected to know the data going into their big data repositories.  The reason “know your data” is so important with big data is that it comes from potentially a wide variety of sources such as:

• Social media
• News feeds
• Images
• Streaming media (audio and video)
• Documents
• Messaging systems
• Audit logs
• Transaction logs
• Web sites
• System logs

With this diversity of information sources, it is anyone’s guess as to how much sensitive information could end up in an organization’s big data repositories.  But worse yet, anyone in the big data field will tell you that you need to anticipate all potential sensitive data so that you can secure and protect it appropriately.  Why is this?  Because big data tools allow everything to be searchable: text, images, audio, video, anything.  So if you do not want the information to be searchable, then you need to identify it and either encrypt it, truncate it or remove it so that it cannot be found.  As those of you that are using data loss prevention (DLP) or other tools to find cardholder data (CHD) stored on your systems are well aware, finding CHD is not as easy it would appear.  As a result, finding it in big data could be the ultimate finding the needle in the haystack game.

The next problem with big data is that the security tools for big data are very early in their development and, in some cases, are really bolt on after thoughts that use constantly running queries to find and protect the sensitive data.  While a lot of vendors claim they can secure data at the “field” level, I have spoken to a number of clients going through big data implementations that tell me this is a pipe dream at the moment.  As such, in all cases I am aware; big data protection is currently accomplished through totally encrypting all of the data and very severely restricting access.

Which begs the question, how can big data be PCI compliant?  Well it can be PCI compliant as long as: (1) access to it is extremely limited (only a very few people have access such as two to three), or (2) you are able to truncate, remove or encrypt the CHD contained in your big data hive(s).  Given that accurately locating CHD can be nearly impossible with current techniques, I just do not see option 2 as currently viable, so extremely limited access is your only workable option.  Even then I seriously doubt that big data is a good place for CHD to be stored as severely limiting access is also not viable given why big data is being implemented.  As a result, big data is probably not a good place for sensitive data, cardholder or otherwise, until the security tools catch up.

I think my readers will recognize why their log data would fit into the big data category.  It definitely has high volume as it typically comes from a large pool of devices that are generating potentially hundreds to thousands of entries per second which also satisfies the high velocity requirement as well.  And the high variety aspect is also satisfied as log data from a Cisco or Juniper device is nothing like log data generated from a Windows or Linux server or any other litany of network devices.  However, while the likelihood of CHD should be nonexistent in log data, CHD can still end up in log data due to debugging being performed.  As such, I am not certain I would be comfortable with log data in a big data hive until the maturity of the security tools is better.

The bottom line at the moment is I just do not see big data being ready for PCI compliance at this point.  I am sure that someday big data will be capable of being PCI compliant, but not at this time.  So all of you that need to be PCI compliant running towards the light at the end of the big data tunnel.  That light you see is not then end of the tunnel but an oncoming train about to run you over.

Meaningful Security Awareness Training

Is there really such a thing or am I dreaming?

For any of you that are involved in security awareness efforts, you know what I am talking about.  Security awareness training efforts just do not seem to catch fire or interest anyone, even yourself.  So what is one to do?  The reason I bring this topic up is that I attended an FS-ISAC Webinar where Lance Spitzner of SANS offered a very interesting idea in regards to security awareness training.

Before I get too deep into security awareness training, a bit of background.  Mr. Spitzner pointed out in his presentation that human beings are very bad at judging risk.  Worse yet, since most people have a poor understanding of the Internet and technology, that risk judgment gets even worse as most people, even IT professionals, just do not seem to get the risks presented by the Internet.  He presented numerous examples of just how bad people are at risk evaluation without information or a frame of reference.

If you think this is a fallacy, go and read peoples’ Facebook and LinkedIn pages.  The amount of proprietary and sensitive information that can be gleaned off of social media pages is terrifying.  But it is not just social media that creates problems.  Organizations do it to themselves all of the time with their own Web sites.  In the name of openness and marketing savvy, organizations post amazing amounts of proprietary and sensitive information on their own Web sites.  The ready availability of all of this proprietary and sensitive information lends itself to making a successful social engineering attack a foregone conclusion.

As I like to point out in my social engineering presentations, no one walks down the street indiscriminately handing out their business cards to everyone they encounter.  The looks I get from that statement are truly amazing.  Most of the people in the room do not get it and, unfortunately, probably never will get it until they are breached.  However those that do get it usually turn pale as it is usually the first time they realized the seriousness of the situation and the amount of risk to their organization all of that information presents.  When you are on the Web, organizations and people post their life stories for anyone and everyone to see.  Is it any wonder why the DEF CON “How Strong Is Your Schmooze” social engineering contest is so successful?

I have thought about this situation a lot lately as social engineering becomes more and more one of the tools used to initiate a breach.  I keep coming back to what can we do to minimize this disaster?  Security awareness training just does not seem to be working and then I run across Lance Spitzner’s presentation to FS-ISAC.  Mr. Spitzner states that people are just like any other device in the mix.  He points out that Microsoft patches Windows every month on ‘Patch Tuesday’, so why are we not “patching” people at least monthly.  What an idea.

Mr. Spitzer stated me to thinking about people as running the human operating system, or hOS as I prefer to now call it (my apologies to Apple).  And all of a sudden, viewing people as devices running hOS clarifies security awareness training.  Now, I know there are some that will chastise me for dehumanizing people.  But I justify my doing that in the fact that it needed to happen so that we can better understand and educate people so they are less at risk.

If you accept the premise that people should be treated no differently than any other device, then you know that security awareness training on hiring or an annual basis is just not often enough.  Microsoft issues patches to their software monthly if not more often in emergencies.  Since human beings are terrible at judging risk, then how can only annual security awareness training address the issues in hOS?  And that is just it, annual training cannot.  hOS needs to be regularly “patched” just like every other operating system.  That means at least a monthly patching cycle.  But doing monthly “patching” is not just all you have to do for hOS, you also need to make the “patching” relevant to hOS.

This is where subscribing to news and information security RSS feeds or listservs to track what the hot issues are for hOS.  Just like Microsoft focuses their patching of Windows on the most dangerous vulnerabilities, hOS vulnerabilities also need to be tracked the same as technological vulnerabilities.

By decoupling people from the equation and looking at the security awareness problem as patching another OS, it liberates you to think in new ways.  So, what are the steps in patching an OS?

1. Identify the vulnerability.
2. Determine the risk of the vulnerability.
3. Determine what can be done to mitigate or remediate the vulnerability.
4. Develop a program to mitigate or remediate the vulnerability.
5. Test the mitigation or remediation of the vulnerability.
6. Implement the mitigation or remediation of the vulnerability.

Now apply those principles to hOS on a monthly basis.  Taking the results of your research you can surely come up with a vulnerability or two that has occurred whether it is a suspicious email with a PDF or spreadsheet attachment or a drive-by attack.  Take those as examples, explain their risk, explain how to recognize these attacks, and then put your marketing department to work on developing a message that trains people.  There is a reason I recommend the marketing department and that is because you can share this information with your customers as well as your employees.

Send out these messages on a regular basis, preferably monthly but definitely more often than annually.  Follow up those messages with ‘lunch and learn’ or similar sessions to further discuss those messages and to ask attendees if they have any security questions or have encountered any threats at work or even at home.  These steps should show your customers and fellow employees that security does not require knowledge of technology so much as just using common sense and being skeptical.

Security awareness does not need to be conducted like a TV sitcom, but it can work if you take the approach that you are patching another device and you make that training relevant.