Monthly Archives: February 2016

5 techniques to creating an invincible password


One of the most important aspects of an IT security professional is being able to not only have a strong password, but also teach others in your company to follow this same password making process as well. You are only as strong as your weakest link, and we all know that most cyber-attacks start from human error. The dos and don’ts of making a secure password may seem tedious at first, but in the long run it is the best option to stay protected.

First step, we will get rid of idiom “passwords” because now we will be creating “passphrases”. You don’t want to just use one of two words as the main part of your passphrase. Dictionary and brute force attacks are become more advanced, cracking single word passwords in minutes. What you want to do instead is take a phrase that you can remember, but not something too relatable to yourself. Some examples would be like the chorus from your favorite song or the first sentence in your favorite book. Use my example below for now:

“She had them apple bottom jeans, boots with the fur”

You will now want to take the first or last letter from each word and cram them together, this will be the base of your passphrase:


Next, you want to make a few of the letters capital:


Try to have at least two letters capitalized. Now take your phrase and add a number or special character on the beginning/end of the phrase.


The last step is to make sure it is 14 characters long of more. My example has only 12 so I would want to go back and add 2 more characters to the phrase:


There you have it, simple as that. Now you have a password that meets the length criteria and is well out of the scope of any dictionary attack. You will also have an easy time remember this one because the base phrase is something that you have memorized anyway (a song or phrase). The idea is to find something that is easy for you and only you to remember for your base phrase, then the rest will fall in place after a few times using the password.

Creating a strong passphrase is very important, but do not ever write down your phrases. It doesn’t matter if they are in a safe, creating a super secure password will do you no good if it cannot be memorized. Now let’s say that you have a lot of accounts with different passwords, what you can do to solve this is get a password locker. It is a tool that holds all of your passwords on your computer, with one master password to unlock the others. This way you only have to memorize one secure password. Congrats, you can now train passphrase creation. Take what you have learned and spread this knowledge to your company. The employees are the first line of defense and need to be well prepared for it.

A guy challenged Hackers at DEF CON to hack him,Find out what they did to him?

A good lesson for everyone !!!  Hacking is easier than you think.


Fusion’s Kevin Roose asked some of the best hackers at DEF CON to do their worst to him. He didn’t even know what was coming.

Security Predictions 2016: Ransomware will continue to evolve and become increasingly complicated


As we start each year, the team at thedigitalageblog looks into the crystal ball and makes predictions for the year.  Sometimes we’re right and sometimes we’re wrong, but we find it useful to look to the future and document what we see.

Our Prediction centers on the ongoing Ransomware attacks:

Ransomware will continue to evolve and become increasingly complicated.  We continue to be shocked at the amount of ransomware attacks where the “victim” actually pays the ransom.  The FBI said it received 992 CryptoWall complaints from April 2014 to June 2015, representing total losses of $18 million—and that is just reported cases. Because criminals are finding this scheme lucrative, hackers will continue to work on producing virus variants that are harder to detect and decrypt. Ransomware depends on human error; it is usually activated by a user clicking on a link in a phishing email. Encryption of sensitive data combined with regular back-ups onto external devices or cloud services are an excellent defense against these schemes. If you have a current copy of your data or web site, business can continue with minimal disruption. Paying the ransom does not, after all, guarantee full restoration of your data or web site. It’s important to note that mobile devices can also be overtaken by ransomware, and often the accompanying threat is to ruin one’s reputation.

Is It Time to Join the Cloud?

Wondering if joining the cloud is the right move for your company? It’s a question that many CTOs have considered recently as the advantages of cloud computing  are frequently heralded as the next evolution of managing an IT infrastructure. Moving your IT infrastructure to a cloud could save your company money on hardware and software costs, it could save time by providing maintenance and management for your data, and it can save resources by eliminating the needs and requirements for equipment storage.

However, any shift from the norm is met with some fair amount of healthy skepticism. And no company should hastily make the switch to cloud computing without first examining the disadvantages as well as the advantages. The reality is there is no one-size-fits-all answer when it comes to cloud computing and ultimately the decision must be made by examining the needs and operational requirements of each company and comparing these to the available cloud computing services.

Understanding the benefits of cloud computing first comes by examining the three different levels of service that cloud computing can provide: infrastructure-as-a-service, platform-as-a-service and software-as-a-service.

Infrastructure-as-a-service, also known as hardware as a service, uses virtual machines to connect to a partitioned space on the cloud servers. The local computers connect through via the Internet to the cloud server that does all the heavy lifting. The obvious benefit here is that it eliminates the cost of an in-house infrastructure – companies do not need to invest in capital expenditures like servers, data center space, and network equipment to get up and running. You can still use your own software, but it is all run on the cloud instead of your local computers. This is a great option for small, startup companies because they can immediately have access to an enterprise-grade infrastructure for a fixed monthly fee. Some vendors of hardware as a service include Rackspace, Sunguard, Cloudscaling, Amazon, Google and IBM.

The next level of cloud computing is platform-as-a-service. This option provides you with a development platform where you can develop software applications for the web. The cloud provider takes care of handling the loading for you and ensures your applications are elastic with the number of users. Think of Facebook as an example of a platform as a service provider. Third party developers can write new applications that Facebook makes available on their social application platform. Google also provides APIs to developers to build web applications. This service is useful for software development companies because the cloud provider facilitates the development of applications without the cost and complexity of buying and managing the underlying hardware and software provision hosting capabilities. You have all the facilities required to complete the development life cycle, from development, to testing, to deployment, to hosting, to maintenance in the same integrated development environment. This is a useful solution for companies that want to focus exclusively on software development because it relieves their platform woes. For companies that already use a platform internally, the platform-as-a-service advantage is that the cloud platforms are designed to scale linearly. Cloud development platforms have guidelines that help the application scale to accommodate any number of users.’s is an example of a platform as a service vendor

The highest level of cloud computing is software-as-a-service, also called software on demand. Here, companies simply use software on a cloud rather than buy it, license it, upgrade it, and patch it on their local machines. Anyone using a service like Yahoo Mail or Google Docs is already using software as a service cloud computing. This is the most popular form of cloud computing because it is highly flexible and minimizes the maintenance of software. This service is best suited for companies that are not specifically in the technology business and simply need their software to be available and require little maintenance. Even companies who already have their own software should look into using software-as-a-service if they spend a lot of time on the maintenance of in-house software. There are many providers of software-as-a-service, including Amazon, Microsoft and Google.

Now, while many of these cloud computing services sound beneficial, there are still some disadvantages to take into account before jumping into a cloud. Keep in mind that all of these services require an Internet connection. If your connection goes out, you won’t be able to connect to the cloud and use the hardware, platform, and/or software that your company requires to operate. In this case, companies may want to still invest in some local infrastructure so operations do not come to a crashing halt.

Another concern is that some companies are apprehensive about turning all their data over to a third party (not to mention, it can be a chore to migrate massive amounts of data to a cloud). How can they be sure their data is protected? What if the cloud server is hacked? While these questions should be investigated, remember that cloud computing services live and die by their reputations, so information assurance is a high priority for all of them.

These fears of cloud computing stem from the fact that your company is at the mercy of a third party. There is a loss of control and it is not a predictive as having a local infrastructure. If something goes wrong, you have to depend on your cloud provider to respond and troubleshooting can be very complicated. Many companies are still reluctant to give up control over their data.

But with these warnings in mind, cloud computing has many general advantages that all companies can appreciate. Company data is backed up and secured by your cloud provider. Less equipment and hardware saves space and reduces electricity costs. Users have access to the same data and software no matter how geographically diverse. With less time spent on “keeping the lights on” with in-house maintenance, CTOs can better spend their time and resources on future growth. And with a fixed cost structure for the service, you can better allocate your IT budget.

Companies may want to consider first testing the waters by using an existing cloud offering as an extension of their in-house architecture. Then, if the company is comfortable with the service, they can move new projects to cloud-based services. Finally, the company can migrate their existing applications to the cloud if the cloud is reliable and it makes sense economically.

In the end, it is up to each individual CTO to determine if the advantages of cloud computing make sense for their company. This can only be determined with a thorough assessment of the costs and requirements of their technology needs and comparing it to the costs and risks of a cloud computing service. While it may be economical for some companies, it may not be for others. But for every company, it is worth at least worth the time and effort to look into.

Cybercriminals Target IRS E-filing PIN application


IRS counters efforts to hack e-filing PIN system.

The Internal Revenue Service (IRS) has released details about a cyber attack upon its Electronic Filing PIN application. The IRS reported that it has stopped the cyber attack.

IRS officials said they identified unauthorized attempts involving approximately 464,000 unique Social Security Numbers (SSNs), of which 101,000 were used to successfully access an E-file PIN. The automated attack used personal data stolen elsewhere outside the IRS to attempt to generate E-file PINs for the SSNs.

“Using personal data stolen elsewhere outside the IRS, identity thieves used malware in an attempt to generate E-file PINs for SSNs,” the IRS said in a prepared statement. “No personal taxpayer data was compromised or disclosed by IRS systems. The IRS also is taking immediate steps to notify affected taxpayers by mail that their personal information was used in an attempt to access the IRS application.”

All affected taxpayers will be notified by mail of the attack. “The IRS is also protecting their accounts by marking them to protect against tax-related identity theft,” the agency added.

The IRS was also quick to assure that the attack was not related to the temporary shutdown of the e-filing system, during which time the IRS could not accept many returns due to a system-wide computer failure, according to Fortune.

IRS cybersecurity experts are currently assessing the situation, and the IRS is working closely with other agencies and the Treasury Inspector General for Tax Administration. The IRS also is sharing information with its Security Summit state and industry partners.

In this recent event, cyber criminals used a list of known SSNs to make repeated attempt to access the IRS’s Get My Electronic Filing PIN portal. But as Naked Security pointed out, “Ironically, an E-Filing PIN is a sort of second factor of authentication (2FA), that you need, along with other personal data, when submitting online tax returns. In other words, it seems that you can request your second factor of authentication by using your first factor, which isn’t quite the idea of 2FA.”

This new attack follows a 2015 massive data breach at the IRS, during which hackers stole information from approximately 330,000 taxpayers to obtain $50 million in federal funds through false tax returns. An inspector general report following the breach discovered that the computer system the IRS had been using to detect identity theft may have been vulnerable to hackers.

These breaches underscore the importance of ensuring proactive data security that circumvents the opportunities for such events to occur in federal databases. It also highlights concerns about requiring multi-factor authentication to access sensitive data.

If Amazon were in Apple’s position, would it unlock its cloud for the feds?

There’s an easy way to protect your data in the cloud.

As Apple continues to resist FBI demands to unlock a terrorist suspect’s phone, it raises a question: What if Amazon Web Services was ordered to provide access to a customer’s cloud? Would AWS hand the data over to the feds?

+MORE AT NETWORK WORLD: Tim Cook issues internal memo on ongoing FBI/iPhone saga | VMware turns to IBM in the public cloud +

Amazon’s terms of service provide us a clue. AWS says it complies with legally binding orders when compelled to do so. Here’s a statement from Amazon’s FAQ on cloud data privacy (which is not written specifically about the Apple-FBI issue):

“We do not disclose customer content unless we’re required to do so to comply with the law or a valid and binding order of a governmental or regulatory body. Governmental and regulatory bodies need to follow the applicable legal process to obtain valid and binding orders, and we review all orders and object to overbroad or otherwise inappropriate ones.”

Most of the time, when ordered to hand over data, Amazon does so. In 2015 AWS received 1,538 subpoenas from law enforcement officials, according to information the company recently began making public. Just over half the time (in 832 cases, or 54% of the time) AWS complied fully with those orders. Another quarter of the time (in 399 cases) Amazon partially responded to the request for information, while in the remaining 20% of cases AWS did not respond to the subpoena.


For customers who are concerned about Amazon handing over their data to the government, there are protections that can be put in place. “There’s a huge market focused on encrypting data stored in the cloud, and giving the customers the keys,” explains 451 Research analyst Adrian Sanabria. If customers use a third-party encryption service to scramble their data and manage the keys themselves, then even if Amazon did hand over the data to the feds, it would be useless. “Yes, it does sometimes create some issues with flexibility and breaking functionality, but it is there as an option if you want it, and (if done properly) AWS (or the government) can’t decrypt the data,” Sanabria says.

+ MORE ON APPLE: Apple and the FBI will need to compromise, Cisco’s CEO says +

AWS offers multiple different encryption methods, including ones that are built in automatically to some services – like S3, the Simple Storage Service, and others that customers manage themselves, such as the Hardware Security Module (HSM). AWS’s marketplace offers a variety of additional encryption and security services from independent software vendors.

Amazon says that it notifies customers when there’s been a request for their data to be handed over, unless there’s a compelling reason not to do that; for example if its clear the cloud service is being used for an illegal purpose.

AWS is more stringent about not providing other types of information to the government. In the second half of 2015 alone, AWS received 249 “National security requests” but did not comply with any of them. AWS also received 78 requests from non-U.S. entities, the vast majority of which (60) the company did not respond to.

AWS did not respond to a request to comment on this story.

Microsoft Azure basically has the same policy, according to the company’s website, saying “We do not provide any government with direct or unfettered access to your data except as you direct or where required by law.”

Even with all the concern over providers or the government being able to access data, Sanabria estimates that only a minority of cloud users encrypt data and manage their own keys.





Internet of Things sparks healthcare cybersecurity concerns, HIMSS16 speaker says

As connectivity continues to expand, cybersecurity should be top of mind for CIOs, CISOs and other hospital executives, according to Eric Miller of Ascension.

medicaldevicehitn_0The Internet of Things is set to explode. Forecasters expect more than 6 billion objects connected to the Internet this year and some expect 50 billion by 2020. But with connectivity comes risk.

For healthcare providers trying to leverage what is emerging as the IoT for healthcare – that growing universe of wearable sensors, networked devices and home monitoring systems deployed to collect medical data and even treat patients – ineffective cybersecurity can have potentially dangerous consequences.

“The Internet of Things is different from the Internet of Things for healthcare in terms of risk,” said Eric Miller, senior director of IT at Ascension Information Services.

Miller pointed to a recent initiative in which white hat hackers working with the Mayo Clinic were easily able to hack into numerous connected medical devices, including an infusion pump that delivers drugs and fluids into patients.

One of the hired hackers, in fact, was able to connect an infusion pump to his computer network and manipulate the dosage remotely.

Miller and Paul Unbehagan, chief architect of Avaya, will discuss technologies that enable the security of connected devices and how providers can recognize and mitigate these cyber security risks during a HIMSS16 session on March 1, 2016.

“Our goal is to show how to reduce the risk from connected medical devices in a manageable way,” Miller added. “There’s a process side to it and a technology side, and we will discuss both,” Miller said.

The session will cover how providers can get a handle on the number and types of Internet of Things for healthcare devices connected to their network; how to apply risk models to device classifications in order to clarify the threat level; how to implement automation to manage the security of the growing number of connected devices; how to evaluate inventory management options against existing technologies; and how to create an implementation plan.

“We want attendees to leave this session with an understanding of how to improve their risk posture for the existing Internet of Things for healthcare as well as the connected devices to come,” he said.

The Internet of Healthcare Things” will be held Tuesday, March 1, from 1 – 2 p.m. PST in the Sands Expo Convention Center Human Nature Theater.


DHS Establishes Information Sharing Capability and Process Required under CISA; Issues Multi-Agency Information Sharing Guidance

The Department of Homeland Security (“DHS”) has posted four documents on the US Computer Emergency Readiness Team (US-CERT) website to satisfy several requirements set forth in the  Cybersecurity Information Sharing Act of 2015 (“CISA”).  Details on the four documents are provided below.

By way of background, CISA was passed into law on December 18, 2015 and provides authorization for, among other things, the sharing of cyber threat indicators and defensive measures by and between the federal government, private entities, and state, local, and tribal governments.  The law also provides liability protections for non-Federal entities that share or receive cyber threat indicators or defensive measures, provided that these activities are conducted “in accordance with” the Act.  This requires, among other things, that (1) the information shared meets the definitions of cyber threat indicator or defensive measure, as applicable; (2) that the sharing be “for a cybersecurity purpose”; and (3) that the sharing entity comply with the requirement to screen information prior to sharing it for personal information that is not directly related to a cybersecurity threat and remove it.

In addition, when sharing with the federal government via electronic means, liability protections generally attach only if the information is submitted through the capability and process required to be established by DHS under the act.  CISA directs that this be “through electronic mail or media, an interactive form on an Internet website, or a real time, automated process between information systems.”

In keeping with these requirements, the three ways DHS has established for entities to electronically submit cyber threat indicators to the federal government are as follows:

  1. Via DHS’ Automated Indicator Sharing (“AIS”) program, which allows entities to share information with the federal government in real time by connecting through a specialized client to an AIS server operated by DHS’s National Cybersecurity and Communications Integration Center (NCCIC).  Information shared in this manner must conform to the Structured Threat Information eXchange (STIX) and be transmitted via the Trusted Automated eXchange of Indicator Information (TAXII), which are the format and exchange mechanisms, respectively, selected by DHS for real time threat sharing.  Among other features of AIS, DHS notes that it:
    • Performs a series of automated analyses and technical mitigations to ensure that personally identifiable information that is not directly related to a cybersecurity threat is removed before any information is shared (with human review where necessary); and
    • Anonymizes the identity of the submitter of the information, unless the submitter has consented to sharing its identity.
  2. Via email.  When using this method, entities must email “” and ensure that the shared information conforms to specified formatting requirements.
  3. Via a webform established by DHS for this purpose.

DHS discusses these methods for sharing cyber threat indicators and defensive measures with the federal government in one of the four documents it posted: Interim Procedures Related to the Receipt of Cyber Threat Indicators and Defensive Measures by the Federal Government.  This document, issued by the Secretary of Homeland Security and the Attorney General in consultation with the heads of appropriate federal agencies, “describes the processes for receiving, handling, and disseminating information that is shared pursuant to CISA,” as required under Section 105(a)(1) of CISA.

The other three documents that DHS posted to its website generally satisfy specific directives in CISA to provide additional detail around certain processes, as follows:

  1. Guidance to Assist Non-Federal Entities to Share Cyber Threat Indicators and Defensive Measures with Federal Entities under the Cybersecurity Information Sharing Act of 2015: This document responds to Congress’s directive in Section 105(a)(4) of CISA and provides guidance on (1) types of information that would qualify as a cyber threat indicator that would be unlikely to include information that is not directly connected to a cybersecurity threat that is also personal information or personally identifiable information, and (2) types of information protected by otherwise applicable privacy laws and that are unlikely to be directly related to a cybersecurity threat.
  2. Privacy and Civil Liberties Interim Guidelines: Cybersecurity Information Sharing Act of 2015:  Section 105(b)(1) of CISA directs the Attorney General and Secretary of Homeland Security to “jointly develop, submit to Congress, and make available to the public interim guidelines relating to privacy and civil liberties which shall govern the receipt, retention, use, and dissemination of cyber threat indicators by a Federal entity obtained in connection with activities authorized in this title.”  The interim guidelines created in response to this directive direct federal entities to “follow procedures designed to limit the effect on privacy and civil liberties of federal activities under CISA.”  Specifically, the interim guidelines define CISA-specific implementations of the Fair Information Practice Principles (FIPPs) set forth in Appendix A of the National Strategy for Trusted Identities in Cyberspace, namely: transparency, individual participation, purpose specification, purpose specification, data minimization, use limitation, data quality and integrity, security, and accountability and auditing.
  3. Sharing of Cyber Threat Indicators and Defensive Measures by the Federal Government under the Cybersecurity Information Sharing Act of 2015: In response to a directive in Section 103 of CISA, the Director of National Intelligence, the Secretary of Homeland Security, the Secretary of Defense, and the Attorney General, in consultation with the heads of appropriate federal entities, issued these procedures, which “facilitate and promote” the sharing of threat information by the federal government with non-federal entities, such as private entities and state and local governments.  Such sharing falls into the following categories:
    • Timely sharing of classified cyber threat indicators and defensive measures in the possession of the Federal Government with representatives of relevant federal entities and nonfederal entities that have appropriate security clearances;
    • Timely sharing with relevant federal entities and non-federal entities of cyber threat indicators, defensive measures, and information relating to cybersecurity threats or authorized uses under this title, in the possession of the Federal Government that may be declassified and shared at an unclassified level;
    • Timely sharing with relevant federal entities and non-federal entities, or the public if appropriate, of unclassified, including controlled unclassified, cyber threat indicators and defensive measures in the possession of the Federal Government;
    • Timely sharing with federal entities and non-federal entities, if appropriate, of information relating to cybersecurity threats or authorized uses under this title, in the possession of the Federal Government about cybersecurity threats to such entities to prevent or mitigate adverse effects from such cybersecurity threats; and
    • Periodic sharing, through publication and targeted outreach, of cybersecurity best practices that are developed based on ongoing analyses of cyber threat indicators, defensive measures, and information relating to cybersecurity threats or authorized uses under this title, in the possession of the Federal Government, with attention to accessibility and implementation challenges faced by small business concerns (as defined in Section 3 of the Small Business Act (15 U.S.C. 632)).

The procedures note that the required information sharing is currently implemented through a series of existing programs, of which the procedures provide an overview.  The procedures also provide an overview of the roles and responsibilities of federal entities, non-federal entities, and Information Sharing and Analysis Centers (ISACs) and Information Sharing and Analysis Organizations (ISAOs) in the information sharing context.

For Your Eyes Only: Experts Explore Preventing Inadvertent Disclosures During Discovery

The Altep, kCura and Milyli webinar explored best practices for safeguarding information, as well as technological tools for redaction

There may be a number of “Scott’s” in Chicago, but there are fewer with a specific last name attached, and there is only one with that specific Social Security Number. This information – or a telephone number, or a fingerprint, or even the MAC address of a computer – can be used to identify and verify a person.

But of course, for as valuable as personally identifiable information (PII) may be for you, it’s just as valuable to a malicious actor looking to steal and utilize it for nefarious purposes. That’s why, when conducting discovery, protecting that information should be of the utmost importance for organizations, law firms, and discovery vendors.

Three of those legal technology companies joined together to put that security forth in a recent webinar called“How to Prevent the Disclosure of PII.” The webinar’s panel included Hunter McMahon, vice president of legal and consulting services, Altep; Scott Monaghan, technical project manager, Milyli; Aileen Tien, advice specialist, kCura; and Judy Torres, vice president of information services, Altep.

In order to prevent disclosure, the panelists asked one important question: What exactly is PII? “It really comes down to what information can identify you as an individual,” McMahon said. This includes information that can be categorized into different categories based on how specific and how personal it is , leading McMahon to notenote that data holders should examined PII to determine if it is sensitive, private, or restricted.

When examining PII in the system, it’s also important to examine what regulations and laws the PII falls under. This can include a number of different federal regulations, HIPAA/HITECH (health PII), GLBA (financial PII), Privacy Act (PII held by Federal Agencies), and COPPA (children’s PII). Forty-seven states also have their own information laws, including varying guidelines on breach notification, level of culpability, and more.

Once that information is known, said the panelists, those conducting discovery should turn to the next question: What are the processes in place to protect the data? “Documents that are in the midst of discovery are really an extension of your retention policy… so you have to think about that risk the same way,” McMahon noted.

Torres explained that the proper approach to take to PII is that it will always be in a document set, if it seems unlikely that PII exists in a system. For example, she said not to assume that because a data set concerns only documents accessed during work hours, it will not contain PII.

“Most people, when they’re working, are also working the same time as those people they need to send documents to,” Torres explained. In one case, looking at data from Enron’s collapse, the documents in the case contained 7500+ instances of employee PII, including that of employee’s spouses and children, as well as home addresses, credit card numbers, SSN, and dates of birth.

In order to combat this data lying in the system, it’s important to take a proactive approach, the panel said. “The approach is much like data security in that it’s not going to be perfect, but you can help reduce the risk,” McMahon added.

To protect it in review, those conducting discovery can limit access to documents with PII, limit the ability to print, and limit the ability to download native files. Likewise, teams can employ safeguards during review such as training review teams on classifications of PII, training reviewers on PII workflow, implementing a mechanism for redaction and redaction quality control, and establishing technology encryption.

And even if not using human review, abiding these protocols can be important, “I see such a trend of more cases using assisted review, so you’re not necessarily having human eyes on every document. So it makes sense to make our best effort to protect PII on documents that may not necessarily have human review,” Torres said.

Properly conducting redactions to make sure nothing is missed can be a pain for reviewers as well, but Tien walked the webcast’s viewers through an introduction of regular expressions (reg-ex), one of the most common technology tools for PII redaction. In short, reg-ex is a pattern searching language that allows one to construct a single search string to search for a pattern of characters, such as three numbers, or three letters.

For one example, Social Security Numbers have a very specific format: XXX-XX-XXXX. Reg-ex can be used to find all constructions of this type, using an input like the following: [0-9]{3} – [0-9]{2} – [0-9]{4}

“With practice, you’ll be able to pick this up like any foreign language,” Tien said.

See post Sneaky PII: What’s Hiding in Your Data?

PCI DSS 3.2 slated for early 2016


To accommodate updated migration dates to a more secure version of TSL and other factors in the payment industry, the PCI Security Standards Council will release PCI DSS version 3.2 in the spring

PCI DSS version 3.2, scheduled for release in the first half of 2016, likely March or April, will address  the current threat landscape as well as “trending attacks causing compromises” detailed in current breach forensics reports, PCI Security Standards Council Chief Technology Officer (CTO) Troy Leach said in a blog post Q&A.

“With this in mind, for 3.2 we are evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed,” Leach said.

New versions of PCI DSS are typically released in the fall, but the council moved 3.2’s debut up, in part, to “address the revised migration dates away from SSL/early TLS,” Leach said. In a December bulletin, the council extended the deadline to June 30, 2018 for organizations to complete migration from Secure Socket Layer and Transport Layer Security 1.0 to a secure TLS iteration.

An early release also acknowledges PCI DSS‘s status as a “mature standard” that doesn’t need significant updates any longer. “Moving forward, you can likely expect incremental modifications to address the threat landscape versus wholesale updates to the standard,” he said.

Leach also noted that a spring release “with long sunrise dates” gives organizations time to do the business case for their security investments in the drastically changing payment acceptance market “from advancements in mobile payments to EMV chip rollout in the United States, to adoption of other forms of dynamic data and authentication.” An earlier release “allows us more time to dedicate to security priorities for those specific payment channels in the future,” he explained.

Additionally, the organization will release changes to PA-DSS a month after PCI DSS 3.2 is unveiled.

As is customary, the council will retire version PCI DSS 3.1 three months after it releases version 3.2.