Based on our conversation, our client requested additional information from the GPMS vendor. This included:

• A “System Security Plan” to provide an overview of the PMS’s information system security requirements and the controls in place or planned to meet those requirements.
• Copies of network and application penetration tests conducted prior to the system being put into operation or prior to major changes.
• Any forms of independent attestation relating to the design and operation of GPMS’s Information Security Management System (e.g., Shared Assessment AUP, SOC 2, ISO 27001).
• Any forms of independent attestation relating to the design and operation of GPMS’s Business Continuity Management System (e.g., BS 25599, ISO 22301).

When the GPMS vendor was not able to provide this information, the client widened his search and is currently evaluating other alternatives – including keeping the PMS in-house.

Image Source: legalproductivity.com

The post Assessing the Security of Legal Practice Management Software in the Cloud appeared first on Pivot Point Security.

That’s a very simple question, but often the answer is a lot more complex. At a minimum, it might take me considerable time to research the issue. I need to check the Microsoft Security Research & Defense blog, I have to check the vendor’s website, I have to see if there’s any notices of vulnerability in CVE or anyplace else, and so on.

Based on that research, I potentially can identify what the risks and issues are, and then communicate those to the customer. But sometimes the answer to the question “Is it secure?” also depends on the organization’s business model and the nature of their infrastructure: a bank has a different security risk profile than a coffee shop.

Photo by GServo

Security is usually complex and involved, and it doesn’t have any value unless it’s applied to something in context. It’s not an off-the-shelf component of your IT environment, and implementation is key. For example, I can install a super-secure firewall for you, but if you set the administrator password to “blank,” somebody else is going to take over that firewall.

So in addition to research, I often spend time contextualizing how a client plans to implement the solution in question. Sometimes this leads to recommendations on how to implement and/or maintain the software. Other times it’s about helping them find an alternative that better fits their risk profile.

For example, one highly secure organization I worked with recently was concerned about Java. Of course, Java is not just an application but a programming and runtime environment, and there’s a whole suite of applications that rely on Java in order to operate. A slew of super-critical vulnerabilities have come out relating to Java over the last year, which could potentially open a company up to risk or liability. This is especially true if you need backward compatibility with older versions of Java because of how some software your business needs has been coded.

The general guidance around Java is: don’t install it on any system that doesn’t require it. If you do need it, keep current with patches. If you can’t patch it, compartmentalize it in a minimal privilege environment where you’ve got audit trails and other compensating controls in place, so if something happens, you can minimize and mitigate the amount of damage done. More drastic controls can include not letting the system go out to the web, not attaching it your network, or even going as far as requiring users to move files on/off it with a USB drive. Each compartmentalization step is going to be more involved and have more of a business impact, but it’s in turn reducing the risk profile.

Once you’ve compartmentalized a potentially vulnerable system that introduces risk into your environment, you’ve reduced the damage that can be inflicted in the event of a compromise. If you open up a poisoned Microsoft Word document on a standalone system, for instance, the attack is probably going to stall because it relies on some kind of network connectivity to remotely control that box or to exfiltrate data from it. So (relatively) no harm done… as long as you can tell when you’ve been attacked. For this reason, even standalone systems often should have antivirus and endpoint protection on them.

Fortunately, most businesses don’t need an expert to go through and look at every single application in their environment. There’s a certain level of implicit trust that vendors like Microsoft and others will help keep you secure — provided you can keep the patch regimen up.

So: “Is it secure?” The answer is relative.

The post Hey, Is This Application Secure? appeared first on Pivot Point Security.

• How can we ensure that NJ businesses survive future events like Sandy?
• How can we ensure the resilience of information technologies that support New Jersey businesses?

In this 2-Part Special Report, we will uncover the answers to those questions, and shed light on the things that need to be done today.

Read the article by downloading the PDF from NJTC.

The post Disaster & Recovery appeared first on Pivot Point Security.

The improvement in security posture as a whole is largely attributable to Microsoft getting more serious about security in the middle of the last decade, and moving to a secure-by-default approach.

But, since a majority of information security risk stems from non-optimal vulnerability and configuration management and it’s not an overly challenging practice to get right – why are most organizations still not very good at it?

Here are a few of the reasons, as I see it:

• Organizations are quick to buy tools (e.g., Nessus, NT Objectives) but they are slow to allocate the money to train their personnel on optimal use of the tools on an ongoing basis. This issue is often exacerbated by the fact that they often fail to understand the amount of time it takes to operate, maintain, and react to the data the tool produces.
• “Security owns the tool, Operations owns the problem.” But the real accountability when it comes to vulnerabilities (caused by system patch levels or configuration) and their impact is often debated. So Operations, whose performance reviews are often based on rolling out new features/technology, are naturally going to want to downplay the importance of mitigating non-critical issues. Whereas Security is going to want to ensure that most of these non-critical risks are addressed as they cumulatively put the organization at risk. Too often, the person responsible for deciding if Operations or Security is right does not have the knowledge to break the tie and/or bases the decision on organizational politics.
• Vulnerability and configuration management is important, but rarely critical. As organizations try to do more with less, other projects with far greater visibility get the lion’s share of the attention of the person tasked with VCM. This is exacerbated by the fact that VCM is likely the most boring task on your security engineer’s work list (just below log review).

I think it’s for these reasons that Pivot Point is seeing a real increase in projects where we provide outsourced or co-sourced Vulnerability and Configuration Management Services. I think this makes a lot of sense, as the service solves the key issues outlined above:

• Organizations can buy the tools along with the expertise to make sure that is the tools are optimally configured and operating as intended. If preferable, we can actually run the tool as well. Most of the time we suggest that it be configured to run automatically anyway.
• Having an “independent/objective” third-party in the room during the vulnerability and configuration review process ensures that decisions are being made with all of the information on the table in a non-partisan way. Having someone to act as a liaison to and advocate for management ensures that risks are managed effectively and in accordance with the organization’s acceptable risk criteria.
• Having a third-party to delegate “less desirable” job functions to will make your key security team members happier.

The bottom line: Because you are paying a qualified third-party with a reputation to uphold to dedicate their time and focus to this function, there is an indisputable accountability that ensures that this important function gets the attention it needs – before it results in a security incident.

Photo by Andreas H

The post Why Outsourced or Co-Sourced Vulnerability and Configuration Management is Becoming More Popular appeared first on Pivot Point Security.

You don’t want to find out the hard way about security vulnerabilities in your web applications — and you don’t have to. Finding and fixing holes proactively, ideally before the application reaches production, is the lowest-cost and lowest-risk option by far.

Pivot Point Security regularly performs application vulnerability assessments and application penetration tests. The former relies on automated tools, which report what they find. The latter takes those results and gives them to a skilled human, who manually tests and confirms what the automated tools found, sorting out real threats from “false positives” and assessing specific levels of risk. Taken together, these services support comprehensive testing and well-informed evaluation of the results, so that risk mitigation can proceed in the most efficient and effective manner possible.

Pivot Point is a big believer in leveraging open and trusted standards. For application-level security assessments we prefer The Open Web Application Security Project (OWASP) “Top 10″ security candidates. There’s a new list for 2013, which incorporates a number of changes from the last version, which was released in 2010.

Every web application developer should familiarize themselves with the OWASP website. The OWASP Top 10 tells you everything you need to know about eliminating the most prevalent and dangerous security vulnerabilities from your code. It not only enumerates the top ten targets, but also explains how to test for them and offers potential solutions to address the problems you find.

Pivot Point tests against it in all our software tools, and it likewise informs any subsequent manual testing as described above. More and more of our clients are aware of it and use it as part of their internal process, even compared to two or three years ago. But there are still a lot of application-level security vulnerabilities out there…

Another great source of information for both developers and security analysts is the Common Weakness Enumeration (CWE) list of software weaknesses. This list incorporates the OWASP guidance along with a comprehensive delineation of additional issues to look for when reviewing application source code.

In a nutshell: OWASP helps you evaluate applications as site visitors would see and potentially exploit them in their browsers. Whereas CWE supports a deeper inspection to uncover “bad coding practices” that (especially in combination) hackers could exploit.

I don’t think I’ve ever found a “perfect” web application that didn’t trigger any red flags in a vulnerability assessment. But upon inspection “risks” are not always worth mitigating when we balance the true danger they represent versus the cost of reprogramming and updating an application.

For example, if an application’s source contains comments that reveal passwords used during development, that’s much worse than comments flagging different page sections. But the assessment tools don’t know the difference; they flag any comment as a potential information disclosure vulnerability. (Removing comments before moving applications into production is nevertheless good practice.)

What’s the worst application vulnerability I’ve seen lately? At one company I was able to exploit an application so that when users logged in they’d go to the legitimate site, but then immediately be re-directed to a third-party web page (controlled by me) that asked them to reset their password. Upon doing so, providing me with both their old and new passwords, their password would actually be changed on the legitimate site, and they would be returned.

Neither the user nor the application would find anything wrong, but I just stole two passwords. If I were a black hat hacker, maybe I’d damage some data within the application, or use the stolen user data to get more data about targeted individuals and eventually commit serious fraud.

Whatever industry you’re in, and whatever web applications you are running, the sooner you test them and identify and mitigate significant vulnerabilities the better. Then make sure your development process includes ongoing security awareness for your developers/testers. Software developers and testers working on pre-production code are the people you want finding application security vulnerabilities — not us hackers, whatever the color of our hats.

The post How OWASP Can Prevent Your Business From Getting Stung By Hackers appeared first on Pivot Point Security.

In the wake of Hurricane Sandy, many NJ businesses faced, and continue to deal with, tough challenges. Besides the ongoing recovery efforts, businesses in the area have to ask the question, “Can it happen again?” – and more importantly, “If it does happen again, will we be prepared?”

In an effort to help businesses in the region, Pivot Point Security has partnered with the New Jersey Technology Council to spread the word about the importance of Disaster Recovery and Business Continuity. “DRBCP is something everyone knows they need, but so many places ‘gamble’ that disaster won’t find them. It’s natural to think that with the time and resources needed to address the issues, we can always ‘put it off’ – until we’re caught unprepared,” says John Verry, Security Sherpa at Pivot Point Security. “At Pivot Point we want to spread the gospel of DRBCP – and convince businesses that no matter their size and the extent of their resources, DRBCP is within reach.”

The Special Report “Disaster Recovery & Business Continuity – Perfect Together”, published in the April edition of Tech News, is an attempt to help business leaders understand and come to terms with DRBCP. In it, Verry explains the difference between Business Continuity and Disaster Recovery. “They’re not the same,” says Verry. “A business continuity programs examines how you operate, identifies the most critical business processes you need to stay in business, and defines how you will keep those processes running if a disaster occurs.” On the other hand Verry says, “A disaster recovery program focuses more precisely on the information technology and communications assets your organization uses, and how to keep them operational following a disruptive incident.”

“Simply put,” Verry says, “BC looks at your business holistically, while DR looks at the technology infrastructure.”

“The good news is that there is a lot of guidance available to businesses of all sizes. Companies don’t need to go it alone. We’re committed to helping businesses be ready,” says Verry. The article contains several helpful tables outlining DRBCP resources, from ISO and FFIEC standards to professional organizations.

This first article focuses on building a Business Continuity Management System (BCMS). “Think of this as the administrative framework that links all the various BC and DR activities together into a cohesive program,” says John Verry. He counsels businesses to focus their initial discovery on the following activities: Business Impact Analysis (BIA), Risk Analysis (RA) and Strategy Definition. “Once you’ve completed these important discovery activities, you’ll be ready to prepare a process-oriented plan to address a disaster situation using the four R’s – Recognize, Respond, Recover and Restore.”

The May issue of TechNews will feature Part 2 of this Special Report. The New Jersey Technology Council hopes that companies will review this information and take advantage of this opportunity to be better prepared. And Pivot Point Security will eb there to help!

The post Disaster Recovery for NJ Sandy Victims and Beyond appeared first on Pivot Point Security.

As I see it, HIPAA liability has come full circle:

• The Health Insurance Portability and Accountability Act of 1996 made Covered Entities (health care providers, insurers, and service providers that handle PHI) responsible for HIPAA compliance and directly liable for HIPAA violations. Business Associates only had contractual obligations under their business associate agreements to maintain the privacy and security of PHI, but were not subject to sanctions under HIPAA rules.
• The HITECH Act of 2009 expanded the obligations of covered entities and business associates to protect the confidentiality and security of PHI. Most notably, HITECH made Business Associates responsible for compliance with breach notification rules, and subjected business associates to civil and criminal penalties for HIPAA violations.
• The OMNIBUS Provisions of 2013 broadens the definition of a “Business Associate” to include organizations that have not explicitly executed a Business Associate agreement with a Covered Entity (CE). It also broadens the breach notification obligations by modifying the definition of “breach” and the risk assessment process for determining whether notification will be required.

Up to this point, the US Department of Health and Human Services (HHS) has focused its enforcement of HIPAA on healthcare providers and related healthcare organizations. The new Omnibus Rule broadens HIPAA enough to allow HHS to hold Business Associates, including law firms, directly liable for compliance with HIPAA rules.

I see two impacts resulting from this for the legal vertical — one obvious and one scary:

The Obvious: Law firms that are explicit (or implicit) Business Associates of other Covered Entities need to comply with the HIPAA Security rules. These include putting forty or so Administrative, Physical, and Technical controls in place to safeguard the confidentiality, integrity, and availability of PHI. The good news is that most law firms have the bulk of these controls accounted for. Unfortunately, the level of documentation and/or the implementation of some (Risk Management, Security Awareness Training) may be insufficient to demonstrate compliance.

The Scary: The “nightmare HIPAA scenario” for a law firm would be a disclosure resulting in “Breach Notification” as the financial and reputational impacts could easily range into the millions. The “scary” part of the Omnibus Rule is that it broadens the definition of a breach to include violations of the “minimum necessary standard.” In order to understand why this is scary we need to take a step back and look at the HIPAA Privacy Rule changes.

The Privacy Rule includes a “minimum necessary” standard, which states that business associates must make reasonable efforts to limit use, disclosure, and requests of PHI to the “minimum necessary” to accomplish an intended purpose. In a law firm, compliance will require information security policies that limit access to documents containing PHI exclusively to those lawyers who need it to carry out work for that particular client.

The Omnibus Rule makes access to PHI in your document management system by anyone other than the lawyer/direct support staff working on the issue a presumed breach. In order for it not to require breach notification you need to demonstrate/document, via a formalized risk assessment, that the probability that the information has been compromised is very low. The risk assessment needs to include: an analysis of the nature/quantity of PHI involved; review/documentation of the unauthorized access; determination of whether the PHI was acquired/viewed/used; and validation that the risk to the PHI has been reduced to an acceptable level.

Where should a law firm begin?

1. Determine whether the nature and extent of your legal contracts with clients and the PHI in your environment subjects you to HIPAA compliance. If you’re lucky enough that there is little/none you can stop reading. If your practices include areas like Medical Malpractice, Workers Compensation, or Product Liability, you probably handle enough PHI to proceed to step 2
2. Determine the nature, extent, and flow of PHI through your environment. Does it transit your email system (and mobile devices)? Are there eDiscovery implications for you or your eDiscovery partners? Is your storage of this data limited to your document management system (or is it on file shares and local hard drives)? Do you apply principles of “minimum required access” to PHI?
3. Determine whether it is practical to limit the scope of your HIPAA compliance requirement. Can you segregate a particular practice to its own document management system (some Pivot Point Security legal clients segregate document management and litigation support systems for this reason) ? Can you prevent PHI from being sent/received via email? Can you prevent/detect PHI from being stored on local hard drives, thumb drives, off-site backups or DVDs? Can you encrypt PHI without impacting operations?
4. Conduct a gap assessment between current practices and those practices required by HIPAA. With the emphasis on “attestable/certified” information security in legal firms (e.g., ISO 27001, SOC 2) I would recommend that rather than restricting the gap assessment to HIPAA, you use ISO 27002 guidance and initially map the output/remediation plan to HIPAA. You will get much greater value at minimum additional cost. A better strategy may be to use the Shared Assessment Agreed Upon Procedures. This will give you a very recognized form of attestation to provide your clients (sort of a mini ISO 27001 certificate).
5. Prioritize your work effort to address those elements that will initially mitigate the greatest amount of risk (e.g., Risk Management for Breach Notification, Security Awareness relating to PHI, access control and user access monitoring to PHI, segregation of PHI to the extent possible, etc.)

HIPAA Omnibus / ISO 27001

In my (humble) opinion, the Omnibus Rule gives law firms another 1.5 Million reasons (maximum penalty for non-compliance) to move towards ISO 27001 certification – a process many were already committed to.

The post Law Firms: New HIPAA Omnibus Rule Will Drive ISO 27001 Adoption appeared first on Pivot Point Security.

In a recent post I blogged about changes now coming into effect, which will greatly increase the number of organizations that are Business Associates (BAs) for HIPAA compliance purposes. This post covers another major change to HIPAA that Covered Entities (CEs) and BAs need to be aware of, that could likely impact your breach notification procedures.

If HIPAA applies to your company, it’s very likely that to comply with the new rules you’ll need to change your process for assessing whether to report a breach. Here are four steps that Pivot Point Security recommends you take to ensure compliance:

Step 1: Understand the new changes.

The HIPAA rules in effect since 2009 incorporate a “harm standard” that organizations applied to assess whether a security incident would need to be reported. The new HIPAA Omnibus Rule replaces this standard with new (and less subjective) guidance.

According to Susan McAndrew, deputy director of the Department of Health and Human Services Office of Civil Rights, which enforces HIPAA, CEs and their BAs need to consider: “Is it likely that the breach will result in the information itself, the data that was lost, being compromised in some way?”

In other words, you should probably report all breach incidents unless the risk of compromise is low.

Step 2: Modify your assessment process accordingly.

The HIPAA Omnibus Rule directs organizations to consider four factors when assessing breach impacts:

1. The unauthorized party who used the protected health information (PHI)
2. The PHI involved, and whether it could lead to individuals being re-identified
3. Whether PHI was actually viewed or acquired
4. How successfully the risk to the PHI has been mitigated

Upon assessing these and any other relevant factors, you must report a breach unless you can safely say that the lost PHI is unlikely to be compromised.

Step 3: Alert employees and BAs of key changes.

The new Omnibus Rules are stricter than the old “harm standard” about whether a breach should be reported. Make sure everyone in your organization who might be involved in breach assessments is aware of the new rules and corresponding new evaluation procedures. Reporting and acting on suspected breaches promptly should be foremost in the minds of staff.

Likewise, it’s important to touch base with BAs and make sure they’re well aware that HIPAA mandates they notify you about all breaches that involve your data. Further, the subcontractors of BAs must notify them, who in turn must notify you.

Step 4: Document any Breach Assessments in the interim.

If your unfortunate enough to incur a breach during the six-month grace period leading up to the compliance deadline in September, you are better off using the new standard for notification – better to be on the safe side.

Critical to breach determination is the risk assessment process wherein you thoroughly document what you considered and determined about each of the aforementioned four factors before deciding whether or not to report a breach. The time lag between the occurrence of the incident and its investigation could be long, and you don’t want any unanswered questions on the table.

HIPAA Omnibus: Where To Turn.

To find out more about today’s HIPAA-related concerns and how Pivot Point Security can help your organization “know you’re secure and prove you’re compliant,” visit our website or call 1-888-748-6876.

The post Omnibus Breach Assessment Rules: 4 Steps To Compliance appeared first on Pivot Point Security.

One of the key changes in the new rule, which will have a broad impact across the healthcare industry and far beyond, is a significantly broader definition of what constitutes a “Business Associate” for compliance purposes. In the past an organization was not a Business Associate (and therefore not required to be HIPAA compliant) unless it signed a Business Associate Agreement. Omnibus makes virtually any entity handling Patient Health Information a Business Associate – even if they have not signed a Business Associate Agreement. Healthcare and health plan providers now have more Business Associates to worry about than previously, and many service providers that weren’t worried about HIPAA, now need to be.

The sweeping intent of these changes is to ensure that HIPAA protections extend “no matter how far ‘down the chain’ the information flows.” They make many more third parties subject to applicable HIPAA rules, notably the HIPAA Security Rule and parts of the Privacy Rule.

To summarize the changes:

* A Business Associate is basically any person/organization that creates, receives, maintains or transmits protected health information (PHI).

* This includes more “obvious” services such as claims processing or administration, data analysis, processing or administration, utilization review, quality assurance, patient safety activities (per 42 CFR 3.20), billing, benefit management, practice management, etc.

* It also includes less “obvious” services such as legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, or financial services.

* Entities providing data transmission services for PHI, and/or require access “on a routine basis” to PHI are implicitly defined as Business Associates – even if they have not signed a Business Associate Agreement.

* A subcontractor that creates, receives, maintains or transmits PHI on behalf of a Business Associate is also defined as a Business Associate — the impact of this change is huge.

* The so-called “conduit exception” is now limited to organizations that only transmit PHI (e.g., an Internet Service Provider). Third parties that “maintain and store” PHI (e.g., a cloud storage provider) are now considered Business Associates.

HHS acknowledges in its commentary on the new rule that small businesses might be onerously burdened with HIPAA compliance as they don’t yet have the “formal administrative safeguards” like a risk management program, written policies, documented compliance, etc. Nevertheless, HSS will enforce HIPAA vigorously; and now, state attorneys general can also enforce HIPAA.

Moreover, the penalties for noncompliance are much higher than previously (the maximum penalty for non-compliance has been increased to $1.5M). Check out the new rules now and make a plan for dealing with them if they apply to you. If you’re unsure how to proceed, turn to Pivot Point, we can talk you through your options.

The post Omnibus: HIPAA Now Applies to Many More Companies — Is Yours One of Them? appeared first on Pivot Point Security.

At a recent conference I was talking with a lawyer whose client’s business had been irreparably harmed by a cloud service provider that lost critical business data. As the lawyer walked me through the situation I recognized each of the challenges:

• Failing to fully understand the risk of being reliant on a single cloud provider
• An over-emphasis on pricing during cloud vendor selection
• Insufficient Vendor Risk Management practices (they trusted – but didn’t verify)
• Incomplete testing of the disaster recovery elements of the solution before pushing it into production
• Failing to update their insurance policies to cover the use of a cloud service provider

After he rattled off the list of issues with a sad smile he said, “Nothing like betting your business on red” – which immediately resonated with me.  Most of us at one point or another have had a chance to play roulette. If you watch a roulette table the money and attention is focused on red, black, and the 36 numbers.

Why? Because we don’t want the zero or zero-zero to come up because they represent the house and usually mean we all lose. Despite the fact that we can place a bet on zero or zero-zero, we rarely do – in part because it implies rooting for a “negative” and unlikely outcome (although it would actually be positive if it hit).

Information Security Risk Management works the same way.  There is an ingrained bias to look at our businesses like we look at the roulette wheel: there are 36 potentially positive outcomes and two negative outcomes (actually one in Europe). So we see the reward and downplay the risk.

Conducting risk assessments, negotiating security provisions into your contracts, reviewing vendors’ third-party testing, conducting disaster recovery tests, and buying cyber liability insurance are all “negative” activities to protect against “unlikely” outcomes. Hence, we often fail to recognize the value of these actions and end up “betting our business on red.”

Several days ago I had lunch with a client and we were talking through a planned data center migration – with notable risks around the fact that many of the core data center team was going to be terminated after the migration. When I noted the risk and proposed some measures to consider to mitigate that risk – he quickly dismissed them. I simply replied “Sure you want to bet the company on red?”

In the end, he chose not to.

The post Information Security Risk Management: Don’t Bet Your Business on “Red” appeared first on Pivot Point Security.