Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."
Virtualization Will Continue to Dominate IT Strategy & Infrastructure
Large and small enterprises will continue to grow their virtualization footprints at the same time that they are looking to migrate applications to the cloud. The cost reductions provided by the market leader VMware will ensure that the VMware customer base will continue to consolidate applications and servers on their virtualization technology and that they will continue to be a powerful player in the IT infrastructure space for many years.
While VMware is the dominant technology provider for virtualization, we will see Microsoft attempt to increase their footprint with Hyper-V, and OpenStack solutions will also expand. We expect that all of the virtualization solution providers will attempt to de ne a clear path to the cloud based on their technologies. VMware is already moving in this direction with their vCloud Air initiative, and Microsoft uses Hyper-V as the foundation for the Azure cloud.
Encryption key management solutions that only run in hardware, or that only run on cloud platforms, present substantial obstacles for businesses with virtualized data centers. The rich set of management and security tools are not able to work effectively with solutions that are outside the virtualization boundary. Customers are looking to reduce their hardware footprint, not increase it. And solutions that can’t be managed or secured in the usual way represent additional risk and cost. Encryption key management solutions should be able to run within the virtualization boundary as an approved security application. Key management vendors vary greatly in their ability to support the range of deployments from traditional IT data center, to virtualized plat- forms, to the cloud. Organizations will continue to struggle with key management across these environments.
- Encryption key management solutions should be able to run as fully native virtual machines in a VMware or Hyper-V environment.
- Encryption key management solutions should be compatible with security and management functions of the virtual platform.
- To maintain maximum business flexibility, deploy a key management solution that works well in virtual, cloud, and traditional hardware platforms.
- Look for key management solutions that carry industry security certifications such as PCI Data Security Standard (PCI DSS), etc.
Key Management Vendor Stability Loses Ground
Merger and acquisitions in the security community continue at a rapid pace. Encryption key management vendors are being absorbed into larger organizations and this trend will likely continue. The public relations around such mergers and acquisitions is always accompanied with glowing prognostications and happy talk. Unfortunately, as often happens with any merger, key management vendors may experience disruption in their organizations as a result of a merger or acquisition. A key management solution may not be strategically important to an acquirer and this can result in disinvestment in the solution negatively impacting customer support. Key management is a part of an organization’s critical infrastructure and these changes can be disruptive.
Organizations can work to minimize the potential impact of key management vendor consolidation by understanding the vendor’s organizational structure, corporate history, and financial basis. Venture backed organizations can be expected to experience an exit through a merger, acquisition, or public offering. Vendors with solutions that are not strategically important to their product mix can also experience change and disruption. Using care in key management vendor selection may be one of the most important efforts you can make. This will be a continuing challenge in the years ahead.
- Understand your key management vendor’s equity foundation and the likelihood of a merger or acquisition. If the key management vendor is largely funded by venture capital it is almost certain that the company will experience a merger or acquisition event.
- Understand your key management vendor’s management team. Have key employees been with the company for a longer period of time? This is one good indicator of organizational stability.
Vendor Customer Support is a Growing Concern
As mentioned previously, encryption key management vendors continue to be absorbed into larger organizations and this trend will likely continue. Unfortunately, as can happen with any merger, key management vendors may experience disruption in their organizations as a result of a merger or acquisition. This can directly a effect the customer support organization and your ability to get timely and reliable technical support for your encryption key management solution. Deteriorating customer support can put your organization at risk. Key management solutions are a part of your critical infrastructure and proper customer support is crucial to operational resilience.
Another side affect of reduced or under-funded customer support is the inability of your organization to expand and invest in new applications and systems. These impacts on customer support may not present short-term problems, but can impair long-term resilience and growth flexibility. Many organizations will continue to experience inadequate customer support from key management vendors.
- Understand the customer support organization of your key management vendor. Does the vendor demonstrate a strong investment in customer support? Is there adequate management of the customer support team?
- Review the Service Level Agreement (SLA) provided by your key management vendor. Be sure you understand the expected response times provided by the vendor customer support team.
- How do other organizations experience customer support from your key management vendor? Be sure to talk to reference accounts who use the key management product and who have interact- ed with the vendor’s customer support team.
The news has been heavy recently with stories of Ransomware attacks on hospitals, businesses, and even police departments. The basic Ransomware attack usually starts with a user clicking on a poisoned link or opening an infected document or file. A trojan program installed on a user PC or server then runs and denies access to that data until a ransom is paid.
The denial of access to data is often done through the encryption of all of the files on a PC. CryptoLocker is an example of this type of access denial, but there are now many variants of encrypted access denial. Other methods of access denial have been used, but encryption is now the most common method. Strong encryption is readily available to anyone including cybercriminals, and unless the attack uses poor encryption methods there is no way to unlock the data without paying the ransom to receive the decryption key.
A disturbing trend has developed with Ransomware over the last few months. In addition to encrypting a user’s PC or a single server, Ransomware has taken to encrypting network and mounted drives, even drives that are mirrors to cloud storage services. The mounted drives might even include your backup storage! The encryption of network drives affects a much larger group of users and can be devastating to the organization as a whole. And when the backup network drive is affected there is no way to even restore from that backup. Many organizations can afford to lose a single user PC - but imagine losing all of the company’s information on a central server!
Monetarily, ransoms are usually not very large, but there are exceptions. Cyber criminals know that a smaller ransom is more likely to be paid and they can then move on to the next victim. Ransom payments are usually done in Bitcoin to avoid tracking the payment through the normal banking system. While not a perfect strategy for cyber criminals, it usually works pretty well.
So, what can you do to avoid the catastrophic loss of your data from a Ransomware attack?
Old style, off-site, disconnected backup is back in fashion!
Whatever is connected to your network is at risk in a ransomware attack. Backup cartridges stored off-site at an archival service like Iron Mountain, or even stored at your local bank, can’t be damaged by Ransomware. I know that many organizations have migrated to cheaper online and virtual tape backup systems, but these may be accessible to a dedicated attacker. If your internal systems can “see” the backup storage, so can an attacker. You need to have backups that are not accessible to the attacker - put some airspace between your backups and the cyber criminals!
Tape, cartridge and disk-based backup systems have been around for quite some time, are reasonably priced, and can be quick to deploy. Here are some things to look for in backup systems:
- Tape or disk physical media can be stored off-site
- Backups should be encrypted - don’t risk the loss of an unencrypted tape or cartridge
- Don’t share keys across individual backups - every backup should have a unique key.
- Create documented procedures for backups.
- Create documented procedures for restoring from backup.
- Test your restore! Your backup strategy is only as good as your proven ability to restore from the backup.You don’t have a backup strategy until you’ve tested it with an actual restore!
- Schedule your backups so that they are automatic.
Because old-style off-site backup has been around for a while you will find good documentation and best practices about backup and recovery. You don’t have to reinvent the wheel here. Mature and proven solutions are available right now.
Addressing off-site backup may seem old-fashioned to you right now. You won’t think so if your organization falls victim to a Ransomware attack! Here at Townsend Security we use a cartridge backup solution from Quantum who are one of our partners, but you have lots of choices. Get started now!
Those of us in the data security industry often wear technology blinders as we go about the business of trying to secure the sensitive data of the organizations we serve. Every organization has limited resources and it is hard to compete with line of business needs in terms of budget and human resources. It’s an ongoing struggle that comes with the territory.
Of course, any organization that has suffered a severe data breach quickly changes its attitude towards investing in security. The internal attitudes at Target, Anthem and Sony are different today than they were in the past, and for good reasons.
For those who’ve not experienced a data breach, the organizational costs remain vague and theoretical. I thought you might like to read how an attorney views the impacts of a data breach that involves the loss of credit card information. David Zetoony, an attorney with the legal firm Bryan Cave, has written several white papers discussing aspects of security. These are very readable works and well worth the time. Even if you are not processing credit card payments, I think this article is relevant to the loss of any sensitive data.
Here is his paper on the impacts of a data breach involving credit cards.
There is a bonus section in this paper about cyber insurance. In my eBook on Key Management Trends and Predictions I mention Cyber Insurance as an evolving industry. This paper by David Zetoony delves much deeper into the issues related to Cyber Insurance. He provides some very practical advice on how to think about Cyber Insurance and how to evaluate potential coverage. If you are new to the topic, or if you’ve not reviewed your Cyber Insurance policy for more than a year, you need to read the second part of David’s paper.
Neither I nor Townsend Security has any relationship with David Zetoony and the legal firm of Bryan Cave. I stumbled on this David’s work and thought you might find this informative. For those of you making the case for increased security, you might consider sharing David’s paper with your management team and legal counsel.
This is a special blog post written for Townsend Security by the Drupal Drop Guard team.
While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, we’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.
The general deployment workflow
Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let us sum up the development activity of the different branches.
This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.
The stage branch is where code that’s about to be released (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.
The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.
Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)
Where to commit Drupal updates in the development workflow?
To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).
If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.
Low (<=1 month):
- Bug fix updates - Feature updates
These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.
Medium (<5 days):
- Security updates that are not critical and not highly critical
These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.
High (<4 hours):
- Critical and highly critical security updates
For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!
Updates automation options
There are only a few ways to ensure the updates will be applied just in time and when it’s really needed, depending on the type of update. Any of those have positive and negative sides, and it’s only up to you to choose what suites you the best:
- Monitoring for updates manually or via one of available services or custom scripts, and once the security update is detected, process it according to the workflow defined in your organization. This approach works in most cases, but it requires someone to be ready to take action 24/7;
- Building a completely custom solution, which will not only detect updates, but also take care of applying them when it’s time. The only obvious drawback of this is that you have to spend a lot of time building and maintaining your custom tool.
- Using the updates automation service, such as Drop Guard, which will integrate seamlessly in your workflow and process updates in exactly the way you want. You don’t have to worry about being alerted all the time, or spending too much time on building your own solution, but be prepared to spend a few dollars on the 3rd party solution.
Requirements for automation
If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:
- Code deployment with GIT
- Trigger the update of an instance by URL using e.g. Travis.ci, Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.
Also to keep in mind:
- Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
- Automated tests reduce the time you spend on quality assurance
Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.
There are many ways of ensuring the continuous security for your website, and it’s up to you whether to go with a completely manual process, try to automate some things, or opt-in for a fully automated solution such as Drop Guard.
As the importance of encryption increases across the regulatory spectrum, it is heartening to see database vendors implementing encryption and encryption key management that meet security best practices. MongoDB Enterprise is one of the most popular modern databases and has given its customers the ability to quickly and effectively implement encryption and good key management at the level of the database itself. This means that MongoDB Enterprise customers can transparently implement encryption directly in the database without deploying third party file or volume based encryption products to accomplish this task. MongoDB customers enjoy rapid deployment of encryption, a unified management interface to the database, high performance encryption, and integrated encryption key management based on the industry standard Key Management Interoperability Protocol (KMIP).
By basing key management on the OASIS KMIP standard MongoDB is providing real benefits to their customers. These include:
- Rapid implementation of key management with no need for developer resources.
- No requirement for server-side software libraries, updates, and patching.
- Secure encryption key retrieval services based on TLS.
- Vendor neutrality for encryption key management services.
- Vendor portability and avoidance of vendor lock-in.
- Seamless migration from one key management solution to another.
MongoDB Enterprise is a case-study in the benefits of using open standards for encryption and key management. MongoDB’s customers can choose the key management solution that makes the most sense for them, and having choices reduces the cost of encryption key management.
Townsend Security's Alliance Key Manager solution works out of the box with MongoDB Enterprise to help customers meet compliance regulations which require encryption of sensitive data. It takes just a few minutes to deploy Alliance Key Manager and to configure MongoDB for key management. On first boot, Alliance Key Manager creates a set of strong encryption keys including a 256-bit AES key that can be used with MongoDB, and it creates a set of PKI certificates used for TLS authentication. The PKI certificates are copied to the MongoDB server to secure the connection to the key manager. A quick command or two from the MongoDB command line console and, Voila! Your MongoDB encryption key is now fully protected by a key encryption key on Alliance Key Manager. You have an encrypted MongoDB database and a highly redundant and recoverable encryption key management infrastructure. From the technical team at MongoDB:
“The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a file system perspective, and data only exists in an unencrypted state in memory and during transmission.”
After installing the key manager certificates on the server hosting the MongoDB database, here is an example of the command to enable encryption:
mongod --enableEncryption --kmipServerName akmmongo --kmipServerCAFile /etc/mongodb-kmip/AKMRootCACertificate.pem --kmipClientCertificateFile /etc/mongodb-kmip/AKMClientCertificate.pem --dbpath /var/lib/mongodb/
It’s that simple.
With Alliance Key Manager you have your choice of network-attached hardware security modules (HSMs), VMware virtual machines, and dedicated cloud instances in Microsoft Azure and Amazon Web Services. The key manager works the same way in all environments so you can even mix and match hardware, VMs, and cloud instances to achieve the level of security that is right for your organization. All instances of Alliance Key Manager are dedicated to you with no access by cloud service providers or third parties. Key custody remains exclusively under your control.
Many MongoDB customers deploy the database in VMware environments. Alliance Key Manager also runs in VMware as a virtual machine. You can deploy the key manager in a VMware security group and protect one or more instances of MongoDB across the entire VMware environment. If you are running on a VMware vCloud platform the same support is provided for key management.
For compliance, Alliance Key Manager is validated for PCI-DSS compliance in the VMware platform. This will help you achieve PCI-DSS compliance for your MongoDB database and applications. The PCI-DSS statement of compliance is here.
MongoDB is rapidly becoming the high performance, scalable, NoSQL database of choice for organizations large and small. As such it becomes a part of the critical infrastructure for business applications. Alliance Key Manager also implements high availability features such as automatic, real-time encryption key mirroring, and backup. For customers deploying the hardware version of Alliance Key Manager, there is redundancy at the hardware level with dual hot-swappable RAID disks, redundant power supplies, and redundant network interfaces. All of these features mean that your key management infrastructure will be resilient and reliable.
Alliance Key Manager will help you will meet common compliance regulations such as PCI-DSS, HIPAA, FFIEC, FISMA, the EU General Data Protection Regulation (GDPR), and other compliance schemes. Alliance Key Manager regardless of platform is based on the same FIPS 140-2 compliant software found in our enterprise level HSM. With no restrictions or license costs for client-side connections, you can protect as many MongoDB databases as you like with one Alliance Key Manager.
The product team at MongoDB did a great job of implementing encryption and key management for their customers. They deserve to be applauded for basing their solution on industry standards like KMIP. This will lower the bar for getting encryption right in the database. With Alliance Key Manager, getting encryption right means rapid deployment, conservation of developer resources, lower administration costs, and provable compliance.
A match made in techno-heaven.
The new European Union General Data Protection Regulation (EU GDPR) has now passed both the EU Council and Parliament and replaces the earlier Data Protection Directive (Directive 94/46/EC). Unlike an EU directive, this regulation does not require individual countries to pass legislation and it goes into effect immediately. Organizations have a two-year transition period to comply with the new data protection regulations, but it would be unwise to delay. Smart organizations will start work immediately so that there are no gaps upon the arrival of the deadline, and so that their public reputation is preserved. A good overview of the regulation can be found here and it contains a link to the full regulation.
There are many aspects to the new GDPR, and if you are required to meet the regulation you should take a very close look at the entire publication. Let’s look at a few of the elements of the GDPR with a focus on data protection.
What information must be protected?
The regulation uses two terms that are important to understand. The term “data subject” means an individual person. The term “personal data” means any data that either directly identifies an individual person, or which can be used indirectly to identify an individual. A few examples of data that indirectly identify an individual would include a medical identification number, location data such as an IP address, or social identity such as an email address or Facebook account.
The definition of personal information is quite broad. It would be a mistake to narrowly focus on just a few fields of data in your database, you should look for all information about a person that you store. If any information uniquely identifies a person, or if information can be combined to identify a person, it should be protected.
What constitutes a data breach?
The definition of a data breach is much broader than defined in the US. It certainly includes the the accidental loss of data or the loss of data in the course of a data breach by cybercriminals. But it also includes other activities including the accidental or unlawful:
- Destruction of personal information.
- Alteration of personal information.
- Unauthorized disclosure of information, even without criminal intent.
- Access to personal information.
In other words, assume that the data you store about an individual belongs to them exclusively, and is valuable. You are holding it in trust, and you have a fundamental responsibility to preserve and protect that information! This will be a conceptual challenge for organizations more familiar with US data protection rules.
Non-EU organizations should pay special attention to this definition of a data breach. It goes far beyond what typical regulations in the US define as a data breach.
What are my breach notification requirements?
The data breach definition applies to all personal information that is transmitted (data in motion) or stored (data at rest) or in any other way processed by your organization. In the event you experience a data breach you must notify the appropriate authorities and the individuals who are affected. There are stringent time constraints on the notification requirements and this will require special preparation to meet those requirements.
Important note: If your data is encrypted you may be exempt from some notification requirements (from Article 32):
The communication of a personal data breach to the data subject shall not be required
if the controller demonstrates to the satisfaction of the supervisory authority that it has implemented appropriate technological protection measures, and that those
measures were applied to the data concerned by the personal data breach. Such
technological protection measures shall render the data unintelligible to any person
who is not authorised to access it.
Who is covered by the regulation?
The GDPR uses the special term “Controller” for an organization that transmits, stores, or processes personal information. You are a Controller of personal information if in any way you transmit, store or process personal information. This applies in equal measure to service organizations that receive personal information in a secondary capacity.
The GDPR also uses the special term “Processor”. You are a Processor if personal information flows through a system that you control. This applies to information you provide to other organizations and to third party computing service providers such as cloud service providers (CSPs).
Are non-EU organizations covered by the EU GDPR?
Yes, if you are located outside of the EU but are doing business in the EU or operating in the EU (you are a controller or processor of personal information of EU citizens), you fall under the requirements of the EU GDPR. This will surprise many organizations who do not have offices or employees located in the EU zone.
Are there any special categories for protection?
The EU General Data Protection Regulation establishes some special categories of individuals and information that come in for additional controls. Information about children and the information of medical patients require special attention on the part of organizations who process this type of information.
What are the penalties for non-compliance with data protection requirements?
While there is some flexibility in how fines are levied for unintentional non-compliance to the GDPR and depends somewhat on which rules you are out of compliance with, the penalties can be quite severe. The failure to protect sensitive data with encryption with appropriate technical controls is considered a severe violation. No one should ignore the potential impact of these fines. For example, an enterprise that fails to protect data can be subject to fines of up to 1,000,000 EUR (1 Million Euro) or up to 2 percent of annual worldwide revenue. You can see why this new regulation is getting a lot of attention in the European Union!
See Article 79 of the GDPR for more information about fines and penalties:
Is encryption a mandate?
This is from the GDPR recitals:
(23) The principles of protection should apply to any information concerning an identified
or identifiable person. To determine whether a person is identifiable, account should
be taken of all the means likely reasonably to be used either by the controller or by any
other person to identify the individual. The principles of data protection should not
apply to data rendered anonymous in such a way that the data subject is no longer
The most common way of making data anonymous is encryption with good encryption key management.
And you should know this from Article 30 of the GDPR:
1. The controller and the processor shall implement appropriate technical and
organisational measures to ensure a level of security appropriate to the risks
represented by the processing and the nature of the personal data to be protected,
having regard to the state of the art and the costs of their implementation.
2. The controller and the processor shall, following an evaluation of the risks, take the
measures referred to in paragraph 1 to protect personal data against accidental or
unlawful destruction or accidental loss and to prevent any unlawful forms of
processing, in particular any unauthorised disclosure, dissemination or access, or
alteration of personal data.
It is likely that in almost all cases the only appropriate technical measure to ensure anonymization and security appropriate to the risk of loss is encryption with appropriate key management controls. When encryption is not specifically required we sometimes call this a “backdoor” mandate - you are not required to implement encryption, but in the context of a data breach anything else will be deemed inadequate, and subject the organization to fines. You don’t want that to happen to you.
I hope this helps you understand the basic data protection requirements of the new EU General Data Protection Regulation. I know that the regulation is complex and there remain some ambiguities. In future blog posts I will go into more detail on various aspects of the GDPR and how our solutions at Townsend Security are helping EU organizations meet the data protection requirements.
Capturing administrative credentials as a path to stealing sensitive credit card data is becoming a more common method used by cybercriminals. It is not surprising, then, that the PCI Security Standards Council would address this rising threat in the new version of the PCI Data Security Standard (PCI-DSS). For some time now the PCI council has been telling merchants, service providers, and banks that it would more aggressively respond to emerging threats, and version 3.2 of the PCI-DSS standard reflects this.
One of the most effective ways of countering this threat is to implement two factor authentication (2FA or TFA). This is also sometimes call multi-factor authentication (MFA), and the two terms are used interchangeably. If you use Google, Facebook, Yahoo, or any number of other Internet services you are probably already aware of two factor authentication as a security mechanism. With two factor authentication you no longer just provide just a password to login as an administrator of an account, or to make administrative changes to your systems. You must supply a 5 or 6-digit PIN code to complete the login sequence. The PIN code is generated separately from your signon prompt and thus is harder for cybercriminals to capture.
A password is something you know, so the second factor for authentication must be something you have such as a cell phone or token, or something you are such as a fingerprint or iris image. Secret questions don’t qualify as as second factor as they are also something you know, like the password. A general description of two factor authentication can be found here.
Prior to version 3.2 of the PCI Data Security Standard, remote users were required to use two factor authentication for access to all systems processing, transmitting, or storing credit card data. With version 3.2 this is now extended to include ALL local users performing administrative functions in the cardholder data environment (CDE). This makes sense as user PCs can be infected with malware that leads to the compromise of administrative credentials. It hardly matters anymore if the user is local or remote.
Why is this a big deal?
First, many companies processing credit card data do not have remote workers, and 2FA will be new technology. Even if you have remote administrators, they are probably authenticating with 2FA via a VPN session which will not work with internal administrators. This means evaluating new 2FA solutions, deploying them in all of your CDE environments, training employees on how to use the technology, and implementing new HR procedures to manage employees and access to 2FA.
Second, many 2FA solutions require deployment on hardware servers that must be deployed and maintained. There may be impacts on the company network and firewalls, and it means a new technology ramp-up. This includes addressing hybrid environments that may encompass traditional IT data centers, virtualized environments, and cloud applications. If the 2FA solution is based on hardware tokens that employees have to carry, you will have to manage the distribution, revocation, and replacement of tokens.
Third, many merchants have complex cardholder data environments and a 2FA project can be daunting. Think about a large box store retailer. Besides the normal check-out Point-of-Sale systems, they might have pharmacy, optical, automotive, and many other departments under the same roof. The CDE might be complex and extensive and the 2FA effort may be large depending on how much administrative work is performed locally.
Last, it is not enough to deploy a 2FA solution. It must be properly monitored in real time. An attacker may attempt to guess or brute-force attack the PIN code. A good 2FA solution will log both successful and unsuccessful PIN validation requests. The logged failures should be monitored by a SIEM solution so that the security team can react to the threat quickly.
Here at Townsend Security we provide a solution to IBM i (AS/400, iSeries) customers that is based on mobile, voice, and optional email delivery of PIN codes. Alliance Two Factor Authentication integrates directly with the global Telesign network to deliver PIN codes. A customer who needs to deploy two factor authentication can install, configure and verify a 2FA PIN code sequence in less than 30 minutes. There is no hardware to install or maintain, and there are no individual tokens to distribute and manage. We think that this solution will help many IBM i customers quickly achieve compliance with version 3.2 of PCI-DSS and PA-DSS. More information here:
In future blogs I will talk more specifically about our solution.
Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."
Encryption and key management should move from an IT project to an integrated and seamless part of the IT infrastructure. Organizations need to be able to deploy encryption with ready-to-use infrastructure so that encryption ceases to be a barrier. In order to accomplish this encryption and key management solutions must be embedded in the IT infrastructure and enabled by policy. Key management solutions must implement the automation infrastructure that enables this type of deployment. All aspects of the provisioning of an encryption key server from network configuration, system logging, user administration, generation and distribution of credentials, key mirroring, backup and restore, and encryption key management must become API driven through standard web services.
Unfortunately, standards bodies and vendors have been slow to address this critical aspect of key management. While there is some movement to de ne some aspects of encryption key management through web services or add-on solutions like Chef, the net- work and services aspects of key managers have not been adequately addressed. This will continue to make it difficult to move key management into the realm of seamless and invisible critical infrastructure.
- Ask your key management vendor how they implement APIs for server configuration, deployment and management.
- Understand the key management vendor’s road- map and plans for key management automation.
- Ask the key management vendor for examples of customers using their Web services features.
- Understand any vendor licensing restrictions for installing management utilities.
There is No Single Source for Best of Breed Security
Understandably, customers long for a single vendor who can solve all of their security needs. Currently the process of deploying best of breed security involves working with multiple vendors whose products do not interoperate. It means spending a lot of IT resources managing a large variety of vendor products and services. While there are a handful of larger vendors attempting to provide a complete set of products, their marketing language does not match reality and there is no indication that it will for some time to come.
Looking ahead, organizations should expect to work with a number of security vendors in order to deploy best of breed security for their sensitive data. It is unlikely that this will change in the near future. Smart organizations will identify best of breed applications that are easy to use, and make the resource investments needed to acquire and manage these solutions.
- Always try to deploy the best of breed security solutions and understand that this means dealing with multiple vendors.
- Prioritize your security needs according to risk, and tackle the highest priority items first.
- Understand and empower your IT organizations to acquire and deploy the best solutions. It is always more cost effective to prevent a problem than remediate it after the fact.
CISOs often can have an arduous time getting budget. To top it off, they are tirelessly thinking about how to improve security programs, justify what they are currently doing, and getting the budget they need for next year. When it comes to improving budget, CISOs need to trade their technology hat with a colleague in the sales or marketing department.
When it boils down to it, a CISO is not technology provider, but rather business solution provider. This can sometimes be a hard realization to make. Especially after spending the first part of your career immersed deep in the technology weeds. For the new CISO, and even seasoned veterans, it can be a challenge to learn to sell and market your ideas (and get funding from) the various stakeholders within the company. It is imperative for the CISO to market and sell the security side of the house to the business at large to get what they need.
Speak Their Language
Not too long ago, the CISOs job was to walk to the C-suite and say, for example, “Hey, we need encryption and key management. Give me the budget and I will go make that happen.” Back in the day, they would usually get the money. Now it is more about building relationships and having a business problem to solve.
With times changing, now it is important to better understand what technologies the stakeholders are hearing about and how you can leverage their knowledge of current security events to bolster your security program. Many of the stories that in the past would have been exclusive to publications like CSO Online and Krebs on Security are now showing up in places like Forbes, Businessweek, and the Wall Street Journal – places where your stakeholders go to get information.
When we look at what is being covered by the mainstream media, it is stuff that security professionals have had to deal with for years, but was relatively unknown to the upper echelons of the company. When security admins talk about data breaches, they talk about SQL injections or the best practice for data protection and how to manage a database – IT vernacular.
It is important to remember that the executive team doesn’t speak your language. When they talk about someone impersonating the CEO via email and exposing W2 information, they don’t know that this is called a “phishing attack.” Security professionals know this, but that isn’t what they call it in USA Today. You have to understand how to make those connections and draw those lines for people.
Sell and Market Your Program
You will have an opportunity from time to time to engage stakeholders for 30-seconds to 2 minutes. When you have those chances for an interaction, you need to sell your program. You need to practice it and have it come across very natural and as you would normally talk. Some suggestions:
- Talk about the great things that you are doing and that you want to do more of it
- Make sure that they understand your successes
- Don’t talk about stuff that doesn’t matter – that is not how you get a budget
It is also important to have various elevator pitches, depending on who you are going to be talking with. For example, if you have 30 seconds with a CIO or director, the pitch is going to be different for each one, because they care about different things. Remember, when you talk with them, it has to be about something that they care about. The secret to success is to sell your program and the services of your group. Don’t just talk about building a security kingdom, but rather business solutions.
Often, when you think about selling, you think about selling to the CFO or even the board. You don’t often think about it, but you do in fact have to sell to the SOC (Security Operations Center) manager or other teams or lines of business within the organization. You may not be asking them for funding, but you need to get them on board so that when you do go to whoever you need to make the big pitch to, they will have your back. It is a much easier sell when there is a choir of voices saying, “Yeah, this is what we think that we need. This is the solution that we want. We have already bought into the fact that this is what we need.” If you can get 3 or 4 other directors from different lines of business backing you, you will be much more successful at actually getting funding than if you were to say “This is what I think is needed” and the board replies “What does the SOC manager think?”
If your funders still need more convincing, compliance regulations can often help your cause. Regulations like PCI DSS and HIPAA (as well as others) are constantly evolving, going through review and update, and bringing in stronger language and more stringent security demands. PCI DSS, in particular, carries a big stick. Whether you love it or hate it, it can often get you what you need because your business has to comply if they want to take credit cards.
External audit findings can also help propel your security program forward. When they come back negative, business risk has been identified – and business risk speaks very loudly to the C-suite. It is in their charter to acknowledge business risks and take appropriate actions.
Finally, and unfortunately, there will be times that you are simply told “No, there just isn’t budget for _______.” But what you can do, because you are a smart CISO, is go into your backup pitch. Just because you didn’t hit a “grand slam” doesn’t mean that getting a “single” or a “walk” is out of the question. Your “walk” should be the absolute bare minimum needed to move your cause forward, at least a little. Even the guy that gets walked is going to score from time to time. If you can take a “walk” and deliver something with it, you are going to further gain the trust of your funders and establish a positive track record for delivering on time and on a budget.
Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."
The evolution of computing and delivery platforms continues at a rapid pace and this presents substantial challenges as organizations of all sizes attempt to deploy data protection strategies. Security professionals now know that Data Centric Data Protection, or encryption, is crucial to their security strategy. Deploying encryption means properly protecting encryption keys. This is the biggest challenge organizations will face with their encryption strategy. The large investment required to develop defensible key management implementations, the importance of key management to critical data infrastructure, the rush to cloud and hybrid implementation.
Encryption Finally Takes Off
Encryption of sensitive data, sometimes called Data Centric Data Protection, has not been a high priority in many organizations. Investments in security have focused on deploying endpoint protection such as anti-virus and data leak protection, active monitoring and alerting of system logs, and other security features. While encryption is a core security requirement, it has not had as much attention and many organizations are lagging in this key security control.
The large data breaches over the last two years and the resulting impacts on the executive teams, along with resulting brand damage, has changed all of that. Customers, employees and all other stakeholders expect the highest levels of executive management to be pro-actively involved in the protection of sensitive data. When CEOs lose their jobs over a data breach, the industry is poised for change. Encryption and data protection are now considered cornerstones of a company’s governance, risk management, and compliance regime. Failures in data protection are now perceived as failures at the highest levels of management. Additionally, the State of California’s recent guidance that a minimum reasonable level of security requires the full implementation of the CIS Critical Security Controls, will force organizations to fully adopt encryption protections. This is leading to a rapid re-focus of the security strategy on data protection with strong encryption and key management. This will continue in the months and years ahead.
- Review your defense-in-depth security strategy and move quickly to protect sensitive data with strong encryption and key management.
- Be sure your IT department has a clear inventory of sensitive data across all of you internal systems, cloud solutions, and service providers. Know what is protected and what is at risk.
- Prioritize your encryption projects to address the most sensitive and exposed data.
- Every implementation of encryption needs good encryption key management. Start a remediation plan for any current encryption implementation that fails to properly protect encryption keys.
- Communicate your security strategy to your customers, employees and stakeholders. Let them know that data protection is important.