Skip navigation

Geek Speak

9 Posts authored by: joshberman Employee

As you know, we’re gearing up for THWACKcamp 2017, which promises to be our best yet. If you haven’t registered, you’ll want to get on that PRONTO! In our 100% free, virtual, multi-track IT learning event, thousands of attendees will have the opportunity to hear from industry experts and SolarWinds Head Geeks and technical staff. Registrants also get to interact with each other to discuss topics related to emerging IT challenges, including automation, hybrid IT, DevOps, and more.

 

We are continuing our expanded-session, two-day, two-track format for THWACKcamp 2017. SolarWinds product managers and technical experts will guide attendees through how-to sessions designed to shed light on new challenges, while Head Geeks and IT thought leaders will discuss, debate, and provide context for a range of industry topics. In my “If It’s Not in the Ticket, It Didn’t Happen” session, I'll be joined by SolarWinds Product Managers Kevin Sparenberg and Bryan Zimmerman to discuss best practices for streamlining the help desk request process.

 

Because I haven't worked in a help desk setting, and have likely been thought of as a “problem child” by a help desk or two, I’m sure I’ll appreciate the perspectives Kevin and Bryan will share in this session. I look forward to understanding the similarities and differences involved in supporting internal and external stakeholders, in addition to acting as an MSP in this same capacity. Tapping the wisdom they've accumulated from their individual experiences working on and leading help desk teams, Kevin and Bryan will offer help desk technicians advice on everything from the appropriate levels of information that are needed on the front end of the support process, to which tools can be used throughout the resolution workflow to help accelerate ticket resolution.

 

Check out our promo video and register now for THWACKcamp 2017! And don't forget to catch our session!

Electronic Protected Health Information (ePHI) must flow from its source to many different recipients to efficiently support the mission of providing quality heath care. However, HIPAA’s data privacy and security standards limit the manner in which ePHI can be transmitted. With HIPAA now in full force - having expanded its reach officially to business associates after the Final Omnibus Rule - and Phase 2 audits currently in progress, now is the perfect time to review the controls and policies you have set in place to protect ePHI in transmission.

 

In many cases, transferring ePHI is embedded into the workflow with sender/receiver applications that directly connect via secure API. In this scenario the authorization model is sometimes built into the software, and sometimes manually managed and security and privacy are embedded. But what happens in the situation where ePHI does not have a pre-existing defined secure electronic delivery mechanism?  With some simple controls on the sender and receiver sides, Managed File Transfer (MFT) offers a means to create a flexible, embedded, or adhoc, HIPAA-safe, data transfer mechanism.

 

The benefits of Managed File Transfer for ePHI are many, including:

  1. Hosted or on-premises capabilities
  2. Secure point-to-point transfer between Covered Entities (CEs) and Business Associates (BAs)
  3. Uses standard internet protocols that even small CEs and BAs can support with limited IT staff
  4. On demand, ad hoc, secure data exchange when unexpected data transfer needs arise

 

If you find your organization needs to use MFT for HIPAA, how do you know if the security of the system meets the requirements for transferring ePHI? Unlike the payment card industry, the HIPAA security guidelines are not proscriptive. They are derived from the HIPAA Security Rule, which was promulgated in its final form on March 26, 2013[1]. Fortunately, as the Security Rule has been put into practice, additional clarifications and guidelines have been made available from various sources and Health and Human Services (HHS) shares them via their website.

 

With respect to file transfer in particular, HHS.gov points to guidelines developed by the Federal Trade Commission (FTC) under the FTC’s authority over consumer data privacy. The FTC guidelines for peer-to-peer transfer mechanisms[2], which are adaptable and relevant to managed file transfer of ePHI, include:

 

  1. Restrict the locations to which work files containing sensitive information can be saved or copied. For example, you can create designated, well-defended network servers to house these files, or use a file management program. These kinds of tools and techniques isolate sensitive information and may limit the extent to which peer-to-peer file sharing programs need to be banned.
  2. If possible, use application-level encryption to protect the information in your files. This type of encryption can help protect files that are shared inadvertently on peer-to-peer networks. If you use encryption, keep the passwords and encryption keys safe. Make sure they are not available in drives or folders designated for sharing.
  3. Use file naming conventions that are less likely to disclose the types of information a file contains. For example, it’s easy to spot terms like “ssn,” “tax,” or “medical” within a filename.
  4. Monitor peer-to-peer networks for sensitive information, either directly or by using a 3rd-party service provider. Because search terms can be viewed by others on peer-to-peer networks, be careful about the terms you use. Some search terms (such as those that include “ssn”) may increase the risk to sensitive information, while others (such as company or product names) likely will not.

 

Recall that the HIPAA Security Rule divides safeguards into administrative, physical, and technical controls. Each of the above recommendations should be mapped to the HIPAA safeguards. The following is a recommendation.

 

Administrative: § 164.308(a)(7)(ii)(E) Application Data Criticality Analysis 

Include your MFT process in this part of your administrative controls analysis.

 

Physical: Device and Media Controls § 164.310(d)(1)

As an integral part of your ePHI data transmission process, care should be taken with any media components that may fail or need to be recycled. HIPAA has very strict data destruction guidelines[3] pointing to NIST- SP 800-88[4]. If you are not an expert in data destruction techniques, have your policy point to a certified data destruction provider.

 

Finally, the relevant technical controls are summarized in this table.

 

Control

Technical                                                    

Restrict Locations

Access Control§ 164.312(a)(1)

Servers should be configured according to policy with correct authentication, authorization, and security.

Application

Level Encryption

§Transmission Security 164.312(e)(1)

Encryption & Decryption § 164.312(a)(2)(iv)

 

Implement encryption standards according to your written policy applying a well-vetted standard, consider NIST 800-52 or OWASP guidelines.

File Naming Convention

Integrity Controls§ 164.312(e)(2)(i)

Implement written standards to assure file naming conventions which will assist in meeting integrity controls.

Monitor Peer-to-peer

Audit Controls § 164.312(b)

Implement continuous monitoring to ensure that no unencrypted data is transmitted. Use caution when storing audit log data to avoid accidental disclosure though gathering and transmission of audit logs.

 

If the above seems daunting, consider a packaged Managed File Transfer solution rather than building your own. As a solution, MFT is easily deployable and can meet your HIPAA security and compliance needs by following the above guidelines. A well-designed MFT solution will include built-in capabilities to address the HIPAA security rule, including:

 

  1. Providing a secure, contained environment for ePHI sharing that offers access controls for authentication, authorization, and built-in security of the MFT that meet or exceed HIPAA guidelines.
  2. Built-in certified encryption cipher suites which meet or exceed NIST 800-52 guidelines.
  3. Audit and logging mechanisms that can be used to help ensure proper file naming conventions and confidentiality of the ePHI processed through the MFT.

 

As with any decision involving HIPAA security, choosing an MFT should include input and requirements from your compliance representative, the IT and security administrators, and the business owner.

 


[1] https://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

[2] https://www.ftc.gov/tips-advice/business-center/guidance/peer-peer-file-sharing-guide-business

[3] http://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html

[4] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf

It has been more than 20 years since HIPAA was enacted on August 21, 1996, and in those two decades it has seen quite a bit of change – especially with regards to its impact on IT professionals. First, with the HITECH Act which established the privacy, security, and breach notification rules in 2003, and then the issuance of the Final Omnibus Rule in 2013. Each advancement served to define the responsibilities of IT organizations to protect the confidentiality, integrity, and availability of electronic protected health information (PHI) – one of the central tenants of HIPAA – and stiffen the consequences for noncompliance. But, despite these changes, HIPAA’s enforcement agency (the Office of Civil Rights or OCR) did not begin to issue monetary fines against covered entities until 2011. And only in recent years, with the announcement of the OCR’s Phase 2 HIPAA Audits, did they begin to set their sights on Business Associates (BAs), those 3rd-party providers of services, which, due to their interaction with ePHI, are now legally required to uphold HIPAA.

 

2016, however, has seen increasing monetary fines, including a $5.55 million settlement by Advocate Health Care[1]. In 2013, the Advocate data breach released information about 4 million users. This breach occurred two years prior to the Anthem breach, disclosed in March 2015, which affected up to 80 million users, making it the largest health care data breach up to that point. Given the time it takes OCR to analyze and respond to data breaches, don’t expect to see any Anthem data breach analysis from OCR in 2016.

 

In the meantime, OCR is implementing their Phase 2 audits. This round of audits delves more deeply into organization policies with business associates, and examines some documents from live workflows. Some organizations have already received notification of their Phase 2 audits, which were sent on July 11, 2016. A total of 167 entities were notified of their opportunity to participate in a “desk audit,” which would examine their HIPAA implementation against the new Phase 2 guidelines. This initial audit will cover 200-250 entities, with most of them being completed via the desk audit process. A few entities will be selected for onsite audit[2].

 

What is a Phase 2 Audit?

First, Phase 2 audits cover both Covered Entities (CEs) and Business Associates. (Recall that the Final Omnibus Rule held CEs and BAs joint and severally liable for compliance). In the pilot phase audits, only Covered Entities were examined. Second, in this phase most of the audits will be completed via a “desk audit” procedure.

 

A desk audit is a nonintrusive audit where the CE or BA receives an information request from OCR. The information is then uploaded via a secure portal to a repository. The auditors will work from the repository to generate their findings.

 

Based on the updated Phase 2 audit guidelines, Phase 2 audits will cover the following areas.

 

Privacy Rule Controls

Uses and Disclosures; Authorizations; Verifications

Group Health Plans

Minimum Necessary Standard; Training

Notices; Personnel designations

Right to Access; Complaints

Security Rule Controls

Assigned Responsibility; Workforce Security

Risk Analysis and Risk Management

Incident Response, Business Continuity and Disaster Recovery

Facility and BA controls

Access Control and Workstation Security

Data Breach

Administrative Requirements

Training; Complaints

Sanctions

Breach; Notice

 

What is different from previous audits is the format of the audit (desk audit vs onsite) and the focus on reviewing not just policies, but worked examples of policy and procedure implementation[3] using actual samples of the forms and contents, as well as the outcomes of the requests contained within the forms. The complete list of all the elements of these initial Phase 2 audits is extensive. You can read the complete list on the HHS website.

 

Phase 2 audits require data or evidence of the results of an exercise of some of the HIPAA policies or processes. From an entity perspective that takes the audit to a practical level.

 

Turning specifically to the audit of security controls, most IT and security pros who have been through an IT risk assessment or an ISO audit will be familiar with the HIPAA audit structure. The approach is traditional; comparing policies to evidence the policy has been correctly implemented.

 

If you have not been through an audit before, don’t panic. Here are some basic rules.

 

  1. Be prepared. Review the evidence you will need to provide. Wherever possible, gather that evidence in a separate data room.
  2. Be respectful. Even if this is a desk audit being completed via portal, provide only the evidence asked for, in a legible format, within the time frame requested.
  3. Be honest. If you don’t have the evidence requested, notate that you don’t have it, yet. If you have implemented the control, but just don’t have the evidence, provide documentation of what you have implemented.
  4. Be consistent. To the extent possible, use the same format for providing evidence. If you need to pull logs, put them into a nicely formatted, searchable spreadsheet.
  5. Be structured. Make it easy for the auditor to find and examine your responses. If you need to provide policies, have them neatly formatted in the same font and structure. It’s especially nice if you are an auditor reading lots of documentation to have good section headings and white space between sections. PDF is the most advisable format, but make it searchable for ease of verification.

 

Recall that the purpose of the Security Rule is to ensure two main things:

  1. That ePHI is correct, backed up, and accessible.
  2. That only appropriate, authorized users and processes have access to ePHI.

 

You can expect that you will need to provide evidence, mostly logs, that cover the controls that ensure the purpose of the Security Rule is being met. For example:

  1. Who is the responsible security officer, and what is their job description?
  2. When was your risk assessment completed?
  3. Have you implemented any remediation or compensating controls identified in your risk assessment?
  4. Can you demonstrate evidence that security violations are being identified and remediated? Expect your incident response procedures to be examined.
  5. Can you demonstrate that the workforce is complying with your security policies and procedures, including security training?
  6. Can you demonstrate that those who need access to ePHI can do so, and that when authorization is revoked (due to change of status, termination, etc.), that the electronic access is changed as well?
  7. What evidence can you show of anti-malware compliance?
  8. Are your cryptographic controls in place and up to date?  [Hint: see our blog post on PCI DSS 3.2 updates for information on SSL/TLS]
  9. Are your disaster recovery and business continuity plans actionable and tested? Include facilities access plans, which should address physical unauthorized access attempts.
  10. Have you implemented all of the access controls and policies required to share data with BAs?
  11. Can you demonstrate compliance with de-identification disposal requirements of electronic media upon change or de-activation?
  12. Don’t forget contracts. Even though you may be responsible for mostly technical controls, the Security Rule does have requirements for your contracts with BAs.

 

As with most compliance schemes, a number of the requirements are well understood standard security best practices. As our panel at THWACKcamp [See the Shields Up Panel Recap] agreed, the old adage, “If you are secure you are probably compliant,” applies to HIPAA, too.

Have you had a recent audit experience you’d like to share?  Please comment on this post. We can all learn from each other’s experiences. Happy auditing!

 


[1] http://www.hhs.gov/about/news/2016/08/04/advocate-health-care-settles-potential-hipaa-penalties-555-million.html#

[2] http://www.hhs.gov/sites/default/files/OCRDeskAuditOpeningMeetingWebinar.pdf

[3] http://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/

Compliance, as it applies to IT departments, involves following rules and regulations that are meant to protect sensitive data of all types. It can govern everything from IT decision-making and purchasing, to configurations, and the policies and procedures a company must create and enforce to uphold this important task.

 

Rightfully so, many businesses are taking the obligation of compliance very seriously. After all, there is a lot at stake when fines and penalties can be levied against you (among other legal repercussions) for noncompliance.

 

As an IT pro, it’s important to know you what you’re up against. Answer these questions from our recent Compliance IQ Quiz – or verify your IQ from your earlier exam – to see how your knowledge stacks up when it comes to IT compliance.

 

Despite InfoSec folklore, the actors most often involved in a breach of sensitive information are coming from outside your company. Unfortunately, understanding the source of these threats is only half the battle when it comes to maintaining IT security and compliance.

 

1.) Which of the following three types of cyberattacks can be classified as an external threat?

 

A) Technical attacks

B) Phishing attacks

C) Physical attacks

D) All of the above

 

HINT: Watch our "IT Security Threats and Risk Management” video (15:47 - 34:35). Click here.

 

Answer: D) All of the above

 

It is true that most threats to your data and compliance initiatives come from beyond the four walls of your organization, but that doesn’t mean your fellow employees can't somehow be involved.

 

2.) Which of the following exploits is classified as "a form of social engineering in which a message, typically an email, with a malicious attachment or link is sent to a victim with the intent of tricking the recipient to open an attachment."

 

A) Pre-texting

B) Baiting

C) Phishing

D) Elicitation

 

HINT: Would you know if your network was breached? Read this article on solarwinds.com.

 

Answer: C) Phishing

 

If your business interacts with sensitive data that falls under the protection of HIPAA, PCI, NCUA, SOX, GLBA, or other frameworks, then compliance should be on your radar.

 

3.) Poll: Which of the following industries does your business serve? (Select all that apply)

 

A) Financial services

B) Healthcare

C) Technology

D) Federal

E) Education

F) Other

 

See who participated in the quiz in this chart, below:

solarwinds-compliance-iq-quiz.png

 

No locale, industry, or organization is bulletproof when it comes to the compromise of data, even with a multitude of compliance frameworks governing the methods used to prevent unlawful use or disclosure of sensitive data.

 

4.) In the past year, which industry experienced the highest number of breaches of sensitive information? For reference, we have highlighted the key compliance frameworks that guide these industries.

 

A) Financial services - PCI DSS, NCUA, SOX GLBA, and more

B) Healthcare - HIPAA

C) Technology - ISO, COBIT, and more

D) Federal - FISMA, NERC CIP, GPG 13, and more

E) Education - FERPA F) Other

 

HINT: Check out Verizon’s 2016 Data Breach Investigation Report. Click here.

 

Answer: A) Financial services

 

If your business must comply with a major IT regulatory framework or scheme, you may be subject to serious penalties for noncompliance.

 

5.) Not adhering to a compliance program can have severe consequences, especially when breaches are involved. Which of the following can result from noncompliance?

 

A) Withdrawal or suspension of a business-critical service

B) Externally defined remediation programs

C) Fines

D) Criminal liability

E) All of the above

 

HINT: Read this Geek Speak post titled The Cost of Noncompliance. Think big picture and across all frameworks.

 

Answer: E) IT compliance violations are punishable by all of these means, and more.

 

The cost of a breach goes well beyond the fines and penalties levied by enforcement agencies. It also includes the cost of detecting the root cause of a breach, remediating it, and notifying those affected. There are also legal expenditures, business-related expenses, and loss of revenue by damaged brand reputation to take into account, as well.

 

6.) True or False: The price that businesses pay for sensitive data breaches is on the rise globally.

 

HINT: You do the math!

 

Answer: True. According to the Ponemon Institute, the cost associated with a data breach has risen year over year to a current $4 million.

 

Healthcare is increasingly targeted by cyberattacks, including a spree of high-profile breaches and increased enforcement efforts from the OCR over the past few years.

 

7.) What type of data are hackers after if your business is in the healthcare industry?

 

A) CD or CHD

B) ePHI

C) PII

D) IP

 

HINT: Read this post: Top 3 Reasons Why Compliance Audits Are Required.

 

Answer: B) ePHI - Electronic Protected Health Information

 

Other Definitions: CD/CHD - Cardholder Data; ePHI - Electronic Protected Health Information; PII - Personally Identifiable Information; IP - Intellectual Property

 

Despite the higher black market value of healthcare data, 2016 saw a greater volume of compromised PCI data. This makes it all the more important to understand this framework.

 

8.) Which response most accurately describes PCI DSS compliance?

 

A) The organization can guarantee that credit card data will never be lost

B) The organization has followed the rules set forth in the Payment Card Industry Data Security Standards, and can offer proof in the form of documentation

C) The organization is not liable if credit card data is lost or stolen

D) The organization does not store PAN or CVV data under any circumstances

 

HINT: Check out this article: Best Practices for Compliance.

 

Answer: B) The organization has followed the rules set forth in the Payment Card Industry Data Security Standards, and can offer proof in the form of documentation.

 

According to the Verizon 2016 Data Breach Investigation Report, 89% of breaches had a financial or espionage motive. With a long history of unified compliance efforts, the banking industry certainly takes this seriously, and so should you.

 

9.) True or False: The Federal Financial Institute of Examiners Council (FFIEC) is empowered to prescribe uniform principles, standards, and report forms to promote uniformity in the supervision of financial institutions.

 

HINT: See footnote #3 from the The Cost of Noncompliance.

 

Answer: True.

 

Though your aim as an IT pro may be to get compliance auditors off your back, the cybersecurity threat landscape is constantly changing.

 

10.)  True or False: If your organization passed its first compliance audit, that means its network is secure.

 

HINT: Watch our Becoming and Staying Compliant video (10:06- 11:09). Click here.

 

Answer: False. Continuous IT compliance is key to meeting and maintaining regulatory requirements long-term.

 

Any feedback on this quiz or burning questions come as a result? Share a comment, we’d love hear your thoughts.

PCI DSS 3.1 expires October 31st this year. But don’t panic. If you don’t have a migration plan for 3.2, yet, you have until Feb 1, 2018 before the requirements become mandatory. For most merchants, the changes are not onerous. If you are a service provider, however, there are more substantial changes, some of which are already in effect. In this post we focus on the requirements for merchants, and present a quick overview of the required changes so that you can identify any gaps you may still need to remediate. 

 

The main changes in PCI DSS 3.2 are around authentication, encryption, and other minor clarifications. We will primarily discuss authentication and encryption in this article.

 

Authentication

The PCI council review of data breaches over the years has confirmed that current authentication methods are not sufficient to mitigate the risk of cardholder data breaches. Even though cardholder data is maintained on specific network segments, it is nearly impossible to prevent a data breach if the authentication mechanisms are vulnerable as well. Specifically, the reliance on passwords, challenge questions, etc. only, has been proven to be a weakness in the overall security of cardholder networks. 

 

The new 3.2 requirements now state that multi-factor authentication (MFA) is required for all individual, administrative, non-console, or remote access to the cardholder data environment.[1] The new standard is clear. Multi-factor[2] means at least two of the following:

 

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric

 

Multi-factor does not mean a password and a set of challenge questions, or two passwords.

 

Implementing such multifactor authentication takes time and planning as there are almost 200 different types of multifactor solutions on the market.

Multifactor authentication is also complex because:

  1. It likely needs to integrate with your single sign-on solution
  2. Not all IT systems can support the same types of MFA, especially cloud solutions
  3. MFA resets are more complex (especially if a dongle is lost)
  4. Most MFA solutions require rollout and management consoles on top of your built-in authentication

 

Encryption

In recent years, SSL, the workhorse for securing e-commerce and credit card transactions, has been through the ringer. From shellshock, heartbleed, and poodle to the Man-in-the-Middle AES CBC padding attack reported this May, SSL, openSSL, and all the derivative implementations that have branched from openSSL have been experiencing one high severity vulnerability after another. [SIDEBAR: A list of all vulnerabilities in openSSL can be found here: List of OpenSSL Vulnerabilities, other SSL vulnerabilities can be found on the vendors websites or at the National Vulnerability Database.] Of particular concern are SSL vulnerabilities in Point of Sale solutions and other embedded devices as those systems may be harder to upgrade and patch than general-purpose computers. In response, the PCI council has issued guidance on the use of SSL.[3]

 

The simplest approach to achieve PCI DSS 3.2 compliance is not to use SSL, or early versions of TLS, period. [SIDEBAR TLS  - Transport Layer Security is the name of the IETF[4] RFC that was the follow on to SSL]. In fact, any version of TLS prior to 1.2 and all versions of SSL 1.0-3.0 are considered insufficiently secure to protect cardholder data. As a merchant, you may still use these older versions if you have a plan in place to migrate by June 2018, and a risk mitigation plan to compensate for the risks of using such older versions. Risk mitigation plans might include, for example, additional breach detection controls, or documented patches for all known vulnerabilities, or carefully selecting cipher suites to ensure no weak ciphers are permitted, or all of the above. If you have a Point of Sale or Point of Interaction system that does not have any known vulnerabilities, you may run these systems using older versions of SSL/TLS. The PCI council reserves the right to change guidance if new vulnerabilities associated with a particular POS or POI become known which jeopardize the cardholder environment.

 

If you are concerned about the risk to your e-commerce or mobile environment with upgrading your SSL to TLS 1.2 or higher, you can ask your online marketing department what the oldest versions of iOS, Android, Windows® and Mac® are that connect to your systems. Android has supported TLS 1.2 since version 4.1, although it is not enabled by default. As of version 4.4, Kitkat, released Oct. 2013, TLS 1.2 has been enabled by default. iOS 5, has supported TLS 1.2 since Oct. 2011. Windows 8 is the first Microsoft OS to support TLS 1.2 by default. Prior to that, you needed to manually configure TLS 1.2 support. A complete TLS table for Windows is available here: TLS version support. For Mac OS® you need to reach Mavericks, (Oct. 2013) to find a Mac computer with TLS 1.2 enabled by default.  

 

If all this versioning seems daunting, not to worry. Most modern browsers, which auto- upgrade, have been supporting TLS 1.2 for a long time.[5] The net/net is most organizations have nothing to fear with upgrading their secure communications layer to TLS 1.2.

 

Minor Clarifications

There are some additional nuances regarding the correct cipher suites to use to meet PCI DSS 3.2 requirements, which we will cover in a future post on using managed file transfer in cardholder environments.

 

If you are a PCI pro, you now have a good overview of the major changes coming in PCI DSS 3.2. Note that we didn’t address the additional changes a service provider needs to comply with, nor did we walk though all 12 requirements of PCI DSS and how they apply to IT organizations. For some of that, you should check out the Simplifying PCI Compliance for IT Professionals White Paper.

 

Questions about PCI DSS?

If you have questions regarding the latest version of PCI DSS, or what’s generally required from an IT perspective to maintain compliance, we urge you to join in the conversation on THWACK!

 


[1] Requirement 8.3

[2] Requirement 8.2

[3] PCI DSS 3.2 Appendix 2

[4] Internet Engineering Task Force RFC 2246, et. seq https://www.ietf.org/rfc/rfc2246.txt

[5] https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers

1606_LEM_Integration_Guide_w160h600.png

The process of expanding operations or adopting new technology within an IT organization is sometimes met with caution. Rightfully so, given what’s at stake. Even the smallest configuration error, which can happen when you introduce new software or systems into a network, can spell disaster. Whether it leads to downtime, loss of data, the advent of security vulnerabilities, or compliance violations, the costs can be great for businesses of all sizes.

 

It’s not surprising, then, that some IT pros are hesitant to try out new software or test the latest SolarWinds offerings. But what it really boils down to is the fact that some IT pros don’t have the resources available to test a solution effectively without fearing these negative consequences.

 

What if I told you it was possible to test a solution like SolarWinds® Log & Event Manager (LEM) in a manner that was both safe and free for your business? Would you consider adding a powerful SIEM solution to your arsenal that tackles IT security and compliance? Well, you can! Introducing the LEM + GNS3® Integration Guide.

 

What is GNS3?

 

GNS3 is a multi-vendor tool that allows you to build, design, and test network configurations and software in a risk-free virtual environment. This technology eliminates the need for expensive physical testing by offering a network-attached or stand-alone virtual test bed, free of charge. With real-time network emulation, users can conduct proof-of-concept testing and troubleshooting on dynamic network configurations.

 

Download the GNS3 and SolarWinds LEM Integration Guide

 

Whether you’re a seasoned GNS3 pro that’s new to LEM, or a LEM user that’s interested in building a lab to experience the full functionality of the product within a safe and secure virtualized instance for testing or troubleshooting, this guide has something for you. In addition to instructing you on how to get started with VMWare®, Hyper-v®, GNS3, and LEM, this guide will help you understand some of the LEM basics to help ensure that you hit the ground running with this advanced security solution.

 

Click here for access to the guide and free 30-day trial of LEM!

 

To learn more about the partnership we’ve formed with GNS3, check out the GNS3 Group on THWACK: https://thwack.solarwinds.com/groups/gns3

When it comes to the technical aspects of PCI DSS, HIPAA, SOX, and other regulatory frameworks, the goals are often the same: to protect the privacy and security of sensitive data. But the motivators for businesses to comply with these regulatory schemes varies greatly.

Penalties for Noncompliance

 

Regulatory Compliance Framework

Industry

Scope

Year

Established

Governing Body

Penalties

PCI DSS

Payment Card Industry Data Security Standards

Applies to any organization that accepts credit cards for payment

2004

Payment Card Industry Security Standards Council (PCI SSC)[1]

  • Fines up to $200,000/violation
  • Censure from credit card transactions

HIPAA

Health Insurance Portability and Accountability Act[2]

Applies to healthcare-related businesses deemed either covered entities or business associates by law

1996

The Department of Health and Human Services (HHS) Office for Civil Rights (OCR)

  • Up to $50,000 per record
  • Maximum on $1.5M/year

SOX

Sarbanes–Oxley Act

 

Applies to any publicly traded company

2002

The Security and Exchange Commission (SEC)

  • Fines up to $5M
  • Up to 20 years in prison

NCUA

National Credit Union Association

Applies to credit unions

1934
(r. 2013)

NCUA is the federal agency assigned to enforce a broad range of consumer regulations that apply to federally chartered credit unions and, to a lesser degree, federally insured state chartered

credit unions.[3]

  • Dissolve your credit union
  • Civil money penalties

GLBA

Gramm-Leach-Bliley Act

Applies to financial institutions that offer products or services to individuals, like loans, financial or investment advice, or insurance

1999

Federal Trade Commission (FTC)

  • $100,000 per violation
  • Up to 5 years in prison

FISMA

Federal Information Security Management Act

Applies to the federal government and companies with government contracts

2002

Office of Management and Budget (OMB), a child agency of the Executive Office of the President of the United States

  • Loss of federal funding
  • Censure from future contracts

 

 

This list only represents a fraction of the entire regulatory compliance structures that govern the use of information technology and processes involved in maintaining the confidentiality, integrity, and availability of sensitive data of all types.

 

Yes, there are monetary fines for noncompliance or unlawful uses or disclosures of sensitive information – the chart above provides an overview of that – and for most, that alone offers plenty of incentive to comply. But beyond this, businesses should be aware of the many other consequences that can result from non-compliance or any other form of negligence that results in a breach.

 

Indirect Consequences of Noncompliance

 

Noncompliance whether validated by audits, or discovered as the result of a breach, can be devastating for a business. Though, when a breach occurs, its impact often extends well beyond the fines and penalties levied by enforcement agencies. It can include the cost of detecting the root cause of a breach, remediating it, and notifying those affected. Further, the cost balloons when you factor in legal expenditures, business-related expenses, and loss of revenues faced by damaged brand reputation.

 

As if IT pros did not have enough to worry about these days, yes, unfortunately compliance too falls into their laps. But depending on the industries they serve and the types of data their business interacts with, what compliance actually entails can be quite different.

 

Regulatory Compliance and the Intersection with IT

 

Without a doubt, there are many aspects of data security standards and compliance regulations that overshadow everything from IT decision-making and purchasing, to configurations, and the policies and procedures a company must create and enforce to uphold this important task.

 

Organizations looking to comply with a particular regulatory framework must understand that no one solution, and no one vendor, can help prepare them for all aspects of compliance. It is important that IT professionals understand the objectives of every compliance framework they are subject to, and plan accordingly. 

 


[1] The PCI SSC was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Participating organizations include merchants, payment card-issuing banks, processors, developers, and other vendors.

[2] The Health Information Technology for Economic and Clinical Health (HITECH) Act, which was enacted as part of the American Recovery and Reinvestment Act of 2009, prompted the adoption of Health Information Technology. This act is recognized as giving “teeth” to HIPAA as it established stricter requirements by establishing the Privacy, Security, and Breach Notification Rules, as well as stiffer penalties for violations. The HIPAA Omnibus Rule, which went into effect in 2013, further strengthened the OCR’s ability to enforce compliance, and clearly defined the responsibility of compliance for all parties that interact with electronic protected health information (ePHI).

[3] It is important to note that in the financial world, guidance from the Federal Financial Institute of Examiners Council (FFIEC) to a bank is mandatory because the guidance specifies the standards that the examiner will use to evaluate the bank. Credit unions technically fall under a different regulator than banks, however, the National Credit Union Association closely follows the FFIEC guidance.

 

1606_LEM_Compliance-Campaign_WP_640x200_Intro.png

The IT help desk is the lifeblood of an organization. It assists co-workers and end-users in many critical ways, including troubleshooting, answering questions, solving known problems, and helping the organization maintain productivity. However, if you’re manually managing the IT help desk function for your business, the speed at which you’re able to resolve issues could suffer, leading to delayed ticket resolution and unhappy end-users.

 

In this blog, I’ll detail five challenges businesses face by manually managing the IT help desk (as illustrated in the infographic), and offer up an alternative solution that’s sure to help desk admins and technicians avoid a lot of unnecessary headaches.

 

The Trouble With a Manual Help Desk

 

  1. Routing Tickets – Manually managing the IT help desk can make it difficult to track the availability of technicians to respond to issues. In this case, accidentally doubling down on requests is far from unheard of. And without in-depth knowledge of each individual on your team, assigning tasks based on the criticality and technicality of issues is more of a shot in the dark. Regardless, both scenarios can delay the process of even responding to a ticket, much less meeting a resolution.

  2. Tracking Down the End-user - When relying on a manual system for running the IT help desk, tickets are addressed in-person, which wastes time tracking down the end-user to provide hands-on assistance. Clearly, time spent running around leaves less time for resolving issues.

  3. Tedious, Manual Support – Troubleshooting at the “scene of the crime” (i.e. the end-users’ workstation) can have its benefits, but it leaves end-users twiddling their thumbs while a support technician diagnoses and corrects an issue. Of course, that end-user has much better things to do with their time, including hitting the next deadline, or getting to a meeting, which simply compounds the issue.

  4. Manually Closing Tickets – Another aspect of manually managing the IT help desk involves closing support cases. Though seemingly painless, the process of updating a static spreadsheet somewhere and contacting the supported party to confirm satisfaction can be even more of a time suck for IT support admins than you realize.

  5. Results and Performance – We all know time is money. Therefore, the time it takes to resolve an issue, which can certainly be compounded by all the factors I’ve listed above, means time (and money) wasted because someone is left stranded by IT issues. Plus, when evaluating the performance of the IT help desk organization as a whole, let’s just say downtime is frowned upon.

 

Two Ways to Run an IT Help Desk

 

IT Help Desk technicians face challenges on a daily basis. Manually managing the entire help desk function does not have to be one of those challenges. Through the combined use of SolarWinds® Web Help Desk and DameWare® Remote Support, life for IT pros can be far simpler. Take a look at the infographic below to see a comparison of what it’s like to manage a web help desk operation manually versus the use of these two solutions.

 

A lot can be said about the benefits of enabling remote support capabilities within your help desk solution, especially when IT issues arise. Consider the combined use of these two SolarWinds solutions, if not for the end-users and co-workers you support, but for the productivity of your businesses as a whole.

 

 

2 Ways to Run a Help Desk

2 Ways to Run a Help Desk from SolarWinds

Whether providing support to end-users or fellow employees, there are countless benefits to leveraging an IT Help Desk solution. From ticketing and service management, to IT asset management and more, these solutions have a lot to offer in the way of optimizing the efficiency of the support function of a business.

 

IT help desk admins are busy people. They are constantly juggling service requests and trouble tickets, either bouncing from workstation to workstation to provide hands-on support, or offering assistance via phone or web.

 

Though help desk solutions offer the advantage of tracking and managing all aspects involved in battling support issues, sometimes there’s nothing like a face-to-face, rather a screen-to-screen visit to improve this interaction.

 

In this blog, I’ll detail five benefits of the combined use of an IT help desk solution and remote support tools, a power punch combo that is sure to have an impact on the delivery of IT support.

  1. Simplifying IT Service Management (ITSM) – By integrating remote support tools into a help desk solution, help desk technicians can manage ticketing automation and SLAs, and seamlessly interact with end-users to resolve their issues. Establishing remote connections to the end-user’s desktop directly from within help desk tickets and chat windows provides a gateway to greater transparency. It also eliminates the need to visit users personally, simplifying the ITSM process from end-to-end.

  2. Increasing operational efficiency – As mentioned above, help desk solutions remove the need for manually managing tickets, creating performance reports, assigning tickets to technicians, etc. Using such a tool allows IT support pros to focus on the task at hand: remediating support issues. By integrating remote support capabilities, this enhances their performance, providing direct access to problematic end-user machines and IT systems, enabling them to diagnose performance problems and troubleshoot immediately from anywhere.
  3. Automating IT support – An ideal help desk system automates IT support operations, including ticketing management, IT asset discovery and management, escalations, change/approval management, and more. The addition of remote support capabilities helps to streamline IT support from ticket creation to resolution, all within a single console.
  4. Lowering time to resolution – Enabling remote support tools within a help desk solution gives IT help desk admins the ability to explore problems right from the source, rather than shuffling through screen shots or spending time deciphering written or verbal details, which are often provided by the technical layman. This empowers them to accelerate the resolution process.
  5. Improving customer satisfaction – IT issues can bog down business, causing trouble for the end-users and the company as a whole. Having these tools at their disposal allows help desk technicians to quickly diagnose and resolve issues, so end-users and fellow employees can get back to business. When coupled with the ability to track and measure the performance of help desk technicians, this strengthens a company’s ability to provide excellent support. And this, in turn, translates to greater customer satisfaction over time.

 

Interested in learning more about the benefits of incorporating remote support capabilities into your help desk solution? Watch this quick two-minute video to discover the value

SolarWinds® Web Help Desk customers receive from integrating DameWare® Remote Support into their solution.

 

Do you have other examples of how remote support has helped your help desk achieve greater levels of success? Share a comment to fill us in!

Filter Blog

By date: By tag: