• 15 May 2020 11:51 | AJ Yawn (Administrator)

    Technological innovation in healthcare continues to rise as healthcare organizations take advantage of emerging technologies to deliver their services to patients. With this push for a digital healthcare experience, the healthcare startup market has skyrocketed over the past few years. According to Rock Health, digital health venture funding had a record start in 2020, with $3.1B invested early in Q1 2020. While the global pandemic has dramatically altered everyone's lives and every sector, the innovation to combat this pandemic and shift how healthcare services are delivered has been inspiring to see. 

    Healthcare organizations or HIPAA (Health Insurance Portability and Accountability Act) covered entities will continue to partner with these startups and other organizations to digitally deliver their services to patients. This partnership is captured in an agreement known as business associate agreements (BAAs) between the covered entity and the organization providing functions or activities that requires access to PHI, also known as a business associate.

    It is often misunderstood who is exactly considered a HIPAA business associate. For those organizations that are classified as a business associate, are they required to comply with HIPAA Security, Privacy and Breach Notification Rules? Does the covered entity or healthcare organization have any requirements to verify their compliance?

    I am not a lawyer, and I am not intending to give legal advice on the HIPAA law. However, I hope this article will help you better understand business associates and their role in healthcare security. Understanding the requirements associated with being a business associate will help covered entities and business associates protect themselves from HIPAA fines.


    According to the U.S. Department of Health and Human Services (HHS), a business associate is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information (PHI) on behalf of or provide services to, a covered entity.

    In simpler terms, a business associate is a vendor or subcontractor that has access to PHI. Some examples of potential business associates are:

    • Cloud service provider i.e. Amazon Web Services

    • Software companies that may be exposed to or use PHI

    • providers of data transmission services, portals, or other interfaces created on behalf of Covered Entities that allow patients to share their data with the Covered Entity

    • data storage (it does not matter if the PHI can be viewed or is encrypted

    • Law firms

    • External auditors or accountants

    • Answering Services

    • e-prescribing services

    • Marketing firms

    Healthcare-related organizations such as healthcare providers, insurance companies, pharmacies, healthcare clearinghouses, or nursing homes need business associates to provide their services. Presenting a huge opportunity for those organizations that are considered business associates to engage in business with these healthcare organizations.


    In the interconnected healthcare digital world, business associates present a significant risk to the confidentiality, integrity, and availability of PHI. This is why business associates are directly liable for certain requirements of the HIPAA Rules. A few examples of recent business associate HIPAA violations are listed below:

    • Hawaii Pacific Health experienced a breach where patient records were inappropriately accessed by a former employee of one of their partners

    • Surefile, a record storage firm, reported a Hacking/IT incident to the department of HHS that could have impacted close to 1 million records according to the individual reporting the breach

    • Interactive Medical Systems reported a Hacking/IT incident to HHS that could have impacted over 15,000 individuals

    • SOLO Laboratories reported a Hacking/IT incident of a network server that impacted over 60,000 individuals.

    As required by section 13402(e)(4) of the HITECH Act, the HHS Secretary posts a list of covered entity and business associate breaches of unsecured protected health information affecting 500 or more individuals on their breach portal here. Business associates are important because similar to covered entities they have obligations under the HIPAA law.


    The HIPAA Privacy Rule allows healthcare organizations (covered entities) to disclose PHI to business associates as long as they obtain satisfactory assurances that the business associate will use the information only for the purposes for which it was engaged by the covered entity, will safeguard the information from misuse, and will help the covered entity comply with some of the covered entity’s duties under the Privacy Rule (HHS).

    The satisfactory assurances must be in writing and are captured in a business associate agreement or BAA. BAA's are required to list the obligations of the business associate and what the business associate is agreeing to. A few examples of some of these obligations that are included in a BAA are:

    • Protecting PHI

    • Training Employees

    • Breach Notification

    • Subcontractor provisions to protect PHI

    • Return or Destroy Information

    Signing an agreement with a customer means you are now responsible to execute those obligations outlined in the agreement. Being a business associate and signing a BAA means that you are now liable for civil and criminal penalties for non-compliance with HIPAA regulations as outlined in the HIPAA Omnibus Rule and HITECH Act. HHS has published sample business associate agreement provisions to help organizations draft these contracts.

    While this sounds like a hassle and a lot of work, there are benefits to being a business associate. Pricing compliance with HIPAA Rules helps you protect your customers and your data, as well as differentiates your organization from your competitors.

    Beyond signing a BAA, organizations often undergo assessments to prove to third parties that they are compliance with the HIPAA Rules. Proving to covered entities or other third parties your compliance with HIPAA often requires a third-party to assess your organization to identify the administrative, physical and technical safeguards implemented and operating effectively at your organization. It is important to note that HIPAA is enforced by the Office of Civil Rights (OCR). HHS does not endorse a HIPAA certification or compliance assessment or firm. However, proving to the OCR or to customers that you have implemented the necessary safeguards to comply with the HIPAA Rules is best accomplished by being evaluated by an independent, third-party auditor.


    Business associates are vital components of the healthcare ecosystem assisting healthcare providers and other covered entities to deliver their critical services to patients. Healthcare technology startups, along with other business associates and covered entities, will play a huge role in helping the world recover from COVID-19. Understanding the requirements for business associates will ensure PHI is protected and organizations are protecting themselves from breaches, reputational damage, and potential legal issues.

  • 1 May 2020 07:07 | AJ Yawn (Administrator)

    In our most recent chapter meeting, I discussed AWS Security Basics. The AWS Well-Architected framework helps cloud architects and security professionals build applications that are configured according to AWS best practices. Based on five pillars — operational excellence, security, reliability, performance efficiency, and cost optimization — the Framework provides a consistent approach to build and scale applications. Please let us know what you thought about the event in this short survey that takes less than 30 seconds!

    This session we reviewed the basics of the AWS Security Pillar, specifically discussing how organizations can leverage native AWS services to implement these best practices to secure their application and ease the pain of cybersecurity audits.

    During this session, we walked through the AWS console and demonstrate a few services that can be used to reduce audit fatigue and evidence collection during assessments.

    Miami Chapter Members receive access to a hands-on Miami chapter AWS lab environment to practice these skills and validate your understanding. Join the chapter today!

  • 9 Apr 2020 16:24 | Arturo Santos (Administrator)

    First and foremost I want to wish everyone health, safety and patience during these critical times. As security professionals, we know that the best protection against any threat is not to have to face it in the first place, so it’s not hard for us to understand the urgency to maintain social distancing and follow the guidelines to help overcome the COVID-19 infection risk.

    Today I also want to share important news:

    The (ISC)2 Miami Chapter is now re-energized with new blood in the board! I’m happy to introduce our new board members:

    Frank Martinez, who has been an active member since the beginning and instrumental collaborator to help build and maintain the Chapter’s ties to Miami Dade College, and Nova Southeastern University is now the Secretary for the Chapter. Frank is a seasoned security expert, very well-known and respected in the local community.  

    Alexander (AJ) Yawn answered our call to volunteer as a board member with a very specific interest in education, when the board met him, more than his credentials and experience, it was his enthusiasm and abundance of ideas that lead an easy decision to name him the new Education Chair.

    Learn more about Frank, AJ and the board here: https://www.isc2chapter-miami.org/Board

    We had to cancel our March event, but we’ve taken the opportunity to design a new approach to our educational events in a virtual format starting on April 29, 2020 with a very current topic “AWS Security Basics for CyberSecurity Audits” , members will earn CPE’s for participation as long as they register in advance here: https://www.isc2chapter-miami.org/event-3802961

    We have also re-engaged (ISC)2 to discuss ideas to help deliver with new means and formats on the vision to inspire a safe and secure cyber world. In particular, we have an on-going conversation with the (ISC)2 Director of Education and the executives of the Profesional Development Institute, to brainstorm ideas and resources, stay tuned for news resulting from these dialogs.

    We will continue delivering events in virtual format, especially under the current circumstances, and as always your ideas and recommendations are welcome. Send them to us via email to miami.isc2chapter@gmail.com  

    Please remain safe, together we shall overcome.

    Thank you!

    Arturo Santos


    (ISC)2 Miami Chapter   

  • 1 Apr 2020 07:37 | AJ Yawn (Administrator)

    Protecting customers' data is a concern for all organizations regardless of industry or size. Most organizations outsource key aspects of their business to third-party vendors such as Software-as-a-Service (SaaS) solutions or cloud hosting providers (i.e. Amazon Web Services). As companies continue to share the responsibility of protecting sensitive data, there is increased importance and scrutiny on the cybersecurity practices implemented at these organizations.

    Third-party assessments are a common way in which organizations prove their cybersecurity practices to vendors, customers, and prospects. SOC 2 examinations have become one of the de facto standards for organizations to prove how there are securely managing their customers' data to protect their interests and privacy. For most organizations conducting business with a SaaS provider, a SOC 2 examination is a minimum requirement. SOC 2 reports are common for other service organizations as well such as law firms, marketing agencies, accounting firms, healthcare organizations, and more.

    SOC 2 is a reporting framework developed by the American Institute of Certified Professional Accountants (AICPA) intended to meet the needs of a broad range of customers or vendors that require information and assurance about the controls at a service organization relevant to the securityavailability, and processing integrity of the systems the service organization uses to process users’ data and the confidentiality and privacy of the information processed by these systems. SaaS or other service organizations utilize these reports to assist with:

    • Vendor due diligence 
    • Demonstrating security as a differentiator
    • Internal corporate governance and risk management processes
    • Proving security to a regulatory body or governing authority

    SOC 2 examinations involve a Certified Professional Accounting (CPA) firm assessing an organization's information security and privacy control environment. The assessment includes a description of the controls, the tests performed to assess them, and the results of these tests.

    Trust Services Categories

    One of the first decisions an organization has to make when pursuing a SOC 2 examination is which Trust Services Categories (TSC) will be in scope. These five categories outline the controls and topics the service organization will be evaluated against. In a SOC 2 examination, all organizations must include the Security TSC whereas the availability, processing integrity, confidentiality, and privacy TSCs are optional. The TSCs are described below:

    Security. Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity's ability to meet its objectives.

    Availability. Information and systems are available for operation and use to meet the entity's objectives.

    Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives.

    Confidentiality. Information designated as confidential is protected to meet the entity's objectives.

    Privacy. Personal information is collected, used, retained, disclosed, and disposed of to meet the entity's objectives.

    Types of SOC 2 Reports

    In a SOC 2 examination, organizations can undergo a SOC 2 Type 1 or SOC 2 Type 2 examination. A Type 1 examination is a report on the controls at a service organization at a specific point in time, whereas, a Type 2 examination is a report on the controls at a service organization over a period of time. The period of time evaluated in a SOC 2 Type 2 examination is typically between 3-12 months.

    How often are these examinations performed?

    A SOC 2 Type 1 examination is generally only performed once. The common scenario for Type 1 examinations is when organizations are undergoing the SOC 2 process for the first time and need a SOC 2 report as soon as possible. After the Type 1 is completed, the Type 2 reporting period immediately begins. For example, if an organizations' Type 1 report has a report date of December 31, 2019, the Type 2 reporting period would begin January 1. A SOC 2 Type 2 examination is an annual activity for organizations.


    Potential and existing customers want to know that organizations have taken all necessary measures to protect the sensitive data processed by the service. SOC 2 examinations, facilitated by an independent CPA firm, enable the service organization to demonstrate the safeguards in place that are relevant to the security, availability, processing integrity of the systems used to process sensitive data and the confidentiality and privacy safeguards in place to protect the data. These reports allow organizations to demonstrate security as a differentiator, accelerate the vendor due diligence process by undergoing one audit to respond to multiple customer requests and, most importantly, assess the information security risks your organization is facing.

  • 26 Mar 2020 09:00 | AJ Yawn (Administrator)

    This blog post was originally published on the ISC2 National Blog here.

    Amazon Web Services (AWS) is the industry-leading cloud service provider by any metric you can find doing a quick google search. The shared responsibility model is generally understood by individuals managing production workloads that are hosted on AWS and *most* auditors understand how this impacts a SOC 2 or other compliance assessment. AWS has developed several services and features to help manage the security of an organizations’ AWS account and resources. These services, when used effectively, can reduce evidence requirements, reduce or eliminate the risk of auditor findings, and most importantly secure your AWS account. These basic security configurations should be implemented for every organization hosted on AWS regardless of organizational maturity, industry or type. Following these below recommendations will also reduce evidence requirements and documentation for your SOC 2 audit. Auditors can leverage the reports, configuration screenshots, IAM policies, etc. to satisfy several controls. Reducing the operational disruption of your organization and the time it takes to achieve compliance. The below recommendations will result in a more secure AWS account and resources, reduction of time (and hopefully cost) of your SOC 2 examination and allows you to include some unique security controls in your SOC 2 report to differentiate yourself from your competitors.

    The Basics

    Secure your root account

    The root account on your AWS account has unlimited access to perform unlimited functions within your AWS account. It is not recommend to use your root account for daily functions, there are very few functions that require you to use your root account (familiarize yourself with these tasks). Securing and minimizing the use of this account is vital to securing your AWS account and resources. Your auditor will (should) ask you to prove that you have secured that account, here are a few recommendations to secure your root account:

    • If you haven't, create an IAM user with administrative access and stop using your root account. 

    • Enable MFA on the AWS Account Root User

    • Delete the root account access keys

    • Change the password and store in a password vault with limited access

    • Enable AWS CloudTrail and configure alerts to notify administrators when the root account is utilized 

    • Add custom controls to your SOC 2 report to differentiate yourself from your competitors.

    Utilize AWS Trusted Advisor

    AWS Trusted Advisor provides real-time insight into your AWS account and resources to assist with ensuring your following AWS best practices. This insight includes many security checks that highlight critical security risks that you should be monitored regularly. Here are a few recommendations to utilzie AWS Trusted Advisor:

    • Ensure AWS Trusted Advisor is enabled

    • Configure weekly updated results emails for Trusted Advisor checks

    • Review Trusted Advisor checks for accuracy and implement changes to correct any identified issues (i.e. Trusted Advisor checks if MFA is enabled on your root account)

    • Provide Trusted Advisor security reports to your SOC 2 auditors to reduce evidence requirements by 25%

    • Add custom controls to your SOC 2 report to differentiate yourself from your competitors.

    Identity & Access Management (IAM) Credential Report

    The IAM credential report is a great resource to view the status of all users within your account, including the status of MFA configurations, passwords, and access key rotation. This report is a treasure trove of information for a SOC 2 auditor. The days of capturing an obscene amount of screenshots of your IAM user are long gone. The below recommendations outline a few ways you should use this report:

    • Review the IAM credential report on a regular (at least quarterly) basis and document the results of your review

    • Provide the IAM Credential Report to your SOC 2 auditors to reduce evidence requirements by at least 10%

    • Implement changes to correct any identified issues (i.e. a user not rotating their access keys in 2 years)

    • Add custom controls to your SOC 2 report to differentiate yourself from your competitors.

    Implement Force MFA

    The theme of the annual RSA conference this year was Human Element. Humans will always be an integral aspect of a cybersecurity program, despite the advancements we have made in technology. However, humans oftentimes make mistakes. Configuring MFA on AWS is simple for each user however, disabling MFA is also fairly simple for each user. This human aspect of removing MFA has caused significant findings in compliance assessments I have performed for some of the largest companies in the world. Implementing a “Force MFA” IAM policy will help eliminate this risk of humans being human, this IAM policy requires users to set up and maintain their own MFA devices and prevents them from accessing any AWS resources until they authenticate with MFA. Essentially, users can only enable MFA when their account is created and cannot access any other resources within AWS until MFA is enabled and utilized. Here are some recommendations to consider when implementing a force MFA policy:

    • Configure the Force MFA policy according to AWS recommendations

    • Enable AWS CloudTrail and configure alerts to notify administrators when MFA is disabled for any user

    • Add custom controls to your SOC 2 report to differentiate yourself from your competitors.


    AWS CloudTrail allows you to audit, continuously monitor, and assess account activity taken through the AWS Management Console, AWS SDKs, command-line tools, and other services. This tool is valuable for audits but also for ongoing event-driven security. Enabling AWS CloudTrail is a minimum security requirement for any . environment, consider the following recommendations when configuring CloudTrail:


    These recommendations describe how you can utilize native services within your AWS account to secure your resources and reduce audit fatigue during an SOC 2 examination. Leveraging these strategies are the bare minimum you should implement when operating a production environment on AWS. AWS makes it easy for administrators to implement these strategies and utilize to provide auditors with less evidence that is technically accurate and provides deeper assurances regarding the compliance of your account and resources.

  • 4 Mar 2020 06:56 | AJ Yawn (Administrator)

    This blog post was originally published on HackerNoon here.

    “Hey, can you meet with our SOC 2 auditors’ for a couple of hours next week to talk about our SDLC process?” Oh no! This question continually causes heartburn and eventual headachesfor software engineers. Spending multiple hours in a conference room explaining to auditors how your team deploys changes, what a pull request is and explaining how infrastructure as code works is not how engineers would describe a productive afternoon.

    What is SOC 2 and why does this impact engineers?

    SOC 2 (or other regulatory frameworks) examinations are not going anywhere, they have become the cost of doing business for technology-enabled service organizations that provide SaaS or other services that interact with, store or transmit their customers’ sensitive information. These examinations assist organizations with proving to current and potential customers how they are securing their data. The software development process is an integral aspect of SOC 2 examinations. Every SOC 2 examination regardless of in-scope Trust Services Categories or organization type, requires an evaluation of the change management processes and procedures. Often this means spending countless hours retrieving evidence of changes and answering questions about your DevOps process with internal compliance personnel and external auditors. During a SOC 2 examination, auditors are concerned with a few specific attributes related to each software change:

    1. Is there formal documentation (comments on the PR, Jira ticket, etc.)?
    2. Was the change tested?
    3. Were there any reviews of the change or PR?
    4. Was this change approved?

    These questions sound like they create significant obstructions to collaboration, and speed, which is essential in a DevOps environment. However, there is a way to maintain a healthy, secure codebase while also encouraging collaboration and adherence to compliance requirements. 

    Protected Branches

    Enabling protected branches and implementing native security policies on these branches will make these audit experiences tolerable and less painful. GitHub is one of the more common software development platforms in the industry, this article will focus on GitHub protected branch configurations however these same theories can be applied to other software development platforms. GitHub defines protected branches in the following manner, “Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.” Protecting a branch eliminates the risk of a planned or unplanned catastrophic event where a branch is deleted. This is the first step in enabling guardrails to secure your branch. Some additional checks or requirements can be enabled with a protected branch to configure security policies are described below:

    Recommended optional checks and requirement configurations on protected branches

    Require status checks to pass before merging

    • This check requires that all continuous integration (CI) checks to pass before branches can be merged into the protected branch
    • CI tools such as CircleCI, Jenkins or Travis integrate with GitHub and can provide a status check update on each prospective change
    • Reduce evidence requirements for the SOC 2 audit by utilizing this configuration to display testing requirements for each change

    Require pull request reviews before merging

    • Code reviews are important for any development life cycle, this check requires at least one approved review before a pull request is merged. 
    • This check also establishes separation of duties by preventing an engineer from merging their pull requests without a secondary review
    • Reduce evidence requirements for the SOC 2 audit by utilizing this configuration to display review requirements for each change

    Require review from Code Owners

    • Require approval from a predetermined set of users (or owners) that must approve the change before a pull request is merged
    • Reduce evidence requirements for the SOC 2 audit by utilizing this configuration to display approval requirements for each change


    Security and compliance can no longer be an afterthought for DevOps teams. Integrating security configurations into the software deployment pipeline will allow developers to bake software security in every stage of the process. Compliance assessments like SOC 2 or PCI-DSS are inevitably going to impact your development team and process. Enabling native configurations to systematically enforce these security requirements will make these compliance assessments easier to obtain, maintain, and hopefully make those conversations with auditors a little shorter and less complex for all parties involved.

  • 29 Mar 2019 21:18 | David Capote (Administrator)

    There are 27 Key things you can do today that will strengthen your personal Cyber Security Defenses.

    1. Always patch your operating system and all applications on all devices, workstations, laptops, tablets, Cell Phones.
    2. Use strong passwords
    3. Don’t reuse passwords. Keep unique passwords for each site or application.
    4. Use 2 Factor Authentication.
    5. Encrypt your computers. You can use Vera crypt, Symantec PGP, Bit locker. Full Disk Encryption is what you need in case your device is compromised.
    6. Use a BIOS Password. That prevents someone from loading a boot-able Linux distribution disk and reading all of the data off your hard drive.
    7. Use a VPN.
    8. Delete any old emails especially if the information is sensitive.
    9. Physical security is important, don’t leave your computers unattended.
    10. Be careful when opening attachments and only open emails from known or trusted senders.
    11. Do not enable macros on any documents opened in an email. Open the document in protected view.
    12. Don’t send sensitive information electronically unless you can verify who the sender that is requesting it is.
    13. Use a static DNS Server entry for example you can use Googles DNS Servers - This will help prevent browser hijacking sessions and browser redirects.
    14. Use HTTPS whenever possible and if the site you are going to has an invalid or corrupt security certificate it’s best not to go to that site.
    15. Use updated antivirus and anti-malware programs and run regular scans.
    16. Don’t provide too much personal information in your online profiles in LinkedIn or Facebook or any online sites.
    17. Limit the amount of personal information you give out, for example avoid giving out your address or phone number if not needed.
    18. Don’t visit unfamiliar sites.
    19. Be careful when typing in the URL, if you are not sure, then do a google search for the exact URL as some sites take advantage and prey on typo squatting techniques.
    20. Try to use Chrome instead of Firefox or IE. It can have better security. This is a personal preference though.
    21. Make regular online or cloud based backups of your data.
    22. Don’t install unnecessary software on your computer.
    23. Disable unnecessary services.
    24. Don’t login to your computer as a local admin, login as a standard user.
    25. Use strong passwords on your router and disable remote administration of your router, update the firmware on your router, change the default SSID of your home wireless network and set the SSID to not broadcast.
    26. Don’t give your credentials to anyone. If a visitor, friend or relative need to use your computer setup a temporary account with a strong password NOT The same password you are using for your login of course!
    27. Don’t write down your password anywhere.

    © 2019 (ISC)2 Miami Chapter

      Powered by Wild Apricot Membership Software