As a security professional, I often receive questions from customers regarding why applications or classes of applications should or should not be used in their enterprises. My response usually identifies a pair of criteria that I believe are critical in choosing enterprise-level solutions:

1. There is truly a need for the application.  There must be an honest business need for the application. If not, organizations should seriously question the decision to use it. This must be carefully considered as every application chosen to support an enterprise-level need increases the overhead of an organization’s IT staff in terms of security and management responsibilities.  Many things are “nice to have,” but, at the end of the day, they simply decrease an organization’s security posture and tax already stressed resources.
    
2. The application can be thoroughly supported by the vendor or with available third-party resources.  Before using an application, the organization should determine how well they can support that application. It’s not wise to tie the success of an enterprise to an application that is overly difficult to manage or maintain. If the application does not have active vulnerability discovery and remediation support, requires management and support overhead that the organization cannot supply, relies on program or system support that negatively impacts the organizations business continuity management program, or contains areas of management and/or security vulnerabilities that cannot be sufficiently addressed using available native or third-party solutions, then the use of the application is likely not a good choice. Too often, we become fascinated with the shiny new car and forget to consider if we have the ability and money required to keep the car running.

Examples of applications that companies should be concerned about include social media and older legacy applications.  These show both ends of the software spectrum – the new and the old.  Both, however, have concerns that must be addressed before they are allowed into the enterprise.

Social media is a rapidly expanding area, and, in many cases, these applications can definitely have legitimate business uses.  However, organizations should consider the dangerous concerns that social networking applications present concerning unauthorized data loss, loss of worker productivity, bandwidth and system resource consumption, and possible infection vectors for compromised code and malware.

Older, well-known applications are often used in favor of newer versions of the same systems.  Companies must consider that the cost savings made in not upgrading to newer versions may be offset by inherent security risks. Widely published and well-known security vulnerabilities contained in these programs can be easily compromised using tools openly proliferated across the Internet.  Also, the software may be at the end of its support lifecycle or tied to older hardware that is no longer easily available for replacement.  Older protocols and operating systems may have a legitimate business use, but, given the wide variety of more secure, supported, and commercially viable options available, the continued use of these products are likely more of a risk than benefit.

What litmus test does your organization use to determine whether or not to deploy a specific application in your environment?

Chris Gray
Senior Risk and Compliance Management Consultant

In February 2009, President Obama signed into law the American Recovery Reinvestment Act (ARRA), an economic stimulus package that included new Health Information Technology for Economic and Clinical Health (HITECH) provisions. These provisions strengthened requirements for protecting patient information, extended the reach of HIPAA requirements to business associates of covered entities, subjecting them to the same civil and criminal penalties, and increased fines for non-compliance and new breach notification protocols. The federal government even earmarked $20 billion in ARRA stimulus funds for healthcare providers and business associates that could demonstrate meaningful use for these incentives.

But, here we are, nearly a year and a half later, and a recent healthcare survey conducted by the Healthcare Information and Management Systems Society (HIMSS) found that many hospitals, behavioral health sciences organizations and doctors offices, and their business associates are still unprepared to meet the new HITECH provisions. Why? Because the impact of HIPAA HITECH is far reaching, and can be overwhelming to businesses that fall within its scope.

Understanding the provisions and implications is the first step in achieving compliance. It is also a necessity if you’re going to build policies and practices that adhere to HIPAA/HITECH, and potentially secure some of those stimulus incentives. Here are what I deem to be some of the most important requirements:

• All of the elements of the HIPAA Security Rule. While the Final Rule has been in place since 2003, many organizations took a “wait and see” approach to fully implementing these standards for protecting electronic protected health information (e-PHI). HITECH should be seen as an opportunity to revisit the overall alignment with HIPAA security and improve current security practices.
• Under HIPAA/HITECH, business associates of covered entities such as health plans and providers are subject to HIPAA privacy and security rules. As a result, those associates are now required to implement appropriate safeguards. In addition, covered entities must now re-evaluate the way they manage contractual relationships with these entities to make sure that all patients are protected.
• The ARRA requires the U.S Department of Health and Human Services (HHS) to audit covered entities and their business associates regarding HIPAA privacy and security compliance, and to formally investigate a covered entity or a business associate upon receipt of a complaint. Under the ARRA, penalties can range, depending on type of violation, from $100 to $50,000 per violation, with a cap of $25,000 to $1.5 million per year for violations of an identical requirement during the same calendar year.
• The HIPAA security standard did not previously include explicit breach notification requirements. Now, individuals affected by a breach of the privacy and security of their e-PHI must be notified within 30 days after HHS issues guidance. Breach notification applies to covered entities, but also extends to their business associates.

The bottom line is that regulation complexity continues to increase, combined with stiffer penalties and disclosure requirements for breaches. It is imperative that healthcare participants understand the implications for their organizations and respond appropriately.

Evan Tegethoff
Solutions Architect – Risk and Compliance Management

GLBA, PCI, HIPAA, SOX … in today’s business world, almost every organization must address multiple types of regulations and standards. In many cases, such compliance is tied to specific dates with immediate fines assessed if the requirements are not met. As a result, so many people, regardless of industry, seem to spend all of their efforts and budgets on compliance.

There’s one major problem with this “throw money at the compliance requirements” approach. It does not necessarily make companies more secure. GLBA, for instance, requires that organizations protect their financial data, but it does not address most forms of privacy-related information or intellectual capital. PCI is driving companies to spend entire annual IT budgets on point solutions to address specific elements of the Data Security Standard. Unfortunately, with all of these requirements and costs, many of the organization’s other security program elements are pushed aside, leaving much of the company’s sensitive data (not related to cardholder information) with a much less secure posture. HIPAA protects medical privacy information around patient care.  It does not, however, require many other important elements of a well functioning security program such as effective vulnerability management and risk-based decision making. Sarbanes-Oxley Section 404 assesses the effectiveness of internal controls around financial information, but beyond this scope, the security environment is largely ignored.

With all of these competing demands, companies are spending incredible amounts of money to achieve compliance, focusing on the checklist of required controls to avoid fines and reputational stigmas. Unfortunately, in addressing the specific goals of a specific regulatory requirement, the organization misses out on implementing a complete and well functioning security program.  Rather than drive security strategy and architecture, compliance should instead be viewed as a result of an overall approach that ensures a proper data lifecycle – proper data classification, proper data collection, protection, storage and disposal. This distinction is critical since, in my experience, companies that do not adopt the viewpoint of proactively addressing proper data lifecycle rather than simply treating specific issues usually end up in a perpetually cycle of reactive fire-fighting.

Here’s a real world example to illustrate my point. One organization, a retail company with thousands of remote store locations, was aggressively addressing PCI requirements and spent a significant amount of money on point solutions to achieve compliance. Late in the effort of checking off all the PCI DSS compliance boxes, the organization, wisely, took a moment to begin an inventory of all valuable data that resided in their systems. One issue that arose was the presence of unencrypted data elements that could, together, be used to establish user identity – a definite risk for privacy violations by most state data protection and breach notification legislations.  This information, however, was not a PCI issue, and it was shelved for remediation at a later date.

Unfortunately, before the changes could be implemented to address the issue, a physical breach occurred and the information was lost.  An immediate assessment took place, involving external expertise to identify legal and regulatory requirements to address breach notification costs, required notification communications, and steps to address customer concerns such as credit reporting agency support to provide ongoing monitoring of credit-related issues to affected customers.  Total cost?  More than a quarter-million dollars to perform extensive privacy reviews, and nearly the same amount in external counsel fees and lost internal manpower hours. PCI fines are sometimes extensive, but agreements can often be reached with the acquiring bank(s).  Shelving that real risk in favor of concentrating on compliance had a much more immediate, and likely expensive, price tag.

So, what is the lesson learned here?  This situation should have been addressed by first pausing a moment to understand the totality of the problems before spending a cent on point-in-time, point-of-presence fixes. The second step should then have been to understand what solutions, from a conceptual point of view, needed to be implemented to mitigate the risks rather than just focusing on a checklist approach.  Then, with risks identified and minimized through data lifecycle management, the scope of “real” work could have been reduced, and technology and process implementation could have been relied upon to truly secure the enterprise.

I guarantee that following a risk-based approach rather than a compliance-focused approach would have resulted in far less expense, greatly reduced the amount of time lost reacting to an emergency situation, delivered effective protection of carefully researched and identified sensitive data, and provided compliance with specific PCI requirements as well as other applicable regulation and standards.

Chris Gray
Senior Risk and Compliance Management Consultant

Wait! Read this blog before you spend any money on security.

Do you really understand the true risk to your sensitive data and critical systems? If not, it’s time for you to do a little soul searching and find the answers to some really important questions, such as “What really matters to my organization from a security perspective?” And, “Where are we failing to secure our critical assets?”  Given the inability of most organizations to apply adequate time and/or budget to simultaneously tackle every potential security issue, you really need to answer these questions so that you can identify and address your truly critical concerns first.  I’ve seen too many organizations run around in circles trying to secure the next items on their radar – an approach that more often than not turns out poorly.

Here’s what I recommend: use risk to determine the priority of your security initiatives. Take a systematic and effective approach to your security program by first understanding the business drivers in each of the business units. Don’t know where to start? Ask yourself, “How does this unit make money?” Although a bit simplistic, this is a great place to start. From here you should be able to identify mission-critical assets – those are the assets required by the critical systems you just identified.

Once you have identified critical systems and assets, you now know what to protect, but from whom? And what? Categorize and determine the capabilities of the most likely threats you have to these critical systems and assets. Then, determine the vulnerabilities you have in your existing security controls and identify the effort required to exploit these vulnerabilities. Then, start tackling the risks that could most significantly impact your enterprise. Sound like a lot? In all truthfulness, a risk-based approach – especially if legal and regulatory requirements are a concern- is the most efficient way to gain accurate visibility into your current state of compliance and identify what steps are required to mitigate gaps. And, if you need help, check out our new Information Security Risk Assessment service.

Once you’re headed down this path, it is natural to wonder if you have too much or too little security and if you’ll know either way. And that’s great – at least you are considering both ends and that means balance. It is important to understand that critical systems and sensitive data are not the only assets of your company – so is money and time. There is such a thing as too much security. The spending of resources on security improvements should be limited by the value their implementation brings to the protection of other assets (capped by asset value).

You should put enough effort into security to reduce the real, validated risk to an acceptable amount. When security efforts are a hindrance to your business processes beyond the value of what is being protected, your company has too much security in place.

I’ve just thrown a lot at you so let me give you a good rule of thumb. When you start worrying more about how much you are spending on security than you are about your assets being compromised, then you are spending too much. If you are still worried about the protection of your assets over security spending, you have put in too little.  Re-evaluate, re-address and re-implement.

Have you been taking the right approach? Can you demonstrate that to management?

Doug Landoll
Practice Director – Risk and Compliance Management

Late last week, I read a SearchSecurity.com blog that quoted Caleb Sima as saying, “…developers shouldn’t learn anything about security. It’s not their job.” I felt compelled to write about the piece, not to support or condemn that statement, but rather to encourage people to think about the bigger picture. 

You see, there are a variety of factors that play into what a security program should contain, and every organization is completely different. Security requirements can be influenced by whether a company is public or private, its vertical markets and even its size, among other things. They can also be impacted by the organization’s level of security awareness.  As a result, some companies may have IT departments that include one security-focused resource; others may have entire departments with multiple resources, while some don’t have any security experts on staff at all. This disparity makes it almost impossible to come up with a one-size-fits-all, cookie cutter approach to information security.

So, rather than focus on the development process, which is clearly just one aspect of security, each company really needs to think about how its overall security program should look when it’s mature. The underlying goal is always to define and develop a program that protects the confidentiality, integrity and availability of information assets. This requires taking the appropriate steps to evaluate the organization’s current risk landscape as well as the risk-reducing potential of available solutions.

Using this risk-based approach, companies will be able to see where they fall short when it comes to compliance, including for regulations and standards such as HIPAA, GLBA, and PCI, and mitigate gaps. Organizations will also be better equipped to address their unique risks with measures that are logical, efficient and cost-effective. Furthermore, companies will be in a position to effectively test the integrity of their existing security program so they can see where their current measures are sufficient and where they are not, and then weigh their priorities based on need.

It is not news to anybody that threats are present in every environment and, regardless of the existence of an information security program, incidents can and do occur. However, organizations that invest time and effort into implementing coherent information security practices reduce both the likelihood (probability) and scope of the episode. This translates into an enormous business impact. Failing to entrust data can be very costly, including the direct expenses associated with detecting, halting and repairing compromised systems, as well as the tangential expenses tied to attempting to restore a ruined reputation. There also are penalties for violating state and federal privacy laws under the principles of unfair or deceptive trade practices, and the inherent loss of productivity, which can result in tens of thousands of dollars a day based on loss of email usage alone. The implications – both financial and operational – skyrocket when malware spreads to other aspects of the computing environment such as servers, workstation operating systems, and file shares.

Think about it. Can your organization really afford to focus only on one piece of the puzzle?

Doug Landoll, CISSP, CISA, MBA
Practice Director – Risk & Compliance Management