Alex Crittenden

More by Alex Crittenden
WP_Query Object
(
    [query] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "61"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "61"
                            [compare] => LIKE
                        )

                )

        )

    [query_vars] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "61"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "61"
                            [compare] => LIKE
                        )

                )

            [error] => 
            [m] => 
            [p] => 0
            [post_parent] => 
            [subpost] => 
            [subpost_id] => 
            [attachment] => 
            [attachment_id] => 0
            [name] => 
            [pagename] => 
            [page_id] => 0
            [second] => 
            [minute] => 
            [hour] => 
            [day] => 0
            [monthnum] => 0
            [year] => 0
            [w] => 0
            [category_name] => 
            [tag] => 
            [cat] => 
            [tag_id] => 
            [author] => 
            [author_name] => 
            [feed] => 
            [tb] => 
            [paged] => 0
            [meta_key] => 
            [meta_value] => 
            [preview] => 
            [s] => 
            [sentence] => 
            [title] => 
            [fields] => 
            [menu_order] => 
            [embed] => 
            [category__in] => Array
                (
                )

            [category__not_in] => Array
                (
                )

            [category__and] => Array
                (
                )

            [post__in] => Array
                (
                )

            [post__not_in] => Array
                (
                )

            [post_name__in] => Array
                (
                )

            [tag__in] => Array
                (
                )

            [tag__not_in] => Array
                (
                )

            [tag__and] => Array
                (
                )

            [tag_slug__in] => Array
                (
                )

            [tag_slug__and] => Array
                (
                )

            [post_parent__in] => Array
                (
                )

            [post_parent__not_in] => Array
                (
                )

            [author__in] => Array
                (
                )

            [author__not_in] => Array
                (
                )

            [search_columns] => Array
                (
                )

            [ignore_sticky_posts] => 
            [suppress_filters] => 
            [cache_results] => 1
            [update_post_term_cache] => 1
            [update_menu_item_cache] => 
            [lazy_load_term_meta] => 1
            [update_post_meta_cache] => 1
            [nopaging] => 1
            [comments_per_page] => 50
            [no_found_rows] => 
            [order] => DESC
        )

    [tax_query] => WP_Tax_Query Object
        (
            [queries] => Array
                (
                )

            [relation] => AND
            [table_aliases:protected] => Array
                (
                )

            [queried_terms] => Array
                (
                )

            [primary_table] => wp_posts
            [primary_id_column] => ID
        )

    [meta_query] => WP_Meta_Query Object
        (
            [queries] => Array
                (
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "61"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "61"
                            [compare] => LIKE
                        )

                    [relation] => OR
                )

            [relation] => OR
            [meta_table] => wp_postmeta
            [meta_id_column] => post_id
            [primary_table] => wp_posts
            [primary_id_column] => ID
            [table_aliases:protected] => Array
                (
                    [0] => wp_postmeta
                )

            [clauses:protected] => Array
                (
                    [wp_postmeta] => Array
                        (
                            [key] => new_authors
                            [value] => "61"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                    [wp_postmeta-1] => Array
                        (
                            [key] => new_presenters
                            [value] => "61"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                )

            [has_or_relation:protected] => 1
        )

    [date_query] => 
    [request] => 
					SELECT   wp_posts.ID
					FROM wp_posts  INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
					WHERE 1=1  AND ( 
  ( wp_postmeta.meta_key = 'new_authors' AND wp_postmeta.meta_value LIKE '{ad2edc232b64cf59860f1fde10d6a9040ed839084a987395f39acdf665c5cc3d}\"61\"{ad2edc232b64cf59860f1fde10d6a9040ed839084a987395f39acdf665c5cc3d}' ) 
  OR 
  ( wp_postmeta.meta_key = 'new_presenters' AND wp_postmeta.meta_value LIKE '{ad2edc232b64cf59860f1fde10d6a9040ed839084a987395f39acdf665c5cc3d}\"61\"{ad2edc232b64cf59860f1fde10d6a9040ed839084a987395f39acdf665c5cc3d}' )
) AND wp_posts.post_type IN ('post', 'webinars') AND ((wp_posts.post_status = 'publish'))
					GROUP BY wp_posts.ID
					ORDER BY wp_posts.post_date DESC
					
				
    [posts] => Array
        (
            [0] => WP_Post Object
                (
                    [ID] => 1192
                    [post_author] => 61
                    [post_date] => 2012-10-01 07:00:00
                    [post_date_gmt] => 2012-10-01 07:00:00
                    [post_content] => Bring Your Own Device (BYOD) is a big topic at the moment and I’m sure that you’re already looking at how to address BYOD functionally or have already implemented BYOD at your organization.  I’m not going to debate the pros and cons of BYOD.  I’m also not going to argue for or against it from a security perspective - at this point being ‘for or against’ is irrelevant, it’s happening whether or not the security team thinks it’s a good idea.  What I’m going to address in this post is a very high-level discussion about how best to identify and address the technical risks that BYOD will expose in your environment.  From the perspective of security, what BYOD really means is that what was historically a fully ‘internal’ environment is now exposed to ‘outside’ threats.  A comprehensive approach to address internal security (which was often not understood and therefore not fully funded by executives - I mean ‘it’s behind the firewall, right?’) is now even more critical to your organization.  If the CEO and CFO want to use their personal iPads at work, then they need to understand the security risks that they are inherently accepting by pushing for a BYOD environment.  Even though many organizations have already implemented BYOD, I’m going to start this quick discussion as if you haven’t yet done so.  Why?  For two reasons:
  1. Because there are companies out there that haven’t yet put an approach in place and
  2. You may not have been given the time/resources/budget that you know you needed when being pushed to implement BYOD and you might need more ammunition when you go to the top execs to explain to them why they now have a security problem...
In the list of things I’m not going to do - I’m also not going to talk about specific device management technology, anti-virus options, etc. because, frankly, I’m not qualified and there are so many options out there right now vying for dominance that it would take too long to go through all of the various pieces and parts of this rapidly changing space (even if I did have the expertise). So, onto a quick review of the assessment steps that would be completed prior to/post BYOD implementation...
  1. Pre-BYOD
    1. Risk Assessment
      1. You need to perform a real risk assessment - documenting the risks associated with the internal environment, the inclusion of devices not entirely within your control, and what applications and data are going to be potentially exposed to individuals working with their own technology.
      2. Executives need to understand the risks and agree that the benefits to the organization outweigh those risks
      3. During this process you should also document requirements of any of the technology solutions that are going to be chosen to facilitate BYOD.  This is going to be heavily informed by the risk assessment - make sure that the solutions/policies/processes under consideration address the risks identified in the risk assessment
    2. Network Architecture Review: This can be performed as part of the risk assessment, but someone (preferably someone external to the team actually managing the networks) needs to review both current network architecture and the proposed architecture for BYOD.  This includes reviewing any firewalls that are being put in place to segment the BYOD environment away from other critical internal environments.
    3. Technical Assessment of the environment pre-implementation: Why?  Because any existing issues that have been masked by the fact that the environment was internal (or were simply ignored because management didn’t put any priority on protecting the network from insider threats) may now be a lot more relevant.  You need to fully understand the issues associated with your internal environments now that you are going to be bringing outside devices in behind the external firewalls
  2. Post-BYOD
    1. Post-implementation Penetration Test: A good penetration test (not just a scan or fully-automated assessment) is really necessary post BYOD implementation.  If done properly this pen test will provide a reasonably good review of everything that is exposed via the BYOD environment.  Make sure that whomever is doing the testing (again, not the people responsible for the BYOD implementation or the general network management) is looking at all three layers of the environment - application, infrastructure, and OS.  This should catch any major security issues associated with configuration, network management, and the applications or data that are exposed to the BYOD devices.
    2. Periodic Assessments: Organizations now routinely assess their external environments on a regular schedule; however, this is not always the case with internal environments.  With BYOD this needs to change - the internal environment needs to be looked at a lot more frequently than in the past and should receive the same scrutiny and attention as the external network.
Ultimately, as a security professional, BYOD should just be one more area of attention in your vulnerability management program, but it’s an area that some of the non-technical executives don’t always understand.  Hopefully, by taking the proper steps to review and assess the BYOD environment both pre- and post-implementation, your organization can enjoy the benefits of BYOD while minimizing the risk. [post_title] => BYOD & Security Assessments [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => byod-security-assessments [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:02 [post_modified_gmt] => 2021-04-13 00:06:02 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1192 [menu_order] => 783 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1193 [post_author] => 61 [post_date] => 2012-08-23 07:00:00 [post_date_gmt] => 2012-08-23 07:00:00 [post_content] => I have worked for and with technology-focused companies for the past 15 years.  I’m a huge believer that technological advances (or even just new ways of using existing technology) are making our lives demonstrably better. There are stops and starts along the way, but as a society, we are using technology to improve our businesses and our lives. I truly believe this. But I also believe that we, at times, rely on ‘technology’ as our savior. It fixes all problems, it solves all puzzles. Everything that we don’t really understand (but have been forced to address either at work or in life) seems like it can be dealt with by some technical product. This view is supported by the fact that, in the world of IT at least, a technical product does exist for almost anything for which there is even the perception of a need. This is especially true when you are talking about a discipline like information security. Infrastructure design and configuration, application security, regulatory compliance, policy development, privacy, disaster recovery, database security, vendor management....all of these areas might fall under ‘information security’. At the very least, those in charge of information security have some input into all of these areas. There’s a lot to know, or at least understand, here and many professionals within our community are asked to overreach their personal knowledge bank on a daily basis in order to address a need of the business. Beyond the complexity of the required knowledge, there is also a well-understood desire for standardization and progress. This is especially true if you are working for large, politically complex organizations. If you are working with disparate groups or product/program managers that are under a lot of time-pressure and working with a defined budget, you want to present a ‘solution’ that is standardized, well-structured, easily understood, and represents progress for the security program. Even if it’s not everything that should be done. Ultimately, it may be more effective to get something in place that becomes an accepted practice, even if it’s not perfect.   I’ve been thinking quite a bit about this over the last couple of weeks. Several large organizations have recently come to NetSPI and asked us to re-assess environments and applications that were recently assessed as part of their standard internal process (which involved entirely automated tools and assessment-on-demand type services). They came to us because someone on the internal security team was concerned that they were falsely assuming all was well after ‘clean’ results from these expensive technology solutions. Sadly, we were not able to provide them with any assurance - in each case our team identified vulnerabilities that were critical in nature and provided administrator access to apparently ‘secure’ environments and applications. These vulnerabilities were not zero-day issues - in some cases they weren’t even hard to identify. In two instances, the technologies that were used in the solution being reviewed simply weren’t supported by the on-demand assessment service that was utilized as part of their internal process (not that our client was informed of this by the vendor). At the end of the day, the fully automated and on-demand assessment solutions just didn’t find critical issues that our clients needed to know about in order to reduce risk. My point in relating this information isn’t to bash the use of technology or automated solutions in assessing technical security. Automation is a key part in making security more efficient, and standardization helps to promote adoption and understanding internally - both good things. My point is to recognize that technology isn’t perfect and information security has characteristics that make putting all of your assessment ‘eggs’ in a single basket provided by an automation vendor a very risky proposition for an organization that is actually looking to manage risk and exposure effectively. A recent study (Performance of automated network vulnerability scanning at remediating security issues) that looked at the performance of automated network vulnerability scanners specifically found that, across the breadth of tools tested, only slightly more than half of the vulnerabilities known to exist in the test environment were identified (and remediation guidelines presented) by the tools tested in the study. (As a side note, the same study hits the tools pretty hard on the usefulness of the reporting that is generated - something that we’ve had issues with for years and why we created our own reporting structure and content as part of CorrelatedVM™.) An interesting quote in regard to vulnerability scanning with the automated tools: ‘...there are issues with the method: manual effort is needed to reach complete accuracy and the remediation guidelines are oftentimes very cumbersome to study.’ This certainly supports NetSPI’s approach and the methodology that we follow with clients. While this study was focused specifically on leading network vulnerability scanning tools, another study (Why Johnny Can’t Pentest:  An Analysis of Black-box Web Vulnerability Scanners) found a very similar situation with web vulnerability scanners. Apparently the researchers in this case found that while certain kinds of vulnerabilities are found quite effectively, ‘there are whole classes of vulnerabilities that are not well-understood and cannot be detected by any of the scanners.’ (their emphasis) My point in all of this is that automated vulnerability scanning is certainly useful and, with large environments or applications, absolutely necessary (we use some of these tools in our assessment process), but don’t be lulled into a false sense of security. If this is all that you are doing to identify and address potential vulnerabilities within your network or critical application environments then you have a problem. Alex Crittenden [post_title] => A False Sense of Security [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => a-false-sense-of-security [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:00 [post_modified_gmt] => 2021-04-13 00:06:00 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1193 [menu_order] => 784 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1209 [post_author] => 61 [post_date] => 2012-04-24 07:00:00 [post_date_gmt] => 2012-04-24 07:00:00 [post_content] =>

For those of you who have followed the NetSPI blog, you will (hopefully) have noticed that we do try to make our posts useful and informative.  We’ve kept the rants to a minimum and the speculation non-sensational.  Many of our posts are technical and focused on detailed descriptions of testing techniques.  Some of our posts are less technical and focused on industry trends and advice. This post is not of the technical nature (I’m the wrong guy) nor is it really about industry trends (maybe a little).  I want to use this post to focus on some industry-specific vocabulary.  While there have been those in the security industry that have knowingly mis-used terminology to deceive clients, it seems that the trend is growing and we’d like to take the time to help those of you who read this blog or stumble over this post really understand what a few related, but very different terms mean. Specifically I want to focus on the term ‘Penetration Testing’ and its derivative services. Please note that I’m writing this for both the people outside the security community that are buying penetration testing or penetration testing tools as well as consultants and technical assessors within our industry.  I think that there are many on both sides that are either ignorant or willfully misusing language. Here’s how NetSPI (and our clients) define the term:

Penetration Test - An assessment of an environment or application (or both) that utilizes a combination of automated tools and manual processes to 1) enumerate vulnerabilities, 2) verify the existence of the vulnerabilities, and 3) safely exploit those vulnerabilities to better understand the risk that those vulnerabilities pose to the environment.

 

Please note that this is a three-part process.  If you only enumerate vulnerabilities it is NOT a penetration test (this is sometimes called a ‘health check’ or is referred to as a ‘scan’ as it is primarily an automated exercise).  If you only enumerate vulnerabilities and verify that they exist it is NOT a penetration test (this is what NetSPI calls a ‘Vulnerability Assessment’). Note also the phrase ‘a combination of automated tools and manual processes’.  If you are only using automated tools and are not manually testing, verifying, and penetrating, you might be able to call what you are doing a ‘Penetration Test’, but it’s a very, very poor one. There are a lot of information security companies out there right now that provide ‘Penetration Tests’ that stop at enumeration.  There are also a lot of companies out there selling ‘Penetration Tests’ that might verify some or all of the vulnerabilities they enumerate actually exist.  Both of these situations are misleading and we constantly have to educate organizations on what the term ‘Penetration Test’ really means.  It has ‘penetration’ in the name, for goodness sake; if there is no penetration how can it be called a ‘Penetration Test’?

Level of ServiceAppropriate Nomenclature
Vulnerability Enumeration through Automated Scanning / Reporting"Scan", "Health Check"
Vulnerability Enumeration and Verification Through Automated Scanning and Manual Processes"Vulnerability Assessment"
Vulnerability Enumeration, Verification, and Safe Exploitation through a Combination of Automated Tools and Manual Testing"Penetration Test"

I realize that for many of you (most of you, hopefully) this post is nothing new. If so, I’m certainly sorry for wasting your time, but every time I think we as an industry are past this issue it pops up again. I’ve also discovered that non-security executives often seem to think that a pen test is a pen test is a pen test and while this certainly isn’t the case (there is real skill involved in effective penetration testing, as well as the need for a solid process), what’s really frustrating is that it’s often the situation that what people call a pen test is actually a vulnerability assessment or a scan and that drives me nuts. In any case, please let me know if you have any feedback or thoughts on this topic. This is a big one for us - NetSPI focuses very heavily on penetration testing (as well as vulnerability assessment) and, in my opinion, we are the best in the business. Even if you’re in the industry and want to argue with me on that (btw - you’re wrong), I hope that you are doing your part to help educate clients as to the differences between these terms and the levels of service associated with each. Alex Crittenden

[post_title] => Penetration Testing - Deception through Vocabulary [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => penetration-testing-deception-through-vocabulary [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:05:52 [post_modified_gmt] => 2021-04-13 00:05:52 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1209 [menu_order] => 800 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 1219 [post_author] => 61 [post_date] => 2012-01-18 07:00:00 [post_date_gmt] => 2012-01-18 07:00:00 [post_content] =>

What the Coming HHS Audits Mean for Your Healthcare System With the announcement that KPMG really is going to start performing HIPAA Privacy Audits in the New Year, we’ve had numerous conversations with healthcare providers around getting their privacy and security programs up to scratch. It’s a well-known secret in the healthcare industry that HIPAA compliance does not receive the attention (or the funding) that it should. There are of course exceptions and I should note that most security and privacy professionals in the healthcare industry take their jobs very seriously and honestly do consider the protection of patient data to be their number one priority. But, it’s often difficult to do your job if you don’t have the funding or resources needed to do it properly. The federal government hasn’t helped - creating a mandatory requirement, but not putting in place any mechanism for testing compliance with that requirement rapidly creates a sense of non-urgency. What’s the point of REALLY making sure that we’re HIPAA compliant if no one’s going to check? It costs a lot of money, it’s annoying to doctors, it’s not even the slightest bit sexy, and it’s going to impact options to the organization. And, if none of your competitors are limiting themselves and spending extra money on ensuring HIPAA compliance, a healthcare executive is going to see true HIPAA compliance as a competitive disadvantage. Now it looks like everything is going to have to change. Don’t believe me? Think the audits are going to be ‘no big deal?’ Let’s draw a parallel with another compliance requirement – PCI DSS. For those of you not familiar with PCI, you should be – you probably have to comply with this as well. In any case, it’s the data security standard inflicted on merchants and service providers (companies that facilitate credit card payments) by the large credit card brands (VISA, MasterCard, etc.) Anyone that takes (or processes) a credit card for payment needs to be PCI compliant. Although the card brands catch a lot of flak for ‘inflicting’ PCI on the world, the truth of the matter is, something needed to be done. Credit card data was not being protected and it was costing the card brands a LOT of money in fraudulent charges and impacting consumer credit ratings. If they hadn’t created their own standard the government most likely would have. When PCI was first rolled out to the community there were a lot of merchants that thought it was no big deal, but they didn’t plan on three things:

  1. The card brands were perfectly willing to let non-compliant merchants make ‘examples’ of themselves (link, link)
  2. The legal community quickly learned what ‘PCI-compliant’ meant and how not being PCI-compliant could be used in things like multi-million dollar class-action lawsuits
  3. The PCI standard gave consumers a benchmark against which to judge the merchant’s brand.

These points have been effective because the card brands maintain a unified front when it comes to PCI (they all agree to the codified requirements as the baseline required by merchants to transact credit cards securely) and because they have a mandatory audit mechanism in place that gives them the power to take action if the merchant or service provider isn’t complying with PCI. I think that we have the same dynamic going on now with HIPAA.

  1. KPMG is going to be looking to justify their million dollar contract with the government – they will find issues with compliance during their audits.
  2. The legal community is already very aware of privacy breaches in healthcare and what that means for things like multi-million (and multi-BILLION) dollar class-action lawsuits (link, link, link)
  3. Everyone now has a benchmark against which to judge how much a healthcare provider cares about their patients’ data

I think that it’s time to figure out a plan on how to really address HIPAA – both in the short-run (i.e. achieving an initial compliant state) and long-run (maintaining compliance moving forward.)  If you aren’t familiar with the recent announcement involving the upcoming audits here’s a link on the HHS site which includes a sample of the letter that will be sent out to organizations.  Also note – the first round of audits is going to focus on Covered Entities, but future rounds will also include Business Associates. For some additional information on how to put together a workable approach to really achieving HIPAA compliance please see material on the NetSPI blog and NetSPI services pages.  Also – NetSPI will be putting together whitepapers, additional blog posts, and (possibly) a webinar on this topic over the next couple of months.  Please check back here for more information, make a comment, or send me an email (link below) if you would like to discuss.

[post_title] => HIPAA Privacy Audits - How Badly Am I Screwed? [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => hipaa-privacy-audits-how-badly-am-i-screwed [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:05 [post_modified_gmt] => 2021-04-13 00:06:05 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1219 [menu_order] => 810 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [4] => WP_Post Object ( [ID] => 1256 [post_author] => 61 [post_date] => 2011-12-08 07:00:00 [post_date_gmt] => 2011-12-08 07:00:00 [post_content] =>

What Can I Do?

What can you do to take action and address the issue?  There are a number of strategies for addressing PA-DSS as a healthcare organization in the short run:
  • Compile a list of potential applications and check the PA-DSS validated list at the PCI SSC's website - https://www.pcisecuritystandards.org/security_standards/vpa/
    • NOTE - you need to make sure that you are checking application revision as well - it matters in this process (i.e., if the app is listed, is your release listed?)
  • Contact any of your software vendors that might fit the criteria noted above and ask them to document a response to a few questions:
    • If the application (or the revision) is not on the list, ask why and what are the vendors' plans?
    • If the vendor does not feel that PA-DSS applies to their application, ask them to document why and have their response looked at by someone qualified to provide an opinion (a list of organizations that can validate applications can be found here - https://www.pcisecuritystandards.org/qsa_asv/find_one.shtml)
    • If the vendor has indicated that their application is PA-DSS-compliant, but it's not on the list, ask why - the PCI SSC has indicated that the validated payment application list (#1) is the only list that's going to matter.
    • Again, if the application is not on the validated list, and the vendor indicates that they are in process with a PA-QSA, ask which one and the timeline. Ask to talk with the PA-QSA. Most would be very happy to speak with you as long as the application vendor is willing and allows them to do so.
  • Educate yourself and your team on the PA-DSS and how others in healthcare are addressing PA-DSS with their vendors. There are a number of good blogs and documents from the PCI Council. I know that a number of leading healthcare application vendors are providing educational opportunities addressing PA-DSS. Finally, most PA-QSA firms would be happy to talk with you and answer questions (although I'd pick one that has healthcare experience; otherwise, they may be heavily focused on retail). I'll include links and resources below.
  • For upcoming applications that you are considering for purchase and that fit the criteria for PA-DSS:
    • Explain to potential vendors that you are screening for PA-DSS. If they aren't on the PA-DSS validated list either now or by a mutually agreed-upon date, take them out of the purchase process.
    • Stipulate in your contracts that applicable vendors will not only achieve compliance, but will also maintain PA-DSS compliance as required by the PCI SSC. Validation is not a one-time event for application providers; it is an on-going process that needs to be continuously addressed.

Summary

The healthcare industry is one of the most highly regulated industries on earth. Given the myriad requirements that your organization faces on a daily basis, I do not wish to raise one more to your attention; however, the far-reaching nature of the Payment Card Industry Data Security Standard and its sister standard, the Payment Application Data Security Standard, requires that the healthcare community not ignore some critical industry mandates. HITECH and HIPAA have driven security and privacy and, given the nature of the information that they are protecting, that approach is understandable. The need to protect credit card data is often not seen as a priority in healthcare the way it is in other industries (like retail), but the PCI DSS can create significant issues for any organization that takes credit cards as payment. Gaining a better understanding of PA-DSS, its applicability to your software solutions, and its potential impact on your organization is important. This is a standard that is largely dependent on vendor compliance and therefore can pose some unique challenges that other standards and regulations do not share. Please take the time now to analyze the potential impact of the PA-DSS on your organization and take the steps that you can to minimize that impact.

References

PCI Council Sites / Documents of Interest: Additional Sites / Documents of Interest: [post_title] => PCI PA-DSS in Healthcare - Part 2 [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => pci-pa-dss-in-healthcare-part-2 [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:12 [post_modified_gmt] => 2021-04-13 00:06:12 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1256 [menu_order] => 813 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 1258 [post_author] => 61 [post_date] => 2010-11-05 07:00:00 [post_date_gmt] => 2010-11-05 07:00:00 [post_content] => Healthcare executives are concerned with a broad array of regulatory and compliance-related issues.  Many of those concerns are focused on patient health, government oversight and regulation, HITECH and meaningful use, financial cost controls, and even on credit card security. That last item might not be a complete surprise, but I suspect that, for many of you, it is way down on the priority list. It's an understandable approach given the magnitude of your other concerns, but it is a decision that may come to haunt you, particularly given the emphasis that card brands (VISA, MasterCard, American Express, Discover, and JCB) have put on credit card security and the focus that they have been bringing to the healthcare field. Retailers have been struggling with credit card security for years, but the card brands have started to cast a wider net, and healthcare has become a primary focus for PCI compliance. I am sure that you are aware of the Payment Card Industry Data Security Standards (PCI DSS), a very broadly applicable security standard that concerns itself with all aspects and environments that deal with credit card information. What you might not be fully aware of (or may not fully understand the implications of) is the Payment Application Data Security Standard (PA-DSS.)  This standard is managed by the same organization that manages the PCI DSS and, with some important due dates having recently passed us by, healthcare software companies are only just starting to "wake up" to the fact that they may have to worry about PA-DSS. In this pair of articles I attempt to do three things:
  1. Provide a brief overview of PA-DSS and why it came into existence.
  2. Help you understand why you should know and care about the PA-DSS.
  3. Provide you some steps that you can take to make sure your vendors are addressing PA-DSS

What is the PA-DSS?

To provide a bit of context, it's important to understand where the PA-DSS originated. PA-DSS was born from a previous program known as the PABP, or the Payment Application Best Practices program. The PABP program was a voluntary program created and administered by VISA that would allow application vendors to have a third-party assessor validate that their applications were built using security industry best practices. The PABP was a program that didn't have a lot of teeth, wasn't overly prescriptive, and wasn't mandated by VISA, so only a handful of companies (mostly retail-focused) bothered to go through the process - almost entirely for marketing purposes. In 2008, the PCI Security Standards Council (the organization created by the major credit card brands to administer the PCI DSS) was asked to take over the PABP program and align it fully with the PCI DSS. The outcome of that effort is the PA-DSS, which translates the requirements of the PCI DSS into a standard that application companies follow to ensure that they are providing an application that their clients can utilize in a PCI DSS-compliant manner. The PA-DSS is a very, very detailed standard whose requirements span documentation, technology, architecture, coding practices, process, lab testing, and a full SDLC investigation to provide a complete assessment of the security of the application. These dual standards did create some confusion for organizations concerned with or subject to the PCI DSS.  Anyone accepting a credit card needs to be PCI DSS-compliant, but they didn't have to use PA-DSS validated applications (a standard administrated by the same council.)  To make their own position clear, VISA stepped forward and stated that they required the use of PA-DSS validated applications for organizations processing VISA transactions.  As VISA accounts for the largest volume of credit card transactions in the United States, their stance on PA-DSS certainly carries a lot of weight. Now, you may be thinking, 'why all of this concern over a standard that is so focused on payment applications'?  The concern within the healthcare community comes from the definition of "payment application" - the PCI SSC has declared that, if an application fits certain criteria, it is considered a payment application, regardless of industry or the primary focus of the application. The criteria can be boiled down to:
  1. Does the application transmit, store, or process cardholder data?  (i.e., does it touch relevant credit card information?)
  2. Is the application sold, licensed, or distributed to third parties?  (i.e., it's not an application that you developed internally or had custom developed for your organization)
An FAQ on the PA-DSS program and its requirements is located on the PCI SSC's website but, if you consider just the two points above, this standard covers a lot of application solutions within the healthcare space. Basically, any software application that deals with credit card data, even if it's the most ancillary aspect of that software's functionality, is subject to the PA-DSS.

Why Should I Care?

So, why should you care?  Well, first of all, because VISA has mandated that every merchant (i.e., any organization taking a credit card for payment) must use PA-DSS-validated applications after a particular date. That date was July 1st of 2010 (yes, we're already past the mandated date.)  VISA has indicated that acquirers (the organizations that process credit card transactions) "must take prompt action to move all merchants and agents to PA-DSS-validated applications" and, although they have not at this point documented consequences for non-compliance, typical consequences could include fines, higher interchange rates, or a straight refusal from VISA to process any of your transactions. Also, as VISA works through the acquirer, not with you directly, your acquirer might simply cut you off from processing any credit card transactions. A second reason to care is that you may already be contractually obligated to address both PCI DSS and PA-DSS. Many payment processors already include provisions for your PCI DSS compliance in their contracts, but, given the pressure from VISA, PA-DSS requirements are starting to show up as well. That means that utilizing PA-DSS compliant applications for managing and accepting payment may be a requirement for taking any credit card, not just VISA-branded cards. Even if a processor doesn't restrict card acceptance, it may impose a penalty in the form of a higher interchange rate to cover their own exposure to potential security ramifications or action by VISA. The third reason (although not the least important) you should care is that this is an issue which may have a material impact on your organization, but is largely out of your direct control. You cannot have someone validate the software that you use in your facility (unless you are utilizing internally developed or fully customized applications) - the process needs to be initiated by the software vendor, the documentation updates need to be done by the vendor, the testing needs to be done on specific revisions of the applications, etc. You can't fix this problem no matter how good you are at making your environment and facility secure. This is the responsibility of the application vendor, but it has the potential to have a significant impact on your organization's ability to accept credit card payments. I'll elaborate a little further in the next section, but action needs to be taken to get your vendors moving in the right direction on PA-DSS. In the retail community, it took retailers screening vendors for PA-DSS and building PA-DSS into contracts for application companies to finally stop arguing and get moving on their PA-DSS requirements. Healthcare organizations are only starting to recognize that they need to keep their vendors' feet to the fire on PA-DSS, and it's only now becoming a big issue as a few of the more forward-thinking application companies targeting the healthcare space are starting to prepare for and go through PA-DSS validation. Next up - what can I do?... [post_title] => PCI PA-DSS in Healthcare – Part 1 [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => pci-pa-dss-in-healthcare-part-1 [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:11 [post_modified_gmt] => 2021-04-13 00:06:11 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1258 [menu_order] => 851 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [6] => WP_Post Object ( [ID] => 1300 [post_author] => 61 [post_date] => 2009-11-05 07:00:59 [post_date_gmt] => 2009-11-05 07:00:59 [post_content] => This post is a result of many, many conversations with software companies regarding the PCI Payment Application Data Security Standard (PA-DSS).  What’s really interesting about all those conversations is that they tend to fit into two categories – the first involves software companies that know that they need to go through PA-DSS validation and are looking for real guidance, the other typically involves organizations that are looking for someone to tell them that the standard doesn’t apply to them for some reason.

 The questions below are the most common ones that we receive from that second group.  Hopefully, the answers will help those non-POS companies that are wondering whether PA-DSS applies to them.

1.    We are a healthcare (or some other type of) software company, not a POS vendor. We're not even implemented in a retail setting. PA-DSS doesn't really apply to us, right?

No, this is not correct. If your situation matches the criteria for the standard (just below), then PA-DSS applies. That doesn't mean that you have to go through the validation process, it just means that you have to go through the validation process if you want to keep selling your software to companies that accept Visa transactions. Keep reading and I'll explain. General Criteria:
  • Is the application being sold, distributed, or licensed to a third party?
  • Does the application store, process, or transmit cardholder data (credit card information)?  Note – ‘process’ doesn’t necessarily mean financial transaction. For example, taking and hashing a card number would be considered ‘processing’ cardholder data.
2.    Our company is really a Service Provider - 80% of our business is hosted, and we only sell our software to a subset of our clients for implementation at their location. We don't have to bother going through this, do we? According to the PCI SSC, if your software matches the criteria (see #1), then you need to go through the process. In fact, if you haven’t already, you most likely need to go through the full PCI DSS process as a Service Provider as well. There are exemptions for one-off, customized solutions, but if you are selling the same base application to two or more clients (and, again, you meet the criteria) you need to address PA-DSS. 3.    Isn't there some way of doing this more cheaply? Not really. The process of validating an application under PA-DSS is actually quite involved. It includes documentation review, lab testing, interviewing, process and controls review, documentation, documentation, documentation, and some more documentation. This is not PABP (if you are familiar with the original Visa software security standard). We have seen significant issues with companies that thought they could treat PA-DSS with the same level of attention and effort as they gave to the older standard. 4.    Are the PCI Council and the card brands trying to put my company out of business? No - I honestly don't think so. They are just looking to make sure that applications capable of being implemented in a PCI-compliant manner are what are being sold in the marketplace to handle credit card information and transactions. Their interest is primarily in keeping their card data secure and in making sure that the merchant is choosing applications that will support that goal. 5.    Are they really going to enforce this? Yes, I think they are. Visa has given every indication that they fully intend to enforce PA-DSS validation and, given their willingness to do so on the broader PCI DSS, I would be willing to bet that they won’t back down. 6.    Do my customers need to have our product validated for them to be compliant with the PCI DSS? No, your customers are not required by the PCI DSS to utilize PA-DSS validated applications today. In practice (a point stressed at the recent PCI Community Meeting), Visa will be requiring merchants and service providers to use PA-DSS validated applications (unless the applications are developed internally). That Visa announcement makes PA-DSS a practical requirement (even if not technically a PCI requirement) for companies that want to continue accepting Visa as a form of payment. 7.    How long does the PA-DSS process take? It actually depends heavily on the software vendor. If they are highly motivated, committed, and well prepared (and timing with the PA-QSA matches up), the process can be fairly quick. This isn’t necessarily typical, however. At NetSPI we work with our PA-DSS clients in a very interactive manner. We want to identify gaps and allow you to address them prior to testing and review being complete. Closing identified gaps requires the software vendor to take real action; without that action and commitment, the process can really drag. There is little the PA-QSA can do to move the process along without that commitment. 8.    Why are there fewer PA-QSAs vs. PCI-QSAs? In my opinion, it is due to a few things:
  • Application expertise and app security expertise are NECESSARY for PA-DSS – it’s not quite so easy to throw outside resources at PA-DSS and try to survive on a rigid audit process; you actually have to know what you are talking about.
  • The rigorous QA program that the PCI SSC has implemented on the PCI DSS side was actually ‘turned on’ from day one on the PA-DSS side and required a level of documentation and commitment on the part of the PA-QSA that many in the PCI community simply didn’t want to (or couldn’t) handle.
  • In PA-DSS, the relationship between the firm validating the software and the vendor going through validation is extremely important. This isn’t just about an audit and we’re done. If a PA-QSA firm is doing its job correctly, the QSAs are having discussions with their client about future updates, version control issues, architecture issues, how to operationalize future PA-DSS validation efforts, etc. That’s a consulting/partnership relationship, and many in the PCI community aren’t focused on that type of relationship.
9.    Implementing our solution in our PA-DSS partner's lab is a real pain, do we have to?

Not necessarily – the council prefers that your application be tested in a PA-QSA’s lab, but it’s not required. If it is impractical for the application to be installed in the testing lab (and your PA-QSA feels comfortable defending that opinion), you can bring the PA-QSA to your location.

10.    We think this whole thing is ridiculous. What if we refuse? You certainly have the right, but the PCI SSC has been very straightforward: the PCI PA-DSS list is to be the de facto standard on PCI–acceptable applications. If your application is not on the list, you are taking a risk, the potential impact of which would most likely go far beyond the expense of going through the process. 11.    We've gone through CCHIT (or some other standard that includes security). Aren't we covered? No. PA-DSS is not a suggestion from Visa– it’s a requirement. It is also the only standard that is entirely focused on cardholder data (the data that card brands really care about). If your solution has been successfully audited or validated under another security-focused standard, you may have a head start on getting your solution to a PA-DSS-compliant state. That effort may help prepare you for PA-DSS validation. [post_title] => Questions on PA-DSS from Software Companies and Straight Answers [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => questions-on-pa-dss-from-software-companies-and-straight-answers [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:12 [post_modified_gmt] => 2021-04-13 00:06:12 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1300 [menu_order] => 887 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [7] => WP_Post Object ( [ID] => 1305 [post_author] => 61 [post_date] => 2009-10-22 07:00:59 [post_date_gmt] => 2009-10-22 07:00:59 [post_content] =>

In a post that I wrote earlier, "The Far-Reaching Impact of the PCI DSS," I mentioned the influence of the PCI DSS on industries other than retail and hospitality. I'd like to expand on that topic by taking a look at healthcare software and the Payment Application Data Security Standard(or PA-DSS, a standard within the broader PCI DSS.)

Since the introduction of the PA-DSS, and the 'retirement' of the former standard (PABP), NetSPI has been constantly engaged with companies that suddenly have to address what was previously a voluntary standard and one that was considered relevant only by Point-Of-Sale (POS) vendors.

However, what has been pretty clear from the beginning is that PA-DSS is in no way limited to the retail checkout environment. As defined by the PCI SSC, the PA-DSS applies to applications that:

  • Store, process, or transmit cardholder data
  • Are sold, distributed, or licensed to third parties

It's really pretty straightforward - if you are a software company and your product fits these two criteria, PA-DSS applies to you. That means that healthcare application companies whose products touch cardholder data now need to add PA-DSS to the list of standards they need to be concerned about. Also, I should mention that the deadline that VISA has set for PA-DSS compliance is July 2010.

Many integrated healthcare solutions are built to support a wide range of needs inside a complicated hospital or practice environment – managing workflow, interaction, and data sharing internally between departments as well as externally with patients, insurance companies, and, potentially, public health representatives.

Often these highly valuable (and highly intricate) systems were not built with a primary focus on financial transactions – they sprang from the needs of doctors, patients, and the medical system. The requirements involved with PA-DSS and the broader PCI DSS can be confusing and hard to translate for healthcare software companies that have certainly incorporated security and privacy into their products, but have traditionally focused on patient confidentiality rather than cardholder data protection.

Today, my recommendations for healthcare software companies would be:

  1. Rapidly determine if their solutions meet the criteria for PA-DSS and, if so,
  2. Quickly find a partner that belongs to the small group of seasonedPA-QSAs (it’s a fairly small group) and has significant experience with both healthcare and enterprise-level applications (an even smaller group.)

As the deadline approaches, addressing these two things is the first step in a process that really needs to be more holistic and take into account the full spectrum of security concerns that face the healthcare software community. That holistic view now includes validating against a standard that was not developed by a healthcare-centric entity, but rather by an organization that was created to ensure credit card security (regardless of the market or environment.)

Understanding where and how the PA-DSS translates into their solutions is one of the challenges for software providers in the space, and there are few knowledgeable, experienced partners to turn to as July gets closer

[post_title] => Healthcare Solutions and PA-DSS Compliance (with a Deadline in July) [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => healthcare-solutions-and-pa-dss-compliance-with-a-deadline-in-july [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:05 [post_modified_gmt] => 2021-04-13 00:06:05 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1305 [menu_order] => 892 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [8] => WP_Post Object ( [ID] => 1307 [post_author] => 61 [post_date] => 2009-10-21 07:00:59 [post_date_gmt] => 2009-10-21 07:00:59 [post_content] =>

At the PCI Community Meeting last month in Las Vegas, one thing was abundantly clear – merchants and service providers need help. The confusion that comes with a complicated, comprehensive security standard, coupled with governance that shifts back and forth between the PCI-SSC and the card brands, has created a situation that requires that a QSA be more than just an auditor for their clients.

Now, I should state that I’m a full supporter of the PCI SSC and the PCI DSS – I’m not here to bash the council or the brands. Security around cardholder data is something that really needed improvement (and continues to need improvement), and the PCI DSS is really just a codified set of best practices with a tight focus on cardholder data.

At the community meeting I noticed that a number of the attendees appeared frustrated by how many times a question to the SSC (or to the card brand representatives to the SSC) elicited a response of "That’s really a brand-specific question and will need to be asked to the individual brands directly."  By this point most companies recognize that the PCI DSS is not the overall goal for their security strategy – its narrow focus ignores a great deal that organizations need to be concerned about in terms of information security. However, today many organizations still don’t realize that PCI isn’t even ‘complete’ in addressing credit card security – the brands may have important individual guidance that supersedes the PCI DSS.

Which brings me back to my initial statement – people need help and not just audits. The merchant and service provider community is looking for leadership and for partners to work with them to understand the unique and shifting landscape of compliance and security. This includes PCI, but it also includes the broader discussion of what the individual brands require outside of the PCI DSS and the impact of decisions on overall security.

The community expects and, truthfully, deserves this leadership. After all, we’re the experts and they are putting their trust in that expertise. Yes – passing your PCI audit is very important, but it isn’t the only thing that’s important, even within credit card security.

[post_title] => Beyond the PCI Audit: Helping Merchants and Service Providers as a Partner [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => beyond-the-pci-audit-helping-merchants-and-service-providers-as-a-partner [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:00 [post_modified_gmt] => 2021-04-13 00:06:00 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1307 [menu_order] => 893 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [9] => WP_Post Object ( [ID] => 1315 [post_author] => 61 [post_date] => 2009-09-21 07:00:59 [post_date_gmt] => 2009-09-21 07:00:59 [post_content] =>

As the PCI Community Meeting is set to start tomorrow, I have been thinking about the current state of the retail marketplace and what that means for NetSPI's focus--security and compliance. During the down economic times no retailer really came through unscathed. Everyone suffered to some degree, but even during the most difficult periods of this recent recession, retailers that were well-run and focused on a strategic vision managed to weather the storm and to prepare themselves for the coming improvement in market conditions. Interestingly enough, during this same period the attitude towards compliance and security also shifted within the management ranks at these same organizations. What was once something they hoped to avoid became not just accepted, but in some ways welcomed. The realization that compliance and security were not just checklist items, but rather could provide strategic advantage really sank in, and these leading retailers began to use the requirements of PCI (for example) to re-invigorate broader security initiatives and to use any technical or policy adjustments as opportunities to simplify their security scope and implement better overall security policy. NetSPI's retail clients expanded their security efforts during these poor economic times and now sit in a position where they can leverage that effort into a better experience for their customers as well as for their own employees. For them it was another facet of their plan to better position their company to lead in an improved economy.

We are now starting to see that trend expand to retail organizations that have been harder hit during the recession. Organizations that are in transition are also starting to see the light and to understand that, by taking a strategic approach to compliance and security, they will ultimately position themselves to fit better with the new attitudes of consumers. Consumers are not as brand-loyal as they were before the economic challenges and are far less forgiving of a retailer that doesn’t take their private information seriously. With the economy showing signs of improvement, a rebirth is beginning in the retail space. Activities that have been conspicuously absent for the last few years--acquisitions, major technology investment, location expansion, and even IPOs--are starting to make headlines in the trade magazines and the broader press. This is a good sign for both the retail community and our economy at large, but the organizations that will take the lead over the next few years and separate themselves from the pack are those companies that have both a strategic vision (which includes security) and the ability to execute effectively.

[post_title] => Security, Compliance, and the New Retail Economy [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => security-compliance-and-the-new-retail-economy [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:14 [post_modified_gmt] => 2021-04-13 00:06:14 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1315 [menu_order] => 901 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [10] => WP_Post Object ( [ID] => 1320 [post_author] => 61 [post_date] => 2009-08-06 07:00:59 [post_date_gmt] => 2009-08-06 07:00:59 [post_content] => The last few years have seen a great deal of discussion, arguing, hand-wringing, and posturing within the retail / hospitality community regarding the PCI DSS.  It has also driven a lot of investment in technology--and a lot of investment by technology companies. Then PA-DSS came along. The PCI Council took a voluntary program (PABP) and turned it into a robust, mandatory security standard, the impact of which is still being absorbed by software vendors that provide solutions to retail and hospitality merchants. Again, there was much hand-wringing, posturing, and general frustration (this time from the vendors.) The remarkable thing to me is the degree to which, until very recently, this consternation over PCI and its applicability and requirements has largely been isolated to the retail / hospitality community. Slowly, the rest of the business world is waking up to the fact that PCI reaches far beyond retail. Electronic currency (i.e., debit and credit) is not a payment mechanism isolated to any one vertical; instead, it's increasingly used by consumers in all aspects of their spending. This realization ’process’ looks an awful lot like the classic grieving process--denial, anger, bargaining, depression, and finally, acceptance--and is the same process that the retail community has gone through for the last five years (for L1 & L2 merchants I think we've pretty much gotten to the acceptance stage). A lot of hospitals, higher education organizations, healthcare technology firms, and the like are really just beginning this process - denial is still a big part of the conversations that we have with these organizations. Now, this is certainly not a universal situation. NetSPI is working with some very forward-thinking, security-focused organizations on PCI and related security initiatives, but it's common enough to note and it's where we spend a lot of time working to educate the broader community. Luckily, we have a lot of experience with these other industries and can help our clients work through this process with more than just a retail/hospitality perspective. The fact that other standards are also applicable in some instances may be causing some of the difficulty in accepting the fact that PCI is important and applies. HIPAA, for example, has security requirements to protect personal health information. I have had numerous conversations about PCI with companies in healthcare that have sounded something like "I have to adhere to the HIPAA security standards, so I'm covered." Actually, if you take credit card payments, and you are just worrying about HIPAA's security requirements, you have a serious problem. Anyone that takes or manages electronic payments--healthcare providers, lawn care companies, hospitals, insurance companies, doctor's offices, accounting firms, tax preparation services, plumbers, event scheduling services, etc, etc, etc, etc.--is subject to PCI's requirements. The software vendors that service and support all of these industries and handle PCI-relevant information within their solution are also subject to PCI's requirements (via PA-DSS). So my advice - learn to accept PCI and take the steps today that will help make compliance more efficient and improve overall security. Find a partner that is focused on PCI guidance, not just auditing.  Make sure that they understand your industry, ask good questions that go beyond the scope of compliance, and give you honest feedback. If you accept electronic payments, PCI applies to you. If you are in denial, you need to move through your grieving process quickly so that you can make critical decisions and take the actions required to protect your organization and minimize risk. [post_title] => The Far-Reaching Impact of the PCI DSS [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => the-far-reaching-impact-of-the-pci-dss [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:15 [post_modified_gmt] => 2021-04-13 00:06:15 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1320 [menu_order] => 906 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 11 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 1192 [post_author] => 61 [post_date] => 2012-10-01 07:00:00 [post_date_gmt] => 2012-10-01 07:00:00 [post_content] => Bring Your Own Device (BYOD) is a big topic at the moment and I’m sure that you’re already looking at how to address BYOD functionally or have already implemented BYOD at your organization.  I’m not going to debate the pros and cons of BYOD.  I’m also not going to argue for or against it from a security perspective - at this point being ‘for or against’ is irrelevant, it’s happening whether or not the security team thinks it’s a good idea. What I’m going to address in this post is a very high-level discussion about how best to identify and address the technical risks that BYOD will expose in your environment.  From the perspective of security, what BYOD really means is that what was historically a fully ‘internal’ environment is now exposed to ‘outside’ threats.  A comprehensive approach to address internal security (which was often not understood and therefore not fully funded by executives - I mean ‘it’s behind the firewall, right?’) is now even more critical to your organization.  If the CEO and CFO want to use their personal iPads at work, then they need to understand the security risks that they are inherently accepting by pushing for a BYOD environment. Even though many organizations have already implemented BYOD, I’m going to start this quick discussion as if you haven’t yet done so.  Why?  For two reasons:
  1. Because there are companies out there that haven’t yet put an approach in place and
  2. You may not have been given the time/resources/budget that you know you needed when being pushed to implement BYOD and you might need more ammunition when you go to the top execs to explain to them why they now have a security problem...
In the list of things I’m not going to do - I’m also not going to talk about specific device management technology, anti-virus options, etc. because, frankly, I’m not qualified and there are so many options out there right now vying for dominance that it would take too long to go through all of the various pieces and parts of this rapidly changing space (even if I did have the expertise). So, onto a quick review of the assessment steps that would be completed prior to/post BYOD implementation...
  1. Pre-BYOD
    1. Risk Assessment
      1. You need to perform a real risk assessment - documenting the risks associated with the internal environment, the inclusion of devices not entirely within your control, and what applications and data are going to be potentially exposed to individuals working with their own technology.
      2. Executives need to understand the risks and agree that the benefits to the organization outweigh those risks
      3. During this process you should also document requirements of any of the technology solutions that are going to be chosen to facilitate BYOD.  This is going to be heavily informed by the risk assessment - make sure that the solutions/policies/processes under consideration address the risks identified in the risk assessment
    2. Network Architecture Review: This can be performed as part of the risk assessment, but someone (preferably someone external to the team actually managing the networks) needs to review both current network architecture and the proposed architecture for BYOD.  This includes reviewing any firewalls that are being put in place to segment the BYOD environment away from other critical internal environments.
    3. Technical Assessment of the environment pre-implementation: Why?  Because any existing issues that have been masked by the fact that the environment was internal (or were simply ignored because management didn’t put any priority on protecting the network from insider threats) may now be a lot more relevant.  You need to fully understand the issues associated with your internal environments now that you are going to be bringing outside devices in behind the external firewalls
  2. Post-BYOD
    1. Post-implementation Penetration Test: A good penetration test (not just a scan or fully-automated assessment) is really necessary post BYOD implementation.  If done properly this pen test will provide a reasonably good review of everything that is exposed via the BYOD environment.  Make sure that whomever is doing the testing (again, not the people responsible for the BYOD implementation or the general network management) is looking at all three layers of the environment - application, infrastructure, and OS.  This should catch any major security issues associated with configuration, network management, and the applications or data that are exposed to the BYOD devices.
    2. Periodic Assessments: Organizations now routinely assess their external environments on a regular schedule; however, this is not always the case with internal environments.  With BYOD this needs to change - the internal environment needs to be looked at a lot more frequently than in the past and should receive the same scrutiny and attention as the external network.
Ultimately, as a security professional, BYOD should just be one more area of attention in your vulnerability management program, but it’s an area that some of the non-technical executives don’t always understand.  Hopefully, by taking the proper steps to review and assess the BYOD environment both pre- and post-implementation, your organization can enjoy the benefits of BYOD while minimizing the risk. [post_title] => BYOD & Security Assessments [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => byod-security-assessments [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:02 [post_modified_gmt] => 2021-04-13 00:06:02 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1192 [menu_order] => 783 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 11 [max_num_pages] => 0 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => cf12d8d59614d0b9ed8f8a61bdf0af44 [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [allow_query_attachment_by_filename:protected] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )

Discover how NetSPI ASM solution helps organizations identify, inventory, and reduce risk to both known and unknown assets.

X