• 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 compliance 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, SOC 2 compliance 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 assessment 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.

    Conclusion

    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.

    CloudTrail

    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:

    Conclusion

    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

    Conclusion

    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 - 8.8.8.8. 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