This month the Mirai botnet waged the world’s largest DDoS attack in history against Dyn, a major domain-name server. The attack wreaked havoc across the entire internet, taking down major sites, gaming networks and other online services over the course of three massive waves throughout the day before Dyn was finally able to beat the hackers back.

IoT Vulnerabilities Enable Bad Botnets

IoT vulnerabilities are what made the Mirai botnet possible, helping attackers attain great scale across tens of millions of unique IP addresses.

A month before, the same botnettook down the website of independent security journalist Brian Krebs with a similarly massive DDoS attack leveled against Akamai, Krebs’ then hosting provider. The Krebs DDoS attack, well over 620 Gbps in size, was more than twice as large as the next biggest DDoS attack Akamai had ever faced up until then. That same month, separate attacks committed against OVH, an ISP, reached 1.1 Tbps; the botnet responsible reportedly used more than 145,000 smart cameras.

These aren’t the first instances of malevolent IoT hacks hitting the headlines. Hackers perpetrated the great Target attack of 2013 by compromising Target’s vendor-managed smart-HVAC system. Meanwhile, hacks have occurred in consumer IoT devices ranging from “smart” televisions to “smart” baby monitors.

White-hat researchers have also pointed out that connected cars are rife with frightening vulnerabilities. And on the enterprise side, even industrial SCADA systems managing critical infrastructure have been breached.

IoT devices have long been notoriously insecure, and it is only recently that the doom some pundits have been predicting for years has caught the attention of the hoi polloi. Accordingly, below are four tips from Internet of Things security experts on best practices for foiling would-be IoT hackers, gleaned from a recent IoT Security Summit in Boston.

Let’s hope that people listen this time.

Test and Verify Your IoT Code Extensively

When it comes to DevOps and IoT, “the most common [source-code vulnerabilities] are buffer overflows [and] memory leaks,” related Callie Frisch in an interview on the exhibition floor at this month’s IoT Security Summit. Frisch would know; she is communications manager of TrustInSoft, a Paris-based company that specializes in analyzing source code for developers and auditing safety- and security-critical software.

Because of the small size of most IoT devices, a lot of IoT source code tends to be written in C or C-related languages (such as C++ and C#); these languages are particularly prone to buffer overflow vulnerabilities and memory leaks.

The libsecurity-c project for IoT devices, for instance, employs an “extensive testing effort[,] using tools such as Valgrind, GCC and CLANG compilers, and IBM ExpliSAT for formal verification,” along with additional layers for further testing and verification.

Additional verification and protection methods to prevent buffer overflows can be deployed, including stack cookies. A stack cookie is a randomized data string that applications are coded to write into the stack just before the Instruction Pointer Register, to which data overflows if a buffer overflow occurs. If a buffer overflow occurs, the stack cookie will be overwritten as well. The application is thereby further coded to verify that the stack cookie string continues to match how it was initially written; if the stack cookie doesn’t match, the application is coded to terminate.

Secure Against IoT Device Identity Spoofing

It is important to secure against IoT device identity spoofing, said experts at the summit.

“You need to know what device you’re talking to, and [if it is] a legitimate device,” said Petr Peterka, CTO of Verimatrix, in a presentation on developer perspectives at the event, “[because] the ability to download critical software updates over the air is critical to security.”

“You want to have a unique identity for [an IoT] device,” Julia Cline, director of Product Management for Rubicon Labs, told eSecurity Planet in an interview at the summit, “because if you don’t, some other device can get on [the network] and say, ‘Hey, I’m that device!'”

Traditionally (to the extent anything can be traditional in the IoT realm), setting and managing unique identities has been difficult for IoT devices due to their small and low-end their chipsets. Rubicon specializes in providing these unique identities for IoT devices of all sizes; so there is, it would seem, no longer any excuse to not do so.

“We provide secure identification down to the lowest-end microcontrollers…that don’t at this point have any identity behind them,” said Cline. While standard device identity measures only go so far, she said, “we use symmetric cryptography to go below that.”

Pay Attention to Network Approvals Beyond Encryption

Still, certificate matching has its technological limits for IoT devices.

“A lot of IoT devices are tiny; they don’t have the space” for certificate matching, said Mike Mackey, CTO and vice president of Engineering of CENTRI, in another on-site interview at the IoT Security Summit.

So too with solutions like Rubicon’s encryption-based identity matching.

“Encryption is blindly trusted; you don’t sandbox encryption,” pointed out Scott Rice, senior manager of Strategic Initiatives for Venafi, in an interview at the summit. “The bad guys are getting into systems with encryption.”

“NIST this past August released a draft for … lightweight cryptography for IoT,” Mackey added. “They suggest [typical enterprise encryption] probably isn’t going to suffice for IoT.”

Accordingly, the network as a whole needs to be secure in order to keep IoT devices secure.

“If you can crack a device that has some kind of trust with an enterprise, that’s another attack surface,” said Rice.”[So] if there is stuff on the network that is bad, you [need to be] getting rid of it immediately.”

Carefully Vet — and Do Not Blindly Trust — IoT Vendors

To this end, Rice pointed to the recent controversy surrounding Aruba when the company was discovered to have sold IoT devices with factory-installed key and certificate patterns that were known to be compromised. Not only that, but Aruba reportedly was aware of this flaw for years. Accordingly, Rice advises deploying solutions (like Venafi’s) to discover all of the keys and certificates on your network — and, if you didn’t know you had them and they are compromised or otherwise unapproved, revoke them.

“This is one of those things where customers should know better,” lamented Rice, “but they’re not doing anything about it.”

Peterka, for his part, advises going even deeper — down to the OEM hardware level.

“We work with chip vendors,” said Peterka. “You need to start from the bottom [because] chip vendors … can put secrets in any device.”

Read More: Top IoT Security Solutions

Change Default Security Settings on Networking Gear

This would seem to be a no-brainer for network security in general, but many people — individuals and enterprise IT workers alike — leave the logins and passwords on their routers and other networking equipment set to their factory defaults.

“Change the default setting on [your] router,” network security writer Steve Zurier advised his readership three days after the Dyn attack. “Strong passwords on … routers can prevent the type of DDoS that happened last Friday to Dyn.” Additionally, implementing a mobile device management platform within your organization can help businesses manage all of the risks of IoT devices.

Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate communications and data privacy consultant, writer, speaker and bridge player. Follow him on Twitter at @JoeStanganelli.

The post 5 Essential IoT Security Best Practices appeared first on eSecurity Planet.

No threat risk model (an assessment of software, network or other risks and threats) is complete without a methodology for rating threats. In an earlier article we addressed two common and simple threat risk models, both developed by Microsoft — STRIDE and DREAD — along with the more complex CVSS (Common Vulnerability Scoring System). Here we look at how three others rate threats: Trike, MIL-STD-882E and OCTAVE.

Trike

Trike is an open source threat modeling methodology with a distinct threat rating component. It delves beyond threat modeling and into “attack graph[ing],” requiring extensive parsing and detail.

For threat rating purposes, however, it is much simpler. In the world of Trike, every attack falls into one of two attack types: elevations of privilege or denials of service. (This solves the cross-correlation problems presented by the more simplistic — and more redundant — STRIDE, as discussed in the earlier article.)

With this in mind, Trike assesses the risks of these attacks impacting assets presented by four specific actions, comprising the acronym CRUD:

• Creating
• Reading
• Updating
• Deleting

(The creators of Trike acknowledge that a fifth and “exotic” action, “invoking,” is possible — and thereby assessable — in an environment that “is specifically intended to move around code and execute that same code as part of the core function of the system.” But they spend no more than a paragraph discussing and quickly dismissing it because of the rarity of the situation.)

A threat rating chart using Trike will list all possible assets connected with the system being assessed; external assets are included as well. For each asset, the risk of either attack type is assessed on a five-point scale for each CRUD action.

Trike also takes human actors into account — such as an administrator, an account holder or an anonymous user or reader. Separately, actors are rated on a five-point scale for the risk they are assumed to present to a system based on trust. A trusted administrator with full privileges, for example, would get a rating of one, whereas an anonymous user with the most limited access would get a high rating. They are also rated on a three-point scale – always, sometimes, never – for each of the CRUD actions they have access to perform upon each asset.

Five-point scales are used throughout the threat modeling aspects of Trike, as well (for instance, for assessing weaknesses). For those used to modern, three-point DREAD methodology, even a five-point rating system for risk — which Trike’s creators indicate is based on probability — can seem too vague.

Unfortunately, this is not the only aspect in which Trike lacks directness and specificity. As with many open-source tools/methodologies and their websites, both Trike and its site could use a lot of work. The website has not been updated in years. Trike version 2.0 — Trike’s “current” version — has not been documented; version 1.5 was never fully documented either.

The Trike paper and corresponding documentation present interesting ways of thinking about fully assessing threats, and the website and paper themselves plainly disclaim that what it describes needs more rigorous testing and may not work perfectly, but the complexity of Trike potentially limits its usefulness for the neophyte. In the end, Trike’s best use for the time being may be as an academic thought experiment — providing theory to underpin the practical workings of a more straightforward threat assessment system.

MIL-STD-882E

MIL-STD-882E, a Department of Defense methodology, uses two scales for rating risks: a four-point severity rating scale and a six-point likelihood scale. Unlike with other threat models, MIL-STD-882E goes ahead and specifically defines what each point on the scale means, as shown in these images from a DoD report below:

The two scales combine to form a simple yet detailed risk assessment matrix, as shown here:

“The DoD’s system tends to result in a higher ranking, which equates to a higher value for the cost of a life,” writes security researcher Craig Smith in his new book, The Car Hacker’s Handbook. “Also, MIL-STD-882E is designed to be applied throughout the life cycle of a system, including disposal, which is a nice fit with a secure development life cycle.”

Nonetheless, Smith finds MIL-STD-882E too simplistic a methodology for assessing malicious threats. “When rating threats, we want more detail than just Risk = Probability x Severity,” pens Smith.

Still, MIL-STD-882E does have some depth. Similar to how Trike assesses the risk of human actors, MIL-STD-882E assesses the “software safety criticality” of software systems based on their level of autonomy or automation – potentially making it especially useful for virtualized environments and systems where any form of machine learning or rudimentary AI is employed.

Additionally, MIL-STD-882E offers the benefits of being straightforward and well defined, helping to make up for what it lacks in depth. Thus MIL-STD-882E is a great “starter” methodology for those less experienced with threat-rating theory,  while remaining useful for more experienced security analysts as well.

OCTAVE

OCTAVE (aka the Operationally Critical Threat, Asset and Vulnerability Evaluation), although jointly developed by the U.S Computer Emergency Readiness Team (US-CERT) and Carnegie Mellon’s Software Engineering Institute, is less of a methodology for assessing technological risk and more of a methodology for assessing organizational risk. Indeed, the voluminous reports that describe OCTAVE criteria read like business-school manuals.

The upside of OCTAVE is that it is at once in-depth and flexible. The downside of OCTAVE is that it is at once in-depth and flexible.

OCTAVE rates risks, likelihoods and impacts on a three-point scale. Additionally, OCTAVE implementation requires teams to specifically define for themselves what each of the three points on each respective scale actually mean.

While ideally anyone using a different threat-rating methodology would determine specific definitions for their ratings anyway, OCTAVE is unique here for getting people to think more carefully about how they choose to rate threats. On the other hand, this still — potentially — represents a weakness when compared to MIL-STD-882E, which flat-out tells those who use it what each rating means.

OCTAVE is more flexible. Probability analyses are “optional,” the only requirement being thoroughness; analysis teams are directed to consider a variety of factors that can influence probability, as well as to explicitly determine the exact numerical thresholds for “high,” “medium” and “low” probabilities.

OCTAVE is far from perfect; its documentation, while detailed, is at times tediously dense and vague. Some engineers and programmers may not like OCTAVE because, being geared more toward organizational risk, it uses “fluffier” business language to describe risk.

On the other hand, by presenting so many questions for analysis teams to consider, OCTAVE — like Trike (debatably) and unlike MIL-STD-882E (debatably) — forces them to think deeply about the methodology behind the threat-rating methodology.

As such, OCTAVE — whether or not it is right for any particular project or organization — presents an ideal to strive for: adaptability. OCTAVE, in its present incarnation, can be easily combined with other threat-rating methodologies — and, as such, allows the threat analyst to imagine how any combination of threat-rating methodologies (whether OCTAVE-inclusive or not) could be picked and chosen from a la carte for one’s particular purpose.

This approach is no stranger to security professionals and has even been explicitly advised; ultimately, you have to choose what works best for you and your goals.

“Expand, bend, or throw out [threat-rating methodology] ideas … as necessary,” Tom Olzak, CEO of Erudio Security, urged readers in his March 2006 paper on STRIDE and DREAD, A Practical Approach to Threat Modeling. “The objective isn’t adherence to some process articulated one Saturday afternoon by [an] IT professional. Instead, it’s the secure operation of your network.”

 Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate-communications and data-privacy consultant, writer, speaker and bridge player. Follow him on Twitter at @JoeStanganelli.

The post Selecting a Threat Risk Model for Your Organization, Part Two appeared first on eSecurity Planet.

Threat risk modeling, which involves identifying, quantifying and addressing security risks associated with IT systems, is a big part of the job for security professionals.

Fortunately, numerous threat risk models have been developed. Some are geared toward specific purposes (such as web application development), but can be adapted in other ways and for other uses. Some are simple and can be applied immediately by a neophyte. Others are in-depth and complex, requiring dozens of pages of dense reading to even begin to understand how to apply them. Many, of course, fall somewhere in between.

In this, the first of a two-part series, we will cover three popular methodologies for threat modeling — STRIDE, DREAD and CVSS — addressing the individual quirks of each one. (And if you can also read part two on selecting a threat risk model, which looks at Trike, OCTAVE and MIL-STD-882E.)

The aim of this series is to highlight the important points of each, enabling you to decide which method or methods are right for you and to get started in assessing risk using your method(s) of choice.

STRIDE

Straightforward and brutally to the point, STRIDE was developed by Microsoft several years ago. It is discussed at length in what is perhaps the seminal work on STRIDE, a November 2006 MSDN Magazine article, “Uncover Security Design Flaws Using the STRIDE Approach.”

STRIDE mnemonically identifies six risk categories for assessed threats:

• Spoofing [identity] — identifying authentication threats
• Tampering [with data] — identifying threats to data integrity
• Repudiation
• Information disclosure — identifying data stewardship threats and data leaks
• Denial of service — identifying threats to availability
• Elevation of privilege — identifying authorization vulnerabilities

While allowing for easy compilation of categorized threat lists, there is not much more to STRIDE than that; even Microsoft employees have acknowledged its weaknesses.

“STRIDE has a number of cross-correlations — for example, escalation of privilege (E) tends to imply spoofing and loss of non-repudiation, and could imply tampering, information disclosure, and denial of service,” observed Microsoft marketer David LeBlanc in a 2007 blog. “Ouch — every vulnerability category we had, all in one bundle.”

Redundancy and lack of rigor notwithstanding, LeBlanc went on to defend STRIDE as but one useful tool in the security researcher’s toolbox.

“The fact that it isn’t a rigorous classification doesn’t mean that it isn’t useful,” wrote LeBlanc. “It is useful in helping people focus the debate about what to do about some specific problem.”

STRIDE is one of two techniques that LeBlanc and colleague Michael Howard documented in their book, Writing Secure Code. The other — particularly common in web testing — is DREAD.

DREAD

DREAD (an apt name indeed for a threat rating system) mnemonically outlines the five categories of risk that it measures:

• Damage [potential]
• Reproducibility
• Exploitability
• Affected users
• Discoverability

“If we look at the five components, we see that none of these are highly correlated — one of them does not imply the other,” blogged LeBlanc in defending the model. “This means we have independent factors, which is one of the strongest criteria for a solid model.”

In modern DREAD methodology, for each threat identified from a threat model, each category is assigned a score of one, two or three; the higher the number, the higher the risk. (Some threat assessors give Discoverability the highest score for existing applications as a matter of convention — assuming that a threat will be discovered.)

The five numbers are then added up, giving you a total score. A risk score in the five to seven range is considered low, while a risk score in the 12 to 15 range is considered high.

Writing about DREAD and other threat-model considerations in his new book, The Car Hacker’s Handbook, security researcher Craig Smith recommends leaving the entire scoring results visible in your risk report “so that the person reading the results can better understand the risks.” This allows security teams assigned to address those risks to more quickly narrow their focus to reduce risk to an acceptable level.

“I feel [DREAD] applies a bit better to physical threat modeling than STRIDE, yet has the same simple design,” said Smith in an email interview. “Once a company has a system like DREAD under their belt, they could easily upgrade their process to a more advanced scoring system if needed.”

To be certain, the greatest benefit of DREAD is that it is simple and straightforward in both application and interpretation, while highlighting priority areas. It also offers flexibility; it can be readily applied and adapted to almost any situation — even one not specific to programming, networks or IT in general. Smith acknowledges, however, that DREAD may not be a detailed enough risk methodology for some security professionals. For them, Smith specifically recommends CVSS.

CVSS

CVSS — or Common Vulnerability Scoring System — might be seen as the antithesis to DREAD and STRIDE in terms of simplicity.

It uses 14 metric groups: six “base” groups, three “temporal” groups and five “environmental” groups:

• Environmental factors take into account organizational priorities. For example, if availability is more important than confidentiality, confidentiality risks will be modified downward and availability risks modified upward.
• Temporal characteristics use complex equations to account for “the characteristics of a vulnerability that change over time.”
• Base metrics are initially weighted on a scale of zero through 10 and then modified based upon the temporal and environmental metrics.?

Unsurprisingly, CVSS can be problematic and unwieldy. The history of DREAD can shed some light here. In its original incarnation, DREAD categories were scored on a scale of zero through 10 — as CVSS is today — but this method fell out of favor for some logical and readily apparent reasons.

“If we apply some obvious tests, we find that a damage of one, and all other factors 10 (a well-known nuisance, e.g., pop-ups) gets weighted the same as a discoverability of one and everything else 10 (hard to sort out, but causes the heat death of the universe). This is an obvious malfunction,” conceded LeBlanc. “Next, what’s the difference between discoverability of six and seven? Who the heck knows? I don’t.”

This led to the simplifying of DREAD to a ternary scale. Meanwhile, dozens of documentation pages are needed to explain how CVSS works. What it offers in detail, CVSS also offers in complexity — which, in turn, adds its own flavor of risk on top of the very risks the security researchers are attempting to assess.

“CVSS is more complex than DREAD or other five-point ranking systems, but you will have a more detailed picture when you [are] done as to the exact nature of the vulnerability and risk,” said Smith.

Nonetheless, Smith emphasized that he “usually recommend[s] DREAD.”

“I would rather see a simple threat model done than a more complex one attempted and never finished,” said Smith. “Getting an organization comfortable and willing to regularly use threat models is more important than having a complex system nobody wants to use.”

Final Point on Threat Risk Models and Preview of Part Two

It is important to remember that there is no “best” threat-rating system. While each methodology has its own strengths and weaknesses, the “best” system for any given project ultimately depends on the particular project — and the particular people — involved.

Next up we will cover Trike, MIL-STD-882E and OCTAVE.

Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate communications and data privacy consultant, writer, speaker ?and bridge player. Follow him on Twitter at @JoeStanganelli.

The post Which Threat Risk Model Is Right for Your Organization? appeared first on eSecurity Planet.

Credit cards are not secure. That has been the case for a long time, and it remains the case today.  It is why point-of-sale malware has been so popular among hackers and their dark Web customers, and it is why major retailers like Target, Home Depot and Michael’s, and other businesses like Anthem and Adobe have suffered so many headline-snagging breaches.

Some blame traditional U.S. credit-card technology, the magnetic “swipe-the-stripe” cards popularized by IBM decades ago. Today, most countries favor EMV (“Europay, Mastercard and Visa”) credit cards that use a computer chip. EMV cards uniquely encrypt transaction data on a per-use basis, arguably making them much more secure.  For these reasons, banks and credit card companies in the U.S. are pushing to make EMV the standard stateside.

Yet EMV cards are full of their own security flaws – including a lack of actual authentication during PIN verification – making them similarly vulnerable to the kind of card skimming hacks to which magnetic stripe cards can fall prey (albeit with different technology). Making matters worse, many EMV card fraud victims have had to deal with a disputatious customer service department refusing to accept that fraud occurred because their records show – erroneously – that the cardholder’s PIN was verified.

Indeed, many of the EMV vulnerabilities are part and parcel of a poor security culture in which banks, credit card companies and retailers assume that EMV is impenetrable. As any information security expert knows, no system is impenetrable.

…except, possibly, a quantum computing system.

Credit Card Encryption You Cannot Crack

New credit card encryption research based upon quantum computing may make all of these problems go away – by making both magnetic stripes and EMV obsolete.  Researchers have proposed a solution for a truly unhackable credit card that utilizes quantum cryptography, which some boast is truly uncrackable.

The proposed security arrangement, dubbed “quantum-secure authentication” (“QSA”), would employ “a strip of nanoparticles” attached to a credit card instead of a magnetic stripe or a traditional embedded computer chip.  The nanoparticles would be zapped with a laser to create an inimitable pattern.

Because the system would use the unique qualities of quantum mechanics by making use of multiple simultaneous states of the qualities of light, the laser-created pattern could never be observed – let alone copied. This, researchers say, creates a huge advantage over traditional credit cards of both the magnetic stripe and EMV variety because the sensitive data stored on the credit card becomes effectively inaccessible to deconstruction – even if the encryption key is known.

The system works upon the principles of what is known as blind quantum computing, which presents exciting opportunities to make information systems more secure because of its reliance upon the quirky, quarky nature of quantum physics.

At the subatomic quantum level, matter can exist in multiple states simultaneously – and, by extension, the presence of light can exist in multiple states simultaneously. This lends itself well to the binary manner in which computing is conducted fundamentally – e.g., “0” versus “1” or “on” versus “off.” Because of the observer effect, the mere fact of somebody actually observing or recording these quantum states will change those quantum states – theoretically making it impossible to compromise quantum computing-based security, and – therefore – QSA-protected credit cards.

High Cost of Credit Card Fraud

The QSA solution, if widely adopted, could have major worldwide economic impact.  There is a great deal of money at stake when it comes to solving the credit card security problem. Credit card fraud costs the world about $14 billion annually, U.S.-based credit card fraud accounting for half of that figure. Target’s 2014 data breach alone, which compromised about 40 million payment cards, carried gross costs in excess of $250 million.

A substantial credit card breach can net a bundle for enterprising hackers.  According to a 2013 Dell SecureWorks report, basic credit card information (including cardholder name, credit card number, expiration date and CVV code) alone is typically worth a dollar or two per card – more in the case of a non-U.S. credit card, and much more (up to 12 percent of the verified available balance, in some cases) in the case of prestige credit cards such as platinum, diamond or black cards. Additional credit card data – including PINs and full Track 2 credentials on magnetic stripe cards – can reportedly yield a premium as well. (Again, this highlights the importance to hackers of POS malware, which can effectively swipe this data en masse.)

In addition to the notion of permanently stemming the tide of credit card fraud, researchers suggest that QSA could also be used to secure other forms of identification, such as passports. For now, however, quantum computing research is still relatively nascent.

Dynamic CVV

In the interim, digital security company Oberthur Technologies has developed a solution called dynamic CVV that is based upon combining a security token with credit cards. Oberthur’s solution – which, admittedly, is 10 to 50 times more expensive than existing credit cards – involves placing in the card a lithium ion battery-powered random number generator in lieu of a permanently printed CVV code. By generating new three-digit values for a CVV code more than once an hour, Oberthur’s dynamic CVV would prevent hackers and criminals from being able to make use of any compromised customer CVV data from a retailer’s systems.

While this will only help to prevent online credit card fraud (there’s not much you can do if a criminal has physical possession of your actual credit card), dynamic CVV – which could enter the market as early as 2017 – presents a good and highly attainable start on the secure credit card of the future. If combined with QSA, a truly unhackable credit card might be a reality within our lifetimes.

Joe Stanganelli is a writer, attorney and communications consultant. He is also principal of Beacon Hill Law in Boston. Follow him on Twitter at @JoeStanganelli.

The post Making Credit Cards Unhackable appeared first on eSecurity Planet.

Insuring against cyber threats is not exactly a new concept, but most companies — two out of every three — don’t have cyber insurance policies. Despite recent headlines about major security breaches, growth in the cyber insurance market may actually be slowing.  According to New York-based brokerage firm Marsh LLC, the number of cyber insurance policies sold in 2012 increased 33 percent compared to 2011 – but grew only 20 percent in 2013.

It’s not difficult to understand why. Because the concept of cyber insurance is relatively new, the market can seem complex and inconsistent. There has been a significant variance among carriers in their understanding of technology and cyber security. Cyber insurance policies can be pricey, too. Some premiums go as high as $35,000 for a $1 million in coverage. Still, the costs of cyber insurance pale in comparison to those of a major breach. According to a study by the Ponemon Institute, the average data breach cost $5.4 million in 2012 — representing an average $188 per compromised customer account.

Therefore, it’s worth it to at least understand what cyber insurance is all about – and to what extent it can benefit your organization. Here are six need-to-know facts about cyber insurance to get you started:

Your Umbrella Policy Is Not Cyber Insurance…

Cyber insurance, being more of a specialty offering, is different from general liability and professional indemnity insurance. General liability policies frequently cover basics like physical damage. If a hack, a virus or even a simple software bug creates a data loss, data breach or server downtime, your general liability policy might not compensate you for your loss and costs. Indeed, many insurers specifically exclude electronic losses from their general policies. Cyber insurance policies, on the other hand, can and frequently do cover these situations.

…but There May Be Some Redundancies

Sometimes, however, there is some overlap. Data losses as a result of physical damage to or theft of devices could be covered by some general policies. Manufacturer warranties also sometimes cover physical damage — even accidents. In limited situations, a data breach or intrusion as a result of negligence may even be covered by certain professional errors and omissions policies. Therefore, it’s best to thoroughly review your existing coverage before going shopping for cyber insurance policies. You can then ask your insurance agent for a less comprehensive policy in exchange for a reduced premium.

Not All Cyber Insurance Policies Are Created Equal

Cyber insurance is still considered to be relatively nascent. Despite being over a decade old, there is not a lot of standardization among cyber insurance policies. Consequently, a standard policy may include undesirable exclusions. It is important to assess your organization’s needs, go over your proposed policy carefully, and negotiate with the carrier over terms that don’t fit your needs. What’s more, don’t hesitate to shop around. According to L. D. Simmons, a partner in multinational law firm McGuireWoods LLP, insurance carriers are still struggling to effectively price the cyber insurance market. Some have a better grasp on cyber security risks and costs than others; consequently, the swing in premiums for identical policies from different carriers can be huge.

Cyber Insurance Can — and Should — Go Beyond Hacking Protection

Some cyber insurance policies may not reimburse for the costs of data loss. Others may reimburse only certain types of costs.

In the wake of a number of high-profile hacks on companies like Target, cyber insurance may be thought of as a measure to take in case of a data breach or data theft. It is just as important — arguably even more so — to be insured against data loss. Just over four years ago, Gartner published a study in which the company found that 94 percent of companies that suffered a major data loss went out of business within two years. Of those companies, more than 45 percent were put out of business “immediately.”

Even a relatively minor data loss can bring huge costs to bear. Massachusetts General Hospital had to pay a $1 million fineto the US Department of Health and Human Services when an employee of Partners HealthCare (the largest healthcare provider in Massachusetts, of which MGH is a founding member) left the records of 192 patients on a train.

Fortunately, Partners HealthCare had a cyber insurance policy in place that covered regulatory costs due to data loss. Consequently, MGH was able to have the fine offset by the policy.

Cyber Insurance Is No Substitute for Good Security…

Just like auto insurance is not a license to drive drunk, cyber insurance is not an excuse to throw caution to the wind when it comes to cyber security. Carriers typically require you to have a certain level of security already in place to qualify for coverage.

In any event, you will be required to provide an assessment of your organization’s current cyber security. The assessment — typically conducted by a third-party (unless your business is small enough) — includes such details as password management, data backup procedures, and security configurations.

…but It Will Probably Improve Your Security

Obviously, the risk assessment of your security practices will impact not only your qualification but also your premiums. In this sense, cyber insurance is inherently likely to improve your cyber security because it forces you to review your practices – and encourages you to make them better.

What’s more, many carriers will proactively help you secure your data in addition to insuring it. To help ensure a costly payout won’t be necessary, a number of insurance companies offer risk management services to help their clientele. These services can include security plan development, data security training to employees, detailed vulnerability assessments and more.

The value of these services is evident not only from a security standpoint but also from a compliance standpoint. “Being able to prove that they weren’t negligent could save organizations millions in the long-run,” explains Jamie Bouloux, a cyber insurance liability executive at AIG. “[I]f something happens when a client loses data, they can tell the regulator that they did everything within reason to try to ensure that there was an environment of security where its employees knew how to handle client information.”

Joe Stanganelli is a writer, attorney, and communications consultant. He is also principal and founding attorney of Beacon Hill Law in Boston. Follow him on Twitter at @JoeStanganelli.

The post Cyber Insurance: 6 Facts You Should Know appeared first on eSecurity Planet.