Townsend Security Data Privacy Blog

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.

Dev
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.

Stage
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.

Master
The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.

Hotfix branches
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:

1. 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;
2. 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.
3. 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

Conclusion
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.

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.

What is “social engineering,” and how do you prevent malicious attacks such as phishing? I’m sure many of you have heard the term before, but you may not quite know what social engineering means. There are many forms of Social Engineering; however, when we talk about baiting, phishing, and tailgating we’re not talking about a fun weekend at the lake.

When it comes to the realm of data security, ‘social engineering’ refers to using social means to gain entry into a system, building, or storage of information.

One example of social engineering you might remember from the movies is the scene in the  film “Hackers,” when the hero gains access to a TV station by tricking a security guard into revealing the phone number of an internal modem, which he then uses to take over the station. According to Kevin Mitnick, a reformed computer criminal turned security consultant, it is much easier to trick someone into giving a password for a system than to spend the effort to crack the system.

In our daily lives social engineering is a bit more subtle, but even more prevalent than what we see in the movies. For example, an attacker may wait outside of a secured door, waiting for an employee to enter, and either claim a lost or forgotten badge, or simply grab the door before it closes and walk in. This is known as ‘Tailgating’, and even though most people know what this is and how to prevent it, it is in our nature to be helpful and that makes us want to help a “New Employee” that looks lost.

Almost everybody has heard about someone receiving a legitimate looking email from a service such as a bank or utility, asking you to verify your information. This technique is called phishing. Most people are savvy enough to recognize this sort of thing (Unless you really do know a Saudi Prince that wants to give you $50,000) and either ignore it or report it to the institution being fraudulently represented. Unfortunately, this type of attack is still effective and many people are tricked into giving away access to their personal information.

Another type of Social Engineering attack is called quid pro quo. This is an attack where a hacker calls random numbers at a company claiming to be from technical support. Once they find a cooperative victim, they instruct them to install malware that then gives the attacker access to the internal network.

Preventing Social Engineering attacks is difficult because prevention relies on individual knowledge of what these attacks look like. What is your company doing to prevent Social Engineering attacks?

Many companies today have policies in place that require account verification before any information is given out. This certainly helps stem the flow of unprotected information, but it is not a foolproof method.

In today’s business environment it is up to companies to properly train their employees in the countermeasures against Social Engineering, and up to the trained individual to remain vigilant in following safe practices and procedures regarding release of information. 

If your company needs to protect sensitive data such as credit card information, health information, or other personally identifiable information (PII), you should also make sure you have the correct network security in place as well as protecting sensitive data at the source using strong encryption and encryption key management.

When it comes to encrypting credit card numbers to meet PCI security regulations and prevent data breaches, point of sale (POS) vendors selling payment application software often implement encryption key management that is cobbled together and doesn’t meet best practices. For POS vendors who supply retail businesses with complete cash register systems, including POS terminals and payment application software, inadequate key management solutions leave retailers vulnerable to data breaches.

Although all POS vendors must certify their payment application software under the PA-DSS standard, many vendors skate by with poor encryption and encryption key management that has been thrown together to meet the bare minimum requirements.

Although their vendors have passed the test, retailers are still experiencing some of the largest data breaches because their POS vendors don’t adequately protect encryption keys or use encryption key management best practices to secure cardholder data.

At the end of the day, individual businesses are responsible for their own data security; however, POS vendors offering payment application software can boost their own security posture and protect their own reputation by offering better encryption key management for credit card numbers to their customers. Database administrators and information security officers in retail companies can ease their fear and anxiety about their POS solutions. They can rest easy if their POS vendor provides a FIPS-certified encryption and key management solution with these three advantages:

1. Encryption Key Management that is Easy to Use - Good encryption key management should be easy to install, configure, evaluate, license, and sell to end users. Townsend Security’s 1U server plugs right into your IT infrastructure and requires no on-site technician to install. Our cross-platform encryption key management HSM integrates seamlessly into Microsoft, IBM i, Linux and other legacy platforms. Our team provides training, OEM integration, NIST and FIPS certifications, marketing materials, and consistent back end support as well as sample code, binary libraries, applications, key retrieval and other tools you and your customers need to implement encryption and key management fast and easily.

2. Encryption Key Management that is Cost Effective - Small and mid-sized retailers are a growing target of hackers due to the fact that these companies tend to have less data security. These companies, however, need to secure their sensitive data and must meet compliance regulations just like larger businesses do. We strongly believe that cost should not be a barrier to any business. Townsend security offers cost-effective licensing and easy deployment for seamless integration in less time and at an affordable price. We also offer OEM and “white label” options to save time and pain around branding. The average data breach costs a company $5.5 million. With better encryption and key management, you can save your customers millions of dollars.

3. Encryption Key Management that Protects Your Company in the Event of a Breach - In today’s technology climate, data breaches are no longer a matter of “if,” but “when.” Even the strongest networks can be hacked. The only way to secure data is to encrypt the data itself, thereby making it unreadable and unusable to unauthorized users. However, the encrypted data is only as safe as the encryption keys! In the retail industry, the responsibility of a data breach will fall on the retail company that experienced the breach, as well as the POS and software vendors. If a breach occurs to one of your customers, encryption key management will protect your customers and protect your own organization as well.

Almost every single POS vendor offers encryption and key management for their payment applications, but not every POS vendor does the job right. In these cases, a retailer may pass a PCI audit but still be vulnerable to a data breach. With a NIST-certified OEM encryption key management solution, a POS vendor can offer retail customers the best data security available and generate new revenue with that offer.

The last thing a POS vendor wants is a data security plan that looks good on paper but doesn’t deliver when the going gets tough. The good news is that the right tools are easily available to companies who want to not only meet, but exceed compliance and prepare for evolving data security standards. “Good security breeds good compliance and not the other way around -- compliance is the low bar,” says Mark Seward, senior director of security and compliance for Splunk. With a Townsend Security partnership, POS vendors can offer their customers industry standard and NIST/FIPS certified solutions by implementing an OEM encryption key manager that is customized for their specific applications.

In 2012, we saw several large data breaches occurring to website-based companies such as LinkedIn, eHarmony, and Last.fm. These breaches exposed millions of passwords and led us to ask the question, are emails and passwords personally identifiable information (PII)? Because people tend to use email addresses and passwords across multiple website accounts that might contain information such as first and last names, physical addresses, and credit card information, we suspect that if email addresses and passwords aren’t considered PII by everyone today, they soon will be.

Last year I wrote a blog article on the states that had passed some sort of data privacy law, and how widely each state’s definition of PII varies:

(Aug. 8th, 2012) “A significant number of states just lifted verbatim what other states had written into law. A rough guess is that about one third of the states had almost identical data privacy laws.

But the remaining two thirds of the regulations varied greatly, even in defining what PII is. It was common to consider the First Name and Last Name in combination with a Social Security number, bank account number, or driver's license number as information that constituted PII that needed to be protected. But after reading and collating all 45 states, I found 41 data items that were considered PII! In addition to the standard data items, I found passport numbers, military IDs, medical numbers, email addresses, and much else. I even found definitions of PII that went something like this: ‘Any information in aggregate that can identify an individual must be protected.’ It was a lot of ground to cover.

So, should you be protecting email addresses? Absolutely!”

This is something I believe not only still holds true, but will become even more important in the future. Using encryption to protect log-in information and passwords is the best way any one company can protect that information. Of course, using good encryption key management is also a critical part of that process. Even if a hacker gets hold of encrypted data, they cannot get access to that data unless they also find the encryption keys.

For more information, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and encryption key management work together to secure your data.

SHA-1 is perhaps the most often encountered hash algorithm in use today. But its use in digital signatures will be restricted by NIST in the near future. NIST has already restricted use of SHA-1 for federal organizations starting back in 2010, but the weaknesses found in the SHA-1 algorithm has prompted NIST to restrict it’s use for all digital signature generation.

Digital signatures have two aspects: signature generation and signature verification. In January 2011 NIST issued Special Publication 800-131A titled "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths." Digital signature generation is addressed in Appendix B.2, Digital Signature Generation Using Asymmetric (Public) Keys and SHA-1. Here NIST states, "Some applications, such as signing a public key certificate, are very high risk and the use of SHA-1 in those applications should be avoided as much as possible. In NIST’s view, after 2013, the risk is unacceptable in all applications, and the use of SHA-1 when generating a digital signature is not allowed after that date."

Signature verification of already calculated hashes will still be allowed in what is termed a "legacy-use" period.

SSL uses X.509 certificates which are frequently seen with the Signature Algorithm attribute sha1WithRSAEncryption. As December 31, 2013 is fast approaching you may want to consider recreating these certificates with one of the newer SHA-2 algorithms such as SHA-256 or SHA-512. For example when creating certificate signing requests with OpenSSL try using "openssl req -new -sha256 etc...".

NIST has good reason to restrict the use of SHA-1 after 2013. Not only have experts found weaknesses in the SHA-1 algorithm through differential attacks, companies using SHA-1, such as LinkedIn, have already fallen prey to hackers. LinkedIn’s data breach this year could have likely been prevented if they had been using stronger hash algorithms with proper salting.

Is your company still using SHA-1 hash algorithms? Learn more about why you should move to SHA-2 or higher  in our podcast, “How LinkedIn Could Have Avoided a Data Breach” featuring security expert, Patrick Townsend.

The National Institute of Standards and Technology (NIST) announced the selection of the new Secure Hash Algorithm SHA-3 this week. The winning algorithm is Keccak submitted by the team of Guido Bertoni, Joan Daemen and Gilles Van Assche, and Michaël Peeters. This culminates five years of work by the NIST team and the work of many Cryptologists and security specialists around the world. We owe a huge debt of gratitude to everyone involved in this project. While we are hardly aware of how much we use and depend on the work produced by this community of academics and professionals, it is hard to overestimate how much each of us benefits from this work.

Do I need to do anything right now?

No. The SHA-2 family of hash algorithms is considered secure and there is no near-term concern about this family of secure hash algorithms. Here at Townsend Security, when we reach for a secure hash algorithm, we use SHA-256 from the SHA-2 family, and it is expected to be secure for many years to come.

HOWEVER, if you are using MD5 or SHA-1, it is time to upgrade to SHA-2 , or SHA-3 if you like.

Will this new algorithm change how we do message authentication?

I don’t think so. There is some new flexibility in respect to the length of the generated hash, but the use of SHA-3 is likely to be very similar to SHA-2. The advantage of SHA-3 is that it is not SHA-2. That is, if SHA-2 is found to be weak in some way, it is not likely that SHA-3 will be weak in the same way. Basically, SHA-3 will be used for the same purposes as SHA-2.

Will I need to use a salt with this hash method?

Yes, you would use a salt value with SHA-3 for the same reasons you would for SHA-2 – to avoid dictionary attacks that are often optimized with rainbow tables. Any time you have a small amount of data to hash (think credit card number, social security number, email address, and so forth), it is a good idea to use a salt value, and to take care to protect the salt from disclosure.

Is there any reason NOT to use SHA-3 now?

As Bruce Schneier points out in his book on “Cryptography Engineering”, there are lots of ways to get security software engineering wrong. I don’t worry about the underlying security proofs of the SHA-3 algorithm, but I do worry about bad security software engineering because I’ve seen so much of it. I am sure that NIST will have a validation program for SHA-3 (maybe it is already in place), and security vendors will bring their work through this process. I think there are good reasons to wait for the technology to mature before jumping into using SHA-3.

Pop quiz:

Does the name Joan Daemen ring a bell?

If you remembered his name from the Advanced Encryption Standard (AES) competition some years ago, kudos to you! Joan Daemen and Vincent Rijmen submitted the work that became this important symmetric encryption standard.

Happy Halloween!

Patrick

I had the pleasure of meeting Alison Burkill at the Help/System user conference recently and spending a few minutes talking with her about Power Systems security. Alison is the IBM Product Manager for software on Power Systems, and delivered a keynote speech at the user conference. The keynote was about all of the great new features of the Power Systems platform and it highlighted the security features that IBM has incorporated into the base Power Systems platform.

In our sit-down in the demo center I asked Alison one of my favorite questions - “What do you think is the biggest security pain point that IBM Power Systems customers face today?”

I was expecting a discussion about the security technologies that often trip up Enterprise customers – encryption, key management, system logging, log monitoring, and nitty-gritty stuff like that.

Nope.

She said that IBM customers are always taken by surprise when they fail a security audit. IBM systems have a reputation for great security and when IBM customers fail a security audit they are dumbfounded that it can happen to them.  Education, she said, might be our biggest need.

I agree. And I think I know why IBM customers are often shocked when they fail an audit:

• IBM Power Systems do have a great reputation for security and that can lead to a false sense of comfort. I can assure you that IBM systems are not immune from security breaches and data theft.

• Compliance regulations are not written on a platform-by-platform basis. There is no carve-out that exempts IBM customers from meeting data security requirements. A compliance auditor expects you to meet the same requirements as every one else on every other platform.

• It is a rare security auditor who has deep experience with the IBM Power Systems platform. They are going to be skeptical of your claims that the IBM platform is more secure than any other.

• IT professionals often do not have a lot of background and training in regulatory compliance. This is a gap in our education, and Alison is right that we are often only vaguely aware of what regulations require.

• Lastly, as technologists we have a tendency to program first and ask questions later. We can make simple mistakes, like storing encryption keys on the same server as protected data and not realize that we’ve violated a core precept of data protection. We might be using the latest and greatest API from IBM, but not be meeting compliance requirements. It happens a lot.

And there you have it, the perfect setup for the compliance audit surprise! In fairness, this doesn’t only happen to IBM customers, we find the same surprises happening to Windows and Linux users. But it seems that IBM customers are always a bit MORE surprised when it happens to THEM!

I think Alison Burkill is right – Education might be our biggest security need in the IBM Power Systems community. Ignorance is not bliss when the compliance auditor comes calling. 

Download our White Paper "PCI Data Security - Meeting the Challenges of PCI DSS" that discusses PCI compliance and answers some of the common questions companies have about PCI adits.

Patrick

We’ve seen some high profile data breaches at colleges and universities lately. People have been asking if there is any reason why these organizations are experiencing a higher level of attack, and why this is happening now. Are they more susceptible in some way?

There is some good evidence that higher education institutions are experiencing data breaches at a higher rate than other organizations.  Just based on the reported number of reported breaches, number of records stolen, and the number of colleges in the general population of targets, you can conclude that they are, in fact, experiencing a higher rate of loss.

Are college students responsible for the higher levels of breaches?

In spite of the fact that college students are far more knowledgeable about technology, and have a high curiosity index, there is no evidence that students are the source of these breaches. If you look at insider threats and include students in this category, the data doesn’t support this idea. And students don’t want to put their academic opportunities on the line over a break-in, they are way too smart to put that much at risk.

So, why are colleges experiencing higher rates of loss?

Asked why he robbed banks, Willie Sutton supposedly said “Because that’s where the money is.”  A typical college runs retail operations through book stores and cafes, collects critical financial information about students and their families, and may operate a student health service. They are complex modern operations with very large amounts of sensitive data that is often retained for many years. I believe that colleges and universities are considered high value targets because they have a lot of valuable information. 

Here are some things that higher education organizations can do right away:

1) Know where your sensitive data lives.

You should have a good inventory of all of the systems that collect and store credit card numbers, social security numbers, financial information, and student patient information. Having a good map of your data assets is crucial to your data protection strategy.

2) Purge the data you no longer need.

We sometimes forget to take out the trash in our IT systems, and that historical data can be the target of a data breach. Now that you know where your data lives, purge the historical data that you don’t need.

3) Prioritize your attack plan.

We all tend to do the easy things first. There is some satisfaction in getting some points on the score board early in the game. Resist this tendency and protect the most valuable assets first.

4) Protect your data with strong encryption and key management.

There is a lingering belief that encryption is difficult and expensive, especially when it comes to encryption key management systems. That is no longer true! Be sure to include encryption and proper key management in your data protection strategy. If front-line defenses fail, and they will, be sure that the data that is stolen is unusable because it is encrypted.

There are reasons for colleges and universities to be optimistic about improving their data protection posture. Security professionals have learned a lot over the last few years, and there is better guidance and best practices on how to tackle this problem. And security vendors now offer more affordable and easier to use encryption and key management solutions. Download our podcast "Higher Education Under Attack - Data Privacy 101" for more information on what universities can do to prevent data breaches and how to easily get started today.

Patrick

In today's interconnected world, your company's reputation can be won or lost on the strength of your data security. Almost every day, you can read news reports about data breaches that expose confidential customer information. Credit card numbers, banking information, even home addresses and telephone numbers have been exposed by unscrupulous hackers and inattentive employees. Social network and online news outlets quickly spread the word of any potential breaches, exposing your company to public scrutiny and ridicule. Data breaches also expose your business to legal liability and sanctions. Once the data is out, there is no putting the cat back into the bag. You will be forced to explain what precautions you've taken, and why they didn't work. If you fail to meet any federal, state, or industry standards for data security, you could find yourself in a very precarious position.

Data breaches come about in a variety of ways. Many highly publicized exposures are the result of direct efforts by hackers. These hackers can have a variety of motivations, from purely financial to personal ideology, but the end result for your company is the same. If they get in, and get useful information, your bottom line and reputation can suffer irreparable harm.

Another infamous, but no less harmful, form of data loss can be caused by employee negligence. Lost laptops, misplaced flash drives, and low-quality passwords can all lead to data loss. A common thief who steals a notebook computer from a car may find himself in possession of your most sensitive data. Even though these exposures can't be directly attributed to any failure on your part, your business will still be responsible for a breach notification.

To adequately protect your data from all conceivable threats, you need to be protecting it with encryption and key management, which goes farther than just access prevention. A dedicated hacker or inattentive employee can circumvent the most secure firewall and bypass the most stringent security protocols. The only way to make sure your data is truly secure is to make sure that, no matter where it's located, it's useless to unauthorized personnel.

It's almost impossible to ensure that your sensitive data remains where you put it. Whether intentional or accidental, there is always the possibility that sensitive data will be removed from your site. The best defense against harmful data breaches is a comprehensive security protocol that utilizes data. When your data is properly encrypted, compliance regulations state that you aren’t responsible for a breach notification – because there is no useable data!

Townsend Security provides NIST-certified AES encryption for all major enterprise platforms and a FIPS 140-2 certified encryption key management hardware security module (HSM) – technology that will help you avoid a breach notification. There is no better way to securely store data and minimize your exposure. 

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.