Sigstr helps the world’s best marketers do amazing things with their employees’ emails. The average person spends 6.3 hours in their inbox every day. Sigstr gives marketers the ability to serve targeted ads to their audience where they’re spending the majority of their time: the inbox. This connectivity between Sigstr and email clients presents information security risks that Sigstr must address. We sat down with Brent Mackay, Director of Product Management and Data Protection Officer at Sigstr, to discuss what their team learned through the SOC 2 audit process and how it gives Sigstr a competitive edge in the email and marketing application space.

The Need for SOC 2

What information security risks face email applications? Generally, we see spam, phishing, and malware. According to Symantec, in 2018, Microsoft Office files accounted for almost half of all malicious email attachments. 1 in 10 URLs sent in emails are malicious. Each hacked email account is worth between $5 and $10. Those types of risks led to Sigstr going above and beyond to ensure that their service will not leave a vulnerability open to unauthorized access. Sigstr knows that employee email is incredibly sensitive, which is why they decided to pursue SOC 2 Type I and Type II attestations.

Mackay comments, “At the beginning of 2019, we announced Sigstr’s SOC 2 Type I attestation with a commitment to continue moving our security program forward. In August, we announced the SOC 2 Type II attestation. An important part of SOC 2 compliance is the ongoing adherence and improvements made to security systems and processes. The standards for SOC 2 shift as the tech ecosystem changes and ongoing improvements to controls are needed in order to stay up to date. Sigstr plans on annual SOC 2 Type II audits as a mission for customers to have confidence that their data is safe with us.”

Information security and compliance have two-fold importance to Sigstr. To keep their applications safe from unauthorized access and maintain uptime, they have to be the best of the best – and compliance helps raise the bar. It’s also important to the growth of Sigstr’s business, aiding them in closing deals with enterprise-level organizations who demand that their vendors be held to a high standard of security and compliance.

Lessons Learned from the SOC 2 Audit Process

After gaining Type I and II attestations, Sigstr felt as though the SOC 2 audits were definitely worth the time, effort, and cost. Mackay says, “Going through the SOC 2 audit process is exciting and challenging. Since this was the first set of SOC 2 audits that Sigstr had gone through, there was somewhat of a fear of the unknown. KirkpatrickPrice did a great job to help us prepare and we are very glad to have gone through the process.”

The Sigstr team learned a lot along the way about how to be in a position to better secure customers’ email data. Mackay explained that their team had three main takeaways after going through the SOC 2 audit process, which includes:

  1. Before going into a SOC 2 audit, it’s important to research what it entails and then measure your company’s preparedness. There are dozens of controls and policies that need to be in place prior to starting the audit, and it would be daunting to try to write and implement them during an audit. An easy place to start is to document the processes and controls you currently have in place.
  2. It is easy to underestimate the time the audit will take end to end. Audit timelines will vary based on your company size and scope of the engagement, but at Sigstr, we learned that it is a full-time job for a few people for approximately three months. We prepared our security team to allocate their time appropriately since the majority of the work was on them.
  3. When going through the process of creating controls and policies to govern your information security program, it can be very tempting to embellish and add aspirational controls. This can come around to bite you because controls that you put into policies will be audited. Whatever you put into a policy, you will be asked to furnish evidence of that during your Type I and Type II audits. If you fail to do so, it will show up as an exception on your report. We followed a simple mindset of “do what you say and say what you do.”

Competitive Advantage Gained from SOC 2

Sigstr is the only company in their space that has gone through a SOC 2 audit – and they didn’t just go through the Type I. They completed both Type I and Type II within a year. That alone is a competitive advantage, but furthermore, Sigstr’s SOC 2 audits were measured against all five Trust Services Criteria. We see most organizations choose between one and three, so this choice shows Sigstr’s incredible commitment to securing the email data that they are responsible for.

Having a SOC 2 Type II report readily available has also helped Sigstr accelerate the vendor approval process with many of their customers. Without a SOC report, the vendor approval process can take much longer, and potentially lose the opportunity to do business with larger customers.

Sigstr’s compliance journey can teach others how valuable an information security audit can be – for your processes, your technology, your people, and your clients. Want to learn about how your organization could tackle the SOC 2 journey? Contact us today.

More About Sigstr

Sigstr makes employee email your new favorite ad channel. Run hundreds of simultaneous banners to intelligently target your audience by industry, geography, or opportunity stage. Gain deep account-based insights and buyer intent data based on the real relationships your team develops (all from email and calendar patterns). In addition to standardizing email signatures, Sigstr turns every email your employees send into a marketing campaign.

More SOC 2 Resources

SOC 2 Academy

SOC 2 Compliance Checklist

Was the Audit Worth It?

On October 10, 2019, the California Attorney General released the much-anticipated California Consumer Privacy Act (CCPA) proposed regulations – providing some clarity to the strict data privacy law. The proposed regulations were divided into four key areas: notices to consumers, consumer requests, verification requirements, and special considerations for minors. What do you need to know about these regulations? How will they impact your organization’s CCPA compliance efforts? Let’s discuss.

CCPA Proposed Regulations: An Overview

1. Notices to Consumers

One of the key initiatives behind CCPA is giving consumers more autonomy over what happens to their personal information. In order to ensure that this happens, the Attorney General gave more direction on the types of notices businesses must give to consumers. To comply with CCPA, companies must provide notice of the following:

  • Notice at Collection of Personal Information
  • Notice of Right to Opt-Out of Sale of Personal Information
  • Notice of Financial Incentive
  • Privacy Policy

In addition, according to the proposed regulations, each of the required notices must adhere to the following criteria:

  • Use plain, straightforward language and avoid technical or legal jargon.
  • Use a format that draws the consumer’s attention to the notice and makes the notice readable, including on smaller screens, if applicable.
  • Be available in the languages that the business, in its ordinary course, provides contracts, disclaimers, sale announcements, and other information to consumers.
  • Be accessible to consumers with disabilities; at a minimum, provide information on how a consumer with a disability may access the notice in an alternative format.
  • Be available online or at a physical location where consumers will see it before opting into the financial incentive or price or service difference.

2. Consumer Requests

Businesses must also be sure to include methods for consumers to submit requests about their personal information. According to the regulations, entities must:

  • Have at least two methods for consumers to request to know and/or delete their personal information. This might include a toll-free number, an online form, an email address, or a form submitted through mail.
  • Take into consideration the primary way it interacts with consumers when deciding which methods to collect consumer requests. For example, if an organization conducts most of its business online, then an online form and a toll-free number would be appropriate. On the contrary, if a business primarily interacts with consumers online and in person, three methods to collect would be necessary (i.e. an online form, a form to be mailed, and a toll-free number).
  • Confirm receipt of consumer requests to know and/or delete within 10 days and respond to consumer requests to know and/or delete within 45 days – beginning on the day in which the request is submitted.
  • Use a two-step process for online requests to delete where the consumer must first, clearly submit the request to delete and then second, separately confirm that they want their personal information deleted.

3. Verification Requirements

While consumers will have greater control over what happens to their personal information under CCPA, the Attorney General made it clear that businesses are responsible for verifying the identity of all persons requesting to know or delete their data. The regulations provide verification requirements for password-protected accounts, non-account holders, and authorized agents. It also gives general guidance for verifying consumers’ identities, including:

  • Establish and document a reasonable method for verifying the identity of consumers requesting to know and/or delete personal information.
  • Use the personal information already collected about consumers to match with verifying information. Businesses should avoid collecting any new personal information, when feasible.
  • Implement reasonable measures to detect fraudulent identify-verification activity.

4. Special Considerations for Minors

According to KirkpatrickPrice Director of Regulatory Compliance and data privacy expert, Mark Hinely, organizations who process the personal information of minors should pay close attention to the Attorney General’s proposed regulations.

  • When processing the data of minors younger than 13, organizations must establish and document a reasonable method for determining the identity of the parent or guardian of the child authorizing the sale of the personal information.
  • When processing the data of minors between 13 and 16, organizations must establish and document a reasonable method for 13-to-16-year-olds to opt-in to the sale of their personal information. Those in this age range must also be reminded of their right to opt-out to the sale of their personal information at a later date.

With CCPA enforcement only two months away, are you sure your organization adheres to these updates? These regulations are bound to change over the next few months, and it’s imperative that you stay on top of the latest updates if your business is required to comply with the data privacy law. Let KirkpatrickPrice help keep you updated – subscribe to our blog or contact us today to speak to one of our data privacy experts about how we can partner with you to ensure compliance with these regulations and conquer CCPA.

More CCPA Resources

5 Facts to Know About CCPA

Privacy Policies Built for CCPA Compliance

Preparing for CCPA: 4 Data Privacy Best Practices to Follow

California Consumer Privacy Act vs. GDPR: What Your Business Needs to Know

In October 2019, Citizen Times reported that Mission Health, North Carolina’s sixth-largest health system and HCA Healthcare’s North Carolina Division, had disclosed a data breach caused by a cross-site scripting (XSS) attack.

Cross-site scripting (XSS) vulnerabilities rank among OWASP’s top 10 web application security risks. XXS occurs when a web application doesn’t properly sanitize user input and their input (such as malicious code) is either reflected or stored on the returned page. The best way to combat the dangers of XSS vulnerabilities is to perform code review before the application goes into production.

This attack, which injected malicious scripts into Mission Health’s e-commerce web application, wasn’t found for three years. Fortunately, the e-commerce site didn’t impact any PHI, but three years’ worth of names, addresses, payment card numbers, expiration dates, and CVV codes were sent to unauthorized individuals.

Can you imagine if this XSS attack targeted a web application that touched PHI? Could code review have found this XSS flaw? Would penetration testing have helped? This data breach is just one more example of the added precautions healthcare organizations must take to identify all areas of risk and implement cybersecurity best practices, even if they have to go beyond HIPAA requirements.

Cybersecurity in Healthcare

The amount of data breaches that occur within healthcare prove it to be an industry that isn’t keeping up with the cybersecurity threat landscape. According to IBM’s 2019 Cost of a Data Breach Report, the healthcare industry has the most expensive data breaches – the average totaling $6.45 million.

What makes data breaches even more expensive? Time. The time it takes to find the breach and the time it takes to contain and respond to it. IBM reports that, on average, it takes organizations 206 days to identify a data breach and 73 days to contain that breach.

That means when a data breach occurs, it will take the organization about nine months just to find and stop it. Unfortunately for Mission Health, the time it took them to find the injected malicious scripts was about three years – much higher than average.

Perform Code Review to Find Cross-Site Scripting Flaws

Cross-site scripting occurs when a web application doesn’t properly sanitize user input and their input (such as malicious code) is either reflected or stored on the returned page. In Mission Health’s case, it was stored – which can have a severe impact. Web applications are one of the most common attack surfaces for data breaches, and OWASP has determined the XSS flaws are among the 10 most critical security risks to web applications.

It’s extremely difficult to find and remove XSS flaws from a web application, but OWASP says:

“The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output.”

Code review is a tedious job, but someone needs to do it so that XSS flaws or injected malicious scripts don’t go unnoticed for three years.

Part of thorough code review is testing against OWASP’s XSS prevention rules:

  • Never Insert Untrusted Data Except in Allowed Locations
  • HTML Escape Before Inserting Untrusted Data into HTML Element Content
  • Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
  • JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
  • HTML escape JSON values in an HTML context and read the data with JSON.parse
  • CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
  • URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
  • Sanitize HTML Markup with a Library Designed for the Job
  • Avoid JavaScript URLs
  • Prevent DOM-based XSS
  • Use HTTPOnly cookie flag
  • Implement Content Security Policy
  • Use an Auto-Escaping Template System
  • Use the X-XSS-Protection Response Header
  • Properly use modern JS frameworks like Angular (2+) or ReactJS

Web Application Penetration Testing

Once code review is performed, a web application penetration test should also take place. The goal of the penetration test is for no additional web application vulnerabilities to be discovered. If there are, that means the code review wasn’t thorough enough – but penetration testing is valuable for validating this.

Web applications can be problematic for many security analysts who don’t have the experience to be testing them – especially if it’s done in conjunction with code review. We often see other firms blindly assign an analyst to a web application project, but without the proper knowledge and expertise, a penetration tester can miss important findings within the web application. That’s why web application penetration testing methods at KirkpatrickPrice include the following, plus more:

  • Forced Browsing
  • Session Management
  • Cookie Manipulation
  • Source Code Disclosure
  • Response Splitting
  • File Upload/Download Attacks
  • URL Manipulation
  • Injection Attacks for HTML, SQL, XML, SOAP, XPATH, LDAP, Command
  • XSS

At KirkpatrickPrice, we also take a hybrid approach to code review that includes both automation and manual assessment in order to find any vulnerability that, if discovered, could be abused. Our team of highly skilled penetration testers have the expertise to understand the complexities of your code.

If you want to avoid a data breach due to unnoticed, cross-site scripting flaws like the one at Mission Health, contact us today.

More Penetration Testing Resources

Guide to 7 Types of Penetration Tests

Think Like a Hacker: Common Vulnerabilities Found in Web Applications

7 Reasons Why You Need a Manual Penetration Test

HITRUST®, a the leader in information security and privacy risk management and compliance programs, has announced a much-anticipated update to the HITRUST CSF in an effort to remain one of the leading data protection standards. HITRUST CSF v9.3 adds new privacy and security standards and updates six others existing within the certifiable framework. These changes were made in response to the ever-shifting information security landscape that is consistently updated with new laws and regulations.

As expected, the most significant updates in the CSF v9.3 are the inclusions of The California Consumer Privacy Act (CCPA) 1798 and The South Carolina Insurance Data Security Act 2018 (SCIDSA) 4655. As these laws are enacted and amended, HITRUST is working to enhance its own framework and continuing to stay up to date on all information security advancements. How do these laws affect HITRUST assessments? Let’s take a look at the basics of CCPA and SCIDSA.

Inclusion of CCPA

CCPA was enacted in 2018 in an effort to provide legal protection of consumers’ personal data and rights to access information about how personal data is shared and stored. The law goes into effect on January 1, 2020 and will affect businesses in and out of California. If an organization conducts business and handles the personal data of California consumers, it may be subject to CCPA. The main legal requirements, as of now, include consumer rights to access, deletion, non-discrimination, and opt-out of selling, privacy disclosure related to data collection and use and disclosure, vendor contract requirements, and implement and maintain reasonable security measures.

HITRUST CSF v9.3 includes information and mapping related to CCPA to provide a holistic framework that meets organizational security needs. As the law is amended and adjusted, HITRUST will continue to update its information to reflect any changes to the law.

Inclusion of SCIDSA

SCIDSA was enacted to establish better standards for data security, investigation, and notification of cybersecurity events. The law requires qualifying organizations to have a comprehensive information security program and proper reporting procedures in place for cybersecurity events. The act was signed into law in 2018 and went into effect January 1, 2019. The main components of SCIDSA requirements include a risk assessment, establishment and monitoring of an information security program, risk management, training, and due diligence, investigation of cybersecurity events, notification of cybersecurity events, and reporting, notices, and certification of compliance.

As more states write and enact their own data security and cybersecurity law, the HITRUST CSF adapts; the inclusion of SCIDSA in v9.3 is a testament to that.

What to Expect From HITRUST CSF v9.3

Other changes in this updated version of the CSF include:

  • NIST SP 800-171 R2 (DFARS)
  • AICPA 2017
  • CIS CSC v7.1
  • ISO 27799:2016
  • CMS/ARS v3.1
  • IRS Publication 1075 2016
  • NIST Cybersecurity Framework v1.1

Updates for information security laws and policies, plus the enhancements of an updated glossary, source mappings, and streamlined questioning help the HITRUST CSF to become a more well-rounded framework for your organization. If your organization is currently in an existing v9.2 assessment, you won’t see an impact unless you see fit to adjust your assessment to the scope and requirements of v9.3. As 2020 quickly approaches, you can expect to see the major release of HITRUST CSF v10 towards Q4, according to HITRUST. To learn more about HITRUST CSF v9.3 or to talk with an expert, contact KirkpatrickPrice today.

More HITRUST Resources

Navigating HITRUST CSF Compliance

Preparing for CCPA: 4 Data Privacy Best Practices to Follow

7 Deadly Sins of a HITRUST CSF Assessment

Could what happened at Capital One happen at your organization?

That depends on your commitment to cloud security. This breach could happen to any organization that’s not educated on AWS vulnerabilities and best practices. We’ve talked about how security misconfigurations played a role in Capital One’s breach, but now let’s discuss how privilege management contributed to this successful hack.

What Happened at Capital One with IAM Misconfigurations?

According to Verizon’s 2019 DBIR, misuse of privileges is the cause of  nearly 70% of breaches and 29% of all breaches involve the use of stolen credentials. Privilege management, misuse, and Identity & Access Management (IAM) misconfigurations led to the first misstep in the Capital One Breach.

When the attacker executed the first command, the hack began. This command allowed the attacker to acquire security credentials for a specific WAF-role with elevated privileges that had access to folders in Capital One’s AWS environment.

Did this role need elevated privileges?

The public can’t know for a fact. Were those credentials protected appropriately? Apparently not, because the environment was susceptible to the SSRF attack that had detrimental consequences for Capital One. It’s important to evaluate privileges assigned to all roles in your organization.

The Principle of Least Privileges in AWS

In AWS, the concept of least privilege means that you give users the least amount of access and responsibility necessary to complete their duties. Least privilege is also referred to as role-based access or need-to-know access and falls under AWS Identity and Access Management policies.

Configuring a system based on least privileges and need-to-know principles aren’t new concepts, but many organizations fail in this area. Best practice for least privileges comes down to the assignment of roles and responsibilities, limiting access based on what’s required, and creating a separation of duties. Consider the following requirements from industry frameworks:

  • SOC 2 common criteria 6.3 says, “The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.”
  • We see the subject of least privileges again in PCI Requirement 7.1.2, where it requires organizations to limit access to privileged user IDs to personnel who truly require it for the function of their job.
  • Least privileges and minimum necessary is also key to the HIPAA Privacy Rule, which requires covered entities to enhance their safeguards to limit unnecessary or inappropriate access to and disclosure of PHI.

AWS Security Best Practices for IAM

Best practice for least privileges is to ensure that your policies allow the fewest actions and access to resources as possible.

It is even AWS’ recommendation that when you create IAM policies, you begin with least privileges and then grant elevated privileges when necessary. IAM policies should also be tested by someone with knowledge of your AWS environment and IAM policies for assurance that they are functioning as intended.

AWS recommends creating IAM policies surrounding these subject areas:

  • Lock Away AWS Account Root User Access Keys
  • Create Individual IAM Users
  • Use Groups to Assign Permissions to IAM Users
  • Grant Least Privilege
  • Get Started Using Permissions with AWS Managed Policies
  • Use Customer Managed Policies Instead of Inline Policies
  • Use Access Levels to Review IAM Permissions
  • Configure a Strong Password Policy for Users
  • Enable MFA
  • Use Roles for Applications that Run on Amazon EC2 Instances
  • Use Roles to Delegate Permissions
  • Do Not Share Access Keys
  • Rotate Credentials Regularly
  • Remove Unnecessary Credentials
  • Use Policy Conditions for Extra Security
  • Monitor Activity in Your AWS Account

Don’t underestimate the value and complexity of IAM policies, though – especially in AWS. IAM policies are one of the most complicated things out there because you have to have an operational and security perspective. IAM policies give your organization the power over which actions can be performed by or on any given resource in your AWS environment. How does your organization ensure that IAM policies protect your AWS environment?

How to Strengthen AWS Environments With Proper IAM

As more data migrates to AWS, organizations must have processes in place to validate their cloud security efforts. Whether that’s through consulting with an AWS Cloud Practitioner or CCSK, something like a SOC 2 audit, or advanced penetration testing, you need a third party’s perspective and expertise to gain assurance.

What consequences would you face if, like Capital One, your clients’ data was compromised?

We don’t want you to ever have to find out. Let’s partner together to secure your AWS environment.

More AWS Security Resources

Cloud Security Audits

The Justice Department’s complaint

AWS’ Letter to Senator Ron Wyden

Who’s Responsible for Cloud Security?

Who Should Perform Your Cloud Audit?