Tag: Compliance

  • SOC 2 Compliance: Is it Right for Your Organization?

    What it Means to be SOC 2 Compliant

    AICPA (the American Institute of Certified Public Accountants) developed the SOC 2 (System and Organization Controls) framework in 2010 to provide guidance for evaluating the operating effectiveness of an organization’s security protocols, especially within cloud environments.

    SOC 2 is a compliance and privacy standard that outlines how organizations should manage customer data and related systems to ensure confidentiality, integrity, and availability.

    SOC 2 defines five Trust Services Criteria (TSC) that evaluate various aspects of information security and governance. The first, security, must be a part of any SOC 2 audit, and organizations can choose to include other trust services categories. Organizations tailor their SOC 2 audits based on their specific needs and the services they provide.

    1. Security: Ensures protection against unauthorized access, breaches, and other security incidents by assessing the effectiveness of controls related to data protection, access, and system security.
    2. Availability: Ensures systems are available for use as needed by examining whether the service is available as promised and whether any planned or unplanned downtime occurs.
    3. Processing Integrity: Ensures accurate and complete processing of data as well timeliness and consistently of data processing.
    4. Confidentiality: Ensures data confidentiality by examining data encryption, access restrictions, and confidentiality agreements.
    5. Privacy: Ensures compliance with privacy regulations for personal information.

    Customizing SOC 2 Controls to Best Fit Your Organization

    Organizations design their own internal controls to meet these requirements, as needs and controls are unique to each organization. It’s common for organizations to use a service or consulting company, such as Raxis’ partner Strike Graph, to help them understand the different controls, to assess which are relevant for the organization’s systems and services, and to ensure that they have fulfilled the controls properly before an audit takes place.

    Many organizations focus entirely on the Security TSC, also known as the common criteria, for their SOC 2 audits. The common criteria are required for all SOC 2 audits. These are the areas of focus, created in 2017 and revised in 2022:

    • CC1: Control Environment
    • CC2: Communication and Information
    • CC3: Risk Assessment
    • CC4: Monitoring Activities
    • CC5: Control Activities
    • CC6: Logical and Physical Access Controls
    • CC7: System Operations
    • CC8: Change Management
    • CC9: Risk Mitigation

    During the SOC 2 audit, an independent auditor evaluates the organization’s security posture related to the selected Trust Services Criteria. Organizations provide evidence for the controls they have in place, and, if auditors feel there are deficiencies, organizations can choose to remedy those during the audit or to explain why they accept the risk.

    SOC 2 Type 1 versus SOC 2 Type 2

    While Type 1 provides a foundational layer regarding the control design for the organization, Type 2 offers a comprehensive view of control effectiveness over time. Type 1 is the first step in annual SOC 2 compliance. Organizations can choose to combine Type 1 and Type 2 during their first SOC 2 audit or to become Type 1 compliant the first year and then move on to Type 2 in subsequent years.

    SOC 2 Type 1 evaluates an organization’s cybersecurity controls for their effectiveness at safeguarding customer data at a specific point in time, while Type 2 examines how well the organization’s system and controls actually perform over a period of time (often 3-12 months).

    Compliance Checkmark

    Raxis, for example decided to focus on SOC 2 Type 1 in our first year of compliance so that our team had the time to focus on building out the necessary controls in the most robust manner possible that matched our systems and services. SOC 2 allows organizations (to a certain extent) to setup their controls with as much simplicity or complexity as they see fit. As security is integral to every part of Raxis’ business and goals, our aim in choosing to become SOC 2 compliant was to take the time to build the controls out to best protect the data entrusted to us.

    Honestly, we discovered that we could not discover the best way to implement our controls without building out and testing the systems themselves. In the end, we could have performed our SOC 2 Type 2 audit in 2023 as well, but with the busy end-of-year penetration testing season, we decided to complete our first SOC 2 Type 2 compliance audit this April, covering this past winter and spring.

    How Does Penetration Testing Relate to SOC 2 Compliance

    SOC 2 compliance is essential for demonstrating your commitment to data protection, while penetration testing provides an extra layer of security by identifying vulnerabilities so that your organization can correct them before they are exploited.

    But there’s more… SOC 2 compliance often requires a penetration test (and a retest of critical and severe findings) as one of the controls in order to show that organizations successfully monitor and correct/mitigate security risks to their systems.

    Raxis often performs SOC 2 penetration tests for our customers and is proud to work with SOC 2 partners to perform penetration tests for their customers as part of their framework offerings. Tailoring your penetration test to your specific needs and goals is an important first step in scoping any test.

    Why Choose to Become SOC 2 Compliant?

    While not yet required, SOC 2 compliance helps establish trust between service providers and their customers. With high-profile data breaches becoming more common, many organizations, like Raxis, choose to become SOC 2 compliant both as an exercise to ensure the security controls they’ve created are robust and also to ensure the controls are updated as the threat landscape changes over time.

    SOC 2 compliance is audited annually, ensuring that both the organization’s controls themselves and their implementation are tested regularly to ensure that new risks are accounted for and that security policies and procedures do not become stale. SOC 2 compliance ensures that organizations handle customer data securely and transparently, meeting specific criteria for trust and protection.

  • Raxis Achieves SOC 2 Type 2 Compliance

    We are thrilled to announce that Raxis has successfully achieved SOC 2 Type 2 compliance. This milestone underscores our commitment to maintaining effective security controls over our information systems and the penetration testing and cybersecurity services we offer.

    Our SOC 2 compliance provides assurance to our clients that their data is handled securely and in accordance with industry best practices. We remain committed to maintaining the highest level of security and privacy, and we will continue to invest in our compliance program to stay ahead of evolving threats.

    We remain dedicated to providing a secure platform and services for our clients. We are pleased to provide our SOC 2 Type 2 report to current customers and prospective customers under NDA. Contact our team for more information.

  • Cybersecurity in the Financial Sector: Regulations are Approaching Reality

    After years of development and public input, the Federal Trade Commission (FTC) in December finalized some changes to the Standards for Safeguarding Customer Information (Safeguards) Rule – a key part of the Gramm-Leach-Bliley Act (GLBA).

    Of the four major rule changes, one simply adds a new category of business under the definition of “financial institution,” another exempts institutions that serve fewer than 5,000 people, and a third standardizes some terminology across agencies.

    Though all of these are important for various reasons, the most significant changes from Raxis’ perspective are the ones that more clearly define the elements of the information security programs required by GLBA and which ensure better accountability for implementing and testing such programs.

    The Problems

    In the past, the federal government was reluctant to be overly prescriptive with its cybersecurity requirements. The prevailing mindset was that doing so would mean compliance would happen by “magic” – in this case, meaning mindless activities guaranteed to inspire complacency. Flexibility was necessary to ensure that institutions were free to adopt the practices that ensured the best protection for their company or niche.

    The reality we’ve witnessed during more than a decade of Raxis penetration testing is that the level of cybersecurity awareness and sophistication can vary wildly among financial institutions, regardless of size or business model. Ambiguity in the regulations allowed a patchwork of cybersecurity measures to emerge under the general umbrella of compliance. It was clear to our team that the Safeguards Rule needed to be more specific to make sure all the institutions were implementing the most basic best practices.

    Lack of specificity in the prior iterations of the rules also made it harder for regulators and the institutions themselves to know whether their infosec programs were effective. Along with more specifics, the institutions needed stronger accountability measures.

    The Improvements

    Toward the goal of greater accountability, the Safeguards Rule added two important provisions: Designation of a single “qualified individual” to act as a de facto chief information security officer (CISO) to manage the infosec program and a requirement that he or she report to the company’s board. Most institutions have those functions covered in some form or fashion, but we’ve seen instances where responsibilities were split among employees and even departments.

    Having a qualified infosec leader in place is a good first step toward consolidating authority, but more important is how well and how quickly the institutions adopt the following changes to the Safeguards Rule:

    • Review of access controls. This change requires institutions to regularly test digital and physical access to customer data to make sure only authorized personnel can see it – and see only the parts of it that are necessary to do their jobs. If a Raxis team member successfully breaches your network during a test, you can bet we will check to see if you’ve followed the principle of least privileged access.
    • Inventory of key data and systems. The inventory process ensures that institutions know what they are protecting with their infosec program. As we discussed in a prior post, it’s not always obvious what data and what systems are at risk.
    • Intrusion detection. This change makes annual pentesting and semi-annual vulnerability assessments a requirement for companies that don’t have continuous monitoring of their networks. Raxis offers all the services described above, but we don’t believe they should be presented as either/or choices. Continuous monitoring or vulnerability assessments should trigger a pentest if serious vulnerabilities are discovered.
    • Secure application development. With this rule change, the FTC outlines some best security practices for in-house and third-party app development. As we explained in some recent posts, public-facing web applications face some unique security challenges, and it’s good that the FTC understands the seriousness of that issue.
    • Incident response planning. This update simply requires that institutions develop written plans for responding to security incidents and includes information about what those plans should cover.
    • Encryption requirement. This may seem like a no-brainer, but the Safeguards Rule now requires encryption of data in transit and at rest. But it also provides for the ability of the “qualified individual” to authorize an acceptable alternative if encryption isn’t feasible.
    • Multifactor authentication (MFA) requirement. Again, this would appear to be table stakes for a financial institution, but based on Raxis’ experience, it has not been adopted nearly as widely as it should have been already. The rule change, we hope, will make MFA a standard practice industrywide.
    • Change management procedures outline the steps financial institutions should take when they alter their infosec programs. As a security measure, this ensures such changes are documented and approved beforehand.

    This is just a snapshot of what Raxis considers the FTC’s most impactful changes to the GLBA Safeguards Rule. Like all such regulations, they should all be viewed by the institutions as minimum guidelines, not as a safe harbor or assurance of security. Similarly, regulators should judge compliance not by whether the boxes have been checked, but by how thoroughly the institutions have prepared themselves for the attacks that are coming.

    There is no finish line in cybersecurity, but these changes will give all US financial institutions a head start on better protection for their customers.

    To read the full Safeguards Rule as finalized, be sure to visit the Federal Register.

  • What Companies Should be Telling Investors about Cybersecurity

    As a customer, how much do you know about how major corporations handle your personal data? If you’re a shareholder in a company (or several), do you have any idea how well it is prepared for a cyberattack? What is the company protocol for publicizing a security breach?

    For the vast majority of Americans, the likely answer is no on all counts. And here’s the worst part: You won’t find out by reading their official filings with the Securities and Exchange Commission (SEC) or hear the topic come up on a quarterly earnings call.

    A recent study confirmed what a lot of us have known for a while – a lot of publicly traded companies still refuse to reveal the true nature of the threats they face and what they’re doing to mitigate them. Despite increasing pressure from the SEC, the report suggests that most would greatly prefer to stay silent, even after a breach has occurred.

    The report was assembled by the National Association of Corporate Directors (NACD), Security Scorecard, Cyber Threat Alliance, Diligent, and IHSMarkit. These organizations and companies are arguing for more cybersecurity transparency. In my view, this action is long overdue as ransomware and other serious threats grow in both frequency and severity, according to the authors.

    To be clear, as a CEO, I understand why some corporations worry they’ll face a competitive disadvantage if they are too forthcoming about risk. As a professional penetration tester (ethical hacker), I also appreciate their concerns about giving the bad guys in my line of work information that might be exploited or even help cybercriminals better understand the value of data they’ve stolen.

    On the other hand, I am also an investor and a customer. Wearing all these hats makes me frustrated that the government and Corporate America haven’t come up with a solution that puts everyone on a level playing field – including the people who are shouldering much of that risk in the form of their investments.

    In my view, that solution could be as simple as providing answers to three simple questions that would help me, as an investor or potential investor, decide whether to put my money on the table.

    • First, what assets do you have that are most at risk from a cyberattack? This might be intellectual property that can be stolen, customers’ personal information, the money in your corporate bank account, or all of the above and more. And it should address the potential impacts on upstream and downstream vendors and customers. The most important issue here is knowing that the company understands what it has to lose.
    • The next question follows logically: What are you doing to protect those assets? This doesn’t have to be a laundry list that describes each security layer in detail, but it should give readers a sense that the security is appropriate to stop the types of threats it anticipates. Again, what I really want to know is that the company is doing what’s necessary, not just providing a generic response that restates the question.
    • The third and perhaps most important question is whether the security has been evaluated and validated by experts outside the company. Former President Ronald Reagan famously described his policy toward the Soviet Union as “trust but verify” and that’s appropriate in the world of cybersecurity as well. Though we have to trust companies to be candid and truthful, there is a lot of value in having professional third parties provide independent analyses.

    Simply answering these questions is no guarantee that the company won’t be breached, but there is great value in the asking. For one, it keeps cybersecurity top-of-mind in the c-suites, ensuring that it factors into all major company decisions. It also gives policy makers a clear idea about our nation’s cyber resilience and exposes major shortcomings that can be addressed with legislation or regulation. And it provides peace of mind for people who are considering placing their hard-earned money in the company’s hands.

    In the wake of the far-reaching SolarWinds and Colonial Pipeline breaches, now is an excellent time to ask Congress and the SEC to work with publicly traded companies to find a workable disclosure template that better protects all of us.

  • What You Need to Know (But Were Afraid to Ask) about Raxis Web App Testing

     What’s special about a Raxis web app test?

    One thing that sets Raxis apart is that our pentesting team is made up of engineers who performed varying roles creating and supporting IT systems before they became pentesters. This includes several engineers who have strong backgrounds in software and web development.

    Even better, Raxis is proud to have a close-knit team of pentesters who collaborate and share their ever-growing knowledge with each other and with our customers. You may have a former web developer performing your test, and that person can easily reach out to a former network admin. They can share info about the most secure web app features as well as how the supporting network should be configured securely..

    Our customers repeatedly tell us how much they appreciate this because it directly translates to relevant, actionable findings. It also encourages natural conversation between their development teams and the security engineers here at Raxis.

    How does this collaboration help customers?

    A recent test we conducted provides a great example: We identified several findings, and the customer was very pleased with the process. Upon follow-up, our sales team found out that the customer saw a small performance reduction after implementing our recommendations. From the customer’s perspective, enhanced security was worth the small drop in performance.

    Because of our development background, however, Raxis’ team members knew that didn’t have to be the case. Our project manager proactively set up a call with the customer to discuss. Result: The customer remediated using Raxis’ advice and regained all of the original performance. They told us they appreciated how Raxis “went the extra mile.”

    To us, that’s just business as usual.

    How many application tests do we do?

    Customers often ask about our application testing process. Application testing accounts for over 50% of our penetration tests. Last year, we performed over 600 application tests. Like all of our assessments, each test is custom tailored to the customer’s application and overall objectives. This could mean testing the entire app, a portion of the app, or following the app throughout the entire development cycle.

    What is your methodology?

    Like all of our assessments, our application tests are primarily manual attack simulations against a customer’s application. Where you see an email field, we see an opportunity for cross-site scripting. Aside from our own experience and expertise, Raxis applies the OWASP framework to our penetration testing, including (though, of course not limited to) the following assessment categories:

    • Access Control
    • Authorization and Authentication
    • Session Management
    • Configuration Management
    • Error Handling
    • Sensitive Data Exposure
    • Input Validation, Injection and Cross-Site Scripting
    • Root Cause Analysis / Reporting
    So, what do I get out of this?

    At the end of a Raxis application assessment you get peace of mind and a solid deliverable. Our reports align with the NIST standard, so they meet regulatory compliance standards. The reports feature an executive summary, engagement storyboard (where applicable), and detailed vulnerability findings that include screenshots, risk explanations, remediation recommendation, and risk scoring.

    Is your web app security keeping you awake at night?

    We understand. Just as we are known for excellence in pen testing, we’re also known for our no-pressure sales and scoping process. We get it. We don’t like to be harassed, and we know you don’t either. If you’d like to start a conversation with one of our experts to help understand the possibilities for your project, feel free to reach out. We’d love to help.